当前位置：首页 > news >正文

Anthropic 经典指南：如何构建有效的 AI Agent——从简单模式到自主系统

news 2026/6/16 22:21:18

Anthropic 经典指南：如何构建有效的 AI Agent——从简单模式到自主系统

这是 Anthropic 迄今为止被引用最多、传播最广的一篇技术文章。由 Erik S. 和 Barry Zhang 撰写，发布于 2024 年 12 月，至今仍被视为 AI Agent 工程实践的入门必读和架构选型参考。

文章的核心观点非常明确：最成功的 Agent 实现，不是用了最复杂的框架或最花哨的库，而是用了最简单、可组合的模式。

Anthropic 在过去一年中与数十个团队合作，跨行业构建 LLM Agent。他们从这些实践中提炼出了一套完整的构建方法论——从最基础的增强型 LLM，到五种 Workflow 模式，再到自主 Agent，层层递进。

本文大纲

Agent 是什么：Workflow 与 Agent 的区分
什么时候该用 Agent，什么时候不该
基础构件：Augmented LLM
五种 Workflow 模式
自主 Agent：什么时候真正需要自治
三大核心原则
ACI 设计：像重视 HCI 一样重视 Agent-Computer Interface

Agent 是什么

"Agent"这个词在不同语境下含义不同。有人把它定义为完全自主的系统，能独立运行数小时、调用各种工具完成复杂任务；有人用来描述更受约束的、遵循预定义流程的实现。

Anthropic 把所有这些变体统称为 Agentic Systems，但做了一个关键的架构区分：

Workflows（工作流）：LLM 和工具通过预定义的代码路径进行编排。执行路径是确定的，由开发者设计。
Agents（自主代理）：LLM 动态地控制自己的执行过程和工具使用，自主决定如何完成任务。执行路径是不确定的，由模型决策。

这个区分非常重要——它决定了系统的可预测性、调试难度和成本结构。

什么时候该用 Agent，什么时候不该

文章最重要的建议之一：从最简单的方案开始，只在必要时增加复杂度。

这意味着很多时候你根本不需要构建 Agentic System。对很多应用来说，优化单次 LLM 调用——加上检索增强（RAG）和上下文示例——就已经足够了。

Agentic System 的代价是什么？用延迟和成本换取更好的任务表现。 你需要认真评估这个 tradeoff 什么时候合理。

Workflow 适合：任务定义明确、需要可预测性和一致性的场景
Agent 适合：需要灵活性、模型驱动决策、且需要大规模处理的场景

关于框架

Anthropic 提到了几个可用的框架——Claude Agent SDK、Strands Agents SDK、Rivet、Vellum——但给出了一个非常务实的建议：

开发者应该从直接使用 LLM API 开始：很多模式只需要几行代码就能实现。

框架的问题在于它们创造了额外的抽象层，可能遮蔽底层的 Prompt 和 Response，让调试变得更困难。框架还会诱惑你添加不必要的复杂度——当一个更简单的设置就够用的时候。

如果确实使用框架，确保你理解底层代码。对底层机制的错误假设，是客户错误最常见的来源。

基础构件：Augmented LLM

所有 Agentic System 的基础构件是增强型 LLM——一个被赋予了三种增强能力的 LLM：

Retrieval（检索）：能够自主生成搜索查询，从外部知识库获取相关信息
Tools（工具）：能够选择合适的工具，与外部服务和 API 交互
Memory（记忆）：能够决定保留什么信息，维护跨会话的上下文

关键的实现建议是：把这些能力适配到你的特定用例，并确保为 LLM 提供清晰、文档完善的接口。MCP（Model Context Protocol）是实现这一目标的一种方式。

五种 Workflow 模式

1. Prompt Chaining（提示链）

将一个任务分解为一系列顺序步骤，每个 LLM 调用处理上一步的输出。可以在中间步骤加入程序化检查（Gate），确保流程仍在正轨上。

适用场景：任务可以清晰、干净地分解为固定子任务。目标是用延迟换精度——让每次 LLM 调用处理更简单的任务。

典型用例：
- 先生成营销文案，再翻译成另一种语言
- 先写文档大纲，检查大纲是否符合标准，再基于大纲写完整文档

关键洞察：Prompt Chaining 的价值在于每次调用都是一个更简单的任务，模型在单一聚焦的任务上表现更好。

2. Routing（路由）

对输入进行分类，然后导向专门化的后续任务。本质上是"先判断是什么，再决定怎么做"。

适用场景：复杂任务有明确的分类，不同类别需要不同处理方式，且分类可以被准确完成。

典型用例：
- 客服系统将"一般咨询""退款请求""技术支持"路由到不同的下游流程和工具
- 简单问题路由到小模型（如 Claude Haiku）降低成本，复杂问题路由到大模型（如 Claude Sonnet）保证质量

关键洞察：没有 Routing，为一种输入优化可能会损害其他输入的表现。Routing 实现了关注点分离。

3. Parallelization（并行化）

