AI 协议：从“萌新”蜕变为“打工人”！

2022 年 11 月 30 日，ChatGPT 问世，AI 大幕就此拉开，开始了爆炸式增长。短短一个技术代际里，模型就从“会聊天的新人”成长为“能交付的工程师”：底层能力就像个人的学识，而真正让其稳定、可控、可协作的，则是围绕它建立的规则与约束。回望这段演化，你会发现它与职场成长极其相似——两三年打磨底蕴，再用流程与制度把能力沉到生产线上。

从我的观察来看，AI 从工具到同事的华丽转身，离不开各种协议，比如：llms.txt^[1] 让模型读得准、少走弯路，AGENTS.md^[2] 让它在代码仓库里按规办事，MCP^[3] 则把它与外部工具和数据稳稳接起来（在 MCP 上层还有个 A2A）。

相关阅读：

• 深度解析：Anthropic MCP 协议
• 浅谈 Agent、MCP、OpenAI Responses API
• Google A2A：多智能体通信协议
• AI 进阶：从 Vibe coding 到职场必备
• 深度理解：提示词工程
• LLM 高效沟通指南

背景

如果大家经常使用各种 AI coding 工具，那你的系统大概率也是像帖子吐槽的那样，充满了各种 .xxx 配置文件。而 AGENTS.md 就是在该背景下诞生的，试图建立统一的规范来管理日益复杂的、割裂的配置数据。

如果 AGENTS.md 标准能得到社区积极响应，那它的影响力不亚于 MCP。我这样认为的理由：如果说 MCP 是针对大模型的，那 AGENTS.md 就是针对本机操作系统的。

所以，我想写篇文章来简单聊聊 AGENTS.md，但稍微整理思路后，发现把 llms.txt、MCP 之类的协议串起来，似乎更完整，于是就有了这篇文章。

内容摘要

目前，AI 行业似乎正在构建一个分层的开放标准技术栈（协议），以管理和协调日益复杂的智能体系统。更赤裸点说，都在抢夺制定标准的话语权，从 Anthropic MCP 到 Google A2A 再到 OpenAI AGENTS.md，皆是如此。这些标准出身虽有不同，但并非竞争关系，共同构成了更大的智能体生态。本文主要对 llms.txt、AGENTS.md 和模型上下文协议（Model Context Protocol, MCP）进行分析讨论。之所以选这几个协议作为代表，是因为在我看来，它们层层递进且能力互补：

• llms.txt：作为基础的数据层，扮演着 “AI 站点地图”角色。它为 LLM 提供了一种标准化的方式，使其能够在推理时（inference time）被动地读取和理解网站的结构化、精炼内容，从而有效解决了上下文窗口限制和网络信息“噪声”问题。
• AGENTS.md：作为开发环境层，充当了 “AI 编码智能体的入职指南”。它为 AI 智能体在特定代码库中工作提供了本地化的、明确的指令，涵盖了构建、测试、代码风格等关键开发流程，从而将机器可读的指令与面向人类的 README.md 文件清晰地分离开来。
• MCP：模型上下文协议作为动态交互层，是这个新兴生态系统中最具变革性的部分，堪称 “AI 的通用 API 层”。它为 AI 系统与外部工具、数据源和服务之间建立实时、双向的通信提供了一个开放标准，从根本上解决了工具集成的 “N×M” 碎片化难题。
• ...

MCP 已获得包括其主要竞争对手在内的全行业范围的采纳。这一现象标志着一项重大的行业战略决策：将工具使用层（tool-use layer）商品化。通过在工具集成层面达成共识，各大 AI 实验室将主要的竞争战场转移到了更具防御性的领域——即底层 AI 模型的性能、安全性和建立在这些开放标准之上的专有智能体编排框架。

llms.txt

llms.txt 协议的出现，标志着为 AI 系统提供精炼、可信上下文的首次大规模标准化尝试。它构成了智能体交互栈的基础层——一个旨在优化信息检索、提升推理质量的只读信息层。

起源与动因：解决“上下文窗口问题”

