最近总能在技术群和代码仓库里看到 AGENTS.md热度高得像每个 AI 项目都要配一份才算“现代工程”。我一开始也跟很多人一样心里打了个大大的问号这不就是给 AI 看的 README 吗多写一个 Markdown 文件真能让那些动不动就“上下文丢失”“改错文件”的编程助手变靠谱带着这个疑问我挑了三个实际项目来试水一个是个人维护的小工具库一个是别人留下的 legacy 中台系统还有一个是多人协作的微服务仓库。用了一个多月陆陆续续踩了不少坑也总结出一些自己的判断。先把结论放在前面AGENTS.md 不是万能药它更像一份“给 AI 代理的入职手册”有没有用取决于你写它的手法、维护的频率以及你对自己项目到底有多了解。这篇就把我的真实使用体验、踩过的坑以及一份可以直接抄作业的模板骨架完整分享出来。1. AGENTS.md 到底是什么先搞清楚它和普通文档的区别1.1 它解决的是“AI 进仓库之后靠什么做判断”的问题先说个基础问题为什么编码助手有了代码之后还是经常答非所问。很多人以为是模型能力不够其实大多数时候是代理Agent在进入项目时根本不知道该遵守哪些规则。它能看到一堆文件但不知道哪个是入口、哪段代码不能碰、测试该用哪个命令跑、分支模型是主干开发还是 Git Flow。就像空降到一个陌生团队的新人哪怕前面摆了一柜子资料也不知道该翻开哪一页。AGENTS.md 就是用来补这个空白的。它通常放在仓库根目录文件名固定让 Cursor、Claude Code、Codex、Copilot 这类工具在初始化会话时自动读取并注入上下文。它不是给人读的说明书而是给代理读的“第一课”。我第一次意识到它的作用是在一个 Python 工具库里。那个项目有几十个脚本入口散落在scripts/下而且好几个函数名长得很像。之前让 AI 改需求它总会挑错文件改完还理直气壮地跑一遍错误的测试命令。我在根目录放了一份 AGENTS.md写明“入口是cli.py核心数构在core/测试请用poetry run pytest tests/”接着再让代理做同样的事它第一眼就去了正确的位置行为立刻不一样了。这不是玄学而是代理工具在打开会话时会优先读取这个约定文件把它和系统提示词、用户的临时指令拼在一起作为初始上下文。对代理来说这份文件比 README 更接近“操作手册”因为它不需要你翻几百行说明只需要干净利落地告诉它这是什么项目、怎么构建、怎么测试、有哪些禁区。1.2 与 README、CONTRIBUTING 的边界不是同类文件是给代理的“第一课”有人会问项目里已经有 README.md 和 CONTRIBUTING.md 了为什么还要多一个 AGENTS.md这个问题的答案恰恰是理解它价值的关键。README 是给人看的作用是介绍项目是什么、怎么跑起来侧重可读性和宣传性。CONTRIBUTING 是给人看的协作规范讲提 PR、Code Review、commit message 的流程。AGENTS.md 是给机器看的“约束条件”它要求信息密度更高、命令更精确、规则更偏向“禁止做什么”。我见过有人在 README 里写“项目使用微服务架构遵循领域驱动设计追求高内聚低耦合”这种东西人看了有感觉但代理看了跟没看一样因为里面没有可执行的信息。AGENTS.md 里更应该出现的是类似“禁止在utils/下新增通用函数请直接放入shared/”这种命令式描述。两者服务的对象不同写作逻辑也完全不同。还有一个容易混淆的点是 AGENTS.md 和 CLAUDE.md 的关系。CLAUDE.md 是 Claude Code 自己支持的指令文件AGENTS.md 是社区推动的更通用约定目前很多主流工具对两者都会读取。如果你的团队只用某一个工具可以只维护对应的文件但如果你希望代理行为在不同工具间保持一致AGENTS.md 显然更通用。我自己现在的策略是仓库里放一份 AGENTS.md然后在其他工具的原生指令文件里用一行AGENTS.md引用它避免多份内容同步导致漂移。2. 有没有用取决于你看懂没看懂“上下文工程”这件事2.1 大型语言模型代理为什么“换了项目就不会工作”要回答“AGENTS.md 真的有用吗”核心得理解代理的工作方式。AI 编程助手本质上是一个带工具的对话系统它有一个上下文窗口窗口里装着系统提示词、历史对话、读取过的文件片段、工具返回结果以及用户最新的指令。模型就在这些信息里做下一步决策。问题在于上下文窗口是有限的。现代模型虽然有百万级 token 的能力但工程上没人会把整个仓库塞进去。代理通常是“按需读取”先看目录结构点开几个文件判断相关代码在哪儿再深入阅读。这个摸索过程非常耗时而且容易出错。我观察过代理在没有 AGENTS.md 时的行为它会把 README 通读一遍然后挨个打开它觉得“可能是入口”的文件经常在无关文件里浪费大量 token最后给出的方案甚至在依赖关系上就是错的。原因很简单没有人告诉它项目里最重要的事实。AGENTS.md 本质上是在压缩上下文。它用几千字把项目里最关键的信息提炼出来让代理在第一次行动之前就拿到高质量的路标。这就像你给新人一张地图而不是让他自己在城市里乱逛。文件有没有用不是看它写了多少字而是看它到底能不能帮代理省下试错次数。2.2 上下文窗口成本与其在会话里复制不如让代理自己加载我见过一些团队不是不写 AGENTS.md而是习惯在每次和 AI 对话时手动贴一段“背景说明”。这种做法在小任务里没问题但一旦任务复杂就会出现两个毛病第一手动贴的背景经常忘记更新和仓库现状对不上第二贴的内容受限于你当时的记忆容易漏掉关键信息。AGENTS.md 解决的是“约定优于配置”的问题。只要代理工具支持读取这个文件每次会话它都会自动加载不需要你重新描述一遍项目背景。换句话说你的一次写作换来的是此后所有代理会话的稳定输入。这就像是给代理配了记忆芯片而不是每次重新自我介绍。我实际测试过一个场景一个仓库两个模型同一道任务有 AGENTS.md 和没有 AGENTS.md 各跑一轮。没有的那轮C 模型花了 12 次工具调用才找到需要修改的文件其中有 4 次读的是无关文件有 AGENTS.md 的那轮它在第 2 次工具调用就直接定位到了src/services/order.py理由里写着“根据 AGENTS.md 的说明订单相关逻辑统一放在此文件中”。省下来的不只是时间还有肉眼可见的 token 消耗。2.3 为什么是 Markdown以及为什么 Markdown 本身也会出问题AGENTS.md 选择了 Markdown 而不是 txt、YAML 或 JSON这个选择本身是有讲究的。Markdown 是开发者最熟悉的文本格式既有结构标题、列表、代码块又不会被复杂的嵌套语法干扰模型理解。相比 JSON 的引号和缩进噪音Markdown 对 LLM 的解析更友好token 消耗也更低。但 Markdown 也有自己的坑。最大的坑是“表格和换行”。你在 GitHub 上渲染得很漂亮的表格被模型读取时可能是另一回事尤其是单元格里塞了长路径和命令行时模型经常把它拆散。我踩过一次AGENTS.md 里用表格写了环境变量映射代理读完之后把DATABASE_URL的值理解成了两行拼接出完全错误的连接串。后来我把这类内容改成了代码块或者键值的列表形式问题就消失了。另一个坑是“语义噪音”。为了排版好看有人会在文档里加大量装饰性语句像“本项目致力于……” “我们相信……”这种废话。人类读者会觉得有温度但模型会把这些当成潜在指令有时会生成一些莫名其妙的口号式 commit message。所以写 AGENTS.md 时尽量用祈使句和陈述句少用抒情和比喻把它当成一份技术规格书来写而不是宣传册。3. 实操视角值得放进 AGENTS.md 的内容清单与不需要放进的内容3.1 我会优先写进去的几个部分构建、测试、约束、术语表结合多次试错我整理了一份自己每次新建 AGENTS.md 都会对照的内容清单。这份清单不是从网上抄来的是在真实项目中反复验证过“确实能让代理表现变好”的部分。首先构建命令和依赖管理方式必须有。代理如果要跑测试、做静态检查靠猜测是不行的。我见过代理用 pip 装依赖结果那个项目明明是 poetry 管理的装完一堆版本冲突也见过代理用 npm run build但项目其实需要先patch-package。在 AGENTS.md 里写明“本项目使用 pnpm workspace构建命令是pnpm build测试命令是pnpm test依赖统一通过pnpm add -w安装”代理就不会在命令选择上瞎猜。其次关键路径和架构约束要有。比如“新业务模块放在src/features/下公共组件放src/components/禁止反向依赖src/legacy/”。这类约束对代理来说就是“护栏”。我遇到过最典型的情况是代理为了图方便直接在老模块里 import 了新模块被 code review 打回好几轮。写了约束之后它至少会先思考一下而不是闭眼就干。再次禁止事项和常见坑必须写。比如“不要修改generated/下的文件它们由代码生成器产生”“不要在api/层写业务逻辑”“数据库迁移文件只能递增不允许改动已提交的迁移”。这些信息在 README 里通常不会写但代理又非常容易触犯。最后术语表和领域模型也建议放一个精简版。对那些业务名词密集的项目比如“订单”“工单”“审批流”到底怎么翻译成代码实体代理经常搞混。我在一个电商后台项目里写了一小段术语对照代理生成的新接口参数名立刻规范了很多。3.2 哪些内容写了反而帮倒忙AGENTS.md 不是越厚越好。写太多反而会让代理“迷失重点”甚至把注意力从真正的用户需求转移到一堆规章上。我总结了几类明显帮倒忙的内容基本一出现就果断删掉。第一类空泛的原则和价值观。比如“写出高质量、可维护、优雅的代码”这种句子对模型几乎没有任何指导意义还会诱导代理生成过度设计的代码。我测试过一次AGENTS.md 里写了一句“本项目追求极致的代码性能”结果代理把一个简单的数据映射函数改成了带缓存、批处理、异步预加载的巨型实现光看注释就让人头皮发麻。后来把它改成“优先考虑可读性禁止在非热点路径做激进优化”一次就校直了。第二类过时信息。AGENTS.md 最怕的就是内容与代码脱节。比如文档里写明“旧版接口仍要维护”但代码里旧接口已经下线了代理看到冲突时通常会选信文档而不是去翻代码结果生成一堆调用过期接口的代码。我后来给自己定了一个规矩每次大版本改动、目录结构调整、命令变化时必须同步更新 AGENTS.md否则宁可不写也不能写错的。第三类过于琐碎的目录清单。把整个项目的文件树贴进去毫无意义代理本来就能通过工具浏览目录。AGENTS.md 应该写的是“哪个目录是什么职能”而不是“哪个文件叫什么名字”。我把项目里完整的tree输出删掉、替换成三层以内的架构说明之后代理的定位准确率反而更高了。3.3 一个可以直接抄的骨架示例这里放一个我目前觉得最顺手的骨架适合中小型仓库大家可以按需删减# AGENTS.md ## 项目概述 - 用途面向电商商家侧的后台管理系统处理商品、订单、库存、营销四块核心业务。 - 技术栈Vue 3 TypeScript Vite Pinia后端走公司统一网关前端不直接连数据库。 ## 构建与测试 - 安装依赖pnpm install - 本地开发pnpm dev - 运行测试pnpm test单测pnpm test:e2e端到端 - Lintpnpm lint - 提交前必须通过 lint 和单测。 ## 目录结构仅说明风格不逐文件列举 - src/api所有后端接口封装禁止在此拼接 UI 相关逻辑。 - src/components通用展示组件不应包含业务请求。 - src/composables可复用逻辑状态管理推荐使用 Pinia store不直接放入 composable。 - src/views页面级组件负责组装避免过重逻辑。 ## 编码约束 - 禁止直接修改 generated/ 目录下任何文件如需调整请改生成器配置。 - 禁止在 api 层写 alert、console.log 等副作用代码。 - API 参数统一使用 camelCase后端下划线参数在 api/ 层完成转换。 - 新增页面路由前检查是否存在同名页面避免重复入口。 ## 常见变更场景 - 修改商品列表先改 src/views/product 下对应组件再在 src/api/product.ts 中调整接口封装。 - 新增营销活动类型需要同时修改 src/types/marketing.ts 和后端联调说明。 - 更换 UI 库不得直接替换全局组件先评估 src/components 下封装层的影响。我第一次把这份骨架放进一个真实项目之后代理生成代码的“一次通过率”有了明显提升尤其是涉及目录策略和禁用事项的部分效果比想象中更明显。当然骨架本身也要演化不同项目最需要强调的内容完全不一样。4. 什么情况下确实没用什么情况下它非常值钱4.1 单文件小项目和随处跑偏的老系统说实话不是所有项目都适合 AGENTS.md。如果你的项目就一个文件几百行代理一眼就能看完所有代码这时候再配一份 AGENTS.md 纯粹是负担。我刚开始心态比较激进给一个只有两百行脚本的小工具也写了一版结果发现代理根本不会去读它因为它扫到的代码量太少了系统提示词足够覆盖全部信息额外的文档反而成为噪音。后来我把这类小项目里的 AGENTS.md 全删了。另一种容易“失效”的情况是代码结构极度混乱的老系统。AGENTS.md 需要如实描述项目状态但很多老系统根本说不清楚自己的依赖边界目录名字叫着core里面其实全是旧逻辑。这时候写文档要么写得很假要么写出来也没人敢信。我接手过一个遗留中台第一次试图写 AGENTS.md 时光是整理“哪段逻辑不要动”就花了半天结果代理根本不按照文档走因为它读到的代码和文档描述的认知差距太大模型在选择时更倾向于相信自己扫到的现场。对这种项目我的建议是先花一段时间做目录整理和代码梳理等系统有一定一致性后再让 AGENTS.md 登场顺序不能反。4.2 大型多人仓库、紧急修复和历史遗留代码AGENTS.md 的甜区和上面相反AGENTS.md 真正值钱的场景恰恰是人多、模块多、交接过密的地方。大型多人仓库是第一个甜区。团队越大口头约定越多新加入的代理和人越难搞清楚潜规则。我所在的团队有段时间频繁出现“代理在别人模块里改代码”的尴尬事后来发现根因是 AI 只看了当前任务相关的文件完全不知道哪些模块是有 owner 的。在 AGENTS.md 里写明“账号模块所有改动需要先同步给 backend-account 组”之后代理在动手前会主动检索负责人冲突率立刻降了下来。第二个甜区是紧急修复。线上 bug 发生时你希望代理快速定位到问题点而不是花五分钟在仓库里逛。有 AGENTS.md 的项目代理可以直接跳到指定业务目录结合内部注释快速给出修复方案。我经历了一次线上告警代理在 90 秒内定位到了多租户下数据隔离的缺陷点这在以前根本不敢想。第三个甜区是历史遗留代码的“安全边界”。老系统里总有那些“别乱动”的模块比如复杂的权限校验、定时任务、数据迁移。AGENTS.md 里把这些区域标记出来并写下“改动前必须输出影响面分析”代理的操作就会谨慎很多。我甚至会在文档里注明“权限校验逻辑如果是改行为、而不是修 bug请拒绝执行并询问”这种方式等于给代理加了一个安全阀。4.3 失效的文档比没有文档更坏事AGENTS.md 最大的风险不是它不存在而是它“给代理一种虚假的安全感”。我见过很多项目AGENTS.md 写得很漂亮但实际代码早就和文档说的不一样了。这种情况比没有文档更危险因为代理在遇到矛盾时有时会优先采信文档而文档又是错的于是它沿着错的方向猛写返工时发现已经改了一堆不该动的代码。我自己也上过这个当。两个月前有一个项目把构建工具从 webpack 换成了 ViteAGENTS.md 忘了更新。结果代理按旧的 webpack 命令跑构建反复报错它还根据错误信息自动改配置文件把好好的 Vite 配置改得面目全非。那次事故之后我开始把 AGENTS.md 的更新纳入代码评审清单只要构建命令、目录结构、依赖管理方式发生变化就强制相关开发者顺手改文档和改代码一起提交。所以说AGENTS.md 有用与否关键在它是否“保鲜”。一份陈旧但充满自信的文档对 AI 代理的误导能力比它对人类的误导能力大得多。人类看到文档和现实不符会怀疑文档但模型经常只会顺着文档的上下文继续生成内容越走越远。5. 写完 AGENTS.md 后还要把它当作“需要持续维护”的活文档5.1 维护节奏版本更新的三次触发点搞清楚了 AGENTS.md 不是“写一次就一劳永逸”下一个问题就是多久维护一次。我的经验是不需要机械地给 AGENTS.md 设更新计划但要记住三个强制触发点。第一次触发点是构建和依赖体系变化。比如从 npm 切到 pnpm、升级了 Node 版本、CI 从单测试跑改成 parallel 模式这些都会直接改变代理要执行的核心命令。任何一次package.json的脚本变化、构建链路的调整都应该回头检查 AGENTS.md 里的命令是否失效。第二次触发点是目录结构或架构约束调整。比如新拆了一个feature-xxx模块、把公共函数从utils挪到shared、引入了新的目录命名规范。这些变化在代码 review 里往往只是“移动文件”但对 AGENTS.md 来说它可能意味着整段“目录说明”都要改。第三次触发点是代理行为出问题的时候。如果某天你发现代理开始在错误的位置生成代码先别急着换模型回头看看 AGENTS.md 里有没有过时信息。很多时候是服务端提示词加了新东西或者依赖升级后代码结构变了文档没有跟上。我习惯在每个迭代结束后问自己一句如果我现在让一个刚初始化的新代理来跑这个仓库它拿着这份文档能做出正确决定吗只要答案是犹豫的就该马上更新文档。5.2 用注释留痕避免内容漂移AGENTS.md 本质也是仓库里的一个文件它应该和代码一样接受 review、保留历史。我会在文件头部维护一个“最近变更”区域记录每次重要更新的时间和内容。比如## 最近变更 - 2025-03-10构建工具从 webpack 切换为 Vite更新“构建与测试”部分。 - 2025-03-02新增 src/modules/refund 退款模块更新目录结构说明。 - 2025-02-18禁止修改 generated/ 目录新增编码约束。这个做法有两个连带好处。第一review 时大家一眼能看到文档变化和大版本的关联不会互相踩到第二代理读文件时也会看到这些历史信息更清楚哪些规则是近期强化的、哪些是历史遗留。偶尔代理甚至会根据变更记录推断“旧的规则可能已经失效”这反而提升了它的判断准确率。另外一个防止漂移的细节是AGENTS.md 不要写“通用 AI 使用技巧”比如“请先阅读 README 再回答问题”“请遵循最佳实践”。这类内容放在任何项目里都成立但会占掉上下文空间稀释掉真正属于这个项目的关键信息。作好留痕的核心是让文件里每一句话都有这个仓库特有的信息量而不是泛泛而谈。5.3 让 AGENTS.md 和 CI 流程互动我的尝试最近我开始做一个实验性尝试在 CI 里加一步“文档校验”专门检测 AGENTS.md 是否符合格式要求、是否包含关键字段如构建命令、目录结构、禁改路径。这一步不会阻断发布但会在 MR 上留一个 warning提醒作者“AGENTS.md 可能需要同步更新”。实现思路不复杂写一个轻量脚本解析 AGENTS.md检查里面是否存在必须的标题和字段如果缺失就打标记。我特意没有做成强校验因为 AGENTS.md 本质上还是一份灵活文档如果 CI 强制它必须包含某段内容反而会让团队为了“过检查”而堆砌无用信息。比较合适的度是只做存在性检查提醒“你这次 commit 动了构建配置但 AGENTS.md 没有相关记录”而不是替团队做内容审核。这个实验运行了一轮之后团队里对 AGENTS.md 的态度有了微妙变化。它从“一个可有可无的给 AI 看的东西”变成了“和代码一起维护的技术资产”。当我看到有同学在 MR 描述里顺手写了一句“同步更新了 AGENTS.md 中的目录说明”时我知道这个文件在这个团队里已经真正活下来了。6. 我的最终结论与一个收尾技巧回到标题那个问题AGENTS.md 真的有用吗我的答案是它有用但用处不在“给 AI 一份说明”这么简单。它的价值是倒逼你回答一个问题如果我的项目明天要交给一个完全不了解背景、但执行力极强的工程师去改我需要提前写下什么这个过程会逼你理清架构边界、构建方式、代码红线而这些理清之后的内容人可以用AI 也可以用。我在实际使用中还有一个体会不要把 AGENTS.md 想得过于复杂它不需要覆盖项目的所有细节只需要让代理在“最开始的一步”不做错决定。最重要的指令往往只有几条怎么跑测试、别碰哪个目录、新增代码放哪。这几条写清楚就已经能避免大量返工。最后再分享一个小技巧如果实在不知道文档里该写什么可以新建一个空 AGENTS.md让代理先执行一个简单任务观察它在哪个环节犯傻把那个环节的答案写进去。但这种用法一定要搭配“定期更新”的纪律否则三个月后那份文档自己就会变成一个新的坑。说到底AGENTS.md 只不过是一张地图真正让项目变好的永远是那个愿意把地图画准确、并且不断修正的人。
AGENTS.md实战：给AI编程助手的入职手册，解决上下文丢失与规则混乱
最近总能在技术群和代码仓库里看到 AGENTS.md热度高得像每个 AI 项目都要配一份才算“现代工程”。我一开始也跟很多人一样心里打了个大大的问号这不就是给 AI 看的 README 吗多写一个 Markdown 文件真能让那些动不动就“上下文丢失”“改错文件”的编程助手变靠谱带着这个疑问我挑了三个实际项目来试水一个是个人维护的小工具库一个是别人留下的 legacy 中台系统还有一个是多人协作的微服务仓库。用了一个多月陆陆续续踩了不少坑也总结出一些自己的判断。先把结论放在前面AGENTS.md 不是万能药它更像一份“给 AI 代理的入职手册”有没有用取决于你写它的手法、维护的频率以及你对自己项目到底有多了解。这篇就把我的真实使用体验、踩过的坑以及一份可以直接抄作业的模板骨架完整分享出来。1. AGENTS.md 到底是什么先搞清楚它和普通文档的区别1.1 它解决的是“AI 进仓库之后靠什么做判断”的问题先说个基础问题为什么编码助手有了代码之后还是经常答非所问。很多人以为是模型能力不够其实大多数时候是代理Agent在进入项目时根本不知道该遵守哪些规则。它能看到一堆文件但不知道哪个是入口、哪段代码不能碰、测试该用哪个命令跑、分支模型是主干开发还是 Git Flow。就像空降到一个陌生团队的新人哪怕前面摆了一柜子资料也不知道该翻开哪一页。AGENTS.md 就是用来补这个空白的。它通常放在仓库根目录文件名固定让 Cursor、Claude Code、Codex、Copilot 这类工具在初始化会话时自动读取并注入上下文。它不是给人读的说明书而是给代理读的“第一课”。我第一次意识到它的作用是在一个 Python 工具库里。那个项目有几十个脚本入口散落在scripts/下而且好几个函数名长得很像。之前让 AI 改需求它总会挑错文件改完还理直气壮地跑一遍错误的测试命令。我在根目录放了一份 AGENTS.md写明“入口是cli.py核心数构在core/测试请用poetry run pytest tests/”接着再让代理做同样的事它第一眼就去了正确的位置行为立刻不一样了。这不是玄学而是代理工具在打开会话时会优先读取这个约定文件把它和系统提示词、用户的临时指令拼在一起作为初始上下文。对代理来说这份文件比 README 更接近“操作手册”因为它不需要你翻几百行说明只需要干净利落地告诉它这是什么项目、怎么构建、怎么测试、有哪些禁区。1.2 与 README、CONTRIBUTING 的边界不是同类文件是给代理的“第一课”有人会问项目里已经有 README.md 和 CONTRIBUTING.md 了为什么还要多一个 AGENTS.md这个问题的答案恰恰是理解它价值的关键。README 是给人看的作用是介绍项目是什么、怎么跑起来侧重可读性和宣传性。CONTRIBUTING 是给人看的协作规范讲提 PR、Code Review、commit message 的流程。AGENTS.md 是给机器看的“约束条件”它要求信息密度更高、命令更精确、规则更偏向“禁止做什么”。我见过有人在 README 里写“项目使用微服务架构遵循领域驱动设计追求高内聚低耦合”这种东西人看了有感觉但代理看了跟没看一样因为里面没有可执行的信息。AGENTS.md 里更应该出现的是类似“禁止在utils/下新增通用函数请直接放入shared/”这种命令式描述。两者服务的对象不同写作逻辑也完全不同。还有一个容易混淆的点是 AGENTS.md 和 CLAUDE.md 的关系。CLAUDE.md 是 Claude Code 自己支持的指令文件AGENTS.md 是社区推动的更通用约定目前很多主流工具对两者都会读取。如果你的团队只用某一个工具可以只维护对应的文件但如果你希望代理行为在不同工具间保持一致AGENTS.md 显然更通用。我自己现在的策略是仓库里放一份 AGENTS.md然后在其他工具的原生指令文件里用一行AGENTS.md引用它避免多份内容同步导致漂移。2. 有没有用取决于你看懂没看懂“上下文工程”这件事2.1 大型语言模型代理为什么“换了项目就不会工作”要回答“AGENTS.md 真的有用吗”核心得理解代理的工作方式。AI 编程助手本质上是一个带工具的对话系统它有一个上下文窗口窗口里装着系统提示词、历史对话、读取过的文件片段、工具返回结果以及用户最新的指令。模型就在这些信息里做下一步决策。问题在于上下文窗口是有限的。现代模型虽然有百万级 token 的能力但工程上没人会把整个仓库塞进去。代理通常是“按需读取”先看目录结构点开几个文件判断相关代码在哪儿再深入阅读。这个摸索过程非常耗时而且容易出错。我观察过代理在没有 AGENTS.md 时的行为它会把 README 通读一遍然后挨个打开它觉得“可能是入口”的文件经常在无关文件里浪费大量 token最后给出的方案甚至在依赖关系上就是错的。原因很简单没有人告诉它项目里最重要的事实。AGENTS.md 本质上是在压缩上下文。它用几千字把项目里最关键的信息提炼出来让代理在第一次行动之前就拿到高质量的路标。这就像你给新人一张地图而不是让他自己在城市里乱逛。文件有没有用不是看它写了多少字而是看它到底能不能帮代理省下试错次数。2.2 上下文窗口成本与其在会话里复制不如让代理自己加载我见过一些团队不是不写 AGENTS.md而是习惯在每次和 AI 对话时手动贴一段“背景说明”。这种做法在小任务里没问题但一旦任务复杂就会出现两个毛病第一手动贴的背景经常忘记更新和仓库现状对不上第二贴的内容受限于你当时的记忆容易漏掉关键信息。AGENTS.md 解决的是“约定优于配置”的问题。只要代理工具支持读取这个文件每次会话它都会自动加载不需要你重新描述一遍项目背景。换句话说你的一次写作换来的是此后所有代理会话的稳定输入。这就像是给代理配了记忆芯片而不是每次重新自我介绍。我实际测试过一个场景一个仓库两个模型同一道任务有 AGENTS.md 和没有 AGENTS.md 各跑一轮。没有的那轮C 模型花了 12 次工具调用才找到需要修改的文件其中有 4 次读的是无关文件有 AGENTS.md 的那轮它在第 2 次工具调用就直接定位到了src/services/order.py理由里写着“根据 AGENTS.md 的说明订单相关逻辑统一放在此文件中”。省下来的不只是时间还有肉眼可见的 token 消耗。2.3 为什么是 Markdown以及为什么 Markdown 本身也会出问题AGENTS.md 选择了 Markdown 而不是 txt、YAML 或 JSON这个选择本身是有讲究的。Markdown 是开发者最熟悉的文本格式既有结构标题、列表、代码块又不会被复杂的嵌套语法干扰模型理解。相比 JSON 的引号和缩进噪音Markdown 对 LLM 的解析更友好token 消耗也更低。但 Markdown 也有自己的坑。最大的坑是“表格和换行”。你在 GitHub 上渲染得很漂亮的表格被模型读取时可能是另一回事尤其是单元格里塞了长路径和命令行时模型经常把它拆散。我踩过一次AGENTS.md 里用表格写了环境变量映射代理读完之后把DATABASE_URL的值理解成了两行拼接出完全错误的连接串。后来我把这类内容改成了代码块或者键值的列表形式问题就消失了。另一个坑是“语义噪音”。为了排版好看有人会在文档里加大量装饰性语句像“本项目致力于……” “我们相信……”这种废话。人类读者会觉得有温度但模型会把这些当成潜在指令有时会生成一些莫名其妙的口号式 commit message。所以写 AGENTS.md 时尽量用祈使句和陈述句少用抒情和比喻把它当成一份技术规格书来写而不是宣传册。3. 实操视角值得放进 AGENTS.md 的内容清单与不需要放进的内容3.1 我会优先写进去的几个部分构建、测试、约束、术语表结合多次试错我整理了一份自己每次新建 AGENTS.md 都会对照的内容清单。这份清单不是从网上抄来的是在真实项目中反复验证过“确实能让代理表现变好”的部分。首先构建命令和依赖管理方式必须有。代理如果要跑测试、做静态检查靠猜测是不行的。我见过代理用 pip 装依赖结果那个项目明明是 poetry 管理的装完一堆版本冲突也见过代理用 npm run build但项目其实需要先patch-package。在 AGENTS.md 里写明“本项目使用 pnpm workspace构建命令是pnpm build测试命令是pnpm test依赖统一通过pnpm add -w安装”代理就不会在命令选择上瞎猜。其次关键路径和架构约束要有。比如“新业务模块放在src/features/下公共组件放src/components/禁止反向依赖src/legacy/”。这类约束对代理来说就是“护栏”。我遇到过最典型的情况是代理为了图方便直接在老模块里 import 了新模块被 code review 打回好几轮。写了约束之后它至少会先思考一下而不是闭眼就干。再次禁止事项和常见坑必须写。比如“不要修改generated/下的文件它们由代码生成器产生”“不要在api/层写业务逻辑”“数据库迁移文件只能递增不允许改动已提交的迁移”。这些信息在 README 里通常不会写但代理又非常容易触犯。最后术语表和领域模型也建议放一个精简版。对那些业务名词密集的项目比如“订单”“工单”“审批流”到底怎么翻译成代码实体代理经常搞混。我在一个电商后台项目里写了一小段术语对照代理生成的新接口参数名立刻规范了很多。3.2 哪些内容写了反而帮倒忙AGENTS.md 不是越厚越好。写太多反而会让代理“迷失重点”甚至把注意力从真正的用户需求转移到一堆规章上。我总结了几类明显帮倒忙的内容基本一出现就果断删掉。第一类空泛的原则和价值观。比如“写出高质量、可维护、优雅的代码”这种句子对模型几乎没有任何指导意义还会诱导代理生成过度设计的代码。我测试过一次AGENTS.md 里写了一句“本项目追求极致的代码性能”结果代理把一个简单的数据映射函数改成了带缓存、批处理、异步预加载的巨型实现光看注释就让人头皮发麻。后来把它改成“优先考虑可读性禁止在非热点路径做激进优化”一次就校直了。第二类过时信息。AGENTS.md 最怕的就是内容与代码脱节。比如文档里写明“旧版接口仍要维护”但代码里旧接口已经下线了代理看到冲突时通常会选信文档而不是去翻代码结果生成一堆调用过期接口的代码。我后来给自己定了一个规矩每次大版本改动、目录结构调整、命令变化时必须同步更新 AGENTS.md否则宁可不写也不能写错的。第三类过于琐碎的目录清单。把整个项目的文件树贴进去毫无意义代理本来就能通过工具浏览目录。AGENTS.md 应该写的是“哪个目录是什么职能”而不是“哪个文件叫什么名字”。我把项目里完整的tree输出删掉、替换成三层以内的架构说明之后代理的定位准确率反而更高了。3.3 一个可以直接抄的骨架示例这里放一个我目前觉得最顺手的骨架适合中小型仓库大家可以按需删减# AGENTS.md ## 项目概述 - 用途面向电商商家侧的后台管理系统处理商品、订单、库存、营销四块核心业务。 - 技术栈Vue 3 TypeScript Vite Pinia后端走公司统一网关前端不直接连数据库。 ## 构建与测试 - 安装依赖pnpm install - 本地开发pnpm dev - 运行测试pnpm test单测pnpm test:e2e端到端 - Lintpnpm lint - 提交前必须通过 lint 和单测。 ## 目录结构仅说明风格不逐文件列举 - src/api所有后端接口封装禁止在此拼接 UI 相关逻辑。 - src/components通用展示组件不应包含业务请求。 - src/composables可复用逻辑状态管理推荐使用 Pinia store不直接放入 composable。 - src/views页面级组件负责组装避免过重逻辑。 ## 编码约束 - 禁止直接修改 generated/ 目录下任何文件如需调整请改生成器配置。 - 禁止在 api 层写 alert、console.log 等副作用代码。 - API 参数统一使用 camelCase后端下划线参数在 api/ 层完成转换。 - 新增页面路由前检查是否存在同名页面避免重复入口。 ## 常见变更场景 - 修改商品列表先改 src/views/product 下对应组件再在 src/api/product.ts 中调整接口封装。 - 新增营销活动类型需要同时修改 src/types/marketing.ts 和后端联调说明。 - 更换 UI 库不得直接替换全局组件先评估 src/components 下封装层的影响。我第一次把这份骨架放进一个真实项目之后代理生成代码的“一次通过率”有了明显提升尤其是涉及目录策略和禁用事项的部分效果比想象中更明显。当然骨架本身也要演化不同项目最需要强调的内容完全不一样。4. 什么情况下确实没用什么情况下它非常值钱4.1 单文件小项目和随处跑偏的老系统说实话不是所有项目都适合 AGENTS.md。如果你的项目就一个文件几百行代理一眼就能看完所有代码这时候再配一份 AGENTS.md 纯粹是负担。我刚开始心态比较激进给一个只有两百行脚本的小工具也写了一版结果发现代理根本不会去读它因为它扫到的代码量太少了系统提示词足够覆盖全部信息额外的文档反而成为噪音。后来我把这类小项目里的 AGENTS.md 全删了。另一种容易“失效”的情况是代码结构极度混乱的老系统。AGENTS.md 需要如实描述项目状态但很多老系统根本说不清楚自己的依赖边界目录名字叫着core里面其实全是旧逻辑。这时候写文档要么写得很假要么写出来也没人敢信。我接手过一个遗留中台第一次试图写 AGENTS.md 时光是整理“哪段逻辑不要动”就花了半天结果代理根本不按照文档走因为它读到的代码和文档描述的认知差距太大模型在选择时更倾向于相信自己扫到的现场。对这种项目我的建议是先花一段时间做目录整理和代码梳理等系统有一定一致性后再让 AGENTS.md 登场顺序不能反。4.2 大型多人仓库、紧急修复和历史遗留代码AGENTS.md 的甜区和上面相反AGENTS.md 真正值钱的场景恰恰是人多、模块多、交接过密的地方。大型多人仓库是第一个甜区。团队越大口头约定越多新加入的代理和人越难搞清楚潜规则。我所在的团队有段时间频繁出现“代理在别人模块里改代码”的尴尬事后来发现根因是 AI 只看了当前任务相关的文件完全不知道哪些模块是有 owner 的。在 AGENTS.md 里写明“账号模块所有改动需要先同步给 backend-account 组”之后代理在动手前会主动检索负责人冲突率立刻降了下来。第二个甜区是紧急修复。线上 bug 发生时你希望代理快速定位到问题点而不是花五分钟在仓库里逛。有 AGENTS.md 的项目代理可以直接跳到指定业务目录结合内部注释快速给出修复方案。我经历了一次线上告警代理在 90 秒内定位到了多租户下数据隔离的缺陷点这在以前根本不敢想。第三个甜区是历史遗留代码的“安全边界”。老系统里总有那些“别乱动”的模块比如复杂的权限校验、定时任务、数据迁移。AGENTS.md 里把这些区域标记出来并写下“改动前必须输出影响面分析”代理的操作就会谨慎很多。我甚至会在文档里注明“权限校验逻辑如果是改行为、而不是修 bug请拒绝执行并询问”这种方式等于给代理加了一个安全阀。4.3 失效的文档比没有文档更坏事AGENTS.md 最大的风险不是它不存在而是它“给代理一种虚假的安全感”。我见过很多项目AGENTS.md 写得很漂亮但实际代码早就和文档说的不一样了。这种情况比没有文档更危险因为代理在遇到矛盾时有时会优先采信文档而文档又是错的于是它沿着错的方向猛写返工时发现已经改了一堆不该动的代码。我自己也上过这个当。两个月前有一个项目把构建工具从 webpack 换成了 ViteAGENTS.md 忘了更新。结果代理按旧的 webpack 命令跑构建反复报错它还根据错误信息自动改配置文件把好好的 Vite 配置改得面目全非。那次事故之后我开始把 AGENTS.md 的更新纳入代码评审清单只要构建命令、目录结构、依赖管理方式发生变化就强制相关开发者顺手改文档和改代码一起提交。所以说AGENTS.md 有用与否关键在它是否“保鲜”。一份陈旧但充满自信的文档对 AI 代理的误导能力比它对人类的误导能力大得多。人类看到文档和现实不符会怀疑文档但模型经常只会顺着文档的上下文继续生成内容越走越远。5. 写完 AGENTS.md 后还要把它当作“需要持续维护”的活文档5.1 维护节奏版本更新的三次触发点搞清楚了 AGENTS.md 不是“写一次就一劳永逸”下一个问题就是多久维护一次。我的经验是不需要机械地给 AGENTS.md 设更新计划但要记住三个强制触发点。第一次触发点是构建和依赖体系变化。比如从 npm 切到 pnpm、升级了 Node 版本、CI 从单测试跑改成 parallel 模式这些都会直接改变代理要执行的核心命令。任何一次package.json的脚本变化、构建链路的调整都应该回头检查 AGENTS.md 里的命令是否失效。第二次触发点是目录结构或架构约束调整。比如新拆了一个feature-xxx模块、把公共函数从utils挪到shared、引入了新的目录命名规范。这些变化在代码 review 里往往只是“移动文件”但对 AGENTS.md 来说它可能意味着整段“目录说明”都要改。第三次触发点是代理行为出问题的时候。如果某天你发现代理开始在错误的位置生成代码先别急着换模型回头看看 AGENTS.md 里有没有过时信息。很多时候是服务端提示词加了新东西或者依赖升级后代码结构变了文档没有跟上。我习惯在每个迭代结束后问自己一句如果我现在让一个刚初始化的新代理来跑这个仓库它拿着这份文档能做出正确决定吗只要答案是犹豫的就该马上更新文档。5.2 用注释留痕避免内容漂移AGENTS.md 本质也是仓库里的一个文件它应该和代码一样接受 review、保留历史。我会在文件头部维护一个“最近变更”区域记录每次重要更新的时间和内容。比如## 最近变更 - 2025-03-10构建工具从 webpack 切换为 Vite更新“构建与测试”部分。 - 2025-03-02新增 src/modules/refund 退款模块更新目录结构说明。 - 2025-02-18禁止修改 generated/ 目录新增编码约束。这个做法有两个连带好处。第一review 时大家一眼能看到文档变化和大版本的关联不会互相踩到第二代理读文件时也会看到这些历史信息更清楚哪些规则是近期强化的、哪些是历史遗留。偶尔代理甚至会根据变更记录推断“旧的规则可能已经失效”这反而提升了它的判断准确率。另外一个防止漂移的细节是AGENTS.md 不要写“通用 AI 使用技巧”比如“请先阅读 README 再回答问题”“请遵循最佳实践”。这类内容放在任何项目里都成立但会占掉上下文空间稀释掉真正属于这个项目的关键信息。作好留痕的核心是让文件里每一句话都有这个仓库特有的信息量而不是泛泛而谈。5.3 让 AGENTS.md 和 CI 流程互动我的尝试最近我开始做一个实验性尝试在 CI 里加一步“文档校验”专门检测 AGENTS.md 是否符合格式要求、是否包含关键字段如构建命令、目录结构、禁改路径。这一步不会阻断发布但会在 MR 上留一个 warning提醒作者“AGENTS.md 可能需要同步更新”。实现思路不复杂写一个轻量脚本解析 AGENTS.md检查里面是否存在必须的标题和字段如果缺失就打标记。我特意没有做成强校验因为 AGENTS.md 本质上还是一份灵活文档如果 CI 强制它必须包含某段内容反而会让团队为了“过检查”而堆砌无用信息。比较合适的度是只做存在性检查提醒“你这次 commit 动了构建配置但 AGENTS.md 没有相关记录”而不是替团队做内容审核。这个实验运行了一轮之后团队里对 AGENTS.md 的态度有了微妙变化。它从“一个可有可无的给 AI 看的东西”变成了“和代码一起维护的技术资产”。当我看到有同学在 MR 描述里顺手写了一句“同步更新了 AGENTS.md 中的目录说明”时我知道这个文件在这个团队里已经真正活下来了。6. 我的最终结论与一个收尾技巧回到标题那个问题AGENTS.md 真的有用吗我的答案是它有用但用处不在“给 AI 一份说明”这么简单。它的价值是倒逼你回答一个问题如果我的项目明天要交给一个完全不了解背景、但执行力极强的工程师去改我需要提前写下什么这个过程会逼你理清架构边界、构建方式、代码红线而这些理清之后的内容人可以用AI 也可以用。我在实际使用中还有一个体会不要把 AGENTS.md 想得过于复杂它不需要覆盖项目的所有细节只需要让代理在“最开始的一步”不做错决定。最重要的指令往往只有几条怎么跑测试、别碰哪个目录、新增代码放哪。这几条写清楚就已经能避免大量返工。最后再分享一个小技巧如果实在不知道文档里该写什么可以新建一个空 AGENTS.md让代理先执行一个简单任务观察它在哪个环节犯傻把那个环节的答案写进去。但这种用法一定要搭配“定期更新”的纪律否则三个月后那份文档自己就会变成一个新的坑。说到底AGENTS.md 只不过是一张地图真正让项目变好的永远是那个愿意把地图画准确、并且不断修正的人。
