Wiki Notes

Appearance

推理轨迹压缩专题 ​

版本：v1.1

最后更新：2026-07-07

适用对象：需要为 Agent、长任务工作流、多工具链、RAG 链路和多轮推理系统设计阶段摘要、状态快照、轨迹治理和成本控制策略的产品、平台、算法与工程同学

很多复杂 Agent 任务都会产生很长的过程信息：

  • 思考步骤
  • 工具调用记录
  • 检索证据
  • 中间判断
  • 失败重试轨迹
  • 审批与人工接管事件

如果这些轨迹全部原样保留并继续送回模型，常见后果会非常直接：

  • token 成本快速上升
  • 延迟明显变差
  • 重复噪声越来越多
  • 关键约束和关键信号反而被淹没
  • 后续回合开始“为历史轨迹服务”，而不是为当前任务服务

这也是为什么一旦系统进入长链路、长会话、多工具状态，推理轨迹压缩几乎会变成必做项。

OpenAI 的 reasoning、conversation state、background mode、evaluate agent workflows 文档，以及 LangGraph 的 memory / add-memory / persistence 文档，都指向同一个工程原则：

  • 原始轨迹对排障和审计很重要
  • 但在线执行时，只应该把后续决策真正需要的那部分轨迹带回模型

一句话理解：

  • 推理轨迹压缩不是删历史，而是把“原始过程”压成“后续执行仍然可用的状态、证据和决策摘要”

1. 什么是推理轨迹压缩 ​

更实用的理解通常是：

  • 把长链路中的过程信息压缩成后续决策真正需要的摘要、状态或结构化片段

重点不是：

  • 把所有东西浓缩成一句话

而是：

  • 保留关键决策信号
  • 去掉重复和低价值细节
  • 让后续回合继续可执行

所以它是一种面向执行的压缩，而不是面向阅读的压缩。

2. 为什么轨迹压缩和普通摘要不一样 ​

普通摘要更偏向：

  • 讲个大概
  • 帮人快速理解发生了什么

而轨迹压缩更关注：

  • 哪些步骤已经完成
  • 哪些失败过
  • 哪些结论仍然有效
  • 哪些约束必须继续保留
  • 当前任务状态是什么
  • 下一步还能做什么

它服务的对象主要不是人，而是：

  • 下一个模型回合
  • 下一个执行节点
  • 下一次任务恢复

如果压缩结果只是“看起来通顺”，却不能支持下一步执行，那就不是好的轨迹压缩。

3. 为什么长轨迹会越来越伤系统 ​

轨迹原样保留的代价，不只是 token 增加。

3.1 成本问题 ​

  • 输入 token 持续累积
  • 工具 schema、系统提示和历史轨迹一起争预算

3.2 延迟问题 ​

  • prefill 变长
  • token counting、context assembly 变慢
  • 长链路更容易触发超时

3.3 注意力问题 ​

  • 关键约束被历史噪声淹没
  • 失败过的旧尝试反而干扰当前判断

3.4 可维护性问题 ​

  • 团队越来越难解释“为什么现在 prompt 会长成这样”

所以推理轨迹压缩真正要解决的是：

  • 不让系统被自己的历史拖住

4. 哪些内容最适合优先压缩 ​

更适合优先压缩的通常包括：

  • 重复思考片段
  • 多轮检索和工具返回
  • 中间试错过程
  • 阶段性长会话历史
  • 重复出现的限制条件
  • 已经验证过但后续不必全文保留的证据
  • 同类失败的重复重试轨迹

这些内容如果原样保留，最常见的问题不是“完全没用”，而是：

  • 它们的全文价值已经低于它们占据的注意力成本

5. 哪些内容不能随便压 ​

推理轨迹压缩做得过头，很容易把真正关键的东西一起删掉。

尤其这些信息通常应被保留或单独结构化保留：

  • 当前任务状态
  • 关键失败原因
  • 当前分支为何被放弃
  • 高风险约束
  • 审批边界
  • 用户明确要求
  • 仍然有效的高价值证据

更稳妥的做法通常是：

  • 先定义哪些信息属于 must_keep_signals

否则压缩就会从“降噪”变成“删掉关键事实”。

6. 一个更实用的轨迹对象模型 ​

很多系统把轨迹理解成一串消息。

更成熟的做法通常是把轨迹分成几类对象：

json
{
  "task_id": "task_001",
  "phase": "policy_check",
  "steps": [
    {
      "step_id": "s1",
      "type": "tool_call",
      "tool": "query_order",
      "status": "success"
    },
    {
      "step_id": "s2",
      "type": "reasoning",
      "status": "success"
    },
    {
      "step_id": "s3",
      "type": "tool_call",
      "tool": "search_policy",
      "status": "success"
    }
  ],
  "failures": [],
  "constraints": [
    "amount_gt_5000_requires_approval"
  ]
}

