第 3710 期 智能体驱动框架的解剖与推演

VivekTrivedy 2026-06-03 09:05 日本

智能体并非模型本身，而是模型与驱动框架的结合体。模型提供智能，框架赋予它状态、工具与反馈闭环。

前言

智能体并非模型本身，而是模型与驱动框架的结合体。模型提供智能，框架赋予它状态、工具与反馈闭环。本文从模型的原始能力出发，推导出文件系统、沙箱、记忆、上下文管理等核心组件的设计逻辑，并展望二者协同进化的未来。

本文由 5 分钟新知精选，今日前端早读课文章由 @Vivek Trivedy 分享，@飘飘编译。

译文从这开始～～

核心要点

• 分解复杂目标：规划工具让智能体能够拆解任务、追踪进度，并在执行过程中灵活调整。

• 并行分派工作：为各个独立子任务生成子智能体，每个子智能体拥有各自隔离的上下文环境。

一句话总结：智能体 = 模型 + 驱动框架。驱动框架的工程设计，本质上就是围绕模型搭建系统，将其打造成真正能干活的引擎。模型提供智能，驱动框架则让这份智能发挥实际价值。本文将定义何为 "驱动框架"，并推导出当下乃至未来的智能体所需的核心组件。

【第3708期】智能体引擎优化：当AI成为你文档的头号读者

究竟什么是 "驱动框架"？

智能体 = 模型 + 驱动框架

如果你不是模型，那你就是驱动框架。

所谓驱动框架，就是模型本身之外的一切 —— 所有代码、配置和执行逻辑。一个裸模型算不上智能体，但当驱动框架赋予它状态管理、工具调用、反馈回路以及可执行的约束条件时，它便成了智能体。

具体而言，驱动框架包含以下内容：

• 系统提示词

• 工具、技能、MCP 及其描述信息

• 集成基础设施（文件系统、沙箱、浏览器）

• 编排逻辑（子智能体生成、任务交接、模型路由）

• 钩子与中间件，用于确定性执行（上下文压缩、续写、代码检查等）

关于模型与驱动框架之间的边界划分，业界有很多含混不清的做法。但在我看来，上述定义最为简洁明了，因为它迫使我们从 "围绕模型智能来设计系统" 的角度出发进行思考。

【第3698期】AI可观测性：大语言模型与智能体的全链路透视

本文接下来将逐一剖析驱动框架的核心组件，并从模型这一基本单元出发，反向推导每个组件存在的意义。

为什么需要驱动框架？—— 从模型的视角看

有很多我们希望智能体完成的事情，模型本身是做不到的。这正是驱动框架存在的意义。模型（大体上）接收文本、图像、音频、视频等数据，然后输出文本。仅此而已。开箱即用的模型无法：

• 在多轮交互中维持持久状态

• 执行代码

• 获取实时知识

• 搭建环境、安装依赖包来完成实际工作

这些统统是驱动框架层面的能力。大语言模型的结构特性决定了，它们必须被某种机制包裹起来，才能真正发挥作用。

举个例子：为了实现 "对话" 这种产品体验，我们把模型放进一个循环中，用来记录历史消息并追加新的用户输入。读到这里的每一位，其实都已经用过这种驱动框架了。核心思路就是：将期望的智能体行为，转化为驱动框架中的具体功能。

【第3448期】Build System 视角：重新认识前端打包工具的设计哲学

从期望行为反推驱动框架的设计

驱动框架工程帮助人类注入有价值的先验知识，以引导智能体的行为。随着模型能力不断增强，驱动框架也被用于精准地扩展和修正模型，使其能够完成以前根本不可能完成的任务。

我们不会穷举所有驱动框架的功能，而是以 "帮助模型完成实际工作" 为出发点，推导出一组核心功能。我们将遵循如下思路：

我们想要（或想要修正）的行为 → 帮助模型实现该行为的驱动框架设计。

文件系统：持久存储与上下文管理

我们希望智能体拥有持久化存储能力，以便与真实数据交互、卸载上下文装不下的信息，并让工作成果跨会话留存。

模型只能直接操作上下文窗口内的知识。在拥有文件系统之前，用户只能将内容复制粘贴给模型 —— 这种体验笨拙不堪，对于自主运行的智能体更是完全行不通。而人类世界早已依赖文件系统来完成工作，模型在训练过程中也自然而然地学习了数十亿个关于文件系统使用方式的词元。于是，一个水到渠成的方案应运而生：

驱动框架内置文件系统抽象和文件操作工具。

文件系统堪称驱动框架中最基础的原语，因为它解锁了一系列关键能力：

• 智能体拥有了一个工作空间，可以读取数据、代码和文档。

• 工作成果可以渐进式地写入和卸载，而非将所有内容塞在上下文中。智能体能够存储中间产物，维护跨越单次会话生命周期的状态。

• 文件系统是天然的协作界面。多个智能体和人类可以通过共享文件进行协同，"智能体团队" 等架构正是建立在这一基础之上。

• Git 为文件系统增添了版本控制能力，智能体因此可以追踪工作进度、回滚错误、创建实验分支。

