What AGENTS.md、SKILL.md 和 CLAUDE.md 各自的作用有何不同，以及如何在不浪费 Token 的情况下使用它们 https://t.co/knGdUUhdKs

上下文工程与理解 AGENTS.md、SKILLS.md 和 CLAUDE.md

悄悄驱动 LLM 世界的 .md 文件

如果你在 2026 年花过任何时间使用 AI 编程智能体进行开发，你可能会注意到一个奇怪的现象：每个工具都想要一个位于仓库根目录的专属 Markdown 文件。CLAUDE.md、AGENTS.md、SKILL.md、.cursorrules、.windsurfrules、copilot-instructions.md。这看起来像是杂乱无章，但每一个文件都解决了一个实际问题，理解它们之间的差异将帮你避免以五种不同方式重复维护上下文。

这些文件之所以存在，是因为 LLM 智能体并不像人类队友那样了解你的代码库。新工程师会阅读你的 README、问几个问题，并在潜移默化中掌握约定。而智能体完全没有这些。它每次启动会话时都需要明确写出的上下文，而 Markdown 成为自然选择，因为它是纯文本、可 diff、并且人类和模型都能阅读。

AGENTS.md：通用上下文文件

AGENTS.md 已成为业界最接近共享标准的存在。它现在归属于 Agentic AI Foundation，也就是负责监管 MCP 的同一个治理模型，并且被超过六万个仓库中的三十多种不同智能体工具读取。其理念很简单：每个仓库一个权威文件，包含构建命令、测试命令、代码风格，以及智能体必须遵守的约束。

AGENTS.md 的趣味在于其背后关于如何写好它的研究。工具厂商今年引用的研究发现，架构概览对智能体几乎没有什么帮助，而精确的命令、版本约束和明确的“完成”标准则能显著减少错误。像“尽可能”或“确保全面覆盖”这类模糊指令会被忽略，因为智能体需要的是操作策略，而不是为人类写的散文式描述。

还有一个值得牢记的警示性发现：让 LLM 为你生成 AGENTS.md 文件往往会适得其反。今年早些时候的研究表明，生成的文件降低了任务成功率并增加了成本，主要是因为它们重复了智能体已能从仓库本身推断出的信息。一份简短、人工编辑的文件胜过长篇、AI 撰写的文件。

SKILL.md：能力，而非项目上下文

如果说 AGENTS.md 描述的是项目，那么 SKILL.md 描述的就是能力。技能（skill）是一个包含 SKILL.md 文件以及可选脚本、参考资料和资源的文件夹，其设计目标是在 Claude Code、Codex、Copilot 和其他兼容智能体之间可移植。

精妙之处在于渐进式披露。会话开始时，智能体只从 YAML frontmatter 中读取技能的名称和描述。只有当任务实际匹配该技能领域时，它才会加载完整正文，而补充脚本或参考文档则会更晚加载。这样能让智能体的上下文窗口保持精简，而不是把所有可能用不到的指令一股脑地提前塞进去。

对于维护可复用提示词或工作流库的人来说，这是比把所有东西都塞进一个庞大 AGENTS.md 更自然的归宿。这也解释了为什么像 skills.sh 这样的市场会火起来，因为技能就是一个包含 Markdown 的文件夹，发布和安装都极其简单。

CLAUDE.md 与各工具专属文件

CLAUDE.md、.cursorrules、.windsurfrules 和 copilot-instructions.md 是 AGENTS.md 的工具专属同类文件。在行业达成共享标准之前，每个编辑器或智能体都发明了自己的约定，而其中大多数至今仍被保留，以提供向后兼容。

实践中出现的可行模式——如果你的团队维护多种工具，值得采纳——是把 AGENTS.md 作为单一事实来源，并从中生成工具专属文件。这可以避免那种更新了一个文件却忘了其他四个的典型故障模式，否则就悄悄重新引入了这些文件本应防止的上下文漂移。

