多Agent工作流长程任务实践：为什么便宜的模型反而最贵

近期，主流动了大模型市场动作频频，随着 GPT-5.6 Luna 的降价和 DeepSeek V4 Flash 的升级，一种多 Agent 协同方案开始流行起来：

让更强、更贵的模型负责顶层规划与任务编排，然后将执行环节交给更便宜的模型。
这套逻辑听起来很完美——既能保留强模型的判断力，又能大幅降低 Token 成本。

但我在实际项目中跑了几轮后发现，效果远低于预期。

前阵子 Fable 刚解禁时，周额度只能用 50%…😅
为了精打细算，不少人都建议拿 Fable 做调度，把具体实现交给 Opus。
我也照着这个思路反复尝试，可不论怎么调整提示词，最终产出的质量和完成速度，都没有明显超过全程直接用 Opus。

这是为什么呢？

我觉得核心问题在于：很多长程任务根本没办法简单地拆成独立块来分别执行。
比如真实的编程开发场景，理解需求、阅读代码、排除错误方向、选择技术方案、实现细节和后续修正，本来就是一条连续的判断链。

把它强行拆分给多个 Agent，就意味着反复交接。前置 Agent 读过哪些代码、排除过哪些方向、为什么选了当前方案——这些宝贵的“思维上下文”在交接过程中极易丢失，导致后续步骤产生偏差。

更糟糕的情况是：如果前置 Agent 在规划时选错了路径，后面的执行 Agent 往往会把这个错误结论当成既定前提，继续闷头沿着错误方向跑，越做越错。
最终，主 Agent 还是得被迫重新读代码、检查结果、解释问题并修正偏差。
这样一来，看似省下了调用高级模型的 Token，实际上付出了更多的返工成本、审查成本，还引入了上下文污染、错误路径依赖，以及更长的交付周期。

难道多 Agent 方案就毫无价值吗？当然不是。
我觉得它更适合另外两种情况。

一种是任务彼此独立、能够并行处理，而且做错的风险很低。例如可以将检索、扫描和信息整理交给子 Agent，这样反而能保护主 Agent 的上下文不被海量“噪音”污染。

另一种是“独立视角”和“角色隔离”。比如让多个模型各自提出方案，再由另一个模型来综合；或者让不同 Agent 分别负责编码、代码审查和测试，甚至专门安排一个 Agent 做对抗性审查，避免同一个模型既当运动员又当裁判。

所以，当下次选择模型时，也许我们第一个要问的问题不应该是：

“哪个模型最便宜？”

如果想了解更多关于 人工智能 及其在 Agent、深度学习等领域的实践经验，欢迎来云栈社区一起交流。