AGENTS.md 完整指南：一份文件，三步上手，让 AI 编程代理看懂你的项目

AGENTS.md 完整指南：一份文件，三步上手，让 AI 编程代理看懂你的项目

【免费下载链接】agents.mdAGENTS.md — a simple, open format for guiding coding agents项目地址: https://gitcode.com/GitHub_Trending/ag/agents.md

先讲个真实的小尴尬。上周我让编程代理在我仓库里做了一次重构，它干完活顺手跑了一条生产构建命令——热更新直接报废，开发服务器卡在一个谁也说不清的状态里，我花了二十分钟才收拾回来。问题不在代理"笨"，而在于它不知道这个项目里哪些命令不能碰，而我从来没告诉过它。

后来我了解到，越来越多项目靠一个不起眼的文件解决这个问题：AGENTS.md。它是一个专门给 AI 编程代理看的 Markdown 说明文件，核心功能就是用统一、开放的格式，把构建命令、测试流程、代码规范这些"项目内部知识"讲给代理听。目前已有超过 6 万个开源项目在使用它，Codex、Gemini CLI、Jules、GitHub Copilot、Cursor、VS Code 等主流工具都能原生识别。

AGENTS.md 到底是什么？一份给代理的"作业说明"

把 README.md 想象成给人看的项目介绍：快速上手、功能亮点、贡献指南。而 AGENTS.md 是另一份东西——给代理的固定入口。它的位置可预测（就在仓库根目录），内容也聚焦于代理干活真正需要的部分：装依赖用什么命令、测试怎么跑、风格上有哪些讲究。

几个让人放心的基本事实：

• 它就是标准 Markdown，没有任何必填字段，标题和结构随你定义，代理只是解析你写下的文字；
• 一个文件写好后，所有支持该格式的工具共用，不用为每个代理各写一份配置；
• 它和 README 互补而非替代，两边各管各的读者。

为什么 README.md 扛不下这个活？

你当然可以把测试命令塞进 README 的角落，但很快会发现问题：

1. README 会被写胖。人类读者只关心"这项目是干嘛的"，代理关心的目录结构、CI 位置、容易踩的坑全混在一起，两边都难看；
2. 代理需要的信息有时很琐碎（比如"改完依赖记得同步 lockfile 并重启 dev server"），放在面向人的文档里显得莫名其妙；
3. 分开之后，README 保持简洁给贡献者看，AGENTS.md 专注给代理看，谁都不迁就谁。

这也是社区选择"再建一个独立文件"而不是扩展现有文档的原因：给代理一个清晰、可预测的说明位置，比什么都强。

最快上手步骤：三步写出第一份 AGENTS.md

第一步：在仓库根目录放一个文件

就一行路径的事。文件叫 AGENTS.md，放在仓库根目录即可。懒办法也行：直接让正在协作的代理帮你生成一版初稿，再人工校对——它们最清楚自己缺哪些信息。

第二步：写五块最常用的内容

不用贪多，实践中高频出现的就是这几块：

• 项目概览：一两句话讲清这个项目是什么、范围在哪；
• 构建与测试命令：装依赖、起服务、跑测试各用什么，直接给可复制的命令；
• 代码风格：语言偏好、命名约定、文件组织方式；
• 测试要求：哪些场景要补测试、合入前的最低门槛；
• 安全注意事项：凭据放哪、哪些操作有副作用。

再往后，commit 信息格式、PR 标题规范、部署步骤、大文件的处理姿势……凡是你愿意叮嘱新队友的，都可以塞进来。

第三步：个别工具需要补一行配置

绝大多数工具会自动发现根目录的 AGENTS.md，只有少数要手动指一下：

• Aider：在.aider.conf.yml里加一行read: AGENTS.md；
• Gemini CLI：在.gemini/settings.json的 context 里指定"fileName": "AGENTS.md"。

配完就能用了，没有别的门槛。

Monorepo 最佳实践：嵌套 AGENTS.md 按子包拆分

大仓库里全局规则往往不够用。解法很直接：在子包目录里再放一个 AGENTS.md。代理会自动读取"离被编辑文件最近"的那份，距离最近者优先，每个子项目都能带一份量身定制的说明。作为参考，OpenAI 的主仓库里就铺了 88 个 AGENTS.md。

如果说明之间真有冲突，规则也很简单：离被改文件最近的 AGENTS.md 胜出；而你在对话里明确说的话，优先级最高，盖过一切文件。

兼容的 AI 工具清单：一份说明，二十多个工具通用

写一份说明，受益的是一整条工具链。目前兼容生态包括（按团队）：

这个格式最早由 Codex、Amp、Jules、Cursor、Factory 等团队协作提出，如今由 Linux 基金会旗下的 Agentic AI Foundation 托管维护，属于谁、又不属于谁——你用什么代理都能直接采用。

常见疑问逐条过：必填项？冲突？自动测试？

• 必须有固定字段吗？没有。它就是 Markdown，想写什么小节写什么小节。
• 指令互相矛盾听谁的？离被编辑文件最近的 AGENTS.md 赢，聊天里的明确指示赢过所有文件。
• 写了测试命令，代理会自动跑吗？会。只要你列出来了，代理会主动执行相关检查，并在收工前把失败项修好。
• 以后能改吗？随时改，把它当成活文档，而不是一次性交付。
• 已经有 AGENT.md 之类的旧文件？直接重命名为 AGENTS.md，再给旧名字建一个软链接保持兼容即可。

实例拆解：这个网站的源码本身就是一份教程

AGENTS.md 的官方网站（一个 Next.js 站点）的源码，恰好是最好的样例。打开仓库根目录的 AGENTS.md，你能看到非常"有血有肉"的规则：代理会话期间只允许用npm run dev起开发服务，严禁在会话里跑生产构建（原因：会把.next切成生产资源、弄坏热更新）；增删依赖后必须同步 lockfile 并重启 dev server；新组件一律 TypeScript。这些条款几乎条条来自真实踩坑——开头我讲的那个事故，就是这类规则要防的事。

想本地把样例站点跑起来看看：

git clone https://gitcode.com/GitHub_Trending/ag/agents.md cd agents.md && pnpm install && pnpm run dev

然后访问http://localhost:3000。页面各版块（FAQ、兼容工具墙、示例区）的实现分别在 components/ 和 pages/ 里，逛一逛能直观感受到"一个格式撑起一整个介绍站"是什么概念。

三条行动清单：今天、本周、持续

• 今天：在仓库根目录建一个 AGENTS.md，先只写构建和测试命令——这两块是收益最高的；
• 本周：补上代码风格、测试要求和容易踩的坑，顺便看看团队里谁在用需要手动配置的代理；
• 持续：把"每次代理犯一次错，就补一行规则"当成习惯。这份文件越用越准，是真正靠使用长出来的文档。

说到底，AGENTS.md 没有魔法，它只是把"你嘴上叮嘱了无数遍的话"落成了一个固定位置。写一次，所有代理都读得到。

【免费下载链接】agents.mdAGENTS.md — a simple, open format for guiding coding agents项目地址: https://gitcode.com/GitHub_Trending/ag/agents.md