协调问题不在模型
大多数构建多 Agent 系统的团队一开始都假设瓶颈是模型能力。事实很少如此。对于子任务而言，模型已经足够好。最先崩溃的是协调层：Agent 如何共享状态，如何决定下一个由谁行动，以及当其中一个产出了其他 Agent 无法使用的东西时，系统如何恢复。
单个 Agent 是一个循环。而一个集群是一个分布式系统，其节点不可靠，且以自然语言通信。第二种视角才能准确预测失败模式。
为什么自然语言交接是脆弱的
当一个 Agent 把工作交给另一个 Agent 时，交接通常是非结构化文本。这在原型阶段很方便，在生产中却很昂贵，原因有三。
第一，自然语言交接是有损的。接收方 Agent 必须从散文中重新推断意图。如果发送方遗漏了某个约束，接收方无法恢复它。没有任何 schema 可供校验。
第二，它们是非确定性的。相同的上游输出在不同运行中可能被解读为不同含义，这使得失败难以复现。
第三，它们掩盖了部分失败。一个返回看似合理但不完整结果的 Agent，与一个成功完成的 Agent 看起来一模一样，除非下游有东西去检查它。
解决办法不是消除自然语言，而是约束交接面。为 Agent 间消息定义一个带类型的信封：任务标识符、产出的 artefact、必须成立的约束，以及一个显式状态。Agent 的散文可以放在某个字段里，但编排器路由和校验的依据是信封。
一个具体机制：带类型的信封与校验门
设想一条研究与起草流水线，包含一个 planner、若干 retriever、一个 synthesiser 和一个 critic。没有结构时，synthesiser 收到一堆文本，然后猜测什么重要。
有了带类型的信封，流程如下：
{
"task_id": "r-014",
"produced_by": "retriever-2",
"status": "partial",
"artefact": { "claims": [ { "text": "...", "source": "..." } ] },
"constraints": ["no claims without a source", "max 12 claims"],
"missing": ["coverage of the cost dimension"]
}
编排器不读散文。它读 status、constraints 和 missing。如果 status 是 partial，它可以重新派发缺失的维度，而不是把一个降级的 artefact 继续传递下去。synthesiser 只接收约束已满足的信封。
这就是校验门，也是大多数集群中单点杠杆最高的补充。它把静默降级转化为显式的路由决策。它还让系统变得可测试：你可以在不调用任何模型的情况下，把一组记录下来的信封重放进编排器。
拓扑选择及其代价
不存在普遍正确的集群形态。常见的有三种，每一种都要放弃一些东西。
Supervisor 模式。 一个编排器 Agent 向 worker 派发并聚合结果。易于推理，易于记录日志，并且把失败处理集中化。代价是瓶颈：supervisor 的上下文必须容纳足够信息才能正确路由，而它成为单一节点，其错误会传播到所有地方。
Pipeline 模式。 Agent 串联成链，每个转换前一个的输出。简单且可预测。代价是脆弱：早期的错误会累积，且没有分支来吸收它。Pipeline 适合规格明确的转换，而非开放式研究。
点对点或辩论模式。 Agent 直接交换意见并收敛到一个答案。它能暴露出 supervisor 会抹平的分歧。代价是难以设界：token 开销、延迟和终止条件都变得不平凡。没有显式的轮次上限和收敛判据，它可能无限运行，同时产出听起来自信的噪声。
在实践中，大多数生产系统是一个带类型信封的 supervisor 加上一两条专门的子流水线，而不是一个全连接的网状结构。
诚实的取舍：并行换来延迟，代价是一致性
并行运行 Agent 能减少墙钟时间并提高吞吐量。它同时也移除了顺序上下文，使得后一个 Agent 无法看到前一个 Agent 学到了什么。两个并行工作的 retriever 可能返回重叠或矛盾的 claim；而顺序链本可以让第二个避开第一个的死胡同。
这个取舍是真实的，无法通过工程手段消除。能做的是让合并步骤显式化。并行分支应当发出带类型的信封，合并应当按一条既定规则来调和冲突，例如优先选择 provenance 分数更高的来源，或把冲突标记给 critic Agent。没有合并策略，并行只会更快地产出更大一堆未经验证的文本。
第二个取舍是可观测性。每增加一个 Agent，就增加一跳需要追踪。如果编排器不为每个信
评估必须针对接缝
孤立地评估单个 Agent 是必要的，但不充分。集群中真正重要的失败发生在接缝处：一次交接丢掉了约束，一次合并错误地解决了冲突，一次重试重复了工作。
一个实用的方法是在三个层次上评估。
- Agent 层。 给定一个格式良好的输入，Agent 是否满足自身的契约？这最容易测试，也最不能预测系统行为。
- 交接层。 给定记录下来的上游信封，下游 Agent 是否产出一个满足其声明约束的信封？这能捕捉 schema 漂移和静默的部分失败。
- 轨迹层。 给定一个完整任务，系统是否能在有界的步数和 token 内达到可接受的结果？拓扑和合并策略实际上是在这里被检验的。
轨迹评估需要一个独立于 Agent 自我报告的可接受结果定义。否则系统就是在自己给自己批改作业。
先构建什么
如果集群正在失败，修复的顺序比任何单一修复的精巧程度都更重要。
- 为每条 Agent 间消息引入带类型的信封。仅此一项就能让失败变得可见。
- 在每个交接处加上校验门，带一个显式的
partial状态和一条重新派发路径。 - 为并行分支定义合并策略，包括如何检测和解决冲突。
- 为每个信封埋点结构化 trace，使运行可以重放。
- 只有在此之后，才去调 prompt 或换模型。
大多数团队反着来，在协调层甚至无法表达哪里出错之前，就先去抓一个更强的模型。
结论
扩展 LLM Agent 集群是一个披着机器学习外衣的分布式系统问题。模型通常够用；交接、合并策略和可观测性通常不够。带类型的信封、校验门和轨迹层评估，针对的是生产中实际出现的失败模式。这些取舍，尤其是并行与一致性之间的取舍，是结构性的而非偶然的，诚实的做法是有意识地做出选择，并为后果埋点。
封面照片：panumas nikhomkhai / Pexels。