Agent系列3：clauda-如何高效构建Agent智能体

开源agent智能体系列专题：主要是介绍目前市面上开源的智能体框架，如CrewAI、AutoGen、LangChain、phidata、Swarm等，介绍它们的优缺点、功能特性、效果和用法等。

感兴趣的朋友可以关注公众号"XiaozhiAGI"，将持续输出关于RAG、Agent、Agentic workflow、AGI等人工智能前沿技术动态、产品动态。

---

正文翻译如下：

2024年12月20日  国外AI公司-Anthropic

在过去的一年中，我们与数十个团队合作，跨行业构建大型语言模型（LLM）代理。始终，最成功的实现不是使用复杂的框架或专门的库，而是使用简单、可组合的模式构建。

在这篇文章中，我们分享了我们从与客户和建筑代理合作中学到的经验，并为开发人员提供了关于构建有效代理的实用建议。

1.什么是代理商？

“代理”可以用多种方式定义。一些客户将代理定义为完全自主的系统，可以在长时间内独立运行，使用各种工具来完成复杂任务。其他人使用该术语来描述遵循预定义工作流程的更具规范性的实现。在Anthropic，我们将所有这些变体归类为真正的代理系统，但在工作流程和代理之间划出了重要的架构区别。

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

• 另一方面，代理是LLM动态指导自己的流程和工具使用的系统，保持对他们如何完成任务的控制。

下面，我们将详细探讨这两种类型的代理系统。在附录1（“实践中的代理”）中，我们描述了两个领域，客户在使用这些类型的系统时发现了特别的价值。

2.何时（以及何时不）使用代理

在使用LLM构建应用程序时，我们建议找到最简单的解决方案，并在需要时仅增加复杂性。这可能意味着根本不构建代理系统。代理系统通常会为了更好的任务性能而牺牲延迟和成本，您应该考虑何时这种权衡是有意义的。

当需要更多的复杂性时，工作流为明确定义的任务提供可预测性和一致性，而当需要大规模的灵活性和模型驱动决策时，代理是更好的选择。然而，对于许多应用程序，通过检索和上下文示例优化单个LLM调用通常就足够了。

3.何时以及如何使用框架

有许多框架可以使代理系统更容易实现，包括：

• LangGraph来自LangChain；

• 亚马逊基岩的AI代理框架；

• 铆钉，一个拖放GUILLM工作流生成器；和

• Vellum，另一个用于构建和测试复杂工作流的GUI工具。

这些框架通过简化标准的低级任务，如调用LLM、定义和解析工具以及将调用链接在一起，使入门变得容易。然而，它们通常会创建额外的抽象层，这可能会掩盖底层提示和响应，使它们更难调试。当更简单的设置就足够时，它们还可能会使增加复杂性变得诱人。

我们建议开发人员直接使用LLM API：许多模式可以在几行代码中实现。如果您使用框架，请确保您理解底层代码。对底层代码的错误假设是客户错误的常见来源。

有关一些示例实现，请参阅我们的食谱。

4.构建块、工作流和代理

在本节中，我们将探讨我们在生产中看到的代理系统的常见模式。我们将从我们的基础构建块——增强型LLM开始，逐步增加复杂性，从简单的组合工作流程到自主代理。

4.1.构建块：增强型LLM

代理系统的基本构建块是通过检索、工具和内存等增强功能增强的LLM。我们当前的模型可以积极使用这些功能——生成自己的搜索查询、选择适当的工具并确定要保留哪些信息。

增强型LLM

我们建议关注实现的两个关键方面：根据您的特定用例定制这些功能，并确保它们为您的LLM提供一个简单、文档齐全的界面。虽然有很多方法可以实现这些增强，但一种方法是通过我们最近发布的模型上下文协议，它允许开发人员通过简单的客户端实现与不断增长的第三方工具生态系统集成。

对于本文的其余部分，我们将假设每个LLM调用都可以访问这些增强功能。

4.2.工作流程：提示链接

提示链接将任务分解为一系列步骤，其中每个LLM调用处理前一个的输出。您可以在任何中间步骤上添加编程检查（参见下图中的“门”），以确保流程仍在正轨上。

提示链接工作流程

何时使用此工作流：此工作流非常适合任务可以轻松干净地分解为固定子任务的情况。主要目标是通过使每个LLM调用更容易来权衡延迟以获得更高的准确性。

提示链接有用的示例：

• 生成营销文案，然后将其翻译成不同的语言。

• 编写文档大纲，检查大纲是否符合某些标准，然后根据大纲编写文档。

4.3.工作流程：路由

路由对输入进行分类并将其定向到专门的跟进任务。此工作流程允许分离关注点并构建更专门的提示。如果没有此工作流程，针对一种输入进行优化可能会损害其他输入的性能。

