GitHub 上有个 issue，编号 6235，在 anthropics/claude-code 仓库。2025 年 8 月 21 号提交的。请求让 Claude Code 支持 AGENTS.md。状态是 Closed。
就这么关上了。
我第一眼看到这条 issue 时，没打算写它。一个功能请求，开源项目每天那么多，开开关关太正常了。隔几天再想，它吵的其实不是一个文件格式，是编码 agent 读项目上下文这件事，那份说明该算项目的一部分，还是某个工具的私有配置。请求者把话挑明了：Codex、Amp、Cursor 这些产品在往 AGENTS.md 上靠，一个统一的 Markdown 文件，让 agent 都能读；而 CLAUDE.md 太贴着 Claude Code，跟不用 Claude Code 的人协作时很别扭。
这已经不是“多支持一个文件格式”。这是说，CLAUDE.md 这堵墙在单工具里是承重墙，多工具协作的现实里，它把不用 Claude Code 的人挡在外面。
我的态度先说死：我不会把关键项目知识写进一个只有某个工具能读的私有文件里，然后让团队里其他人各自维护一份副本。我不用 Claude Code 碰过的项目，同事的 Cursor 也得能读项目上下文。这个判断一年前可能是少数派，现在正变成工程上的默认常识。这正是这个 issue 被关掉之后最反讽的地方——GitHub 上可以关掉一个功能请求，但关不掉正在形成的气候。
我不打算把 CLAUDE.md 从头解释一遍，懂的人自然懂。要说的是它的承重墙在哪，以及这堵墙承重的同时挡掉了什么。CLAUDE.md 的设计初衷不复杂：Claude Code 启动时读项目根目录下的这份文件，里面写项目怎么组织的、代码规范、还有常用命令，它用这些信息快速建立对项目的理解。这是给 agent 的“项目说明书”。你一个人、一个工具、一个项目的时候，它非常趁手，格式和内容都可以贴着 Claude Code 的行为来写，越精准越好用。但它的底子有个假设：项目上下文是给 Claude Code 这一个工具读的。这个假设一旦不成立——团队里三个人用三种 agent——它就变成一堵墙。
问题不在 CLAUDE.md 写得好不好。在“把它当成唯一项目上下文来源”这个动作本身。你写进去的结构、规范、常用命令，本该是项目的公共知识；一进 CLAUDE.md，它们就成了 Claude Code 的私有配置。Git 仓库是公共空间，代码、文档、编码规范都是公共的。那 agent 用来理解这些公共信息的那份说明，凭什么要变成某个工具的私有物？
想通这点，AGENTS.md 的承重墙就露出来了。格式上它跟 CLAUDE.md 没差多少，都是 Markdown，都是给 agent 看。差别在归属：AGENTS.md 不属于任何工具，它属于项目。一份放在根目录，Codex、Amp、Cursor 都能读，Claude Code 读不读全看它自己的读取列表。这个“归属感”才是核心。你如果只看文件内容，不看谁在维护它，很容易觉得这俩就是一回事。但写到项目里、被人一读，差别立刻出来。
这张表一摆，issue 的核心结构就出来了，不需要更多解释：
| 维度 | CLAUDE.md | AGENTS.md |
|---|---|---|
| 服务对象 | Claude Code | 多个编码 agent（Codex、Amp、Cursor 等） |
| 归属感 | 工具私有 | 项目公共 |
| 协作边界 | 偏向 Claude Code 使用者 | 所有开发者一致 |
| 项目知识迁移成本 | 锁在 Claude Code 生态里 | 跟随项目 Git 仓库本身 |
| 私有扩展的余地 | 完全可以继续存在 | 可以有，但不应是基线 |
这张表不是要论证 CLAUDE.md 该死。它是在说：把工具的私有格式当项目上下文的标准载体，协作成本是真的；有跨工具野心的项目会天然往 AGENTS.md 靠。这不是两个文件格式的竞争，是私有和公共之间的一次重新配置。
写到这儿我得补一刀。请求者说 CLAUDE.md 过度偏向 Claude Code，这句我接一半。CLAUDE.md 的偏向对 Claude Code 用户来说是特性，不是毛病。它知道 Claude Code 具体怎么调工具、有哪些限制，所以能写得比通用文件准。你要让一份通用文件在别家 agent 那边也这么准，它只会堆一堆条件分支：“这段给 XX 工具”“那段给 YY”。最后要么信息密度掉下来，要么每个人维护一版文件。这个代价是真的，不是支持了 AGENTS.md 就天下太平。
但这不能成为不动的理由。两层本来可以分开：项目级的关键上下文放 AGENTS.md，工具级的偏好留 CLAUDE.md。两者不互斥，也不是谁杀谁。问题是 Claude Code 连这个选项都不给。
然后就是它被关掉这件事。状态是 Closed，没写理由，至少我没看到正式说明。技术上不该难，多读一个 Markdown 文件能有多难？难的是格式背后谁说了算。Claude Code 要是把 AGENTS.md 加进读取列表，等于承认基线不是 CLAUDE.md，而是 AGENTS.md；等于把“项目知识怎么给 agent 读”的公共定义让出去。对一个在编码 agent 市场有话语权的工具来说，这不是加功能，是认不认公共标准。所以我不信它会轻易过。
我说这是猜的。关闭理由没人写，我也没有内部消息。但判断不靠内部消息成立。GitHub 的 issue 关闭机制本来就不透明，只丢给你一个状态。这个状态本身已经说明了一部分：在 AGENTS.md 这件事上，Anthropic 选择继续把 CLAUDE.md 当默认入口。
往深一层说，编码 agent 理解代码库这件事，正在从各家自己搞一套，走向一套共享的基础约定。原因不玄，就是协作。软件开发在 Git 仓库里发生，Git 仓库不属于任何单一工具。谁家的上下文文件想跨工具生效，都得回到这个公共空间。这是趋势，一个 issue 加速不了，也拦不住。
回到地面。这事给一线开发者其实就一条：选 agent 时，把上下文文件格式算进去。一个人、一个封闭项目、只用 Claude Code，CLAUDE.md 够好，更准，没问题。团队里成员可能用不同 agent，或者你预估到将来会换工具，那就把关键项目上下文写进 AGENTS.md，跟项目走，不跟某个人的工具走。这决策不高深，就是个小工程选择：你把项目说明写进哪个文件，直接决定它以后能不能迁移、读取、共享。
这个选择比很多人以为的贵。写一次没什么。但项目知识在私有格式里沉淀久了，迁移不是改个后缀名，是把知识本身重新抽象一遍。到那时候你才发现，当初把上下文写进哪个文件，根本不是小事。
我还是得说一句：这个 issue 原文非常短，几分钟就能读完。我这份拆解是二手货，带着我的偏见和裁剪。关心这个标准之争，去读那个 issue，看请求者怎么说的，看下面完整讨论。别让摘要替你下结论。
issue 关了，核心问题没关。AGENTS.md 这套公共格式还在往前走，一个 Closed 按钮挡不住，顶多在它自家生态里挡一会儿。这堵墙我替你拆了，路得你自己走。