有一句行话流传甚广：Token就是钱。每一个kan似微小的字符消耗，背后dou牵动着真金白银的API账单。对于长期运行的AI Agent，尤其是像OpenClaw这样复杂的系统，Ru果不精打细算，一个月下来烧掉几千美元简直是轻而易举的事。你可Neng会问，OpenClaw究竟有什么魔力，Neng让它在保持高性Neng的同时把成本控制在如此低廉的范围内？

答案并不神秘，它不依赖某种单一的“银弹”技术，而是建立在一套严密的、分层级的13项省Token设计之上。这套方案从System Prompt的构建，到对话历史的压缩，再到工具输出的截断，乃至底层的缓存策略，全方位地构筑了成本防线。今天我们就来拆解这套设计，kankan它是如何把每一分钱dou花在刀刃上的。

一、 核心哲学：每一处架构dou是取舍

在深入具体的技术细节之前，我们必须先理解OpenClaw的设计哲学。这里没有随意的代码堆砌，每一个决策背后dou是对成本与收益的权衡。正如技术圈里常说的，Token就是钱，每一个省token的决策背后dou是一个架构取舍。

hen多开发者习惯于把所有信息一股脑地塞给模型，觉得“给得越多，效果越好”。但在OpenClawkan来这是一种极其奢侈且低效的Zuo法。真正的优化，是在不牺牲智Neng表现的前提下通过精巧的架构设计，剔除那些冗余的、重复的、低价值的信息。这不仅仅是省钱，geng是为了让模型“思考”得geng专注。

二、 System Prompt层：控制固定开销的源头

System Prompt是每次请求dou会携带的“固定成本”。Ru果这部分过于臃肿，无论后续对话多么简短，基础费用dou会居高不下。OpenClaw在这一层埋下了五个精妙的设计。

1. Bootstrap文件的“硬截断”机制

想象一下Ru果用户心血来潮，写了一本几万字的小说作为AGENTS.md，或者把SOUL.md写得像百科全书一样长。Ru果每次请求dou把这些完整内容注入，那Context Window瞬间就会被填满，Token消耗量将呈指数级上升。

OpenClaw对此设计了“双闸门”机制：

单文件上限通过bootstrapMaxChars参数限制单个配置文件的字符数。

总量上限通过bootstrapTotalMaxChars限制所有配置文件加起来的总字符数。

一旦超出，系统会自动截断并打上标记。这就像是给每个文件穿上了“紧身衣”。Ru果模型真的需要kan完整版，它完全Ke以通过调用read工具按需读取。这种“按需分配”的策略，防止了单一文件吞噬几万Token的灾难。

2. Skills的“按需加载”策略

OpenClaw拥有强大的技Neng系统，但Ru果你安装了上百个Skill，每个Skill的说明文档又有几千字符，全量加载简直是噩梦。

设计者在这里采用了类似“图书馆索引”的方案。System Prompt里只注入一个极其紧凑的清单：包含Skill的名字、一句话描述和文件路径。这通常只占几行文本。当模型判断当前任务需要某个特定Skill时它会主动去read对应的SKILL.md。

这种设计虽然增加了一次工具调用的Overhead，但相比于把所有Skill全塞进System Prompt，节省的Token量高达90%以上。这就是典型的“以时间换空间”的智慧。

3. 子Agent的“极简主义”提示

主Agent负责统筹，而子Agent负责具体的执行。OpenClaw发现，子Agent根本不需要知道“主人叫什么名字”、“Agent的人格是什么”或者“心跳怎么回复”。

因此，OpenClaw引入了promptMode: minimal模式。在这种模式下子Agent的提示词被大幅精简：

砍掉Skills列表。

砍掉Memory Recall指令。

砍掉Self-Update、Reply Tags、Silent Replies、Heartbeats等元数据。

Bootstrap文件也只保留核心的AGENTS.md和TOOLS.md，跳过SOUL.mdUSER.md等。

通常，子Agent的System Prompt只有主Agent的三分之一到一半大小。考虑到一个主Agent可Neng会同时Spawn多个子Agent，这种节省是乘数级的，效果惊人。

4. 时间信息的“缓存友好”设计

这是一个极其细节但影响深远的优化。hen多开发者习惯在System Prompt里写入精确到秒的当前时间。然而Anthropic的Prompt Cache机制是基于前缀匹配的。Ru果时间戳每秒dou在变，那么缓存的前缀就永远无法命中，导致每次请求dou要重新计费。

OpenClaw的Zuo法是：System Prompt里只写时区，不写具体时间。当模型需要知道时间时通过调用session_status工具获取。用一次极小的工具调用，换取整个Session的缓存命中率，这笔账算得非常精明。

5. 日记文件的“非自动注入”原则

MEMORY.md作为长期记忆，会被注入System Prompt，因此必须严格控制其大小。但是那些记录日常琐碎的memory/--.md日记文件，绝对不Neng自动注入。

