智能体执行框架（Harness）的构成要素

TLDR： 智能体 = 模型 + 执行框架（Harness）。执行框架工程（Harness Engineering）是我们围绕模型构建系统、将其转化为工作引擎的方法。模型提供智能，执行框架让这份智能变得有用。本文将定义什么是执行框架，并推导出当前及未来智能体所需的核心组件。

到底什么是“执行框架”？

智能体 = 模型 + 执行框架

如果你不是模型，那你就是执行框架。

执行框架包含了所有不属于模型本身的代码、配置和执行逻辑。一个原始模型本身不是智能体。但当执行框架为它提供了状态、工具执行、反馈循环和可执行的约束时，它就变成了智能体。

具体来说，执行框架包括：

• 系统提示（System Prompts）
• 工具、技能（Skills）、MCP 及其描述
• 捆绑的基础设施（文件系统、沙箱、浏览器）
• 编排逻辑（子智能体生成、任务交接、模型路由）
• 确定性执行的钩子/中间件（压缩、续写、代码检查）

在模型和执行框架之间划分智能体系统的边界有很多混乱的方式。但在我看来，这是最清晰的定义，因为它迫使我们思考如何围绕模型智能来设计系统。

本文其余部分将探讨核心的执行框架组件，并从模型这个核心原语出发，推导出为什么需要每个组件。

为什么需要执行框架？从模型的视角看

我们希望智能体能做一些模型无法开箱即用的事情。这就是执行框架的用武之地。

模型（大多）接收文本、图像、音频、视频等数据，然后输出文本。仅此而已。开箱状态下，它们无法：

• 在多次交互间保持持久状态
• 执行代码
• 访问实时知识
• 设置环境并安装软件包来完成工作

这些都是执行框架层面的功能。大语言模型（LLM）的结构决定了需要某种机制来包装它们，以完成有用的工作。

例如，为了实现“聊天”这样的产品用户体验，我们将模型包装在一个 while 循环中，以跟踪之前的消息并追加新的用户消息。阅读本文的每个人都已使用过这种执行框架。核心思想是，我们希望将期望的智能体行为转化为执行框架中的实际功能。

从期望的智能体行为倒推执行框架工程

执行框架工程帮助人类注入有用的先验知识来引导智能体行为。随着模型能力越来越强，执行框架被用来精确地扩展和修正模型，以完成以前不可能的任务。

我们不会列举所有执行框架功能。目标是从“帮助模型完成有用工作”这个起点，推导出一系列功能。我们将遵循这样的模式：

期望的行为（或需要修正的问题） → 帮助模型实现该行为的执行框架设计。

文件系统：用于持久存储和上下文管理

我们希望智能体拥有持久存储，以便与真实数据交互、卸载超出上下文容量的信息，并在多个会话间保持工作进度。

模型只能直接操作其上下文窗口内的知识。在文件系统出现之前，用户必须将内容直接复制粘贴给模型，这种用户体验笨拙，且不适用于自主智能体。现实世界早已使用文件系统进行工作，因此模型自然也在数十亿 token 的训练数据中学会了如何使用它。自然的解决方案变成了：

执行框架提供文件系统抽象和文件操作工具。

文件系统可以说是最基础的执行框架原语，因为它解锁了以下能力：

• 智能体获得一个工作空间来读取数据、代码和文档。
• 工作可以增量添加和卸载，而不是将所有内容都保存在上下文中。智能体可以存储中间输出，并保持跨越单个会话的状态。
• 文件系统是自然的协作界面。 多个智能体和人类可以通过共享文件进行协调。像智能体团队（Agent Teams）这样的架构就依赖于此。

Git 为文件系统添加了版本控制，使智能体能够跟踪工作、回滚错误和分支实验。我们稍后会再次讨论文件系统，因为它被证明是实现其他所需功能的关键执行框架原语。

Bash + 代码：作为通用工具

我们希望智能体能够自主解决问题，而无需人类预先设计每一个工具。

目前主要的智能体执行模式是 ReAct 循环，即模型进行推理、通过工具调用执行操作、观察结果，并在 while 循环中重复此过程。但执行框架只能执行其具备逻辑的工具。与其强迫用户为每个可能的操作构建工具，更好的解决方案是给智能体一个像 bash 这样的通用工具。

