跳转至

别再把上下文当聊天记录

📊 Level ⭐⭐⭐ | 13.6KB

-> 原文存档 从微信文章 别再把上下文当聊天记录 提取。

主要章节

  • 赌注：相信模型能管理自己的上下文

  • 真正的工程难点：会话剪枝

  • 子智能体上下文管理

  • 设计在哪里收敛

  • 参考阅读：

深度分析

「上下文不是聊天记录」这个论点的核心洞见在于：LLM 的上下文窗口并不是一个「记忆空间」，而是一个「工作空间」。聊天记录的形式（role / content 交替、时序排列）只是一个历史实现细节，并不对应 LLM 处理信息的最佳方式。会话剪枝（Session Pruning）的真正难点不是「保留哪些消息」，而是「保留哪些信息对当前子任务最有效」。 「赌注：相信模型能管理自己的上下文」这个表述背后有一个深刻的设计哲学转变：传统软件开发中，开发者控制所有状态；在 Agent 系统中，开发者需要把状态管理权委托给模型，但同时提供足够的结构化约束。这个平衡点极其难找——给模型太多自由会导致不可预测行为，给太少又会让模型失去真正的推理能力。 子智能体上下文管理是一个尚未被很好解决的工程问题。当一个复杂任务被分解为多个子 Agent 并行执行时，每个子 Agent 都需要自己的上下文切片，而这些切片之间如何保持信息一致性、如何处理交叉依赖（一个子 Agent 的输出是另一个子 Agent 的输入），目前的解决方案都还相当粗糙。

四个 harness 之间的趋同模式值得单独提炼。Pi、OpenClaw、Claude Code、Letta 在四个关键维度上各自独立收敛到了相似的解法：文件读取硬上限与 offset/limit 分页、工具结果大小限制、子智能体会话隔离、token 阈值触发的 LLM 驱动 compaction。这种跨框架的收敛并非偶然——它反映了 agent 上下文管理正在从「隐式约定」走向「显式工程问题」。更值得关注的是，这种模式甚至跨越了 coding agent 的边界：Arize 的 Alyx（数据探索 agent，非代码编辑场景）独立采用了几乎完全一致的上下文管理策略，包括工具结果预算、幂等调用去重和 checkpoint 机制。正如 Agent Harness Context Management Working Set 和 Context Window Management Comparison 等 wiki 中归纳的：上下文管理的核心约束（固定大小窗口 vs 近乎无限的信息需求）是跨领域的，因此其工程解法也必然趋同。

Harness 控制 vs 模型自主控制是上下文管理中最核心的设计权衡。Pi 选择 harness 优先：由 harness 层施加硬上限、token 阈值和截断策略，模型在约束内行动。OpenClaw 在此基础上叠加了纵深防御（bootstrap 上限 + 工具结果预算 + 多轮总结），依然以 harness 为主导。Claude Code 走得最远：feature flag 远程调参 + 查询前 pipeline + 去重 stub + 九段结构化总结 prompt，把 harness 的控制力推到了极致。而 Letta 采取了 memory 优先的路径，把文件解析、分块、嵌入到向量库，让模型通过工具自主检索，上下文窗口只呈现一个受管理的视图。四种策略代表了从完全 harness 控制到完全模型自主的连续谱。文中那个类比点睛：最好的内存管理是程序根本不用思考的那种——寄存器、缓存行、页表、交换空间各司其职。agent harness 正在走同一条路：把上下文管理从模型的显式认知负担，变成系统层面的透明基础设施。

