OpenAI Responses API 上下文太长怎么压缩：/responses/compact 与状态续接边界

带工具调用的客服代理跑到十几轮之后，最先出问题的往往不是模型本身的能力上限，而是请求里塞了太多冗余旧消息：上下文占满额度，延迟一路走高，下一轮说不定直接因为输入超长报错。OpenAI Responses API 已经自带专门的 compaction 处理路径，可以把冗长的历史会话压缩成能直接复用的 items 集合，这套机制根本不是简单把最早的文本截掉那么粗糙。

先判断：到底是上下文溢出，还是业务状态丢了

Responses API 搭建的多轮代理通常会同时累积用户消息、模型输出、推理项、工具调用记录和工具返回结果。真正容易踩坑的从来不是单条消息体积大，而是每一轮都把上一轮的完整历史全量带上，工具调用循环又把原始返回结果不断追加进去。日志里最常见的表现是输入token量持续攀升，模型还没抛错，耗时和调用成本已经开始异常上涨。

这里要先把两类问题分开：上下文体积超限需要做压缩；业务逻辑缺字段要做状态持久化补全。压缩只能整理模型侧的上下文内容，绝对替代不了订单号、权限、租户ID这类应用层数据的持久化存储。

方案演进：从手工摘要到原生 compaction 能力

早期大家常用的思路是直接让模型把历史对话总结成一段摘要文本，再把这段摘要当成下一轮请求的输入。这个方法实现门槛很低，但很容易碰到两个绕不开的边界问题：摘要很容易漏掉工具调用的结构化结果，纯文本摘要也很难完整还原模型对历史状态的上下文理解。

Responses API 的 compaction 接口返回一组可以直接复用的 items，里面包含特殊的 type=compaction 项。官方文档说明里，这个项携带的是模型生成的加密、极致节省token开销的状态表示，上层应用不要尝试解析或者自行改写其中的 encrypted_content。

Go 客户端对接：先执行压缩，再用返回的 items 续接会话

下面的代码只展示请求边界逻辑，SDK 的具体类型名请以你项目当前用的版本为准。核心注意点是：压缩请求传完整或者经过筛选的历史会话，拿到 compaction 返回结果之后，把接口返回的 items 直接当成下一次 Responses 请求的输入，不要自作主张转成一段普通字符串再拼接回去。

type CompactRequest struct {
    Model string        `json:"model"`
    Input []interface{} `json:"input"`
}

type ContinueRequest struct {
    Model string        `json:"model"`
    Input []interface{} `json:"input"`
}

func compactAndContinue(ctx context.Context, client *http.Client, baseURL string, history []interface{}) error {
    compactBody := CompactRequest{Model: "gpt-5", Input: history}
    compactItems, err := postJSON[[]interface{}](ctx, client, baseURL+"/responses/compact", compactBody)
    if err != nil {
        return fmt.Errorf("compact response state: %w", err)
    }

    next := ContinueRequest{Model: "gpt-5", Input: compactItems}
    _, err = postJSON[map[string]interface{}](ctx, client, baseURL+"/responses", next)
    return err
}

这段示例故意把未知字段留在 []interface{} 里，因为不同 SDK 版本对 item 联合类型的封装逻辑可能存在差异。实际接入的时候，建议保留返回的原始JSON字段方便排查问题，不要只存最终渲染出来的文本内容。

触发时机：阈值只是参考，状态检查才是执行门槛

可以把token计数或者响应元数据接入一个简单的状态机：正常运行、接近阈值、压缩中、压缩完成、续接回归。触发阈值不要硬编码成某个模型的最大上下文上限，模型类型、工具输出长度和部署配置都会改变实际可用的上下文空间。

1. 先记录本轮输入token量、历史item总数量和工具返回结果的体积。
2. 到达项目预设的软阈值时，停止继续追加大型原始工具结果，只保留必要摘要或者关联引用。
3. 调用 compaction 接口，检查HTTP返回状态、返回项数量以及是否存在合法的compaction项。
4. 用压缩得到的结果先跑一次低风险验证请求，核对任务ID、权限约束和工具调用上下文是否正常。

不要在每一次请求前都无条件触发压缩。压缩本身也有网络开销，频繁调用反而会让短会话的响应速度变慢，更合理的触发逻辑是软阈值自动触发，调用失败的时候保留原始会话，进入可观测的降级处理路径。

回归校验：压缩后这些项必须保持可访问

压缩接口调用成功不代表代理的行为逻辑完全正确。至少提前准备一组固定的回归校验用例：让代理复述一个早期给出的业务约束、引用一个工具返回的ID、拒绝一个没有权限的操作，再发起一次全新的工具调用。每次都记录压缩前后的输入体积和输出结果差异。

• 状态层面：租户、用户、任务和幂等键是否和压缩前完全一致。
• 工具层面：上一轮还没跑完的未闭合调用有没有被误判为已完成。
• 安全层面：隐藏提示、密钥、个人敏感信息有没有进入不必要的持久化日志。
• 恢复层面：压缩接口超时之后，能不能继续用未压缩的历史会话处理，避免重复提交带副作用的操作。

常见问题

compaction 可以替代业务侧数据库存储吗？

不行。订单状态、权限、计费和任务进度这类核心数据仍然要由应用数据库或者任务调度系统保管，compaction 只负责整理模型运行需要的会话上下文内容。

可以只单独保留 compaction item 吗？

不能一概而论。后续请求里需要依赖的高价值上下文仍然要按照官方接口要求保留，上层应用直接用接口返回的全部items就行，不要自行删掉看起来好像重复的结构化项。

压缩调用失败的时候要不要立刻重试带副作用的工具？

不要。先确认压缩请求本身有没有在服务端执行完成，再对照幂等键和业务侧的实际状态判断要不要重试，避免支付、发货或者写入类操作被重复触发。

怎么判断压缩操作真的生效了？

同时观测输入token量、历史item数量、请求延迟和回归任务结果这几个指标，只看下一轮请求能返回文本，根本证明不了上下文和工具状态都被正确保留下来。

把压缩当成一次可回滚的状态迁移

对于长会话场景来说，compaction 本质上更像一次可回滚的状态迁移：先保存好原始会话的全量引用，再生成压缩后的items集合，跑完低风险续接验证之后才切换到新的压缩状态。就算压缩服务临时出问题，也能回退到旧的未压缩历史，或者转交给人工介入处理。把这个边界逻辑做扎实，代理才不会莫名其妙因为“上下文变短”就跑出不可解释的异常行为。