执行框架提供 bash 工具，让模型可以通过编写和执行代码来自主解决问题。

Bash + 代码执行是给模型一台计算机并让它们自主处理其余问题的一大步。模型可以通过代码即时设计自己的工具，而不是局限于一组固定的预配置工具。

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

沙箱与工具：用于执行和验证工作

智能体需要一个具有合适默认设置的环境，以便安全地行动、观察结果并取得进展。

我们已经给了模型存储和执行代码的能力，但所有这些都需要在某个地方发生。在本地运行智能体生成的代码有风险，并且单一的本地环境无法扩展到大型智能体工作负载。

沙箱为智能体提供安全的操作环境。 执行框架可以连接到沙箱来运行代码、检查文件、安装依赖项和完成任务，而不是在本地执行。这实现了代码的安全、隔离执行。为了更安全，执行框架可以设置命令白名单并强制网络隔离。沙箱还解锁了扩展能力，因为可以按需创建环境、将任务分发到多个环境，并在工作完成后销毁环境。

好的环境自带好的默认工具集。 执行框架负责配置工具，以便智能体能够完成有用的工作。这包括预安装语言运行时和软件包、用于 Git 和测试的 CLI，以及用于网络交互和验证的浏览器。

浏览器、日志、截图和测试运行器等工具为智能体提供了一种观察和分析其工作的方式。这有助于它们创建自我验证循环，在其中编写应用代码、运行测试、检查日志并修复错误。

模型本身无法开箱即用地配置自己的执行环境。决定智能体在哪里运行、可以使用哪些工具、可以访问什么以及如何验证其工作，这些都是执行框架层面的设计决策。

内存与搜索：用于持续学习

智能体应该记住它们见过的东西，并访问训练时不存在的信息。

模型除了其权重和当前上下文中的内容外，没有额外的知识。在无法编辑模型权重的情况下，“添加知识”的唯一方法是通过上下文注入。

对于内存，文件系统再次成为一个核心原语。执行框架支持像 AGENTS.md 这样的内存文件标准，这些文件在智能体启动时被注入上下文。随着智能体添加和编辑此文件，执行框架将更新后的文件加载到上下文中。这是一种持续学习形式，智能体持久存储一个会话中的知识，并将这些知识注入未来的会话。

知识截止日期意味着模型无法直接访问新数据（如更新的库版本），除非用户直接提供。为了获取最新知识，网络搜索和像 Context7 这样的 MCP 工具可以帮助智能体访问知识截止日期之后的信息，例如新的库版本或训练停止时不存在的当前数据。

网络搜索和用于查询最新上下文的工具是有用的原语，值得内置到执行框架中。

对抗上下文腐化（Context Rot）

智能体的性能不应随着工作进程而下降。

上下文腐化描述了模型在其上下文窗口填满时，推理和完成任务的能力如何变差。上下文是宝贵且稀缺的资源，因此执行框架需要管理它的策略。

今天的执行框架在很大程度上是良好上下文工程（Context Engineering）的交付机制。

压缩（Compaction） 解决当上下文窗口即将填满时该怎么办的问题。没有压缩，当对话超过上下文窗口时会发生什么？一种选择是 API 报错，这不好。执行框架必须为此情况使用某种策略。因此，压缩会智能地卸载和总结现有的上下文窗口，以便智能体可以继续工作。

工具调用卸载（Tool call offloading） 有助于减少大型工具输出的影响，这些输出可能会嘈杂地填满上下文窗口，却不提供有用信息。执行框架保留超过一定 token 阈值的工具输出的头部和尾部 token，并将完整输出卸载到文件系统，以便模型在需要时可以访问。

技能（Skills） 解决了在智能体启动时加载过多工具或 MCP 服务器到上下文中，导致性能在智能体开始工作前就下降的问题。技能是一个执行框架层面的原语，通过渐进式披露（progressive disclosure） 来解决这个问题。模型本身不会选择在启动时将技能前置内容加载到上下文中，但执行框架可以支持这一点，以保护模型免受上下文腐化的影响。

长周期自主执行

我们希望智能体能够自主、正确地完成复杂工作，并且能持续很长时间。

