以下内容转载自 Anthropic 官方网站技术文章并通过 AI 翻译，完整原文请见：https://www.anthropic.com/engineering/building-effective-agents
我们曾与各行各业构建 LLM 代理的数十个团队合作。一贯地，最成功的实现通常使用简单、可组合的模式，而不是复杂的框架。
在过去的一年里，我们与数十个旨在构建大语言模型 (LLM) 代理的团队紧密合作。我们观察到，最成功的案例并非使用了复杂的框架或专门的库，相反，它们往往是基于简单、可组合的模式构建的。
在本文中，我们将分享从客户合作及自身代理构建过程中总结的经验，并为开发人员提供构建高效代理的实用建议。
什么是代理？#
“代理 (Agent)”有多种定义方式。一些客户将其定义为完全自主的系统，能够利用各种工具长期独立运行以完成复杂任务。另一些则用该术语描述遵循预定义工作流、更具规定性的实现。在 Anthropic，我们将所有这些变体统称为代理系统 (agentic systems)，但在架构上对工作流 (workflows) 和代理 (agents) 做了重要区分：
- 工作流是将 LLM 和工具通过预定义代码路径进行策划的系统。
- 代理则是 LLM 能够动态指导自身流程和工具使用，并保持对任务完成方式控制权的系统。
下面我们将详细探讨这两类代理系统。在附录 1（“代理的实践”）中，我们描述了客户认为此类系统特别具有价值的两个领域。
何时（以及何时不）使用代理#
在构建 LLM 应用程序时，我们建议寻找尽可能简单的解决方案，仅在必要时增加复杂性。这可能意味着根本不需要构建代理系统。代理系统通常以增加延迟和成本为代价来换取更好的任务性能，您应当权衡这种折衷是否值得。
当需要更高复杂性时，工作流能为定义明确的任务提供可预测性和一致性；而当需要在规模化场景下发挥灵活性和模型驱动的决策能力时，代理则是更好的选择。然而，对于许多应用来说，通过检索和上下文示例优化单个 LLM 调用通常就足够了。
何时及如何使用框架#
有许多框架可以简化代理系统的实现，包括：
- Claude Agent SDK；
- AWS 的 Strands Agents SDK；
- Rivet，一个拖拽式 GUI LLM 工作流构建器；以及
- Vellum，另一个用于构建和测试复杂工作流的 GUI 工具。
这些框架通过简化调用 LLM、定义和解析工具以及链接调用等标准底层任务，让入门变得容易。然而，它们往往会创建额外的抽象层，掩盖底层的 prompt 和响应，使调试变得更加困难。它们还可能诱导开发者在简单的方案就足够时增加不必要的复杂性。
我们建议开发人员从直接使用 LLM API 开始：许多模式只需几行代码即可实现。如果您确实使用了框架，请确保您理解其底层代码。对“黑盒”功能的错误假设是客户出错的常见原因。
请参阅我们的 Cookbook 获取一些示例实现。
构建块、工作流和代理#
在本节中，我们将探讨生产中常见的代理系统模式。我们将从基础构建块——增强型 LLM 开始，逐步增加复杂性，从简单的组合工作流演进到自主代理。
基础构建块：增强型 LLM#
代理系统的基本构建块是经过增强（如检索、工具和记忆）的 LLM。我们目前的模型可以主动利用这些能力——生成搜索查询、选择合适的工具并确定要保留的信息。
增强型 LLM
我们建议关注实现的两个关键方面：针对特定用例定制这些能力，并确保它们为 LLM 提供简单、文档齐全的接口。虽然实现这些增强有很多方法，但其中一种是使用我们最近发布的 Model Context Protocol (MCP)，它允许开发人员通过简单的客户端实现集成第三方工具生态系统。
在本文余下部分，我们将假设每个 LLM 调用都可以访问这些增强能力。
工作流：Prompt 链 (Prompt chaining)#
Prompt 链将任务分解为一系列步骤，其中每个 LLM 调用处理前一个步骤的输出。您可以在任何中间步骤添加程序化检查（见下图中的“gate”），以确保流程处于正确轨道。
Prompt 链工作流
何时使用此工作流： 此工作流非常适合可以轻松、清晰地分解为固定子任务的情况。其核心目标是通过让每个 LLM 调用处理更简单的子任务来换取更高的准确性。
示例：
- 生成营销文案，然后将其翻译成另一种语言。
- 编写文档大纲，检查大纲是否符合特定标准，然后根据大纲编写完整文档。
工作流：路由 (Routing)#
路由对输入进行分类，并将其导向专门的后续任务。这种工作流实现了关注点分离，允许构建更专业的 prompt。若没有此工作流，针对一种输入的优化往往会损害模型在其他输入上的表现。
路由工作流
何时使用此工作流： 路由适用于存在明显分类的复杂任务，且分类可以由 LLM 或传统分类模型/算法准确处理的情况。
示例：
- 将不同类型的客户服务查询（一般问题、退款请求、技术支持）引导至不同的下游流程、prompt 和工具。
- 将简单常见的问题路由至低成本模型（如 Claude 4.5 Haiku），而将困难罕见的问题路由至更强大的模型（如 Claude 4.5 Sonnet），以优化整体性能。
工作流：并行化 (Parallelization)#
LLM 有时可以同时处理一个任务，并以程序化方式聚合其输出。并行化有两种关键变体：
- 分截 (Sectioning)：将任务分解为并行的独立子任务。
- 投票 (Voting)：多次运行同一任务以获得多样化的输出。
并行化工作流
何时使用此工作流： 当子任务可以并行化以提高速度，或者需要多个视角/尝试以获得更高可信度的结果时。对于涉及多重考量的复杂任务，当每个考量由独立的 LLM 调用负责时，性能通常更好。
示例：
- 分截：实施护栏系统，一个实例处理用户查询，另一个实例筛查不当内容。这通常比让单个 LLM 同时处理回复和护栏效果更好。
- 投票：检查代码是否存在漏洞，由多个不同的 prompt 进行审查，如果发现问题则进行标记。
工作流：编排者-工作者 (Orchestrator-workers)#
在编排者-工作者工作流中，中央 LLM 动态分解任务，将其分配给工作者 LLM，并汇总最终结果。
编排者-工作者工作流
何时使用此工作流： 适用于无法预知具体子任务的复杂任务（例如在编程中，需要修改的文件数量和性质取决于具体任务）。它与并行化的关键区别在于其灵活性——子任务不是预定义好的，而是由编排者根据输入动态决定的。
示例：
- 针对涉及多个文件复杂变更的编程产品。
- 需要从多个来源收集并分析信息的搜索任务。
工作流：评估者-优化者 (Evaluator-optimizer)#
在这种工作流中，一个 LLM 调用生成响应，另一个提供评估和反馈，并在循环中进行优化。
评估者-优化者工作流
何时使用此工作流： 适用于有明确评估标准且迭代改进具有衡量价值的场景。
示例：
- 文学翻译：译者 LLM 可能无法一次性捕捉所有细微差别，而评估者 LLM 可以提供有用的批评。
- 复杂搜索任务：需要多轮搜索和分析，由评估者决定是否需要进一步搜索。
代理 (Agents)#
随着 LLM 在理解复杂输入、推理规划、可靠使用工具以及错误恢复等方面能力的成熟，代理正逐渐进入生产环境。代理的工作通常始于用户的指令或交互讨论。任务明确后，代理独立进行规划和操作，并在需要进一步信息或判断时返回询问用户。在执行过程中，代理必须从每一步的运行环境（如工具调用结果或代码执行情况）中获取“事实依据 (ground truth)”以评估进度。代理可以在检查点或遇到障碍时暂停以获取人工反馈。如果是为了维持控制权，通常会包含停止条件（如最大迭代次数）。
代理可以处理复杂任务，但其实现往往非常简单。它们通常就是在循环中使用工具、根据环境反馈进行决策的 LLM。因此，精心设计工具集及其文档至关重要。我们在附录 2（“为工具进行 Prompt 工程”）中详细介绍了相关最佳实践。
自主代理
何时使用代理： 适用于难以预测步骤数量、无法硬编码固定路径的开放式问题。由于代理具有自主性，其成本可能更高且存在错误累积的风险，因此建议在沙盒环境中进行广泛测试并配备相应的护栏。
示例：
- 解决 SWE-bench 任务 的编程代理。
- 我们的“计算机使用”参考实现。
编程代理的高级流程
组合与定制模式#
这些构建块并非一成不变的准则。它们是开发人员可以根据不同用例进行重塑和组合的常见模式。成功的关键在于衡量性能并不断迭代。再次强调：仅在复杂性能够带来显著改进时才考虑增加复杂性。
总结#
LLM 领域的成功不在于构建最复杂的系统，而在于为您的需求构建正确的系统。从简单的 prompt 开始，通过全面的评估进行优化，仅在简单方案无法满足需求时再引入多步代理系统。
在实现代理时，我们遵循三个核心原则：
- 保持代理设计的简洁性。
- 通过显式展示代理的规划步骤来优先考虑透明度。
- 通过详尽的工具文档和测试精心打造您的代理-计算机接口 (ACI)。
框架可以帮助您快速入门，但在进入生产阶段时，不要犹豫去减少抽象层并使用基础组件。遵循这些原则，您可以创建出既强大又可靠、可维护且受用户信赖的代理。
致谢#
由 Erik Schluntz 和 Barry Zhang 撰写。
附录 1：代理的实践#
由于篇幅关系，附录部分主要探讨了客户支持和编程代理两个最具前景的应用领域。
附录 2：为工具进行 Prompt 工程#
无论您构建哪种代理系统，工具都是核心。我们建议：
- 给模型足够的 Token 让它在采取行动前进行“思考”。
- 保持格式接近模型在互联网上自然见到的文本。
- 确保没有格式“开销”（如要求精确计算数千行代码的行数）。
- 站在模型的角度思考工具描述是否清晰，并进行 Poka-yoke（防错）设计。
我们在构建 SWE-bench 代理时，发现将相对路径改为绝对路径能显著降低模型的出错率。这对提升代理-计算机接口 (ACI) 的稳定性至关重要。