Reasoning Summaries 的实现原理：它在 Agent 工作流里到底怎么运作

从一次真实调试说起

上周调试一个多步 Agent 时，发现它在第三步突然回答“我不记得前面说过什么了”。检查日志，每次调用 LLM 都传入了完整的对话历史——但 token 限制导致模型只读最后几轮。更糟的是，中间的关键推理步骤被截断，Agent 只能随机猜测。

这个场景就是 Reasoning Summaries 要解决的核心问题：当完整历史无法全部塞进上下文窗口时，如何保留最具价值的推理信息。

Reasoning Summaries 到底是什么

Reasoning Summaries 不是简单的对话摘要。它是一组对 Agent 内部推理过程的结构化压缩结果，通常包含：

• 推理链关键节点（例如：中间假设、验证结果、分支决策）
• 每个节点的置信度或优先级标记
• 已消耗的外部工具调用结果（如搜索返回、代码执行输出）

与普通摘要不同，它注重保留“logical progression”（逻辑推进），而不是信息完整性。例如，一个金融 Agent 在分析财报时，需要记住“在第一步发现现金流为负，因此后续估值模型需要调整折现率”，而不是“财报里提到现金流为负”。前者是推理，后者是事实。

它在 Agent 工作流里到底解决什么问题

Agent 工作流往往是循环结构：观察状态 -> 规划动作 -> 执行动作 -> 更新状态。在这四个阶段中，Reasoning Summaries 主要作用于“更新状态”环节——将当前推理结果压缩后并入内存，供下一轮使用。

具体而言，它解决了三个实际工程问题：

1. 上下文窗口溢出：多轮交互后，历史很容易超过模型的最大 token 限制。Summaries 将几轮对话压缩成一段精炼的推理摘要，保留最关键的决策依据。
2. 推理断裂：模型在长对话中容易丢失早期结论。通过显式维护推理链摘要，即使上下文窗口被刷新，Agent 也能基于摘要继续推理。
3. 调试困难：当 Agent 行为异常时，查看完整日志很痛苦。Summaries 提供一条清晰的主推理路径，快速定位错误分支。

最容易失败的地方

在我参与的项目中，最常见的失败案例是过度压缩。

团队用“最大压缩比”策略，把每一轮输出都压缩成一句话。结果 Agent 很快就丢失了任务的原始目标——它在第一轮决定要查数据库 A，第二轮发现数据不足转向数据库 B，第三轮却忘记了自己为什么放弃 A，又回去查了一遍。

另一个高频错误是压缩时机错误。有些人选择在每次 LLM 调用后立即压缩，结果压缩本身消耗了大量推理预算，而且频繁的压缩操作打断了主逻辑。更合理的做法是：只在上下文即将达到 70% 容量时才触发压缩，或者每次关键转折点（比如工具调用后）压缩一次。

还有一个容易忽略的点：压缩后的摘要可能丢失否定信息或条件约束。例如，原推理是“如果销量增加则增产，否则维持库存”，摘要可能只留下“增产”，导致 Agent 在不满足条件时也执行了错误动作。必须确保压缩过程保留条件结构。

现在就要落地，第一步怎么做

第一步不是写代码，而是定义你的 Agent 需要记住什么。

给当前负责的 Agent 构建一个推理记忆模板。例如，一个代码审查 Agent 可能需要：

1. 当前审查的代码文件与行号范围
2. 已发现的 Bug 及其严重性
3. 尚未检查的模块列表
4. 已有结论（例如：发现内存泄漏，需要调整缓存策略）

第二步，选择合适的实现方式。目前主流方案包括：

• 使用 LLM 生成自然语言摘要：简单，但摘要质量依赖 prompt 设计，且可能丢失细节。适合任务较简单的 Agent。
• 结构化记录：用字典或数据类存储决策树，每次更新节点值。可精确压缩，但需要预定义 schema。适合逻辑固定的任务。
• 混合方案：同时维护一个结构化关键字段和一个自然语言摘要，后者用于 LLM 理解上下文，前者用于精确查找。

第三步，集成到 Agent 循环中。在每一步更新状态后，检查是否达到压缩阈值，若是则调用摘要函数，用摘要替换部分历史，并将摘要标记为“压缩内容”以备调试。

失败时的备用方案

如果 Reasoning Summaries 效果不佳（比如摘要后 Agent 推理质量明显下降），可以回退到两种方案：

1. 滑动窗口策略：不和上下文搏斗，使用固定大小的窗口最近 N 轮完整记录，放弃早期历史。适合历史关联性不强的任务，比如单次问答。
2. 检索增强记忆：将每一轮推理编码为向量存入向量数据库，Agent 每次推理前检索 Top-K 相关历史。适合长周期任务，比如持续多天的项目评审。

当然，这两个方案只是保底。如果团队资源允许，可以尝试微调一个专门的摘要模型，但那是另一条长线了。

总结

Reasoning Summaries 是 Agent 工程里不可回避的组件。做得对，可以大幅提升长链推理的稳定性；做得不对，反而引入更隐蔽的 bug。关键不在于追求“全而美”的摘要，而在于策略性地保留推理线索。