Agent 设计的反框架哲学：Anthropic 五大工作流模式深度解读

导言：当我们在谈论 Agent 时，我们到底在谈什么

过去两年，AI 行业的注意力被"Agent"这个词反复撕扯。从 LangChain 的"Chain 即一切"，到 AutoGPT 掀起的自治 Agent 狂潮，再到今天 MCP（Model Context Protocol）成为协议层的事实标准，"Agent"的概念边界一直在被反复重画。在这个背景下，Anthropic 在 2024 年末发布的《Building effective agents》一文，以其反主流的克制态度，重新定义了这片领域的最佳实践——也是 2026 年工程师构建生产级 Agent 时最值得反复重读的"反框架"宣言。

本文不打算复述那篇文章的目录结构，而是希望从一个更实战的角度回答三个问题：

1. 为什么"简单可组合的模式"在生产中击败了"复杂的智能体框架"？
2. 五种工作流模式（Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer）各自的适用边界在哪里？
3. 在 MCP 协议与 Code Mode 兴起的今天，这些模式正在如何被重新组织？

一、基座：被严重低估的"Augmented LLM"

在讨论任何工作流之前，Anthropic 给出了一个非常重要的"地基"——所谓 Agent 的最小有效单元，其实是一个已经具备检索、工具、记忆能力的 LLM。换句话说，Agent 不是"加在 LLM 上面"的某种系统，而是一个能力足够强、能主动生成检索查询、自主选择工具、自行决定保留哪些信息的 LLM。

这件事在 2026 年回顾特别有感触：当 Claude 4.5 Sonnet、GPT-5、Gemini 2.5 Pro 这一代模型已经能在单次调用里完成多步推理、自主函数调用和长期上下文管理时，很多团队仍在用 GPT-3.5 时代的"循环—观察—决策"模式封装它们，结果就是：

• 框架本身成了性能瓶颈：抽象层把 prompt、token 流和工具调用日志全部藏起来，调试时根本无法确认模型"真正看到了什么"。
• 复杂度的反噬：每一次循环都会把上一次的结果重新塞回上下文，token 成本随步数线性甚至超线性增长。
• 错误的归因错位：当 Agent 表现不佳时，团队往往归咎于"框架调度"，而忽略了底层模型本身的能力边界。

Anthropic 的建议非常明确：先用 LLM API 直写，把模式用几十行代码实现；如果一定要用框架，至少要完全理解它在底层做了什么事情。这是一句朴素但绝大多数团队都做不到的告诫。

二、五种工作流模式：复杂度阶梯的清晰分层

2.1 Prompt Chaining：最被低估的"线性流水线"

适用场景：任务可以被确定性拆解为多个顺序步骤，且每一步的输出可以作为下一步的输入。

典型案例：先让 LLM 写大纲 → 再针对每个章节生成内容 → 最后做一次风格统一性的整体润色。中间可以插入程序化断言（gate）——例如检查章节数、字数下限、敏感词清单等。

核心优势：

• 可调试性极强：每一步都是独立的 prompt + 输出，失败时可以精确定位到哪一步。
• 成本可控：可以对小步骤用便宜模型（如 Haiku），对核心步骤用旗舰模型（如 Opus 4.7），模型分层是 Prompt Chaining 的隐藏红利。
• 延迟可接受：因为是顺序执行，可以做并行预取（prefetch）部分独立输入。

反模式：把 Prompt Chaining 当成"什么都能套"的银弹。LLM 并行能力的浪费是其最大代价——如果任务可以被并行化（见 2.3），强行 Chaining 就是在烧钱。

2.2 Routing：分类器就是产品

适用场景：输入空间存在明显异质性——不同类型的输入应该走不同的处理路径。

最经典的例子是客服系统：账单问题、技术问题、投诉问题、闲聊问题应当由不同 prompt（甚至不同模型）处理。试图用一个大而全的 prompt 覆盖所有输入，必然导致每类问题的表现都打折。

Anthropic 在 Appendix 1 中给出的客服 Agent 案例值得反复研究：先用一个小模型（甚至传统分类器）做意图识别，再分发到对应的子 Agent。这种设计在生产环境里被证明比"一个超长 prompt 的超级 Agent"稳定得多。

工程经验：

• 路由分类器本身不需要 LLM：一个微调的 BERT、或者基于关键词/规则的 fallback，往往就够用。LLM 应该被留给真正需要语义理解的部分。
• 路由层是整个系统的可观测性金矿——通过观察"哪些问题被路由到哪条路径"，可以快速发现 prompt 工程的问题所在。

2.3 Parallelization：被忽视的"投票与分片"原语

