第 6 章 — 基础编排策略
LLM Primer IV: Designing AI Cognition with MCP 章节走读的第六篇。多 agent 系统就是一个分布式系统 — 接受这个框架之后,这一章里大多数设计决策就变得熟悉,2024 和 2025 年那些最贵的故障也就不再神秘。
这一章为什么存在
关于 agentic 系统的营销话术暗示 agent 越多本质上越好 — 更多认知马力、更多专精、更多涌现能力。工程现实在大多数场景里跟这个相反。每多一个 agent 就多一次往返、多一个序列化点、多一个 "前一个的输出变成后一个的输入" 的接口、多一个对话飘走的机会。该问的起点不是 "我怎么把这件事拆给好几个 agent?",而是 "一个配对工具的模型,能不能在一次调用里把这件事做完?"。
这一章走两种最简单的编排形状 — 顺序和并发 — 以及该排在两者之前的那个问题。过去两年里最贵的一些生产故障不是编排出了问题。是一些系统本来一个配齐工具的 agent 就够,却被造成多 agent,延迟十倍、还附赠协调 bug。
6.1 多 agent 真正帮上忙的时候
一个 agent 加工具的方案最强的场景,是任务能拆成少量定义清晰的操作,作用在定义清晰的数据源上。一个 code review 助手读 diff、跑 linter、查约定、写评论,可以做成一次模型调用挂四个工具。再加一个 agent 只会引入延迟而不增加能力 — 模型本来就在规划;让第二个模型用不同方式规划是协调成本,不是改进。
三类性质让多 agent 真的赚回来。上下文异质性 — 两个阶段需要差别极大的 system prompt、工具、参考资料,硬塞进一个窗口就稀释了模型的注意力。研究然后写作是教科书例子:检索想要广度和搜索工具,写作想要散文和零工具。对外部检查的迭代精修 — 输出要被复核且可能被重写,生产者和复核者都想要自己的上下文和 prompt。独立子任务的并行 — 五个文档源要总结、三种视角要收集、十个文件要分析 — 串行做就是在浪费没有因果依赖的工作的墙钟时间。
下决心做多 agent 之前,工程师应该能说出动机是哪一类性质。2025 年某大型物流公司的复盘里,他们把一个七 agent 的客服编排换成单 Claude agent 加六个 MCP 工具;单 agent 版本更快、更便宜、解决质量分数还更高。"我们能塌掉吗?" 应该是每次编排评审的常驻问题。
6.2 顺序编排:流水线与渐进精修
顺序编排是最简单的多 agent 形状。一个 agent 的输出变成下一个的输入。大多数生产里的 "多 agent" 系统其实是顺序流水线假扮的。强项是可读性:流水线能画在白板上、能按阶段测、能当一串输入-输出契约来推理。阶段间的契约是关键物件 — 每个阶段声明自己的输入 schema,编排器用代码而不是信任来强制,校验失败触发重试或回退,而不是默默传播下去。
典型场景是研究然后写作。一个挂着网络搜索和检索工具的研究 agent 产出一份结构化简报;一个没有工具、只有散文 prompt 的写作 agent 把简报变成一篇文章。写作 agent 看不到错的起步、丢掉的来源、长长的推理链。它看到的是简报。两个阶段可以用不同模型 — 推理强的做研究,文笔强的做写作 — 成本只在该花的地方累积。渐进精修是近亲:起草、编辑、事实核查、重排版。专精算子打过通才一次性想干完一切。
诚实的代价有三。延迟 — N 阶段流水线的下限是所有阶段运行时间的和。长流水线按定义就把自己排除在对话延迟之外。错误放大 — 四阶段每阶段 95%,端到端就是 81%;八阶段就是 66%。每阶段校验加有界重试是让这道算术能用的关键。阶段间信息丢失 — 每个输出必然比工作上下文窄,写作 agent 后面意识到需要的信息就没了,除非简报 schema 比严格需要的更丰富。
6.3 并发编排:scatter、gather、多视角
并发编排让多个 agent 并行跑,再把输出合并。决定性的性质是工作期间没有因果依赖 — 依赖只在合并那一步。有时候叫 scatter-gather,有时候叫 agent 版 map-reduce;拓扑是一样的。
三个用例让这个模式划算。独立子任务的并行 — 五个来源并行读,然后一个综合器。墙钟时间是最慢那个读取加综合器,而不是和。多视角分析 — 同一个输入分别交给金融分析师 prompt、法律评审 prompt、产品策略 prompt,而且这些框架真的不同到输出不只是表面变体。为可靠性做集成 — 同一个 prompt 跨几个 agent,输出投票或平均,在错答案的代价远高于 3 倍 token 账单时合理。
合并那一步是工程努力回本的地方。给天真的综合器塞一堆长长又互相矛盾的输入就成了瓶颈。三个模式能改善:结构化中间输出让综合器按字段确定性地合并,不用再读散文;层级归约让每个合并 agent 看到有界数量的输入,即便扇出在变大;冲突浮现让综合器标出分歧而不是默默挑一边。
判断 scatter-gather 对不对的诊断问题:如果我告诉一个并行 agent 另一个现在正在产什么,它会不会改输出?如果会,那这件事不是独立的,模式就错了 — 你需要的要么是顺序依赖,要么是第 7 章的动态模式。
6.4 协调的诚实算术
每一种编排模式,在运行时都是一个跑在不可靠 worker 上的分布式工作流。哪怕在优质模型上,单次调用 1% 到 5% 的失败率都很常见 — JSON 解析失败、契约违反、幻觉出来的 tool 名字、悄悄被跳过。乘进一条流水线,2% 单阶段 8 阶段就是 85% 端到端。缓解是结构性的:每阶段校验触发有界重试;每阶段可观测性记录输入、输出、延迟、token 花销、过了哪几道校验门;有界回退,让重试预算用尽时优雅降级而不是把整条流弄塌。
延迟预算需要上限,不只是下限 — 用户不关心平均,他们关心长尾。成本预算需要一份事先模型:两阶段流水线大概是一阶段的 1.5 倍,五分支 scatter-gather 是 5 到 8 倍,roundtable 是 10 倍以上。有些系统在规模化下根本不可行,因为单次交互成本超过了交互价值。在设计时做算术,不要等账单到了再做。
第 6 章接下去会怎么走
顺序和并发是积木。它们能处理大多数多 agent 用例,前提是任务拓扑在设计时已知、worker 角色固定。它们共享一个假设:设计时就有人决定了 agent 是谁、它们怎么连。编排是静态的;流水线在任何用户请求到来之前就画好了。第 7 章把这个假设拿掉。
明天 — 第 7 章:高级协作与动态模式。Roundtable、handoff 路由、magentic 编排 — 当拓扑必须按请求构建而不是按设计构建时出现的那些模式,以及更简单的模式能躲掉的那些故障(不停机、错路由、计划失控)。
