过去团队管理开发规范主要依靠代码审查、文档和人的经验。进入Agent开发阶段后规则直接影响执行Agent能否安装依赖、访问网络、修改目录、继续重试和完成验证都会决定自动化是安全交付还是快速扩散错误。很多团队仍然把这些要求全部写进提示词不要修改生产配置不要新增依赖修改后记得测试高风险操作先询问我。这种写法在一次对话中有效但当Codex开始跨桌面端、CLI、IDE、自动化任务和多个Agent持续运行时临时提示词会失去一致性。真正的问题是团队规则是否已经从自然语言要求变成能够被复用、继承、检查和强制执行的系统政策这就是Policy as Code。一、为什么只靠提示词管理规则一定会漂移提示词最适合表达“这一次要完成什么”。例如修复订单重复提交问题只修改后端服务不调整前端。它描述了当前目标和临时边界。但长期规则通常包括每次修改后必须运行哪些测试哪些目录禁止修改哪些依赖不能引入哪些命令必须审批交付时必须提供哪些证据。如果每次都依赖开发者重新粘贴规则迟早会出现差异。一个人写“不要修改数据库”另一个人写“尽量不要改数据库”一个Agent理解为完全禁止另一个Agent认为必要时可以修改。Codex支持通过AGENTS.md在任务开始前加载持久化项目指导并按照全局、项目和更靠近当前目录的规则逐层组合目录中的AGENTS.override.md还可以覆盖同级基础指导。稳定规则不应该一直停留在临时提示词中而应该进入可版本管理的配置层。二、Policy as Code到底是什么Policy as Code不是把所有制度复制成一个巨大配置文件。它的核心是把原本依赖口头提醒和人工记忆的约束转化为结构化、可复用、可审查的政策。一条完整政策通常包含四部分适用范围→ 允许或禁止的行为→ 必须提供的证据→ 违反规则后的处理方式例如适用范围支付服务。行为限制禁止修改支付状态枚举禁止访问生产密钥。验证要求必须运行支付单元测试与集成测试。失败处理连续两次失败后停止不得绕过测试。这不再是一句提醒而是一条可检查、可执行、可验证的政策。三、提示词、AGENTS.md、Skills和配置怎样分工很多团队的问题不是没有规则而是把规则放错了位置。提示词描述本次任务提示词负责当前目标、上下文、临时约束和完成条件。它应该回答这次要解决什么哪些内容不在范围内当前任务成功的标准是什么遇到什么情况应该暂停。AGENTS.md保存仓库长期约定AGENTS.md适合记录仓库布局、构建命令、测试要求、代码规范、审查规则和目录特有禁令。Codex会在开始工作前读取适用范围内的指导并允许项目根目录与子目录形成分层规则。例如项目根目录规定公共接口变化必须说明兼容策略。支付目录再增加不允许修改支付状态枚举必须运行支付集成测试。Skills保存可重复执行的流程Skill可以打包说明、资源、模板和可选脚本让ChatGPT或Codex按相同流程完成重复任务。例如发布前检查Skill安全审查Skill数据库迁移SkillPull Request交付Skill。AGENTS.md告诉Agent“必须做什么”Skill进一步告诉它“应该按什么步骤做”。配置与托管配置统一运行默认值Codex支持用户级~/.codex/config.toml也支持项目或子目录中的.codex/config.toml企业还可以通过托管配置下发工作区要求。这一层适合统一模型、审批、沙箱、网络和工具连接避免桌面端、CLI和IDE之间的配置漂移。四、为什么软规则之外还需要硬边界文字规则只能告诉Agent“不应该做什么”权限系统决定它“实际上能不能做”。Codex的权限机制把沙箱限制和审批策略分开沙箱控制文件系统、网络和本地动作的边界审批决定哪些动作执行前必须暂停确认。Rules还可以控制哪些命令允许在沙箱外运行但官方目前将Rules标记为实验能力。因此权限应该按风险分级阅读代码默认允许修改项目文件限制在工作区安装依赖按任务审批访问网络按域名或场景开放创建Pull Request允许但保留审查部署、迁移数据库、删除数据必须人工批准生产密钥默认不可访问。成熟政策不是要求Agent“自觉”而是让高风险动作无法静默发生。五、一个规则漂移的真实场景假设团队让多个Agent处理支付模块。最初的提示词写着不要修改支付状态修改后运行测试。Agent A严格执行只改了幂等逻辑。第二天Agent B收到的提示词变成尽量不要调整支付状态。它发现修改状态枚举可以快速解决测试于是增加了一个新状态。第三个Agent负责前端却没有拿到任何支付规则只根据后端Diff更新页面。最终结果可能是后端新增状态旧客户端无法识别数据分析仍按旧枚举统计部分测试通过生产回滚脚本不支持新状态。每个Agent都完成了自己的局部任务但团队政策已经在交接中丢失。如果把规则分层根目录AGENTS.md要求公共契约变化必须说明兼容策略支付目录AGENTS.override.md禁止修改状态枚举支付验证Skill要求运行单元测试、集成测试和旧客户端兼容检查沙箱禁止读取生产密钥合并流程要求人工批准契约变化那么Agent即使更换、会话中断或从CLI切换到桌面端核心政策仍然存在。六、为什么AGENTS.md不能写成公司制度大全把规则持久化不等于把所有文档都塞进AGENTS.md。官方建议保持AGENTS.md精简只放每次任务都真正需要的仓库指导并把规则放在最接近其适用代码的位置。过长文件会让重要规则被背景说明淹没也容易产生冲突和无关上下文噪声。更合理的方式是AGENTS.md保存稳定约束Skill保存完整流程参考文档保存背景知识提示词描述本次目标。例如“禁止直接修改生产配置”应该放在AGENTS.md或权限层“如何完成一次标准发布”更适合做成Skill。七、为什么Skills比复制模板更可靠很多团队已经有检查清单但每次仍然依靠人工复制。复制模板容易出现版本失效、步骤缺失和结果格式不统一。Skill可以把说明、模板、示例和脚本放进同一个可复用单元。Codex可以根据Skill名称和描述判断何时使用也可以由用户显式指定。例如“数据库迁移审查Skill”可以检查表结构、旧数据、回滚脚本和风险报告并在需要生产访问时停止请求审批。Skill保存的是团队操作经验而不只是一次提示词技巧。八、为什么团队最终需要托管配置个人开发者可以自己维护配置但团队扩大后完全访问、审批、网络和工具连接很容易出现差异。企业托管配置的价值是让管理员定义工作区级要求再将其应用到Codex使用环境中。官方的Managed configuration和企业设置文档就是为统一安全与运行要求提供管理入口。这时Policy as Code升级成组织治理仓库决定怎样开发团队决定怎样协作组织决定哪些能力绝对不能越界。九、如何建立一套可执行的Agent政策矩阵团队可以从四个维度整理政策。对象政策作用于哪个仓库、目录、Agent、工具或环境动作允许读取、修改、执行命令、访问网络、安装依赖还是创建交付物条件什么情况下可以自动执行什么情况下需要审批证据完成后必须提供哪些测试、Diff、日志和风险说明例如对象支付服务。动作允许修改业务代码禁止修改生产配置。条件新增依赖必须审批接口契约变化必须人工确认。证据支付单元测试、集成测试、兼容性说明和回滚方案。这种矩阵可以进一步映射到AGENTS.md、Skill、config.toml、沙箱规则和CI门禁。十、推荐的落地顺序Policy as Code不需要一次完成。第一步收集重复纠错整理最近一个月中开发者反复提醒Agent的问题。第二步写入AGENTS.md把每次任务都适用的稳定规则写入仓库并按目录拆分。第三步把复杂流程做成Skill将发布、迁移、审查和复盘等多步骤工作保存为可复用Skill。第四步统一配置默认值设置模型、审批、工具和沙箱默认值减少不同入口之间的行为差异。第五步把高风险要求变成硬限制利用权限、沙箱、Rules和CI门禁控制不可逆动作。第六步持续检查政策效果观察Agent最常违反哪些规则、哪些政策从未触发、哪些要求互相冲突再逐步调整。Policy as Code应根据真实失败持续演化。结语ChatGPT、Codex、Pro和Plus让个人和团队更容易启动多个Agent、并行处理任务并自动执行开发流程。但Agent规模扩大以后真正危险的不是模型不会写代码而是不同Agent遵循不同规则、不同入口使用不同权限、不同任务产生不同交付标准。可靠的Agent治理应该形成五层结构提示词定义本次目标AGENTS.md保存仓库约定Skills固化重复流程配置统一运行默认值权限和沙箱建立硬边界。规则只写在提示词里它是一种提醒。规则被版本管理、分层继承、自动验证并由权限强制执行之后它才真正成为政策。AI时代的软件团队不只是要让Agent更聪明还要让Agent在明确、稳定、可审计的边界内工作。