#模型时代# Anthropic博客...
- 高飞
- 2024-12-30 15:06:49
模型时代 Anthropic博客：如何构建有效的智能代理
如果要选一个技术领域，作为明年大模型应用的主流方向，那么一定是Agent。这个词国内翻译为代理，或者智能体。
Anthropic几天前就发布了一篇博客文章，谈了一下他们的Agent方法论，转发一下。
原文传送门：www.anthropic.com/research/building-effective-agents
***
构建有效的智能代理
12月20日
在过去的一年里，我们与数十个跨行业的团队合作构建大语言模型(LLM)代理。我们一致发现，最成功的实现并非使用复杂的框架或专门的库，而是采用简单、可组合的模式进行构建。
在这篇文章中，我们分享了与客户合作和自主构建代理的经验，并为开发者提供构建有效代理的实用建议。
*什么是代理？
"代理"可以有多种定义。一些客户将代理定义为能够长期独立运行的完全自主系统，使用各种工具来完成复杂任务。另一些则用这个术语描述更具规范性的实现，即遵循预定义工作流程的系统。在Anthropic，我们将所有这些变体都归类为代理系统，但在工作流和代理之间做出了重要的架构区分：
- 工作流是通过预定义的代码路径来编排LLM和工具的系统。
- 代理则是LLM能够动态指导自己的流程和工具使用的系统，可以自主控制如何完成任务。
下文我们将详细探讨这两种代理系统。在附录1（"实践中的代理"）中，我们描述了两个客户在使用这些系统时发现特别有价值的领域。
*何时（以及何时不）使用代理
在构建LLM应用时，我们建议寻找最简单的解决方案，只在必要时增加复杂性。这可能意味着完全不构建代理系统。代理系统通常会用延迟和成本来换取更好的任务表现，你需要考虑这种权衡是否合理。
当需要更多复杂性时，工作流为明确定义的任务提供可预测性和一致性，而代理则在需要大规模灵活性和模型驱动决策时更为适合。然而，对于许多应用来说，通过检索和上下文示例来优化单个LLM调用通常就足够了。
*何时以及如何使用框架
有许多框架可以让代理系统的实现变得更容易，包括：
- LangChain的LangGraph
- 亚马逊Bedrock的AI Agent框架
- Rivet，一个拖放式GUI LLM工作流构建器
- Vellum，另一个用于构建和测试复杂工作流的GUI工具
这些框架通过简化标准的底层任务（如调用LLM、定义和解析工具、链接调用等）使入门变得容易。但是，它们往往会创建额外的抽象层，使底层提示和响应变得更难调试。它们也可能诱使开发者在更简单的设置就足够的情况下增加复杂性。
我们建议开发者从直接使用LLM API开始：许多模式可以用几行代码实现。如果你确实使用框架，请确保理解底层代码。对底层内容的错误假设是客户常见的错误来源。
*构建模块、工作流和代理
在本节中，我们将探讨我们在生产中看到的代理系统常见模式。我们将从基础构建模块——增强型LLM开始，逐步增加复杂性，从简单的组合工作流到自主代理。
**构建模块：增强型LLM（图一）
代理系统的基本构建模块是经过检索、工具和记忆等功能增强的LLM。我们当前的模型可以主动使用这些功能——生成自己的搜索查询、选择适当的工具，并确定要保留什么信息。
我们建议关注实现的两个关键方面：
1. 将这些功能定制化以适应你的特定用例
2. 确保它们为LLM提供易用、文档完善的接口
虽然有许多方法可以实现这些增强功能，但一种方法是通过我们最近发布的模型上下文协议（Model Context Protocol），它允许开发者通过简单的客户端实现与不断增长的第三方工具生态系统集成。
在本文的其余部分，我们假设每个LLM调用都可以访问这些增强功能。
**工作流：提示链式处理（图二）
提示链式处理将任务分解为一系列步骤，其中每个LLM调用处理前一个调用的输出。你可以在任何中间步骤添加程序化检查（见下图中的"gate"），以确保流程仍在正轨上。
***何时使用这种工作流
这种工作流最适合那些可以轻松且清晰地分解为固定子任务的情况。主要目标是通过使每个LLM调用成为更简单的任务来用延迟换取更高的准确性。
提示链式处理的有用示例：
- 生成营销文案，然后将其翻译成不同语言
- 写一份文档大纲，检查大纲是否满足特定标准，然后基于大纲写文档
**工作流：路由（图三）
路由对输入进行分类并将其导向专门的后续任务。这种工作流允许关注点分离，并构建更专门化的提示。如果没有这种工作流，为一种输入优化可能会损害其他输入的性能。
***何时使用这种工作流
路由适用于复杂任务，其中有不同的类别最好分开处理，且分类可以由LLM或更传统的分类模型/算法准确处理。
路由的有用示例：
- 将不同类型的客户服务查询（一般问题、退款请求、技术支持）导向不同的下游流程、提示和工具
- 将简单/常见问题路由到较小的模型（如Claude 3.5 Haiku），将困难/不寻常的问题路由到更强大的模型（如Claude 3.5 Sonnet），以优化成本和速度
**工作流：并行化（图四）
LLM有时可以同时处理任务，并通过程序化方式汇总它们的输出。这种工作流，即并行化，主要有两种关键变体：
- 分段：将任务分解为并行运行的独立子任务
- 投票：多次运行相同任务以获得多样化的输出
***何时使用这种工作流
当划分的子任务可以并行化以提高速度，或者需要多个视角或尝试来获得更高置信度的结果时，并行化是有效的。对于具有多个考虑因素的复杂任务，当每个考虑因素由单独的LLM调用处理时，LLM通常表现更好，因为这允许专注于每个特定方面。
并行化的有用示例：
分段：
- 实现防护措施，其中一个模型实例处理用户查询，而另一个筛查不当内容或请求。这通常比让同一个LLM调用同时处理防护和核心响应表现更好
- 自动化评估以评估LLM性能，其中每个LLM调用评估模型在给定提示上的不同方面表现
投票：
- 审查代码中的漏洞，多个不同的提示审查并在发现问题时标记代码
- 评估给定内容是否不当，多个提示评估不同方面或要求不同的投票阈值来平衡假阳性和假阴性
**工作流：编排者-工作者（图五）
在编排者-工作者工作流中，中央LLM动态分解任务，将其委派给工作者LLM，并综合他们的结果。
***何时使用这种工作流
这种工作流非常适合那些无法预测所需子任务的复杂任务（例如，在编码中，需要更改的文件数量和每个文件中更改的性质可能取决于任务）。虽然在拓扑上与并行化相似，但关键区别在于其灵活性——子任务不是预定义的，而是由编排者根据具体输入确定的。
编排者-工作者的有用示例：
- 每次都需要对多个文件进行复杂更改的编码产品
- 涉及从多个来源收集和分析信息以寻找可能相关信息的搜索任务
**工作流：评估者-优化者（图六）
在评估者-优化者工作流中，一个LLM调用生成响应，而另一个在循环中提供评估和反馈。
***何时使用这种工作流
当我们有明确的评估标准，且迭代改进能提供可衡量的价值时，这种工作流特别有效。好的适配有两个标志：首先，当人类表达他们的反馈时，LLM响应可以得到明显改善；其次，LLM能够提供这样的反馈。这类似于人类作者在制作精良文档时可能经历的迭代写作过程。
评估者-优化者的有用示例：
- 文学翻译，其中存在翻译LLM最初可能无法捕捉的细微差别，但评估者LLM可以提供有用的批评
- 复杂的搜索任务，需要多轮搜索和分析才能收集全面信息，评估者决定是否需要进一步搜索
**代理（图七）
随着LLM在关键能力上的成熟——理解复杂输入、进行推理和规划、可靠使用工具，以及从错误中恢复——代理正在生产中兴起。代理通过来自人类用户的命令或交互式讨论开始工作。一旦任务明确，代理就会独立规划和运作，可能会返回给人类寻求进一步信息或判断。在执行过程中，代理必须在每一步从环境中获得"基本事实"（如工具调用结果或代码执行）来评估其进展。然后，代理可以在检查点或遇到阻碍时暂停以获取人类反馈。任务通常在完成时终止，但也常包括停止条件（如最大迭代次数）以保持控制。
代理可以处理复杂任务，但它们的实现通常很简单。它们通常只是基于环境反馈在循环中使用工具的LLM。因此，清晰和细致地设计工具集及其文档至关重要。我们在附录2（"工具的提示工程"）中详细介绍了工具开发的最佳实践。
***何时使用代理
代理可用于难以或无法预测所需步骤数量的开放性问题，以及无法硬编码固定路径的情况。LLM可能会运行多轮，你必须对其决策有一定程度的信任。代理的自主性使其非常适合在受信任环境中扩展任务。
代理的自主性意味着更高的成本，以及可能出现的累积错误。我们建议在沙盒环境中进行广泛测试，并配备适当的防护措施。
代理的有用示例：（图八）
以下示例来自我们自己的实现：
- 用于解决SWE-bench任务的编码代理，这些任务涉及根据任务描述对多个文件进行编辑
- 我们的"计算机使用"参考实现，其中Claude使用计算机完成任务
*组合和定制这些模式
这些构建模块并非规定性的。它们是开发者可以根据不同用例塑造和组合的常见模式。与任何LLM功能一样，成功的关键在于衡量性能并迭代实现。再次强调：只有在明显改善结果时才考虑增加复杂性。
*总结
在LLM领域取得成功并不是要构建最复杂的系统，而是要构建满足你需求的正确系统。从简单的提示开始，通过全面评估优化它们，只有在更简单的解决方案无法满足需求时才添加多步骤代理系统。
在实现代理时，我们尽量遵循三个核心原则：
1. 保持代理设计的简单性
2. 通过明确展示代理的规划步骤来优先考虑透明度
3. 通过详细的工具文档和测试来精心设计代理-计算机接口（ACI）
框架可以帮助你快速入门，但在转向生产时不要犹豫减少抽象层并使用基本组件构建。通过遵循这些原则，你可以创建不仅强大而且可靠、可维护，并能赢得用户信任的代理。
如果要选一个技术领域，作为明年大模型应用的主流方向，那么一定是Agent。这个词国内翻译为代理，或者智能体。
Anthropic几天前就发布了一篇博客文章，谈了一下他们的Agent方法论，转发一下。
原文传送门：www.anthropic.com/research/building-effective-agents
***
构建有效的智能代理
12月20日
在过去的一年里，我们与数十个跨行业的团队合作构建大语言模型(LLM)代理。我们一致发现，最成功的实现并非使用复杂的框架或专门的库，而是采用简单、可组合的模式进行构建。
在这篇文章中，我们分享了与客户合作和自主构建代理的经验，并为开发者提供构建有效代理的实用建议。
*什么是代理？
"代理"可以有多种定义。一些客户将代理定义为能够长期独立运行的完全自主系统，使用各种工具来完成复杂任务。另一些则用这个术语描述更具规范性的实现，即遵循预定义工作流程的系统。在Anthropic，我们将所有这些变体都归类为代理系统，但在工作流和代理之间做出了重要的架构区分：
- 工作流是通过预定义的代码路径来编排LLM和工具的系统。
- 代理则是LLM能够动态指导自己的流程和工具使用的系统，可以自主控制如何完成任务。
下文我们将详细探讨这两种代理系统。在附录1（"实践中的代理"）中，我们描述了两个客户在使用这些系统时发现特别有价值的领域。
*何时（以及何时不）使用代理
在构建LLM应用时，我们建议寻找最简单的解决方案，只在必要时增加复杂性。这可能意味着完全不构建代理系统。代理系统通常会用延迟和成本来换取更好的任务表现，你需要考虑这种权衡是否合理。
当需要更多复杂性时，工作流为明确定义的任务提供可预测性和一致性，而代理则在需要大规模灵活性和模型驱动决策时更为适合。然而，对于许多应用来说，通过检索和上下文示例来优化单个LLM调用通常就足够了。
*何时以及如何使用框架
有许多框架可以让代理系统的实现变得更容易，包括：
- LangChain的LangGraph
- 亚马逊Bedrock的AI Agent框架
- Rivet，一个拖放式GUI LLM工作流构建器
- Vellum，另一个用于构建和测试复杂工作流的GUI工具
这些框架通过简化标准的底层任务（如调用LLM、定义和解析工具、链接调用等）使入门变得容易。但是，它们往往会创建额外的抽象层，使底层提示和响应变得更难调试。它们也可能诱使开发者在更简单的设置就足够的情况下增加复杂性。
我们建议开发者从直接使用LLM API开始：许多模式可以用几行代码实现。如果你确实使用框架，请确保理解底层代码。对底层内容的错误假设是客户常见的错误来源。
*构建模块、工作流和代理
在本节中，我们将探讨我们在生产中看到的代理系统常见模式。我们将从基础构建模块——增强型LLM开始，逐步增加复杂性，从简单的组合工作流到自主代理。
**构建模块：增强型LLM（图一）
代理系统的基本构建模块是经过检索、工具和记忆等功能增强的LLM。我们当前的模型可以主动使用这些功能——生成自己的搜索查询、选择适当的工具，并确定要保留什么信息。
我们建议关注实现的两个关键方面：
1. 将这些功能定制化以适应你的特定用例
2. 确保它们为LLM提供易用、文档完善的接口
虽然有许多方法可以实现这些增强功能，但一种方法是通过我们最近发布的模型上下文协议（Model Context Protocol），它允许开发者通过简单的客户端实现与不断增长的第三方工具生态系统集成。
在本文的其余部分，我们假设每个LLM调用都可以访问这些增强功能。
**工作流：提示链式处理（图二）
提示链式处理将任务分解为一系列步骤，其中每个LLM调用处理前一个调用的输出。你可以在任何中间步骤添加程序化检查（见下图中的"gate"），以确保流程仍在正轨上。
***何时使用这种工作流
这种工作流最适合那些可以轻松且清晰地分解为固定子任务的情况。主要目标是通过使每个LLM调用成为更简单的任务来用延迟换取更高的准确性。
提示链式处理的有用示例：
- 生成营销文案，然后将其翻译成不同语言
- 写一份文档大纲，检查大纲是否满足特定标准，然后基于大纲写文档
**工作流：路由（图三）
路由对输入进行分类并将其导向专门的后续任务。这种工作流允许关注点分离，并构建更专门化的提示。如果没有这种工作流，为一种输入优化可能会损害其他输入的性能。
***何时使用这种工作流
路由适用于复杂任务，其中有不同的类别最好分开处理，且分类可以由LLM或更传统的分类模型/算法准确处理。
路由的有用示例：
- 将不同类型的客户服务查询（一般问题、退款请求、技术支持）导向不同的下游流程、提示和工具
- 将简单/常见问题路由到较小的模型（如Claude 3.5 Haiku），将困难/不寻常的问题路由到更强大的模型（如Claude 3.5 Sonnet），以优化成本和速度
**工作流：并行化（图四）
LLM有时可以同时处理任务，并通过程序化方式汇总它们的输出。这种工作流，即并行化，主要有两种关键变体：
- 分段：将任务分解为并行运行的独立子任务
- 投票：多次运行相同任务以获得多样化的输出
***何时使用这种工作流
当划分的子任务可以并行化以提高速度，或者需要多个视角或尝试来获得更高置信度的结果时，并行化是有效的。对于具有多个考虑因素的复杂任务，当每个考虑因素由单独的LLM调用处理时，LLM通常表现更好，因为这允许专注于每个特定方面。
并行化的有用示例：
分段：
- 实现防护措施，其中一个模型实例处理用户查询，而另一个筛查不当内容或请求。这通常比让同一个LLM调用同时处理防护和核心响应表现更好
- 自动化评估以评估LLM性能，其中每个LLM调用评估模型在给定提示上的不同方面表现
投票：
- 审查代码中的漏洞，多个不同的提示审查并在发现问题时标记代码
- 评估给定内容是否不当，多个提示评估不同方面或要求不同的投票阈值来平衡假阳性和假阴性
**工作流：编排者-工作者（图五）
在编排者-工作者工作流中，中央LLM动态分解任务，将其委派给工作者LLM，并综合他们的结果。
***何时使用这种工作流
这种工作流非常适合那些无法预测所需子任务的复杂任务（例如，在编码中，需要更改的文件数量和每个文件中更改的性质可能取决于任务）。虽然在拓扑上与并行化相似，但关键区别在于其灵活性——子任务不是预定义的，而是由编排者根据具体输入确定的。
编排者-工作者的有用示例：
- 每次都需要对多个文件进行复杂更改的编码产品
- 涉及从多个来源收集和分析信息以寻找可能相关信息的搜索任务
**工作流：评估者-优化者（图六）
在评估者-优化者工作流中，一个LLM调用生成响应，而另一个在循环中提供评估和反馈。
***何时使用这种工作流
当我们有明确的评估标准，且迭代改进能提供可衡量的价值时，这种工作流特别有效。好的适配有两个标志：首先，当人类表达他们的反馈时，LLM响应可以得到明显改善；其次，LLM能够提供这样的反馈。这类似于人类作者在制作精良文档时可能经历的迭代写作过程。
评估者-优化者的有用示例：
- 文学翻译，其中存在翻译LLM最初可能无法捕捉的细微差别，但评估者LLM可以提供有用的批评
- 复杂的搜索任务，需要多轮搜索和分析才能收集全面信息，评估者决定是否需要进一步搜索
**代理（图七）
随着LLM在关键能力上的成熟——理解复杂输入、进行推理和规划、可靠使用工具，以及从错误中恢复——代理正在生产中兴起。代理通过来自人类用户的命令或交互式讨论开始工作。一旦任务明确，代理就会独立规划和运作，可能会返回给人类寻求进一步信息或判断。在执行过程中，代理必须在每一步从环境中获得"基本事实"（如工具调用结果或代码执行）来评估其进展。然后，代理可以在检查点或遇到阻碍时暂停以获取人类反馈。任务通常在完成时终止，但也常包括停止条件（如最大迭代次数）以保持控制。
代理可以处理复杂任务，但它们的实现通常很简单。它们通常只是基于环境反馈在循环中使用工具的LLM。因此，清晰和细致地设计工具集及其文档至关重要。我们在附录2（"工具的提示工程"）中详细介绍了工具开发的最佳实践。
***何时使用代理
代理可用于难以或无法预测所需步骤数量的开放性问题，以及无法硬编码固定路径的情况。LLM可能会运行多轮，你必须对其决策有一定程度的信任。代理的自主性使其非常适合在受信任环境中扩展任务。
代理的自主性意味着更高的成本，以及可能出现的累积错误。我们建议在沙盒环境中进行广泛测试，并配备适当的防护措施。
代理的有用示例：（图八）
以下示例来自我们自己的实现：
- 用于解决SWE-bench任务的编码代理，这些任务涉及根据任务描述对多个文件进行编辑
- 我们的"计算机使用"参考实现，其中Claude使用计算机完成任务
*组合和定制这些模式
这些构建模块并非规定性的。它们是开发者可以根据不同用例塑造和组合的常见模式。与任何LLM功能一样，成功的关键在于衡量性能并迭代实现。再次强调：只有在明显改善结果时才考虑增加复杂性。
*总结
在LLM领域取得成功并不是要构建最复杂的系统，而是要构建满足你需求的正确系统。从简单的提示开始，通过全面评估优化它们，只有在更简单的解决方案无法满足需求时才添加多步骤代理系统。
在实现代理时，我们尽量遵循三个核心原则：
1. 保持代理设计的简单性
2. 通过明确展示代理的规划步骤来优先考虑透明度
3. 通过详细的工具文档和测试来精心设计代理-计算机接口（ACI）
框架可以帮助你快速入门，但在转向生产时不要犹豫减少抽象层并使用基本组件构建。通过遵循这些原则，你可以创建不仅强大而且可靠、可维护，并能赢得用户信任的代理。