后文我们还会再度回到文件系统这个话题，因为事实证明，它也是实现其他诸多驱动框架功能的关键原语。

【第3676期】Node.js 终于有了虚拟文件系统：node:vfs 来了

Bash + 代码：通用型工具

我们希望智能体能够自主解决问题，而不必依赖人类为每一种操作预先设计专用工具。

当前主流的智能体执行模式是 ReAct 循环 —— 模型进行推理，通过工具调用执行动作，观察结果，然后在一个循环中不断重复。但驱动框架只能执行它预置了逻辑的工具。与其强迫用户为每一种可能的操作都构建专用工具，不如给智能体一个通用型工具，比如 bash。

驱动框架内置 bash 工具，让模型通过编写和执行代码来自主解决问题。

Bash 加上代码执行能力，是朝着 "把一台电脑交给模型，让它自己搞定剩下的事" 这一目标迈出的一大步。模型可以通过代码即时设计自己的工具，而不再受限于一组固定的预配置工具集。

驱动框架仍然会附带其他工具，但代码执行已经成为自主问题解决的默认通用策略。

沙箱与工具：执行与验证工作

智能体需要一个具备合理默认配置的环境，以便安全地执行操作、观察结果并持续推进工作。

我们已经赋予了模型存储能力和代码执行能力，但这一切都需要一个承载的场所。在本地运行智能体生成的代码存在风险，而且单一的本地环境也无法支撑大规模的智能体工作负载。

沙箱为智能体提供了安全的运行环境。驱动框架无需在本地执行，而是可以连接到沙箱来运行代码、检查文件、安装依赖、完成任务。这确保了代码在安全隔离的环境中执行。为了进一步增强安全性，驱动框架可以设置命令白名单并实施网络隔离。沙箱还解锁了可扩展性 —— 环境可以按需创建、在多个任务间并行展开，工作完成后即可销毁。

好的环境离不开好的默认工具。驱动框架负责配置工具链，使智能体能够高效工作。这包括预装语言运行时和软件包、用于版本控制和测试的 CLI 工具、用于网页交互和验证的浏览器等。

浏览器、日志、截图、测试运行器等工具赋予了智能体观察和分析自身工作的能力。借助这些工具，智能体可以构建自我验证闭环 —— 编写应用代码、运行测试、检查日志、修复错误，循环往复。

模型本身并不具备配置自身执行环境的能力。决定智能体在哪里运行、哪些工具可用、能访问什么资源、如何验证工作成果 —— 这些都是驱动框架层面的设计决策。

【第3672期】CSS 迎来原生随机能力：random() 与 random-item() 初探

记忆与搜索：持续学习

智能体应当记住自己见过的东西，并能获取训练时尚未存在的信息。

模型除了自身权重和当前上下文中的内容外，别无其他知识。在无法直接编辑模型权重的前提下，"增加知识" 的唯一途径就是上下文注入。

在记忆方面，文件系统再次扮演了核心原语的角色。驱动框架支持诸如AGENTS.md这样的记忆文件标准，在智能体启动时将其注入上下文。当智能体添加或编辑这个文件后，驱动框架会将更新后的文件重新加载到上下文中。这是一种持续学习机制 —— 智能体将一次会话中获得的知识持久化存储，并在未来的会话中注入这些知识。

知识截止日期意味着，模型无法直接获取新数据（例如更新后的库版本），除非用户主动提供。为了获取最新知识，网络搜索以及 Context7 等 MCP 工具帮助智能体访问知识截止日期之后的信息 —— 比如新版本的代码库或训练结束后才出现的最新数据。

网络搜索和用于查询最新上下文的工具，是值得内置于驱动框架中的重要原语。

对抗上下文腐化

智能体的表现不应随着工作推进而逐渐衰退。

1、上下文腐化

描述的是这样一种现象：随着上下文窗口被逐渐填满，模型的推理和任务完成能力会不断下降。上下文是一种珍贵而稀缺的资源，因此驱动框架必须具备相应的管理策略。

如今的驱动框架，在很大程度上就是优秀上下文工程的交付载体。

2、压缩机制

解决的是上下文窗口即将填满时该怎么办的问题。如果没有压缩，当对话超出上下文窗口长度时会发生什么？一种情况是 API 直接报错 —— 这显然不可接受。驱动框架必须为此制定应对策略。因此，压缩机制会智能地卸载和摘要现有上下文窗口的内容，使智能体能够继续工作。

3、工具调用输出卸载

有助于减轻大量工具输出的影响 —— 这些输出往往像噪声一样充斥上下文窗口，却并不提供有用信息。驱动框架会保留超过阈值词元数的工具输出的首尾部分，并将完整输出卸载到文件系统中，以便模型在需要时查阅。

4、技能机制

解决的是智能体启动时加载过多工具或 MCP 服务器导致上下文膨胀、尚未开始工作性能就已下降的问题。技能是一种驱动框架层面的原语，通过渐进式披露来解决这一问题。模型并没有主动选择在启动时将技能的前置描述加载到上下文中，但驱动框架可以支持这种机制，从而保护模型免受上下文腐化的侵蚀。

长周期自主执行

我们希望智能体能够在较长的时间跨度内，自主、正确地完成复杂工作。

