用 CrewAI 这类第三方 SDK：多 agent 值不值

多 agent 是这个领域最容易被过度使用的东西。这一篇讲什么时候值得。

先问三个问题

加第二个 agent 之前：

一、一个 agent 到底卡在哪？ 说不出具体卡点，加一个只会把问题摊开成两份。

二、这个卡点是「装不下」还是「做不好」？ 装不下（上下文超了）加 agent 有用；做不好（能力不够）加一个同样做不好的 agent 没用。

三、我需不需要一个独立的判断视角？ 这一条如果是「是」，直接上 —— 见下。

唯一不可替代的理由

前两个理由都能用别的办法缓解（压缩上下文、换更强的模型、拆成多轮）。只有第三个不能。

让写东西的那个评判自己写得好不好，它会夸自己。 这是结构问题不是智力问题 —— 它没法跳出自己的视角。

有实践把「把干活的和判活的分开」称为一个强杠杆；同一现象在别处叫 No Ground Truth —— 模型会报告成功，不管它是不是真的成功了。

所以「一个写、一个专门挑刺」这种两 agent 结构，是多 agent 里性价比最高的一种，而且它不需要复杂的编排。

编排方式：三种，控制权递增

排序是自主性从低到高，可复现性从高到低。 选哪个的判据很实际：你需不需要比较两次运行？ 需要就往上面选。

建议从代码编排开始。 它最土，但同一份输入两次跑路径完全一样 —— 而这是你能衡量任何改进的前提。

工业界最成功的那个案例，协调机制简单得离谱

值得拿来对照一下期望。有一个 16 个 agent 并行写出十万行代码的项目，它的协调机制是：

认领任务 → 往一个目录里写个文件
两个 agent 抢同一个 → git 同步时天然冲突
干完 → 拉取、合并、推送、释放

没有消息总线，没有中央调度器，没有角色分工。 作者自己写明：agent 之间没有别的通信方式，也没有任何管理高层目标的流程。

它把并发控制外包给了一个已经存在四十年的系统。 git 本来就要解决「多人改同一份代码」，那么「多个 agent 改同一份代码」就是同一个问题。

所以别急着造复杂的协调机制。 先看看有没有现成的东西能承担这件事。

交接处必须有契约

多 agent 最阴险的失败是错误沿着链路洗白。

这不是我的个案。MAST 对 7 个框架、1642 条执行轨迹做过失败归类，三大类的分布是 系统设计 43.9% / agent 之间对不齐 32.15% / 任务验证 23.5% —— 中间那一类整整占三成，而它全部发生在交接处。

有份多 agent 案例研究把「在交接处校验显式契约」列为五条设计准则之一。我加一条更具体的：下游校验时，参照物只认原始材料，不认上一步的产物。

这条规矩是我自己撞出来的。我那套东西的依据校验一开始写得很松，允许下游引用上一步生成的状态机；结果上游编出来的一个界面文案，被下游当成既定事实原样引用，校验全程绿灯 —— 因为那句话确实“有出处”，出处就是上一步。我的判断是：出处链只要允许指向中间产物，它就会自己把错误洗白。 现在的口径是引号里的原话必须能在原始材料里逐字找到，中间产物一概不认。

边界与代价

多 agent 的调试成本是超线性的。 一个出错你看它的输出；四个出错你得先定位是谁、再看它拿到的输入 —— 而它的输入是别人的输出。

收益需要被证明，不能被假设。 有实验量过让 meta agent 设计 agent 结构的经济性：回本点在约一万五千个样例，很多场景永远回不了本，而且设计出来的 agent 运行还更贵。多 agent 编排比那个便宜得多，但同样要先量一个 agent 的上限。

共享记忆要当心。 一次误判被固化成事实，后面所有 agent 都跟着错。进记忆要有门槛，出记忆要有期限。

这个系列到这儿。 五篇合起来只回答了一个问题：哪一段该交给模型决定，哪一段不该 —— 而这个问题的答案，决定了你能不能说清楚自己的系统这周比上周好在哪。