Appearance
让 Codex 跑得更久、做得更多
本文整理自 OpenAI 官方博客：Shell + Skills + Compaction: Tips for long-running agents that do real work，介绍三个让 Codex 处理长任务的核心能力：Skills（技能）、Shell 工具和上下文压缩。
三个核心概念，先搞清楚
Skills（技能）：可重复调用的操作手册
Skill 是一个文件包 + 一个 SKILL.md 说明文件。你可以把它想象成版本化的操作手册——需要做某件事的时候，Codex 就翻出来按照手册执行。
每个 Skill 暴露给 Codex 的信息是：名称、描述、路径。Codex 根据这些来决定要不要调用它，调用的时候才会读完整的 SKILL.md。
Shell 工具：给 Codex 一个真实的终端
Shell 工具让 Codex 在真实的终端环境里干活，包括：
- OpenAI 托管的容器：通过 Responses API 运行，有状态、支持多轮连续操作
- 本地 Shell：你自己控制机器，工具语义一样
托管 Shell 可以安装依赖、跑脚本、生成输出文件（比如报告、数据集）。
上下文压缩：防止长任务被"撑死"
任务跑得越长，上下文窗口越容易撑满。服务器端压缩会自动帮你处理，两种方式：
- 自动压缩：上下文超过阈值时在流式输出中自动触发，什么都不用做
- 手动压缩：调用
/responses/compact端点，自己控制压缩时机
为什么要一起用？
- Skills 把稳定的流程和模板从提示词里移走，需要的时候再加载
- Shell 提供完整的执行环境，真正能跑代码、生成文件
- 压缩 保证长流程不会因为上下文撑满而中断
- 三者结合 = 可重复执行的真实工作流，而不是脆弱的巨型提示词
10 条实用技巧
1. Skill 的描述要回答三个问题
Skill 的 description 实际上是 Codex 决定要不要调用它的依据，写得好坏直接影响触发准确率。
描述里要回答：
- 什么时候该用这个 Skill？
- 什么时候不该用？
- 这个 Skill 的输入、输出和成功标准是什么？
建议在描述里加一个短小的「用 vs. 不用」对比块，写得越具体越好。
2. 加上反面例子，减少误触发
有个反直觉的现象：把 Skill 加进来之后，一开始准确率可能会下降。
原因是模型不确定什么时候该用，于是乱触发或者不触发。
修复方式：在描述里加上明确的「不要在 X 情况下调用这个 Skill（应该用 Y 替代）」的案例。
Glean 的实测数据：加入 Skill 路由后，触发率最初下降了约 20%，加上反面例子和边缘情况覆盖后完全恢复。
3. 模板和示例放进 Skill，不要堆在系统提示词里
以前习惯把报告模板、格式示例塞进系统提示词？换个做法——放进 Skill 里。
好处有两个：
- 按需加载：只有 Skill 被调用时才占用上下文，不相关的查询完全不用付这个代价
- 质量更好：模板在需要的时候清清楚楚地呈现给模型
特别适合有固定输出格式的场景：结构化报告、数据解析报告、账户计划、升级摘要……
Glean 反馈：这种模式带来了他们生产环境中最大的质量提升和延迟改善。
4. 一开始就规划好容器复用和压缩
长期任务很少能靠一次提示跑完。从设计阶段就要考虑连续性：
- 跨步骤复用同一个容器，保持依赖、缓存文件和中间输出的稳定
- 传入
previous_response_id，让模型在同一线程里继续工作 - 把压缩当成默认选项，而不是撑不住了才用的应急手段
5. 需要确定性时，直接告诉模型用哪个 Skill
默认情况下，Codex 自己决定调不调用 Skill，这通常够用。
但如果你在跑一个有明确要求的生产流程，不需要模型"灵活发挥"，直接说：
"使用
<skill 名称>技能。"
这是最简单的可靠性手段——把模糊的路由变成明确的指令。
6. Skill + 网络访问 = 高风险，要谨慎设计
这是容易忽视、但后面很难补救的安全点。
Skill 加上开放网络访问，是数据泄露的高风险组合。
推荐的默认姿态：
- Skills：允许
- Shell：允许
- 网络：默认不开，需要时只开白名单里精确的域名
使用了网络的工具输出要视为不可信数据，不要直接拿来执行。
7. 用 /mnt/data 作为输出文件的统一存放点
在托管 Shell 里，把所有输出文件（报告、清洗后的数据、电子表格）统一写到 /mnt/data。
好的工作模式：工具写磁盘 → 模型在磁盘上推理 → 开发者从磁盘取结果。
这样有清晰的交接边界，输出可以被检索、审查，或传给下一步流程。
8. 网络白名单是两层结构
网络权限在两个地方控制：
- 组织级白名单（管理员配置）：设定最大允许的目标域名集合
- 请求级
network_policy：必须是组织白名单的子集
实操建议：
- 组织白名单保持小而稳定——只放你真正信任的域名
- 请求白名单更小——只放这个任务实际需要的域名
如果请求里包含组织白名单之外的域名，会直接报错。
9. 用 domain_secrets 传认证信息，别把密钥暴露给模型
如果需要调用需要鉴权的 API，用 domain_secrets——模型只会看到占位符（比如 $API_KEY），真实的值只在请求到达批准的目标域名时才被注入。
这是代理需要调用受保护 API 时的安全默认做法。
10. 本地开发 + 云端部署，Skills 保持不变
两种模式可以自由切换：
- 本地 Shell 模式：自己执行
shell_call，把结果返回给模型，迭代快、调试方便 - 托管容器：需要可重复性、隔离和部署一致性时切换过去
推荐的开发流程：
- 本地跑，快速迭代
- 稳定后迁移到托管容器
- Skills 在两种模式下保持一致——工作流不变，只是执行环境换了
三种组合模式
模式 A：安装依赖 → 拉取数据 → 生成文件
最简单的 Shell 用法：
- 安装几个库
- 调接口或抓数据
- 把报告写到
/mnt/data/report.md
这是"真实工作代理"的基础，输出结果清晰，可以展示给用户、存日志，或传给下一步。
模式 B：Skills + Shell 实现可重复工作流
跑几次 Shell 工作流之后会发现：提示词一飘，可靠性就下降。这时候引入 Skills：
- 把步骤、规则、模板写进 Skill
- 把 Skill 挂载到 Shell 环境
- 让 Codex 按照 Skill 执行，稳定产出
特别适合：表格分析、数据清洗 + 摘要生成、定期业务报告……
模式 C（进阶）：Skills 作为企业工作流载体
当你需要多工具协作时，Skills 可以让工具调用逻辑变得程序化，而不需要把所有东西塞进系统提示词。
Glean 的实测数据：一个面向 Salesforce 的 Skill 把评估准确率从 73% 提升到 85%，首 token 响应时间缩短了 18.1%。
关键手段：精细的路由、反面例子、把模板嵌入 Skill。
Skills 最终会变成组织的活的操作手册（SOP）：随业务演进而更新，由代理稳定执行。
快速总结
- Skills：把"怎么做"编码进去——步骤、模板、规则
- Shell：执行"做"这个动作——安装、运行、写文件
- 压缩：让长流程保持连贯——不用手动管理上下文
- 本地迭代快，稳定后上托管容器
- 网络权限默认收紧，用
domain_secrets传密钥 - Skills 两种模式通用，工作流写一次到处跑