GPT-5.6-sol Bug：无法调用工具导致卡死

背景

近日在 LINUX DO 社区的 AI 板块中，有用户报告了一个关于 GPT-5.6-sol（推测为某个模型或实验版本）的 bug。该 bug 表现为：在特定提示词触发下，模型陷入「左右互搏」的循环，无法正常调用工具（如搜索、代码执行等外部能力），最终导致回答卡死。该用户通过细致复现，锁定了触发条件，并引发了社区 7 位参与者的讨论。此问题涉及大型语言模型与工具调用（Function Calling）的交互机制，对依赖模型工作流（agent workflow）的用户具有重要参考价值。

核心内容

用户在使用 GPT-5.6-sol 时，发现模型在处理任务时出现异常：模型试图调用工具去「审查」某些内容，但始终无法实际调用，而是停留在自我对话状态——模型一直在说自己要做什么，却无法执行。具体过程如下：

1. 初始尝试：用户未提供明确的「goal」（目标）时，模型完全不动手，没有任何输出。用户随后指示模型「主动干活」，模型回复了其计划，但始终卡在「打算调用工具」的阶段，无法真正执行。

2. 加入 goal 模式：用户提供了具体 goal 后，模型开始「自己攻打自己」——似乎是在内部模拟调用工具的流程，但一直卡住，无法完成。

3. 触发条件复现：用户发现该 bug 是由以下提示词触发的：

   请你在回答前，先向我提问。要求：一次只问一个问题。请根据我的回答继续追问，直到你有 95% 的信心，完全理解我的真实需求和目标后，再给出最终方案。

   在模型按照该提示词向用户提问几轮后（即用户回答了几个问题后），模型就再也无法调用工具了。但若用户使用 /clear 清除对话历史，然后直接让模型执行任务（不附加上述提问逻辑），模型则可以正常调用工具，没有卡顿。

4. 社区反馈：该帖子共有 9 条回复（7 位参与者），表明该 bug 引起了关注，可能涉及多个模型版本或类似 prompt 的普遍问题。

关键要点

• bug 表现：模型陷入自我对话循环，声称要调用工具却无法实际调用，最终回答卡死。
• 触发条件：使用特定提示词要求模型先通过多轮提问来确认用户需求（直到 95% 信心），在该流程执行几次后，工具调用功能失效。
• 恢复方法：清除对话（/clear）后，模型恢复正常工具调用能力。
• 关键变量：无 goal 时模型完全不动；提供 goal 后模型开始「自攻自守」但仍卡死；清除对话后问题消失。
• 影响范围：7 位参与者帖子，表明可能不是个例，且与模型内部的工具调用逻辑、状态管理、多轮交互的上下文溢出或权限冲突有关。

意义与影响

1. 揭示了 LLM 在复杂 prompt 下工具调用机制的脆弱性：要求模型「先提问确认需求」是一种常见的 prompt engineering 策略，但该案例表明，这种多轮交互可能破坏模型维持工具调用状态的能力，导致 agent 行为异常。
2. 为 agent 工作流设计提供警示：开发者在构建依赖工具调用的 agent 时，需要谨慎使用「反问式」前置提示。建议在明确规划好工具调用与对话轮次的边界后再使用此类 prompt，或预留 [reset tool context] 之类的控制手段。
3. 凸显了清除历史对恢复模型状态的价值：/clear 能解决问题，说明 bug 来源于上下文积累或内部状态污染，而非模型参数本身的永久缺陷。用户和开发者应了解这一恢复手段。
4. 可能影响相关模型的 prompt 设计最佳实践：社区参与者可据此调整 prompt，例如将「先问后答」逻辑拆分为两个独立调用（先提问收集信息，再在后续轮次中赋予工具调用权限），而非一次对话内同时包含提问与工具调用。
5. 对 AI 产品的稳定性测试提出新需求：类似 GPT-5.6-sol 的模型在发布前，应重点测试「无 goal→有 goal→多轮反问→工具调用」的序列压力场景，确保工具调用不会因前置对话逻辑而失效。