大模型的上下文窗口是稀缺资源而 Skill、工具和能力描述却几乎可以无限扩展。于是Harness Agent 这类产品真正竞争的已经不只是模型本身的“智力”而是对有限上下文资源的控制能力。谁能更好地做上下文管理、预算分配和能力装载谁就更能把模型的能力稳定地交付到具体任务里。128K tokens 的上下文窗口听起来很大但它需要承载系统提示词、工具定义、对话历史、、Skill 的信息、模型输出预留空间。现在我们就一起感受下Codex对于Skill上下文预算控制的精妙设计。预算控制设计在深入算法之前回忆下之前有说过Codex的Skill的架构设计它的核心思想在于渐进式披露过程我们初步的理解为以下3个层级步骤Skill 上下文预算控制就是围绕整套 Skill 运作机制对上下文资源做精细分配。它要解决的不是单纯的长度限制而是在有限窗口内优先保留真正决定模型行为的那部分技能信息让关键能力能够稳定进入上下文、参与推理并尽量避免无关内容稀释指令密度。预算控制算法预算计算算法渐进式披露的第一步是确定 Skill 目录能占多少空间即预先设定Skill目录空间限制边界。Codex对于边界限定计算有两条路径1上下文占比约束当 Codex 能获取到模型的上下文窗口大小如 128K tokens是约定预算 上下文窗口 ×2%单位是 Tokens。例如OpenAI模型上下文窗口为128k时所允许的Skill目录占用的空间约128K → 128000 × 2% 2560 tokens2固定字符空间当获取不到上下文窗口大小模型信息未知或值为负数兜底预算 8000 字符单位是 Characters。这是因为Token 估算方法时依赖于模型OpenApi tokenizer计算对于未知的模型每次预算计算都要跑一遍 tokenizer 不现实所以固定字符空间约束 8000 字符是一个近似的空间大小token数 ≈ 字节数 ÷ 4。APPROX_BYTES_PER_TOKEN 4基于英文文本的平均 token 长度经验值。对中文等语言会有偏差1 个中文字 ≈ 3 字节 UTF-8 ≈ 0.75 token 而实际 tokenizer 可能算 1-2 token但作为预算控制足够用——预算控制不需要精确到每个 token只需要大致不超就行。所以这里需要注意的是同一个Skill描述在codex中的不同模型下可能计算出来开的cost是不同的因为可能使用了不同计算方式目录裁剪算法目录裁剪算法是生成Skill目录过程中核心的预算控制算法render_skill_lines_from_lines() 函数。它对所有 Skill 按三层策略递降处理每层对应不同的裁剪力度。这里的目录成本核心指名称、描述、路径 第一层全部展示无裁剪codex通过遍历所有 SkillLine累加每个 Skill 的 full_cost包含完整名称、描述的渲染成本如果总和不超过预算直接返回完整渲染结果。即所有skill目录成本总和预算此时不做任何裁剪全部展示给LLM。在大多数正常使用情况下—5 个 System Skill 几个用户 Skill总共 8-10 个 Skill——完整展示的总成本通常在 500-1500 tokens 之间远低于 2560 tokens的预算。所以通常来说个人使用时基于不会进入到裁剪策略中。 第二层裁剪描述逐字符公平分配算法不出意外的出现意外了当Skill过多时所有目录成本超过了预期的预算时可能就会触发当前裁剪策略。但是需要注意的是当前策略触犯条件为所有目录成本超过预算且去掉描述后的最小成本未超过预算此时codex采用的策略是裁剪描述逐字符公平分配算法即所有 Skill 保留在列表中不删除任何一个但描述被裁剪到更短。❌ 固定等分裁剪算法固定分配Codex在做描述裁剪时并不是固定等分的去裁剪每个skill即假设有4个skill预算大小为20则平均每个skill的预算空间为5token然后进行裁剪。这种方式存在一个较大的问题就是不公平例如某些skill可能描述很短但是却分配到了过多的预算导致预算浪费反而描述更长的skill却因为预算不足被裁剪。✔️逐字符公平分配算法按需分配Codex采用的是逐字符公平分配算法这是一种最精巧的算法目的在于按需分配描述越长分越多短描述Skill几乎没展示空间。算法而核心为每个 Skill 每轮获得 1 个描述字符的机会完全平等但短描述 Skill 用完原始描述后自动退出剩余预算自然流转给还在排队的长描述Skill。假设预算留给描述的空间只有 6 个字符有 3 个 Skill- Skill A 描述x1 字符- Skill B 描述abcdefghi9 字符- Skill C 描述uvwxyz6 字符最终的裁剪结果为Skill-A完整、Skill-Babc、Skill-Cuv。但是需要注意的是codex真正的成本计算不是简单的1 字符 1 成本。因为预算可能是 Token 单位需要把字符增量转换为 Token 增量。 第三层省略 Skill如果Skill目录最小成本整体成本 - 所有描述成本 name: (file: path)格式就已经超过了预算了此时就不再裁剪描述直接删除某些 Skill——名称和路径都不出现在目录中。这里本质上也很简单就是按照之前说的Skill分层优先级来进行省略。System → rank 0最高优先级Admin → rank 1Repo → rank 2User → rank 3最低优先级路径别名算法空间优化路径别名算法不是实际裁剪算法应该说是整个预算的一种空间优化算法。Skill 路径可能很长尤其是 Plugin 提供的 Skill。比如一个 Plugin Skill 的路径可能是/Users/xl/.codex/plugins/cache/openai-curated/github/hash1234567890/skills/gh-fix-ci/SKILL.md这个路径本身就有 90 字符在预算紧张时光是路径就吃掉大量空间。Codex 为长路径创建短别名——用 r0、r1、r2 等替代原始 Skill Root 路径形成映射关系例如### Skill roots - r0 /Users/xl/.codex/plugins/cache/openai-curated/ ### Available skills - gh-fix-ci: Fix CI pipelines (file: r0/github/hash1234567890/skills/gh-fix-ci/SKILL.md)内容截断算法硬截断Skill 目录只是第一层——始终可见的索引。当用户触发某个 Skill 时它的完整 SKILL.md 内容会被注入这是第二层。需要注意的是codex在对Skill内容采用的是硬截断的方式它约束Skill最大内容上限约 40000 字符约 10000 tokens一旦超过 40000 字符则在第 40000 个字符处截断返回截断后内容 truncated 标记。同时截断时发送 WarningSkill xxx exceeded the main prompt context limit and was truncated.采用硬截断的方式核心是因为极端场景触发首先40000 字符足够覆盖绝大多数 Skill大多数 SKILL.md只有几百到几千字符安全阀几乎不会被触发。它存在是为了防止极端情况——某个 Skill 的 SKILL.md 有 50000字符可能是作者不小心或包含了大段代码模板不会全部涌入模型请求撑爆上下文。所以裁剪是一种危险的行为因此我们在定义Skill内容需要充分考虑到这些因素。工程化总结这里分析的内容对于Codex上下文管理只是冰山一角例如去重机制、安全阀控制都没有说到。但是也是收益匪浅。Skill 系统的核心矛盾是无限增长的能力描述 vs 稀缺的上下文窗口。Codex 的应对方式不是超了就砍而是构建了一套分级的资源调度体系——预算计算定边界、目录裁剪在边 界内分配、内容截断防溢出止损。每一级都比上一级更激进但都有明确的触发条件。这套体系的设计哲学可以概括为一个词按需。目录始终注入因为模型需要知道有什么可用——这是基础需求不可省略完整内容按需注入因为只有被触发的 Skill 才需要详细指导——这是精准需求不可浪费路径别名按需启用因为预算充裕时绝对路径更直观——简单方案优先裁剪按需升级因为轻度压力裁剪描述就够了没必要直接省略 Skill同时在实际落地Skill时需要核心关注和思考一下描述的精炼度直接决定你能否被完整展示层级选择决定你的生存优先级SKILL.md 的长度控制在 40000 字符以内渐进式披露的三层结构是你的设计模板scripts 和 references 没有专属预算保护自己节省https://github.com/openai/codex
Codex Skill 上下文预算控制的精妙设计（原理）
大模型的上下文窗口是稀缺资源而 Skill、工具和能力描述却几乎可以无限扩展。于是Harness Agent 这类产品真正竞争的已经不只是模型本身的“智力”而是对有限上下文资源的控制能力。谁能更好地做上下文管理、预算分配和能力装载谁就更能把模型的能力稳定地交付到具体任务里。128K tokens 的上下文窗口听起来很大但它需要承载系统提示词、工具定义、对话历史、、Skill 的信息、模型输出预留空间。现在我们就一起感受下Codex对于Skill上下文预算控制的精妙设计。预算控制设计在深入算法之前回忆下之前有说过Codex的Skill的架构设计它的核心思想在于渐进式披露过程我们初步的理解为以下3个层级步骤Skill 上下文预算控制就是围绕整套 Skill 运作机制对上下文资源做精细分配。它要解决的不是单纯的长度限制而是在有限窗口内优先保留真正决定模型行为的那部分技能信息让关键能力能够稳定进入上下文、参与推理并尽量避免无关内容稀释指令密度。预算控制算法预算计算算法渐进式披露的第一步是确定 Skill 目录能占多少空间即预先设定Skill目录空间限制边界。Codex对于边界限定计算有两条路径1上下文占比约束当 Codex 能获取到模型的上下文窗口大小如 128K tokens是约定预算 上下文窗口 ×2%单位是 Tokens。例如OpenAI模型上下文窗口为128k时所允许的Skill目录占用的空间约128K → 128000 × 2% 2560 tokens2固定字符空间当获取不到上下文窗口大小模型信息未知或值为负数兜底预算 8000 字符单位是 Characters。这是因为Token 估算方法时依赖于模型OpenApi tokenizer计算对于未知的模型每次预算计算都要跑一遍 tokenizer 不现实所以固定字符空间约束 8000 字符是一个近似的空间大小token数 ≈ 字节数 ÷ 4。APPROX_BYTES_PER_TOKEN 4基于英文文本的平均 token 长度经验值。对中文等语言会有偏差1 个中文字 ≈ 3 字节 UTF-8 ≈ 0.75 token 而实际 tokenizer 可能算 1-2 token但作为预算控制足够用——预算控制不需要精确到每个 token只需要大致不超就行。所以这里需要注意的是同一个Skill描述在codex中的不同模型下可能计算出来开的cost是不同的因为可能使用了不同计算方式目录裁剪算法目录裁剪算法是生成Skill目录过程中核心的预算控制算法render_skill_lines_from_lines() 函数。它对所有 Skill 按三层策略递降处理每层对应不同的裁剪力度。这里的目录成本核心指名称、描述、路径 第一层全部展示无裁剪codex通过遍历所有 SkillLine累加每个 Skill 的 full_cost包含完整名称、描述的渲染成本如果总和不超过预算直接返回完整渲染结果。即所有skill目录成本总和预算此时不做任何裁剪全部展示给LLM。在大多数正常使用情况下—5 个 System Skill 几个用户 Skill总共 8-10 个 Skill——完整展示的总成本通常在 500-1500 tokens 之间远低于 2560 tokens的预算。所以通常来说个人使用时基于不会进入到裁剪策略中。 第二层裁剪描述逐字符公平分配算法不出意外的出现意外了当Skill过多时所有目录成本超过了预期的预算时可能就会触发当前裁剪策略。但是需要注意的是当前策略触犯条件为所有目录成本超过预算且去掉描述后的最小成本未超过预算此时codex采用的策略是裁剪描述逐字符公平分配算法即所有 Skill 保留在列表中不删除任何一个但描述被裁剪到更短。❌ 固定等分裁剪算法固定分配Codex在做描述裁剪时并不是固定等分的去裁剪每个skill即假设有4个skill预算大小为20则平均每个skill的预算空间为5token然后进行裁剪。这种方式存在一个较大的问题就是不公平例如某些skill可能描述很短但是却分配到了过多的预算导致预算浪费反而描述更长的skill却因为预算不足被裁剪。✔️逐字符公平分配算法按需分配Codex采用的是逐字符公平分配算法这是一种最精巧的算法目的在于按需分配描述越长分越多短描述Skill几乎没展示空间。算法而核心为每个 Skill 每轮获得 1 个描述字符的机会完全平等但短描述 Skill 用完原始描述后自动退出剩余预算自然流转给还在排队的长描述Skill。假设预算留给描述的空间只有 6 个字符有 3 个 Skill- Skill A 描述x1 字符- Skill B 描述abcdefghi9 字符- Skill C 描述uvwxyz6 字符最终的裁剪结果为Skill-A完整、Skill-Babc、Skill-Cuv。但是需要注意的是codex真正的成本计算不是简单的1 字符 1 成本。因为预算可能是 Token 单位需要把字符增量转换为 Token 增量。 第三层省略 Skill如果Skill目录最小成本整体成本 - 所有描述成本 name: (file: path)格式就已经超过了预算了此时就不再裁剪描述直接删除某些 Skill——名称和路径都不出现在目录中。这里本质上也很简单就是按照之前说的Skill分层优先级来进行省略。System → rank 0最高优先级Admin → rank 1Repo → rank 2User → rank 3最低优先级路径别名算法空间优化路径别名算法不是实际裁剪算法应该说是整个预算的一种空间优化算法。Skill 路径可能很长尤其是 Plugin 提供的 Skill。比如一个 Plugin Skill 的路径可能是/Users/xl/.codex/plugins/cache/openai-curated/github/hash1234567890/skills/gh-fix-ci/SKILL.md这个路径本身就有 90 字符在预算紧张时光是路径就吃掉大量空间。Codex 为长路径创建短别名——用 r0、r1、r2 等替代原始 Skill Root 路径形成映射关系例如### Skill roots - r0 /Users/xl/.codex/plugins/cache/openai-curated/ ### Available skills - gh-fix-ci: Fix CI pipelines (file: r0/github/hash1234567890/skills/gh-fix-ci/SKILL.md)内容截断算法硬截断Skill 目录只是第一层——始终可见的索引。当用户触发某个 Skill 时它的完整 SKILL.md 内容会被注入这是第二层。需要注意的是codex在对Skill内容采用的是硬截断的方式它约束Skill最大内容上限约 40000 字符约 10000 tokens一旦超过 40000 字符则在第 40000 个字符处截断返回截断后内容 truncated 标记。同时截断时发送 WarningSkill xxx exceeded the main prompt context limit and was truncated.采用硬截断的方式核心是因为极端场景触发首先40000 字符足够覆盖绝大多数 Skill大多数 SKILL.md只有几百到几千字符安全阀几乎不会被触发。它存在是为了防止极端情况——某个 Skill 的 SKILL.md 有 50000字符可能是作者不小心或包含了大段代码模板不会全部涌入模型请求撑爆上下文。所以裁剪是一种危险的行为因此我们在定义Skill内容需要充分考虑到这些因素。工程化总结这里分析的内容对于Codex上下文管理只是冰山一角例如去重机制、安全阀控制都没有说到。但是也是收益匪浅。Skill 系统的核心矛盾是无限增长的能力描述 vs 稀缺的上下文窗口。Codex 的应对方式不是超了就砍而是构建了一套分级的资源调度体系——预算计算定边界、目录裁剪在边 界内分配、内容截断防溢出止损。每一级都比上一级更激进但都有明确的触发条件。这套体系的设计哲学可以概括为一个词按需。目录始终注入因为模型需要知道有什么可用——这是基础需求不可省略完整内容按需注入因为只有被触发的 Skill 才需要详细指导——这是精准需求不可浪费路径别名按需启用因为预算充裕时绝对路径更直观——简单方案优先裁剪按需升级因为轻度压力裁剪描述就够了没必要直接省略 Skill同时在实际落地Skill时需要核心关注和思考一下描述的精炼度直接决定你能否被完整展示层级选择决定你的生存优先级SKILL.md 的长度控制在 40000 字符以内渐进式披露的三层结构是你的设计模板scripts 和 references 没有专属预算保护自己节省https://github.com/openai/codex
