每个智能体执行框架都面临同一个根本性限制:上下文窗口的容量,永远不足以容纳模型可能需要记住的一切。随着会话增长、文件读取扩展、子代理调用增多和工具输出累积,框架必须做出三个关键决策——哪些内容保留在工作集中,哪些内容被压缩,哪些内容留待后续检索。

这个问题的核心早已不是"提示词里应该放什么",而是"系统如何在时间维度上主动管理上下文"。表现优异的系统不再将上下文窗口视为被动的转录缓冲区,而是将其作为需要主动管理的资源:保持高价值状态就近可用,按需分页获取数据,构建索引以快速定位所需信息,并以暗示其他内容可访问的方式进行截断。

不同的执行框架做出了不同的选择,但它们正在收敛到一个相似的基础模式:上下文不再仅仅是能塞进转录里的所有内容,而是系统必须主动管理的对象。真正的设计问题在于——多少管理应该由框架承担,多少应该由模型自行完成。

图片

信任模型自主管理上下文

每一项上下文管理决策都编码了对模型行为的假设。核心问题是:框架应该主动约束上下文使用,还是依赖模型自行正确地管理这个预算。

文件读取是最具代表性的场景。当模型需要读取超出上下文容量的文件时,必须由某一方决定保留什么。主流框架普遍采用分页参数——偏移量和限制值——来支持分段读取。

图片

一种做法是框架优先策略:框架硬性保护上下文,然后教导模型学会分页。文件读取被设置严格的上限,无论是行数还是字节数,先到达者触发截断。截断后的输出附带明确的继续提示,告知模型还有多少内容未读取,以及如何获取下一段。工具描述本身也强化这一行为,引导模型在需要时使用偏移和限制参数。

另一种做法是纵深防御:在基础截断之上,叠加额外的预算层。启动时加载的上下文文件有独立的字符上限,所有启动文件有总预算限制。当单个文件超出预算时,采用首尾保留、中间裁剪的策略——保留开头和结尾,舍弃中间部分。工具输出结果又有独立的预算,当尾部看起来包含重要信息(如错误信息、结构闭合标记、摘要关键词)时,切换为首尾模式;否则仅保留开头。

还有一种做法是双层门控机制。第一层在文件打开之前就进行检查——通过元数据查询判断文件大小,超出阈值则直接拒绝读取,并在错误信息中指引模型使用分页或替代方案。第二层在读取之后运行——对输出进行 token 计数,捕获那些字节数在阈值内但 token 密度高的文件。两层限制都支持远程动态调整,无需发布新版本即可改变行为。

即使文件在限制之内,工具也默认返回固定行数,超长行被单独截断。模型必须显式请求更多内容。工具描述本身成为引导模型行为的重要载体——详细的说明文档解释分页机制、提及大小限制、涵盖多种文件格式支持,并鼓励并行读取多个文件。

去重机制同样值得关注。当模型在相同参数下重复读取同一文件且文件未发生变化时,框架返回存根而非完整内容,避免在上下文中产生重复 token。

还有一种独特的设计引入了持久化记忆层:基于版本控制文件系统的内存文件系统,代理的持久记忆以结构化文件形式存储。特定子目录下的文件被固定到系统提示中,始终保持在上下文内;目录外的文件仅以名称和描述可见,直到代理主动读取。代理通过文件在目录间的移动、层级重组和描述更新,自行管理渐进式披露。记忆编辑通过版本控制自动提交和同步。

这些不同方法的收敛点非常清晰:先检查再读取、行数限制、偏移和限制参数、继续提示、溢出到磁盘。而差异点则体现在是否引入持久化记忆层,以及这一层的开放程度。

会话裁剪:真正的工程难点所在

随着对话增长,每个框架都必须决定保留什么、丢弃什么。这是设计差异最具意义的地方,因为压缩策略直接决定了长时间运行的智能体是保持连贯性还是逐渐退化。

图片

第一种方案是基于大语言模型的摘要压缩。当上下文估算 token 数超过预留阈值时触发压缩。系统从对话末尾向前遍历,保留最近的固定量级 token 的消息。更早的内容被送入大语言模型进行摘要。摘要结果作为合成的用户消息,前置到保留的尾部之前。在整个过程中,工具调用与工具结果的配对完整性得到保护——系统不会在孤立的工具结果处截断,而是遍历边界确保配对完整。

第二种方案在基础压缩之上增加了分层机制。触发条件是历史记录超过上下文窗口的固定比例。历史被分割为等质量的 token 块,最旧的块被丢弃,其余保留并修复工具调用和结果的配对。被丢弃的内容经过多阶段多通道的大语言模型摘要,最终合并。在压缩执行前,一个静默的代理轮次让代理先将状态持久化到记忆文件中,防止历史信息消失时丢失关键状态。此外,还有非破坏性的内存工具结果裁剪机制,在固定的缓存周期上运行,保护持久对话的同时为当前请求回收上下文。

