长任务 Agent 为什么会越跑越贵：从 reasoning 保留到上下文压缩的 API 路由实践

一个 AI 编程代理看起来只是在执行“修复这个 bug”，实际上可能连续经历几十次模型请求：读取仓库、定位文件、调用工具、运行测试、分析失败、修改方案，再次执行。任务越长，越容易出现两个相反的问题：模型忘记了前面已经推导出的结论，或者上下文越来越大，导致每一步都更慢、更贵。

7 月 29 日，OpenAI 公布了一项 ARC-AGI-3 工程实验。相同的 GPT-5.6 Sol，在通用测试 harness 中的公开任务得分为 13.3%；保留 reasoning、并用 compaction 替代滚动截断后，得分达到 38.3%，同时输出 token 减少约 6 倍。这个结果不是“某个模型突然变聪明了”，而是说明长任务的表现很大程度取决于 API 状态管理和 harness 设计。

这对使用多个模型、多个 Agent 工具的开发团队有一个直接启发：模型路由不能只在第一轮请求时选择供应商，还要管理每一轮的上下文状态、推理预算和压缩时机。

这次实验真正比较的是什么

ARC-AGI-3 是一个交互式推理基准。Agent 需要在没有明确文字教程的二维环境中探索、学习规则、建立可适应的世界模型，并在多步行动中完成目标。官方基准强调的是学习效率、长程规划、稀疏反馈和跨步骤适应，而不是一次回答是否正确。

OpenAI 的实验发现，原始 harness 有两个会放大长任务难度的设置：

每次行动后丢弃模型的私有 reasoning。模型还能看到过去动作的简短记录，却不能看到自己此前形成的计划和判断。
上下文超过限制后采用 rolling truncation，直接丢掉较早的消息。模型不仅失去思考过程，也可能失去发现环境规律所需的早期观察。

改用 Responses API 后，实验保留了 reasoning，并使用 compaction 生成更小的上下文窗口。公开任务上，GPT-5.6 Sol 的 RHAE 得分从 13.3% 上升到 38.3%。OpenAI 同时报告，开启这两个设置后，得分约提升 3 倍，输出 token 约减少 6 倍。这个数字来自 OpenAI 自己的实验，不应直接当作所有业务工作负载的预期收益；它更适合用来说明状态设计会改变评测结果。

reasoning 保留不是“把思维链写进日志”

Reasoning 模型会产生不可见的 reasoning tokens，用于规划、调用工具、比较方案和处理歧义。它们仍然占用上下文空间，也计入输出 token 使用量。API 使用者需要解决的是：在下一轮请求中，如何让模型继续使用必要状态，而不是把内部推理内容暴露给用户或业务日志。

OpenAI 的 reasoning 文档建议在多步工作流中优先使用 Responses API。对支持的 GPT-5.6 模型，可以通过 previous_response_id 继续对话状态；如果采用无状态的输入数组链式调用，则应把上一轮输出（包括 compaction item）追加到下一轮输入。

这也解释了为什么“每轮都把摘要重新塞进 prompt”不是完整替代方案：摘要可能遗漏工具结果、未完成的计划或状态变化，而且摘要本身也会重复消耗输入 token。更合理的做法是把模型状态和业务审计分开：

数据	用途	是否适合直接写入业务日志
用户消息、工具参数、工具结果	复现任务与审计	视敏感数据策略而定
response id、模型、路由决策	继续调用和归因	适合记录
reasoning 状态与 compaction item	让模型延续任务	按供应商的隐私和保留策略处理，不要当可读文本解析
token usage、延迟、错误码	成本与可靠性治理	适合记录

compaction 和滚动截断不是一回事

滚动截断的逻辑是“太长了就删掉最早的内容”。它实现简单，却无法判断哪些信息是任务的关键状态。compaction 则由模型服务生成一个新的、压缩后的上下文窗口，保留后续推理所需的状态。OpenAI 文档说明，返回的 compaction item 是加密且不可读的，不应被应用层拆解或手工裁剪。

Responses API 提供两种使用方式：

服务端 compaction：在请求中设置 context_management 和 compact_threshold。当渲染后的 token 数越过阈值，服务端在同一条响应流中触发压缩。
独立 compact endpoint：应用自己决定何时调用 /responses/compact，把完整窗口交给接口，再把返回窗口原样作为下一次 /responses 的输入。

