这是 Anthropic 迄今为止被引用最多、传播最广的一篇技术文章。由 Erik S. 和 Barry Zhang 撰写，发布于 2024 年 12 月，至今仍被视为 AI Agent 工程实践的入门必读和架构选型参考。
文章的核心观点非常明确：最成功的 Agent 实现，不是用了最复杂的框架或最花哨的库，而是用了最简单、可组合的模式。
Anthropic 在过去一年中与数十个团队合作，跨行业构建 LLM Agent。他们从这些实践中提炼出了一套完整的构建方法论——从最基础的增强型 LLM，到五种 Workflow 模式，再到自主 Agent，层层递进。
"Agent"这个词在不同语境下含义不同。有人把它定义为完全自主的系统，能独立运行数小时、调用各种工具完成复杂任务；有人用来描述更受约束的、遵循预定义流程的实现。
Anthropic 把所有这些变体统称为 Agentic Systems，但做了一个关键的架构区分：
这个区分非常重要——它决定了系统的可预测性、调试难度和成本结构。
文章最重要的建议之一：从最简单的方案开始，只在必要时增加复杂度。
这意味着很多时候你根本不需要构建 Agentic System。对很多应用来说，优化单次 LLM 调用——加上检索增强（RAG）和上下文示例——就已经足够了。
Agentic System 的代价是什么？用延迟和成本换取更好的任务表现。 你需要认真评估这个 tradeoff 什么时候合理。
Anthropic 提到了几个可用的框架——Claude Agent SDK、Strands Agents SDK、Rivet、Vellum——但给出了一个非常务实的建议：
开发者应该从直接使用 LLM API 开始：很多模式只需要几行代码就能实现。
框架的问题在于它们创造了额外的抽象层，可能遮蔽底层的 Prompt 和 Response，让调试变得更困难。框架还会诱惑你添加不必要的复杂度——当一个更简单的设置就够用的时候。
如果确实使用框架，确保你理解底层代码。对底层机制的错误假设，是客户错误最常见的来源。
所有 Agentic System 的基础构件是增强型 LLM——一个被赋予了三种增强能力的 LLM：
关键的实现建议是：把这些能力适配到你的特定用例，并确保为 LLM 提供清晰、文档完善的接口。MCP（Model Context Protocol）是实现这一目标的一种方式。
将一个任务分解为一系列顺序步骤，每个 LLM 调用处理上一步的输出。可以在中间步骤加入程序化检查（Gate），确保流程仍在正轨上。
适用场景：任务可以清晰、干净地分解为固定子任务。目标是用延迟换精度——让每次 LLM 调用处理更简单的任务。
典型用例：
- 先生成营销文案，再翻译成另一种语言
- 先写文档大纲，检查大纲是否符合标准，再基于大纲写完整文档
关键洞察：Prompt Chaining 的价值在于每次调用都是一个更简单的任务，模型在单一聚焦的任务上表现更好。
对输入进行分类，然后导向专门化的后续任务。本质上是"先判断是什么，再决定怎么做"。
适用场景：复杂任务有明确的分类，不同类别需要不同处理方式，且分类可以被准确完成。
典型用例：
- 客服系统将"一般咨询""退款请求""技术支持"路由到不同的下游流程和工具
- 简单问题路由到小模型（如 Claude Haiku）降低成本，复杂问题路由到大模型（如 Claude Sonnet）保证质量
关键洞察：没有 Routing，为一种输入优化可能会损害其他输入的表现。Routing 实现了关注点分离。
多个 LLM 同时工作，结果通过程序化合并。有两个关键变体：
适用场景：子任务可以并行以提速，或需要多个视角以提高置信度。
典型用例：
- Sectioning：一个模型处理用户请求，另一个同时做内容安全审查——比让同一个模型同时做两件事效果更好
- Voting：多个 Prompt 分别审查代码漏洞，或评估内容是否不当，通过投票平衡误报和漏报
关键洞察：对于复杂任务中的多重考量，让每个考量由独立的 LLM 调用处理，模型能给予每个方面更集中的注意力。
一个中央 LLM（Orchestrator）动态地拆解任务、分派给 Worker LLM、然后综合结果。
与 Parallelization 的关键区别：Parallelization 的子任务是预定义的；Orchestrator-Workers 的子任务是由编排者根据输入动态确定的。
适用场景：无法预先预测需要哪些子任务。
典型用例：
- 编码产品需要对多个文件进行复杂修改，每次任务涉及的文件和修改性质都不同
- 搜索任务需要从多个来源收集和分析信息，每个任务的来源组合不同
一个 LLM 生成响应，另一个提供评估和反馈，形成循环，不断迭代改进。
适用场景：有明确的评估标准，且迭代改进能提供可衡量的价值。两个信号表明这个模式适合：人类反馈可以明显改善 LLM 输出；LLM 自身能够提供有效反馈。
典型用例：
- 文学翻译：翻译 LLM 可能无法一次性捕捉所有细微差别，但评估 LLM 可以提供有用的批评
- 复杂搜索：需要多轮搜索和分析才能收集全面信息，评估者决定是否需要进一步搜索
本质类比：就像人类作者写一份精炼文档的过程——初稿、审阅、修改、再审阅。
Agent 可以处理复杂任务，但实现往往出人意料的简单——本质上就是 LLM 在一个循环中，基于环境反馈使用工具。
适用场景：开放式问题，无法预测需要的步骤数，不能硬编码固定路径。LLM 可能运行多个回合，你必须对它的决策能力有一定信任。
代价：自主性意味着更高的成本，以及错误复合的可能。建议在沙箱环境中充分测试，并设置适当的 Guardrails。
实际案例：
- 编码 Agent 解决 SWE-bench 任务：基于任务描述自动编辑多个文件
- Computer Use Agent：Claude 使用计算机完成任务
客服 Agent：天然适合 Agent 化——交互遵循对话流程，同时需要访问外部信息和执行操作（查客户数据、订单历史、知识库，发退款、更新工单），成功标准明确（用户问题是否解决）。已有公司采用按解决量收费的商业模式，证明对 Agent 有效性的信心。
编码 Agent：代码方案可以通过自动化测试验证；Agent 可以用测试结果作为反馈迭代改进；问题空间定义清晰且结构化；输出质量可以客观衡量。但自动化测试验证的是功能性，人类审查仍然是确保方案与更广泛系统需求一致的关键。
Anthropic 总结了构建 Agent 的三个核心原则：
1. 保持简单。 不要追求最复杂的系统，追求最适合你需求的系统。从简单 Prompt 开始，用全面的评估优化它，只在简单方案不够时才添加多步 Agentic System。
2. 优先透明。 明确展示 Agent 的规划步骤。让用户和开发者能看到 Agent 在想什么、为什么这样决策。黑盒 Agent 难以调试，也难以赢得信任。
3. 精心设计 ACI。 Agent-Computer Interface（Agent-计算机接口）的工具文档和测试，值得和 Prompt 一样多的工程投入。
文章最有实践指导意义的部分是 Appendix 2——工具提示工程。
Anthropic 明确指出：不管构建哪种 Agentic System，工具都是重要组成部分。工具定义和规格应该获得和整体 Prompt 同等的提示工程关注度。
在构建 SWE-bench Agent 时，Anthropic 花在优化工具上的时间比优化整体 Prompt 还多。一个具体案例：模型在使用相对路径时，一旦 Agent 移出根目录就会出错。解决方案是修改工具，始终要求绝对路径——结果模型完美地使用了这种方式。
这篇文章表面讲架构模式，更深层传递的是一个工程哲学：Agent 工程的核心挑战不是模型能力，而是工程判断力。
知道什么时候不用 Agent 比知道怎么用 Agent 更重要。知道什么时候用 Workflow 而不是 Agent 比追求全自主更重要。知道怎么设计一个好用的工具比写一个复杂的编排框架更重要。
五种 Workflow 模式和自主 Agent 不是互相排斥的选项，而是一个渐进的光谱——从最简单的 Prompt Chaining 到最自治的 Agent Loop，开发者应该根据任务特性在这个光谱上找到最合适的位置。
成功的 Agent 系统不是最复杂的系统，而是复杂度恰好匹配需求的系统。
原文地址：Building Effective Agents
作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。