译者注

• • Agent 逐步崭露出应用落地的姿态，我们要做什么准备呢

• • 作为无数 AI 编程辅助工具背后的大功臣，claude 的爹 Anthropic 是咋想的呢？

• • Agent 离不开 Prompt，来看看 Prompt 是如何生长成 Agent 的

过去一年里，我们与多个行业的团队合作，共同构建基于大语言模型 (LLM) 的智能体 (Agents)。实践表明，最成功的案例并未依赖复杂的框架或专业库，而是采用了简单、可组合的模式。

本文将总结我们与客户合作以及自主构建智能体的经验，为开发者提供构建高效智能体的实用建议。

什么是智能体？

“智能体”的定义多种多样。一些客户将其定义为完全自主的系统，这些系统能够长时间独立运行，借助多种工具完成复杂任务。另一些客户则认为智能体是基于预定义工作流程的实现，更加具备指导性。在 Anthropic，我们将这些不同实现统称为 智能体系统 (Agentic Systems)，并在架构上强调 工作流程 (Workflows) 和 智能体 的关键区别：

• • 工作流程 是通过预先编写的代码路径，协调大语言模型和工具的运行。

• • 智能体 则是动态决策自身流程和工具使用方式的系统，能够灵活控制任务的完成方法。

接下来，我们将深入分析这两类智能体系统。在附录 1（“实践中的智能体”）中，我们还将介绍两个客户使用这些系统时发现特别有价值的领域。

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

在使用大语言模型 (LLM) 开发应用时，我们建议优先选择最简单的解决方案，仅在必要时增加复杂性。这也可能意味着不使用智能体系统。智能体系统通常以延迟和更高成本为代价，换取更优的任务表现，因此需要仔细权衡是否值得。

当任务需求更复杂时，工作流程 (Workflows) 适合执行定义明确的任务，因为它能提供稳定性和一致性；而当需要灵活性或依赖模型驱动的决策时，智能体则是更好的选择。然而，对于大多数应用，仅通过检索和上下文示例优化单次 LLM 调用通常已经足够。

何时以及如何使用框架

目前有许多框架可以简化智能体系统的开发，包括：

• • LangChain 提供的 LangGraph；

• • Amazon Bedrock 的 AI Agent framework；

• • Rivet，一个基于拖拽操作的 GUI 工作流程构建工具；以及

• • Vellum，另一款用于设计和测试复杂工作流程的 GUI 工具。

这些框架通过简化常见低层任务（如调用 LLM、定义工具以及组合调用）帮助开发者快速上手。然而，它们也可能引入额外的抽象层，遮蔽底层的提示词和响应，增加调试难度。此外，过于依赖框架可能导致开发者在简单场景中引入不必要的复杂性。

我们建议开发者先直接使用 LLM 的 API，因为很多功能仅需几行代码即可实现。如果选择框架，请确保理解其底层代码逻辑，因为对底层机制的误解是用户常见的错误来源。

有关示例实现，请参阅我们的 cookbook。

构建模块、工作流程与智能体

本节将探讨智能体系统在实际应用中的常见模式。我们将从最基础的构建模块——增强型 LLM 开始，逐步增加复杂性，从简单的组合工作流程发展到完全自主的智能体。

构建模块：增强型 LLM

智能体系统的核心是增强型大语言模型 (LLM)，它通过加入检索、工具和记忆等功能变得更强大。当前的模型可以主动使用这些功能，比如生成搜索查询、选择合适的工具以及决定哪些信息需要保留。

在实际应用中，我们建议关注两个重点：根据具体使用场景定制这些功能，以及为大语言模型提供一个简洁、易用且文档齐全的接口。实现这些增强功能的方法有多种，其中一种是使用我们最近推出的 Model Context Protocol。通过简单的 客户端实现，开发者可以将系统与日益扩展的第三方工具生态轻松集成。

在本文接下来的部分中，我们假设每次 LLM 调用都可以使用这些增强功能。

工作流程：提示链 (Prompt chaining)

提示链是一种将任务分解为多个步骤的方式，每次调用大语言模型 (LLM) 时，都会基于前一步的输出进行处理。在任何中间步骤中，您都可以添加程序化检查（见下图中的“gate”）以确保任务按计划进行。

适用场景： 提示链适用于任务可以被清晰地分解为固定子任务的情况。通过将每次 LLM 调用的复杂性降低，可以在一定程度上牺牲延迟以换取更高的准确性。

提示链的常见应用：