第三种方案结合了预查询优化和大语言模型压缩。在每个 API 调用之前——无论是否存在上下文压力——系统运行一条优化管线。过大的工具结果被持久化到磁盘并替换为精简预览,每个工具和每条消息都有独立的字符上限,确保即使在新会话的第一轮,大型工具输出也会被卸载。真正的压缩在上下文压力达到阈值时触发——此时完整对话被送入模型,配合结构化的多段提示词,涵盖主要请求、关键技术概念、文件与代码、错误与修复、问题解决过程、所有用户消息、待处理任务、当前工作和可选的下一步。摘要结果进入上下文后,最近读取的有限数量文件会在压缩后重新附加到上下文中。压缩器自身也有安全机制:模型生成的分析草稿和最终摘要分别输出,草稿在摘要进入上下文前被剥离,提升质量而不膨胀结果。如果压缩调用本身命中上下文限制,确定性的头部丢弃机制移除最旧的 API 轮次组。

第四种方案将压缩分为服务器端和客户端两个层面。服务器端处理大语言模型驱动的摘要,客户端通过流式 API 接收压缩事件并使用启发式方法估算本地上下文 token 使用。最具特色的是反射子代理机制:当压缩事件触发或达到可配置的消息计数阈值时,系统启动后台反射子代理。反射子代理接收最近对话的转录和父代理记忆的快照,然后编辑版本控制记忆仓库。完成后触发系统提示重新编译,使父代理获取新的记忆。反射提示设有预算上限。

知识的持久化迁移是这种方案的核心思想。重要的状态从临时对话历史迁移到持久的记忆文件中,减少了服务器需要通过压缩保留的内容量。在其他框架中可能丢失的信息,被持久化到代理随时可访问的文件中。这是对长期智能体记忆最具雄心的尝试。

子代理的上下文管理

在各个框架中,子代理通常与父会话隔离。没有一个框架会将父对话的完整历史记录复制到子代理中。真正的问题是:子代理继承了什么工作空间上下文。

图片

最简方案中,每个委派任务启动一个独立的进程和内存会话。子代理仅接收任务描述作为唯一的用户消息,不传递父对话历史。

默认情况下,子代理获得全新的隔离会话,不包含父转录。但存在一种分支模式,可以将父转录复制到子代理中,仅限于同类型代理的派生。工作空间上下文被过滤到最小的允许列表。

更复杂的方案提供两条路径。默认的类型化代理路径创建空白对话——委派提示成为唯一的用户消息,没有父历史。较新的分支路径则将完整的父消息历史传递给子代理,用于提示词缓存共享,加上合成的助手消息和占位工具结果。工具为工作代理重新构建并拥有独立的权限模式。异步代理获得显式的工具允许列表。

最丰富的子代理分类体系包含多种内置子代理类型。分支子代理调用会话分支端点,创建父完整消息历史的服务器端副本,使子代理拥有完整的对话轨迹。非分支子代理以全新的无头实例启动,任务提示作为唯一的用户消息。工具限制通过子代理定义中的工具字段处理,父代理的允许和拒绝规则传播到子代理。子代理结果有字符上限,完整运行转录写入磁盘。技能可以预加载到子代理中,技能内容作为标记块注入到用户提示之前。

设计的收敛点

比较这些框架的代码库后,最引人注目的不是它们的差异,而是它们的一致性。

所有框架都对文件读取设置硬性上限。所有框架都支持偏移和限制分页。所有框架都限制工具结果大小。所有框架都隔离子代理会话。所有框架都运行由 token 阈值触发的大语言模型压缩。所有框架都估算上下文使用率并检测压力。这不是巧合,而是对同一个工程问题的收敛性解决方案:一个固定大小的工作集必须感觉像是无限的。

收敛的深度不仅仅体现在拥有相同的功能上。具体的设计选择呈现出相似的韵律。头截断文件读取并附加继续提示,在不同框架中独立出现。超大工具结果持久化到磁盘,在多个框架中重复。压缩期间的工具调用和结果边界安全保护,在三个框架中一致。将父转录分支到子代理的能力,在多数框架中存在。这些框架独立地得出了相同的答案。

这种模式并不局限于编码代理。为数据探索而非代码编辑构建的产品,也独立地收敛到了相同的设计。工具结果设置独立的 token 预算并使用二分搜索找到适合上下文的最大数据集切片。通过修剪对话历史中重复的预览来去重幂等工具调用。将大型载荷拆分为压缩的大语言模型可见预览和模型可通过查询语言深入挖掘的完整服务器端副本——与文件读取中"将超大结果持久化到上下文之外"的模式相同。对长单元格值采用首尾截断并附带完整内容的反向引用。使用字符除以常数的启发式方法估算 token 压力,并在对话超过固定 token 阈值时强制检查点,此时模型在历史被裁剪前写入自己的状态摘要——结合了确定性压缩触发器和压缩前状态刷新的设计思路。子代理以所有框架都使用的隔离模式启动。一个为完全不同领域构建的产品,收敛到了相同的上下文管理剧本。

五十年的计算历史告诉我们:最好的内存管理是程序从不需要思考的那种。寄存器、缓存行、页表、交换区——每一层都由系统管理,每一层对上层都不可见。程序只需运行。

智能体框架正在朝着同一个方向演进。目标不是向模型展示一切,而是在恰当的时机给予它恰当的工作集,并允许它动态地做出决策来管理自身的上下文。

上下文管理正在从"如何装入更多信息"转向"如何在恰当的时机披露恰当的信息"。这或许就是智能体架构走向成熟的一个标志性信号。