这种结构的价值是：

  • 压缩时可以按对象类型处理
  • 而不是把所有历史都当成一段长文本处理

轨迹越结构化，压缩越稳定。

7. 一个更实用的轨迹压缩分层 ​

最实用的轨迹压缩，通常不是只保留一段摘要，而是至少保留四层。

7.1 状态压缩 ​

回答：

  • 当前任务到了哪一步
  • 已完成什么
  • 待完成什么

7.2 证据压缩 ​

回答：

  • 哪些证据仍然有效
  • 哪些来源是当前决策所依赖的

7.3 决策压缩 ​

回答：

  • 已做出的关键判断是什么
  • 为什么进入当前分支

7.4 风险压缩 ​

回答：

  • 哪些约束、审批边界、失败原因绝不能丢

这四层合在一起，压缩结果才更可能继续服务后续执行。

8. 一个最小可行的轨迹摘要对象 ​

json
{
  "phase_summary": {
    "phase": "policy_check",
    "completed": [
      "已确认订单属于企业版",
      "已检索退款政策"
    ],
    "open_items": [
      "等待审批判断"
    ],
    "valid_evidence": [
      "policy_2026_07: 金额超过5000需要审批"
    ],
    "must_keep_constraints": [
      "不得跳过审批直接更新状态"
    ],
    "latest_failure": null,
    "next_recommended_action": "request_approval"
  }
}

这类摘要对象比一段自然语言更有价值，因为：

  • 后续节点能稳定读取
  • 评测和回放也更容易对比

9. 为什么在线压缩和离线保真要分开 ​

一个常见误区是：

  • 压缩后就把原始轨迹扔掉

这会直接削弱：

  • 排障
  • 审计
  • 质量复盘
  • 压缩策略调优

更稳妥的做法通常是双轨保留：

9.1 在线轨 ​

  • 后续执行使用压缩轨迹

9.2 离线轨 ​

  • 原始轨迹保留在 trace、事件流、状态快照或日志系统中

这样既能降低上下文负担，又不至于彻底失去复盘能力。

10. 什么时候触发轨迹压缩 ​

不要随意压缩。

更实用的触发方式通常包括：

10.1 token 阈值触发 ​

  • prompt tokens 超过预算上限

10.2 阶段边界触发 ​

  • 一个工作流阶段结束
  • 一个子任务完成
  • 一次人工审批结束

10.3 轮次阈值触发 ​

  • 会话连续达到 N 轮

10.4 工具批次触发 ​

  • 一轮中累积了大量工具结果

10.5 中断恢复触发 ​

  • 长任务恢复前，生成可恢复的阶段摘要

压缩时机本身就是系统设计项，不该临场决定。

11. 一个更实用的压缩时机选择 ​

最稳妥的做法通常不是“每轮都压”，而是：

  • 在语义边界清楚时压

例如：

  • 检索结束后
  • planner 完成一轮计划后
  • 审批节点前后
  • 一个批量工具阶段结束后
  • 一次恢复点写盘前

原因很简单：

  • 边界越清晰，压缩越不容易把跨阶段的关键因果关系压坏

如果压缩时机太随意，压缩结果经常会出现：

  • 当前状态模糊
  • 失败原因被截断
  • 决策链断裂

12. 为什么 reasoning summary 是很重要的模式 ​

OpenAI 在 reasoning 相关能力和 agent workflow 文档里，都体现出一个很重要的工程思路：

  • 不需要把所有中间推理全文持久带回后续链路
  • 但可以保留结构化或简洁的 reasoning summary

更实用的理解是：

  • 不是保存“所有想法”
  • 而是保存“后续仍然必须知道的判断结果和依据”

这类 summary 特别适合承载：

  • 当前分支为何成立
  • 哪个备选分支已被否决
  • 还有哪些未确认风险

reasoning summary 越接近状态对象和决策对象，而不是散文段落，后续可用性越高。

13. 为什么轨迹压缩和上下文分层必须一起设计 ​

上下文压缩与记忆分层专题 关注的是：

  • 不同信息应该进入哪一层

轨迹压缩关注的是：

  • 长轨迹怎么被压成合适的表示

二者关系非常直接：

  • 压缩后的阶段摘要，往往应该进入任务记忆
  • 高频试错细节，不应该进入长期记忆
  • 用户偏好不应从推理轨迹里自动抽成长期用户记忆

所以更成熟的做法不是：

  • 先压完，再把压缩结果随便塞进某个持久层

