智能体的演进：从上下文工程到长期运行框架

注：中文版可在我博客中找到。

过去几年，大模型进展的主线大多围绕“模型本身“：参数、数据、预训练、后训练、推理。早期谈论智能体时，最常见的定义也非常简单：LLM + 工具使用。后来逐渐变成上下文工程：管理模型在每次推理步骤中看到的上下文，使得多轮工具使用不会被历史、噪音、工具定义和中间结果淹没。再后来，随着任务演变成长期任务，智能体能力变成了由模型、框架、上下文、工具、评估、沙箱和状态管理共同组成的系统能力：在有限的上下文、外部工具和变化的环境中，智能体必须持续朝目标推进，随时间推移越来越接近完成。

在这篇博客中，我们主要关注上下文工程和长期运行框架。

上下文工程源于提示词工程。当智能体从单轮问答系统变成多轮动作系统时，模型在推理时看到的输入也随之改变。它不再是一个相对独立的外部输入即提示词，而是与模型持续与工具和环境交互相关的上下文。这个上下文可能包含工具定义、文件内容、网页观测、历史消息、测试输出、MCP服务器描述、外部文档、进度记录等。上下文工程决定哪些信息应该提前放入提示词，哪些应该按需检索，哪些应该写入外部记忆，哪些应该由代码或工具处理而不是塞入模型上下文。Anthropic在2025年9月的《AI智能体的有效上下文工程》中系统性地阐释了这一概念。

一个具体的上下文工程示例是：当MCP工具和数量过多、数据量过大时，我们不应让每个工具定义和中间结果都流经上下文。相反，智能体应该编写代码按需调用工具、过滤数据，只将高信号结果带回给模型。上下文工程还包括压缩、结构化笔记、甚至多智能体模式，但这些大多服务于“上下文应如何管理“这个问题。后面讨论的长期运行框架则更进一步：它不仅管理上下文，还将规划、实施、评估、修订和最终验收分离到不同流程中。

到2025年底，随着编码智能体能够在软件工程任务上做出更长时间的连续进展，重心迅速转向长期运行框架：从最初关注模型的编码能力，转向在多个上下文窗口/会话中持续执行任务的能力。11月，Anthropic发布了《长时间运行智能体的有效框架》，可视为长期运行框架的第一个版本。

系统开始从“管理一个智能体的上下文“转向“管理多个会话“。这一版本的框架引入了初始化智能体和编码智能体之间的最小角色分工。初始化者的角色是建立一个可交接的外部项目状态：它将任务分解成一个较小的功能列表，编写进度文件，创建初始化脚本，初始化git仓库，并将每个功能标记为待处理。之后，每个编码智能体会话只推进一个有限增量，例如实现一个功能或修复一个具体问题。框架要求它在结束前进行测试、更新记录、提交并将仓库保留在干净状态。这样，即使下一个会话从新的上下文开始，也能通过进度文件、功能列表、git日志和测试结果重新连接到任务。

2026年1月，Anthropic发布了《揭开AI智能体评估的神秘面纱》。这篇文章将智能体评估系统化：因为智能体在环境中行动、调用工具并在多轮中修改状态，评估不能只看最终句子。还必须看记录/轨迹以及最终环境状态是否真正正确。大致来说，它提出了两个要点。一是任务层面：我们如何确定智能体确实完成了任务并且完成得好，而不是产生一个表面上看起来可以接受但实际上有缺陷或不完整的东西？二是框架层面：我们还需要评估框架的每个组件是否真正承载了负载，而不仅仅是添加了无用的东西。

到2026年3月，在《长期应用程序开发的框架设计》中，这一想法成为框架的第二个版本：初始化器+编码智能体扩展为规划器+生成器+评估器。评估器使用Playwright MCP像用户一样操作应用程序，测试UI、API和数据库状态，并拒绝不符合某些标准的输出。

