构建高效的 Agent

作者：Erik S. & Barry Zhang · 2024 年 12 月 19 日发布

原文链接：Building Effective Agents（Anthropic，2024-12-19）· 以下为中文翻译转载

过去一年里，我们与数十个团队合作，帮助他们在各行各业构建基于大语言模型（LLM）的 Agent。我们观察到一个一致的趋势：最成功的实现并非使用复杂的框架或专用库，而是采用简单、可组合的模式。

本文分享我们从客户实践和自我构建 Agent 中积累的经验，并为开发者提供构建高效 Agent 的实用建议。

什么是 Agent？

"Agent"一词有多种定义。有些客户将其定义为在较长时间内完全自主运行、使用多种工具完成复杂任务的系统；另一些则用它描述遵循预定义工作流的规范性实现。在 Anthropic，我们将所有这些变体统称为**"Agentic 系统"**，但在架构上做出一个重要区分——工作流（Workflows） 与 Agent（Agents）：

工作流：LLM 和工具通过预定义的代码路径编排。
Agent：LLM 动态主导自身流程和工具使用，自主控制完成任务的方式。

何时使用（以及不使用）Agent

使用 LLM 构建应用时，我们建议先寻找最简单的解决方案，仅在必要时增加复杂度。这甚至意味着可能根本不需要构建 Agentic 系统。Agentic 系统通常以增加延迟和成本为代价换取更好的任务表现——你要权衡这种取舍是否值得。

当确实需要更高复杂度时：

工作流适合定义明确的任务，提供可预测性和一致性。
Agent适合需要灵活性和模型驱动决策的大规模场景。

然而，对大多数应用而言，通过检索增强（RAG） 和上下文示例优化单次 LLM 调用通常就足够了。

何时以及如何使用框架

市面上有许多简化 Agentic 系统实现的框架，包括 Claude Agent SDK、AWS Strands Agents SDK、Rivet（拖拽式 GUI 工作流构建器）以及 Vellum 等。

这些框架通过简化调用 LLM、定义和解析工具、链式调用等标准底层任务来降低入门门槛。但它们往往会引入额外的抽象层，遮蔽底层的提示和响应，使得调试更困难，也容易让人在简单方案就足够时过度增加复杂度。

我们的建议：开发者应从直接使用 LLM API 开始——很多模式用几行代码就能实现。如果使用框架，务必理解底层代码。对底层机制的误解是客户出错的常见原因。

构建块、工作流与 Agent

下面我们介绍在生产环境中观察到的常见 Agentic 系统模式。从基础构建块——增强型 LLM 开始，逐步增加复杂度，从简单的组合式工作流到自主 Agent。

构建块：增强型 LLM

Agentic 系统的基本单元是一个经过检索、工具和记忆等增强的 LLM。当前模型已能主动使用这些能力——生成搜索查询、选择合适工具、决定保留哪些信息。

实现时建议关注两个关键方面：根据具体用例定制这些能力，以及确保它们为 LLM 提供简单、文档完备的接口。一种实现方式是通过我们最新发布的 Model Context Protocol（MCP）与不断增长的第三方工具生态集成。

下文假设每次 LLM 调用都可访问这些增强能力。

工作流模式 1：提示链（Prompt Chaining）

核心思路：将任务分解为一系列步骤，每次 LLM 调用处理前一步的输出。可在中间步骤加入程序化检查（门控 gate）确保流程正确。

适用场景：任务可被清晰分解为固定的子任务，目标是通过让每次 LLM 调用面向更简单的任务，以延迟换取更高准确度。

典型例子：

生成营销文案 → 翻译为另一种语言
撰写文档大纲 → 检查大纲是否符合标准 → 基于大纲撰写文档

工作流模式 2：路由（Routing）

核心思路：对输入进行分类，将其导向专门的后继任务。该模式实现了关注点分离，允许构建更专业的提示。

适用场景：复杂任务中存在明显可分类处理的场景，且分类本身可由 LLM 或传统分类模型准确完成。

典型例子：

将客服查询（一般问题 / 退款请求 / 技术支持）路由到不同的下游流程、提示和工具
将简单常见问题路由到小型低成本模型（如 Claude Haiku），复杂罕见问题路由到更强模型（如 Claude Sonnet），以优化性能与成本

工作流模式 3：并行化（Parallelization）

核心思路：LLM 可同时处理一个任务的多个方面，然后程序化汇总结果。有两种关键变体：

变体	说明
分段（Sectioning）	将任务拆分为独立的并行子任务
投票（Voting）	多次运行同一任务以获取多样化输出

适用场景：子任务可以并行以提升速度，或需要多视角/多尝试以获得更高置信度。对于有多重考量因素的复杂任务，LLM 通常在每个因素由独立调用处理时表现更好。

典型例子：

分段：

一个模型实例处理用户查询，另一个筛查不当内容——比让同一次调用同时处理护栏和回复更有效
自动化评估 LLM 表现时，每次调用评估模型在给定提示上的不同方面

投票：

代码漏洞审查：多个不同提示审查代码，发现问题时标记
评估内容是否不当：多个提示评估不同维度，设置不同投票阈值以平衡误报和漏报

工作流模式 4：编排器-工作者（Orchestrator-Workers）

核心思路：中央 LLM 动态拆分任务，委派给工作者 LLM，然后综合结果。