会话压缩策略的差异揭示了各自的工程哲学。Pi 的 compaction 是最经典的：token 阈值触发 → 从尾部保留约 20K tokens → 早期内容 LLM 总结 → 合成 user message 前置，简洁而有效。OpenClaw 在此基础上引入了 history-share 机制（历史超过 50% 时触发），按 token 质量等分切块丢弃最老块，并在压缩前插入一个静默 agentic turn 让模型先把状态 flush 到记忆文件——这个设计解决了「压缩前模型来不及保存工作状态」的痛点。Claude Code 的 compaction 最具结构性：九段 prompt（primary request、key technical concepts、errors and fixes、pending tasks 等）确保压缩后的 summary 覆盖所有关键维度，压缩后还会重附加最近 5 个读取过的文件作为恢复上下文，且 summary 器使用分离的 analysis scratchpad + final summary 来提升质量。Letta 则采用了滑动窗口驱逐策略：从 30% 消息开始驱逐，每轮增加 10%，并有两阶段 summarizer 先钳制工具结果再中间截断作为兜底。每种策略都在压缩质量、计算开销和工具调用安全性之间做出了不同的工程取舍。 Context Window Management Cpu Cache Analogy Agent Context Management Liwen

实践启示

Agent 系统设计者：不要把上下文当黑箱，不要假设「给模型越多的上下文越好」。正确的做法是：明确任务的上下文需求窗口（需要在多少 token 内完成），设计上下文注入策略（在何时注入何种信息），并在 Harness 层实现上下文预算控制。 会话管理实现者：在实现会话剪枝时，应该基于信息贡献度而非时间顺序来决定保留/丢弃哪些消息。可以利用嵌入相似度、注意力权重分析或小模型代理等方法来评估每条消息的信息价值，而非简单粗暴地保留最近 N 条消息。 多 Agent 系统架构师：子 Agent 之间的上下文共享应该通过结构化的「上下文边界」（Context Boundary）来实现，而不是通过把所有子 Agent 的上下文简单拼接在一起。每个子 Agent 应该只看到它完成任务所必须的最少上下文。

工具结果预算策略：工具返回是上下文膨胀的最大单一来源。四个 harness 都对工具结果设置了独立预算：Pi 的 2K 行/50KB 截断、OpenClaw 的 16K 字符/30% 窗口上限、Claude Code 的 50K 字符单工具 + 200K 字符聚合上限、Letta 的文件字符上限（按窗口大小五档分级）。实践中，设计者应为每个工具类型设定独立的字符/token 预算，并在工具结果超过阈值时自动触发磁盘 offloading，返回 2KB 摘要或 preview。关键是：预算必须在 harness 层强制执行，不能依赖模型自觉——模型会为了「完成任务」而无限制地消耗上下文空间。 Agent Context Compression Yexiaochai 11

Compaction 中的 tool-call/result 边界安全：Compaction 过程中最隐蔽的风险是将一个 tool-call 和它的 tool-result 拆散。一旦孤立的 tool-result 出现在上下文中，模型会因缺乏对应的 tool-call 而产生幻觉或逻辑断裂。Pi 的 compaction 会沿边界移动以保持 tool-call/result 成对完整；OpenClaw 有专门的 repairToolUseResultPairing 修复块丢弃后产生的孤立 tool-result；Letta 在 summarizer 溢出时会钳制工具结果而非丢弃。建议在 compaction 实现中加入两层安全检查：(1) 块合并时验证 tool-call/result 对的完整性，(2) summary 生成后扫描是否有孤立的 tool_result 标记。这是一个容易被忽视但对 agent 连贯性至关重要的细节。 Claude Code Openclaw Memory Comparison

磁盘化工具结果卸载：Claude Code 和 OpenClaw 都已实现将超大工具结果持久化到磁盘、在上下文中只保留 preview 的机制。这本质上是操作系统的 page-out 类比：当上下文窗口「内存」紧张时，将不活跃的工具结果「换出」到磁盘，需要时再按需「换入」。Alyx 也采用了类似模式——把大型 JSON payload 拆成 LLM 可见的压缩 preview 和服务端完整副本。这种 pattern 值得所有 agent harness 采纳：工具结果写入临时文件 → 返回路径引用 + 精华摘要 → 模型通过 read_file/grep 按需回读。它让上下文窗口可以专注于「决策上下文」而非「数据缓冲区」，显著提升长会话的连贯性和有效性。

ai agent platforms topic map（已删除）

相关实体