LLM 调用本质上是大数定律——同一个问题问 N 次，取众数，答案的稳定性会指数级提升。Parallelization 在 Anthropic 的定义里有两种形态：

• Sectioning（分片）：把任务拆成 N 个独立子任务，并行处理后聚合。例如：让 5 个 LLM 同时总结长文档的 5 个不同章节，然后合并。
• Voting（投票）：同一个问题问 N 次，对答案做多数表决或置信度加权。例如：代码评审中的多模型投票、敏感内容审核的多模型一致性检查。

关键洞见：Voting 模式与 Orchestrator-Workers 模式截然不同——后者是有中心的任务分解，前者是去中心的多视角校验。在生产中，这两种模式经常被混用而工程师并未自觉。

2.4 Orchestrator-Workers：动态任务分解的皇冠

适用场景：任务不能预先确定子任务的数量和类型，需要由中央 LLM 在运行时决定如何拆分。

典型案例：研究型 Agent——用户问"对比 A、B、C 三家公司的 2025 年 AI 战略"，中央 LLM 决定需要查询哪些信息源、对每家公司做哪些维度的对比、如何综合呈现。如果是 Prompt Chaining，结构是写死的；如果是 Orchestrator-Workers，结构是涌现的。

代价与陷阱：

• 复合错误：每多一层委派，错误率相乘。一个 95% 正确的子 Agent，串 3 层就只有 86% 的整体正确率。
• 可观测性黑洞：动态分解意味着无法预先画静态的调用图，必须依赖trace 级别的工具（LangSmith、Langfuse、Helicone 等）才能调试。
• 成本不可预测：用户问一个问题，可能触发 3 次子任务，也可能触发 30 次。对延迟敏感的产品（实时客服、语音 Agent）慎用。

Anthropic 在 Coding Agent 案例中明确提到：Claude Code 这类自治编程 Agent 本质上是 Orchestrator-Workers + Evaluator-Optimizer 的组合（见 2.5）。但即使是 Anthropic 自己，对自治 Agent 的生产部署也持谨慎态度——需要 sandboxed 环境、需要人工审查回路、需要在成本上做严格封顶。

2.5 Evaluator-Optimizer：自反思闭环的工程化

适用场景：存在清晰可量化的评价标准，且任务质量有显著提升空间（"70 分到 90 分"比"0 分到 60 分"更容易做）。

Evaluator-Optimizer 是 Anthropic 五大模式中最少被独立讨论、但生产价值最高的一个。原因是它把"LLM 自我批评"从 Demo 阶段推到了生产阶段：

• Generator LLM 生成答案 v1
• Evaluator LLM 对 v1 打分 + 给出具体改进意见
• Generator LLM 根据意见生成 v2
• 直到 Evaluator 给出"pass"信号，或达到最大迭代次数

生产经验：

• Evaluator 必须独立：用同一种模型（甚至同一个 session）做生成和评价，会陷入自我偏见的循环。最佳实践是 Evaluator 用更严格的 prompt、不同 temperature（如 0）、最好不同模型家族（Claude 生成 + GPT 评价，或反之）。
• Evaluator 的标准必须是人写的：让 LLM 自己定义"什么是好答案"，结果就是答案在趋同但并未真正变好。人工定义的 rubric 才是 Evaluator-Optimizer 系统的真正价值锚点。
• 迭代次数 ≤ 2：超过 2 轮的 Evaluator-Optimizer 几乎总是成本 > 收益的。

三、组合与裁剪：复杂度治理才是真工程

单独看五种模式是简单的，真正的难度在于它们的组合。Anthropic 给出的几条组合经验非常实战：

1. 从简单开始，逐步升级：遇到一个需求，先用单次 LLM 调用 + 检索试试；不行就加 Prompt Chaining；再不行就 Routing；最后才是 Orchestrator-Workers。80% 的"Agent 项目"应该死在第 1 步或第 2 步。
2. Evaluator-Optimizer 是几乎所有系统的暗藏层：即便是单次 LLM 调用，也可以套一个轻量 Evaluator 做内容安全检查、敏感词过滤、品牌语气把关。把 Evaluator 视为 cross-cutting concern，比把它当作独立工作流更接近生产真相。
3. 自治 Agent 是高利贷：能不用就不用。Anthropic 自己用 Claude Code 做 Coding Agent 时，仍然保留了强人工审批回路（用户确认每一步文件写入、执行命令）。没有人工回路的自治 Agent，在生产里是事故现场而不是产品。

四、Code Mode 与 MCP：协议层如何重塑 Agent 工具调用

2026 年值得特别关注的是 Cloudflare 提出的 Code Mode 范式——它与 Anthropic 的"反框架"哲学不谋而合。

