Anthropic关于智能体的经验分享：如何构建高效的Agent？

最近看到一个文章，是Anthropic半年之前公布的一个关于Agent文章，里面的一些概念以及经验，非常值得大家参考，下面是笔者翻译后的内容，原文在这： https://www.anthropic.com/engineering/building-effective-agents

在过去的一年里，Anthropic 团队与数十个跨行业的团队合作，帮助他们构建大语言模型（LLM）智能体。有个有趣的发现：最成功的实现往往不是那些使用复杂框架或专业库的项目，而是采用简单、可组合模式的项目。

这篇文章分享了Anthropic在与客户合作和自建智能体过程中积累的经验， 为开发者提供构建有效智能体的实用建议。

什么是智能体？

"智能体"这个词有很多种定义。有些人把它定义为完全自主的系统，能够长时间独立运行，使用各种工具完成复杂任务。另一些人则用它来描述遵循预定义工作流程的更规范化的实现。

Anthropic 将这些变体都归类为智能体系统，但在架构上对工作流和智能体做了重要区分：

• 工作流 ：通过预定义的代码路径来编排 LLM 和工具的系统

• 智能体 ：LLM 动态指导自己的流程和工具使用，保持对任务完成方式控制权的系统

  何时使用（以及何时不使用）智能体

---

在构建 LLM 应用时，建议找到最简单可行的解决方案，只在必要时增加复杂性。这可能意味着根本不构建智能体系统。

智能体系统通常以延迟和成本为代价来换取更好的任务性能，需要考虑这种权衡是否值得。当需要更高复杂性时：

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

对于许多应用来说，通过检索和上下文示例优化单个 LLM 调用通常就足够了。 所以大家是不是觉得Agent有时候需要写大量提示工程？

关于框架的选择

市面上有很多让智能体系统更容易实现的框架：

• LangChain 的 LangGraph
• Amazon Bedrock 的 AI 智能体框架
• Rivet（拖拽式 GUI LLM 工作流构建器）
• Vellum（另一个用于构建和测试复杂工作流的 GUI 工具）

这些框架通过简化调用 LLM、定义和解析工具、链接调用等标准底层任务，让入门变得容易。但它们往往会创建额外的抽象层，可能会模糊底层的提示和响应，使调试变得困难。它们也可能诱使开发者在简单设置就够用的情况下增加复杂性。

建议开发者从直接使用 LLM API 开始 ：许多模式可以用几行代码实现。如果使用框架，确保理解底层代码。对底层机制的错误假设是客户错误的常见来源。

构建模块、工作流和智能体

接下来探讨生产环境中智能体系统的常见模式。从基础构建模块——增强 LLM 开始，逐步增加复杂性，从简单的组合工作流到自主智能体。

基础构建模块：增强 LLM

智能体系统的基本构建模块是通过检索、工具和记忆等增强功能提升的 LLM。当前的模型可以主动使用这些能力——生成自己的搜索查询、选择合适的工具、确定要保留的信息。

重点关注实现的两个关键方面：

1. 根据具体用例定制这些能力
2. 确保它们为 LLM 提供易用且文档完善的接口

工作流模式

1. 提示链（Prompt Chaining）

提示链将任务分解为一系列步骤，每个 LLM 调用处理前一个的输出。可以在任何中间步骤添加程序化检查，确保流程保持正轨。

适用场景 ：任务可以轻松清晰地分解为固定子任务的情况。主要目标是通过让每个 LLM 调用成为更简单的任务来权衡延迟换取更高准确性。

示例 ：

• 生成营销文案，然后翻译成不同语言
• 写文档大纲，检查大纲是否符合特定标准，然后基于大纲写文档

2. 路由（Routing）

路由对输入进行分类并将其导向专门的后续任务。这种工作流允许关注点分离，构建更专业的提示。没有这种工作流，针对一种输入的优化可能会影响其他输入的性能。

适用场景 ：复杂任务中存在最好分别处理的不同类别，且分类可以通过 LLM 或传统分类模型/算法准确处理。

示例 ：