DESIGN.md 与值得关注的新进入者

一些更专门的格式也开始与这些文件一起出现。例如，DESIGN.md 用于编码项目的视觉识别系统，将机器可读的设计令牌与人类可读的设计理由结合起来，这样生成 UI 代码的智能体不仅理解颜色值，还理解为什么选择这些颜色。这还处于早期阶段，但它预示着这种模式的发展方向：面向特定上下文切片的小而专的 Markdown 文件，而不是一个文件试图包揽一切。

上下文工程：这些文件存在的真正原因

这一切其实与 Markdown 无关。关键在于，智能体的可靠性在很大程度上取决于它所获得上下文的质量，而 Markdown 恰好是每个人都能接受的最小摩擦格式。这些文件的适用范围各不相同：AGENTS.md 覆盖项目，SKILL.md 覆盖能力，而工具专属文件则主要为了兼容性而存在。

在新奇表象之下，你编写这些文件时实际上是在做上下文工程。这是一种决定 LLM 看到什么、何时看到、以何种形式看到的实践，目的是让它能够出色地行动，而不把 Token 浪费在它不需要的东西上。把下面每一个文件都视为实现这一目标的杠杆，而不是你的工具所期待的一种形式。

如何使用 AGENTS.md 和 SKILL.md 文件？

从 AGENTS.md 开始，但要克制让它面面俱到的冲动。这个文件中的每一句话都会在每次会话时被读取，因此这是纯粹重复发生的 Token 成本。写下精确的命令，而不是散文式描述；说明约束，而不是解释架构；删除任何智能体可以从仓库本身推断出的内容，因为研究表明这些部分不会改善结果，只会增加开销。

几个具体做法能带来可衡量的改变。

• 将“适当地运行测试”替换为确切的命令和标志，这样智能体就不会浪费一轮去发现它

• 删掉任何“架构概览”部分，只保留非标准模式和智能体不应触碰的文件

• 为常见任务添加明确的“完成”标准，因为正是歧义导致智能体过度探索和重读文件

• 绝不要让智能体在没有监督的情况下生成这个文件；之后亲自编辑或大力删减

当你的 AGENTS.md 开始积累只适用于特定任务的能力专属指令时（例如部署步骤或某个小众内部 API），再转向 SKILL.md。这时渐进式披露才真正为你的 Token 预算发挥作用。

智能体在会话开始时只支付 frontmatter 描述的成本，只有当任务实际匹配时才会加载完整技能正文，因此十个未被使用的技能几乎不会让你付出任何代价。

在实际获得这种好处时，要让技能描述保持精炼且足够具体，以便智能体无需打开文件就能正确匹配它们。因为模糊的描述会迫使它为了检查相关性而加载正文，这反而违背了目的。

将 SKILL.md 保留给偶尔调用的能力，而不是每个会话都需要的约束——这些约束应该放在 AGENTS.md 中。

对于工具专属文件——CLAUDE.md、.cursorrules、.windsurfrules 和 copilot-instructions.md——完全不要再手写。将 AGENTS.md 维护为单一事实来源，并用一个简短的同步脚本从中生成其他文件。

这主要不是 Token 优化，而是正确性优化，因为相互差异的文件会悄悄重新引入这些文件本要消除的歧义。

最后，像对待代码一样对待所有这些文件。在与它们所描述变更相同的 Pull Request 中审阅它们，在内容不再真实的那一刻删除过时部分，并定期审计是否已有内容迁移到代码库本身而不再需要重述。一份精简、准确且每次都能被正确读取的文件，将胜过一份详尽却被跳过、忽略或与周围代码相互矛盾的文件。

在 2026 年真正从这些文件中获得价值的团队，并非那些 AGENTS.md 最详细的团队，而是那些将上下文工程视为持续纪律的团队：每个文件要么在 Token 预算中赢得自己的位置，要么被裁掉。