试想一下Ru果你用了三个月，每天生成一个日记文件，几十个文件全被注入，那System Prompt比整本小说dou长，模型根本没法聊天。OpenClaw采用向量检索的方式，只返回Zui相关的Snippet，上限约几百字符。这既保留了记忆的连贯性，又避免了Context的爆炸。

三、 对话历史层：遏制无限增长的怪兽

随着对话的进行，历史消息会不断累积。Ru果不加控制，Context Windowhen快就会被填满。OpenClaw在这一层部署了两个强有力的策略。

6. Compaction：有损压缩的艺术

当对话历史接近Context Window的上限时OpenClaw会触发Compaction机制。这是一种暴力但极其有效的手段：将几百条旧消息压缩成一段精炼的摘要。

虽然这属于“有损压缩”，会丢失一些细节，但对于维持对话的长期进行至关重要。它就像是一个定期清理垃圾的后台程序，确保模型始终关注Zui新的上下文，而不是被陈旧的历史拖垮。

7. Inbound Debounce：合并“连珠炮”

用户在聊天时往往会连续快速发送多条消息。Ru果每发一条就触发一次Agent Run，那么System Prompt和历史记录就会被重复加载多次造成巨大的浪费。

OpenClaw设置了一个窗口期。在这个窗口内到达的消息，会被系统“拦截”并合并成一条，再一次性送给模型。这不仅节省了Token，还避免了模型因为处理碎片化信息而产生混乱。

四、 工具输出层：三道防线的层层阻击

工具返回的内容往往是Token消耗的大户，特别是读取日志或代码文件时。OpenClaw为此构筑了“三道防线”。

8. 第一道防线：工具自身的输出截断

这是源头控制。read工具默认限制读取行数或总大小，exec工具也有输出限制。工具在返回结果之前，就Yi经把过长的内容“砍”了一刀。大部分情况下你不需要在Context里塞一个10MB的日志文件，这一刀通常就足够了。

9. 第二道防线：可编程的持久化钩子

工具结果在写入Session的JSONL文件之前，会经过tool_result_persist插件钩子。这是一个可编程的拦截点。

开发者Ke以编写插件，根据工具类型、输出内容或大小，决定是否修改或截断内容。例如设定一个规则：所有超过1万字符的工具结果在持久化时就强制截断。这样，后续加载历史记录时这些臃肿的数据就不会再出现，从根源上防止了历史记录的膨胀。

10. 第三道防线：Session Pruning

这是Zui后一道关卡。在每次LLM调用前，系统会对旧的toolResult进行Soft-trim或Hard-clear。

前两道防线管的是“新进来的数据有多大”，而Pruning管的是“旧的数据还要不要留”。通过cache-ttl模式，在缓存过期后系统会优先砍掉旧的工具输出，使得重新缓存时的cacheWrite体积geng小，从而进一步省钱。

五、 缓存与架构层：系统级的降本增效

除了针对内容的优化，OpenClaw在架构层面也Zuo了深度的挖掘，充分利用了云厂商的计费特性。

11. Prompt Cache的极致对齐

Anthropic的API支持Prompt Caching：Ru果两次请求的前缀相同，后续请求只需要为新增部分付费。OpenClaw的整个System Prompt设计dou是为了配合这一机制。

此外OpenClaw的Smart Defaults还会根据认证方式自动调整参数。例如OAuth用户的心跳间隔设为较长，API Key用户的心跳设较短，cacheControlTtl也会相应优化。这一切的目标，就是让缓存利用率Zui大化，让每一分钱dou花在真正的“新内容”上。

12. Session隔离：拒绝“污染”

每个聊天位置dou是独立的Session。Ru果不Zuo隔离，#general频道的闲聊会被带入#coding频道的上下文中。模型在写代码时还要处理一堆无关的聊天记录，这纯粹是浪费Token。

通过严格的Session隔离，OpenClaw确保了上下文的纯净性，不仅提升了响应质量，也大幅降低了无效消耗。

13. Inbound去重：拒绝重复劳动

在网络不稳定的情况下Channel重连可Neng会导致同一条消息被重复投递。Ru果没有去重机制，同一条消息会触发两次Agent Run，导致双倍的Token消耗和重复的回复。

OpenClaw利用短期缓存，根据Channel、Account、Peer、Session、Message ID进行多维去重。这kan似简单的逻辑，在实际生产环境中Neng避免大量的资源浪费。

六、 ：从$3600到$15的跨越

技术博主Federico Viticci曾分享过他在一个月内烧掉180万Token、账单高达$3600的惨痛经历。而经过OpenClaw这类优化方案的处理，同样的工作流，成本Ke以被压缩到$2-$15的区间。

这13项设计，没有哪一个是惊天动地的黑科技，但它们组合在一起，形成了一套严密的防御体系。从System Prompt的精简，到历史记录的压缩，再到工具输出的截断和缓存的利用，OpenClaw向我们展示了：优秀的AI工程，不仅仅是让模型变聪明，geng是让模型变“省”。

对于每一个致力于构建长期运行的AI应用的开发者来说这套设计理念dou值得反复研读和实践。毕竟在Token的世界里省下来的就是赚到的。

---