Codex 工程实践（一）：个人与企业如何减少使用漂移
用 Coding Agent 做事，最让人困惑的往往是：同一个仓库、看起来一样的要求，昨天能完成，今天却走了另一条路。终端里能改文件，自动化任务只会读；自己的电脑遵守规范，同事那里又多了一套习惯。
读完《Codex 源码分析》的第 2～5 章，我更倾向于先把这些问题当作运行条件和任务约束的漂移来排查。模型输出存在波动，但入口、配置、工作目录和验收标准的不一致，通常更容易定位和修正。
本系列按博客时间轴编排日期，资料统一于 2026-11-05 阅读与核对。参考系列固定到
f31e90b79f594c606746626a56bdf1e49497b275；本文另核对 OpenAI Codex 上游86ac0916597244a2e67a197822a5483924660ff1。下文的实践方案是我的归纳，不代表产品提供确定性执行保证。
一、先把“漂移”分成四类
| 漂移类型 | 常见表现 | 优先检查什么 |
|---|---|---|
| 入口漂移 | TUI、IDE、自动化任务行为不同 | 实际版本、启动参数、工作目录、认证方式 |
| 配置漂移 | 换个人就换模型、权限或工具 | 用户配置、项目配置、profile、运行时覆盖及组织要求 |
| 任务漂移 | 修一个错误，最后重构整个模块 | 当前目标、允许修改范围、用户最新纠正 |
| 验收漂移 | 代理说完成，流水线仍然失败 | 检查命令、产物要求、失败条件 |
这四类经常叠加。例如，个人终端选过一个宽松的权限配置，CI 没有；任务只写“修好测试”，没有说能否修改接口。结果两次运行不但能做的事不同，对“完成”的理解也不同。
因此，减少漂移的第一步是记录这次运行的条件。只保存最后一条提示词，很难解释差异。
二、多个入口共享核心，也要核对入口契约
参考第 2 章把启动路径拆成了包装入口、原生运行时和子命令分发。这个拆法提醒我：看到相同的 codex 名字，不能直接认定实际执行条件相同。
对个人使用，先核对当前运行版本、仓库路径和配置位置，通常就能排除不少问题。对企业集成，还要记录任务由哪个客户端发起，最终启动的是哪个运行时，以及哪些参数由宿主补入。
exec 尤其值得单独看待。它面向脚本消费，标准输出、事件流和审批行为不能直接照搬交互界面的体验。参考第 4 章还说明了参数输入与 stdin 的组合语义：脚本通过两个入口同时传文本时，最终可能把它们组合起来。
一个可行的约定是：任务要求只从一个明确入口传入；差异、日志或其他材料作为带来源的附加内容。自动化平台同时保存最终任务文本与材料标识，才能复盘实际送入了什么。
三、配置选择与组织约束要分别理解
我会把配置分成两个问题：这次运行希望选什么，以及组织允许选什么。
用户偏好的模型、项目工具、会话参数属于前一个问题；组织对执行权限、网络访问和工具来源的限制属于后一个问题。AGENTS.md 中写“不要访问某目录”可以指导代理，但要建立访问边界，仍需执行层的权限策略。官方安全文档也将沙箱限制与审批区分为不同控制层。
更有意思的是，规则本身也会随版本变化。参考第 3 章展示的源码中，requirements 按来源顺序填充尚未设置的字段，先出现的约束不能由后面的来源覆盖。然而这次核对的上游配置加载器已经明确写成：requirements 按递增优先级收集，再进行配置式 TOML 合并，并对 hooks、rules、deny-read 和远程沙箱配置作字段特定处理。
这说明一张曾经正确的配置优先级图，也可能成为后来的漂移来源。团队需要随运行版本一起维护配置解释，升级后重新检查最终生效结果。把旧文章里的顺序长期写死在部署文档里，反而会掩盖真实行为。
我建议运行记录至少保留以下信息，凭据只记录方式和来源，不记录密钥：
1 | 运行身份：客户端版本、运行时版本、仓库提交、工作目录 |
这份记录是排障用的快照。即使不追求逐次完全复现，它也能把“好像一样”变成可以比较的条件。
四、个人使用：把稳定规则留在仓库里
个人最容易遇到的是规则散落：测试方法在前一个聊天里，目录约定在另一个笔记里，当前任务还继承了过时的决定。
适合放进 AGENTS.md 的内容，应当是仓库内相对稳定、会影响执行的事实，例如入口目录、常用检查方式、生成文件的位置和必须保持兼容的接口。当前功能需求、临时例外和本次修改目标则跟随任务。
例如下面是一份示意性的项目约定，需要替换成仓库真实命令：
1 | # 项目约定 |
不要把所有经验都堆进同一个文件。规则越长、重复和冲突越多，维护成本越高。目录层级的规则也需要结合实际工作路径检查加载情况；“根目录存在文件”不等于当前任务已经获得所有相关约束。
对长任务，我会在阶段切换时核对三个东西：当前要解决的问题、已经验证的事实、下一步动作。用户改变方向时，把旧决定标成已替代，避免新旧要求同时看起来有效。
五、企业使用：基线、例外和结果都要可审查
企业可以在个人做法上增加三层管理。
第一层是运行基线。固定经过验证的版本和配置组合，为终端、IDE 与 CI 建立一组共同的验收任务。这里的固定是升级前有验证依据，并非永远不升级。
第二层是例外机制。临时增加写目录或外部访问时，记录用途、适用范围和结束条件。任务完成后回收例外，避免一次排障变成长期扩大权限。
第三层是结果契约。让自动化任务分别输出过程事件与最终结果，再由调用方检查产物和验收条件。即使请求使用 JSON Schema，也应检查任务是否成功结束、字段是否齐全、引用文件是否真实存在。结构正确只能说明格式可消费，不能说明工作已经完成。
下面是一份应用侧结果格式示意，不是 Codex 内置协议：
1 | { |
升级时，可以从团队常见任务中挑选少量固定样例：一个局部修复、一个跨目录修改、一个权限应被拒绝的操作、一个需要恢复的任务。比较的不只是答案，还包括修改范围、工具使用、检查结果与拒绝行为。
这种做法无法消除模型的全部随机性，但能帮助团队判断：差异来自能力波动、运行条件变化，还是任务定义不清。
六、从一次偏航中恢复
如果代理已经改偏，继续补一大段“以后注意”通常收效有限。我更愿意先检查当前差异，明确哪些修改保留、哪些撤回，再用现有文件与检查结果重建下一步。
例如任务原本只要求修正日期排序，却引入了新的时间库。恢复时应明确是否允许新增依赖，核对现有排序测试，并把下一步收敛到具体文件和行为。不要让代理为了维护先前方案而继续扩大修改。
个人可以从一份简短的项目约定开始；企业则需要把运行基线、组织约束与验收记录接起来。每次出现差异时，都能回答“本次究竟在哪些条件下执行了什么”，漂移才有机会被稳定地治理。
参考阅读
本文按指定章节重新组织问题与实践建议，章节链接固定到阅读时的版本：
下一篇：上下文管理：怎么压缩，怎么拼接。