#ai #Agent
本页目录

多 Agent 编排

单个 agent 撞上上下文膨胀、串行、杂而不精三道墙。多 agent 编排把工作拆给协作的 agent——从确定性编排(chaining/routing)到 agentic 编排(orchestrator-workers),核心收益是上下文隔离和并行。

概述

单个 agent(Agent 循环)什么都自己干,会撞上三道墙:⁠上下文膨胀⁠(一个窗口塞下全部工作,中段信息被稀释)、⁠串行⁠(只能一步步来,慢)、⁠杂而不精⁠(同一个 system prompt 兼顾探索、规划、执行、审查,哪样都不极致)。多 agent 编排就是把工作拆给多个协作的 agent 来突破这三道墙。

但先泼冷水:⁠多数任务不需要多 agent。 单 agent + 一组好工具能解决的就别上多体——多体引入协调开销、上下文同步成本、和调试复杂度。先确认收益(判据同 Agent 循环 的 "workflow vs agent" 四关:复杂度/价值/可行性/错误代价),再动手。这一篇讲清:有哪些编排模式、它们各自解决什么、以及在 Claude 生态里怎么落地、会怎么翻车。

从确定性编排到 agentic 编排

Anthropic 的 "Building Effective Agents" 把多体模式从简到繁排开。⁠关键区分⁠:前几种是代码控制的确定性编排(workflow)——步骤与分支由代码写死,只是每步调一次模型;最后一种(orchestrator-workers)才是模型自己动态拆活的"agent"式多体。

模式形态控制方用在
prompt chainingA 的输出喂 B,串成流水线代码可拆成固定步骤
routing先分类,再分发到专门处理代码输入种类多、各有专门处理
parallelization同时跑多路,汇总(分片 or 多视角投票)代码可并行子任务 / 需多视角
orchestrator-workers协调者动态拆任务给 worker模型子任务数量/形态不预先确定
evaluator-optimizer一个生成、一个评审,循环改进代码+模型有明确质量标准、值得迭代

先用确定性编排。 如果任务能用 chaining/routing 写死,就别上 orchestrator-workers——确定性更可控、可缓存、可调试。只有当"要拆成几个子任务、各是什么"无法预先写死时,才需要让模型当协调者。

orchestrator-workers:agentic 多体的核心

flowchart TD
    O["Orchestrator<br/>读懂目标 → 动态拆解 → 调度 → 汇总"]
    O -->|子任务 A + 所需上下文| W1["Worker A<br/>独立窗口"]
    O -->|子任务 B + 所需上下文| W2["Worker B<br/>独立窗口"]
    O -->|子任务 C + 所需上下文| W3["Worker C<br/>独立窗口"]
    W1 -->|结果摘要| O
    W2 -->|结果摘要| O
    W3 -->|结果摘要| O
    O --> R["综合产出"]

它为什么有用,三个机制层面的理由:

  • 上下文隔离⁠:每个 worker 用自己的窗口处理子任务,只把结果摘要回传 orchestrator。主上下文不被二十个文件的原始内容淹没——直接对应 上下文工程 的"别撑爆窗口、别让中段被稀释"。这是多体相对"单 agent 读一切"的最大收益。
  • 并行 fan-out:独立子任务同时跑,墙钟时间从"串行之和"降到"最慢的一个"。
  • 省钱(且不毁缓存):子任务可以用更便宜的模型跑。但有个 prompt 缓存 的硬约束:⁠在同一个循环里中途换模型会作废整段缓存⁠(缓存按模型分桶)。正确做法是另起 subagent 用便宜模型⁠,主循环保持单模型不变——这样主循环的缓存不破,子任务又省钱。Claude Code 的 Explore subagent 用更便宜的模型(如 Haiku)做只读扇出搜索,就是这个模式。

Claude 生态里的落地

  • Claude Code:Explore / subagent——把广度搜索、独立子任务派给子 agent(常用更便宜模型),结果摘要回主 agent;主 agent 的上下文与缓存不受污染。
  • OMC(oh-my-claudecode):在 Claude Code 之上做显式 team 编排⁠,把探索/规划/执行/审查拆给专门 agent,并坚持一条原则——⁠编写与审查分两条 lane:执行的 agent 不自审,另起 reviewer/verifier 在独立上下文里评。
  • Managed Agents multiagent(托管):在 agent 上声明 multiagent: {type: "coordinator", agents: [...]} 一个可委派名册;运行时每个被委派的子 agent 跑在自己的 thread——上下文隔离的事件流,有独立的模型/系统提示/工具/技能⁠。机制细节:
    • 共享容器与文件系统,⁠但不共享对话历史⁠;
    • 名册 1–20 个 agent,可生成同一 agent 的多个副本,最多 25 个并发 thread;
    • 只支持一层委派⁠(子 agent 的名册不级联);
    • 跨线程通过 agent.thread_message_sent/received 通信,工具确认等会回送到主线程处理。

最佳实践

  • 多数任务不需要多 agent。 单 agent + 一组好工具能解决就别上多体;先过复杂度/价值/可行性/错误代价四关。
  • 先确定性编排,后动态协调。 能用 chaining/routing 写死就别上 orchestrator-workers——更可控、可缓存、可调试。
  • 靠上下文隔离拿收益。 每个 worker 用自己的窗口,只回传结果摘要⁠,主上下文不被原始内容淹没。
  • 省钱另起 subagent,别在主循环换模型。 换模型作废整段缓存;Claude Code 的 Explore 用便宜模型做只读扇出就是这个模式。
  • orchestrator 把所需上下文显式写进委派消息。 线程间不共享历史/工具,worker"不知前因",要么写进消息要么落共享文件。
  • 编写与审查分两条 lane。 执行 agent 不自审,另起 reviewer/verifier 在独立上下文评(见 评估与可观测)。

权衡与失败模式(附修法)

  • 过度委派⁠:一个 grep/read 就能解决也开子 agent → 给明确指引:"只有并行或独立工作流才委派;单文件读、顺序操作直接做。"
  • 协调开销 > 收益⁠:层级太深、来回太多,比单 agent 还慢还贵 → 控制委派深度(Managed Agents 干脆只允许一层);能确定性编排的别上动态协调。
  • 上下文不共享的陷阱⁠:线程间不共享历史/工具,worker"不知道前因" → orchestrator 必须把所需上下文显式写进委派消息⁠,或落到共享文件,再让 worker 读。
  • 换模型毁缓存⁠:为省钱在主循环里切模型,结果缓存全废、反而更贵 → 用 subagent 隔离便宜模型,主循环不切。
  • 自审背书⁠:执行 agent 自评自己的工作 → 评审另起 lane(见 OMC 实践、评估与可观测)。

参考

  • Anthropic 官方文档⁠: "Building Effective Agents"、Managed Agents Multi-Agent(platform.claude.com)

Keywords: multi-agent, orchestration, prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer, subagent, Explore, 上下文隔离, fan-out, prompt cache 不变量, model switch invalidation, Managed Agents multiagent, coordinator, threads, 跨线程消息, 一层委派, OMC team, authoring vs review lane

相关页面

© 2026 liz's doc