12｜突破内存：基于阶梯降级的 Context Compaction 策略
Tony Bai
你好，我是 Tony Bai。欢迎来到《从 0 开始构建 Agent Harness》专栏的第十二讲。
在上一讲中，我们为 go-tiny-claw 引入了 Session（会话）机制和 Working Memory（短期工作记忆）。Agent 终于摆脱了“单次运行就失忆”的尴尬，能够像人类一样，在长程对话中保持上下文的连贯性，并且通过只截取最近的 N 条消息，有效地控制了日常闲聊的 Token 消耗，并保证了短期工作记忆的聚焦。
但是，作为一个以代码重构和系统运维为己任的通用型工业级 Coding Agent，它的核心动作不仅仅是聊天，而是执行工具（Tools）。
设想这样一个场景：你让 Agent 去排查一个线上故障。它在第 2 个回合（Turn 2）调用了 read_file 工具，读取了一个长达两万行的 Nginx 报错日志（约 1MB）。
即使你的 Working Memory 保护区设置得再小（比如只保留最近的 3 条消息），只要这其中一条消息（即 read_file 的执行结果 ToolResult）包含了这 1MB 的超长文本，大模型 API 依然会瞬间抛出一个冰冷的错误：400 Bad Request: context length exceeded。
在驾驭工程中，有一条不可动摇的铁律：如果大模型是 CPU，那么 Context Window（上下文窗口）就是极其昂贵且容量受限的 RAM（内存）。物理防御（防止内存溢出 OOM）的优先级，永远高于业务逻辑（短期记忆的完整性）。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《从 0 开始构建 Agent Harness》，新⼈⾸单¥59
《从 0 开始构建 Agent Harness》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论