适用场景：适合无法预知子任务的复杂任务（例如编程中需修改的文件数量及每个文件的修改方式取决于具体任务）。与并行化的关键区别在于灵活性——子任务不是预先定义的，而是由编排器根据具体输入动态决定。

典型例子：

每次需对多个文件进行复杂修改的编程产品
涉及从多个来源收集和分析信息的搜索任务

工作流模式 5：评估器-优化器（Evaluator-Optimizer）

核心思路：一次 LLM 调用生成回复，另一次调用提供评估和反馈，循环迭代。

适用场景：存在明确的评估标准，且迭代优化能带来可衡量价值。两个适配信号：1）当人类表述反馈时，LLM 回复可以明显改善；2）LLM 本身能够提供这样的反馈。这类似于人类撰写打磨文档时的迭代过程。

典型例子：

文学翻译：翻译 LLM 可能未能捕捉微妙之处，评估 LLM 可提供有用批评
复杂搜索任务：需要多轮搜索和分析以收集全面信息，评估器判断是否需要进一步搜索

Agent

随着 LLM 在理解复杂输入、推理与规划、可靠使用工具、错误恢复等关键能力上的成熟，Agent 开始在生产环境中崭露头角。Agent 从人类用户的指令或交互式对话开始工作。一旦任务明确，Agent 可独立规划和操作，必要时回访人类获取更多信息或判断。在执行过程中，Agent 必须在每个步骤从环境获取"真实反馈"（如工具调用结果或代码执行）以评估进展。Agent 可在检查点或遇到阻碍时暂停等待人工反馈。

Agent 能处理复杂任务，但实现通常很简单——本质上就是LLM 在循环中根据环境反馈使用工具。因此，精心设计工具集及其文档至关重要。

适用场景：开放性问题，难以或无法预测所需步骤数量，无法硬编码固定路径。LLM 可能运行多个轮次，你需要对其决策有一定信任。Agent 的自主性使其在可信环境中扩展任务时尤为理想。

同时要注意：Agent 的自主性意味着更高成本和错误可能累积。建议在沙箱环境中进行大量测试，并设置合适的护栏。

实际案例（来自 Anthropic 自身实现）：

代码 Agent 解决 SWE-bench 任务（根据任务描述修改多个文件）
"计算机使用"参考实现（Claude 使用计算机完成任务）

组合与定制这些模式

这些构建块不是教条，而是常见模式。开发者可根据不同用例自由调整和组合。成功的关键在于衡量性能并持续迭代。再次强调：只有在能明显改善结果时才增加复杂度。

总结

LLM 领域的成功不在于构建最复杂的系统，而在于构建适合你需求的正确系统。从简单的提示开始，通过全面评估优化，只有在简单方案不够用的时候才添加多步骤的 Agentic 系统。

构建 Agent 时，我们遵循三个核心原则：

保持简洁：Agent 设计尽量简单。
优先透明：显式展示 Agent 的规划步骤。
精心打造 Agent-计算机接口（ACI）：通过完善的工具文档和测试来打磨。

框架可以帮助你快速起步，但在进入生产阶段时，不要犹豫减少抽象层次，使用基础组件构建。遵循这些原则，你创建的 Agent 将不仅强大，而且可靠、可维护，并赢得用户信任。

附录 1：Agent 实践案例

客户实践揭示了两个特别有前景的 AI Agent 应用场景，两者都展示了 Agent 在需要对话与行动结合、有明确成功标准、支持反馈循环、问题领域结构清晰且输出质量可客观衡量时最有价值。

在我们的实现中，Agent 现在已能仅凭 PR 描述就解决 SWE-bench Verified 基准中的真实 GitHub Issue。然而，自动化测试有助于验证功能，人工审查对于确保解决方案符合更广泛的系统需求仍然至关重要。

附录 2：工具的提示工程

无论构建哪种 Agentic 系统，工具都可能扮演重要角色。工具使 Claude 能够与外部服务和 API 交互。工具定义和规范应该得到与整体提示同等的提示工程关注。

选择工具格式的建议：

给模型足够的 tokens 进行"思考"，避免其把自己逼入死角。
尽量保持格式接近模型在互联网文本中自然见到过的形式。
确保没有格式"开销"——例如需要精确计数数千行代码，或对所有写出的代码进行字符串转义。

经验法则：想想人类-计算机接口（HCI）需要投入多少精力，就为打造良好的 Agent-计算机接口（ACI）投入同等精力。具体做法：

站在模型的角度思考：基于描述和参数，使用这个工具是否直观？如果不直观，对模型也是如此。好的工具定义通常包含示例用法、边界情况、输入格式要求以及与其他工具的清晰界限。
改进参数名称或描述使其更清晰——就像为团队初级开发者编写出色的 docstring。在使用许多相似工具时尤为重要。
测试模型如何使用工具：在 workbench 中运行大量示例输入，观察模型犯错，然后迭代改进。
防错设计（Poka-yoke）：修改参数使其更难犯错。

在构建 SWE-bench Agent 时，我们花在优化工具上的时间超过了花在整体提示上的时间。例如，我们发现模型在 Agent 离开根目录后使用相对路径会出错，于是将工具改为始终要求绝对路径——模型就完美地使用了这种方式。

原文：https://www.anthropic.com/engineering/building-effective-agents