单Agent有天花板：一个上下文窗口、一个视角、串行思考。多Agent承诺更多，代价是协调开销和故障面成倍增加。三种真实架构模式、通信契约和终止条件，这篇讲清。

📜 目录

• 一、先做三个测试，再决定要不要多Agent
• 二、三种模式
• 三、通信契约：结构化，不要自由文本
• 四、四个必须写死的东西
• 五、框架怎么选
• 六、一个最小可用的编排循环
• 七、成本与延迟的真实账
• 八、常见问题
• 相关文章

多Agent系统架构2026：编排者、对等、层级三种模式

单Agent有天花板：一个上下文窗口、一个视角、串行思考。多Agent承诺更多，代价是协调开销和故障面成倍增加。这篇讲三种真实可用的架构模式，以及让它们不散架的工程约束。

一、先做三个测试，再决定要不要多Agent

1. 任务能干净拆分吗？ 研究报告可以拆成检索、事实核查、成稿；客服对话拆不动。
2. 子任务需要不同上下文吗？ 每个工人只带自己那段材料，比全塞给一个Agent更省token、更专注。
3. 质量瓶颈在广度还是深度？ 需要"多个独立视角互相挑错"才值得上多Agent；单线深度任务用一个Agent加好工具更省。

三个都答"是"再动手。任何一个答"否"，先用单Agent加工具试一周——多数需求在这一步就满足了。

二、三种模式

编排者最常见也最可控：控制流集中在一处，好调试、好加预算。对等适合"必须挑错"的场景，但一定要设迭代上限。层级能扩展到大问题，代价是每一次委派都是一次信息有损压缩。

三、通信契约：结构化，不要自由文本

Agent之间传自然语言，是故障的第一来源：格式漂移、字段丢失、幻觉出不存在的结果。用固定的JSON结构：

{
  "task_id": "t-001",
  "from": "orchestrator",
  "to": "researcher",
  "objective": "列出2026年三家主要供应商的产能",
  "constraints": ["只引用可核查来源", "不超过5条"],
  "output_schema": {"items": [{"name": "", "capacity": "", "source": ""}]},
  "deadline_tokens": 4000
}

工人回传时只允许填 output_schema 的形状。解析失败就当作失败任务重派，别让编排者去"理解"一段跑偏的文字。

四、四个必须写死的东西

1. 唯一真相源：共享状态存在一处（数据库或状态对象），Agent只读写它，不要在消息里复制状态。
2. 有界迭代：每个循环设最大轮数，比如批评-修订最多3轮。没有上限的辩论一定会烧穿预算。
3. 预算上限：按会话设token上限，超限强制收口并返回当前最佳结果。
4. 人机检查点：写操作、对外发送、付费动作之前必须有人确认。这条不是保守，是止损。

五、框架怎么选

选型看一件事：你需要控制流程，还是只需要描述角色。前者LangGraph，后者CrewAI。上线前都要补自己的追踪和预算，框架自带的观测通常不够。

六、一个最小可用的编排循环

state = {"goal": goal, "findings": [], "round": 0}

while state["round"] < 3:
    plan = orchestrator.plan(state)                  # 拆解下一步
    result = worker.run(plan, schema=OUTPUT_SCHEMA)  # 结构化返回
    ok, why = validate(result)                       # 校验形状与来源
    if not ok:
        state["errors"].append(why)
        continue
    state["findings"].append(result)
    if critic.approve(state):                        # 满足完成条件
        break
    state["round"] += 1

return finalize(state)

关键是 validate 和 critic.approve 都是代码判定，不是让模型自己说"我做完了"。

七、成本与延迟的真实账

多Agent的成本结构和单Agent完全不同，先算清再上线：

一条容易忽略的：并行不是免费的，它把串行延迟压力换成了并发压力。API有速率限制时，并行委派会撞429，反而更慢。

经验值：一个带批评循环的3Agent流水线，做同一件事的token消耗通常是单Agent的3-5倍。这个倍数能不能换来值得的质量提升，只有你的评估集能回答。

八、常见问题

Q：多Agent一定比单Agent准吗？ A：不一定。分工带来专注，也带来信息损耗。基准测试要在自己的任务上做，别信宣传。

Q：几个Agent合适？ A：从2个开始（编排+工人），按需要加。每加一个都是新的故障面和新的token开销。

Q：怎么调试？ A：必须有每次会话的完整追踪（谁发给谁、什么内容、花了多少token）。没有追踪的多Agent系统基本没法维护。

Q：能全自动跑长任务吗？ A：可以，但要有人机检查点和预算上限。全自动无上限的长任务，失败时你连停都停不下来。

注：各框架的API与能力随版本变化，以官方文档为准。

相关文章

• GitHub上的多智能体系统：10个框架真实星数
• 本地LLM搭建：Reddit网友真实推荐
• 在iPhone上运行Ollama：3种可行方法