智能体工具包详解：将大语言模型转化为智能体的各个组件

2023年时，描述如何使用语言模型还相当简单。你输入一个问题，比如“写一个用于排序数字数组的Python函数”，几乎立刻就会得到回复。该模型并未展现出任何明显的思考过程，它只是一个纯粹的LLM，没有当今智能体系统所具备的工具、记忆、技能等附加功能。正是这些附加功能让一个普通的LLM变成了AI智能体。

竞争格局的变化

在2023年和2024年期间，竞争的焦点在于各种模型本身。OpenAI拥有领先的通用模型，Anthropic则拥有出色的编程模型，各方都在MMLU和SWE-bench等测试基准上相互角逐。最终这场竞争开始趋于平缓，推理能力和长上下文处理能力变得更为重要。聊天界面中开始出现“正在思考……”的提示，人们也开始好奇其背后的原理。

用户也在发生变化。随着模型性能的提升，人们不再提问，而是开始交付任务。这类任务要求系统设定目标、使用浏览器等外部工具、调取之前的对话和存储的信息，最终输出结果。

通过一个例子来对比这两个时代。早期，人们可能会直接截取亚马逊首页的截图，交给编码模型，要求一次性生成外观相同的网站。这样得到的界面虽然尚可。而现在则希望一次性完成界面设计、后端开发、基础设施搭建以及所有其他相关工作。

到2026年，同一位用户可能会写道“修复GitHub上issue #122中提到的错误”。这句话其实隐含了多个步骤。2023年的模型会回复称无法访问你的代码仓库。而经过良好框架封装的模型则会进入思考循环：推理、规划、选择工具或操作方案、执行该方案、观察结果，然后重复或停止。

什么是框架

围绕大型语言模型存在的所有附加组件（上下文、工具、内存等）都需要一种有序的方式与模型进行交互。这种机制有个专门的名称，其定义也很简短：它就是位于人工智能智能体周围的基础设施层，负责对智能体进行封装、引导、测试、监控并评估其结果。简单来说，它就是大型语言模型周围的操作系统。

该层面涵盖了智能体架构、用于协调子智能体的编排框架、用于评估输出质量的评分系统，以及运行时基础设施、安全性、治理机制和可观测性功能。

为何需要它

人们分配的任务规模不断增大，智能体处理这些任务所需的时间也在增加。Anthropic 的数据表明执行时间正以极快的速度上升。在一年前的 2025 年，一个智能体处理某项任务大约需要一小时时间，而如今这一时长已接近十二小时。

长时间运行的任务会带来各种问题。智能体可能会无限循环、编造并不存在的工具、破坏自身状态、耗尽令牌预算、丢失上下文、重复执行错误操作、在无人知晓的情况下失败、滥用权限，甚至忘记任务目标。

那些故障会带来实际的金钱损失。如果一个智能体陷入无限循环长达十二小时，将会消耗大量代币和计算资源。通过为每个任务设定时间、代币或计算资源方面的预算限制，就可以控制这种消耗。

安全性则是更值得关注的问题。如果模型选择了具有破坏性的工具，比如能够清除文件系统的工具，就需要通过框架来决定它允许操作的范围。简而言之，框架让开发者能够掌控智能体，从而确保其按照预期执行任务。

组成要素

无论某个团队将其框架称为什么，其组成部分都可以归为八类。每一类都代表着智能体必须能够回答的一个问题。

• 智能体状态：当前执行到哪一步了？它用于记录当前的任务、步骤、观察结果以及决策。如果一个计划包含四个步骤，状态信息会标明哪些步骤已完成、哪个步骤正在执行以及哪些步骤尚未开始。没有这种状态记录，被中断的智能体就无法知道应该从哪里继续。
• 工具：有哪些可用的操作？这是最直观的部分，代码执行、浏览器、API、数据库以及命令行界面都属于这一范畴。对于编程智能体而言，read_file函数就是最基础的功能之一。
• 规划：接下来该做什么？它负责决定后续的操作，并起草或修改计划。在编程任务中，它可能会生成四到五个步骤的序列。

内存：目前已知什么？它负责在不同步骤或会话之间存储和检索信息。当从向量数据库中获取内容并放入上下文时，先对其进行总结可以节省空间，这一工作由内存组件负责。

调度：流程如何执行？它控制执行循环、工具调用、重试机制、子代理、并行处理以及任务交接。在购买流程中，支付子代理可能会同时运行，而库存代理则负责更新库存；或者库存代理需要等待支付成功后再继续操作。

上下文管理：大语言模型当前应看到什么？它决定在每个步骤中将哪些内容放入上下文窗口。

安全与治理：允许什么行为？权限设置、沙箱环境、审批流程、政策规范、使用限制以及身份验证都属于此范畴。即便模型被允许编辑文件，也最好禁止其删除文件。

可观测性与评估：它真的成功了吗？该机制能够追踪所发生的一切，并判断任务是成功、失败还是违反了某些约束条件。如果某项任务需要使用十种可用工具中的三种，就需要了解这些工具是如何被使用的。当某个工具无法发挥作用时，原因可能是模型从未拥有过该工具，也可能是相关数据未能传递到模型的处理环境中。通过追踪记录就可以区分这两种情况。

通过设计、构建和运行这些组件来让智能体发挥最佳性能的实践被称为“驾驭工程”。这是一门相对较新的学科，大多数团队仍在探索各项职责的具体归属。

从始至终的编程助手

给一个配备工具包的编程助手下达指令“解决GitHub上issue #122中的错误”。这不是要求“向我解释”的请求，而是一项需要规划、使用工具并调用记忆的真正任务。其逻辑流程如下：

1. 用户的输入会被纳入上下文。模型会对这些信息进行推理并确定目标，该目标会一直保留在上下文中直至达成。
2. 模型会规划具体步骤：查看相关错误、修复正确的文件、编译代码、运行测试并更新记忆内容。
3. 对于第一步，工具包会从向量数据库中获取与当前任务相关的历史错误信息作为记忆依据。其中与认证相关的记录会因匹配度最高而被纳入上下文。

基于该上下文，模型决定打开auth.py文件以修复认证错误。这需要使用read_file和write_file工具来编辑并保存文件。

接着，它使用可用工具集中的终端工具从终端层面测试更改效果。该框架会确保模型对终端和文件拥有适当的访问权限。

模型进入下一个计划步骤并运行测试用例，这需要更多的工具。每个步骤都会更新上下文，以便模型了解当前所处的状态以及还有哪些任务需要完成。

在整个过程中，可观测性机制会记录一切：所使用的工具、耗时、内存占用情况以及过程中出现的故障。

评估部分尚未涉及，但它值得单独讨论。评估标准不仅包括准确性，还包括与智能体实际行为相关的多种指标。

未来发展方向

长时可靠性是当前最棘手的未解问题之一。由于智能体需要运行数小时甚至数天，其运行过程必须具备高度的可靠性。如果智能体陷入循环或处于异常状态，不仅会浪费资源，还可能危及安全。

随着相关框架的日益复杂，评估工作也变得更加困难。每项任务都会留下诸如内存使用情况等数据痕迹，团队必须决定是更换模型，还是重新设计框架、添加新工具或修复现有工具。目前社区正在积极探讨这些问题。