#Agent安全流程

avatar
OpenAI 最近把 agents(.)md 官方站点推上线了，Codex 也同步发布了支持机制。 趁这个节点，我想系统性聊一聊御三家的这三种 agent 配置文件的异同：agents(.)md、CLAUDE(.)md 和 GEMINI(.)md。也顺便聊下推荐的做法。 ✅在正式聊之前，先交代下历史背景： 1. agents(.)md 最早在 2025 年 5 月由 AMP 团队最先提出的，当时很多 Agent 工具（Codex、Cursor、Claude、Gemini）各搞各的 .cursorrules、.agentrc、CLAUDE(.)md，完全没有统一格式。AMP 的目的是统一各家 Agent 工具。 2. OpenAI 很快买下了 agents(.)md 域名，并推动把名字定格为 AGENTS(.)md。并推动了一波工具链的集体接入，其中就包括包括 Codex、Amp、Gemini CLI、Factory 等，OpenAI 也在 7 月 16 日明确明确提出要将其作为跨厂商的中立标准来推进。至此，它才算真正成了跨厂商约定。 3. CLAUDE(.)md 和 GEMINI(.)md 则是各自厂商更早在自家工具链里落地的文件格式：Claude Code 从一开始就鼓励用户在仓库里放 CLAUDE(.)md；Gemini CLI 在发布时就支持 GEMINI(.)md 并内建了分层加载和合并机制。 介绍完背景，就能很清晰的看清楚这三者的关系：先是各自厂商的私有实践， agents(.)md 再跑出来收拢一下搞成统一格式，很典型的各玩各的，然后在从中抽取标准，这在行业里几乎是共识。毕竟标准这个名分和工具的落地执行，从来就不是同步发生的。 ✅首先说说它们各自是什么角色？ 1. agents(.)md 更像是一个给“会自己读代码、做测试，还能提交 PR” 的 agent 写的一个操作指令书，Codex 是第一个官方把“必须跑里面定义的 test、lint、type-check”等校验流程写进系统级规范的。 2. CLAUDE(.)md 是 Claude Code 在启动的时候就会被自动优先加载的上下文提示文档，官方主张把风格约定、测试流程、命令行使用方式写进去，但强调的是自定义行为提示。 3. GEMINI(.)md 更偏向是指令记忆和行为偏好的组合体，Gemini CLI 支持 memory discovery，会自动从多个路径加载并合并这个文件，形成最终的运行配置。 简单概括下， agents(.)md 处理的是我该怎么做，CLAUDE(.)md / GEMINI(.)md 是告诉 agent 你在这里应该怎么表现。一个偏指导性原则，另两个更偏记忆与个性化。 ✅优先级与加载机制：谁先读，谁覆盖谁，差别有点大 1. Codex 支持在任意目录放置 agents(.)md，文件可出现在仓库/家目录等地方，作用域=所在目录为根的子树，优先级按就近原则来定，目录越深、越靠近改动文件的 agents(.)md 越优先生效，天然适配 monorepo 这种软件开发策略。 2. Claude 支持 repo 根、父级、子目录、甚至 ~/.claude 这样的全局 fallback，还能用 /init 命令一键生成。 3. Gemini 的层级加载机制更极致，支持从当前目录 → 项目根目录 → Home 逐层向上加载，同时还能扫子目录合并配置，用 /memory show 能一键查看当前上下文组合结果。 所以你看，这是标准 vs 体验的典型体现：Codex 更偏向于推统一行为约定；Claude 和 Gemini 提供最大记忆灵活性。 ✅执行语义和安全模型：强调应该怎么被跑 1. Codex 的执行是在云端容器中进行，默认禁网，而且系统强制运行 agents(.)md 里的检查指令（test、lint、type-check），强调可验证性。这本质上是在构建可验证性的基础设施。 2. Claude 的执行是 本地 CLI，权限默认是逐条确认的，支持 allowlist 和自定义工具，如果你愿意，也可以开启一个叫 dangerously-skip-permissions 的 YOLO 模式（但官方明确建议只在沙箱里玩）。 3. Gemini 则是 IDE + CLI 双模态，所有变更型操作都走计划预览 → 用户确认 → 权限校验这三板斧，外加支持 MCP 扩展模块，整个执行链非常强调人在环中。 这里区分其实挺明显的，谁给它的执行权、执行边界是谁画的，一目了然。你给 agent 的自由度和防御面，其实就在这些配置里写死了。 ✅文件内容也是存在边界的：不是所有事情都能写，也不是写了就该执行 1. agents(.)md 的定位是团队级别的可执行约束，包括但不限于：构建命令、测试流程、代码风格、PR 校验规范、必须通过的检查点，甚至鼓励把可回归的 checks 前置给机器。 2. CLAUDE(.)md / GEMINI(.)md 更像是这两家厂商的定制版说明书，除了命令与规范，还可写如何与该工具协作。比如可以写行为提示、允许的外部工具、如何处理计划执行、调试偏好等。 3. 反方提醒：很多人误以为可以在这些文件里写项目设计、架构理念、缘由解释，其实这些内容根本不是 agent care 的，它更关心的是我该跑什么、能不能跑、出了错怎么办这些问题。 大概就是 README 是讲给人听的故事，而这些 .md 是 agent 听的命令。边界感不能模糊，尽量不要越界。 ✅标准推进与生态收拢的趋势正在从多头乱战，到逐步统一 1. Codex 把 AGENTS(.)md 定义为供应商无关入口（很重要！！！），不仅指定了加载优先级，还规定了必须执行哪些校验命令。层级、优先级、必须跑检查这些都写成了类似规范的系统条款，社区也在推进更通用的 Agent Rules 讨论以减少碎片化。这算算是第一次把agent 工作规范写成了类标准（终于这三家都有了自己的规范：其他两个是 mcp 和 A2A）。 2. Claude / Gemini 则在各自的开发体验上持续打磨，Claude 有精细的工具授权、commands 注册、权限跳过开关；Gemini 搭配 CLI 和 /memory 指令调试，支持可视化 plan、记忆合并与调试。 整个生态看下来，就会更清楚看到：Codex 想做标准统一 Coding 秩序；Claude / Gemini 在做交互体验；而 agents(.)md 则是中间规范一切的接口格式。 ✅工程落地的关键分水岭（我觉得最实用） 1. Codex 把 agents(.)md 作为前置校验，强调的是执行闭环，强制在流程中按 agents(.)md 跑完验证再交付，天然适合 TDD/CI 闭环；你不跑完 test、lint、type-check，你就别想交付。Claude 和 Gemini 更强调人机共创，agent 给你一个 plan 或 diff，你确认了才执行，权限是逐步放开的。 2. Gemini 的 /memory show 的透明度让人很放心，一个命令能看到我到底加载了哪些规则的；Claude 的 /permissions、allowedTools 调优细到工具级。 3. Codex 以在云端封箱操作以及禁网来控制风险；Claude 提供可跳过权限；Gemini 更强调计划审阅和权限。 所以如果要 agent 真正变成流水线的一部分，就得用 agents(.)md 去定义 agent 的合格行为；而如果更重交互体验，那就补上 CLAUDE(.)md / GEMINI(.)md 去调优记忆。 ✅安全视角的升级：从 prompt 注入到流程注入，agent 让流程本身变成被攻击的对象 现在 agent 能读文件、能跑命令，当 agent 会按文件指令自动跑流程，风险就不再只是 prompt，而是升级成流程被置换的风险。 我的安全护栏建议是： 1. 白名单只允许跑幂等校验：lint / test / type-check / build 这类幂等校验； 2. 禁止执行部署、数据库迁移、curl 外部服务等危险命令； 3. 所有 agents(.)md 等所有的 .md文件，一律走 Code Review，把它们也当做代码，不准默默合； 4. PR 模板/CI 必须要强制执行， 要把 agents(.)md 的 checks 拉齐，保证 checks 全绿； 5. 生产环境一律跑在 sandbox + 最小权限 token 下； 这些做法与官方文档的权限设计思路一致，但要你在团队流程里真正设置权限。agent 既然能做决策，就必须设边界，你不给它围栏，它替你决策的时候可能就直接出圈了，回一下我前段时间说的那个老哥，AI 直接把数据库都给他删了，还伪造了一批数据。 ✅我的推荐做法 核心原则：要把标准落到底，避免厂商锁定，同时把个性化控在工具层，拉满生产力。 1. 真相只有一个，在仓库根 & 各子包放 AGENTS(.)md，写清楚执行闭环、风格、PR 规则、禁行清单这些规则。Codex 能照单执行，其他工具也能读懂。 2. CLAUDE(.)md / GEMINI(.)md 做 agent 特殊的的微调：记忆层级、工具授权、命令行为偏好。具体如 ：CLAUDE(.)md 只写Claude特性相关的增量，比如如允许列表、常用命令、MCP 用法，并引用或遵守 AGENTS(.)md 的校验项。GEMINI(.)md 按层级合并思路组织全局、项目和组件这三档内容；把如何查看和刷新记忆、计划审批偏好这类都写清楚。 3. 再来几个强制的措施：CI 里把 lint、type-check、test、build 都作为必须要走的流程；对任何 agent 产出的 PR 要求都先在本地/容器跑过 agents(.)md 的 checks 再合并代码，CI 和人协作一起把守住底线。 ✅附带一个适配不同团队成熟度的方案： 1. 快速版：根目录一份精简 AGENTS(.)md + 允许列表最小化，先打通流程，能跑起来和验证再说。 进阶版：各 package 就近 agents(.)md；2. CLAUDE(.)md/GEMINI(.)md 只做工具差异的薄封装；在沙箱里给 Claude 开 YOLO 流程跑批量格式化和修改风格。 御三家各自的方案，agents(.)md 明显是来同一江湖的，在前期能力不足的情况下，可以把 当成跨工具的执行合约来用，CLAUDE(.)md / GEMINI(.)md 做自己各自的 agent 的记忆与操作。 你要 agent 真正进入团队，那就得让它先看得懂规则，按规矩做得出结果才行。从管理的角度来讲，这样整个 AI 团队协作才能比较稳定的产出。
#OpenAI agents #AGENTS(.)md标准 #Codex执行闭环 #CLAUDE(.)md/GEMINI(.)md个性化 #Agent安全流程