AGENTS.md

1. 调研缘由

代码代理逐渐进入日常开发后，项目原有的 README 往往不足以承载构建、测试、目录边界和提交约束。AGENTS.md 把这类面向代理的说明放进一个约定文件，官网将其描述为“给 coding agents 的 README”。[S1][S2]

2. 简介与产品工作流

AGENTS.md 是一个开放格式，而不是模型或托管服务。维护者在仓库根目录或子目录写入 AGENTS.md，说明开发环境、测试命令、代码风格和提交要求；支持该约定的代码代理在执行任务前读取相应范围内的文件。[S1][S2]

它解决的不是让代理获得更多权限，而是让团队把原本散落在 README、贡献指南和口头约定里的操作信息放到一个可发现的位置。格式本身是普通 Markdown，仓库可以按目录拆分说明。[S2]

3. 团队与资本背景

AGENTS.md 以公开仓库和网站形式维护，README 将其定位为简单、开放的 coding-agent 指引格式。[S1][S2] 本次未找到需要纳入的公司融资或商业定价资料；它更接近跨工具可读取的仓库约定，而非独立 SaaS 产品。

4. 技术基础与生态位

它位于 protocol-standard 与 dev-tools 的交界：不定义 agent 如何推理或调用工具，而定义项目如何向 agent 提供本地工作上下文。[S2] 由于内容是版本控制中的 Markdown 文件，团队可通过同一套代码审查和分支流程维护指令。[S2]

这和 MCP 的连接协议、A2A 的 agent 间通信不同：AGENTS.md 处理的是单个代码库内的开发约束和任务上下文，并不提供网络传输或身份授权机制。[S3][S4]

5. 市场与外部信号

官网称该格式已被超过 6 万个开源项目使用；这是项目方的采用口径，应视作生态信号而非独立审计数据。[S1] GitHub 仓库公开了最小示例和目录级说明方式，降低了工具实现该约定的门槛。[S2]

目前没有公开统一定价、认证或兼容性测试目录。不同代码代理是否自动发现、如何合并多层文件，仍取决于各工具实现和项目自身说明。

6. 公开评价与主要分歧

正面评价（来源类型）：

• 官方：项目把 AGENTS.md 描述为为 coding agents 提供可预测上下文的开放格式，并给出开发环境和测试说明示例。[S1][S2]
• 开源生态：其价值在于使用普通 Markdown 和仓库内版本控制，便于把代理约束与代码一起审阅；这一点可从 README 的示例结构直接观察到。[S2]

主要批评/质疑（来源类型）：

• 公开独立长期评测有限。该格式不强制规定不同代理的优先级、冲突处理或安全边界，实际效果依赖工具实现和维护者是否保持说明更新。[S2]

存在分歧之处：

分歧主要不在文件是否易写，而在它能否成为跨代理的稳定约定。格式本身保持轻量，但轻量也意味着兼容行为需要各产品分别实现。

7. 同类对比（与头部/高知名度同类项目）

**主要对标项目：**README、CONTRIBUTING.md、MCP。

关键维度对比（事实，标来源）：

维度	AGENTS.md	README / CONTRIBUTING	MCP
主要对象	代码代理的项目说明。[S1][S2]	人类读者和贡献者的项目说明。	AI 应用与外部 tools、resources、prompts 的连接协议。[S3]
载体	仓库内 Markdown 文件。[S2]	仓库内 Markdown 文件。	版本化协议规范与 client/server 实现。[S3]
解决的问题	构建、测试、代码库约束的可发现上下文。[S2]	项目介绍与贡献流程。	外部系统和 agent 的上下文、工具接入。[S3]

公开评价中的对比（标源，非个人裁决）：

AGENTS.md 官方把它类比为“给 agents 的 README”；这表明它更适合补充既有开发文档，而不是替代 README 或网络协议。[S1]

8. 信息缺口与后续观察

1. 需要观察更多代理对嵌套目录、冲突规则和安全限制的实际兼容性。
2. 官网采用数字缺少独立可复现的统计口径。
3. 对大型单体仓库而言，文件颗粒度和维护成本仍需更多公开案例。

9. 归纳洞察 ★

AGENTS.md 反映了代码代理落地的一个朴素需求：模型能力之外，项目还需要把“怎么在这里工作”说清楚。它不增加模型能力，也不提供执行权限；它把上下文治理留在代码库和审查流程里。这个定位使其更像一层轻量协作约定，而不是新的 agent 平台。

10. 来源与更新时间

• 信息截至(as_of): 2026-07-31
• 最后复查(last_checked): 2026-07-31
• 最后更新(last_updated): null