而是：

  • 先压
  • 再按层路由

14. 为什么轨迹压缩和回合控制是联动关系 ​

Agent回合控制专题 的一个关键目标是：

  • 减少无进展循环和无意义重试

而轨迹压缩能直接帮助做到这点，因为它能把长历史归纳成：

  • 已经试过什么
  • 为什么失败
  • 当前还剩什么可尝试

这会显著减少：

  • 同样的检索被重复做
  • 同样的计划被重复写
  • 同样的失败原因被忘掉

如果没有轨迹压缩，长任务很容易进入“历史太多但状态不清”的糟糕局面。

15. 为什么轨迹压缩和长任务恢复强绑定 ​

长任务恢复策略专题 里最核心的一个问题是：

  • 任务中断后，系统如何恢复

如果恢复只能依赖：

  • 全量原始轨迹

那恢复成本和不稳定性都会很高。

更稳妥的做法通常是保留：

  • 最近阶段摘要
  • 当前任务状态
  • 最新有效证据
  • 当前必须继续遵守的约束
  • 未完成步骤

这本质上就是：

  • 轨迹压缩为恢复服务

16. 为什么轨迹压缩不能只压文本，也要压工具和证据 ​

很多系统的“轨迹压缩”只作用在模型消息上。

这通常还不够。

因为真实上下文膨胀的大头常常来自：

  • 工具返回
  • 检索片段
  • 事件流
  • 审批记录

更实用的压缩对象通常包括：

16.1 工具结果压缩 ​

  • 只保留关键字段
  • 去掉冗余原文

16.2 检索证据压缩 ​

  • 只保留高分、最新、当前仍有效的引用

16.3 失败事件压缩 ​

  • 保留失败类别和当前影响，而不是保留整段堆栈文本

16.4 审批与策略压缩 ​

  • 保留当前生效的审批结果和策略决定

否则模型消息压短了，但整体上下文仍然很重。

17. 一个更实用的压缩策略组合 ​

一套成熟的轨迹压缩，往往不是单一策略，而是多策略组合。

17.1 去重 ​

  • 删除重复结论
  • 删除重复工具返回

17.2 截断 ​

  • 对低价值长日志做受控截断

17.3 结构化提取 ​

  • 从长过程里抽出关键状态、证据、失败原因

17.4 阶段摘要 ​

  • 在 phase 边界生成可恢复摘要

17.5 风险约束保留 ​

  • 单独保留绝不能丢的规则

这比“统一让模型总结一下”稳得多。

18. 一个更实用的压缩策略示例 ​

json
{
  "compression_policy": {
    "trigger_if_prompt_tokens_gt": 12000,
    "compress_layers": [
      "tool_results",
      "failed_attempts",
      "phase_chat_history"
    ],
    "must_keep": [
      "active_constraints",
      "latest_valid_evidence",
      "current_task_state",
      "latest_failure_reason"
    ],
    "output_format": "structured_phase_summary"
  }
}

有了这种显式策略，轨迹压缩才不会变成“某段 prompt 里顺手写的一句要求”。

19. 压缩质量应该如何评估 ​

压缩做得好不好，不能只看少了多少 token。

至少应同时看四类指标。

19.1 成本指标 ​

  • prompt tokens 降低多少
  • 缓存命中率是否更好

19.2 延迟指标 ​

  • prefill 是否更短
  • P95 是否改善

19.3 质量指标 ​

  • 成功率是否下降
  • 关键约束是否保留
  • 关键证据是否保留
  • 重复错误是否减少

19.4 恢复指标 ​

  • 中断后是否更容易恢复
  • 恢复后是否更少 replan

如果只盯 token，很容易做出“省钱但质量崩掉”的假优化。

20. 轨迹压缩应该进入评测体系 ​

建议至少构建三类评测。

20.1 压缩前后对比评测 ​

看：

  • 成功率
  • token 成本
  • 延迟
  • 关键约束保留情况

20.2 长任务恢复评测 ​

看：

  • 用压缩摘要能否正确恢复
  • 恢复后是否走对分支

20.3 坏压缩样例评测 ​

例如：

  • 丢了审批约束
  • 丢了失败原因
  • 把旧证据当最新证据保留

这些才是最能暴露压缩策略缺陷的样例。

OpenAI Evaluate agent workflows 和 Trace grading 的启发都很明确：

  • 中间步骤治理必须能被评测，而不只是靠人工体感

21. 线上应该监控哪些轨迹压缩指标 ​

21.1 体积指标 ​

指标用途
avg_trace_tokens_before_compress原始轨迹体积
avg_trace_tokens_after_compress压缩后体积
compression_ratio压缩比