这个评估器是否应该存在取决于任务是否超出了当前模型可靠独立完成的能力。例如，在Opus 4.5上它明显有用；到Opus 4.6，模型本身变得更强，一些脚手架可以被移除或弱化。这些调整和转变自然让我们思考一个更长期的系统设计问题（见他们4月的文章《管理托管智能体的规模化》）：框架不是固定的结构，而是与模型能力共同进化。

早期的Sonnet 4.5 / Opus 4.5存在上下文焦虑，会低估范围，因此需要更多脚手架：上下文重置、冲刺分解、评估器反馈循环。但到了Opus 4.6，模型本身更擅长长期智能体任务、代码审查、调试和长上下文检索。一些原本必要的结构开始变得不那么必要。对于模型已经能可靠独立完成的任务，评估器可能不再值得投入成本。当然，对于刚好处于模型能力边界之外的任务，评估器仍然能带来实际的提升。

框架中的许多设计本质上包含了对“当前模型做不好什么“的假设。模型升级后，这些假设可能不再成立。因此，我们不应将某一代框架视为可以永久使用的架构。相反，我们应该将系统拆分为相对稳定的抽象：用会话记录发生的事情，用框架管理智能体循环和工具使用，用沙箱提供受控的执行环境，等等。这样，底层框架可以不断替换，但智能体产品不依赖于某一代脚手架。

上下文工程

过去人们关注提示词工程，即如何编写系统提示词。但随着智能体变得更面向多轮和长期运行，焦点变为：在每次推理步骤中，模型看到了什么？

例如，智能体的上下文可能包含系统提示词、开发者指令、工具定义、MCP服务器描述、用户消息、对话历史、文件内容、命令输出、浏览器观测、截图、错误、进度笔记、检索到的文档、评估器反馈。这些东西不能盲目全部塞入。即使上下文窗口变得更大，我们仍然需要选择性地取舍，因为长上下文中的噪音会分散模型注意力，并增加成本和延迟。

因此，一个好的上下文是让模型在当前步骤完成下一步的最小高信号上下文。一般来说，我们使用即时上下文：不是将所有文档、工具和历史塞入模型，而是保留引用，例如路径、URL、提交哈希、日志文件、数据库表名等。当模型需要它们时，通过工具加载。这样，智能体的工作记忆只保留索引和当前相关的片段，而不是所有上下文。

长期任务中常见的上下文技术包括：

• 压缩：当上下文几乎满了时，将当前对话轨迹压缩成摘要，然后用该摘要开始下一个上下文。通常这仍然是同一任务和同一智能体循环的延续。其目标是尽可能保持对话连续性。换句话说，模型应该感觉到“我刚才做的事情还在“；只是历史被压缩了。

• 结构化笔记：让智能体主动将任务状态写入持久的外部工件，例如progress.md、feature_list.json、NOTES.md或git提交。不一定只用于同一任务。项目级的NOTES.md可以被后续会话、规划器/生成器/评估器读取，或在相邻任务中复用。

• 上下文重置：使用外部工件，例如笔记产生的文件、git日志、测试结果、任务列表等，作为启动材料来打开一个干净的新上下文/会话。它不保留完整的对话历史，可以清除噪音和错误假设，使新的智能体能重新定位。

• 多智能体架构：进行角色分工和上下文隔离。不同智能体接收不同的上下文，完成不同的子任务，最后只将高密度结果传回主流程。

工具使用

工具使用也有一些需要注意的地方。例如，工具数量不能无限制扩增，否则模型会把注意力浪费在选择上。工具功能不应重叠太多，否则模型不知道用哪个。工具描述应清楚说明何时使用和何时不使用，即边界要清晰。返回值应节省token，不应将不相关的数据倾倒入上下文。返回的错误信息应让模型知道下一步要修复什么。命名应清晰，以便智能体从名称中推断界限。

另外，工具最好不直接作为工具调用暴露给模型，而是映射为代码API/文件树，让智能体通过代码调用。这样，智能体可以只读取当前需要的工具定义，在代码执行环境内过滤大量数据，只将摘要或少量结果返回给模型。它可以使用循环、条件判断和异常处理来完成复杂的控制流，或将中间状态写入文件而不是塞入上下文。