llms.txt 标准于 2024 年 9 月由 Answer.AI^[4] 的联合创始人 Jeremy Howard 首次提出，其核心目标是解决大型语言模型的一个根本性限制：有限的上下文窗口无法完整处理结构复杂的现代网站。传统的网站充满了导航栏、广告、JavaScript 脚本等元素，将这些复杂的 HTML 页面转换为对 LLM 友好的纯文本，不仅过程困难，而且结果往往充满“噪声”，极大地浪费了宝贵的 token 资源。

llms.txt 的设计理念是提供一条直达核心内容的捷径。它与现有的网络标准有着明确的功能区分：

• 它不同于 robots.txt，后者的目的是限制爬虫的访问范围。
• 它也不同于 sitemap.xml，后者仅罗列 URL 列表，缺乏内容的上下文信息。

llms.txt 的独特价值在于，它主动地为 LLM 暴露结构化、有意义的内容，使其成为一个专为 AI 设计的“内容入口”。

技术规范与生态系统

llms.txt 的规范以简洁和实用为核心原则，确保了其易于实施和采纳。

• 格式 & 结构：该标准定义了一个简单的 Markdown 文件，通常托管在网站的根目录 (/llms.txt) 下。其结构既方便人类阅读，也易于程序化解析，通常包含一个一级标题（H1）作为网站名称，一段块引用（blockquote）作为简短摘要，以及多个二级标题（H2）下的链接列表，用于指向更详细的内容页面。
• 变体 & 扩展：
• llms-full.txt：作为 llms.txt 的一个重要补充，这个文件将网站的所有文本内容整合到一个单一的 Markdown 文件中。这一概念是与 Anthropic 合作开发的，旨在让 AI 工具通过访问一个 URL 就能加载整个网站的上下文，极大地简化了信息获取流程（比如 MCP 文档就支持 mcp/llms-full.txt^[5]）。
• .md 页面：该标准还提议，网站应为其主要内容页面提供一个附加 .md 后缀的纯净 Markdown 版本，以便 AI 可以直接访问无干扰的内容（比如 /path/index.html 同级目录下应该有个对应的 /path/index.html.md 文件）。
• 采纳 & 工具：llms.txt 的迅速普及，很大程度上得益于关键参与者的推动。2024 年 11 月，知名的文档平台 Mintlify 宣布为其托管的所有文档站点自动生成 llms.txt 文件（Simplifying docs for AI with /llms.txt^[6]），这引发了多米诺骨牌效应。一夜之间，像 Pinecone^[7]、Anthropic^[8] 和 Cursor^[9] 这样的公司都通过 Mintlify 拥有了符合该标准的文档，极大地提升了其可见度和实用性。随后，一个充满活力的生态系统迅速形成，涌现出大量用于生成和发现 llms.txt 文件的工具（如 FireCrawl^[10]、Markdowner^[11]、WordPress 插件^[12]）和由社区维护的网站目录（如 llmstxt.directory^[13] 和 llmstxthub.com^[14]）。

以下是 llms.txt 内容示例：

# FastHTML

> FastHTML is a python library which brings together Starlette, Uvicorn, HTMX, and fastcore's `FT` "FastTags" into a library for creating server-rendered hypermedia applications.

Important notes:

- Although parts of its API are inspired by FastAPI, it is *not* compatible with FastAPI syntax and is not targeted at creating API services
- FastHTML is compatible with JS-native web components and any vanilla JS library, but not with React, Vue, or Svelte.

## Docs