21.2 质量指标 ​

指标用途
constraint_drop_rate关键约束丢失率
evidence_drop_rate关键证据丢失率
repeated_failed_action_rate是否因压缩不足重复踩坑
resume_failure_after_compression恢复失败率

21.3 系统指标 ​

指标用途
compression_trigger_rate触发压缩的频率
compression_latency压缩本身的耗时
p95_prompt_tokens长尾上下文体积
human_handoff_due_to_context_loss因轨迹信息不足转人工的比例

这些指标能帮助团队分辨：

  • 是压缩不够
  • 还是压缩过头

22. 常见失败模式 ​

22.1 所有轨迹都原样塞回模型 ​

后果：

  • 成本和噪声一起失控

22.2 压缩只保留一句泛化总结 ​

后果：

  • 后续执行缺乏可操作状态

22.3 压缩后丢失失败原因和风险约束 ​

后果：

  • 系统反复重犯同类错误

22.4 压缩时机随意 ​

后果：

  • 阶段边界混乱
  • 摘要质量不稳定

22.5 压缩结果不结构化 ​

后果：

  • 下游节点难以稳定使用

22.6 压缩策略变更不做回放验证 ​

后果：

  • 线上看起来省 token，实际成功率掉了

23. 优化推理轨迹压缩的常见手段 ​

23.1 先把轨迹对象结构化 ​

  • 不要把一切都当长文本处理

23.2 在阶段边界压缩 ​

  • 让摘要有清晰语义边界

23.3 把 must-keep 信号单列 ​

  • 避免被摘要过程一起吞掉

23.4 让压缩结果服务恢复与下一步执行 ​

  • 不只服务“看起来短”

23.5 在线压缩、离线保真双轨分离 ​

  • 兼顾性能和复盘

23.6 用评测和监控调压缩策略 ​

  • 不凭感觉调摘要 prompt

24. 一个可执行的落地流程 ​

24.1 盘点轨迹来源 ​

列出：

  • 模型消息
  • 工具返回
  • 检索证据
  • 失败与重试事件
  • 审批记录

24.2 给轨迹对象分类 ​

至少区分：

  • 状态
  • 证据
  • 决策
  • 风险约束
  • 低价值历史

24.3 设计压缩策略 ​

明确：

  • 何时触发
  • 压哪些对象
  • 哪些不能丢
  • 输出什么结构

24.4 接入任务状态和恢复链路 ​

让压缩摘要真正进入执行系统，而不是只停在日志里。

24.5 做压缩前后评测 ​

重点看：

  • 成功率
  • 成本
  • 延迟
  • 恢复质量

24.6 监控和回放 ​

让团队能持续看到：

  • 压缩是否在帮忙
  • 还是在悄悄伤害链路质量

25. 推荐搭配阅读 ​

26. 落地检查清单 ​

  • 是否定义了状态、证据、决策和风险约束四类压缩目标？
  • 是否明确了哪些信息在压缩中绝不能丢？
  • 是否按 token 阈值、阶段边界或恢复节点触发压缩？
  • 是否把压缩结果做成结构化 phase summary，而不是只留一段散文摘要？
  • 是否区分在线执行使用的压缩轨迹和离线复盘保留的原始轨迹？
  • 是否让压缩结果真正进入任务状态、恢复流程和下一步上下文装配？
  • 是否评估过压缩前后对成功率、成本、延迟和恢复能力的影响？
  • 是否监控 compression_ratio、constraint_drop_rate、resume_failure_after_compression 等指标？
  • 是否把坏压缩样例纳入回归评测？
  • 是否在策略变更后做回放验证，而不是直接上线？

27. 推荐资源 ​

以下资源在 2026-07-07 检查时可访问，适合作为推理轨迹压缩、状态摘要、背景执行和记忆治理的官方参考。

OpenAI ​

LangGraph / LangChain ​

28. 最后总结 ​

推理轨迹压缩不是“让历史更短一点”，而是让系统在长链路里持续知道：

  • 现在处于什么状态
  • 哪些证据仍然有效
  • 哪些失败原因必须记住
  • 下一步还能怎么走

如果这些信息没有被压成可执行的结构，系统就会很快落入两个坏结果之一：

  • 要么原样带着整条历史跑，越来越重
  • 要么压缩得只剩一句空话，后续根本用不上

更成熟的做法，是把轨迹对象结构化，在清晰边界上压缩，明确 must-keep 信号，并把压缩结果真正接回任务状态、恢复链路和评测体系。

这样轨迹压缩才不是一次性总结，而会成为 Agent 在长任务里保持清晰、可恢复、可持续迭代的重要能力。