大模型做编排为何失败？消费级硬件实测

引言：换了大模型，编排就可靠了吗？

在本地跑多智能体系统的人大概都经历过这样的循环：Agent 执行长任务时丢步骤、把本该执行的委派当成文本输出、工具调用后返回空结果。直觉告诉我们，问题出在模型不够强。

上一篇终于把 77GB 的协调者模型跑稳了——显存不再抖动，worker 被迁到第二台机器。于是那个被推迟的问题终于可以正面回答：既然大模型真的能跑起来了，更大的协调者能解决编排问题吗？

答案是不能。而这个否定答案，意外地重塑了整个团队的工作方式。

天花板依然存在：大模型同样会翻车

内存不再是瓶颈之后，协调者的编排能力终于可以被单独评估。它的表现确实比 Gemma 更可靠——委派顺序更稳定。但它没能逃脱同样的失败模式：

• 长计划中依然会漏步骤，发出部分委派、悄悄略过另一些，然后直接写总结
• 偶尔把委派当成文本输出而不是真正执行（上一篇记录过一次：交接任务被打印成裸 JSON 后遭遗弃）
• 工具调用后周期性地返回空结果，需要外部自动催促才能继续：

⚠ Model returned empty after tool calls — nudging to continue

这条警告出现的频率高到足以作为诊断依据。关键在于，这些不是弱模型的错误，而是一个能力足够的模型被要求做它结构上不擅长之事所犯的错误——一边在脑子里维持一个长控制循环，一边在这个循环里做推理。

诊断：天花板在循环，不在模型

决定性的观察是：三种失败模式——丢步骤、用叙述代替执行、空回合——在大模型上出现的方式与小模型完全一致。共同因子不是模型规模，而是 agentic loop（智能体循环）本身。

让语言模型做编排，等于要求它同时扮演四个角色：决定步骤的规划者、发出每次委派的调度器、跟踪哪些委派尚未完成的记账员、以及判断返回结果是否合格的评价者。这需要跨越多轮对话携带大量状态，而跨轮状态保持恰恰是这类模型最薄弱的环节。

更大的模型只是把天花板抬高了一点，并没有拆掉它。

agentic loop（智能体循环） 指的是让语言模型在“思考—行动—观察”之间反复迭代的控制结构：模型先决定下一步动作（通常是调用工具或委派子任务），系统执行该动作并把结果回填到上下文中，模型再据此决定下一步，如此循环直到任务完成或达到终止条件。这种模式的优势是灵活，能处理开放式任务；代价是每一轮都要把完整的历史状态重新喂给模型，而上下文窗口有限、注意力会随长度衰减。因此循环越长，模型越容易“忘记”自己已做过什么、还剩什么没做。这也是为什么丢步骤、重复委派、空回合等错误往往在长任务的后半段集中出现——问题不在单次推理的质量，而在循环本身对跨轮状态保持的持续要求。

解法：把循环从模型手里拿走

如果问题在循环，那循环就不该是模型的工作。解法是确定性编排：用一个很小的脚本持有控制循环——它维护任务列表、派发每次委派、等待并收集结果、决定下一步跑什么。模型只在两件它真正擅长的事上被调用：规划（步骤是什么？）和评估（这个结果可接受吗？）。它永远不需要记住自己派发过什么，因为脚本负责记账。

改进立竿见影且可度量：同一个任务序列，模型驱动的循环跑到一半卡住，五步只完成三步就丢了线索；而同样的计划交给脚本执行，五步全部跑完。模型并没有变得更强，它只是被免除了那件它无法可靠完成的工作。

确定性编排（deterministic orchestration） 与模型驱动的自主循环相对，其核心思想是把控制流从概率性组件中剥离出来，交给普通的命令式代码。脚本中通常维护一个显式的任务队列或状态机，每一步的转移条件由代码写死：取下一个待办项、调用模型生成委派指令、执行委派、把结果写回任务记录、判断是否满足完成条件。模型被降级为无状态的“函数调用”，每次只接收当前子问题并返回结构化输出，不持有任何跨轮记忆。这样做的额外好处是可观测性与可重放性——每个步骤的输入输出都被脚本记录，失败时能精确定位在哪一步、能重跑而不污染全局状态，而纯模型循环中的错误往往难以复现和归因。

代价高昂的教训

当 agent 循环不可靠时，本能反应是换更大的模型。这个本能在此处是错的，而且代价高昂——它正是第四部分那场协调者搜寻、以及第五部分显存之墙背后的推理逻辑，最终却并没有解决它追逐的问题。

编排可靠性不是一种可以用更大参数量买到的模型能力，而是循环结构本身的属性。持久的修复是架构性的：把确定性部分——循环、记账、派发——搬进确定性代码，把模型留给真正需要判断力的环节。控制循环是程序的活，不是语言模型的活，这条分界线划得越早，系统就越可靠。

跨轮状态保持是衡量模型在多轮交互中维持一致内部表征能力的指标，也是当前语言模型公认的薄弱环节。即便上下文窗口足够长，模型对早期信息的利用率也会显著下降，中间位置的内容尤其容易被忽略。对于需要连续几十轮委派与等待的编排任务，这意味着模型实际上是在“每轮重新猜测自己之前做了什么”。扩大参数量能提升单轮推理质量，却无法从根本上改变这一机制——状态不在模型的参数里，而在对话历史里，而历史的使用效率受限于注意力机制本身。这正是把记账职责外移到脚本的理论依据：与其指望模型记住，不如让代码记住。

接下来：执行可靠了，判断力怎么办？

确定性编排让团队的执行变得可靠：计划不再丢步骤，也不会虚构进度。但当计划撞上墙——正确的下一步根本不在计划里，需要有人重新思考方法而不只是执行——它无能为力。

可靠执行和良好判断是两种不同的能力。下一篇要谈的，就是如何在不牺牲前者的前提下补上后者。

核心要点

• 在消费级硬件上实测：77GB 协调者模型运行稳定后，编排失败模式依然存在，模型规模不是解药
• 三种典型失败：长计划丢步骤、委派被当成文本输出、工具调用后返回空
• 根因是把规划、调度、记账、评估四种状态密集型职责压给语言模型，而跨轮状态保持正是其短板
• 解法是确定性编排：脚本持有控制循环，模型只负责规划与评估
• 同一计划从五步完成三步，变为五步全部完成——能力没变，职责变了