自主软件创建是编程智能体的终极目标。但当今的模型饱受提前终止、复杂问题分解困难，以及工作跨越多个上下文窗口时出现前后不连贯等问题的困扰。优秀的驱动框架必须针对这些问题逐一设计应对方案。

此时，前文介绍的各种驱动框架原语开始产生复合效应。长周期工作需要持久状态、规划能力、观察能力和验证能力，才能在跨越多个上下文窗口时依然保持工作的连贯性。

1、文件系统和 Git 用于跨会话追踪工作。

智能体在一项长期任务中会产出数百万词元，文件系统将工作成果持久化保存，以便追踪进度。引入 Git 后，新的智能体可以快速了解项目的最新状态和历史沿革。在多个智能体协作的场景下，文件系统还充当共享工作账本的角色，为智能体之间的协同提供基础。

2、Ralph 循环用于延续工作。

Ralph 循环是一种驱动框架模式，它通过钩子拦截模型的退出意图，在一个全新的上下文窗口中重新注入原始提示词，迫使智能体朝着完成目标继续工作。文件系统使这一切成为可能，因为每次迭代都以全新的上下文开始，但会从上一次迭代中读取状态。

3、规划和自我验证用于保持航向。

规划是指模型将一个目标分解为一系列步骤。驱动框架通过精心设计的提示词以及注入如何使用文件系统中计划文件的提醒来支持这一能力。在完成每一步之后，智能体需要通过自我验证来检查工作的正确性。驱动框架中的钩子可以运行预定义的测试套件，在失败时将错误信息回传给模型形成闭环；也可以通过提示引导模型独立评估自己的代码。验证机制让解决方案以测试为锚点，为自我改进创造反馈信号。

【第3418期】HTML 表单验证：未被充分利用的利器

驱动框架的未来

模型训练与驱动框架设计的深度耦合

当今的智能体产品 —— 如 Claude Code 和 Codex—— 在后训练阶段就已将模型与驱动框架纳入统一的训练回路中。这有助于模型在驱动框架设计者认为其应当原生擅长的操作上不断精进，比如文件系统操作、bash 执行、任务规划，或通过子智能体实现并行工作。

这形成了一个正向飞轮。有价值的原语被发现后纳入驱动框架，继而在训练下一代模型时被使用。随着这个循环不断迭代，模型在其所训练的驱动框架环境中变得愈发强大。

但这种协同进化对泛化能力会产生耐人寻味的副作用 —— 具体表现为：修改工具逻辑会导致模型性能下降。Codex-5.3 提示指南中关于apply_patch文件编辑工具逻辑的描述就是一个很好的例子。一个真正智能的模型在不同补丁方法之间切换应该毫无障碍，但在训练回路中引入驱动框架，却造成了这种过拟合现象。

然而，这并不意味着对你的任务而言，最佳驱动框架就一定是模型后训练时所使用的那个。Terminal Bench 2.0 排行榜就是一个很好的例证：Opus 4.6 在 Claude Code 中的得分远低于在其他驱动框架中的表现。在此前的一篇博文中，我们展示了如何仅通过改变驱动框架，就将我们的编程智能体在 Terminal Bench 2.0 上的排名从前 30 提升至前 5。在针对特定任务优化驱动框架这件事上，还有巨大的潜力可以挖掘。

驱动框架工程的未来走向

随着模型能力不断增强，如今驱动框架中承担的部分职责将逐渐被模型本身吸收。模型将在规划、自我验证和长周期连贯性方面原生地越来越强，因此对上下文注入等外部辅助的依赖也会相应减少。

这似乎暗示，驱动框架的重要性会随着时间推移而降低。但正如提示词工程在今天依然价值巨大一样，驱动框架工程在构建优秀智能体方面很可能将持续发挥重要作用。

诚然，当下的驱动框架在一定程度上是为了弥补模型的不足。但它们同样是在围绕模型智能构建系统，使其更加高效。精心配置的环境、恰到好处的工具、持久化的状态、完善的验证闭环 —— 这些让任何模型都能更高效地运作，无论其基础智能水平如何。

驱动框架工程是一个极为活跃的研究领域，我们正将研究成果应用于 LangChain 旗下的驱动框架构建库 deepagents 的持续改进中。以下是我们当前正在探索的几个开放且引人入胜的课题：

• 编排数百个智能体在共享代码库上并行协作

• 智能体自主分析自身的执行轨迹，识别并修复驱动框架层面的故障模式

• 驱动框架根据给定任务实时动态组装所需的工具和上下文，而非依赖预先配置

本文是一次定义 "驱动框架" 的尝试，也是对驱动框架如何被我们期望模型完成的工作所塑造的一次梳理。

模型承载智能，驱动框架则是让这份智能发挥价值的系统。

愿我们构建更多驱动框架，打造更优系统，成就更强智能体。

关于本文
译者：@飘飘
作者：@Vivek Trivedy
原文：https://www.langchain.com/blog/the-anatomy-of-an-agent-harness

这期前端早读课
对你有帮助，帮”赞“一下，
期待下一期，帮”在看” 一下。

阅读原文