推荐语
OpenClaw的上下文保护机制如何影响Skill使用？了解规则，避免性能下降与成本增加。
核心内容：
1. 上下文保护机制的作用与触发条件
2. Skill数量与描述长度的具体限制规则
3. 避免触发降级的实用优化建议
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
大家好，这篇来聊一个很多人可能没注意到，但如果踩坑了可能会很困惑的问题——OpenClaw 的上下文长度保护机制。
在上一篇文章里我们提到，OpenClaw 每次发消息给模型，都会带上所有可用 Skill 的 name 和 description。如果 Skill 数量太多，或者 description 写得太长，上下文就会变得很大，既影响性能，也增加成本。所以 OpenClaw 引入了一个保护机制：当上下文超过一定阈值时，Skill 会被降级发送。
这篇就来具体说说，这个机制是怎么工作的，以及我们怎么写 Skill 才能避免被降级。
上下文保护机制是什么
OpenClaw 文档中我没看到有这个叫法，上下文保护这是我自己想出来的一个说法，不过实际上做的事情就是这个意思。
简单说，OpenClaw 对于可用 skill 列表的提示词是有一个长度控制的，如果超过默认阈值，会触发降级规则，对 Skill 列表进行压缩。压缩的方式有两种：减少发送的 Skill 数量，或者改用不含 description 的紧凑格式。
我先用文字跟大家描述一下这个规则。节省大家精力，需要看详细分析的话后面也有代码分析。
OpenClaw 每次调用模型的时候，不会把 Skill 的完整内容都发过去， 只会最多发给模型这些 skill 的 name 和 description 属性，构建出来是一个 xml 格式的字符串，在提示词的 skill 分段中，就是这个样子：
<skill>
<name>...</name>
<description>...</description>
<location>...</location>
</skill>
然后说说这个长度规则的判断过程，每次模型运行的时候， 会加载出我们所有可用的 skill 列表。
第一步 - 先做一个 skill 数量匹配，默认值是 150 个上限。 如果我们实际使用的 skill 超过这个上限，包括 OpenClaw 自带的 skill 都算在一起，后面超出的就会被截断，根本不会发给模型。 当然，我们可以用这个设置项，改变这个上限: skills.limits.maxSkillsInPrompt
第二步 - 处理完 skill 数量判断后，如果超出数量，就会被截断成新列表，如果没超出，会保留原来的列表。 然后会用这个列表生成我们上面展示的那个的形式的 xml 字符串。 这一步会判断这个 xml 字符串的长度，如果超出默认的 18000 字符的上限，就会进入 compact 模式。这个上限也可以通过配置项修改：skills.limits.maxSkillsPromptChars
如果进入 compact 模式，就会去掉 description，再重新生成 xml 字符串，就是这个格式：
<skill>
<name>...</name>
<location>...</location>
</skill>
这时候还会继续判断， 如果 compact 模式压缩后的 xml 字符串还是超出上限，就会用二分查询继续缩短列表。 简单来说，最极端的这个情况下，不但 xml 变成压缩模式，skill 列表还会进一步被截断。
大家可以看到， 一旦进入 compact 模式，description 属性就不会发给模型了，这种模式下，一定会造成模型对 skill 理解能力的显著下降。如果 skill 列表还被截断的话，那么有些 skill 模型根本都看不见。
关于如何调整这两个上限的配置项，给大家一个 openclaw.json 示例：
{
"skills": {
"limits": {
"maxSkillsInPrompt": 150,
"maxSkillsPromptChars": 18000
}
}
}
实际情况就是，对于大部分用户，skill 数量超过这个数量上限的概率并不大，除非是你特别爱折腾 skill， 安装了很多其他的。 唯一要注意的是你的 skill 文件中 name 和 description 属性不要写的太长，这个是真的会累加到 xml 字符串上限的。
我相信看完我给大家介绍的这个机制，大家如果不小心真的遇到这种 skill 被吞掉的奇怪问题，就不会摸不着头脑了。
如果大家精力有限的话， 看到这里也够了。 下面是一个详细的代码分析，如果有时间，也可以继续看。 也可以收藏下来以后参考用。
代码分析
具体的规则就在下面这些关键代码上，我先贴出来，这个代码稍长，需要两张图。
贴图的下面段落，会把重要的地方跟大家聊一下：
第一个关键点在这里：
const byCount = params.skills.slice(0, Math.max(0, limits.maxSkillsInPrompt));
maxSkillsInPrompt 是每个 Prompt 最大允许的 skill 数量， 默认值是 150， 如果我们当前会话可用的 skill 超过这个数量， 后面的会被截断。 意思就是完全不会发给模型。
接下来要说的，就是这块 if 判断：
if (!fitsFull(skillsForPrompt)) {
if (fitsCompact(skillsForPrompt)) {
compact = true;
} else {
compact = true;
//，，，
truncated = true;
}
}
首先 fitsFull， 它的意思就是先用全量的规则解析一下，就是带 description 的 xml 格式:
<skill>
<name>...</name>
<description>...</description>
<location>...</location>
</skill>
fitsFull，先解析成全量的 skill 字符串，判断是否超过允许的上限：
const fitsFull = (skills: Skill[]): boolean =>
formatSkillsForPrompt(skills).length <= limits.maxSkillsPromptChars;
maxSkillsPromptChars 就是这个 skill 字符串长度上限， 这个上限是 18000 个字符。 如果超出，就执行 if (fitsCompact(skillsForPrompt)) 这个分支。
fitsCompact 也不难理解，就是去掉 xml 的 description，再判断是否超出字符串长度上限。如果还超出，就进入下面的 if 分支。尝试进一步缩减 skill 列表，符合这个上限。
总结
这次就是和大家把 OpenClaw 关于 skill 长度限制的事情聊了一下，因为它现在如果真的发生了 compact 模式压缩，以及列表缩短， 用户是看不到提示的，只会给模型一个提示词，说列表被缩短了。 如果大家真的遇到这种边缘情况，在不知道这个机制存在的情况下，可能会很难调试问题。
因为 OpenClaw 是一个更新非常快的产品， 我现在说的机制，也只是基于当前版本的，以后这个机制可能也会调整，就要以最新的代码为准了。
说到可以优化的地方，比如最后这个二分查询缩短列表的方法，设计的健壮性可以更好一些。 比如优先去删除那些 name 和 description 超出其他 skill 太多的，而不是二分查询几乎等同于随机的删除，这样就完全避免少数超大元信息的 skill 挤掉其他的了。 我相信后续版本也会改进这个问题。
粤ICP备14082021号
免费POC，
零成本试错
