GPT5.6多智能体并行功能耗资惊人引热议

背景

近日，在 LINUX DO 论坛的 AI 板块中，一篇题为《GPT5.6 Sol极高也太离谱了吧》的帖子引发讨论。发帖人描述了一次使用 GPT 模型（论坛中称其为“GPT5.6”）进行开发辅助的经历：原本只是将静态页面的接口文档提交给模型，期望其自动完成接口对接，但模型在后台持续调用多个子智能体并行执行，直到用户午睡醒来仍未处理完毕，且消耗了接近 40 美元的额度。用户对此感到惊讶，并询问能否单独关闭这种“极高的多智能体并行”功能。

该帖子共有 5 条回复、4 位参与者，反映出社区成员对 AI 工具成本控制与智能体调度机制的高度关注。虽然帖内未公布具体模型版本细节，但“GPT5.6”和“Sol 极高”这两个术语指向了某种高阶多智能体协同模式，其资源消耗远超常规单次对话。

核心内容

原文核心事实如下：

• 任务场景：用户已完成静态页面的开发，在午睡前将接口文档提供给模型，期望模型自动完成与后端接口的对接工作。
• 执行过程：模型并未按常规单次推理完成，而是启动了“多智能体并行”模式，不断调用各种子智能体（可能包括代码生成、接口测试、错误修正等专门化子智能体）来协同处理。
• 结果：用户午睡醒来后发现任务仍未执行完毕，且账单显示已消耗近 40 美元额度。
• 用户疑问：能否单独关闭这种“5.6 极高的多智能体并行”功能？——暗示该功能默认开启或自动触发，用户未主动选择。
• 社区讨论：帖子下有 5 条回复、4 位参与者，表明社区对这一问题有初步交流，但原文未透露具体回复内容。

需要特别说明的是：原文中“GPT5.6”并非 OpenAI 官方发布的模型版本，可能是论坛用户对某类高级模型（如 GPT-4 或后续版本）的戏称或代号；“Sol 极高”可能指代“Sol”指标（需结合上下文，可能为“如此极高”的笔误，也可能是“Sol”作为某种并行度参数），但本文忠实保留原词。

关键要点

• 成本失控：一次简单的接口对接任务，因模型自动启用多智能体并行，消耗近 40 美元，远超用户预期。这凸显了 AI 工具在复杂任务中的“隐形开销”风险。
• 默认行为设计：“多智能体并行”功能似乎被模型默认启用，用户无法在任务开始前预知或关闭，导致被动接受高消耗。
• 子智能体调用机制：模型内部可能存在多个专门化智能体（如代码解释器、API 调试器、文档解析器等），它们被并行调度以完成复杂任务，但缺乏对执行时间和成本的显式控制。
• 用户控制权缺失：用户希望获得“单独关闭”该功能的选项，但目前模型界面或 API 可能未提供此类细粒度开关，暴露了产品设计上的不足。
• 社区关注度：帖子在短时间内获得 5 条回复、4 位参与者，说明该问题在开发者和 AI 重度用户中具有普遍性。

意义与影响

1. 对模型开发者的启示：成本透明度和用户控制权应成为核心设计原则。当模型自动启用多智能体并行等高消耗模式时，应提前告知用户预期耗时和费用，并提供手动关闭或限制并行度的选项。否则，用户可能因“账单惊吓”而放弃使用。

2. 对用户实践的影响：开发者在使用 AI 辅助编程时，需警惕“任务简单位、成本却极高”的陷阱。建议在提交复杂指令前，手动限制模型的最大推理步数或关闭子智能体调用。同时，应关注模型文档中关于“智能体并行”的开关配置。

3. 对技术社区的讨论价值：该帖子揭示了当前 AI 模型在“自主规划-执行”模式下的成本失控问题。类似“GPT5.6”的案例可能并非孤例，而是模型朝着更高自主性演进时必然伴生的副作用。社区需要推动更透明的定价机制和更灵活的配置接口。

4. 对产品演进方向的思考：如果模型无法提供“安全模式”或“低消耗模式”，用户可能转向成本更可控的替代方案（如本地模型或按 Token 计费的 API）。未来，多智能体并行功能应像“自动续费”一样，需要用户主动确认才能启用，而非默认开启。

5. 长期影响：随着 AI 模型能力增强，类似“睡着了还在烧钱”的场景会越来越多。这要求模型厂商在追求性能的同时，建立清晰的成本预期和用户授权机制，否则可能引发用户信任危机，阻碍 AI 在生产力场景中的规模化落地。