配好了模型、写好了性格，Agent就能干活了吗？

还不够。差一份AGENTS.md——Agent的岗位说明书。

模型是大脑，决定聪不聪明；SOUL.md是人品，决定性格和价值观。AGENTS.md是岗位说明书，决定干什么活、怎么干活。

AGENTS.md到底有什么用

一句话定义：Agent每次启动时读取的指令文件，告诉她负责什么、怎么干活、遵照什么标准、什么不能碰。

打个比方：你招了一个新员工，第一天入职，你给她三样东西——公司宣传册（README）告诉她公司是干嘛的，企业文化手册（SOUL.md）告诉她价值观，岗位说明书（AGENTS.md）告诉她具体干什么、怎么干、要干成啥样、什么不能碰。没有岗位说明书，新员工每天工作只能靠猜，无法沉淀、难以进步。Agent也一样。

配与不配的真实差距：

采用默认配置AGENTS.md，Agent不会"废掉"——她依然能用通用能力干活，就像一个聪明但没有系统培训的实习生。交出来的东西不能说差，但总是"不够贴合"：格式不对、口径不对、边界不对、质量不一致，每次都要你重新整理才能用。更要命的是，上周纠正过的问题，下次新会话她又犯了。

ETH Zurich 2026年一项覆盖2500+真实仓库的研究给出了硬数据：配了AGENTS.md后，Agent运行时间减少28.64%，输出token减少16.58%，任务成功率提升约4个百分点。

GitHub对2500+仓库的分析也证实，配置清晰指令的项目，Agent初次输出更接近标准，反复纠正的开销显著降低。目前已有6万多个开源项目采用AGENTS.md，30多种AI工具原生支持这个格式。

翻译成一句话：配置AGENTS.md之后，Agent跑得更快、花钱更少、干活更准。

是否让AI自己写AGENTS.md就可以呢？

更有意思的反直觉发现：让LLM自动生成AGENTS.md，效果反而更差——8个测试场景有5个降低了任务成功率。

六个必避的坑

坑1：让AI自动生成，结果更差

这是最反直觉的坑。

ETH研究实锤：AI自动生成的AGENTS.md，充满"遵循错误处理最佳实践"、"编写清晰可维护的代码"、"保持专业水准"这类废话——Agent本来就知道，写出来只是浪费上下文窗口的token。而且，自动生成的文件往往跟README内容重复，Agent本来就能自己读到这些信息。

这些导致AI自动生成的指令文件在8个场景中有5个降低了任务成功率，每个任务多走2到4步，推理成本反而增加20%以上。

核心内容必须手写，手写30行具体规则，胜过AI生成300行通用模板。

AI可以帮你润色文字、检查结构，但判断"该写什么"必须你自己来。

坑2：职责太笼统，Agent变万金油

"负责信息相关工作"这种描述，Agent会变成万金油，什么都做什么都不精。

要写成具体动作："负责搜索策略制定、信源评估、数据交叉验证、信息结构化交付"。

判断标准很简单：读完这句话，Agent知道第一天该干什么；职责越具体，Agent越不需要猜你的意思。

好的职责描述是动词开头的具体动作，不是形容词堆砌的岗位名称。

坑3：没写决策规则，要么太莽要么太怂

我的战略Agent刚开始没配置AGENTS.md。

在计划写行业分析报告时，我刚拟定分析框架，准备和她讨论框架是否合理。

她直接按分析框架出了一份行业分析报告，没有请示，没有确认。

结果，生成的分析报告方向全偏。

于是，要求"重要行动前必须请示"，她又变成每件事都来问我。

解决办法是设定决策规则，分为三档：

• 自主执行：不用请示，直接执行，比如格式调整、数据整理等；

• 标注执行：置信度高于80%的自主执行，低于80%，标注建议复核，待用户确认后执行，比如，形成数据分析结论等；

• 必须请示：必须请示用户确定是否执行，比如，涉及金额或对外操作等。

坑4：输出格式没规定，每次不一样

AGENTS.md里写"输出结构化内容"、"格式要好"，等于没说。

让Agent做行业分析，每节内容都是表格+几行结论，每次都要我逐节重新写摘要、整理格式才能用。

后来，在AGENTS.md中给了模板和示例，Agent才输出我想要的内容：

