过去一年研究不同行业中开发大语言模型 (LLM) 智能体的多个团队的合作,发现最成功的实现并非依赖复杂的框架或专业化的库,而是通过简单、可组合的模式构建。
本文分享开发智能体的过程中所学到的经验,并为开发者提供构建高效智能体的实用建议。
“智能体”有多种定义:
这些变化形式统称为智能系统(agentic systems),但在架构上对工作流和智能体做重要区分:
接下来详细探讨这两种智能系统类型。
在构建 LLM 应用时,建议寻找尽可能简单的解决方案,仅必要时增加复杂性。这可能意味着完全不构建智能系统。智能系统通常以牺牲延迟和成本为代价,换取更好的任务表现,因此需权衡。
当需要更多复杂性时,工作流可以为定义明确的任务提供可预测性和一致性,而智能体更适合需要灵活性和模型驱动决策的大规模任务。然而,对于许多应用,使用检索和上下文示例优化单次 LLM 调用通常已经足够。
许多框架可简化智能系统实现,如LangChain 的 LangGraph。
这些框架通过简化调用 LLM、定义和解析工具以及串联调用等标准底层任务,帮助用户快速入门。然而,它们常常会引入额外的抽象层,可能掩盖底层提示词和响应,使调试变得更困难,同时也容易诱使开发者添加本可以避免的复杂性。
建议开发者从直接使用 LLM API 入手,因为许多模式可以用几行代码实现。如果确实使用框架,请确保对底层代码有充分了解。对框架内部运行机制的错误假设是客户错误的常见来源。
参考anthropic的 cookbook获取一些示例实现。
本部分实际生产环境中观察到的智能系统常见模式。从基础构建模块(增强型 LLM)开始,逐步增加复杂性,从简单的组合工作流到自主智能体。
智能系统的基本构建模块是通过检索、工具和记忆功能增强的 LLM。我们的现有模型能够主动使用这些功能,如:
增强型 LLM:
建议重点关注实现的两个关键方面:将这些功能定制化以满足特定用例需求,并确保为 LLM 提供易于使用且文档完备的接口。虽这些增强功能有多种实现,但其中一种方法是使用 模型上下文协议,该协议允许开发者通过简单的 客户端实现与日益扩展的第三方工具生态系统集成。
接下来,假设每次 LLM 调用都可以访问这些增强功能。
提示词链式调用将任务分解为一系列步骤,每次 LLM 调用处理上一步的输出。您可以在任何中间步骤添加程序化检查(见下图中的“门”)以确保流程仍在正轨上。
提示词链式调用工作流:
适用场景: 此工作流适用于任务可以轻松、清晰地分解为固定子任务的情况。其主要目标是通过使每次 LLM 调用任务更简单,以延迟换取更高准确性。
提示词链式调用的应用示例:
对输入进行分类,并将其引导到特定后续任务来实现的工作流。这允许更好分离关注点,并能为特定类型的输入构建更专业提示词。没这种工作流,为某种输入优化的方式可能影响其他输入的性能。
路由工作流:
适用场景: 路由适用于复杂任务,这些任务分为不同类别,每个类别更适合独立处理,并且分类能够准确完成,可以由 LLM 或更传统的分类模型/算法处理。
路由的应用示例:
在并行化工作流中,LLM 可以同时处理一个任务,其输出随后由程序进行聚合。这种工作流有两种主要形式:
并行化工作流:
适用场景: 并行化适用于可以分解为独立子任务以加快速度的任务,或需要多次尝试或多个视角来提高结果信心的任务。对于需要考虑多个因素的复杂任务,让每个因素由独立的 LLM 调用处理通常表现更优,能够集中精力应对每个特定方面。
应用示例
在协调者-工作者模式中,中心 LLM 动态分解任务,将子任务分配给工作者 LLM,并综合其结果。
协调者-工作者工作流:
适用场景:非常适合无法预测所需子任务的复杂任务。如编码中,每次需要更改的文件数量及每个文件的更改内容可能取决于特定任务。尽管拓扑上类似并行化,其关键区别在灵活性——子任务不是预定义的,而是由协调者根据具体输入动态确定。
应用示例:
在评估者-优化者模式中,一个 LLM 调用生成响应,另一个 LLM 调用则提供评估和反馈,通过循环迭代优化结果。
评估者-优化者工作流
适用场景: 此工作流特别适合有明确评估标准的情况,并且迭代改进可以带来显著价值。两个适用标志是:首先,当人类提出反馈时,LLM 的响应能够显著改进;其次,LLM 自身可以提供这样的反馈。这类似于人类写作过程中反复修改以生成精炼文档的过程。
应用示例
随 LLM 在理解复杂输入、进行推理和规划、可靠地使用工具以及从错误中恢复的能力方面的逐步成熟,智能体正在生产环境中逐渐被采用。智能体的工作起点通常是用户的指令或与用户的互动讨论。一旦任务明确,智能体会规划并自主执行任务,必要时可能会再次与用户交互以获取更多信息或判断。在执行过程中,智能体需在每个步骤中从环境中获取“真实信息”(例如工具调用的结果或代码执行的反馈),以评估任务进展。智能体可以在检查点或遇到阻碍时暂停以获取用户反馈。任务通常在完成后终止,也可以设置停止条件(如最大迭代次数)以保持控制。
尽管智能体可以处理复杂任务,但其实现通常较为简单,主要是 LLM 在一个循环中基于环境反馈使用工具。因此,设计清晰和完善的工具集及其文档至关重要。
自主智能体:
适用场景: 智能体适合开放性问题,这类问题难以预测所需步骤,且无法通过硬编码定义固定路径。LLM 可能需要多轮操作,因此需要对其决策有一定信任。智能体的自主性使其非常适合在可信环境中扩展任务。
智能体的自主性带来了更高的成本,并可能导致错误的累积。我们建议在隔离环境中进行广泛测试,并配备适当的保护措施。
应用示例
High-level flow of a coding agent:
这些构建模块并非硬性规定,而是开发者可以根据不同用例加以调整和组合的通用模式。与任何 LLM 功能一样,成功的关键在于衡量性能并对实现方案进行迭代优化。重申一点:只有在复杂性确实能够显著改善结果时,才应考虑增加复杂性。
在大语言模型领域取得成功,并不是构建最复杂的系统,而是构建适合自身需求的正确系统。从简单的提示词开始,用全面的评估优化它们,只有当更简单的解决方案无法满足需求时,才引入多步骤的智能系统。
在实施智能体时,我们遵循以下三个核心原则:
框架可以帮助快速入门,但随着进入生产阶段,不要犹豫减少抽象层,并以基本组件进行构建。遵循这些原则,您可以创建功能强大、可靠且易于维护的智能体,赢得用户的信任。
有两个特别有前景的智能体应用领域能够很好地展示本文所讨论模式的实际价值。这两个应用领域显示了智能体在需要结合对话与操作、具有明确成功标准、能够进行反馈循环并且可进行有意义的人工监督的任务中所能带来的显著价值。
客户支持结合了传统的聊天机器人界面与通过工具集成增强的能力。对于更加开放式的智能体而言,这是一个天然契合的场景,因为:
许多公司已经通过基于使用的定价模式证明了这种方法的可行性,即仅对成功解决方案收费,这显示了对智能体效果的高度信心。
软件开发领域在 LLM 功能方面展现了显著潜力,其能力已经从代码补全发展到自主解决问题。智能体特别有效的原因包括:
智能体已经能够根据拉取请求描述解决 SWE-bench Verified基准测试中的真实 GitHub 问题。然而,尽管自动化测试有助于验证功能性,人工审查对于确保解决方案符合更广泛的系统需求仍然至关重要。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。