本页解决什么问题
AGENTS.md 不是普通的项目介绍,也不是把 README 复制一遍。它是 Codex 在进入工作区后用来理解当前任务边界、项目约定、常用命令和验收方式的持久指令文件。
本页只讲项目规则文件本身:发现位置、全局/仓库/子目录层级、AGENTS.override.md、内容结构、命令与验收、规则冲突、示例项目、验证加载和反模式。具体 CLI 参数可能随版本变化,先以本机 codex --help、相关子命令帮助和官方文档为准。
先记住四个结论:
- 全局规则影响多个项目,仓库规则随项目共享,子目录规则只约束该目录及后代目录。
- Codex 通常从全局层开始,再从项目根目录逐级走到当前目录,将找到的非空文件按从远到近的顺序合并。
- 越靠近当前工作目录的规则越具体;冲突时通常采用更近的规则,但前面的非冲突规则仍然成立。
AGENTS.override.md只替换同级候选,不会抹掉其他目录已经合并的规则。
01 什么应该写进 AGENTS.md
适合写入
写那些在这个范围内持续成立,而且 Codex 单靠看代码不一定能可靠推断出来的内容:不适合写入
以下内容通常应放在任务提示、Issue、PR 模板或普通文档中:- 只对本次任务成立的文件范围,例如“这次只改一个按钮”;
- 很快变化的版本、临时分支名或个人电脑绝对路径;
- 公司历史、产品愿景和与编码无关的长篇背景;
- 格式化配置或代码已经清楚表达的重复信息;
- 密码、API key、SSH 私钥、Cookie、真实客户数据和内部令牌;
- 一次性发布安排或已经结束的事故上下文;
- “代码必须完美”“体验更好”等无法验收的口号。
AGENTS.md。
02 发现范围:Codex 会查哪些地方
全局层
Codex 会在自己的主目录寻找全局项目说明。默认通常是~/.codex;若设置了 CODEX_HOME,以该环境变量指向的目录为准。
全局层适合放跨仓库都成立的个人默认行为,例如:
AGENTS.override.md 和 AGENTS.md,通常优先选非空的 AGENTS.override.md 作为这一层候选;不要假设两个文件都会同时生效。
项目层
项目层从项目根目录开始,逐级检查到 Codex 当前工作的目录。项目根通常由 Git 工作树根目录确定,实际行为应以当前版本验证。 例如:shop/src/payments 中工作时,可能适用:
shop/src 中工作时,payments 下的规则不适用。当前目录不同,生效规则链也可能不同。
启动前先确认位置:
每个目录如何选文件
常见候选顺序可以理解为:- 空文件不能证明有有效规则;
- 同级非空 override 通常会让普通
AGENTS.md被跳过; TEAM_GUIDE.md、.agents.md等自定义名称不会自动生效,必须配置为备选名称。
03 合并顺序和规则优先级
Codex 通常先收集全局层,再按项目根到当前目录收集项目层,最后按从根到近的顺序拼接:把例外写清楚
不要写:“优先级”不是权限
更近的规则只能表达更具体的工作约定,不能授予工具没有的权限:- 写“可访问生产数据库”不会改变沙箱或账号权限;
- 写“无需审批即可删除”不会让删除变得安全;
- 写“把日志上传到某网址”不能绕过数据外发政策。
04 AGENTS.override.md 的准确含义
替换同级候选
如果仓库根目录有AGENTS.md,临时调试期间可以增加同目录的 AGENTS.override.md。当 override 被当前版本识别且非空时,同目录普通 AGENTS.md 通常不再作为这一层候选;原文件仍保留,移除 override 后可恢复。
它适合:
- 临时使用测试替身,避免连接外部服务;
- 迁移期间使用不同验证命令;
- 受控实验分支中的更严格只读限制;
- 子目录由不同团队维护且有独立流程。
不会覆盖整条链
假设:repo/backend 中,最后一个文件只替换 repo/backend 这一层。全局和仓库根规则仍在合并链中。若需要局部例外,应明确写出例外,不要假设 override 会清空上层上下文。
示例:
- 这是稳定的局部规则,还是只对本次实验有效?
- 谁负责移除或更新它?
- 团队成员和 CI 是否也会看到它?
AGENTS.md,临时文件完成后删除。
05 三个层级分别写什么
全局:个人默认
放跨项目的工作习惯、安全原则和报告格式,不放项目专属命令、个人路径或团队政策。仓库根:团队约定
根目录AGENTS.md 随代码提交,是团队共享的主要来源。建议写:
- 仓库运行方式和主要入口;
- 主要服务和目录职责;
- 安装、开发、测试、lint、类型检查和构建命令;
- 兼容性、依赖和生成文件约束;
- 提交或 PR 前的检查;
- 不能执行的生产、破坏性或敏感操作。
子目录:组件差异
子目录规则适合写服务专属命令、语言和包管理器、生成代码或迁移策略、组件级验收和边界:06 内容结构:让规则容易执行
推荐结构:标题表达决策
## 常用命令、## 不要修改、## 验收标准 比 ## 其他、## 注意事项 更容易检索。一个标题下尽量只放同一类规则,避免把安全限制埋在背景介绍中。
每条规则使用可执行动词
不要写:说明条件和替代方案
控制长度
多层规则会一起进入上下文,常见默认上限是project_doc_max_bytes 的 32 KiB,具体值以当前配置和版本为准。超出时优先:
- 删除 README 已说明或代码可推断的信息;
- 删除重复的上层规则;
- 把组件内容移到对应子目录;
- 将设计背景移到普通文档;
- 确实需要时再调整
project_doc_max_bytes。
07 命令与验收怎么写
命令来自项目事实
写命令前检查package.json、pyproject.toml、Makefile、锁文件、CI 和贡献指南:
区分验证层级
规定失败后的行为
.env、读取生产日志和网络外发。
把完成写成可观察结果
验收要回答:行为是什么、怎样检查、什么结果算通过:08 示例项目:观察规则链
下面的示例不使用真实凭据或外部服务。创建项目和根规则
AGENTS.md 写:
增加子目录规则
在services/payments/AGENTS.md 写:
services/payments 启动 Codex,根目录“不新增依赖”等未冲突规则仍然适用。
增加同级 override
再创建services/payments/AGENTS.override.md:
- 根目录
AGENTS.md仍属于上层来源; - override 替换同级
AGENTS.md; - 当前目录命令变为
printf 'override-check\\n'; - “不访问外部服务”等未冲突约束仍有效;
- 只读请求不会产生文件变更。
09 验证规则是否被加载
只读复述
先不给修改权限,要求:使用无歧义标记
在临时项目规则中加入:观察低风险行动
配置变化后重启
若修改~/.codex/config.toml:
排查顺序
- 确认启动目录和 Git 根目录;
- 确认文件名、路径和内容非空;
- 搜索全局到当前目录的候选;
- 检查
CODEX_HOME; - 检查同级
AGENTS.override.md; - 检查
project_doc_fallback_filenames并重启; - 检查是否接近
project_doc_max_bytes; - 让 Codex 只读复述来源和冲突;
- 用低风险命令观察验证路径;
- 再判断是规则含糊、冲突还是代理未遵守。
10 规则冲突:怎样判断谁赢
区分冲突和互补
以下是互补规则:处理表
如果根目录禁止修改迁移历史,子目录却允许直接修改,不要自行执行高风险动作。报告冲突文件、适用范围、更具体的规则、风险和需要确认的人。
11 常见反模式
把规则写成项目百科
公司历史、完整目录树和大段背景会稀释命令和禁区。保留范围、入口、命令、约束和验收,详细内容放普通文档。把一次性要求写成长期规则
“这次只改src/foo.ts”不应永久限制后续任务。一次性范围留在提示中。
规则过时
包管理器或测试命令改变后仍保留旧规则,会持续误导代理。把规则当代码维护,在工具链变更的同一提交中更新它。重复上层内容
子目录复制整份根规则会造成多处漂移。根目录写共同部分,子目录只写差异。只有禁止,没有替代
验收写成口号
“确保功能正常”没有路径、命令和通过条件。写预期状态、边界输入、检查命令和失败报告方式。把秘密放入规则
不要为了方便把真实令牌、内部地址或生产连接串写进仓库。使用环境变量和占位符,缺少凭据时停止并报告。把 override 当永久配置
临时 override 长期留在仓库会让团队误解生效规则。写移除条件,稳定规则回填普通文件。把规则当权限控制
规则不能解除沙箱、审批或组织政策。将高风险操作写成需要确认,真正的权限由工具和平台控制。只验证文件存在
看到AGENTS.md 不等于它已生效。必须结合当前目录、同级 override、配置、内容上限和低风险行动验证。
12 可直接改造的模板
13 修改规则文件的工作流
修改前
修改中
修改后
14 最终检查清单
发现范围
- 已确认当前工作目录和项目根目录。
- 已检查
~/.codex或CODEX_HOME。 - 已从项目根逐级检查到当前目录。
- 已检查同级
AGENTS.override.md。 - 已确认备选文件名配置、空文件和内容上限。
内容质量
- 项目范围和目录边界清楚。
- 命令来自真实脚本或 CI。
- 规则使用可执行动词和条件。
- 验收包含可观察结果。
- 没有一次性需求、重复 README 或秘密。
冲突与验证
- 已区分全局、仓库和子目录规则。
- 已确认 override 的替换范围和移除责任。
- 已让 Codex 只读总结规则来源。
- 已观察一次低风险验证路径。
- 已检查
git diff --check、变更文件和工作区状态。 - 已记录未执行的检查和未验证风险。
- 未经明确要求,没有提交、推送或发布。
小结
AGENTS.md 的价值不在于写得长,而在于让 Codex 在正确目录、正确层级中获得正确约束:
AGENTS.override.md 只用于明确的同级替换。持久规则进文件,一次性要求留在提示中;冲突先定位来源,高风险动作先确认;命令必须有真实依据,完成必须有验证证据。
参考资料:参考/codex/11-agents-md.md、参考/codex/13-prompting.md、参考/codex/36-best-practices.md。动态行为以本机 Codex 版本的帮助、配置和官方文档为准。