Claude 设计 - Agent 构建模式

Anthropic 官方总结的五种 workflow 加一种 autonomous agent，怎么对应到 Claude Code。

Anthropic 工程团队在 2024 年底发过一篇"Building effective agents"，把过去一年跟几十个团队合作做 agent 的经验凝练成一套非常朴素的建议：先分清 workflow 和 agent，从最简单的模式开始，只有明确必要时才升级复杂度。这一节把那套模式讲清楚，并且逐条对应到 Claude Code 里可以怎么实现。

Agent 和 Workflow 不是同一件事

先划清一条边界：Anthropic 把所有"LLM + 工具"的系统统称为 agentic systems，但内部分成两类。

Workflow：LLM 和工具的调用顺序由预定义的代码路径编排。分支、并行、循环全部写死在你自己的代码里，模型只在每个节点上做一件小事。
Agent：LLM 自己决定下一步做什么、用哪个工具、什么时候停。控制流本身是模型的输出。

工作流可预测、便于测试、成本可控。Agent 灵活、能应对未知，但延迟高、成本高、错误会累积。官方原话是"先找最简单的方案，只有明显需要时才增加复杂度"。很多任务不需要 agent，甚至不需要 workflow，一个带 retrieval 的单次调用就够。

     input ──▶ [ LLM + tool ] ──▶ output      单次调用
     input ──▶ 预定义编排的多次调用 ──▶ output  workflow
     input ──▶ LLM 自己决定循环几次 ──▶ output  agent

基础构件：Augmented LLM

所有模式的原子单位都是同一个东西：一个带增强能力的 LLM。增强能力有三种：

Retrieval：能查外部知识
Tools：能调工具，例如读文件、跑命令、访问 API
Memory：能保留状态

Claude Code 本身就是一个已经装配好的 augmented LLM：文件系统工具、bash、MCP 接的外部服务、subagent 组成了它的能力池。你写 workflow 或 agent 的时候，每个"节点"其实都是一次带工具的 Claude 调用。

五种 Workflow 模式

1. Prompt chaining 串行分步

一个任务拆成固定的几步，前一步的输出喂给下一步。中间可以插一个"gate"，也就是程序化检查，不合格就打回。

input ─▶ step1 ─▶ [gate] ─▶ step2 ─▶ step3 ─▶ output

什么时候用：任务能干净地拆成几个固定子步骤，你愿意牺牲一点延迟换更高的准确率。典型例子：先起草文档大纲，验一下大纲，再基于大纲写正文。

Claude Code 里怎么落：最直接的实现就是 explore → plan → implement 三段式。或者写一个 slash command，串起"先跑 lint、再让 Claude 修、再跑 test 验"几步，每步的输出决定下一步的 prompt。

2. Routing 分类分派

先分类，再把不同类的输入丢给不同的下游 prompt 或者不同的模型。

input ─▶ classifier ─▶ ┬─▶ 处理 A（专用 prompt）
                       ├─▶ 处理 B（专用 prompt）
                       └─▶ 处理 C（更强的模型）

什么时候用：任务里有明显不同的类别，不同类别用不同 prompt 会显著更好；或者要按难度做成本优化（简单问题走 Haiku、疑难走 Sonnet 或 Opus）。

Claude Code 里怎么落：可以在自定义 skill 里做一个入口 prompt，先分类 issue（bug / feature / question），再 dispatch 到不同的下游 skill。或者主 agent 只做分派，具体任务派给不同类型的 subagent 处理。

3. Parallelization 并行拆分

同一个任务并行地做多次，然后聚合。两种变体：

Sectioning：把任务分成独立的子块并行做，最后拼起来
Voting：同一个问题多次问，取多数或按阈值决定

              ┌─▶ worker A ─┐
input ─▶ 分片 ┼─▶ worker B ─┼─▶ 聚合 ─▶ output
              └─▶ worker C ─┘

什么时候用：子块之间彼此独立，能真并行加速；或者需要多角度判断提高可信度，例如安全审查从注入、认证、密钥等不同角度分别看。

Claude Code 里怎么落：一次消息里同时发多个 Agent 工具调用，几个 subagent 并行跑独立的调研任务，主 loop 只等它们返回结果再合并。Claude Code 的官方指导专门强调过"独立子任务在一条消息里同发"这个技巧。

4. Orchestrator-workers 中央协调 + worker

跟并行相似，但子任务不是预定义的，而是由一个中央 LLM 动态决定要拆几块、每块干什么。worker 干完，orchestrator 汇总。

input ─▶ orchestrator ─┬─▶ worker（动态数量、动态任务）
                       └─▶ ...
        ▲              │
        └─── 汇总 ◀────┘

什么时候用：子任务的数量和内容依赖具体输入，事先没法枚举。典型例子：改一个跨文件的功能，哪些文件要改、每个文件改什么，是看了代码才知道的。

Claude Code 里怎么落：这个模式几乎就是 Claude Code 主 loop 本身的默认玩法。主 agent 决定要读哪些文件、要派几个 subagent 去调研、最后自己合成。你写 skill 的时候如果里面用了 context: fork 或多个 Task 调用，走的就是这个模式。

