Anthropic接受OpenAI标准，智能体从此共用一份AGENTS.md

要 Open 起来了？

刚刚， Code 成员 （@）发帖称， Code 开始支持 .md 文件了。

从 2.1.277 版本开始，如果项目目录中没有 .md， Code 会检查并使用 .md。用户可以通过 / 切换这项行为。

这项能力建立在 Code 的 mods 机制上。 已将 -md 做成内置 mod，并公开了相关源码。

相关源码链接：

表示，未来开发者也可以围绕项目指令构建自定义版本。

.md 就像是项目写给 AI Agent 看的说明书，里面的内容旨在告诉 Agent 项目的结构、怎么安装依赖、运行哪些测试、代码规范是什么等等。官方 .md 网站也明确把它称为「 for 」。 Code 的这次改动第一次让这个热门的 加入了跨厂商的项目指令标准之中。

消息一出，网友喜大普奔，评论区迅速被「终于统一了」、「」刷屏。

甚至连 Codex 负责人 Tibo 也跑来祝贺：「太好了！这就对了。欢迎来到光明的一边。」

要知道，.md 最初就是源自 的 Codex。表面上水火不容的 和 ，在竞争激烈的 Agent 赛道上现在倒是走到了一块。

Code 开始兼容 .md

在默认模式下， Code 会沿项目目录树查找 .md，只要项目路径上没有项目级 .md，找到的文件就会作为项目指令加载。

当 Agent 读取项目子目录中的文件时，mod 还会按目录层级补充对应的 .md。如果同级目录存在 .md，则遵循原有的 .md 规则。

相关设置位于 / 的 中。用户可以选择仅使用 .md，在没有 .md 时回退到 .md，也可以同时加载两类文件。具体采用哪种方式，可以根据项目的协作模式进行调整。

这意味着， Code 不必再完全依赖自身的文件命名约定，对于已经使用 .md 管理项目规则的团队，接入成本明显降低。

曾把兼容问题摆上台面

前段时间，机器之心就报道过， CEO Tobi Lütke 曾考虑在公司内部禁用 Code，直到它支持读取 .md、./ 等文件。

当团队成员同时使用 Codex、 和 Code 时，同一个仓库可能出现不同的配置入口。使用 Codex 的开发者读取 .md，使用 Code 的开发者读取 .md。如果两份文件存在差异，不同 Agent 获得的项目规则也会不同。

这些文件通常记录项目结构、编码规范、测试要求、开发流程，以及 Agent 可以调用的技能。它们已经成为 AI Agent 理解代码库的重要上下文。

开发者此前给出的解决办法包括建立软链接，或者在 .md 中写入 @.md。小型项目比较容易采用这些方案，到了大型 ，配置文件会沿目录树递归生效，维护成本也会迅速上升。

Lütke 认为，团队不应该长期承担这类同步工作。他把这种额外负担称为「复杂性税」。

为何坚持 .md ？

此前也有自己的产品考虑。

曾解释，不同模型家族具有不同的行为特点， 会显著影响模型表现。 模型对 、 和 .md 的组织方式有特定偏好， Code 也会针对不同模型调整 。

这套思路与 关于 的讨论相呼应。项目说明、技能文件和 ，共同构成 Agent 完成任务所需的上下文。

这种模型专属设计有助于优化 Code 体验，也会增加跨工具协作的维护成本。

支持 .md 只是第一步

这次更新首先解决了文件读取入口的问题，对于已经使用 .md 的团队， Code 不再需要额外的软链接或引用配置。

不过，兼容并不等于完全统一。在默认模式下，只有项目路径上没有 .md 时， Code 才会回退读取 .md。如果团队希望同时加载两类文件，还需要在 / 中调整设置。

此外，./ 和 ./ 仍是两套独立目录。团队依然需要决定哪些规则属于跨工具的共同内容，哪些内容只服务于 Code。

随着 AI Agent 进入日常开发流程，项目指令文件正在从工具偏好变成代码库基础设施。 Code 此次加入 .md，说明跨工具共享项目上下文已经成为开发团队的现实需求。

此前 Code 是这个标准最大的缺席者之一， Code 加入以后，主流 AI 工具围绕「Agent 」收敛的趋势就明显得多了。未来可以预见的是，不同 之间的迁移成本将会越来越低。

那么问题来了，现在哪家 更好用呢？