最近因业务需求，我们对OpenClaw进行了全面深度改造，彻底摸清了它在上下文处理中的各种特性和潜在问题。既然已经积累了丰富的实战经验，我们决定将这些能帮助广大用户大幅减少Token消耗的实用技巧系统整理出来，与大家分享。

Skills

OpenClaw的Skills机制本质上是一种“先展示、后调用”的流程。系统首先将所有可用的技能摘要注入上下文，当模型需要某个技能时，再通过Read工具加载完整文件。完整的执行链路如下：

磁盘 SKILL.md 文件
↓ loadSkillEntries() — 扫描磁盘
↓ filterSkillEntries() — 按配置过滤
↓ applySkillsPromptLimits() — 截断保护
↓ formatSkillsForPrompt() — 只取名称+描述
↓ skillsSnapshot.prompt（纯文本，约几百字节）
↓ buildSkillsSection() — 包裹使用规则
↓ system prompt 数组中展开

第一步：技能列表进入上下文的准入机制

系统首先会将所有可用Skills的name和description一并置入上下文。好消息是它只取前N个技能，默认上限为150个。但问题也很明显——即便只加载50个技能的name和description，累积的Token消耗依然不容小觑。随后它会使用二分查找，找到能装入上下文的最大前缀，默认字符上限为30,000。

第二步：触发实际加载的条件

只有当模型判断自身确实需要某个技能时，它才会主动调用Read工具去拉取具体的SKILL.md文件。需要特别注意，根据源码中的提示词设计，每一轮对话只会选中一个技能，不会同时加载多个。后续步骤与Token节省的关系不大。

Project Context

每次启动OpenClaw或创建新会话时，系统会根据配置（例如workspace下的AGENTS.md、SOUL.md以及其他指定的上下文文件）自动提取内容，并将其作为Project Context组装进System Prompt。这正是Token消耗的主要区域。其文件加载限制机制如下：

配置的 Project Context 文件列表
↓ buildBootstrapContextFiles() — 开始分配字符额度 (Budget)
↓ ├— 每个文件最高不超过 20,000 字符 (默认 bootstrapMaxChars)
↓ ├— 所有文件总计最高不超过 150,000 字符 (默认 bootstrapTotalMaxChars)
↓ 拼接进 System Prompt 的 Project Context 块

第一步：单文件额度与首尾保留策略

即使某个指导文件（如AGENTS.md）内容过长，超出了单文件字符上限（默认20,000字符），OpenClaw也不会简单粗暴地截断后半部分或直接报错。它采用了一种较为智能的截断策略：

• 保留文件开头的70%（Head Ratio = 0.7）
• 保留文件结尾的20%（Tail Ratio = 0.2）
• 被截掉的中间部分替换为一句[...truncated, read {fileName} for full content...]

然而，这种方法存在隐患：这种截断纯粹基于字符数量，完全不考虑语义。如果你恰好把一段特别详细、篇幅很长的排错代码或业务逻辑写在中间的被截断区域，那么大模型将完全看不到这部分内容，相当于这部分逻辑凭空消失了。

第二步：全局预算耗尽时的保护机制

OpenClaw提供了一套默认的文件模板，这主要是为新手提供一个较为安全的起点。实际上，你可以编写更多文件来引导大模型，只需在Agent.md或其他入口文件中引入即可。下表列出了这些默认文件的作用：

如果你的文件数量过多，即便每个文件都没有超过两万字，但所有配置文件的总字符数接近全局上限（默认150,000字符）时，每增加一个文件，系统剩余的可分配字符配额（remainingTotalChars）就会迅速减少。当加载到某个文件时，如果系统发现剩余配额不足64个字符（源码中硬编码的门槛MIN_BOOTSTRAP_FILE_BUDGET_CHARS），它会认为“只剩64个字符，引入一个文件毫无意义”，从而完全中断并放弃后续所有上下文文件的加载。

结束

为了避免文章过长影响阅读体验，本次我们重点分享了Skills和Project Context两个核心模块。后续文章将继续探讨配置优化以进一步节省Token、长期记忆的最佳总结机制、长记忆Embed/Query的实践应用以及缓存机制等话题。

根据我们的实际测试，完整实施上述优化后，每轮对话可节约30%~60%的Token消耗；如果针对具体业务进行深度定制，甚至可节约40%~80%。需要说明的是，此计算基准基于OpenClaw自带的Report函数，未计入上游缓存等场景，因此可能不够精确。但无论如何，Token调优的必要性和巨大价值已经显而易见。