工具输出是确定性的；我们应该将确定性计算留给代码。判断和规划，例如如何调用工具、调用哪些工具、按什么顺序、调用多少次，应该留给模型。

长期运行智能体的问题

1. 上下文窗口

长任务一定会超过单个上下文窗口。即使模型支持很长的上下文，上下文始终是有限资源：每多一条信息都会消耗模型注意力预算的一部分。这带来了三个常见现象：

• 遗忘：新会话不知道前一个会话做了什么。

• 上下文腐烂：上下文越长，模型越容易失去重点；早期信息被噪音淹没。

• 上下文焦虑：当模型感觉接近上下文末尾时，它会匆忙收尾，把半成品称为完成。

2. 规划与交接

许多复杂任务包含数十个相互依赖的功能、缺陷、设计决策和验证步骤。如果模型直接从高级提示词开始，它很容易试图一次完成所有事情，然后半途耗尽上下文，留下一个看似做了很多工作但实际上不工作的东西。此外，即使有些东西对下一个智能体有用，下一个智能体也不知道哪些东西有用：看起来像缺陷的东西是故意这样做的，还是上一会话没来得及清理的？

3. 自我评估

模型不一定严格判断自己生成的东西。它可能看到按钮出现就认为功能完成了；看到页面大致看起来不错就认为设计良好；或者运行部分测试就认为整个系统可用。在Anthropic的长期应用程序框架文章中，他们提到让同一个智能体既做生成者又做审查者往往会导致过于宽松的判断。尤其是前端设计、产品完整性和边缘交互，这些没有直接的单元测试定义，模型很容易说服自己。

框架

智能体框架，也称为脚手架，是使模型能够充当智能体的系统。它处理输入，组织工具调用，管理状态，执行循环，并将结果返回给模型。它包括文件系统、任务面板、测试脚本、浏览器、shell、git、日志、沙箱、权限系统、检查点、交接笔记等。

第一代长期运行框架的核心设计相当简单。它主要使用了两种智能体：

• 初始化智能体：在最开始时运行，建立工作框架和环境。

• 编码智能体：逐个会话地推进增量，并在结束前留下结构化的交接工件。

初始化智能体做几件事。

1. 创建任务列表。

例如，如果用户只说“构建一个claude.ai克隆“，初始化智能体不会让后面的智能体直接开始构建。相反，它会将任务分解成许多可验证的功能，例如新建聊天、输入消息、按Enter发送、接收响应、切换主题、加载历史对话等。每个功能的初始状态标记为失败。

2. 创建进度文件。

例如claude-progress.txt或类似文件，记录每轮做了什么、还剩下什么、后续智能体应注意什么。

3. 创建启动脚本。

例如init.sh，告诉后续智能体如何安装依赖、启动服务、运行基本检查。

4. 初始化git仓库。

每轮结束时提交。这样，后续智能体可以通过git log了解最近的变更，系统也能回滚、差异比较和审计。

后续的编码智能体大致做三部分：

1. 理解它们接收到的当前工程状态（定位）：确认当前工作目录，读取进度文件和任务列表，查看最近的git日志，运行端到端测试确认基本功能未损坏。

2. 选择并完成一个功能（选择、实现和验证）：选择优先级最高且未完成的功能，实现一个相对独立的增量，测试并评估该功能。

3. 将干净状态交接给下一轮，使当前代码能被下一个智能体理解：例如更新功能状态和进度文件并提交。如果新功能未完成，留下清晰的边界，而不是假装已完成。

长期运行智能体本质上是用多个短会话拼凑成一个长任务。如果每个会话都留下一点小混乱，错误会利滚利。因此，框架不仅应奖励“可验证的增量“，还应奖励它留下的系统状态。如果一个会话写了三个功能但破坏了启动流程，下一轮可能需要花大量token先恢复环境。长远来看，这样的进展实际上是负收益。

规划器/生成器/评估器三个角色

第一代框架解决了上下文交接问题，但仍有一个大问题：智能体不善于判断自己。因此，Anthropic引入了