多 Agent 图式工作流：从单循环到可控协作
多 Agent 图式工作流：从单循环到可控协作
适合谁： 已经在用 LLM + 工具循环，但开始遇到上下文膨胀、任务串扰、返工难定位问题的开发者与团队。
先说结论： 多 Agent 的价值不在于“多开几个模型”，而在于把任务拆成可观察的状态、明确的分工、可验证的边界。如果任务仍能被一个清晰的流程完成，就不要为了架构感而上图。
很多 Agent 最初都长这样：收到任务，调用模型，必要时调工具，再把结果塞回下一轮上下文。它能快速交付原型，也适合边界清楚的小任务。
问题出现在一个循环同时承担研究、规划、执行、审查与汇总时：错误会沿着上下文继续传递；每轮都带着无关历史；出了问题也很难判断是检索、推理、工具还是验收出了错。
这时需要的不是把循环跑得更久，而是把它改造成一个可控的任务图。
先判断：单循环还够不够
不要把“多 Agent”当成默认答案。先给现有任务贴标签：
| 任务特征 | 更合适的起点 | 不必急着拆分的原因 |
|---|---|---|
| 单一目标、固定步骤、结果可直接验收 | 单次调用或单循环 | 增加节点只会增加协调成本 |
| 固定的多步转换 | 串行链 + 每步检查 | 路径已知，不需要动态调度 |
| 输入类别不同、处理方式不同 | 路由 | 先分类，再交给专长路径 |
| 多个子问题彼此独立 | 并行 fan-out | 可缩短总耗时，也能保留各自证据 |
| 子任务数量或类型事前未知 | 编排器—执行器 | 由主控根据任务实时拆解 |
| 输出能被明确标准反复改进 | 生成器—评估器闭环 | 让评估反馈成为下一轮的输入 |
| 涉及生产发布、权限、支付或删除 | 人工审批门 | 不可逆动作不能只靠模型判断 |
一个实用原则是：先能画出失败路径，再决定是否增加节点。 如果说不清“哪个节点失败后该做什么”，图只会把复杂性藏起来。
图式工作流的四个骨架
无论选哪种框架，先把下面四件事写清楚；它们比模型名更决定系统能否维护。
1. 节点：只承担一种可验收职责
一个节点可以是模型调用、搜索、代码执行、数据库查询或人工操作。但它应有单一目标，例如“提取事实候选”“按规则分类”“执行测试”“生成发布草稿”。
不要让一个节点同时研究、写作、审稿和上线。职责混合时，失败原因会消失在一大段自然语言里。
2. 状态：用结构化数据传递，不靠聊天记录猜测
状态是任务图的共享工作台。每个节点只读取自己需要的字段，并写回可检查的结果。开始时不需要复杂的状态机，一个 JSON 对象已经足够：
state = {
"task": task,
"facts": [],
"draft": None,
"checks": [],
"status": "running",
"attempts": 0,
}
关键不是字段多，而是给重要字段定义来源和所有者：谁能写入、谁负责验证、何时失效。比如事实记录要带来源 URL；测试结果要来自真实命令输出；批准状态只能由人工节点写入。
3. 边：把正常、失败与停止都写成路径
节点之间的连线不能只有“成功后继续”。至少定义三类出口：
- 继续： 输出满足下游输入契约；
- 回退： 缺少证据、工具失败或质量不达标，回到哪个节点补什么；
- 停止： 达到最大尝试次数、预算、时间上限，或等待人工判断。
没有停止条件的自我修正循环，最后常常只是更昂贵的重复。
4. 闸门：把不可逆决策从模型循环中拿出来
模型可以整理“准备发布什么、影响谁、验证是否通过”，但真正的发布、权限变更、付款和删除，应在明确的审批节点暂停。
好闸门展示的是具体行动，而不是抽象问题：变更内容、目标环境、验证结果、风险与回滚方式。这样人工审批才是判断，而不是替系统猜测。
五种最常用的图式模式
模式一：串行链——路径固定时最省心
把固定流程拆成窄步骤：提纲 → 草稿 → 事实检查 → 格式化。每一步的输出都先过程序化或人工定义的检查，再交给下一步。
适合转换、资料整理、固定格式报告等任务。它的风险是上游错误逐步放大，所以要把检查靠近错误发生处，而不是只在最后做一次“看起来对不对”。
模式二：路由——先分类，再匹配工具和提示
当输入类型不同，先用轻量规则、分类器或模型把任务送到正确路径。例如把工单分为产品咨询、故障与退款；把研究请求分为公开资料检索、代码分析与内部数据核验。
路由节点应输出可审计的类别与理由。路由错了并不可怕；可怕的是所有任务都带着全部工具和全部提示一路向下，直到在不相关的能力上误操作。
模式三：并行 fan-out——只并行真正独立的工作
多个来源检索、多个模块测试、多个竞品对比，适合并行。每条支线应拥有自己的输入快照与输出格式，最后由一个汇总节点负责去重、处理冲突和标注证据强弱。
不要把相互依赖的步骤硬拆成并行。后一个节点必须依赖前一个结论时，伪并行通常只会制造竞态与重复调用。
模式四：编排器—执行器——任务结构未知时再使用
复杂改造、开放式研究等任务，往往无法事先列出完整子任务。此时可以让一个主控节点先提出工作拆分，再把独立项交给执行器，最后回收结果并决定是否继续。
这里的控制点是预算和范围：限制同时运行数量、单项最大轮次与允许调用的工具。主控节点不应拥有无边界的递归委派权。
模式五：评估器闭环——只有标准明确时才值得重试
生成器产出结果，评估器依据明确标准给出通过或具体修改项；未通过时将反馈写回状态，生成器再尝试一次。
它适合有可观察质量标准的任务，例如测试失败的代码修复、字段齐全的结构化抽取、已定义风格的文稿。若评估标准只是“更好一些”，循环会变成主观消耗；此时应改为人工审阅或先补评价标准。
一个最小可控架构
从单循环升级时，不必一开始就引入复杂框架。先实现一个能运行、能观测、能停下的骨架：
def run_task(task):
state = initialize(task)
state = classify(state)
state = dispatch_to_specialist(state)
state = verify_with_real_evidence(state)
if state["status"] == "needs_human_approval":
return await_human_decision(state)
if state["status"] == "retryable" and state["attempts"] < 2:
return run_retry(state)
return finalize(state)
这段结构刻意没有绑定 Claude、某个框架或特定模型。先用最少的代码把状态、验证、重试和人工门定义出来；当你确实需要可视化、持久化、并发调度或恢复执行时，再引入对应框架。
上线前的六项检查
- 每个节点有输入与输出契约。 下游不应靠解析一段随意的自然语言来猜字段。
- 关键结论来自环境证据。 工具调用结果、测试输出和一手文档应进入状态，而不是只留在模型叙述中。
- 并行分支彼此独立。 否则改用串行或显式依赖图。
- 重试有上限。 同时限制次数、时间和预算，并记录最后失败原因。
- 高风险动作有人工门。 发布、删除、权限与付费不能被“任务完成”自动触发。
- 能回放一次失败。 至少保留输入快照、关键状态变更、工具结果与最终决策。
不该照搬的地方
- 不要因为“多 Agent”听起来高级，就把一个三步任务拆成五个模型调用。
- 不要让同一个模型既生成又无限制地批准自己；需要评审时，给它独立的标准与失败出口。
- 不要把上下文窗口当作数据库。可复用事实、权限状态、预算与审批应落在结构化状态中。
- 不要把自动化等同于取消人工判断。系统越接近生产影响，越需要明确的暂停点。
来源与边界
本文是基于公开原文与 Anthropic 官方模式说明写成的中文原创实战总结，不是原文翻译，也不代表 Anthropic 或原作者的官方立场。框架、模型能力与成本会持续变化；落地前请用自己的任务集、预算与安全边界验证。