- [FastHTML quick start](https://fastht.ml/docs/tutorials/quickstart_for_web_devs.html.md): A brief overview of many FastHTML features
- [HTMX reference](https://github.com/bigskysoftware/htmx/blob/master/www/content/reference.md): Brief description of all HTMX attributes, CSS classes, headers, events, extensions, js lib methods, and config options

## Examples

- [Todo list application](https://github.com/AnswerDotAI/fasthtml/blob/main/examples/adv_app.py): Detailed walk-thru of a complete CRUD app in FastHTML showing idiomatic use of FastHTML and HTMX patterns.

## Optional

- [Starlette full documentation](https://gist.githubusercontent.com/jph00/809e4a4808d4510be0e3dc9565e9cbd3/raw/9b717589ca44cedc8aaf00b2b8cacef922964c0f/starlette-sml.md): A subset of the Starlette documentation useful for FastHTML development.

小结

首先，llms.txt 不仅仅是一个技术文件，它标志着一个 “为 AI 设计的语义网” 的开端。它代表了网站所有者首次广泛且成功地尝试为机器消费而明确地结构化其内容，而不仅仅是为了人类的视觉呈现或传统的搜索引擎排名。其背后的逻辑链条是：

• LLM 难以处理网络的“表示层”（HTML、CSS、JS）。
• llms.txt 提供了一个直接访问“内容层”的通道，并以干净、机器可读的 Markdown 格式呈现。
• 这种为 AI 进行显式标注的行为，本质上是一种语义标记，其精神内核与早期的“语义网”概念相似，但实现方式更为简洁和务实。
• llms.txt 的普及标志着 Web 开发理念的转变：未来的网站需要为人类和 AI 智能体这两种截然不同的受众进行双重设计。

llms.txt 由社区驱动的快速采纳，展示了 AI 标准化进程中一股强大的自下而上的力量。与企业自上而下的强制推行不同，它的成功源于一个清晰且紧迫的开发者需求（提升 RAG 和智能体性能），以及极低的实施成本。这预示着，未来具备相似特征（解决真问题、易于实施）的开放标准，更有可能在激烈的市场竞争中脱颖而出。

AGENTS.md

如果说 llms.txt 是为 AI 访问外部世界信息制定的规则，那么 AGENTS.md 则是为 AI 在开发者的“内部世界”——即本地代码库中工作而设计的行为准则。它在智能体交互栈中扮演着本地指令层的角色。

智能体 README：起源与必要性

AGENTS.md 是一个开放格式，其设计初衷是成为“智能体的 README”，为 AI 编码智能体提供一个专门且可预测的指令来源。它的诞生源于 AI 软件开发生态系统内部的协作努力，主要贡献者包括 OpenAI Codex、Amp、Cursor 和 Google 等早期探索者。

它的核心必要性在于关注点分离（Separation of Concerns）。传统的 README.md 文件主要面向人类贡献者，解释项目的目的、安装方法和使用指南。而 AGENTS.md 则包含了对 AI 智能体至关重要但对人类开发者可能显得冗余的技术细节，例如：

• 精确的构建命令 (pnpm install, pnpm build)
• 详细的测试指令 (pnpm test -- --watchAll=false)
• 严格的代码风格指南（使用单引号、无分号）
• 特定的提交流程（PR 标题格式）

将这些机器导向的指令放入一个专门的文件中，既能让 AI 智能体获得清晰、无歧义的指导，又能保持 README.md 对人类的简洁性和可读性，避免其因充斥着大量机器指令而变得臃肿不堪。

规范与层级优先级

AGENTS.md 标准的设计刻意追求简洁性，以促进其广泛采纳。

• 格式：该标准不强制规定任何特定的内部格式或标题，而是采用标准的 Markdown 语法。其价值在于标准化的文件名（AGENTS.md），而非一个僵化的内部模式。智能体只需解析其中的文本内容即可。
• 位置与层级结构：文件通常放置在代码库的根目录。至关重要的是，该标准支持层级结构，尤其适用于大型单体仓库（monorepos）。开发者可以在子项目或包内嵌套 AGENTS.md 文件。协议为此定义了一个清晰的优先级规则：“距离被编辑文件最近的 AGENTS.md 文件生效”。这意味着子目录中的指令会覆盖或补充根目录的通用指令，从而实现对不同模块的精细化指导。例如，OpenAI 的主代码库中包含了多达 88 个独立的 AGENTS.md 文件，这充分证明了其对这种层级化指令结构的深度依赖。

以下是 AGENTS.md 的内容示例：

# Sample AGENTS.md file

## Dev environment tips
- Use `pnpm dlx turbo run where <project_name>` to jump to a package instead of scanning with `ls`.
- Run `pnpm install --filter <project_name>` to add the package to your workspace so Vite, ESLint, and TypeScript can see it.
- Use `pnpm create vite@latest <project_name> -- --template react-ts` to spin up a new React + Vite package with TypeScript checks ready.
- Check the name field inside each package's package.json to confirm the right name—skip the top-level one.

## Testing instructions
- Find the CI plan in the .github/workflows folder.
- Run `pnpm turbo run test --filter <project_name>` to run every check defined for that package.
- From the package root you can just call `pnpm test`. The commit should pass all tests before you merge.
- To focus on one step, add the Vitest pattern: `pnpm vitest run -t "<test name>"`.
- Fix any test or type errors until the whole suite is green.
- After moving files or changing imports, run `pnpm lint --filter <project_name>` to be sure ESLint and TypeScript rules still pass.
- Add or update tests for the code you change, even if nobody asked.

## PR instructions
- Title format: [<project_name>] <Title>
- Always run `pnpm lint` and `pnpm test` before committing.

社区论述：在争论中诞生的标准

AI IDE 的混乱配置从 Cursor 决定 fork VS Code 的那一刻就被注定了。其实早在 AI 编辑器出现之前，应用也存在各种 .xxx 配置目录，但它们基本都是针对自身的个性化设置（没人会感觉混乱）。但 AI IDE 所产生的 agent 配置有点像是差异化里出现了相似性（mcp、prompt 之类的东西大同小异），而程序员又是喜欢抽象的群体（一个东西出现两次以上就该提取了），于是大家就开始各种抱怨，尤其是需要同时使用多种 ai coding 工具的。

既然有抱怨，那就是痛点，急需一个可以统一各种应用的配置标准（话语权）。之前 OpenAI 没能抓住 MCP，让 Anthropic 捷足先登了，这次不想错过新一轮话语权，就搞了个 AGENTS 规范。这里还有个小插曲，AGENTS.md 和 AGENT.md 是两个不同的域名，感兴趣的朋友自行了解（相关阅读：A comprehensive list of Agent-rule files: do we need a standard?^[15]）。不过现在 agent.md 域名已经重定向至 agents.md，估计是没啥分歧了。

还有些 issues 讨论，我找了两条有代表性的，从配置混乱到命名混乱，把开发者都搞崩溃了（AGENTS.md thought leadership^[16]、AGENT.md vs AGENTS.md^[17]）。

小结

目前来看，它会成为下一个类似于 MCP 一样标准，用来规范 Vibe Coding：即当前一代的 AI 智能体在开发工作流中扮演着“初级开发者”的角色，需要明确的、机器友好的入职培训。

一名经验丰富的人类开发者可以通过阅读 README、package.json 和浏览代码，自行推断出项目的配置和工作流程。然而，目前的 AI 智能体虽然在执行层面能力强大，但在这种高级别的推理和上下文理解方面仍有欠缺，它们更依赖于明确的指令（例如，“运行 pnpm test 来验证你的修改”）。   AGENTS.md 正是为这位“初级 AI 开发者”量身定制的书面“入职文档”，详细告知了项目的特定规则和操作流程。因此，该标准的必要性直接反映了当前智能体技术的能力现状——执行力强，但需要明确的引导来处理项目特有的上下文和工作流。

MCP

之前写文章介绍过 MCP 了，这次还想把再次介绍一下（它真的重要）。模型上下文协议（Model Context Protocol, MCP）是迄今为止在新兴 AI 标准化浪潮中影响最深远、采纳最广泛的规范。它定义了智能体与外部世界进行动态、双向交互的规则，构成了智能体技术栈中至关重要的交互层。

AI 的 USB 端口：起源与目标

MCP 由 Anthropic 公司于 2024 年 11 月推出，并作为一项开放标准，旨在统一 AI 系统与外部工具、系统和数据源的连接方式。

其诞生的核心动机是为了解决所谓的 “N×M 数据集成问题”。在 MCP 出现之前，每个 AI 模型（N）都需要为每个外部工具（M）开发一个定制的连接器，这导致了系统架构的碎片化、开发效率低下且难以扩展。

用一个生动比喻来解释 MCP 的作用：它就像是 “AI 的 USB 端口”。正如 USB-C 接口为各种设备提供了通用的连接方式，MCP 也为任何 AI 助手接入任何数据源或服务提供了统一的接口，无需为每个组合编写定制代码。在设计理念上，MCP 从语言服务器协议（Language Server Protocol, LSP）中汲取了灵感，LSP 成功地标准化了代码编辑器与特定编程语言工具之间的交互。

架构深度解析

MCP 构建在一个稳健且可扩展的技术基础之上，其核心组件设计清晰。

模型

MCP 采用客户端-服务器（Client-Server）架构，并基于 JSON-RPC 2.0 协议进行通信。“主机”（Host，如 Claude 桌面应用或一个 IDE）连接到“服务器”（Server，如一个 GitHub 工具连接器或数据库接口）。

传输层

协议明确规定了两种标准的传输方式：

• stdio（标准输入/输出）：用于本地连接，即服务器与客户端运行在同一环境中。
• HTTP+SSE（服务器发送事件）：用于远程连接，支持流式数据传输。

核心原语

协议定义了一套核心的消息类型（Primitives），构成其功能的基石：

• 服务器端提供给 AI 的能力：
• Resources（资源）：结构化的数据，用于丰富模型的上下文（如文件片段、代码块）。
• Prompts（提示）：预设的指令或模板，用于引导模型。
• Tools（工具）：模型可以调用的可执行函数或动作（如数据库查询、发送消息）。
• 客户端提供给服务器的能力：
• Roots（根路径）：允许服务器访问本地文件系统的特定入口点。
• Sampling（采样）：允许服务器请求主机端的 AI 模型生成一段文本。这是一个高级功能，能够实现复杂的、递归的推理循环。
• Elicitation（引出）：允许服务器主动向用户请求额外信息。

行业影响力

MCP 的采纳速度和广度是现象级的，标志着 AI 互操作性领域的一个关键转折点。它迅速从一个由单一公司提出的标准，演变为全行业共同遵循的规范。

• 初步发布（2024 年 11 月）：Anthropic 将 MCP 作为开放标准发布，并提供了多种语言的 SDK 和参考服务器实现（如 GitHub、Slack、Postgres），获得了 Block、Replit 和 Sourcegraph 等早期技术领导者的支持。
• OpenAI 的采纳（2025 年 3 月）：作为 Anthropic 的主要竞争对手，OpenAI 宣布在其核心产品中全面采用 MCP，包括 ChatGPT 桌面应用和其 Agents SDK。此举被视为一个重大的战略信号，其 CEO Sam Altman 将其描述为迈向标准化 AI 工具连接的重要一步。
• Google 的采纳（2025 年 4-5 月）：Google DeepMind 的 CEO Demis Hassabis 确认将在 Gemini 模型中支持 MCP，并称其为“正在迅速成为 AI 智能体时代的开放标准”。随后，在 Google I/O 2025 大会上，Google 正式宣布为 Gemini API 提供原生的 MCP SDK 支持。
• Microsoft 的采纳（2025 年 5-6 月）：微软在其 Copilot Studio 和 Visual Studio 的智能体模式中发布了对 MCP 的原生支持，将 MCP 定位为其连接外部知识库和 API 的默认桥梁。
• ...

安全考量与挑战

MCP 的强大能力也带来了严峻的安全风险。2025 年 4 月，安全研究人员发布分析报告，指出了多个潜在的安全问题，包括：

• 提示注入（Prompt Injection）：恶意用户可能通过构造特定的输入来劫持智能体的行为。
• 工具权限升级：多个看似无害的工具组合在一起，可能会导致权限升级，从而泄露敏感文件。
• 工具伪装：攻击者可能创建外观相似的恶意工具来欺骗用户，替代受信任的工具。
• ...

MCP 的官方规范将安全责任主要放在了协议的实现方（即“主机”应用）身上，强调必须为所有数据访问、工具执行和 LLM 采样请求获得用户的明确同意，并提供清晰的控制界面。

小结

MCP 的出现和普及，对 AI 智能体的发展具有深远的战略意义，它与 llms.txt、AGENTS.md 在本质上是不同的。它提供的不是静态的上下文，而是一种动态、有状态、可交互的能力。它将智能体从一个在固定上下文上进行被动推理的系统，转变为一个能够主动参与数字生态系统并与之互动的实体。

• llms.txt 提供的是一份静态文档，智能体一次性读取。
• AGENTS.md 提供的是静态的任务指令，智能体按部就班地遵循。
• MCP 提供的是一个与“工具”的实时连接。智能体可以调用这个工具，接收结果，并根据结果决定下一步的行动，从而形成一个反馈循环。

像 Sampling 这样的高级功能甚至允许工具服务器反过来请求智能体“思考”某个问题，从而构建一个双向的推理回路。因此，MCP 真正实现了智能体的行为（行动与反应），而另外两个标准主要实现的是智能体的理解（阅读与遵循）。

MCP 被包括其主要竞争对手（Anthropic、OpenAI、Google、Microsoft）在内的全行业迅速且普遍地采纳，是一个意义深远的战略事件。它表明行业巨头之间达成了一项心照不宣的共识：将 AI 技术栈中的工具集成层进行商品化。

构建和维护一个专有的工具集成生态系统成本高昂，且会给开发者带来巨大的摩擦（即 N×M 问题）。   通过共同认可一个统一的“插座”（MCP），各大 AI 实验室消除了在这一领域的竞争优势。没有哪家公司能够再通过拥有更多的专有集成来取胜。

这一战略决策，将竞争的焦点转移到了它们能够真正控制和建立壁垒的层面：a) 其核心 LLM 的质量、成本和安全性；b) 其专有智能体编排框架（如 OpenAI Agents SDK）的强大功能和易用性，而这些框架本身也使用 MCP。

因此，采纳 MCP 是一种在某个竞争领域“停火”的策略，以便将资源集中到更具防御性的护城河上。这是典型的“竞合”（co-opetition）策略，旨在共同做大整个智能体 AI 市场的蛋糕。

结语

如果说这些协议、标准都是书面的、形式化的理论。那 AI 代码编辑器绝对是这些标准落地的前沿阵地，比如 Cursor、Windsurf、Cline、 Zed、Warp 等开发者工具，很早都支持了 MCP，为该协议早期生态贡献了巨大力量。

本文对 llms.txt、AGENTS.md 和 MCP 的讨论，似乎也揭示了 AI 行业正在走向一个更加结构化和标准化的未来。然而，这三个协议标准也只是冰山一角。将它们置于更广阔的协议图景中，一个清晰的、分层的智能体 AI 架构正浮出水面。

• 第一层 (数据溯源层 - Data Grounding):
• 协议: llms.txt
• 模型: 被动，只读
• 作用: 为智能体提供关于外部世界（网站、文档）的静态、可信的上下文信息。
• 第二层 (本地指令层 - Local Instruction):
• 协议: AGENTS.md
• 模型: 指令式，只读
• 作用: 为智能体在特定开发环境（代码库）中执行任务提供明确的、本地化的操作指南。
• 第三层 (服务交互层 - Service Interaction):
• 协议: Model Context Protocol (MCP)
• 模型: 主动，交互式
• 作用: 为智能体提供一个标准的接口，使其能够与外部工具和服务进行动态、有状态的实时通信。
• 第四层 (智能体协作层 - Agent Collaboration):
• 协议: Agent2Agent (A2A)
• 模型: 协作式，交互式
• 作用: 定义智能体之间进行通信、协商和任务分配的规则，使多智能体系统成为可能。
• （未来可能还会产生新协议）...

随着生态系统的成熟，我们可以预见将会有更多、更复杂的标准出现。当行业从单个智能体执行任务，迈向由多个智能体协作解决复杂问题的阶段时，围绕智能体安全、身份认证、分布式规划和资源协调等领域的标准化将成为新的焦点。这个由开放标准驱动的智能体新时代，才刚刚拉开序幕。

References