内容
可以有人定义一下“套件”吗？
智能代理 = 模型 + 套件
如果你不是模型，那么你就是套件。
套件是指除模型本身之外的所有代码、配置和执行逻辑。原始模型不是智能代理，但当套件为其提供状态、工具执行、反馈环和可强制执行的约束时，它就变成了智能代理。
具体来说，套件包括以下内容：
- 系统提示
- 工具、技能、MCP（多智能体协作平台）及其描述
- 捆绑基础设施（文件系统、沙箱、浏览器）
- 协调逻辑（子代理生成、任务交接、模型路由）
- 确定性执行的钩子/中间件（压缩、继续、代码检查）
在智能代理系统的边界划分上有许多混乱的方法，但我认为这是最清晰的定义，因为它迫使我们思考围绕模型智能设计系统。
本文的其余部分将探讨核心套件组件，并从模型的原始基本要素出发，推导出每个组件存在的原因。
为什么我们需要套件……从模型的角度
我们希望智能代理执行某些任务，而模型本身无法做到。这就是套件的用武之地。 模型（大多）接收文本、图像、音频、视频等数据，并输出文本。仅凭这些，它们无法：
- 在交互过程中保持持久状态
- 执行代码
- 访问实时知识
- 设置环境和安装软件包以完成工作
这些都是套件级别的功能。LLM（大型语言模型）的结构需要某种机制来包装它们，以便完成有用的工作。例如，为了实现诸如“聊天”之类的产品用户体验，我们将模型包装在一个循环中，以跟踪以前的消息并追加新的用户消息。阅读本文的每个人都已经使用过这种套件。其主要思想是，我们希望将期望的智能代理行为转换为套件中的实际功能。
从期望的智能代理行为到套件工程
套件工程帮助人类注入有用的先验知识，以引导智能代理的行为。随着模型能力的提高，套件被用来扩展和纠正模型，以完成以前不可能的任务。
我们不会列出所有套件功能。我们的目标是从帮助模型完成有用的工作的起点推导出一组功能。我们将遵循以下模式：
期望行为（或需要修复的行为）→ 帮助模型实现该行为的套件设计
文件系统实现持久存储和上下文管理
我们希望智能代理具有持久存储，以与真实数据接口，卸载不适合上下文的信息，并跨会话持久化工作。
模型只能在其上下文窗口内直接操作知识。在文件系统出现之前，用户不得不将内容直接复制粘贴到模型中，这是一种笨拙的用户体验，对于自主智能代理来说根本不起作用。世界已经在使用文件系统来完成工作，因此模型自然被训练在数十亿个标记上，了解如何使用它们。自然而然的解决方案是：
套件随文件系统抽象和文件系统操作工具一起提供。
文件系统可以说是最基础的套件原语，因为它解锁了以下功能：
- 智能代理获得一个工作空间来读取数据、代码和文档。
- 工作可以逐步添加和卸载，而不是将所有内容都保存在上下文中。智能代理可以存储中间输出，并保持状态以延续会话。
- 文件系统是一种自然的协作界面。多个智能代理和人类可以通过共享文件进行协调。诸如Agent Teams之类的架构就依赖于此。
Git 为文件系统添加了版本控制功能，因此智能代理可以跟踪工作、回滚错误和分支实验。我们在下面再次讨论文件系统，因为它原来是其他所需功能的关键套件原语。
Bash 工具实现自主问题解决
我们希望智能代理在不需要人类预先设计每种工具的情况下自主解决问题。
当今主要的智能代理执行模式是 ReAct 环，其中模型通过工具调用进行推理、采取行动、观察结果，并在 while 环中重复。但是，套件只能执行它们具有逻辑的工具。更好的解决方案是给智能代理一个通用工具，如 bash。
套件随 bash 工具提供，这样模型可以通过编写和执行代码来解决问题自主地。
Bash + 代码执行是 赋予模型一台计算机 的一大步，让它们可以自主地解决其他问题。模型可以通过代码动态设计自己的工具，而不是局限于一组预先配置的工具。
套件仍然会提供其他工具，但代码执行已成为自主问题解决的默认通用策略。
沙箱提供安全执行环境
智能代理需要一个具有正确默认设置的环境，以便安全地行动、观察结果并取得进展。
我们已经为模型提供了存储和执行代码的能力，但所有这些都需要在某个地方发生。在本地运行智能代理生成的代码存在风险，而单个本地环境无法扩展以应对大量智能代理工作负载。
沙箱为智能代理提供了安全的运行环境。 套件可以连接到沙箱以运行代码、检查文件、安装依赖项和完成任务。这实现了代码的安全、隔离执行。为了进一步提高安全性，套件可以允许列出命令并强制网络隔离。沙箱还解锁了可扩展性，因为环境可以按需创建、扩展到许多任务，并在工作完成后销毁。
内存和搜索实现持续学习
智能代理应该记住它们所见过的内容，并访问在训练时不存在的信息。
模型除了其权重和当前上下文之外，没有额外的知识。没有访问模型权重的能力，唯一的“添加知识”的方法是上下文注入。
对于内存，文件系统再次成为核心原语。套件支持诸如 AGENTS.md 之类的内存文件标准，这些标准在智能代理启动时被注入上下文中。当智能代理添加和编辑此文件时，套件将更新的文件加载到上下文中。这是 持续学习 的一种形式，智能代理可以持久存储来自一个会话的知识，并在未来的会话中将这些知识注入上下文中。
知识截止意味着模型无法直接访问新的数据，例如更新的库版本，除非用户直接提供这些数据。对于最新的知识，Web Search 和 MCP 工具（如 Context7 ）帮助智能代理访问超出其知识截止的数据，例如新的库版本或在训练停止时不存在的当前数据。
对抗上下文腐败
智能代理的性能不应随着工作过程而下降。
上下文腐败 描述了随着上下文窗口的填充，模型的推理和完成任务的能力会变差。上下文是一种宝贵且稀缺的资源，因此套件需要策略来管理它。
当今的套件在很大程度上是良好上下文工程的交付机制。
压缩解决了当上下文窗口接近填满时该怎么办的问题。没有压缩，如果对话超过了上下文窗口，会发生什么？一种选择是 API 错误，这是不好的。套件必须为这种情况使用某种策略。因此，压缩智能地卸载和总结现有的上下文窗口，以便智能代理可以继续工作。
工具调用卸载有助于减少大型工具输出的影响，这些输出可能会杂乱地填充上下文窗口，而不提供有用的信息。套件保留工具输出的头部和尾部标记，超过一定数量的标记，并将完整输出卸载到文件系统中，以便模型在需要时可以访问它。
技能解决了在智能代理启动时将太多工具或 MCP 服务器加载到上下文中，从而在智能代理开始工作之前降低性能的问题。技能是一种套件级原语，通过 渐进式披露 解决了这个问题。模型没有选择在启动时将技能前置加载到上下文中，但套件可以支持这一点，以保护模型免受上下文腐败。
**技能（Skills）解决了在代理启动时加载过多工具或MCP服务器导致性能下降的问题。技能是一种利用渐进式披露（progressive disclosure）**的底层原语。该模型选择不将技能前置信息加载到上下文中，但底层框架可以支持这一点，以保护模型免受上下文腐烂。
长期自主执行
我们希望代理能够在长时间范围内自主、正确地完成复杂任务。
自主软件创建是编码代理的终极目标。但目前的模型存在早期停止、复杂问题分解困难以及工作跨越多个上下文窗口时的一致性问题。一个好的框架必须围绕这些问题进行设计。
这就是前面提到的框架原语开始发挥作用的地方。长期工作需要持久状态、规划、观察和验证，以跨越多个上下文窗口继续工作。
文件系统和git用于跟踪会话间的工作。 代理在长期任务中产生数百万个令牌，因此文件系统可以持久地捕获工作，以跟踪随时间变化的进度。添加git允许新代理快速了解最新工作和项目历史。对于多个代理共同工作，文件系统还充当共享工作账本，代理可以在其中协作。
拉尔夫循环（Ralph Loops）用于继续工作。 拉尔夫循环是一种框架模式，它通过钩子拦截模型的退出尝试，并将原始提示重新注入干净的上下文窗口，强制代理继续朝着完成目标工作。文件系统使得这一点成为可能，因为每次迭代都以新鲜的上下文开始，但读取来自前一次迭代的状态。
规划和自我验证以保持正确。 规划是指模型将目标分解为一系列步骤。框架通过良好的提示和注入关于如何在文件系统中使用计划文件的提醒来支持这一点。在完成每个步骤后，代理通过自我验证来检查其工作的正确性。框架中的钩子可以运行预定义的测试套件，并在失败时将错误消息返回给模型，或者模型可以独立地评估其代码。验证通过测试确保解决方案的正确性，并为自我改进提供反馈信号。
框架的未来
模型训练与框架设计的耦合
当今的代理产品，如Claude Code和Codex，都是在模型和框架的循环中进行后期训练的。这有助于模型在框架设计者认为它们应该擅长的操作中得到改进，例如文件系统操作、bash执行、规划或使用子代理并行工作。
这形成了一个反馈环。发现了有用的原语，将其添加到框架中，然后在训练下一代模型时使用。随着这个循环的重复，模型在它们被训练的框架内变得更加有能力。
但这种共进化对泛化能力有有趣的副作用。它表现在改变工具逻辑会导致模型性能下降。例如，Codex-5.3提示指南中描述了一个例子，应用补丁工具逻辑用于编辑文件。一个真正智能的模型应该可以轻松地在补丁方法之间切换，但与框架的循环训练却造成了这种过拟合。
但这并不意味着您的任务的最佳框架就是模型后期训练的框架。 Terminal Bench 2.0排行榜是一个很好的例子。Opus 4.6在Claude Code中的得分远低于Opus 4.6在其他框架中的得分。 在之前的博客中，我们展示了如何仅通过更改框架就将我们的编码代理Top 30提升到Terminal Bench 2.0的Top 5。优化框架以适应您的任务还有很多潜力可挖掘。
框架工程的未来
随着模型能力的提高，今天框架中的一些功能将被模型吸收。模型将更好地进行规划、自我验证和长期一致性，从而减少对上下文注入的需求。
这意味着框架应该随着时间的推移变得不那么重要。但就像提示工程今天仍然很有价值一样，框架工程很可能继续对构建良好的代理有用。
确实，今天的框架弥补了模型的缺陷，但它们也围绕模型的智能设计系统，使其更有效。配置良好的环境、合适的工具、持久状态和验证循环使任何模型都更高效，无论其基础智能如何。
框架工程是一个非常活跃的研究领域，我们利用它来改进LangChain的框架构建库deepagents。以下是我们今天正在探索的几个开放且有趣的问题：
- 协调数百个代理并行工作在共享代码库上
- 代理分析自己的轨迹以识别和修复框架级故障模式
- 框架动态组装合适的工具和上下文，实时适应给定任务，而不是预先配置
这篇博客是对框架是什么以及它如何受到我们希望模型执行的工作的影响的探讨。
模型包含智能，框架是使该智能有用的系统。
为了更强大的框架构建、更好的系统和更好的代理。