• • 先生成营销文案，然后将其翻译成其他语言。

• • 编写文档大纲，验证大纲是否符合特定标准，再基于大纲撰写完整文档。

工作流程：路由 (Routing)

路由是一种将输入分类并分配给不同后续任务的流程。通过这种方法，可以针对不同类型的任务设计更专业的提示词。如果不使用路由，优化某一类输入可能会对其他输入的处理性能产生负面影响。

适用场景： 路由适用于复杂任务，这些任务可以分为多种类别，且每种类别可以分别优化。分类的准确性可以通过 LLM 或传统算法实现。

路由的常见应用：

• • 根据客户服务请求的类型（如一般问题、退款请求或技术支持）分配到相应的流程、提示词或工具。

• • 将简单问题分配给较小模型（如 Claude 3.5 Haiku），将复杂问题转交给性能更强的模型（如 Claude 3.5 Sonnet），以平衡成本和效率。

工作流程：并行化 (Parallelization)

并行化指通过让多个 LLM 实例同时处理任务，再将它们的输出进行汇总的工作流程。这种方式有两种主要形式：

• • 分段处理：将任务拆分为相互独立的子任务，分别处理。

• • 投票：对相同任务进行多次尝试，以获取多样化结果。

适用场景： 并行化适用于需要加快处理速度或需要从多个视角分析的任务。对于复杂任务，将不同维度分开处理通常能够提高模型的整体表现。

并行化的常见应用：

• • 分段处理：

  • 使用一个模型实例处理用户查询，另一个模型筛查不当内容或请求。这种分工通常比让同一个 LLM 同时处理两者效果更佳。

  • 自动评估 LLM 的表现，通过多个模型实例分别评估不同维度的能力。

• • 投票：

  • 检查代码是否存在漏洞，通过多种提示词分别审查代码并标记问题。

  • 评估内容是否不当，多个提示词分别从不同角度进行判断，并通过投票机制平衡误报和漏报的比例。

工作流：Orchestrator-workers

在 Orchestrator-workers 工作流中，一个中央大语言模型 (Large Language Model, LLM) 会动态地将任务分解，分派给多个工作 LLM，最后汇总它们的结果。

适用场景： 这个工作流适合处理复杂任务，特别是当任务需要的子步骤难以提前预测时。例如，在编程中，任务可能需要修改多个文件，而文件数量和具体修改内容取决于任务本身。与固定流程不同，这种方法的关键优势在于灵活性——子任务由中央 LLM 根据输入动态生成。

应用示例：

• • 需要对多个文件进行复杂修改的编程工具。

• • 涉及从多种来源收集和分析信息的搜索任务。

工作流：Evaluator-optimizer

Evaluator-optimizer 工作流通过一个 LLM 生成初始结果，然后由另一个 LLM 提供反馈，循环改进。

适用场景： 当任务有明确的评价标准，并且通过迭代优化可以显著提升效果时，此工作流表现尤为突出。两个关键条件是：首先，LLM 的结果在接收到反馈后能明显改进；其次，LLM 本身可以生成高质量的反馈。这类似于人类通过多次修改和打磨完成一份高质量文档的过程。

应用示例：

• • 文学翻译，初始翻译可能遗漏细微差别，但评价 LLM 能指出改进方向。

• • 需要多轮搜索和分析的复杂信息查询任务，评价 LLM 决定是否需要进一步搜索。

智能体 (Agents)

智能体依托大语言模型的能力，逐步应用于解决复杂任务。智能体通常从人类的指令或交互式讨论开始，任务明确后会独立规划并执行。当执行遇到阻碍时，智能体可以暂停并寻求人类反馈，确保任务朝着正确的方向推进。

适用场景： 智能体特别适合那些需要多步操作、难以预定义步骤的任务。在这种情况下，智能体能充分利用其决策能力，为每一步动态制定计划。

应用示例：

• • 用于解决 SWE-bench 任务的编程智能体，这些任务需要对多个文件进行编辑；

• • 在“计算机使用”场景中，Claude 可完成文件管理等任务。

注意事项： 智能体虽然功能强大，但其实现和运行成本较高，且可能出现错误累积。因此，建议在受控环境中测试并添加必要的防护措施。

模式的组合与定制

这些工作流模式只是常见的构建模块，开发者可以根据具体需求自由组合。成功的关键在于不断测试和改进实现，确保增加复杂性时确实能带来更好的结果。

总结

