0 前言
过去一年中,我们与不同行业中开发大语言模型 (LLM) 智能体的多个团队进行了合作。我们发现,最成功的实现并非依赖复杂的框架或专业化的库,而是通过简单、可组合的模式构建。
本文分享从客户合作及自身开发智能体的过程中所学到的经验,并为开发者提供构建高效智能体的实用建议。
1 啥是智能体?
“智能体”有多种定义:
- 一些客户将智能体定义为完全自主的系统,这些系统能够独立运行较长时间,利用各种工具完成复杂任务
- 另一些人则将其描述为遵循预定义工作流的更具指令性的实现
在 Anthropic,我们将这些变化形式统称为智能系统(agentic systems),但在架构上对工作流和智能体做重要区分:
- 工作流是通过预定义的代码路径来协调 LLM 和工具的系统
- 智能体则是动态控制其自身过程和工具使用的系统,保持对任务完成方式的主导权
接下来详细探讨这两种智能系统类型。在附录 1(“智能体的实际应用”)中,我们会描述客户在特定领域中应用这些系统所取得的成果。
2 何时(及何时不)使用智能体
在构建 LLM 应用时,建议寻找尽可能简单的解决方案,仅必要时增加复杂性。这可能意味着完全不构建智能系统。智能系统通常以牺牲延迟和成本为代价,换取更好的任务表现,因此需权衡。
当需要更多复杂性时,工作流可以为定义明确的任务提供可预测性和一致性,而智能体更适合需要灵活性和模型驱动决策的大规模任务。然而,对于许多应用,使用检索和上下文示例优化单次 LLM 调用通常已经足够。
3 何时及咋用框架
许多框架可简化智能系统实现,如:
- LangChain 的 LangGraph
- 亚马逊 Bedrock 的 AI Agent 框架
- Rivet,一种拖拽式 GUI LLM 工作流构建器
- Vellum,另一个用于构建和测试复杂工作流的 GUI 工具
这些框架通过简化调用 LLM、定义和解析工具以及串联调用等标准底层任务,帮助用户快速入门。然而,它们常常会引入额外的抽象层,可能掩盖底层提示词和响应,使调试变得更困难,同时也容易诱使开发者添加本可以避免的复杂性。
建议开发者从直接使用 LLM API 入手,因为许多模式可以用几行代码实现。如果确实使用框架,请确保对底层代码有充分了解。对框架内部运行机制的错误假设是客户错误的常见来源。
参考我们的 cookbook 获取一些示例实现。
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 性能,每次调用评估模型性能的不同方面。
投票:
- 检查代码中的漏洞,通过多种不同提示词对代码进行审查并标记潜在问题。
- 评估给定内容是否不适当,多种提示词评估不同方面,或使用不同投票阈值以平衡误报和漏报。
4.5 工作流:协调者-工作者模式
在协调者-工作者模式中,中心 LLM 动态分解任务,将子任务分配给工作者 LLM,并综合其结果。
协调者-工作者工作流:
适用场景:非常适合无法预测所需子任务的复杂任务。如编码中,每次需要更改的文件数量及每个文件的更改内容可能取决于特定任务。尽管拓扑上类似并行化,其关键区别在灵活性——子任务不是预定义的,而是由协调者根据具体输入动态确定。
应用示例:
- 实现复杂更改的编码产品,涉及多个文件
- 搜索任务,从多个来源收集并分析信息以筛选可能的相关内容
4.6 工作流:评估者-优化者模式
在评估者-优化者模式中,一个 LLM 调用生成响应,另一个 LLM 调用则提供评估和反馈,通过循环迭代优化结果。
评估者-优化者工作流
适用场景: 此工作流特别适合有明确评估标准的情况,并且迭代改进可以带来显著价值。两个适用标志是:首先,当人类提出反馈时,LLM 的响应能够显著改进;其次,LLM 自身可以提供这样的反馈。这类似于人类写作过程中反复修改以生成精炼文档的过程。
应用示例
- 文学翻译,其中译者 LLM 初始可能无法捕捉到所有细微差别,而评估者 LLM 能够提供有益的批评
- 复杂的搜索任务,这些任务需要多轮搜索和分析以收集全面的信息,评估者决定是否需要进一步搜索
4.6 智能体
随 LLM 在理解复杂输入、进行推理和规划、可靠地使用工具以及从错误中恢复的能力方面的逐步成熟,智能体正在生产环境中逐渐被采用。智能体的工作起点通常是用户的指令或与用户的互动讨论。一旦任务明确,智能体会规划并自主执行任务,必要时可能会再次与用户交互以获取更多信息或判断。在执行过程中,智能体需在每个步骤中从环境中获取“真实信息”(例如工具调用的结果或代码执行的反馈),以评估任务进展。智能体可以在检查点或遇到阻碍时暂停以获取用户反馈。任务通常在完成后终止,也可以设置停止条件(如最大迭代次数)以保持控制。
尽管智能体可以处理复杂任务,但其实现通常较为简单,主要是 LLM 在一个循环中基于环境反馈使用工具。因此,设计清晰和完善的工具集及其文档至关重要。在附录 2(“为工具设计提示词”)中,我们扩展了工具开发的最佳实践。
自主智能体:
适用场景: 智能体适合开放性问题,这类问题难以预测所需步骤,且无法通过硬编码定义固定路径。LLM 可能需要多轮操作,因此需要对其决策有一定信任。智能体的自主性使其非常适合在可信环境中扩展任务。
智能体的自主性带来了更高的成本,并可能导致错误的累积。我们建议在隔离环境中进行广泛测试,并配备适当的保护措施。
应用示例
来自我们自身的实现:
- 一个编码智能体,用于解决 SWE-bench 任务,这些任务根据任务描述对多个文件进行编辑
- 我们的 “计算机使用”参考实现,其中 Claude 使用计算机完成任务
High-level flow of a coding agent:
4.7 结合与定制这些模式
这些构建模块并非硬性规定,而是开发者可以根据不同用例加以调整和组合的通用模式。与任何 LLM 功能一样,成功的关键在于衡量性能并对实现方案进行迭代优化。重申一点:只有在复杂性确实能够显著改善结果时,才应考虑增加复杂性。
5 总结
在大语言模型领域取得成功,并不是构建最复杂的系统,而是构建适合自身需求的正确系统。从简单的提示词开始,用全面的评估优化它们,只有当更简单的解决方案无法满足需求时,才引入多步骤的智能系统。
在实施智能体时,我们遵循以下三个核心原则:
- 在智能体设计中保持简洁;
- 优先透明性,明确展示智能体的规划步骤;
- 通过全面的工具文档和测试,精心设计智能体的接口。
框架可以帮助快速入门,但随着进入生产阶段,不要犹豫减少抽象层,并以基本组件进行构建。遵循这些原则,您可以创建功能强大、可靠且易于维护的智能体,赢得用户的信任。
附录-智能体的实际应用
我们与客户的合作表明,有两个特别有前景的智能体应用领域能够很好地展示本文所讨论模式的实际价值。这两个应用领域显示了智能体在需要结合对话与操作、具有明确成功标准、能够进行反馈循环并且可进行有意义的人工监督的任务中所能带来的显著价值。
A. 客户支持
客户支持结合了传统的聊天机器人界面与通过工具集成增强的能力。对于更加开放式的智能体而言,这是一个天然契合的场景,因为:
- 支持交互自然遵循对话流程,同时需要访问外部信息和执行操作;
- 可以集成工具来提取客户数据、订单历史以及知识库文章;
- 诸如处理退款或更新工单之类的操作可以以编程方式处理;
- 成功可以通过用户定义的解决方案清晰地衡量。
许多公司已经通过基于使用的定价模式证明了这种方法的可行性,即仅对成功解决方案收费,这显示了对智能体效果的高度信心。
B. 编码智能体
软件开发领域在 LLM 功能方面展现了显著潜力,其能力已经从代码补全发展到自主解决问题。智能体特别有效的原因包括:
- 代码解决方案可以通过自动化测试进行验证;
- 智能体可以使用测试结果作为反馈迭代改进解决方案;
- 问题空间定义清晰且结构化;
- 输出质量可以通过客观指标进行衡量。
在我们的实施中,智能体已经能够根据拉取请求描述解决 SWE-bench Verified 基准测试中的真实 GitHub 问题。然而,尽管自动化测试有助于验证功能性,人工审查对于确保解决方案符合更广泛的系统需求仍然至关重要。
本文由博客一文多发平台 OpenWrite 发布!
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。