从「能聊」到「能跑」：一套多 Agent 协作体系的搭建复盘

type

Post

status

Published

date

Mar 9, 2026

slug

multi-agent-collaboration-retrospective-from-chatting-to-running

summary

从调度缺位、状态失真与并行污染等问题出发，复盘一套多 Agent 协作体系如何从会聊天走到能稳定交付。

从「能聊」到「能跑」：一套多 Agent 协作体系的搭建复盘（修订版）

这不是概念科普，而是一份工程复盘：我们如何把多 Agent 从“看起来很聪明”，调到“可以稳定交付”。

一、先说结论：多 Agent 不是默认答案，而是成本换收益的选择

我们早期也有一个误区：只要任务复杂，就上多 Agent。后来发现这会把系统拖入另一种低效——链路变长、调试困难、状态更难追。

真正有效的判断不是“单 Agent 还是多 Agent更先进”，而是：

这个任务是否需要动态分工？

效果提升是否值得支付延迟与调试成本？

失败后能否快速定位在哪一层出错？

什么时候不用多 Agent（我们沉淀出的决策段）

如果任务满足以下特征，优先单 Agent / 固定 workflow：

目标与路径都清晰：例如固定格式生成、规则明确的数据整理。

容错要求高于创造性：宁可慢一点，也要稳定可预测。

跨角色协作价值不大：拆分后并不会提高质量，反而增加沟通轮次。

调试窗口很短：你没有时间追调用链，必须快速可控上线。

一句话：

能用确定性流程解决的问题，不要先引入多 Agent 编排复杂度。

什么时候多 Agent 值得上

任务天然可分工（研究 / 执行 / 评审 / 验证）。

上下文规模已逼近单会话极限，需要隔离记忆污染。

需要并行缩时，而且子任务之间可以做到边界清晰。

需要持续任务线（跨轮次推进、可续派、可追踪）。

我们最终选择多 Agent，不是为了“同时让很多 agent说话”，而是为了把任务线工程化：

可分工、可追踪、可续派、可收口。

二、关键拐点：把“中书省”从聊天角色，升级成调度系统

最初的瓶颈并不在执行能力，而在调度缺位。主殿直接盯各执行席时，系统会退化为“人肉编排”：催进度、接回传、再分发、补状态都压在一个点上。

我们把中书省独立后，职责被硬化为四件事：

接旨回执：确认任务已入链路。

拆棒派工：把大任务拆成最小闭环，一次只发一棒。

续派推进：节点回传后自动推进，不靠主殿提醒。

可见留痕：只同步真实发生的动作，不制造“在跑”的幻觉。

分层之后，系统才从“一个会话很能聊”，变成“多角色能协作”。

三、从 0 到可跑：先做最小闭环，再做 handoff 扩展

这是本轮最关键的实现经验：

不要一上来做全套总控；先让一个最小循环稳定重复，再逐层扩展 handoff。

3.1 最小闭环定义（先跑通）

我们先固定一个可回退的最小循环：

输入入栈 → 决策调用 → 工具执行 → 结果回写

只要这个环不能稳定重复，任何“多角色协同”都只是堆复杂度。

3.2 闭环稳定后，再引入 handoff

第二步才引入“转交”：

中书省只负责路由与状态；

子 Agent 按专长执行；

回传必须带可判定 tag（done / handoff / blocked / need_user 等）；

中书省按 tag 决策下一棒，而不是凭语气判断。

3.3 为什么这种顺序有效

因为它提供了一个始终可回退的基线：

出问题时能先退回单环排障；

每新增一层能力都能验证“收益是否大于复杂度”；

避免系统一出错就变成“全链路都可能有问题”。

这一步让我们从“架构图很完整”，走到“运行面可持续”。

四、并行不是一起跑就行：我们在“串写污染”上吃过的大亏

并行阶段最痛的一次故障，不是模型能力不够，而是状态被并行支路互相覆盖。

4.1 现象

多支路同时写共享状态；

汇总节点拿到的是混杂上下文；

同样输入，输出质量波动明显，复现困难。

4.2 误判

我们一开始试图靠提示词约束“别覆盖别人内容”。

结果证明几乎无效：这不是提示词问题，而是状态结构问题。

4.3 修复（真正生效）

我们把并行段改成“子图隔离”：

每条并行支路持有独立状态域；

支路内完成自己的评审/修订循环；

只在汇总节点按规则合并；

汇总时只接收结构化产出，不吞整段原始上下文。

4.4 复盘结论

并行的核心不是“同时跑”，而是“隔离后再汇总”。

这一改动后，稳定性和速度都提升：

复现性更好；

回归排查路径更短；

汇总节点不再承担“垃圾回收器”角色。

五、我们踩过的其他关键坑（精简版）

坑 1：把“说过”当“做过”

会话里说“已发车”，但没有真实派工证据。

修正：已发车/已续派 必须绑定可核对标识（session key / run id / message id）。

坑 2：节点 done 被误判为整线 done

局部完成后未推进 next node，任务假结束。

修正：引入 line/node/end_node，done 后先判是否到终点。

坑 3：工具越多成功率越低

工具集膨胀导致选择歧义、命名冲突、上下文挤占。

修正：裁剪默认工具、统一命名规范、限制超长工具返回。

六、当前系统到底“跑通”到了哪一步

目前已经形成三个稳定收益：

流程不断线：节点推进不再依赖人工催办。

状态可核对：可见层反映真实动作，不再靠口头进度。

故障可定位：分层后能快速判断是路由、执行还是验证问题。

它已经不是演示态，但也还不是“全自动工厂”。

七、还没解决完的问题（对外读者可感知的真实局限）

观测仍偏文本：缺少自动化图谱、耗时统计、失败分布。

跨线冲突仲裁不足：资源冲突仍依赖调度经验。

验收口径不完全统一：不同执行席对 done 的证据粒度有差异。

八、下一阶段：从“可运行”走向“可规模化”

优先级建议：

协议升级：统一 node schema、回传字段、证据类型。

运行面板化：自动展示 line/node、阻塞点、时延分布。

验证接力模板化：把关键回归链路变成默认动作。

中期目标不是“增加角色名称”，而是让系统具备：

可追踪、可复现、可扩容。

九、一句话总结

多 Agent 的价值不在“更热闹”，而在把复杂任务从“谁都在管、没人负责”，变成一条可治理的工程链路：

分层明确、动作可证、状态可见、失败可修复。

这才是它从 demo 迈向生产的分水岭。