路由工作流程

何时使用此工作流：路由适用于复杂任务，其中有更好地单独处理的不同类别，并且可以通过LLM或更传统的分类模型/算法准确处理分类。

路由有用的示例：

• 将不同类型的客服查询（普通问题、退款申请、技术支持）引导到不同的下游流程、提示和工具中。

• 将简单/常见问题路由到Claude 3.5 Haiku等较小的模型，将困难/不寻常问题路由到Claude 3.5 Sonnet等功能更强大的模型，以优化成本和速度。

4.4.工作流程：并行化

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

• 分段：将任务分解为并行运行的独立子任务。

• 投票：多次运行相同的任务以获得不同的输出。

并行化工作流程

何时使用此工作流：当划分的子任务可以并行化以提高速度时，或者当需要多个视角或尝试以获得更高的置信度结果时，并行化是有效的。对于具有多个考虑因素的复杂任务，当每个考虑因素由单独的LLM调用处理时，LLM通常表现更好，允许将注意力集中在每个特定方面。

并行化有用的示例：

• 切片：

  • 实现护栏，其中一个模型实例处理用户查询，而另一个模型实例筛选不适当的内容或请求。这往往比让相同的LLM调用同时处理护栏和核心响应表现更好。

  • 自动评估LLM性能，其中每个LLM调用在给定提示下评估模型性能的不同方面。

• 投票：

  • 审查一段代码是否存在漏洞，如果发现问题，几个不同的提示会审查并标记代码。

  • 评估给定内容是否不合适，多个提示评估不同方面或需要不同的投票阈值来平衡误报和误报。

4.5.工作流程：Orchestrator-workers

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

工作流程orchestrator-workers

何时使用此工作流：此工作流非常适合复杂任务，您无法预测所需的子任务（例如，在编码中，需要更改的文件数量和每个文件中更改的性质可能取决于任务）。虽然它在地形上相似，但与并行化的关键区别在于它的灵活性-子任务不是预定义的，而是由编排器根据特定输入确定的。

orchestrator-workers有用的示例：

• 每次对多个文件进行复杂更改的编码产品。

• 涉及从多个来源收集和分析信息以获取可能相关信息的搜索任务。

4.6.工作流程：评估器-优化器

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

评估优化器工作流程

何时使用此工作流程：当我们有明确的评估标准，并且迭代细化提供可衡量的价值时，此工作流程特别有效。良好适配的两个迹象是，首先，当人类表达反馈时，LLM响应可以明显改善；其次，LLM可以提供这样的反馈。这类似于人类作家在制作精美文档时可能经历的迭代写作过程。

评估器优化器有用的示例：

• 文学翻译，其中有翻译LLM最初可能无法捕捉到的细微差别，但评估LLM可以提供有用的批评。

• 需要多轮搜索和分析以收集综合信息的复杂搜索任务，评估者在其中决定是否需要进一步搜索。

4.7.代理商

随着LLM在关键能力方面的成熟——理解复杂输入、参与推理和计划、可靠地使用工具以及从错误中恢复，代理正在生产中崭露头角。代理从人类用户的命令或交互式讨论开始他们的工作。一旦任务明确，代理就会独立计划和操作，潜在地返回给人类以获取进一步的信息或判断。在执行过程中，代理必须在每个步骤（例如工具调用结果或代码执行）从环境中获得“地面实况”，以评估其进度。然后，代理可以在检查点或遇到阻塞器时暂停以获得人类反馈。任务通常在完成后终止，但也经常包括停止条件（例如最大迭代次数）以保持控制。

代理可以处理复杂的任务，但它们的实现通常很简单。它们通常只是循环中使用基于环境反馈的工具的LLM。因此，清晰而深思熟虑地设计工具集及其留档至关重要。我们在附录2（“提示工程您的工具”）中扩展了工具开发的最佳实践。

自治主体

何时使用代理：代理可用于开放式问题，其中难以或不可能预测所需的步骤数，并且您无法硬编码固定路径。LLM可能会运行许多回合，您必须对其决策有一定程度的信任。代理的自主权使它们成为在可信环境中扩展任务的理想选择。

代理的自治性质意味着更高的成本和可能的复合错误。我们建议在沙盒环境中进行广泛的测试，以及适当的防护措施。

代理有用的示例：

以下示例来自我们自己的实现：

• 一个编码代理，用于解决SWE工作台任务，其中涉及根据任务描述对许多文件进行编辑；

• 我们的“计算机使用”参考实现，其中克劳德使用计算机来完成任务。

编码代理的高级流程

5.组合和自定义这些模式

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

6.总结