在大语言模型 (LLM) 领域，成功的关键不在于构建最复杂的系统，而是创建最适合需求的系统。可以先从简单的提示开始，再通过全面评估进行优化，只有在简单方案无法满足需求时，才考虑引入多步骤的智能体 (agentic) 系统。

在开发智能体时，我们坚持以下三大原则：

1. 1. 智能体设计应注重简洁性；

2. 2. 确保透明性，清晰展示智能体的规划步骤；

3. 3. 通过详细的工具文档与测试，优化智能体-计算机界面 (agent-computer interface, ACI)。

虽然框架能加速开发，但在进入生产环境后，可以减少抽象层次，更多使用基础组件。遵循这些原则，您可以打造功能强大、可靠且用户信赖的智能体。

致谢

本文由 Erik Schluntz 和 Barry Zhang 撰写，内容基于我们在 Anthropic 构建智能体的经验，并结合了客户提供的宝贵见解，在此深表感谢。

附录 1: 实践中的智能体

我们与客户合作发现了两个特别有潜力的 AI 智能体应用案例，充分展示了这些开发模式的实际价值。这些案例表明，智能体在需要对话和操作、目标明确、支持反馈回路并融入人类监督的任务中最具成效。

A. 客户支持

客户支持将传统聊天机器人界面与增强功能相结合，非常适合开放式的智能体应用，原因如下：

• • 交互过程符合对话逻辑，同时需要访问外部信息和执行操作；

• • 可通过工具提取客户数据、订单历史及知识库内容；

• • 可自动处理退款或更新工单等操作；

• • 成功标准可以通过用户定义的结果清晰衡量。

多家公司采用按使用付费的模式，仅对成功解决方案收费，验证了这种方法的可靠性。

B. 编程智能体

在软件开发领域，LLM 的潜力令人瞩目，功能从代码补全扩展到自主解决问题。智能体特别适用于以下场景：

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

• • 智能体可利用测试结果反馈不断优化解决方案；

• • 问题空间明确且有结构；

• • 输出质量可以通过客观标准衡量。

在我们的实现中，智能体能够根据 SWE-bench Verified 基准中的拉取请求描述解决实际的 GitHub 问题。尽管自动化测试可以验证功能，但人类审查仍是确保解决方案符合整体系统需求的重要环节。

附录 2: 工具的提示工程

在构建智能体系统时，工具往往是不可或缺的一部分。工具 使 Claude 能够通过 API 与外部服务交互，明确工具的结构和定义。当 Claude 作出响应时，如果计划调用工具，它将在 API 响应中包含一个 工具使用块。工具定义与规范需要像提示设计一样精细。

同一任务可以用多种方式实现。例如，可以通过 diff 或重写整个文件来编辑文件内容。对于结构化输出，可以选择 markdown 或 JSON 格式。在软件工程中，这些差异可以无损转换，但对于 LLM，某些格式更易于生成。例如，编写 diff 时需提前知道哪些行会更改，而 JSON 格式则要求转义换行符和引号。

优化工具格式的建议包括：

• • 为模型提供足够的 Token，避免其陷入“瓶颈”；

• • 设计接近模型常见的文本格式；

• • 减少复杂度，例如避免要求精确统计代码行数或频繁转义字符串。

就像设计人机界面 (HCI) 时需要投入精力，创建良好的智能体-计算机界面 (ACI) 也需要同等关注。以下是一些实用建议：

• • 从模型的角度出发，评估工具是否易用。好的工具定义应包含示例用法、边界情况、输入格式要求及清晰的功能范围；

• • 优化参数名称或描述，确保直观易懂，类似为初级开发者编写的优秀文档；

• • 测试工具的使用效果，通过 工作台 运行示例输入，发现并改进模型的常见错误；

• • Poka-yoke 工具设计，调整参数以降低误用风险。

在开发 SWE-bench 的过程中，我们花费了大量时间优化工具，而非优化整体提示。例如，当智能体离开根目录时，我们发现使用相对路径的工具容易出错。对此，我们修改工具使其强制要求绝对路径，从而彻底解决了问题。

AI失控焦虑终结者，解密Coze如何驯服大语言模型，掌控感是这么来的——慢慢学AI147【全方位解析】企业如何通过提示词工程优化AI输出，提升市场竞争力—慢慢学AI045【场景驱动】企业的哪些重复性任务，最适合用Coze循环节点来解决？——慢慢学AI146【干货分享】AI 开发者必学！掌握 Coze 工作流核心技能的全攻略！——慢慢学AI145

专注企业 AI 咨询落地，需求对接私信留言，联系小助理