自主编写软件是编程智能体的终极目标。但现在的模型存在过早停止、难以分解复杂问题，以及工作跨越多个上下文窗口时失去连贯性等问题。一个好的执行框架必须围绕这些挑战进行设计。

这时，前面提到的那些框架基础组件就开始发挥叠加效应了。长周期工作需要持久的状态、规划、观察和验证机制，才能跨越多个上下文窗口持续工作。

用文件系统和 Git 来追踪跨会话的工作进度。 智能体在长任务中会产生数百万个 token，文件系统能持久保存工作内容，以便随时间追踪进度。加上 Git 后，新智能体就能快速了解项目的最新进展和历史。对于多个协同工作的智能体，文件系统还充当了共享的工作账本。

Ralph 循环（Ralph Loop）让工作得以延续。 Ralph 循环是一种执行框架模式，它通过钩子（hook）拦截模型的退出尝试，并在一个干净的上下文窗口中重新注入原始提示，强制智能体继续朝着完成目标工作。文件系统让这成为可能，因为每次迭代都从全新的上下文开始，但会读取前一次迭代的状态。

通过规划和自我验证保持正轨。 规划是指模型将目标分解为一系列步骤。执行框架通过良好的提示工程，以及提醒如何使用文件系统中的规划文件来支持这一点。完成每个步骤后，智能体可以通过自我验证来检查工作的正确性。框架中的钩子可以运行预定义的测试套件，如果失败，则将错误信息反馈给模型，让其循环处理；或者提示模型独立评估自己的代码。验证将解决方案锚定在测试中，并为自我改进创造了反馈信号。

执行框架的未来

模型训练与框架设计的耦合

如今的智能体产品，如 Claude Code 和 Codex，都是在模型和框架协同参与的情况下进行后期训练的。这有助于模型在框架设计者认为其应该天生擅长的操作上有所提升，比如文件系统操作、Bash 执行、规划，或者使用子智能体并行工作。

这就形成了一个反馈循环。有用的基础组件被发现、添加到框架中，然后在训练下一代模型时被使用。随着这个循环不断重复，模型在其受训的框架内会变得越来越强大。

但这种协同进化对模型的泛化能力产生了有趣的副作用。一个明显的表现是，改变工具逻辑会导致模型性能下降。一个很好的例子在 Codex-5.3 提示指南 中有所描述，即用于编辑文件的 apply_patch 工具逻辑。一个真正智能的模型应该能轻松在不同补丁方法间切换，但在框架参与下的训练导致了这种过拟合。

但这并不意味着，最适合你任务的框架就是模型后期训练时用的那个。 Terminal Bench 2.0 排行榜 就是个好例子。Claude Code 中的 Opus 4.6 得分远低于其他框架中的 Opus 4.6。在我们之前的博客 中，我们展示了如何仅通过改变执行框架，就将我们的编码智能体在 Terminal Bench 2.0 上的排名从 Top 30 提升到了 Top 5。为你的任务优化框架，还有很大的潜力可挖。

框架工程的发展方向

随着模型能力越来越强，如今框架中的部分功能将被吸收进模型本身。模型将更擅长规划、自我验证和长周期连贯性，从而减少对上下文注入的依赖。

这似乎意味着框架的重要性会随时间减弱。但就像提示工程在今天仍然有价值一样，框架工程很可能在构建优秀智能体方面继续发挥作用。

没错，今天的框架确实在弥补模型的不足，但它们也围绕模型智能构建系统，使其更高效。一个配置得当的环境、合适的工具、持久的状态和验证循环，能让任何模型都更有效率，无论其基础智能水平如何。

框架工程是一个非常活跃的研究领域，我们在 LangChain 也用它来改进我们的框架构建库 deepagents。以下是我们目前正在探索的几个开放且有趣的问题：

• 协调数百个智能体在共享代码库上并行工作
• 智能体分析自己的运行轨迹，以识别和修复框架层面的故障模式
• 框架能够根据给定任务即时动态地组装合适的工具和上下文，而不是预先配置好

这篇博客旨在尝试定义什么是执行框架，以及我们希望模型完成的工作如何塑造了它。

模型承载着智能，而框架是让这份智能变得有用的系统。

愿我们构建更多框架、更好的系统和更出色的智能体。