LLM领域的成功并不在于构建最复杂的系统。这是关于为您的需求构建正确的系统。从简单的提示开始，通过全面的评估对其进行优化，只有在简单的解决方案不足时才添加多步骤代理系统。

在执行代理时，我们尝试遵循三个核心原则：

1. 保持代理设计的简单性。

2. 通过明确显示代理的计划步骤来优先考虑透明度。

3. 通过彻底的工具留档和测试，精心制作您的代理-计算机接口（ACI）。

框架可以帮助您快速入门，但不要犹豫，减少抽象层并在转向生产时使用基本组件进行构建。通过遵循这些原则，您可以创建不仅强大而且可靠、可维护且受用户信任的代理。

7.致谢

由Erik Schluntz和Barry Zhang撰写。这项工作借鉴了我们在Anthropic建立代理的经验和客户分享的宝贵见解，我们深表感激。

附录1：实践中的代理人

我们与客户的合作揭示了AI代理的两个特别有前途的应用程序，它们展示了上述模式的实际价值。这两个应用程序都说明了代理如何为需要对话和行动的任务增加最大价值，具有明确的成功标准，启用反馈循环，并集成有意义的人类监督。

A.客户支持

客户支持通过工具集成将熟悉的聊天机器人界面与增强的功能相结合。这是更适合开放式代理的自然选择，因为：

• 支持交互自然遵循对话流程，同时需要访问外部信息和操作；

• 可以集成工具拉取客户数据、订单历史、知识库文章；

• 可以以编程方式处理退款或更新票证等操作；和

• 成功可以通过用户定义的决议来清楚地衡量。

一些公司已经通过基于使用的定价模型证明了这种方法的可行性，这种模型只对成功的解决方案收费，显示了对其代理有效性的信心。

B.编码代理

软件开发领域已经显示出LLM功能的巨大潜力，其能力从代码完成发展到自主解决问题。代理特别有效，因为：

• 代码方案可通过自动化测试验证；

• 代理可以使用测试结果作为反馈来迭代解决方案；

• 问题空间定义清晰、结构化；和

• 输出质量可以客观地衡量。

在我们自己的实现中，代理现在可以仅根据拉取请求描述在SWE工作台验证基准测试中解决真正的GitHub问题。然而，尽管自动化测试有助于验证功能，但人工审查对于确保解决方案符合更广泛的系统要求仍然至关重要。

附录2：快速设计您的工具

无论您正在构建哪个代理系统，工具都可能是您代理的重要组成部分。工具使Claude能够通过在我们的API中指定它们的确切结构和定义来与外部服务和API进行交互。当Claude响应时，如果它计划调用工具，它将在API响应中包含一个工具使用块。工具定义和规范应该像您的整体提示一样得到及时的工程关注。在这个简短的附录中，我们描述了如何提示您的工具进行工程设计。

通常有几种方法可以指定相同的操作。例如，您可以通过编写diff或重写整个文件来指定文件编辑。对于结构化输出，您可以在markdown或JSON内返回代码。在软件工程中，这样的差异是表面上的，可以无损地从一个转换为另一个。然而，对于LLM来说，某些格式比其他格式要困难得多。编写diff需要在编写新代码之前知道块头中有多少行正在更改。在JSON内编写代码（与markdown相比）需要额外转义换行符和引号。

我们决定工具格式的建议如下：

• 在模型陷入困境之前，给它足够的令牌来“思考”。

• 保持格式接近模型在互联网上自然出现的文本。

• 确保没有格式化“开销”，例如必须准确计算数千行代码，或对它编写的任何代码进行字符串转义。

一个经验法则是考虑在人机界面（HCI）上投入多少精力，并计划在创建良好的代理-计算机界面（ACI）上投入同样多的精力。以下是一些关于如何做到这一点的想法：

• 设身处地为模型着想。根据描述和参数，如何使用这个工具是显而易见的，还是需要仔细考虑？如果是这样，那么对于模型来说可能也是如此。一个好的工具定义通常包括示例用法、边缘情况、输入格式要求以及与其他工具的清晰边界。

• 如何更改参数名称或描述以使事情更加明显？将其视为为团队中的初级开发人员编写出色的文档字符串。在使用许多类似工具时，这尤其重要。

• 测试模型如何使用您的工具：在我们的工作台中运行许多示例输入，以查看模型犯了哪些错误，并进行迭代。

• Poka-yoke你的工具。改变论点，这样更难犯错误。

在为SWE工作台构建代理时，我们实际上花了比整体提示更多的时间来优化我们的工具。例如，我们发现在代理移出根目录后，模型会在使用相对文件路径的工具时犯错误。为了解决这个问题，我们将工具更改为始终需要绝对文件路径-我们发现模型完美地使用了这种方法。

参考资料

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