让 Agent 性能翻三倍的两个 API 参数——以及它们对路由层的真正含义

本周 OpenAI 发布了一篇工程文章，起点是一道 benchmark 谜题，落点是一个对 operator 的明确要求：如果你的路由层会丢弃 reasoning token，或者在上下文管理上回退到滚动截断，那么它正在悄悄降低每一次 GPT-5.6 agent 调用的质量。

核心发现是：retained reasoning 与 compaction 将 GPT-5.6 Sol 在 ARC-AGI-3 上的得分从 13.3% 提升到 38.3%，同时将输出 token 减少 6 倍。这个结果作为 benchmark 数字不是最重要的，它重要的地方在于：Responses API 与 Chat Completions 在 API 语义上存在根本差异，而这些差异直接影响 agent 工作负载的路由决策。

两个参数各自做了什么

Retained reasoning 通过在 Responses API 请求中传递 previous_response_id 来实现。如果不传递，GPT-5.6 Sol 每轮的私有 reasoning token 在返回后会被丢弃。模型能看到历史操作记录，但看不到产生这些操作的推理过程，因此每一步都需要从头重建对任务的理解。启用 retained reasoning 后，模型每步消耗的计算量更少，同时能构建连贯的多步策略。

Compaction 取代了滚动截断。当 Chat Completions 对话触及上下文限制时，标准做法是丢弃最早的消息。Compaction 则将对话压缩成精简表示，保留模型在会话早期学到的内容。OpenAI 使用 175,000 token 的上限，并在上下文增长时进行压缩而非截断。

具体的 API 变更如下：

// 之前：Chat Completions，每轮推理被丢弃
POST /v1/chat/completions
{ "model": "gpt-5.6-sol", "messages": [...history...] }

// 之后：Responses API，通过 previous_response_id 保留推理
POST /v1/responses
{
  "model": "gpt-5.6-sol",
  "previous_response_id": "<上一次响应的 id>",
  "input": "<下一轮用户输入>"
}

当你通过 previous_response_id 链式调用 Responses API 时，compaction 会自动生效，无需自己实现摘要步骤。

为什么这是路由层决策，而不只是模型选择

如果你的 gateway 将 GPT-5.6 请求转发到 Chat Completions endpoint，你运行的并不是 OpenAI 在 ChatGPT 和 Codex 中实际部署的配置，而是 OpenAI 明确指出会导致 agent 性能下降 3 倍的配置。

这对路由团队有三个具体影响：

Endpoint 路由：Chat Completions（/v1/chat/completions）和 Responses API（/v1/responses）是两个语义不同的 endpoint，上下文管理方式完全不同。如果路由规则将两者视为可互换的，当 fallback 配置错误时，针对 Responses API 优化的工作负载会被悄悄发往错误的 endpoint。

状态透传：Responses API 使用 previous_response_id 串联各轮对话。如果你的 proxy 或 gateway 截断或未能转发这个字段，推理链就断了。如果中间件将请求标准化为无状态格式，每一次多轮 GPT-5.6 agent 调用都会被降级。

Token 计费模型：Responses API 中的 reasoning token 会计入用量统计，但它能降低后续轮次的计算消耗。如果你的成本模型将 reasoning token 输出视为浪费，并用路由规则尽量压低它，结果正好适得其反。

Operator 需要做的跨 provider 对比

这个配置差距之所以在 OpenAI 这里特别明显，是因为 GPT-5.6 的架构将私有 reasoning token 与输出 token 分开处理，而跨轮次保留推理需要显式的 API 配套。

Anthropic 的 extended thinking 机制不同：reasoning token 以 thinking content block 的形式嵌入消息结构，通过普通的 assistant 轮次传回，而非独立的 response chain ID。

DeepSeek 的 V4 Pro 和 V4 Flash 支持 thinking 模式，但没有自动 compaction 的 Responses API 等价物，operator 需要自行实现上下文管理。

Gemini 的 session API（Gemini Agent Platform）采用不同的 session-token 架构，内存管理通过 session 而非 response chain 来处理。

对路由层的启示：如果你向下游调用方提供统一的 Chat Completions 接口，需要为哪些功能被模拟、哪些被丢弃、哪些需要调用方直接使用原生 endpoint 制定明确的策略。

这个 benchmark 真正测量了什么

OpenAI 的文章说得很直接：「benchmark 几乎从不单独测量模型，它同时测量一系列不那么显眼的 API 参数选择、测试框架设计和 prompt 策略。」

ARC-AGI-3 使用了滚动截断并丢弃推理，这是大多数第三方 eval 框架的默认行为。结果是 13.3% 的得分，远低于模型的真实能力。同一个模型在与生产环境匹配的配置下得分 38.3%，接近人类基线 48%。

这对路由 tier 决策是一个重要的纠偏信号。如果你依据公开 benchmark 结果在 provider 之间做选型，而这些 benchmark 使用的是默认 Chat Completions 配置，你可能在用运行最优配置的 A provider 对比运行降级配置的 B provider。

运行 GPT-5.6 agent 工作负载的 operator 现在需要审查的内容

对于将任何多步或长 horizon agent 工作负载路由到 GPT-5.6 的团队：

• Endpoint 检查：你的路由配置是将 agent 工作负载发往 /v1/responses 还是 /v1/chat/completions？这个区别直接影响推理的保留方式。
• 状态转发：你的 gateway 是否在各轮之间转发 previous_response_id，还是从本地上下文缓冲区重建无状态请求？
• Fallback 行为：如果 Responses API 返回错误而 gateway 回退到 Chat Completions，fallback 是否保留还是丢弃了推理状态？
• 成本模型：Responses API 中的 reasoning token 计数反映的是跨后续轮次的延迟计算节省。纯粹按单次调用 token 成本优化，会误判 retained reasoning 工作负载的实际效率。

OpenAI 对 API 开发团队的推荐：使用 Responses API（而非 Chat Completions），通过 previous_response_id 保留推理，并启用 compaction。这些现在是 GPT-5.6 agent 工作负载的生产级配置标准。