• 将不同类型的客户服务查询（一般问题、退款请求、技术支持）导向不同的下游流程、提示和工具
• 将简单/常见问题路由到较小模型如 Claude 3.5 Haiku，将困难/异常问题路由到更强大的模型如 Claude 3.5 Sonnet，以优化成本和速度

3. 并行化（Parallelization）

LLM 有时可以同时处理任务，并通过程序化方式聚合其输出。这种工作流有两个关键变体：

• 分段 ：将任务分解为并行运行的独立子任务
• 投票 ：多次运行相同任务以获得多样化输出

适用场景 ：分割的子任务可以并行化以提高速度，或者需要多个视角或尝试以获得更高置信度结果时有效。

示例 ：

• 分段 ：实现防护栏，一个模型实例处理用户查询，另一个筛选不当内容或请求
• 投票 ：审查代码漏洞，多个不同提示审查代码并在发现问题时标记

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

在编排者-工作者工作流中，中央 LLM 动态分解任务，将其委托给工作者 LLM，并综合它们的结果。

适用场景 ：适合无法预测所需子任务的复杂任务（例如编程中，需要更改的文件数量和每个文件中更改的性质可能取决于任务）。与并行化的关键区别在于其灵活性——子任务不是预定义的，而是由编排者根据特定输入确定的。

示例 ：

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

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

在评估者-优化者工作流中，一个 LLM 调用生成响应，另一个在循环中提供评估和反馈。

适用场景 ：当有明确的评估标准且迭代改进提供可衡量价值时特别有效。良好匹配的两个标志是：首先，当人类表达反馈时，LLM 响应可以得到明显改善；其次，LLM 可以提供此类反馈。

示例 ：

• 文学翻译，其中翻译 LLM 最初可能无法捕捉到细微差别，但评估者 LLM 可以提供有用的批评
• 需要多轮搜索和分析以收集全面信息的复杂搜索任务

智能体

随着 LLM 在关键能力方面的成熟——理解复杂输入、推理和规划、可靠使用工具、从错误中恢复，智能体正在生产环境中兴起。

智能体从与人类用户的命令或交互式讨论开始工作。一旦任务明确，智能体就会独立规划和操作，可能会回到人类那里获取进一步信息或判断。在执行过程中，智能体在每个步骤从环境中获得"基本事实"（如工具调用结果或代码执行）来评估其进展至关重要。

适用场景 ：智能体可用于难以或不可能预测所需步骤数的开放式问题，以及无法硬编码固定路径的场景。LLM 可能运行很多轮，必须对其决策有一定程度的信任。

智能体的自主性意味着更高的成本和复合错误的潜力。建议在沙盒环境中进行广泛测试，并设置适当的防护栏。

示例 ：

• 解决 SWE-bench 任务的编程智能体，涉及基于任务描述对多个文件进行编辑

• Claude 使用计算机完成任务的“computer use” reference implementation参考实现

  组合和定制这些模式

---

这些构建模块不是规定性的。它们是开发者可以塑造和组合以适应不同用例的常见模式。成功的关键，与任何 LLM 功能一样，是衡量性能并迭代实现。重申：只有在能明显改善结果时才应该考虑增加复杂性。

总结

LLM 领域的成功不在于构建最复杂的系统，而在于构建适合需求的正确系统。从简单提示开始，通过全面评估优化它们，只有在简单解决方案不足时才添加多步骤智能体系统。

在实现智能体时，遵循三个核心原则：

1. 保持智能体设计的简单性
2. 通过明确显示智能体的规划步骤来优先考虑透明度
3. 通过彻底的工具文档和测试精心设计智能体-计算机接口（ACI）

框架可以帮助快速入门，但随着迁移到生产环境，不要犹豫减少抽象层并使用基本组件构建。遵循这些原则，可以创建不仅强大而且可靠、可维护并受用户信任的智能体。

添加微信，备注” LLM “进入大模型技术交流群

如果你觉得这篇文章对你有帮助，别忘了点个赞、送个喜欢

/ 作者：致Great

/ 作者：欢迎转载，标注来源即可