Context as a Tool:Context Management for Long-Horizon SWE-Agents
Context as a Tool: Context Management for Long-Horizon SWE-Agents
在软件工程（SWE）领域，大型语言模型（LLM）驱动的自主代理正逐渐从简单的代码生成器演变为能够处理复杂、长程任务的系统性实体。然而，随着任务复杂度的提升，代理在与大规模代码库进行长达数百轮的交互时，面临着严峻的上下文管理挑战。传统的“追加式”上下文维护策略往往导致上下文爆炸、语义偏移以及推理崩溃 1。近期由 Liu 等人提出的 CAT（Context as a Tool）框架，通过将上下文维护提升为一种可调用、可规划的工具能力，为长程代理的稳定性与可扩展性提供了新的范式 1。本报告旨在深入探讨 CAT 框架的技术架构、数据生成管线、实验表现及其在 2025 年智能代理生态系统中的战略地位。
长程交互中上下文失效的根源分析
在软件工程任务中，如修复 GitHub 存储库级别的 issue，代理通常需要执行数十次甚至数百次的环境交互，包括文件读取、搜索、代码编辑和测试运行 1。大多数现有的代理架构，如 ReAct 框架，采用的是一种被动且线性的上下文增长模式。在这种模式下，所有的历史交互记录（Thought-Action-Observation）被持续地拼接在 Prompt 中。虽然这种方法在处理短程任务时能够保证信息的完整性，但在长程场景下，其弊端显而易见。
首先是上下文爆炸（Context Explosion）带来的成本与性能双重压力。随着对话轮次的增加，输入 Token 数量呈线性增长，这不仅显著提高了 API 调用成本，还带来了严重的推理延迟 4。根据 2025 年的行业观察，部分代理在处理复杂 issue 时，输入 Token 的比例高达 99%，而模型生成的有效 Token 仅占 1% 5。这种极低的 Token 利用率限制了代理在有限资源下的作业时长。
其次是语义偏移（Semantic Drift）与注意力稀释。Transformer 架构的注意力机制并非线性扩展，当上下文包含大量冗余的 Bash 输出或重复的搜索结果时，模型对初始任务目标（System Prompt）和核心用户意图（User Intent）的关注度会随之下降 6。这种现象被称为“上下文干扰”或“位置偏差”，会导致代理在任务后期忘却核心约束，甚至陷入逻辑循环或产生视觉幻觉 7。
最后是推理崩溃（Reasoning Collapse）。当上下文长度接近或超过模型的硬性窗口限制时，模型往往会出现性能骤降。即使是宣称支持超长上下文的模型，在检索位于文本中间部分的“干草堆中的针”时，其准确性也会大幅下降 10。在没有干预的情况下，代理往往在 60 轮交互左右便会达到饱和点，无法再从新的环境反馈中提取有效信息 1。
CAT 范式：将上下文管理作为一等公民工具
针对上述挑战，CAT 框架提出了一种根本性的变革：将上下文维护从一种系统层面的被动启发式机制，转变为模型决策过程中的一个主动、可学习的工具能力 1。这意味着，上下文管理不再是外部脚本在 Token 满溢时触发的截断，而是由模型根据当前任务进度和认知负荷，自主决定何时、如何进行信息的压缩与重组。
结构化上下文空间架构
CAT 将代理的上下文空间定义为一个动态更新的认知工作区，其逻辑结构可以表示为三个核心组成部分：
其中，Q 代表不可压缩的固定段，包含系统指令（System Prompt）和关键用户目标（Key User Intent），确保代理在整个生命周期内始终锚定核心任务 1。
M(t) 代表长期记忆段，存储经过高度浓缩的历史轨迹摘要，这部分内容随着任务的推进而动态演化，但始终保持紧凑的规模 1。
则代表高保真工作记忆，保留最近 k 个交互步骤的完整细节，以便模型能够对最新的环境反馈做出精准响应 1。
这种设计在认知心理学上具有深刻的对应性：
类似于人类的短期感知，而
类似于经过加工后的语义记忆。通过这种层次化的存储结构，CAT 能够在有限的上下文预算内，同时维持宏观的任务视野和微观的操作精度 7。
工具化上下文管理机制
在 CAT 框架中，上下文管理被建模为一个标准的 Tool 调用。当代理生成的 Thought 认为当前子任务已完成或上下文负荷过重时，它会主动调用 context 工具 1。这一操作被称为“主动折叠”（Proactive Folding）。折叠过程不是简单的文本修剪，而是对历史信息的语义提炼。代理会对压缩区间内的关键决策点、尝试过的策略及其成效、显著的环境状态变化以及后续仍需遵循的约束进行提取 1。
这种“工具化”设计的核心优势在于透明性与可控性。模型明确知道自己正在进行压缩，并能够生成指向压缩后摘要的引用。这与 OpenHands 等系统中常见的被动触发压缩不同，后者往往导致模型在不知情的情况下丢失重要历史，从而产生幻觉 1。
CAT-GENERATOR：轨迹级监督框架与数据生产
为了让模型内化这种工具化的上下文管理能力，CAT 引入了 CAT-GENERATOR，这是一个旨在解决“缺乏上下文管理数据”问题的离线数据构建管线 1。由于现有的 SFT 数据集（如 SWE-smith 或 SWE-ReBench）大多记录的是原始交互轨迹，直接训练无法让模型掌握何时调用压缩工具。
第一阶段：基础 ReAct 轨迹生成
CAT-GENERATOR 首先部署一个标准 ReAct 代理，在禁用上下文管理工具的情况下解决 SWE 任务 1。通过在受控环境中运行，该阶段捕获了大量的成功解决路径，这些路径保留了完整的中间推理、失败模式和详细的环境反馈。这些原始轨迹为后续的“折叠”操作提供了丰富的原始材料 1。
第二阶段：轨迹重构与压缩算子注入
在获得原始轨迹后，框架会对其进行回顾性重构。这一过程的关键在于确定“压缩点”（Condenser Points）。CAT-GENERATOR 并不依赖固定的 Token 阈值，而是综合考虑多种信号来确定压缩时机：
| 触发信号类型 | 描述与判断标准 | 意义 |
|---|---|---|
| 结构化边界信号 | 子任务完成、策略切换或达成中间里程碑 | 确保在任务阶段转换处进行逻辑总结 |
| 上下文膨胀信号 | Token 数量持续增长导致注意力效率下降 | 维持计算效率与模型推理稳定性 |
| 纠错修正信号 | 在经历多次失败后探索出新的可行方向 | 抛弃无效的失败细节，仅保留成功转折点 |
在确定压缩点后，框架调用高能力的大规模语言模型作为“总结器”，将指定区间内的详细记录转化为高保真摘要 1。随后，这些摘要被注入回原始轨迹中，作为 context 工具的 Observation 返回值。这种重构不仅保持了任务解决逻辑的连贯性，还为模型提供了如何使用压缩后信息的正面示范 1。
拒绝采样与数据集优化
为了确保 SFT 数据的质量，CAT-GENERATOR 实施了双层拒绝采样策略。在轨迹层面，剔除所有未能成功解决问题或陷入不可恢复错误状态的样本 1。在步骤层面，移除那些展现出不合理管理行为的样本，例如频繁调用工具却未带来信息增益，或者压缩导致关键语义丢失的案例 1。最终形成的 CAT-Instruct 数据集包含约 20,000 个高质量实例，涵盖了长程交互中的多种场景。
| 指标 | 统计数据（CAT-Instruct） |
|---|---|
| 平均轨迹步数 | 87.4 |
| 最大轨迹步数 | 500 |
| 平均上下文 Token 数（压缩后） | 13,044 |
| 平均每条轨迹上下文管理动作数 | 4.22 |
| 平均压缩率 | 30% |
SWE-Compressor：性能评估与实证研究
基于 Qwen2.5-Coder-32B 模型进行微调得到的 SWE-Compressor 是 CAT 框架的首个实例模型 1。在 SWE-Bench-Verified 这一具有挑战性的基准测试中，该模型展示了卓越的性能。
主流代理系统横向对比
在 2025 年末的竞争格局中，SWE-Compressor 与顶级闭源模型及其他开源 SOTA 模型进行了对比。
| 代理系统名称 | 底座模型规模 | 框架类型 | SWE-Bench Verified 解决率 | 平均成本 (USD) |
|---|---|---|---|---|
| Claude 4.5 Opus | - | 闭源专有 | 74.4% | 0.72 |
| Gemini 3 Pro | - | 闭源专有 | 74.2% | 0.46 |
| GPT-5.2 | - | 闭源专有 | 71.8% | 0.52 |
| SWE-Compressor (CAT) | 32B | OpenHands | 57.6% | 较低 |
| Qwen3-Coder | 480B | OpenHands | 55.4% | 0.25 |
| Claude 3.5 Sonnet | - | Agentless | 38.8% | - |
| DeepSeek-R1 (Jan 2025) | 671B | OpenHands | 45.6% | 极低 |
实验结果表明，SWE-Compressor 尽管模型参数量远小于 GPT-5 或 Qwen3-Coder 的全参数版本，但在同等微调预算下，其解决率显著超越了传统的 ReAct 代理和基于静态阈值压缩的代理 1。这证明了主动上下文管理在提升模型“有效智力”方面的巨大潜力，特别是在资源受限的情况下。
上下文稳定性与长程可扩展性
分析 500 个交互轨迹的 Token 使用曲线可以发现，SWE-Compressor 的平均 Token 消耗在交互进行到约 100 轮后迅速趋于稳定，并始终保持在 32k Token 以下 1。与之形成鲜明对比的是，标准 ReAct 代理的上下文会持续线性增长，直到触发窗口溢出并被迫停止，导致其在超过 60 轮的任务中表现出极高的失败率 1。
此外，轨迹存活率分析显示，超过 40% 的复杂任务需要超过 100 轮的交互才能解决 1。在这种情况下，CAT 框架赋予模型的“长程耐力”成为了攻克中高难度问题的关键要素 1。
任务难度分层表现
CAT 框架的优势在不同难度的任务中表现出非对称性。在针对 SWE-Bench-Verified 的难度分层分析中：
- 简单任务（Easy，<15分钟）：CAT 与 ReAct 表现接近，因为这类任务通常在上下文爆炸前即可解决 1。
- 中等任务（Medium，15-60分钟）：CAT 开始表现出显著优势，解决了大量 ReAct 因语义偏移而失败的案例 1。
- 困难任务（Hard，>60分钟）：CAT 带来的性能提升最为显著。在需要大规模代码重构或跨多个模块调试的场景下，CAT 的折叠机制能够过滤掉琐碎的编译错误细节，让模型专注于宏观的重构逻辑 1。
行业比较：CAT 与同类竞争框架的深度辨析
在 2024 至 2025 年间，上下文管理成为了代理研究的热点领域。除了 CAT，市场上还出现了 Context-Folding、MemGPT、Sculptor 等方案。
CAT vs. Context-Folding (Sun et al.)
ByteDance 提出的 Context-Folding 与 CAT 在思路上高度一致，都强调通过“分支与折叠”来缩减上下文 10。然而，两者的实现路径存在差异：
| 维度 | Context-Folding (Sun et al.) | CAT (Liu et al.) |
|---|---|---|
| 学习方法 | 基于 FoldGRPO 的强化学习 | 基于 CAT-GENERATOR 的轨迹 SFT |
| 奖励机制 | 过程奖赏（Process Reward）引导分解 | 专家轨迹模仿与拒绝采样 |
| 实现复杂度 | 较高，需要大规模 RL 基础设施 | 较低，更易于在中型模型上迁移 |
| 性能表现 | 在极小上下文下达到 58% 15 | 稳定在 57.6% 1 |
Context-Folding 通过强化学习探索出的折叠策略可能在某些特定场景下更具灵活性，但 CAT 证明了通过高质量的离线轨迹模拟，即使不依赖复杂的 RL 过程，也能达到类似的 SOTA 水平 11。
CAT vs. MemGPT
MemGPT 将 LLM 上下文类比为计算机内存管理，引入了外部向量数据库作为“磁盘”，并使用特定的控制指令在内存与磁盘间调度 12。CAT 与其最大的不同在于，CAT 倾向于在“主内存”内通过语义摘要实现“原位压缩”，而 MemGPT 依赖检索增强（RAG）来从外部提取信息。在软件开发这种对因果关系和步骤顺序极其敏感的任务中，CAT 提供的语义连续性摘要通常比离散的 RAG 检索更具逻辑一致性 11。
CAT vs. Sculptor 与 AgentDiet
Sculptor 框架强调将模型作为“雕刻家”，主动剔除上下文中的干扰片段 8。而 AgentDiet 则更侧重于通过推理过程的轨迹缩减来降低推理成本 5。相比之下，CAT 的“工具化”属性更强，它不仅是一个修剪器，更是一个能够将历史经验转化为结构化知识的“知识整合器” 1。
2025 年的上下文工程趋势与商业价值
从 2025 年的技术生态来看，CAT 所代表的“主动上下文管理”已成为企业级代理部署的必备技术。随着模型从“万亿参数竞赛”转向“效率与推理成本优化”，如何以最少的输入 Token 维持最高的逻辑保真度成为了核心竞争力 19。
企业成本与 ROI 分析
对于实施大规模自动化运维或代码迁移的企业，代理的运行成本直接决定了方案的可行性。
| 交互规模 | 传统 ReAct 成本估计 (1M tokens) | CAT 优化后成本估计 | 预计节支额度 |
|---|---|---|---|
| 100个 issue | $19,600 | $11,800 | 39.8% |
| 1000个 issue | $254,000 | $27,500 | 89.2% |
这种成本缩减（最高可达 80% 以上）使得原本因经济性问题而无法落地的长程自动化项目变得可行 5。
推理一致性与减少幻觉
由于 CAT 的折叠机制是在模型内部完成的语义转化，它不仅减少了 Token 数量，还起到了“噪声过滤”的作用。在长达数百步的修复过程中，模型通过不断的阶段性总结，修正了执行过程中的微小偏差，从而显著降低了长尾任务中的幻觉产生率 7。
技术前瞻：多模态与自主进化
展望未来，上下文管理工具将不仅仅处理文本数据。随着多模态代理（如具备视觉能力的 Claude 4.5）的普及，CAT 的折叠机制将需要能够同时摘要图像信息（如 UI 截图或调试图表）和执行日志 19。此外，“实时自我进化”也将是一个重要方向。未来的代理（如 Live-SWE-agent）可能会根据当前任务的复杂度，实时动态调整压缩的粒度和摘要的深度，从而实现更高级别的自主性 23。
结论与行动建议
CAT 框架通过将上下文管理内化为模型的一种可调用工具，打破了长程 SWE 代理面临的“上下文瓶颈”。其核心贡献在于：首先，提出了一种 三层结构化上下文空间，平衡了目标的稳定性与操作的精细度；其次，通过 CAT-GENERATOR 解决了上下文管理动作的监督学习难题，训练出了具有高度自律性的 SWE-Compressor；最后，在实际测试中证明了这种方法在提升解决率的同时大幅降低了计算成本 1。
对于软件工程团队和 AI 系统架构师而言，集成类似于 CAT 的主动管理机制已成为必然选择。它不仅能提升代理处理复杂逻辑的能力，更是在推理成本日益高昂的背景下实现技术落地的重要路径。在未来的代理设计中，上下文管理不应被视为底层的透明操作，而应被视为模型“元认知能力”的核心体现 1。
