核心提要：智能体=模型+框架。框架工程是指在模型周边搭建系统，将其转化为实用的工作引擎。模型承载智能，而框架让这份智能发挥实际效用。本文将定义框架的内涵，并推导出当下及未来智能体所需的核心组件。

谁能给“框架”下个定义？

智能体=模型+框架

若你并非模型本身，那你就是框架的一部分。

框架指的是除模型本身外的所有代码、配置和执行逻辑。原始模型并非智能体，而当框架为其赋予状态管理、工具执行、反馈循环和可强制执行的约束等能力后，原始模型才会成为智能体。

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

• 系统提示词

• 工具、技能、多智能体控制协议及其描述

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

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

• 用于确定性执行的钩子/中间件（内容压缩、任务续跑、代码检查）

划分智能体系统中模型与框架的边界有许多繁琐的方式，但笔者认为这一定义最为清晰，因为它要求我们围绕模型的智能来设计系统。

本文后续将逐一讲解框架的核心组件，并从模型这一核心基础出发，推导各组件存在的必要性。

智能体框架的核心功能模块

• 上下文注入：提示词、记忆、技能、对话内容

• 控制操作：内容压缩、任务编排、模型调用、命令行工具、各类工具、多智能体控制协议

• 反馈循环：推理→决策→结果回传至上下文

• 读写操作

• 观测与验证：浏览器截图、测试结果、日志

• 持久化存储：文件系统、代码版本管理、进度文件

从模型的视角看，我们为何需要框架？

我们希望智能体实现的诸多功能，都是原始模型无法直接完成的，而框架的价值正在于此。

模型（多数情况下）仅能接收文本、图像、音频、视频等数据，并输出文本——仅此而已。原始模型本身无法实现：

• 在多次交互中维持持久化状态

• 执行代码

• 获取实时知识

• 搭建环境、安装依赖包以完成工作

这些均为框架层面的功能。大语言模型的架构特性，决定了它需要一层配套机制的包裹，才能发挥实际作用。

例如，要实现“对话”这类产品交互体验，我们需要用循环语句包裹模型，追踪历史消息并拼接新的用户消息。看到本文的读者，其实都已使用过这类框架。核心思路在于，将我们期望的智能体行为，转化为框架中实实在在的功能。

从智能体的预期行为倒推框架工程设计

框架工程能帮助人类注入有效的先验知识，引导智能体的行为。随着模型能力的不断提升，框架被用于精准拓展模型能力、修正模型缺陷，使其能够完成以往无法实现的任务。

本文不会罗列框架的所有功能，而是从助力模型发挥实际效用这一出发点，推导出框架的核心功能体系，整体思路遵循：

期望实现（或需要修正）的智能体行为→设计对应的框架功能以实现该行为

智能体预期行为与框架配套功能对应表

智能体预期行为 框架新增配套功能

持久化处理真实数据 文件系统+代码版本管理工具

编写并执行代码 命令行工具+代码执行环境

安全执行+默认工具集 沙箱环境+标准化工具配置

记忆并获取新知识 记忆文件+网络搜索+多智能体控制协议

长上下文下保持性能稳定 内容压缩+工具输出卸载+技能渐进式披露

完成长周期复杂工作 持续执行循环+任务规划+结果验证

每一项框架功能，都源于模型自身无法实现的某类行为需求。

用于持久化存储与上下文管理的文件系统

我们希望智能体拥有持久化存储能力，能够对接真实数据、将超出上下文窗口的信息转移至外部存储，并在不同会话间保留工作进度。

模型仅能直接处理其上下文窗口内的信息。在文件系统被引入框架前，用户必须将内容手动复制粘贴给模型，这种交互体验十分繁琐，也无法支撑自治智能体的运行。人类早已在工作中广泛使用文件系统，因此模型在训练中也接触了数十亿关于文件系统使用方法的语料，顺理成章的解决方案便是：

在框架中集成文件系统抽象层和文件操作工具。

文件系统堪称框架最基础的核心组件，原因在于它实现了多项关键能力：

1. 为智能体提供工作空间，使其能够读取数据、代码和文档；

2. 支持工作内容的增量添加与外部卸载，无需将所有信息都保存在上下文窗口中，智能体可存储中间输出结果，并维持跨会话的持久化状态；

3. 是天然的协作载体，多个智能体与人类可通过共享文件协同工作，智能体团队这类架构的运行也依赖于此。

