别被“薄封装”骗了，AI智能体的护城河在“脏活累活”里

谁说模型之外，皆为“薄封装”？

一个流传甚广的说法是，AI智能体（Agent）的“秘密武器”都在模型本身。就连Anthropic内部，打造出顶级编程智能体Claude Code的工程师也曾谦虚地称其为“模型之上最薄的一层封装”。

这种说法极具误导性。它让人们把目光全部聚焦在模型参数、性能榜单的喧嚣中，而忽略了真正塑造产品、决定成败的战场——模型之外的系统架构，或者说，“智能体驾驭系统”（Harness）。

如果说大模型是引擎，那这套驾驭系统就是整台车。引擎的马力固然重要，但车辆的传动、悬挂、刹车和控制系统，才决定了它能否在复杂路况下安全、高效地行驶。今天，我们就拆开两台顶级“赛车”——Claude Code和OpenClaw，从一个看似微不足道的细节“上下文压缩”（Compaction）入手，看看这层“薄封装”里到底藏着多深的学问。

看不见的战场：上下文窗口管理

任何一个需要进行多轮对话的AI智能体，都面临一个无法回避的物理限制：上下文窗口。当对话历史、工具调用、代码读取等信息不断累积，很快就会撑爆模型的窗口上限。如何优雅地为上下文“瘦身”，同时不丢失关键信息，这就是“上下文压缩”要解决的问题。

这绝不是简单地丢弃旧信息那么简单。在这个问题上，Claude Code和OpenClaw走了两条截然相反的路。

1. 策略分野：”事后补救“ vs “事前防御”

Claude Code采取的是一种“反应式”（Reactive）策略。它允许对话历史自由增长，像一辆高速行驶的汽车，直到快要撞上“内存墙”时（距离窗口上限约13000个token），才紧急踩下刹车，启动压缩程序，对整个对话历史进行一次大模型调用总结。

这种策略的优点是在“一帆风顺”时速度快、成本低，因为它避免了频繁的检查和计算。但它赌的是，任务通常在触及上限前就能完成。

OpenClaw则完全相反，它是一个“预防式”（Preemptive）的防御大师。在每一次调用大模型之前，它都会精打细算地估算下一次请求的token成本，并乘以一个1.2的“安全系数”。一旦发现潜在风险，它会立即启动压缩，而且是分级处理：先尝试截断超长的工具返回结果，不行再进行摘要总结，层层递进，避免“小题大做”。

这两种策略没有绝对的优劣，却反映了截然不同的产品哲学。Claude Code追求的是“快乐路径”下的极致效率，而OpenClaw追求的是复杂情况下的稳定性和可预测性。

2. 压缩艺术：”叙事总结“ vs ”契约生成“

当不得不启动大模型进行总结时，两者的处理方式再次分化。

Claude Code的Prompt读起来像一位资深工程师在写一份详尽的交接文档。它要求模型生成一个包含9个部分的“叙事体”摘要，涵盖用户意图、技术概念、错误修复、待办任务等。它甚至有一个绝妙的设计：要求模型“逐字引用”最近对话中关于当前任务的描述，以防止在总结过程中出现“任务漂移”——这是模型在长对话中常见的“毛病”。

OpenClaw的Prompt则像一份冰冷的“技术合同”。它要求模型严格按照5个固定标题（决策、待办、约束、用户请求、精确标识符）输出结果。它不仅要求保留所有ID、哈希值、URL等“不透明标识符”，甚至还有一个自动审计步骤，检查生成的摘要是否符合格式、是否遗漏了关键信息。如果不合格，就打回重做。

一个是相信模型的叙事能力，追求生成一份“可读性高”的备忘录；另一个是把模型视为一个需要严格约束的“代码生成器”，追求结果的“可验证性”。

3. 容错哲学：“保住用户” vs “保住数据”

当压缩过程本身出错时，两者的取舍更是天差地别。

Claude Code的目标是“不惜一切代价让用户继续工作”。它设计了复杂的重试和熔断机制。如果总结失败，它会悄悄地、有损地截断一部分最旧的历史记录，然后重试。如果连续失败次数过多，它会直接放弃压缩，以避免在失败的循环中浪费大量的API调用。根据其内部日志，这种机制的引入，是因为曾发现有上千个会话陷入连续50次以上的压缩失败循环，每天浪费掉约250,000次API调用。这是用真金白银换来的教训。

OpenClaw则将“对话历史的完整性”置于更高优先级。在压缩前，它会先创建一个会话快照。如果压缩失败，它会选择“取消操作”，保留原始的、未经修改的对话记录，把控制权交还给用户。它绝不“悄悄”地丢弃任何信息。

这背后是两种产品价值观的碰撞：是优先保证交互的流畅性，还是优先保证历史记录的绝对保真？对于编程助手这类工具，两种选择都有其合理性。

中国市场的启示：别当“乘客”，要当“司机”

Claude Code之所以能采取一些“取巧”的策略，比如通过一个特殊的cache_edits API来编辑缓存而不使其失效，是因为它和底层的模型、API服务同属一家公司（Anthropic）。它能像操作系统一样，对底层资源有完全的控制权。

而OpenClaw的设计，则更像是一个在不拥有底层API控制权的“租户”环境下的最佳实践。它的防御性、可移植性和对稳定性的极致追求，恰恰是中国绝大多数AI应用开发者的现实处境。

无论是基于文心一言、通义千问，还是智谱清言来构建应用，开发者都无法控制模型服务端的缓存策略或API特性。这意味着，OpenClaw那套“步步为营”、“自我审计”的驾驭系统哲学，更具参考价值。它提醒我们，当无法控制引擎时，更要精心打造自己的车身和控制系统。

近年来，国内涌现出如Dify、Coze等优秀的AI应用开发平台，它们极大地降低了构建智能体的门槛。这些平台本质上提供了一套“标准版”的驾驭系统。这对于快速验证想法、构建原型是极好的起点。但我们必须清醒地认识到，通用的驾驭系统，无法在特定场景下做到最优。你继承了它的便利，也继承了它所有的设计取舍和局限性。

驾驭系统：AI时代的“操作系统”

上下文压缩，只是冰山一角。一个完整的智能体驾驭系统，还包括工具的路由与调度、多智能体协同、流式协议、错误分类、成本核算、记忆管理等一系列复杂的模块。每一项都充满了像Claude Code与OpenClaw之间那样的设计权衡。

这套系统正在成为AI时代的“操作系统”。OpenAI的Agents SDK、微软的Agent 365、Google的Gemini Enterprise Agent Platform，巨头们的布局已经清晰地表明，未来的竞争，将是平台与生态之争，而不仅仅是模型参数之争。谁的“驾驭系统”更健壮、更高效、更能吸引开发者，谁就能掌握下一代应用生态的话语权。

回到最初的问题。为什么不能直接买一套驾驭系统，把它当成商品化的基础设施？

答案是，你可以买来入门，但无法靠它赢得比赛。因为你的用户、你的业务场景、你的成本和延迟要求，都与通用方案的预设不尽相同。当你发现智能体在生产环境中行为诡异，或者延迟无法接受时，你最终还是得一头扎进源码，去理解并改造这套系统的“脾气”。

不要再被“薄封装”的说法迷惑了。对于所有严肃的AI应用构建者而言，驾驭系统本身就是产品，是核心竞争力，是那条最深、最宽的护城河。打造它的过程，充满了“脏活累活”，但也正是在这些细节中，诞生了卓越。