服务端模式适合大多数持续对话和 Agent 循环，独立接口则适合需要在网关层统一控制阈值、租户预算和重试策略的场景。无论选择哪种模式，都不要把 compaction 输出当作普通文本摘要处理，也不要只保留其中一个 item。

API 网关应该路由什么

当 Agent 进入长任务阶段后，路由对象至少有四层。只按模型名做静态转发，会错过真正影响成本和稳定性的变量。

1. 按任务阶段路由

规划、代码定位和最终验证可能需要不同能力。可以把“探索/分类”交给低成本模型，把涉及复杂依赖分析和跨文件修改的阶段交给高推理模型；但一旦任务已经建立了上下文，不应为了换模型而丢失整个状态。网关需要明确哪些状态能跨供应商迁移，哪些状态只能留在同一模型家族。

2. 按上下文预算路由

请求进入网关后先测量输入 token、工具 schema 和历史输出，而不是用字符数估算。OpenAI 的 input token counting API 支持文本、图片、文件、工具和完整对话结构，可用于发送前估算。网关可以据此决定：压缩、切换上下文更大的模型，或拒绝明显超出预算的请求。

3. 按推理预算路由

reasoning.effort 不是越高越好。低难度分类和短工具调用可使用较低 effort；复杂调试、长程研究和安全审查才值得更高预算。由于 reasoning tokens 也会计入输出 token，成本策略应同时记录 output_tokens_details.reasoning_tokens，不能只看可见文本长度。

4. 按状态和失败类型路由

超时、限流、上下文超限、供应商暂时不可用和模型输出不完整，不应共用一个 fallback。网关可以保留任务级状态，区分“可以在同一 response 状态上重试”和“必须开启新会话”。如果发生跨供应商降级，至少要记录原模型、目标模型、压缩次数、重试次数和状态丢失风险。

一套可落地的长任务控制流程

下面的流程适合代码代理、研究 Agent 和带 MCP 工具的自动化任务：

建立任务预算：为每个任务设置最大 wall-clock 时间、模型调用次数、输入 token、输出 token 和金额上限。
保留可续接状态：优先使用供应商支持的 response chaining；网关保存 response id、租户和任务 id 的映射，不保存未经必要性评估的敏感正文。
预估再发送：在每轮调用前统计消息、工具 schema、文件和图片的实际输入 token，预留 reasoning 与可见输出空间。
提前压缩：不要等到请求因为上下文超限而失败。根据 token 阈值触发服务端 compaction，或调用独立 compact endpoint。
记录路由决策：把模型、reasoning effort、压缩阈值、fallback 原因和最终 usage 写入统一账本。
区分可恢复错误：对限流和临时 5xx 做带预算的重试；对 max_output_tokens 导致的不完整响应，增加 headroom 或调整 effort；对状态损坏则停止自动重试并交给人工检查。
用真实任务评测：不要只比较单轮问答分数。把工具调用成功率、任务完成率、总 token、端到端延迟和人工接管次数一起纳入评测。

成本治理的三个误区

误区一：把模型单价当成任务成本。 长任务真正的成本包含多轮输入、reasoning tokens、工具结果、重试和压缩调用。相同模型在不同 harness 下，账单和完成时间可能完全不同。

误区二：把截断当成压缩。 删除旧消息会让上下文变小，但不保证保留关键状态。对于需要学习和持续修正的 Agent，截断可能降低成功率，最终反而增加重试成本。

误区三：只在应用代码里做路由。 每个 Agent 自己实现预算、重试和 fallback，最终会造成指标口径不一致，也很难比较供应商。把 token 计量、状态标识、限流和审计放在统一 API 控制层，才能在模型变化时保留可迁移的策略。

结语：评测的是模型，也评测了你的 harness

ARC-AGI-3 的实验把一个常被忽略的事实摆到台面上：评测结果不只由模型权重决定，还由 API 设置、上下文窗口、工具封装和状态管理共同决定。对于生产 Agent，最先要做的不是盲目升级到更大的模型，而是确认任务是否保留了必要推理、是否会在长时间运行中失去早期状态，以及成本是否能按任务解释。

一个统一的模型调用网关可以把这些变量变成可观测、可配置的策略：在发送前数清输入，在运行中保留状态和压缩上下文，在失败时按错误类型降级，在结束后把 token、延迟和结果归因到任务。这样，模型路由才不只是“把请求转发到另一家供应商”，而是长任务 Agent 的记忆、预算与可靠性控制层。