多个 LLM 同时工作，结果通过程序化合并。有两个关键变体：

Sectioning（分段）：把任务拆成独立子任务，并行执行
Voting（投票）：对同一任务多次执行，获取多样化输出

适用场景：子任务可以并行以提速，或需要多个视角以提高置信度。

典型用例：
- Sectioning：一个模型处理用户请求，另一个同时做内容安全审查——比让同一个模型同时做两件事效果更好
- Voting：多个 Prompt 分别审查代码漏洞，或评估内容是否不当，通过投票平衡误报和漏报

关键洞察：对于复杂任务中的多重考量，让每个考量由独立的 LLM 调用处理，模型能给予每个方面更集中的注意力。

4. Orchestrator-Workers（编排者-工作者）

一个中央 LLM（Orchestrator）动态地拆解任务、分派给 Worker LLM、然后综合结果。

与 Parallelization 的关键区别：Parallelization 的子任务是预定义的；Orchestrator-Workers 的子任务是由编排者根据输入动态确定的。

适用场景：无法预先预测需要哪些子任务。

典型用例：
- 编码产品需要对多个文件进行复杂修改，每次任务涉及的文件和修改性质都不同
- 搜索任务需要从多个来源收集和分析信息，每个任务的来源组合不同

5. Evaluator-Optimizer（评估者-优化者）

一个 LLM 生成响应，另一个提供评估和反馈，形成循环，不断迭代改进。

适用场景：有明确的评估标准，且迭代改进能提供可衡量的价值。两个信号表明这个模式适合：人类反馈可以明显改善 LLM 输出；LLM 自身能够提供有效反馈。

典型用例：
- 文学翻译：翻译 LLM 可能无法一次性捕捉所有细微差别，但评估 LLM 可以提供有用的批评
- 复杂搜索：需要多轮搜索和分析才能收集全面信息，评估者决定是否需要进一步搜索

本质类比：就像人类作者写一份精炼文档的过程——初稿、审阅、修改、再审阅。

自主 Agent：什么时候真正需要自治

Agent 可以处理复杂任务，但实现往往出人意料的简单——本质上就是 LLM 在一个循环中，基于环境反馈使用工具。

适用场景：开放式问题，无法预测需要的步骤数，不能硬编码固定路径。LLM 可能运行多个回合，你必须对它的决策能力有一定信任。

代价：自主性意味着更高的成本，以及错误复合的可能。建议在沙箱环境中充分测试，并设置适当的 Guardrails。

实际案例：
- 编码 Agent 解决 SWE-bench 任务：基于任务描述自动编辑多个文件
- Computer Use Agent：Claude 使用计算机完成任务

两个最有价值的 Agent 应用领域

客服 Agent：天然适合 Agent 化——交互遵循对话流程，同时需要访问外部信息和执行操作（查客户数据、订单历史、知识库，发退款、更新工单），成功标准明确（用户问题是否解决）。已有公司采用按解决量收费的商业模式，证明对 Agent 有效性的信心。

编码 Agent：代码方案可以通过自动化测试验证；Agent 可以用测试结果作为反馈迭代改进；问题空间定义清晰且结构化；输出质量可以客观衡量。但自动化测试验证的是功能性，人类审查仍然是确保方案与更广泛系统需求一致的关键。

三大核心原则

Anthropic 总结了构建 Agent 的三个核心原则：

1. 保持简单。 不要追求最复杂的系统，追求最适合你需求的系统。从简单 Prompt 开始，用全面的评估优化它，只在简单方案不够时才添加多步 Agentic System。

2. 优先透明。 明确展示 Agent 的规划步骤。让用户和开发者能看到 Agent 在想什么、为什么这样决策。黑盒 Agent 难以调试，也难以赢得信任。

3. 精心设计 ACI。 Agent-Computer Interface（Agent-计算机接口）的工具文档和测试，值得和 Prompt 一样多的工程投入。

ACI 设计：被严重低估的关键

文章最有实践指导意义的部分是 Appendix 2——工具提示工程。

Anthropic 明确指出：不管构建哪种 Agentic System，工具都是重要组成部分。工具定义和规格应该获得和整体 Prompt 同等的提示工程关注度。

工具格式选择的三个原则

给模型足够的 Token 来"思考"，避免它把自己写进死角
格式贴近模型在训练数据中见过的自然形式——互联网文本中的常见格式
消除格式"开销"——不要让模型维护精确的行数计数，或转义它写出的代码

ACI 设计的四条建议

站在模型的角度想：基于工具描述和参数，怎么使用这个工具是否显而易见？如果不明显，模型也会觉得困难。好的工具定义包含示例用法、边界情况、输入格式要求和与其他工具的清晰边界。
优化参数命名和描述：就像为团队里的初级开发者写一份优秀的 Docstring。这在工具数量很多时尤其重要。
测试模型如何使用工具：在 Workbench 中运行大量示例输入，看模型犯什么错误，然后迭代。
Poka-yoke（防呆）：修改参数设计，让犯错变得更难。