智能体框架(Harness)的剖析
简而言之：智能体 = 模型 + 框架。框架工程是指我们如何围绕模型构建系统，将其转化为工作引擎。模型包含智能，而框架则使这种智能发挥作用。我们定义了框架的概念，并推导出当今和未来智能体所需的核心组件。
1、请问有人能解释一下“框架”是什么吗？
智能体 = 模型 + 框架
如果你不是模型，你就是框架。
框架（Harness）是指除模型本身之外的所有代码、配置和执行逻辑。原始模型不是智能体。但当框架赋予它状态、工具执行、反馈循环和可强制执行的约束等功能时，它就变成了智能体。
具体来说，一个框架包含以下内容：
- 系统提示
- 工具、技能、MCP 及其描述
- 捆绑的基础设施（文件系统、沙箱、浏览器）
- 编排逻辑（子代理生成、交接、模型路由）
- 用于确定性执行的钩子/中间件（压缩、延续、代码检查）
有很多方法可以划分代理系统在模型和框架之间的边界，但这些方法往往比较繁琐。在我看来，这是最清晰的定义，因为它迫使我们围绕模型智能来思考系统设计。
本文的其余部分将介绍框架的核心组件，并从模型的核心原语出发，反向推导出每个组件存在的理由。
2、为什么我们需要框架……从模型的角度来看
我们希望代理执行一些模型本身无法完成的任务。这时就需要用到框架了。
模型（通常）接收文本、图像、音频、视频等数据，并输出文本。仅此而已。开箱即用时，它们无法：
- 在交互过程中保持持久状态
- 执行代码
- 访问实时知识
- 设置环境并安装软件包以完成工作
这些都是框架级别的功能。LLM 的结构需要某种机制来封装它们，使其能够执行有用的工作。
例如，为了实现类似“聊天”的产品用户体验，我们将模型封装在一个 while 循环中，以跟踪之前的消息并添加新的用户消息。所有阅读本文的人都已经使用过这种框架。其核心思想是，我们希望将期望的代理行为转换为框架中的实际功能。
3、从期望的代理行为反向推导到框架工程
框架工程帮助人们注入有用的先验信息来指导代理行为。随着模型能力的不断增强，框架已被用于精确地扩展和修正模型，使其能够完成以前无法完成的任务。
我们不会详尽列出所有框架功能。我们的目标是从帮助模型执行有用工作的出发点出发，推导出一组功能。我们将遵循这样的模式：
我们想要的行为（或想要修复的行为）→ 使用 Harness Design 来帮助模型实现此行为。
4、用于持久存储和上下文管理的文件系统
我们希望代理拥有持久存储，以便与真实数据交互，卸载不适合上下文的信息，并在会话之间持久化工作。
模型只能直接操作其上下文窗口内的知识。在文件系统出现之前，用户必须将内容直接复制/粘贴到模型中，这不仅用户体验糟糕，而且不适用于自主代理。世界已经在使用文件系统来完成工作，因此模型自然而然地基于数十亿个如何使用文件系统的令牌进行训练。自然的解决方案是：
Harness 附带文件系统抽象和用于文件系统操作的工具。
文件系统可以说是最基础的 Harness 原语，因为它解锁了以下功能：
- 代理获得一个工作区来读取数据、代码和文档。
- 工作可以增量添加和卸载，而不是将所有内容都保存在上下文中。代理可以存储中间输出并维护超越单个会话的状态。
- 文件系统是一个天然的协作界面。多个代理和用户可以通过共享文件进行协调。诸如代理团队之类的架构就依赖于此。
Git 为文件系统添加了版本控制，以便代理可以跟踪工作、回滚错误和创建分支实验。我们将在下文中更详细地探讨文件系统，因为它实际上是我们所需其他功能的关键基础组件。
5、Bash + 代码作为通用工具
我们希望代理能够自主解决问题，而无需用户预先设计每个工具。
目前主要的代理执行模式是 ReAct 循环，其中模型进行推理，通过工具调用执行操作，观察结果，并在 while 循环中重复此过程。但是，组件只能执行它们拥有相应逻辑的工具。与其强迫用户为每个可能的操作构建工具，不如为代理提供像 Bash 这样的通用工具，这样效果更好。
组件附带 Bash 工具，因此模型可以通过编写和执行代码来自主解决问题。
Bash + 代码执行是让模型拥有计算机并自主完成其余工作的重要一步。模型可以通过代码动态设计自己的工具，而不是被限制在一组固定的预配置工具中。d 工具。
Harness 仍然会附带其他工具，但代码执行已成为自主问题解决的默认通用策略。
6、沙箱和用于执行及验证工作的工具
代理需要一个具有正确默认设置的环境，以便它们能够安全地执行操作、观察结果并取得进展。
我们已经为模型提供了存储和执行代码的能力，但所有这些都需要在一个地方进行。在本地运行代理生成的代码存在风险，而且单个本地环境无法扩展到大型代理工作负载。
沙箱为代理提供安全的运行环境。Harness 可以连接到沙箱来运行代码、检查文件、安装依赖项并完成任务，而不是在本地执行。这创建了安全、隔离的代码执行环境。为了提高安全性，Harness 可以允许命令列表并强制执行网络隔离。沙箱还可以提高可扩展性，因为可以按需创建环境，将其分发到多个任务中，并在工作完成后将其销毁。
良好的环境需要良好的默认工具。Harness 负责配置工具，以便代理能够执行有用的工作。这包括预安装语言运行时和软件包、用于 Git 和测试的命令行界面 (CLI)、以及用于 Web 交互和验证的浏览器。
浏览器、日志、屏幕截图和测试运行器等工具使智能体能够观察和分析自身的工作。这有助于它们创建自我验证循环，从而编写应用程序代码、运行测试、检查日志并修复错误。
该模型本身并不配置执行环境。智能体的运行位置、可用工具、可访问资源以及如何验证其工作，这些都是框架级别的设计决策。
7、用于持续学习的记忆和搜索
智能体应该记住它们已经看到的内容，并能够访问训练时不存在的信息。
模型除了权重和当前上下文之外，没有其他知识。由于无法编辑模型权重，因此“添加知识”的唯一方法是通过上下文注入。
对于记忆而言，文件系统仍然是一个核心原语。框架支持诸如 AGENTS.md 之类的记忆文件标准，这些文件会在代理启动时注入到上下文中。当代理添加和编辑此文件时，框架会将更新后的文件加载到上下文中。这是一种持续学习的形式，代理可以持久地存储来自一个会话的知识，并将这些知识注入到未来的会话中。
知识截止意味着模型无法直接访问新数据，例如更新的库版本，除非用户直接提供。为了获取最新知识，Web 搜索和 MCP 工具（例如 Context7）可以帮助代理访问超出知识截止范围的信息，例如新的库版本或在训练停止时不存在的当前数据。
Web 搜索和用于查询最新上下文的工具是集成到框架中的有用基础组件。
8、对抗上下文衰减
代理的性能不应在工作过程中下降。
上下文衰减 描述了随着上下文窗口的填充，模型在推理和完成任务方面性能下降的现象。上下文是一种宝贵且稀缺的资源，因此框架需要策略来管理它。
如今，框架主要作为良好上下文工程的交付机制。压缩机制解决了上下文窗口即将填满时的处理问题。如果没有压缩机制，当对话超出上下文窗口时会发生什么？一种可能是 API 报错，但这显然不是理想的情况。框架必须针对这种情况采取某种策略。因此，压缩机制会智能地卸载并汇总现有的上下文窗口，以便代理能够继续工作。
工具调用卸载有助于减少大型工具输出的影响，这些输出可能会使上下文窗口变得杂乱无章，却无法提供有用的信息。框架会将工具输出的头部和尾部标记保留在超过阈值标记数的位置，并将完整的输出卸载到文件系统，以便模型在需要时可以访问。
技能解决了代理启动时加载到上下文中的工具或 MCP 服务器过多的问题，这会在代理开始工作之前降低性能。技能是框架级别的原语，它通过渐进式披露来解决这个问题。模型没有选择在启动时将技能的前端元数据加载到上下文中，但框架可以支持此功能，以防止模型出现上下文腐烂。
9、长期自主执行
我们希望智能体能够在较长的时间范围内自主、正确地完成复杂的任务。
自主软件创建是智能体编码的终极目标。但目前的模型存在着过早停止、复杂问题分解困难以及跨多个上下文窗口任务执行不一致等问题。一个优秀的框架必须能够克服所有这些挑战。
这就是早期框架原语开始失效的地方。长期任务需要持久化的状态、规划、观察和验证机制，才能在多个上下文窗口中持续运行。
文件系统和 Git 用于跨会话跟踪任务。智能体生成数百万个任务。在长时间的任务中，系统会使用大量的令牌，以便文件系统能够持久地记录工作，从而跟踪进度。添加 Git 可以让新加入的代理快速了解项目的最新进展和历史。对于多个协同工作的代理，文件系统还可以作为共享的工作账本，供代理协作。
Ralph 循环用于持续工作。Ralph 循环是一种工具模式，它通过钩子拦截模型的退出尝试，并在一个干净的上下文窗口中重新注入原始提示，强制代理继续完成目标。文件系统之所以能够实现这一点，是因为每次迭代都从全新的上下文开始，但会读取前一次迭代的状态。
规划和自我验证以确保进度。规划是指模型将目标分解为一系列步骤。工具通过良好的提示和注入如何在文件系统中使用计划文件的提醒来支持规划。完成每个步骤后，代理可以通过自我验证来检查其工作的正确性。框架中的钩子可以运行预定义的测试套件，并在失败时返回模型并返回错误消息；或者，模型可以被提示独立地进行代码自评估。验证将解决方案建立在测试之上，并为自我改进提供反馈信号。
10、模型训练与框架设计的耦合
如今，像 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 上的排名从前 30 名提升到前 5 名。针对你的任务优化框架可以挖掘出巨大的潜力。
11、框架工程的未来发展方向
随着模型能力的提升，目前框架中的一些功能将被模型本身吸收。例如，模型将原生地更好地进行规划、自我验证和长期一致性处理，从而减少对上下文注入的需求。
这表明随着时间的推移，模型框架的重要性可能会降低。但正如快速工程在今天仍然至关重要一样，模型框架工程很可能也会继续对构建优秀的智能体发挥作用。
诚然，如今的模型框架可以弥补模型的缺陷，但它们也围绕模型智能构建系统，从而提高模型的效率。一个配置良好的环境、合适的工具、持久状态和验证循环，无论模型的基础智能如何，都能使其更加高效。
模型框架工程是一个非常活跃的研究领域，我们在 LangChain 利用它来改进我们的模型框架构建库 deepagents。以下是我们目前正在探索的一些开放且有趣的问题：
协调数百个智能体在共享代码库上并行工作
智能体分析自身的运行轨迹，以识别和修复模型框架级别的故障模式
模型框架能够根据给定的任务动态地、即时地组装合适的工具和上下文，而不是预先配置
这篇博客旨在定义什么是模型框架，以及它如何受我们希望模型完成的工作的影响。
模型蕴含智能，而系统则负责将这种智能转化为实际应用。
为了构建更完善的系统和更优秀的智能体。
原文链接：The Anatomy of an Agent Harness
汇智网翻译整理，转载请标明出处