"先亮一句话结论，再给100字摘要，然后用表格呈现数据，每条数据标注来源"，附一个真实输出样例。

一个示例胜过三段文字描述。

"你给的示例是什么样，Agent的输出就是什么样"，格式越具体，输出越稳定。

如果你的Agent负责写报告，就直接给一个报告骨架模板；负责做分析，就给一个分析维度表。

坑5：红线缺失，Agent好心办坏事

GitHub对2500多个仓库的分析发现，"永不提交密钥"是最高频出现的有效约束——说明红线是最被认可的必备内容。

你的Agent可能主动删文件、改配置、对外发消息——不是因为坏，是因为你没告诉她不能做。

安全边界不是建议，是铁律。

必须单独设一个"安全边界"章节，用三级边界法严格约束：

• 绝不做：不删文件、不改配置、不擅自对外发消息；

• 先确认再做：不可逆操作、对外发送消息、修改重要文件；

• 基本纪律：标注来源、交叉验证、不确定时明示"待核实"。

红线要具体，不要写"注意安全"，要写"不删除工作区内任何文件"。

对业务Agent来说，红线就是"不编造数据、不越权决策、不隐瞒不确定性"。

坑6：工具使用没指导，好工具被浪费

给Agent安装了Officecli、Wind Alice工具，但是没有在AGENTS.md中说明。

让她将md格式行业分析报告输出为word版，未调用Officecli工具，Agent自行生成word文件，出来的格式就是md文件的翻版，惨不忍睹。而调用Officecli工具，能输出接近标准版的word文件。

让她查询上市公司财务数据，Agent用搜索引擎查上市公司财务数据——搜出来的是二手信息，营收数据是上一期的。而调用Wind Alice工具，能拿到当期准确的财报数据。

Agent不是不会用工具，而是不知道什么时候该用哪个工具。

合适场景调用合适工具，不写进AGENTS.md，就等于你给员工配了专业设备但没告诉她什么时候用——她会拿锤子拧螺丝。

因此，要在AGENTS.md里写清楚：

• 生成docx、xlsx、pptx文件，调用Officecli工具；

• 查询金融数据，调用Wind Alice工具。

工具指导不是把工具说明书抄一遍，而是告诉Agent什么场景用什么工具、什么场景绝对不能用。

最佳实践与精简模板

根据踩坑经验，总结五条编写原则：

1. 手写为主，AI辅助润色——核心指令必须来自你的实战经验，AI帮你检查结构和语法可以，但别让AI决定写什么内容。
2. 只写Agent猜不到的——逐条自检：这行内容Agent能通过读文件、搜代码自己搞清楚吗？能就删掉。你独有的经验才是价值。
3. 示例胜过描述——一个真实的输入/输出示例，比三段抽象规则有效得多。
4. 具体强于笼统——"一句话结论+100字摘要+表格"比"输出结构化内容"有用。
5. 精简大于全面——研究建议150行以内，超过后推理成本反升20%以上，重点反而被稀释。

一个可直接套用的精简模板：

# AGENTS.md## 1. 核心使命你是[角色]，核心使命是[一句话]。## 2. 任务范围- 核心任务：[具体任务→触发条件→交付物]- 协助任务：[帮别人做但不主导]- 不做：[明确排除]## 3. 安全边界绝不做：[红线清单]先确认：[需请示的场景]基本纪律：[固定行为]## 4. 决策权限- 自主执行：[场景]- 标注执行：[场景+标注要求]- 必须请示：[场景]## 5. 输出规范[放一个真实输出示例]## 6. 工具使用- [场景A]→优先用[工具1]- [场景B]→优先用[工具2]## 7. 错误处理[异常类型]→[重试→降级→告知用户]## 8. 迭代日志- [日期] [改了什么] [为什么改]

模板使用建议：

• 初版建议：先填"核心使命"+"安全边界"+"决策权限"+"输出规范"四块，这四块决定80%的行为质量。先写最小可用版本，用起来之后再迭代。
• 迭代方法：Agent反复犯的错记下来，反推模板缺了什么，补上。每季度审查一次，删过时内容。
• 最好的AGENTS.md不是最全面的那个，是你真正会维护的那个。
• 从30行开始迭代，比从300行开始更容易坚持。