代码版本管理工具为文件系统增加了版本控制能力，让智能体能够追踪工作进度、回滚错误操作、分支开展实验。后续我们还会进一步探讨文件系统，因为它是实现框架其他多项功能的核心基础。

作为通用工具的命令行与代码执行能力

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

当前智能体的核心执行模式为“反应循环”：模型通过推理制定决策，调用工具执行操作，观测操作结果，并在循环中重复这一过程。但框架仅能执行其包含逻辑的工具，因此，与其要求用户为所有可能的操作开发工具，更优的解决方案是为智能体配备命令行这类通用工具。

框架中集成命令行工具，让模型能够通过编写并执行代码自主解决问题。

命令行+代码执行能力，是让模型拥有“计算机操作能力”、实现高度自主解决问题的关键一步。模型可通过代码实时设计专属工具，而非被局限于固定的预配置工具集。

框架仍会集成其他专用工具，但代码执行已成为智能体自主解决问题的默认通用策略。

用于执行与验证工作的沙箱环境和工具集

智能体需要一个配置合理的默认环境，使其能够安全执行操作、观测结果并推进工作。

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

沙箱环境为智能体提供了安全的运行空间：框架不再在本地执行代码，而是连接沙箱环境完成代码运行、文件检查、依赖安装和任务执行，实现代码的安全隔离运行。为进一步提升安全性，框架可设置命令白名单，并实施网络隔离。沙箱环境还能实现弹性扩展，可根据需求按需创建环境、并行处理大量任务，工作完成后即可销毁环境。

优质的运行环境离不开完善的默认工具集，框架负责配置工具集，保障智能体的工作效率，包括预安装语言运行时和依赖包、代码版本管理与测试的命令行工具、用于网络交互与验证的浏览器等。

浏览器、日志、截图、测试运行器这类工具，为智能体提供了观测和分析工作过程的手段，使其能够建立自我验证循环：编写应用代码→运行测试→检查日志→修复错误。

模型本身无法自行配置执行环境，决定智能体的运行位置、可用工具、访问权限以及工作验证方式，均属于框架层面的设计决策。

用于持续学习的记忆与搜索能力

智能体应能记住已接触的信息，并获取其训练完成后新增的知识。

模型的知识仅来源于其训练权重和当前上下文窗口中的内容，在无法编辑模型权重的情况下，“添加知识”的唯一方式就是上下文注入。

在记忆功能实现上，文件系统再次成为核心组件：框架支持记忆文件标准化（如AGENTS.md），智能体启动时该文件会被注入上下文。智能体可对该文件进行增删改查，框架则会将更新后的文件知识从一个会话传递至后续会话，这是实现智能体持续学习、持久化存储知识的一种方式。

知识截止期的存在，使得模型无法直接获取训练结束后更新的信息（如新版库文件），除非用户手动提供。为获取实时知识，框架中集成网络搜索和多智能体控制协议等工具（如Context7），帮助智能体获取知识截止期后的最新信息。

网络搜索和实时上下文查询工具，是值得内置在框架中的核心基础能力。

应对上下文劣化问题

智能体的性能不应在工作过程中出现衰减。

上下文劣化指的是，随着上下文窗口被不断填充，模型的推理能力和任务完成能力会逐渐下降。上下文是宝贵且稀缺的资源，因此框架需要制定对应的管理策略。

如今的框架，在很大程度上是实现优质上下文工程的载体。

内容压缩

用于解决上下文窗口即将被占满的问题。若没有内容压缩机制，当对话内容超出上下文窗口时，接口可能会抛出错误，这显然不是理想的结果。框架必须为此设计应对策略，内容压缩机制会智能地将现有上下文内容进行外部卸载和总结，让智能体能够持续工作。

工具输出卸载

有助于减少大体积工具输出的影响——这类输出会无意义地占用上下文窗口，却无法提供有效信息。当工具输出的令牌数超过阈值时，框架会仅保留其开头和结尾的令牌，并将完整输出卸载至文件系统，模型可在需要时调取。

技能渐进式披露

解决的是智能体启动时，过多工具或多智能体控制协议服务器被加载到上下文中，导致其尚未开始工作性能就已衰减的问题。技能是框架层面的核心组件，通过渐进式披露的方式解决该问题：模型无需在启动时就将所有技能相关的前置内容加载到上下文中，框架通过这种设计，避免模型受到上下文劣化的影响。

长周期自治执行能力

我们希望智能体能够自主、准确地完成跨长周期的复杂工作。

