Grok API上下文太长怎么办？Compaction压缩、完整output与续聊核对

一段Grok API对话积累很多轮工具输出后，每轮重发全文会增加负担。Compaction把旧上下文压缩成可续用的不透明项目，再接新问题。它与previous_response_id延续会话、前缀缓存不是同一功能，本文只讲客户端已有历史的压缩和恢复闭环。

第一步：判断是否应该压缩

官方建议在会话已大到影响输入成本或延迟、仍需记住此前内容，并且仍能放进模型窗口时使用。已经context_length_exceeded的请求不能直接靠Compaction救回，应先合理拆分或缩减。短对话也不必每轮压缩，因为压缩本身使用token。

准备开发者API访问和兼容OpenAI SDK，使用XAI_API_KEY环境变量。示例采用当前文档的grok-4.7，不运行真实付费调用。先保留一份原始会话快照与会话归属，不能将不同用户历史一起压缩，也不能在失败前就删除恢复材料。

第二步：构造可核对的练习历史

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["XAI_API_KEY"],
    base_url="https://api.x.ai/v1",
)
history = [
    {"role": "system", "content": "只按对话已知条件回答，未知信息明确说明。"},
    {"role": "user", "content": "练习活动叫星河读书会，预算单位为元，只在线上举办。"},
    {"role": "assistant", "content": "已记录活动名称、预算单位和线上形式。"},
]

这份短样本用于验证接口与状态衔接，不用于证明节省成本。真实长会话可以另外选一份有权限的脱敏材料，列出必须保留的约束、最新决策和未完成事项；检查时不能只问一个无需历史也能回答的常识问题。

第三步：压缩并原样保留返回output

compacted = client.responses.compact(
    model="grok-4.7", input=history
)
if len(compacted.output) != 1 or compacted.output[0].type != "compaction":
    raise RuntimeError("结果形状异常，保留旧历史")
print(compacted.id)
print(compacted.usage.input_tokens, compacted.usage.output_tokens)
print(compacted.usage.dropped_message_count)

REST入口为POST /v1/responses/compact。返回output中的compaction包含id与encrypted_content，应当作完整不透明状态保存，不能解码、编辑、拼接两个加密块或只摘录其中一段。日志保留请求标识与必要用量即可，不必将整块内容展示给最终用户。

第四步：替换旧历史并继续提问

followup = client.responses.create(
    model="grok-4.7",
    input=[
        *compacted.output,
        {"role": "user", "content": "根据刚才约定，活动名称、预算单位和举办形式分别是什么？"},
    ],
)
print(followup.output_text)

新的input以整个compacted.output开头，后接新轮次，不要再把同一份被压缩旧历史塞回前面。也不要拿虚构cmp编号替换真实返回值。应用持久化时保留完整JSON及所属会话，并通过正常序列化还原，不能用字符串裁剪来适配数据库字段长度。

第五步：验收、比较与回滚

样本续聊应准确回忆星河读书会、元和线上三点。真实任务还应核对关键文件标识与未完成工作。压缩不是逐字归档，重要原始证据仍应保存在业务系统里；无法核对的细节应重新提供，而不是诱导模型声称全部记得。

记录压缩调用本身的input_tokens、output_tokens与dropped_message_count，再比较后续请求的输入量与任务质量，不能只看某轮变快就宣称节省固定比例。调用失败或结果不完整时保留旧历史，不切换状态；再次增长后可以重新压缩，但每次仍应完整保存新的output。

验收：会话未超限；原历史可恢复；返回一个完整compaction；新消息位于其后；关键约束一致；没有混入其他用户状态；压缩与续聊用量分别记录；失败未覆盖有效状态。

将原历史压缩为新状态时，应用要绑定准确的历史版本。若后台仍有新消息写入，先检查版本再切换，不把压缩开始之后的消息意外丢弃。这个教程先用同步等待避免并发；正式接入后再考虑事务和版本控制。也应区分原始资料存储与模型活动上下文，压缩不会自动删除业务系统里保留的原文件。

官方资料

资料核对日期：2026年11月11日。

• xAI：Context Compaction