5. Evaluator-optimizer 评审加迭代

一个 LLM 出结果，另一个 LLM 评审并给反馈，出结果的那个再改，循环直到评审通过。

input ─▶ generator ─▶ output ─▶ evaluator ─▶ 反馈
                     ▲                       │
                     └────── 改进 ◀──────────┘

什么时候用：有清晰的评判标准，且人类能用文字表达反馈的时候。文学翻译、复杂检索、需要打磨的写作都是这个模式的好场景。

Claude Code 里怎么落：/goal 命令天然是 evaluator-optimizer 的一半，它派一个独立的 evaluator subagent 在每一轮之后重新校验目标，不通过就让主 agent 继续干。Stop hook 则是它的确定性版本：脚本判定不通过就直接卡住 turn。第三种实现是官方博客里点名的"adversarial review"，也就是让一个 subagent 用全新上下文重新评审主 agent 的结果，避免出结果的人自己给自己打分。

什么时候用 Autonomous Agent

前面五种都是 workflow，控制流预定义。真正意义上的 agent 是把控制流交还给模型：模型自己看环境反馈、自己决定下一步、自己决定什么时候停。

                ┌──▶ 思考 ──▶ 调工具 ──▶ 观察结果 ──┐
     input ─────┘                                    │
                ▲                                    │
                └───────── 判断继续还是停 ◀──────────┘

官方明确指出 agent 只在两类问题上真正合适：

开放式问题，没法预先枚举步骤，例如"修 SWE-bench 里这个 issue"，涉及几个文件、要不要跑测试、要不要看 issue 讨论，全依赖临场判断
环境能给"ground truth"反馈，例如测试通过 / 失败、代码能不能编译、命令有没有报错，agent 才能从错误里自我修正

对应的代价必须接受：更高的延迟、更高的 token 成本、错误会累积。所以官方的原话很重：充分沙盒测试、加护栏、设停止条件（例如最大轮次上限）。

Claude Code 里，普通对话本身就是一个 autonomous agent 循环。你说一句话，它自己决定读文件、调 bash、开 subagent，直到它认为完事。真正把这套能力放大的两个开关是：claude --permission-mode auto -p "fix all lint errors" 这种批量非交互模式，加上沙盒（/sandbox 或系统级 sandboxing）保证它跑飞了不出圈。

"先从简单开始"不是废话

Anthropic 这套文档反复讲同一句话：不要一上来就搭 orchestrator + evaluator + 十个 worker，先看单次 augmented LLM 调用能不能解决。Claude Code 的组件也是按这个顺序设计的：

模式	Claude Code 对应实现
单次调用	一次普通对话
Prompt chaining	一个多步 skill / slash 命令
Routing	分派型 skill 或多类型 subagent
Parallelization	一条消息里同发多个 Task
Orchestrator-workers	主 loop 自然行为、`context: fork` skill
Evaluator-optimizer	`/goal`、Stop hook、adversarial review subagent
Autonomous agent	`--permission-mode auto` 长任务

配套三条原则原样搬过来：

Simplicity：能少一层就少一层，能不加 orchestration 就不加
Transparency：显式暴露 agent 的推理过程（/plan、显式思考、subagent 报告）
Agent-Computer Interface (ACI)：工具的定义、参数命名、错误提示都要像给初级同事写文档一样仔细，MCP server 和自定义工具尤其吃这一条

一句话总结

Anthropic 官方对 agent 的建议其实反直觉地保守：绝大多数场景不需要 agent，一个 workflow 就够；绝大多数 workflow 不需要 orchestrator，一次 prompt chaining 就够。Claude Code 把这些模式的实现都放好了，你要做的只是选对层级。

参考来源

https://www.anthropic.com/engineering/building-effective-agents Anthropic 工程博客原文，五种 workflow 模式和 agent 边界定义的原始出处
https://www.anthropic.com/engineering/claude-code-best-practices Claude Code 最佳实践，/goal、adversarial review、--permission-mode auto 等落地机制的官方描述
https://docs.claude.com/en/docs/claude-code/slash-commands Claude Code slash 命令与 skill 的完整参考，包含 context: fork、agent 字段等 orchestrator-worker 相关配置
https://docs.claude.com/en/docs/build-with-claude/overview Claude 平台能力总览，augmented LLM 的三种增强（retrieval / tools / memory）来源

Claude 设计 - Agent 构建模式 ​

Agent 和 Workflow 不是同一件事 ​

基础构件：Augmented LLM ​

五种 Workflow 模式 ​

1. Prompt chaining 串行分步 ​

2. Routing 分类分派 ​

3. Parallelization 并行拆分 ​

4. Orchestrator-workers 中央协调 + worker ​

5. Evaluator-optimizer 评审加迭代 ​

什么时候用 Autonomous Agent ​

"先从简单开始"不是废话 ​

一句话总结 ​

参考来源 ​