自主完成软件开发是代码智能体的终极目标，但如今的模型存在提前终止任务、复杂问题分解能力不足、跨多个上下文窗口工作时逻辑不连贯等问题，优质的框架必须针对性设计解决方案。

这也是此前介绍的各类框架核心组件开始发挥协同作用的场景：长周期工作需要持久化状态、任务规划、过程观测和结果验证，才能在多个上下文窗口间持续推进。

1. 文件系统+代码版本管理：实现跨会话的工作追踪。智能体在长周期任务中会生成数百万令牌的内容，文件系统可持久化记录这些工作内容，实现进度的长期追踪；代码版本管理则能让新的智能体快速了解项目的最新进展和历史记录，也为多智能体协作提供了统一的工作记录账本。

2. 持续执行循环：保障工作的持续推进。这是一种框架设计模式，通过钩子拦截模型的任务退出尝试，并在全新的上下文窗口中重新注入原始提示词，强制智能体朝着任务完成的目标继续工作。文件系统为该模式提供了支撑：每次循环都会以全新的上下文启动，但会从文件系统中读取上一次循环的状态。

3. 任务规划+自我验证：保障工作方向不偏离。任务规划指模型将目标分解为一系列步骤，框架通过优质的提示词设计，以及在上下文注入使用文件系统中规划文件的提醒，为任务规划提供支撑。完成每个步骤后，智能体可通过自我验证检查工作的正确性：框架中的钩子可运行预定义的测试套件，若测试失败则将错误信息回传给模型；也可通过提示词引导模型自主评估代码。

4. 结果验证：让解决方案基于测试结果落地，并为智能体的自我优化提供反馈信号。

框架的未来发展

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

如今的智能体产品（如Claude Code、Codex），均采用模型与框架联动的后训练模式。这一模式有助于提升模型在框架设计者认为其应原生擅长的领域的能力，如文件系统操作、命令行执行、任务规划，或是与子智能体并行协作等。

这形成了一个正向反馈循环：研发人员发现实用的核心组件→将其加入框架→在下一代模型的训练中结合该框架开展训练。这一循环不断重复，模型在其训练所依托的框架中，能力会持续提升。

但这种协同演化模式，也给模型的泛化能力带来了一些有趣的副作用，例如修改工具逻辑会导致模型性能下降。Codex-5.3的提示词指南中，就以文件编辑的补丁应用工具逻辑为例，说明了这一问题。真正智能的模型，本应能轻松适配不同的补丁方法，但框架联动的训练模式，却让模型产生了这种过拟合问题。

但这并不意味着，针对某一任务的最优框架，就是模型后训练所使用的框架。《终端基准测试2.0排行榜》就是一个典型案例：我们仅通过修改框架，就将Claude Code中的Opus 4.6模型在该测试中的排名，从第30名提升至第5名。由此可见，针对具体任务优化框架，仍有巨大的潜力可挖。

模型-框架训练循环：框架核心组件如何融入模型训练

1. 发现核心组件（如技能、内容压缩、持续执行循环）

2. 将其加入框架并标准化为产品功能

3. 结合该框架训练下一代模型

4. 模型使用框架的能力得到提升

5. 循环往复

框架工程的发展方向

随着模型能力的不断提升，如今框架中的部分功能，未来会逐渐融入模型本身。例如模型将原生具备更优的规划、自我验证和长周期工作逻辑连贯能力，对上下文注入的依赖会随之降低。

这似乎意味着框架的重要性会随时间推移而下降，但正如提示词工程至今仍具备重要价值一样，框架工程也将持续为搭建优质智能体提供支撑。

诚然，如今的框架在一定程度上是为了弥补模型的缺陷，但它更核心的价值，是围绕模型的智能搭建系统，让智能的效用最大化。无论模型的基础智能水平如何，一个配置合理的运行环境、一套适配的工具集、持久化的状态管理和验证循环，都能让模型的运行效率大幅提升。

框架工程是一个极具活力的研究领域，我们也正通过该领域的研究，持续优化LangChain中的框架构建库。目前，我们正在探索以下几个开放且极具价值的研究方向：

• 编排数百个智能体，使其在共享代码库上并行工作

• 研发能分析自身执行轨迹，识别并修复框架层面故障的智能体

• 研发可针对特定任务，实时动态组装适配的工具和上下文的框架，替代传统的预配置模式

本文旨在定义框架的内涵，并阐述它如何被我们对模型的工作预期所塑造。

模型承载智能，而框架是让这份智能发挥实际效用的系统。

愿我们在框架构建的道路上不断前行，打造更优质的系统，开发更强大的智能体。