传统 MCP 工具调用的痛点：

• 工具数量爆炸后，模型要在数百个工具 schema 里"挑"出正确的几个
• 多个工具串联时，每一步的输出都要穿过神经网络的"读取—复制—输出"循环，token 浪费严重
• 工具 schema 是"为人类阅读"优化的，与 LLM 训练数据的分布不一致

Code Mode 的解法：

• 把 MCP 服务端导出的工具编译成 TypeScript API
• 让 LLM 写代码（而不是直接调工具）来完成多步操作
• 多个工具调用在 LLM 的代码生成阶段就完成，最终只有代码执行结果需要回传给 LLM

Cloudflare 公开数据显示（据其官方博客 2025 年 9 月报道），这一方法在 tokens 消耗上有数量级的下降——传统模式需要传回所有中间结果，Code Mode 只回传最终需要的数据。在涉及 5+ 工具串联的复杂任务中，Code Mode 的成本优势是压倒性的。

对五类工作流模式的影响：

• Prompt Chaining：Code Mode 让 Chaining 内部可以更激进地并发（写并行代码即可），不再受"LLM 必须串行"约束
• Orchestrator-Workers：Worker LLM 现在可以用"写代码"代替"逐个工具调用"，延迟和成本都下降
• Evaluator-Optimizer：Evaluator 可以直接读 Generator 写的代码而不是读自然语言，评价粒度更细（AST 级别、code smell 级别）

MCP 协议本身在 2025 年也快速演进：2025-06-18 的修订增加了 Tool Annotations（readOnlyHint / destructiveHint / idempotentHint）字段，让 LLM 能在调用前判断工具的危险性。这一字段让"安全护栏"从框架层下沉到了协议层——任何 MCP 客户端都能自动获得"这个工具是否会改写文件"等元信息。

五、给 2026 年 Agent 工程师的十条建议

基于以上讨论，我给正在构建生产级 LLM Agent 的团队十条具体建议：

1. 先把 prompt 调好，再考虑加框架。90% 的 Agent 失败源于 prompt 本身，而非编排。
2. 用最简单的模型 + 最多的检索作为基线，再考虑升级模型。Opus 4.7 不是 GPT-3.5 时代的"魔法增益"。
3. 记录每一次 LLM 调用的完整 prompt、输出、token 消耗。没有 trace，没有 Agent 工程。
4. 把 Evaluator 当作 cross-cutting concern，不要等到系统出问题才加。
5. 避免动态任务分解，除非你能清晰回答"为什么不用静态 Chain"的问题。
6. 人工审批回路是 Agent 的安全网，不是可选项。所有"写文件 / 调外部 API / 执行命令"的工具调用都应该有人工 gate。
7. 成本封顶：为单次任务设定 max token、max tool calls、max wall-clock time，自治 Agent 不能无限运行。
8. 模型分层：分类器用小模型，复杂推理用大模型，不要让 Opus 处理意图识别。
9. Code Mode 是复杂工具链的正确选择——不要让 LLM 手动串联 5+ 个工具调用。
10. 把"不需要 Agent"作为正当技术决策。Anthropic 在文章第一段就强调："增加复杂度时要有充分理由"。拒绝构建 Agent 是工程师专业性的体现。

总结：克制即工程

Anthropic 那篇《Building effective agents》最反直觉、也最有价值的观点，是它对"工程复杂度"的克制态度。在一个被 hype 驱动的领域，"不构建 Agent"往往比"构建 Agent"需要更多的专业判断力。

2026 年，Agent 工程的真正分水岭不在于"谁调动了多少工具"，而在于：

• 你能不能精确描述系统的行为边界？
• 你能不能预测单次任务的成本与延迟？
• 你能不能在错误发生时快速定位和回滚？
• 你能不能说"这个需求不需要 Agent"？

能回答这四个问题的团队，才能在 Agent 时代的下一个阶段生存下来。克制，是这个时代最稀缺的工程美德。

参考资料

1. Anthropic Engineering. Building effective agents. 2024-12-19. https://www.anthropic.com/engineering/building-effective-agents
2. Cloudflare Blog. Code Mode: the better way to use MCP. 2025-09. https://blog.cloudflare.com/code-mode/
3. Model Context Protocol Specification. 2025-11-25 revision. https://modelcontextprotocol.io/specification/2025-11-25
4. Simon Willison's Weblog. Tags: MCP. https://simonwillison.net/tags/mcp/
5. Anthropic. Introducing Skills for Claude. 2025-10. https://www.anthropic.com/news/skills
6. LangChain Documentation. Orchestrator-Workers pattern. https://python.langchain.com/docs/concepts/architecture/#orchestrator-workers