为什么压缩是 Agent 系统的元机制而工具只是确定性的基础设施一、一个被误导的行业焦点过去两年Agent 框架的竞赛似乎围绕着一个指标展开谁集成了更多工具。从代码解释器到浏览器控制从数据库查询到图像生成工具数量成了衡量 Agent 能力的显性标准。但这种视角忽略了一个根本事实工具调用本身是确定性的。read_file读第 35 行就是第 35 行grep匹配到的结果就是那些结果执行bash命令的返回码不会撒谎。工具是基础设施是手脚是感官——它们本身不产生智能。真正让 Agent 从单次问答进化为长期工作的是上下文管理。而在上下文管理的所有技术中压缩Compaction是唯一的元机制——它决定 Agent 记得什么、忘记什么从而决定 Agent 能工作多久、工作质量如何。二、上下文管理Agent 的操作系统如果把 Agent 比作计算机上下文窗口就是 RAM——有限、昂贵、高速。文件系统和向量数据库是磁盘——无限、廉价、慢速。Agent 的长期工作能力不取决于它有多少工具而取决于它的操作系统如何管理这块 RAM。2.1 没有上下文管理Agent 是金鱼一个 128K 上下文的 Agent面对一个 10MB 的代码仓库如果不做上下文管理它只能读几个文件就触顶忘记用户最初的约束重复读取同一个函数在循环中耗尽 token 预算工具再多也没用——它根本记不住自己用过什么工具。2.2 上下文管理的七层技术栈业界处理上下文超限的方法可以归纳为七层层级技术作用域确定性L1硬截断Truncate工具返回时100% 确定L2分页读取Pagination工具设计时100% 确定L3去重Deduplication工具返回时100% 确定L4引用替换Reference轮次内100% 确定L5外化记忆Offload跨轮次100% 确定L6结构化压缩Compaction跨轮次/轮次内概率性L7上下文重置Reset跨轮次100% 确定L1-L5 和 L7 都是工程手段是确定性的基础设施。只有 L6——结构化压缩——是智能行为因为它需要判断什么重要、什么可以丢。三、压缩唯一的元机制3.1 为什么压缩是元的工具调用修改的是外部世界文件系统、数据库、API压缩修改的是 LLM 自己的大脑状态。工具调用错了→ 系统返回错误LLM 收到反馈下一轮回正。这是可逆的。压缩错了→ 关键信息被静默丢弃LLM 真诚地相信自己记得的是对的然后基于错误的记忆继续走向深渊。这是不可逆的。压缩是 Agent 系统中唯一一个 LLM 修改自己未来输入上下文的环节。它像人脑的海马体——在睡眠时决定什么进入长期记忆什么被遗忘。海马体坏了再聪明的大脑也会变成痴呆。3.2 压缩失败的复利效应工具调用的错误是单点失败read_file 报错 → 重试 → 成功 → 继续压缩错误是复利失败Round 1: 压缩时丢了用户说不要用全局变量 Round 2: Agent 用了全局变量约束已丢 Round 3: 压缩时丢了全局变量已被使用 Round 4: Agent 在全局变量上继续堆代码 ... Round N: 代码变成 spaghettiAgent 不知道为什么会这样每一轮压缩都在前一轮的失真记忆上继续失真。最终上下文与真实世界严重脱节而 LLM 对此毫无察觉。四、架构分界自主域 vs 控制域理解 Agent 系统必须划清一条界线LLM 自主域工具选什么、参数怎么填、先读后改还是先 grep——这是 LLM 的思维自由系统只提示不控制。算法控制域压缩怎么做、什么能丢什么不能丢、丢完后对不对——这是系统的工程责任必须算法级保障。4.1 工具调用属于自主域LLM 决定调用read_file还是grep决定offset35还是offset230这是它的 reasoning 能力。系统不应该干预——即使它选错了错误也是显式的LLM: read_file(auth.ts, offset99999) → 越界 系统: 返回错误 offset out of range LLM: 重新计算read_file(auth.ts, offset1)自主域允许试错因为错误可被感知、被反馈、被修正。4.2 压缩必须属于控制域压缩不能交给 LLM 自由发挥因为它的失败是静默的、不可逆的。一个正确的压缩系统应该这样工作算法决定丢什么系统按硬规则分类消息不可丢 / 可摘要 / 可丢弃LLM 只负责填充按给定的 Schema把可摘要的消息提炼成结构化摘要算法校验结果检查不可丢项是否还在、修改过的文件是否保留、未解决的错误是否丢失校验失败则阻断不是让 LLM “重新试试”而是回退到 checkpoint 或拒绝压缩五、压缩的工程实现三层防线5.1 第一层硬规则系统决定LLM 不可违背COMPACTION_RULES{immutable:[# 绝对不可丢弃user_constraints_last_5_turns,files_modified_in_this_session,unresolved_errors,unresolved_contradictions],summarizable:[# 可摘要但路径/行号必须保留files_read_but_not_modified,tool_outputs_already_consumed],droppable:[# 可直接丢弃file_unchanged_records,superseded_code_versions]}这些规则不是 prompt 里的建议而是系统对消息数组的直接操作。LLM 的权限边界非常清晰它可以决定key_findings怎么写但不能决定files_modified是否保留。5.2 第二层Schema 填充LLM 执行结构约束LLM 的任务不是自由写摘要而是按算法给定的输入生成结构化输出{preserved:[{type:file_modified,path:src/auth.ts,lines:[35,50]},{type:user_constraint,text:不要用全局变量}],summarized:{files_read:[{path:src/auth.ts,key_findings:实现了登录逻辑,lines:[35,230]}]}}Schema 强制保留定位信息路径、行号只压缩语义内容代码细节。这避免了摘要写得很通顺但丢了关键行号的问题。5.3 第三层一致性校验算法验证不经过 LLMdefverify_compaction(original,compressed):# 修改过的文件不能丢modifiedget_modified_files(original)assertall(fincompressed.files_writtenforfinmodified)# 未解决的错误不能丢unresolvedget_unresolved_errors(original)assertall(eincompressed.issues.errorsforeinunresolved)# 不能产生幻觉新信息必须能在原文中找到forfindingincompressed.summarized.files_read:assertfinding.pathinoriginal_file_paths校验失败的处理不是让 LLM 重新压缩而是回退到更保守的策略或拒绝压缩直接报错。因为压缩是单向门一旦错了就没有挽回余地。六、主流项目的佐证这个论点不是理论推演各主流项目的架构选择都在印证它Claude Code压缩是黑盒但行为暴露硬规则Claude Code 的自动 compaction 不可定制但从其可观测行为可以反推出明确的优先级P0绝不丢弃CLAUDE.md、最近修改的文件路径、未解决的错误P1尽量保留最近 3-5 轮对话、用户明确约束P2可丢弃已消费的 Read 结果、File unchanged记录P3优先丢弃早期探索路径、已解决的错误、被覆盖的代码版本Anthropic 把压缩策略硬编码说明他们认为这太重要不能交给 LLM 随意决定。CoordClaw绕过压缩用外化替代CoordClaw 的选择更极端——如果压缩太危险那就避免需要压缩。一轮生命周期极短T1-T5 标准动作自然不需要轮次内压缩跨轮次不保留对话历史只保留工作日志工作日志是确定性的结构化输出不是 LLM 生成的摘要这相当于把压缩这个概率性问题转化成了结构化输出这个确定性问题。OpenCode把压缩交给社区探索OpenCode 提供experimental.session.compacting钩子但默认不实现。这暴露了一个事实Even 核心团队也认为最佳压缩策略还没有共识。社区插件DCP、mnemosyne各自探索不同的压缩方案恰恰说明压缩是 Agent 系统中最开放、最关键的问题域。七、给架构师的结论设计 Agent 系统时请遵循这条公理凡是不可逆的操作必须落在算法控制域凡是可逆的操作可以交给 LLM 自主域。操作可逆性所属域工具调用读/写/搜✅ 可逆可重试/可回滚自主域代码编辑✅ 可逆git 可恢复自主域任务拆分✅ 可逆可重新规划自主域上下文压缩❌不可逆原始信息已丢控制域记忆外化❌不可逆写入即事实控制域工具设计是确定性的基础设施——它解决能不能做的问题。工具调用是 LLM 的自主行为——它解决怎么做的问题。但压缩是 Agent 的元认知机制——它解决还记得什么的问题。一个 Agent 可以只有三个工具读、写、搜只要它的压缩策略正确就能维护百万行代码。反之一个 Agent 有三十个工具如果压缩策略错误读五个文件就会忘记用户是谁。Prompt 指导思维算法保障底线。压缩就是底线。