如何构建高效的智能体
Anthropic 刚刚发布了一份关于“如何构建高效智能体”的精彩指南，现翻译出来，以飨读者。
在过去的一年里，我们与来自各行各业、致力于构建大语言模型 (LLM) AI 智能体的数十个团队合作。我们发现，最成功的应用往往并未使用复杂的框架或专业库，而是采用了一些简单且可组合的模式来构建系统。
在本文中，我们将分享与客户合作并亲自构建 AI 智能体时所获得的经验，并为开发者提供构建高效 AI 智能体的实用建议。
什么是智能体？
“智能体”（Agent）的定义有多种。有些客户将其定义为可以长时间独立运行、使用各种工具来完成复杂任务的完全自主系统；另一些则将其描述为遵循预先定义工作流、较具指导性的实现方式。Anthropic 将这些不同形式都归类为智能体系统 (agentic systems)，但在架构上，我们强调区分工作流 (workflows)与智能体 (agents)：
- • 工作流指的是通过预定义的代码路径对大语言模型和工具进行编排的系统。
- • 智能体则是通过大语言模型来自主决定工作流程和使用工具的方式，并掌控完成任务的路径。
接下来，我们会详细介绍这两种智能体系统。在附录 1（“智能体的实际案例”）中，我们还会展示客户在特定领域中如何利用这些系统获得显著价值。
使用智能体的场景
当构建基于大语言模型的应用时，我们建议先从最简单的解决方案开始，只有在确有需要时，才增加复杂性。这可能意味着完全不使用智能体系统。因为智能体系统通常需要在延迟和成本之间进行权衡，以换取更好的任务性能，必须评估这是否是可以接受的取舍。
如果有必要增加复杂性，那么工作流在可预见、可定义的任务中提供了更强的可预测性和一致性，而当需要在大规模环境中进行更灵活的模型驱动决策时，智能体则更为适用。但对许多应用而言，仅使用带检索和上下文示例的单次大语言模型调用，通常已经足够。
何时以及如何使用框架
目前市面上有许多框架可以简化智能体系统的实现，例如：
- • LangChain 的 LangGraph；
- • Amazon Bedrock 的 AI Agent 框架；
- • Rivet，一款可视化拖拽式的大语言模型工作流搭建工具；
- • 以及 Vellum，另一款搭建并测试复杂工作流的可视化工具。
这些框架让构建变得更简单，能够快速完成对大语言模型的调用、定义和解析工具以及链式调用等标准化底层任务。但是，它们常常额外引入抽象层，可能会遮蔽底层的提示词和响应，从而使调试难度加大。它们也可能诱使开发者增加不必要的复杂性，而实际上更简单的方案就足以应对需求。
因此，我们建议开发者从直接调用大语言模型 API 入手：许多常见模式都能通过几行代码实现。如果确实要使用某个框架，一定要理解其底层原理。对底层机制的误解是用户在使用中经常遇到的问题。
若要获取更多示例，请参阅我们的示例代码库 (cookbook)。
基础构件、工作流与智能体
在本节中，我们将探讨在实际生产环境中常见的智能体系统模式。从最基础的构件——增强型大语言模型 (LLM)——开始，逐步增加复杂度，从简单的组合式工作流一路拓展到自主智能体。
基础构件：增强型大语言模型
智能体系统的基础构件是经过增强的大语言模型 (LLM)，为其配备检索、工具和记忆等功能。我们当前的模型可以主动使用这些能力——自行生成搜索查询、选择合适的工具并确定要保留的信息。
the augmented LLM
在实际应用中，建议把握两个关键点：首先，要将这些功能与特定用例相结合；其次，要提供一个易用且文档完善的接口给大语言模型使用。实现这些增强功能的方法不止一种，我们近期发布的 Model Context Protocol 就是其中一种方案，通过一个简单的客户端实现，开发者即可对接不断壮大的第三方工具生态系统。
在本文剩余部分，我们默认每次调用大语言模型时，都能使用这些增强功能。
工作流：链式提示词
链式提示词将一个任务分解为一系列步骤，每次大语言模型调用会处理上一步的输出。可以在任何中间步骤加入编程层面的检查（在下图中称为“gate”），以确保流程依然走在正确轨道上。
the prompt chaining workflow
适用场景： 这种工作流非常适合能够被轻松拆解为固定子任务的情形。其主要目标是用多次调用大语言模型来换取更高的准确度，每次调用只需处理相对简单的任务，从而在延迟和准确度之间寻求平衡。
示例：
- • 先生成营销文案，再将其翻译成另一种语言；
- • 先写出一篇文档的大纲，检查该大纲是否满足特定标准，然后再根据该大纲撰写正文。
工作流：路由式
通过对输入进行分类，将其引导至对应的后续任务。此工作流能够实现关注点分离，并为不同类别分别构建更具针对性的提示词。若不进行路由，为某类输入做的优化可能会影响对其他输入的处理效果。
the routing workflow
适用场景： 路由适用于复杂任务，这些任务可分为不同类别，并且每个类别都能更准确地分别处理。对于分类本身，可以使用大语言模型或传统的分类模型/算法。
示例：
- • 针对不同类型的客服请求（如一般性问题、退款请求、技术支持）分别使用不同的处理流程、提示词和工具；
- • 将简单/常见的问题路由到较小的模型（例如 Claude 3.5 Haiku），而将困难/非常规的问题路由到更强大的模型（如 Claude 3.5 Sonnet），以兼顾成本与速度。
工作流：并行式
在某些场景下，大语言模型可以同时处理一个任务，并通过程序方式整合它们的输出。并行式工作流主要分为两种形式：
- • 分块（Sectioning）：将一个任务拆分为若干互不影响的子任务，并行完成；
- • 投票（Voting）：多次运行同一个任务，从而获取多样化的输出。
the parallelization workflow
适用场景： 当子任务可以并行执行以加快速度，或需要多种观点或多次尝试来获得高置信度的结果时，并行化会非常有效。对于带有多重考量的复杂任务，大语言模型通常在分别处理每个考量点时表现更好，因为这让每次调用专注于特定方面。
示例：
- • 分块（Sectioning）：
- • 实现防护机制，一台模型实例负责处理用户查询，另一台则负责审查是否存在不当内容或请求。这通常比让同一个调用同时处理防护及核心响应更有效；
- • 自动进行评测 (eval) 用来评估大语言模型性能，每一次模型调用分别负责评估在给定提示词上模型表现的不同方面。
- • 投票（Voting）：
- • 在审查代码是否存在漏洞时，使用多个不同的提示词多次检查代码，一旦发现问题就会标记；
- • 判断某段内容是否不当时，让多个提示词分别评估不同方面或使用不同的投票阈值，平衡误判和漏判的风险。
工作流：协调者-执行者 (Orchestrator-workers)
在协调者-工作者工作流中，由一个中心的大语言模型动态地拆解任务，将子任务分配给各个执行者模型，并整合它们的结果。
the orchestrator-workers workflow
适用场景： 此工作流非常适合那些无法预先预测需要哪些子任务的复杂场景。例如，在写代码时需要修改多少文件、每个文件需要做哪些改动，都取决于具体的任务。虽然此模式在结构上看似与并行化相似，但其关键区别在于灵活性——子任务不是预先定义的，而是由协调者根据实际输入动态生成。
示例：
- • 面向编程产品的功能，每次都可能对多个文件进行复杂修改；
- • 涉及搜索与分析多个来源信息并筛选可用信息的搜索类任务。
工作流：评估者-优化者 (Evaluator-optimizer)
在评估者-优化者工作流中，一个大语言模型先生成初步输出，另一个大语言模型对该输出进行循环式评估和反馈。
the evaluator-optimizer workflow
适用场景： 如果我们有明确的评估标准，并且多次迭代确能带来可量化的提升，这种工作流特别有效。适合此方式的两个标志是：其一，在有人提供明确反馈时，大语言模型的输出可显著提升；其二，大语言模型本身也能生成有价值的反馈。这与人类作者多次修改文稿，逐渐完善的过程类似。
示例：
- • 文学翻译：首次翻译可能忽略了一些细微之处，而评估者模型可给出有益的批评与建议；
- • 复杂的搜索任务，需要多轮搜索和分析来收集完整信息，此时评估者可决定是否继续执行更多搜索。
智能体 (Agents)
随着大语言模型在理解复杂输入、推理和规划、可靠使用工具以及从错误中恢复等能力上的成熟，智能体在生产环境中开始崭露头角。智能体通常从用户的指令或互动对话开始工作，一旦任务明确，就会自主规划与执行任务，必要时向用户寻求更多信息或判断。在任务执行过程中，智能体需要获取每一步的“真实信息”（例如工具调用的结果或代码执行的结果）来判断进度。智能体也可以在遇到阻碍或需要人工确认时暂停，等待用户反馈。任务完成时通常结束整个流程，但也可以设置停止条件（如限制迭代次数）来控制风险。
智能体能够应对复杂任务，但其实现往往并不复杂——通常只是在循环中根据环境反馈不断调用大语言模型并使用工具。因此，如何精心设计和记录各类工具显得至关重要。在附录 2（“为工具进行提示词工程”）中，我们会进一步探讨工具开发的最佳实践。
Autonomous agent
何时使用智能体： 当问题本身是开放式的，或无法提前确定需要多少步骤、何种具体路径时，就可以考虑使用智能体。大语言模型在此过程中可能会进行多次迭代，所以你需要对其决策能力有一定信任度。在受信任的环境中，智能体非常适合扩展任务规模。
同时，智能体的自主性意味着更高的成本，也存在错误逐步放大的可能。我们建议在沙盒环境中进行大量测试，并配合适当的防护措施。
示例：
以下是我们在内部实现中的示例：
- • 用于解决 SWE-bench 任务 的代码智能体：基于任务描述对多个文件进行编辑；
- • “计算机使用”演示：Claude 通过使用计算机来完成指定任务。
High-level flow of coding agent
组合与自定义这些模式
这些构建块并非绝对标准，只是为开发者提供常见的参考模式，以适配不同的用例。与所有大语言模型功能一样，衡量性能并不断迭代非常关键。再次强调：只有当增加复杂度能够“确实”带来效果提升时才这么做。
总结
在大语言模型领域，成功并不意味着构建出最复杂的系统，而是要搭建出最“恰当”的系统。先从简单的提示词入手，用充分的评测优化提示词，仅当简单方案无法满足需求时，再考虑多步骤的智能体系统。
在构建智能体时，我们倾向于遵循以下三大核心原则：
- 1. 保持设计上的简洁性；
- 2. 强调透明度，在显式的规划步骤中展现智能体的思考过程；
- 3. 谨慎打造智能体-计算机接口 (ACI)，在工具的文档与测试上下足功夫。
框架确实能帮助开发者快速开始，但在部署到生产环境时，也不要忽视将抽象层降到最低、直接使用基础组件的方法。遵循这些原则，可以构建既高效又可靠、维护成本更低、并且广受用户信赖的智能体。
致谢
本文由 Erik Schluntz 和 Barry Zhang 撰写，内容主要来自我们在 Anthropic 构建智能体的实践经验，以及我们客户分享的宝贵见解，我们对此深表感谢。
附录 1：智能体在实践中的应用
我们与客户合作的过程中，发现了两个最具前景的 AI 智能体应用领域，可以很好地展示上文介绍的各种模式所带来的实际价值。这两个应用都体现了：当任务需要兼具对话和执行、有明确的成功指标、允许反馈循环并可结合有效的人为监督时，智能体能带来最大价值。
A. 客服场景
客服工作天然地结合了熟悉的聊天机器人界面和通过工具整合而实现的高级能力。这对于更开放式的智能体而言非常适合，原因包括：
- • 客户支持的互动通常是对话式的，并需要访问外部信息与执行某些操作；
- • 可将工具接入以检索客户数据、订单历史和知识库文档；
- • 像退费或更新工单此类动作都可通过程序方式完成；
- • 成功可以通过用户定义的解决方案是否达成来加以明确衡量。
多家企业已经证明了这种方案的可行性，采用按使用量付费的模式，只对成功解决问题的案例进行收费，从而展现了对其智能体效果的信心。
B. 软件开发智能体
软件开发领域在大语言模型功能上展现了极大潜能，其能力从代码补全逐渐发展到自主解决问题。智能体在此方面尤其有效，主要因为：
- • 代码解决方案可以通过自动化测试进行验证；
- • 智能体可利用测试结果进行多次迭代；
- • 问题域清晰明了且结构化；
- • 输出质量具有客观评估方式。
在我们的实际实现中，智能体已能够基于拉取请求描述，直接完成 SWE-bench Verified 基准上的真实 GitHub 问题。尽管自动化测试能够帮忙验证功能性，但要确保解决方案符合更广泛的系统需求，人工审查仍然至关重要。
附录 2：为工具做提示词工程
无论你正在构建哪种类型的智能体系统，工具都可能在智能体中扮演重要角色。工具 (Tools) 允许 Claude 通过在我们的 API 中明确工具的结构和定义，与外部服务和 API 交互。若 Claude 打算调用某个工具，就会在返回的 API 响应中包含一个工具调用区块 (tool use block)。工具的定义和规格与整体提示词同样需要精心设计。在这份简短的附录中，我们将介绍如何对你的工具进行提示词工程。
实现同一操作的方法往往不止一种。例如，可以通过写“diff”或者重写整个文件来指定文件编辑。对于结构化输出，你既可以在 Markdown 中返回代码，也可以返回 JSON。在软件工程里，这些差异本质上只是格式问题，可以在不同格式之间无损转换。然而，对于大语言模型而言，某些格式比其他格式更难输出。写 diff 的过程需要先知道将要改动的行数才能正确编写分段信息；而在 JSON 中编写代码（对比 Markdown），则需要对换行和引号进行额外的转义。
以下几点可帮助你决定工具输出格式：
- • 为模型留出足够的 Token，以便它在写出最终结果前能有思考余地，避免“写进死胡同”；
- • 保持格式尽量贴近模型在互联网上通常看到的自然形式；
- • 确保没有多余的格式负担，比如不用统计数千行代码的行号，或大规模地转义任何输出内容。
一个可行的准则是：就像人机交互 (HCI) 需要大量精力那样，为“智能体-计算机接口 (ACI)”投入的精力也应同等重要。以下是一些建议：
- • 站在模型的角度思考。根据工具描述和参数，使用这个工具是否一目了然？是否需要反复琢磨？如果是这样，那么模型也很可能需要反复琢磨。一个好的工具定义通常包括示例用法、边界情况、输入格式要求以及与其他工具的清晰区分。
- • 你能否修改参数名称或描述，使其更直观？就像为团队中一名初级开发者写优秀的文档一样。当你使用多个类似的工具时，这一点尤其重要。
- • 测试模型对你的工具的使用情况：在我们的工作台 (workbench)上用大量示例输入试跑，看它会犯哪些错误，然后不断迭代完善。
- • 通过poka-yoke思想来优化工具设计：更改参数以尽可能避免误用。
我们在为 SWE-bench 构建智能体时，实际上花在优化工具上的时间比优化整体提示词还要多。比如，我们发现当智能体离开根目录后，会在使用相对路径的工具时出现错误。为了解决这个问题，我们将工具改为只接受绝对路径，结果模型完全没再出错。
# 如何构建高效的智能体
> Anthropic 刚刚发布了一份关于“如何构建高效智能体”的精彩指南，现翻译出来，以飨读者。
在过去的一年里，我们与来自各行各业、致力于构建大语言模型 (LLM) AI 智能体的数十个团队合作。我们发现，最成功的应用往往并未使用复杂的框架或专业库，而是采用了一些简单且可组合的模式来构建系统。
在本文中，我们将分享与客户合作并亲自构建 AI 智能体时所获得的经验，并为开发者提供构建高效 AI 智能体的实用建议。
## 什么是智能体？
“智能体”（Agent）的定义有多种。有些客户将其定义为可以长时间独立运行、使用各种工具来完成复杂任务的完全自主系统；另一些则将其描述为遵循预先定义工作流、较具指导性的实现方式。Anthropic 将这些不同形式都归类为**智能体系统 (agentic systems)**，但在架构上，我们强调区分**工作流 (workflows)**与**智能体 (agents)**：
- **工作流**指的是通过预定义的代码路径对大语言模型和工具进行编排的系统。- **智能体**则是通过大语言模型来自主决定工作流程和使用工具的方式，并掌控完成任务的路径。
接下来，我们会详细介绍这两种智能体系统。在附录 1（“智能体的实际案例”）中，我们还会展示客户在特定领域中如何利用这些系统获得显著价值。
## 使用智能体的场景
当构建基于大语言模型的应用时，我们建议先从最简单的解决方案开始，只有在确有需要时，才增加复杂性。这可能意味着完全不使用智能体系统。因为智能体系统通常需要在延迟和成本之间进行权衡，以换取更好的任务性能，必须评估这是否是可以接受的取舍。
如果有必要增加复杂性，那么工作流在可预见、可定义的任务中提供了更强的可预测性和一致性，而当需要在大规模环境中进行更灵活的模型驱动决策时，智能体则更为适用。但对许多应用而言，仅使用带检索和上下文示例的单次大语言模型调用，通常已经足够。
## 何时以及如何使用框架
目前市面上有许多框架可以简化智能体系统的实现，例如：
- LangChain 的 [LangGraph](https://langchain-ai.github.io/langgraph/)；- Amazon Bedrock 的 [AI Agent 框架](https://aws.amazon.com/bedrock/agents/)；- [Rivet](https://rivet.ironcladapp.com/)，一款可视化拖拽式的大语言模型工作流搭建工具；- 以及 [Vellum](https://www.vellum.ai/)，另一款搭建并测试复杂工作流的可视化工具。
这些框架让构建变得更简单，能够快速完成对大语言模型的调用、定义和解析工具以及链式调用等标准化底层任务。但是，它们常常额外引入抽象层，可能会遮蔽底层的提示词和响应，从而使调试难度加大。它们也可能诱使开发者增加不必要的复杂性，而实际上更简单的方案就足以应对需求。
因此，我们建议开发者从直接调用大语言模型 API 入手：许多常见模式都能通过几行代码实现。如果确实要使用某个框架，一定要理解其底层原理。对底层机制的误解是用户在使用中经常遇到的问题。
若要获取更多示例，请参阅我们的[示例代码库 (cookbook)](https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents)。
## 基础构件、工作流与智能体
在本节中，我们将探讨在实际生产环境中常见的智能体系统模式。从最基础的构件——增强型大语言模型 (LLM)——开始，逐步增加复杂度，从简单的组合式工作流一路拓展到自主智能体。
### 基础构件：增强型大语言模型
智能体系统的基础构件是经过增强的大语言模型 (LLM)，为其配备检索、工具和记忆等功能。我们当前的模型可以主动使用这些能力——自行生成搜索查询、选择合适的工具并确定要保留的信息。
在实际应用中，建议把握两个关键点：首先，要将这些功能与特定用例相结合；其次，要提供一个易用且文档完善的接口给大语言模型使用。实现这些增强功能的方法不止一种，我们近期发布的 [Model Context Protocol](https://www.anthropic.com/news/model-context-protocol) 就是其中一种方案，通过一个简单的[客户端实现](https://modelcontextprotocol.io/tutorials/building-a-client#building-mcp-clients)，开发者即可对接不断壮大的第三方工具生态系统。
在本文剩余部分，我们默认每次调用大语言模型时，都能使用这些增强功能。
### 工作流：链式提示词
链式提示词将一个任务分解为一系列步骤，每次大语言模型调用会处理上一步的输出。可以在任何中间步骤加入编程层面的检查（在下图中称为“gate”），以确保流程依然走在正确轨道上。
**适用场景：** 这种工作流非常适合能够被轻松拆解为固定子任务的情形。其主要目标是用多次调用大语言模型来换取更高的准确度，每次调用只需处理相对简单的任务，从而在延迟和准确度之间寻求平衡。
**示例：**
- 先生成营销文案，再将其翻译成另一种语言；- 先写出一篇文档的大纲，检查该大纲是否满足特定标准，然后再根据该大纲撰写正文。
### 工作流：路由式
通过对输入进行分类，将其引导至对应的后续任务。此工作流能够实现关注点分离，并为不同类别分别构建更具针对性的提示词。若不进行路由，为某类输入做的优化可能会影响对其他输入的处理效果。
**适用场景：** 路由适用于复杂任务，这些任务可分为不同类别，并且每个类别都能更准确地分别处理。对于分类本身，可以使用大语言模型或传统的分类模型/算法。
**示例：**
- 针对不同类型的客服请求（如一般性问题、退款请求、技术支持）分别使用不同的处理流程、提示词和工具；- 将简单/常见的问题路由到较小的模型（例如 Claude 3.5 Haiku），而将困难/非常规的问题路由到更强大的模型（如 Claude 3.5 Sonnet），以兼顾成本与速度。
### 工作流：并行式
在某些场景下，大语言模型可以同时处理一个任务，并通过程序方式整合它们的输出。并行式工作流主要分为两种形式：
- **分块（Sectioning）**：将一个任务拆分为若干互不影响的子任务，并行完成；- **投票（Voting）**：多次运行同一个任务，从而获取多样化的输出。
**适用场景：** 当子任务可以并行执行以加快速度，或需要多种观点或多次尝试来获得高置信度的结果时，并行化会非常有效。对于带有多重考量的复杂任务，大语言模型通常在分别处理每个考量点时表现更好，因为这让每次调用专注于特定方面。
**示例：**
- **分块（Sectioning）**： - 实现防护机制，一台模型实例负责处理用户查询，另一台则负责审查是否存在不当内容或请求。这通常比让同一个调用同时处理防护及核心响应更有效； - 自动进行评测 (eval) 用来评估大语言模型性能，每一次模型调用分别负责评估在给定提示词上模型表现的不同方面。- **投票（Voting）**： - 在审查代码是否存在漏洞时，使用多个不同的提示词多次检查代码，一旦发现问题就会标记； - 判断某段内容是否不当时，让多个提示词分别评估不同方面或使用不同的投票阈值，平衡误判和漏判的风险。
### 工作流：协调者-执行者 (Orchestrator-workers)
在协调者-工作者工作流中，由一个中心的大语言模型动态地拆解任务，将子任务分配给各个执行者模型，并整合它们的结果。
**适用场景：** 此工作流非常适合那些无法预先预测需要哪些子任务的复杂场景。例如，在写代码时需要修改多少文件、每个文件需要做哪些改动，都取决于具体的任务。虽然此模式在结构上看似与并行化相似，但其关键区别在于灵活性——子任务不是预先定义的，而是由协调者根据实际输入动态生成。
**示例：**
- 面向编程产品的功能，每次都可能对多个文件进行复杂修改；- 涉及搜索与分析多个来源信息并筛选可用信息的搜索类任务。
### 工作流：评估者-优化者 (Evaluator-optimizer)
在评估者-优化者工作流中，一个大语言模型先生成初步输出，另一个大语言模型对该输出进行循环式评估和反馈。
**适用场景：** 如果我们有明确的评估标准，并且多次迭代确能带来可量化的提升，这种工作流特别有效。适合此方式的两个标志是：其一，在有人提供明确反馈时，大语言模型的输出可显著提升；其二，大语言模型本身也能生成有价值的反馈。这与人类作者多次修改文稿，逐渐完善的过程类似。
**示例：**
- 文学翻译：首次翻译可能忽略了一些细微之处，而评估者模型可给出有益的批评与建议；- 复杂的搜索任务，需要多轮搜索和分析来收集完整信息，此时评估者可决定是否继续执行更多搜索。
### 智能体 (Agents)
随着大语言模型在理解复杂输入、推理和规划、可靠使用工具以及从错误中恢复等能力上的成熟，智能体在生产环境中开始崭露头角。智能体通常从用户的指令或互动对话开始工作，一旦任务明确，就会自主规划与执行任务，必要时向用户寻求更多信息或判断。在任务执行过程中，智能体需要获取每一步的“真实信息”（例如工具调用的结果或代码执行的结果）来判断进度。智能体也可以在遇到阻碍或需要人工确认时暂停，等待用户反馈。任务完成时通常结束整个流程，但也可以设置停止条件（如限制迭代次数）来控制风险。
智能体能够应对复杂任务，但其实现往往并不复杂——通常只是在循环中根据环境反馈不断调用大语言模型并使用工具。因此，如何精心设计和记录各类工具显得至关重要。在附录 2（“为工具进行提示词工程”）中，我们会进一步探讨工具开发的最佳实践。
**何时使用智能体：** 当问题本身是开放式的，或无法提前确定需要多少步骤、何种具体路径时，就可以考虑使用智能体。大语言模型在此过程中可能会进行多次迭代，所以你需要对其决策能力有一定信任度。在受信任的环境中，智能体非常适合扩展任务规模。
同时，智能体的自主性意味着更高的成本，也存在错误逐步放大的可能。我们建议在沙盒环境中进行大量测试，并配合适当的防护措施。
**示例：** 以下是我们在内部实现中的示例：
- 用于解决 [SWE\-bench 任务](https://www.anthropic.com/research/swe-bench-sonnet) 的代码智能体：基于任务描述对多个文件进行编辑；- [“计算机使用”演示](https://github.com/anthropics/anthropic-quickstarts/tree/main/computer-use-demo)：Claude 通过使用计算机来完成指定任务。
## 组合与自定义这些模式
这些构建块并非绝对标准，只是为开发者提供常见的参考模式，以适配不同的用例。与所有大语言模型功能一样，衡量性能并不断迭代非常关键。再次强调：只有当增加复杂度能够“确实”带来效果提升时才这么做。
## 总结
在大语言模型领域，成功并不意味着构建出最复杂的系统，而是要搭建出最“恰当”的系统。先从简单的提示词入手，用充分的评测优化提示词，仅当简单方案无法满足需求时，再考虑多步骤的智能体系统。
在构建智能体时，我们倾向于遵循以下三大核心原则：
1. 保持设计上的**简洁性**；2. 强调**透明度**，在显式的规划步骤中展现智能体的思考过程；3. 谨慎打造**智能体-计算机接口 (ACI)**，在工具的**文档与测试**上下足功夫。
框架确实能帮助开发者快速开始，但在部署到生产环境时，也不要忽视将抽象层降到最低、直接使用基础组件的方法。遵循这些原则，可以构建既高效又可靠、维护成本更低、并且广受用户信赖的智能体。
### 致谢
本文由 Erik Schluntz 和 Barry Zhang 撰写，内容主要来自我们在 Anthropic 构建智能体的实践经验，以及我们客户分享的宝贵见解，我们对此深表感谢。
## 附录 1：智能体在实践中的应用
我们与客户合作的过程中，发现了两个最具前景的 AI 智能体应用领域，可以很好地展示上文介绍的各种模式所带来的实际价值。这两个应用都体现了：当任务需要兼具对话和执行、有明确的成功指标、允许反馈循环并可结合有效的人为监督时，智能体能带来最大价值。
### A. 客服场景
客服工作天然地结合了熟悉的聊天机器人界面和通过工具整合而实现的高级能力。这对于更开放式的智能体而言非常适合，原因包括：
- 客户支持的互动通常是对话式的，并需要访问外部信息与执行某些操作；- 可将工具接入以检索客户数据、订单历史和知识库文档；- 像退费或更新工单此类动作都可通过程序方式完成；- 成功可以通过用户定义的解决方案是否达成来加以明确衡量。
多家企业已经证明了这种方案的可行性，采用按使用量付费的模式，只对成功解决问题的案例进行收费，从而展现了对其智能体效果的信心。
### B. 软件开发智能体
软件开发领域在大语言模型功能上展现了极大潜能，其能力从代码补全逐渐发展到自主解决问题。智能体在此方面尤其有效，主要因为：
- 代码解决方案可以通过自动化测试进行验证；- 智能体可利用测试结果进行多次迭代；- 问题域清晰明了且结构化；- 输出质量具有客观评估方式。
在我们的实际实现中，智能体已能够基于拉取请求描述，直接完成 [SWE\-bench Verified](https://www.anthropic.com/research/swe-bench-sonnet) 基准上的真实 GitHub 问题。尽管自动化测试能够帮忙验证功能性，但要确保解决方案符合更广泛的系统需求，人工审查仍然至关重要。
## 附录 2：为工具做提示词工程
无论你正在构建哪种类型的智能体系统，工具都可能在智能体中扮演重要角色。[工具 (Tools)](https://www.anthropic.com/news/tool-use-ga) 允许 Claude 通过在我们的 API 中明确工具的结构和定义，与外部服务和 API 交互。若 Claude 打算调用某个工具，就会在返回的 API 响应中包含一个[工具调用区块 (tool use block)](https://docs.anthropic.com/en/docs/build-with-claude/tool-use#example-api-response-with-a-tool-use-content-block)。工具的定义和规格与整体提示词同样需要精心设计。在这份简短的附录中，我们将介绍如何对你的工具进行提示词工程。
实现同一操作的方法往往不止一种。例如，可以通过写“diff”或者重写整个文件来指定文件编辑。对于结构化输出，你既可以在 Markdown 中返回代码，也可以返回 JSON。在软件工程里，这些差异本质上只是格式问题，可以在不同格式之间无损转换。然而，对于大语言模型而言，某些格式比其他格式更难输出。写 diff 的过程需要先知道将要改动的行数才能正确编写分段信息；而在 JSON 中编写代码（对比 Markdown），则需要对换行和引号进行额外的转义。
以下几点可帮助你决定工具输出格式：
- 为模型留出足够的 Token，以便它在写出最终结果前能有思考余地，避免“写进死胡同”；- 保持格式尽量贴近模型在互联网上通常看到的自然形式；- 确保没有多余的格式负担，比如不用统计数千行代码的行号，或大规模地转义任何输出内容。
一个可行的准则是：就像人机交互 (HCI) 需要大量精力那样，为“智能体-计算机接口 (ACI)”投入的精力也应同等重要。以下是一些建议：
- 站在模型的角度思考。根据工具描述和参数，使用这个工具是否一目了然？是否需要反复琢磨？如果是这样，那么模型也很可能需要反复琢磨。一个好的工具定义通常包括示例用法、边界情况、输入格式要求以及与其他工具的清晰区分。- 你能否修改参数名称或描述，使其更直观？就像为团队中一名初级开发者写优秀的文档一样。当你使用多个类似的工具时，这一点尤其重要。- 测试模型对你的工具的使用情况：在我们的[工作台 (workbench)](https://console.anthropic.com/workbench)上用大量示例输入试跑，看它会犯哪些错误，然后不断迭代完善。- 通过[poka\-yoke](https://en.wikipedia.org/wiki/Poka-yoke)思想来优化工具设计：更改参数以尽可能避免误用。
我们在为 [SWE\-bench](https://www.anthropic.com/research/swe-bench-sonnet) 构建智能体时，实际上花在优化工具上的时间比优化整体提示词还要多。比如，我们发现当智能体离开根目录后，会在使用相对路径的工具时出现错误。为了解决这个问题，我们将工具改为只接受绝对路径，结果模型完全没再出错。
