1. 项目概述：一个IETF草案的“退休”与它所留下的空白

今天早上，一个名为 agents.txt 的IETF草案正式过期了。如果你是一位网站运维者、API开发者，或者正在构建与AI智能体交互的服务，你可能在某个技术博客或讨论区瞥见过这个名字。简单来说， agents.txt 是一个受经典 robots.txt 协议启发的提案，旨在为网站提供一个标准化的方式，告诉自动化的AI智能体：“我这里允许哪些‘访客’，它们可以访问哪些特定的内容端点，以及我提供了哪些能力。” 它的核心愿景是解决一个日益迫切的问题：在AI智能体（如自动化的内容摘要工具、数据分析机器人、客户服务助手等）不再仅仅通过传统网页爬虫方式工作的时代，如何让它们更优雅、更高效地“发现”并理解一个站点能提供什么服务，而不是去暴力地解析整个HTML结构。

这个草案的生命周期定格在了2026年4月10日，没有后续修订版本提交，按照IETF的规则，它自然“退休”了。这听起来像是一个技术标准演进中微不足道的注脚，但背后折射出的，是整个“AI智能体生态”在基础设施层面临的真实挑战：我们如何让机器与机器之间，特别是具备一定自主性的AI智能体与网络服务之间，实现有效的、标准化的“初次握手”？ agents.txt 的尝试失败了，但问题依然存在，甚至更加凸显。接下来，我将结合自己的观察和实践，为你拆解这个草案的来龙去脉，分析当前生态中的替代方案，并给出作为一线从业者，在当前这个“标准真空期”的实际操作建议。

2. agents.txt 草案的核心设计思路与局限

2.1 设计哲学：极简主义的服务发现

agents.txt 的设计理念非常直接，甚至可以说是“复古”的。它提议网站运营者在站点的 /.well-known/agents.txt 路径下放置一个纯文本文件。这个文件的结构模仿了 robots.txt 的简洁性，但内容针对AI智能体进行了定制。其核心字段通常包括：

• User-Agent ： 声明允许访问的智能体标识符（例如， ChatGPT-Explorer , Claude-Web-Reader ）。
• Allow / Disallow ： 指定该智能体可以或不可以访问的URL路径模式，这与 robots.txt 一致，用于基本的访问控制。
• Endpoint ： 这是其创新点，用于指向专为智能体优化的结构化数据接口，例如一个返回JSON-LD的API端点、一个GraphQL接口，或一个专门的RSS/Atom订阅源。理想情况下，智能体应优先访问这些端点，而非爬取普通网页。
• Capability ： 声明站点暴露的能力，例如 summary （提供摘要）、 search （提供搜索API）、 transaction （支持事务处理）等。

它的核心价值在于“发现”（Discovery）。一个智能体来到你的域名，它首先检查 /.well-known/agents.txt ，就像人类查看网站地图或导航栏一样，立刻知道从哪里能高效获取所需的结构化信息，以及自己被允许做什么。这减少了不必要的页面加载、HTML解析和试探性请求，降低了服务器负载，也提升了智能体工作的准确性和效率。

2.2 为何它最终“过期”：理想与现实的差距

尽管想法直观，但 agents.txt 草案在IETF的标准化道路上并未走远。根据草案作者的公开讨论和邮件列表记录，其“天折”背后有几个关键原因：

1. 身份验证与信任的缺失 ： 这是最致命的短板。草案没有定义任何形式的智能体身份验证机制。一个恶意的爬虫可以轻易地伪装成 User-Agent: ChatGPT-Explorer 来访问本应为友好智能体准备的 Endpoint 。在缺乏密码学签名或令牌验证的情况下， Allow/Disallow 规则形同虚设。IETF内部关于是使用增强的User-Agent字符串还是采用签名清单（Signed Manifest）作为身份基元的争论持续了很久，未能达成共识。
2. 工作组未能成形 ： IETF标准通常由活跃的工作组（WG）推动。 agents.txt 作为个人提交的草案，虽然引起了一些关注，但始终未能凝聚起一个足够活跃、有共同推进意愿的工作组。没有持续的动力去解决上述安全模型、语法细节扩展等硬骨头。
3. 范围模糊与竞争 ： “AI智能体”本身就是一个宽泛的概念。 agents.txt 试图为从简单的RSS阅读器到复杂的多步推理代理等一切事物提供一个通用的发现层，这导致其设计在简单性和表达能力之间难以取舍。与此同时，更垂直、更具体的方案（如专注于LLM的 llms.txt ，或专注于工具调用的 MCP ）开始出现，分流了社区的注意力和实践需求。

注意 ：草案的“过期”并不意味着使用该格式的文件会立即失效。它仅代表该提案未能在IETF进程内继续推进成为正式的标准（RFC）。已经部署了 agents.txt 文件的站点，只要还有客户端在读取，它就仍然有效。标准世界的“死亡”和实际部署的“下线”是两回事。

3. 后 agents.txt 时代的替代方案全景图

随着 agents.txt 草案的停滞，生态中其他几种方案正在填补不同层面的空白。它们并非直接的替代品，而是针对不同问题域的解决方案。理解它们的定位至关重要。

3.1 llms.txt ：面向大语言模型的文档站点指南

• 主导方 ： 主要由Anthropic等公司及其社区推动。
• 核心定位 ： 非常具体和垂直。它主要服务于 文档网站 ，旨在告诉LLM驱动的工具（如代码助手、文档问答机器人）如何更好地理解和导航你的文档站。它的内容更偏向于“指引”，例如指定站点的搜索API端点、标识出哪些页面是API参考、哪些是教程，或者声明支持的代码仓库链接。
• 优点 ： 目标明确，解决的是LLM在消化文档内容时的具体痛点。部署简单，就是一个文本文件。在技术文档社区中正获得缓慢但稳定的采用。
• 缺点 ： 范围狭窄，不适用于非文档类网站或更广义的智能体交互场景。它不解决身份验证或通用服务发现的问题。

3.2 MCP（Model Context Protocol）服务清单：动态能力协商

• 核心概念 ： MCP是另一种范式。它不是一个静态的发现文件，而是一个 动态的服务器-客户端握手协议 。一个MCP服务器会向连接的客户端（如Claude Desktop）宣告它“能做什么”（即提供哪些工具或数据源），并以标准化的方式暴露这些能力的调用接口。
• 核心定位 ： 解决“ 这个服务能做什么 ”以及“ 如何调用 ”的问题，属于交互层。例如，一个数据库MCP服务器可以告诉客户端：“我可以执行SQL查询”，并提供一个标准的调用方法。
• 优点 ： 动态、强大、可扩展。支持复杂的工具调用和实时数据交互。是构建本地或远程AI工具生态的强力框架。
• 缺点 ： 它不解决“ 这个服务在哪里 ”的初始发现问题。客户端需要预先知道MCP服务器的地址（主机和端口）才能连接。它和 agents.txt 或 llms.txt 不在一个层面，更像是它们的下游：你先通过某种方式发现了一个服务，然后通过MCP与它深度交互。

3.3 A2A（Agent-to-Agent）与Web Bot Auth：通信与身份层

• A2A草案 ： 由Google推动，关注的是智能体 之间 如何安全、可靠地传递消息。它假设智能体已经彼此发现并建立了连接，解决的是交互过程中的信封格式、路由和保证送达等问题。
• Web Bot Auth及相关IETF草案 ： 这可能是最接近填补 agents.txt 安全空白的努力。这些提案专注于为自动化流量（机器人、智能体）建立密码学身份验证机制，例如使用数字签名来证明“我是谁”。这解决了 agents.txt 未能解决的信任根源问题。
• 关系 ： 你可以将它们视为智能体栈的不同层级。 agents.txt 想做的是“发现层”，Web Bot Auth是“身份层”，A2A是“通信层”。一个完整的生态可能需要所有这些层的组合。

下面的表格对比了这些方案的关键维度：

特性	agents.txt (已过期草案)	llms.txt	MCP 服务器	Web Bot Auth / 签名智能体草案
核心目标	通用服务发现 ：告诉智能体“这里有什么，去哪找”	文档站点优化 ：指引LLM如何理解文档结构	动态能力暴露 ：声明“我能做什么”并提供调用接口	密码学身份验证 ：证明自动化客户端的身份
部署形式	静态文本文件 ( /.well-known/agents.txt )	静态文本文件 ( /.well-known/llms.txt )	常驻进程/服务器，监听端口	HTTP头、签名令牌等（通常结合其他方式）
发现机制	通过固定URL路径发现	通过固定URL路径发现	需预先知道地址 （手动配置或通过其他方式发现）	不直接提供发现，是其他协议的增强组件
身份验证	无 ，仅依赖User-Agent字符串	无 ，或依赖HTTP Referer等简单机制	支持（如TLS、令牌），取决于服务器实现	核心功能 ，提供强身份验证
适用场景	任何希望被AI智能体识别的网站或API	开源项目文档、技术API参考站	需要向AI客户端提供复杂工具/数据的本地或远程服务	任何需要验证自动化客户端合法性的场景
当前状态	IETF草案已过期，无官方状态	社区驱动，逐步采用中	由Anthropic等推动，在开发者工具生态中活跃	IETF工作组讨论中，尚未形成最终标准

4. 作为实践者的操作指南与决策路径

面对这样一个分散的、尚未定型的生态，作为网站或服务运营者，现在应该怎么做？以下是我基于当前技术现状给出的实操建议。

4.1 如果你已经部署了 agents.txt

核心建议：保持不动，但需审计。

1. 无需立即删除 ： 你的 /.well-known/agents.txt 文件仍然在被一些实验性的爬虫、验证工具或早期采用者读取。移除它不会带来任何好处，反而可能切断与这些友好智能体的联系。边际成本为零，保留无妨。
2. 进行语法验证 ： 由于草案已过期，未来不会有官方的语法更新。但社区中的解析器可能会产生分歧。建议定期使用仍在维护的验证器（例如原文作者提到的 global-chat.io/validate ）检查你的文件，确保其格式与主流解析器兼容，避免“语法漂移”。
3. 交叉核对端点 ： 仔细检查你在 agents.txt 中声明的所有 Endpoint 。确保它们：
   • 仍然有效且返回预期的数据格式（如JSON）。
   • 具有适当的安全措施（如API密钥、速率限制），因为 agents.txt 本身不提供保护。
   • 与你在其他注册表或文档中提到的信息保持一致。不一致的端点信息比没有信息更糟糕。

4.2 如果你今天要从零开始构建

核心策略：分层覆盖，组合使用。 没有银弹，但可以通过组合多种轻量级方案来覆盖大多数场景。

1. 第一层：基础发现与指引 ( llms.txt + agents.txt 遗风)

   • 部署 /.well-known/llms.txt ： 如果你的网站有大量文档（开发者文档、产品手册、知识库），这是性价比最高的第一步。按照其社区规范，清晰地指出你的搜索API、主要的API参考页根目录、教程索引页等。这能极大提升ChatGPT、Claude等LLM在分析你站点内容时的效果。
   • 考虑保留 /.well-known/agents.txt 作为后备 ： 尽管其IETF状态已过期，但作为一种“事实上的”约定，它仍然是一个信号，表明你关注AI智能体的访问。你可以在其中放置一些最基本的信息，比如指向你的主要API入口或站点地图的链接。将其视为一个低成本的、向后兼容的声明。

2. 第二层：深度能力暴露 (MCP)

   • 评估MCP的适用性 ： 如果你的服务能提供超越简单数据获取的“能力”——例如，执行计算、查询内部数据库、操作文件系统、控制智能家居设备——那么实现一个MCP服务器是更强大的选择。
   • 实现与部署 ： MCP有相对清晰的协议规范。你可以为你的服务编写一个MCP服务器适配器，将其能力（工具）暴露出来。用户可以将你的MCP服务器配置到他们的Claude Desktop等客户端中，从而直接通过自然语言调用这些能力。
   • 注意 ： MCP需要用户主动配置服务器地址，因此它不适合“公开网站发现”。它更适合于用户已决定使用的工具或服务。

3. 第三层：安全加固 (关注Web Bot Auth进展)

   • 保持关注 ： 密切关注IETF中 web-bot-auth 或相关签名草案的进展。当有成熟、易实现的方案出现时，考虑为你暴露给智能体的端点（无论是通过 llms.txt 声明还是API本身）添加此类身份验证。
   • 当前临时措施 ： 在强身份验证标准落地前，对你提供的任何专用AI端点 务必实施严格的API密钥认证、基于IP的速率限制和请求签名 。永远不要因为相信 User-Agent 头而放松安全警惕。

4.3 一个具体的配置示例

假设你运营一个天气预报API服务 api.weather.example.com ，并有一个开发者门户站 dev.weather.example.com 。

• 在 dev.weather.example.com 部署 /.well-known/llms.txt :

  # llms.txt for Weather Example Dev Portal
  api-version: v2
  search-api: https://api.weather.example.com/v2/search?q={query}
  api-docs: https://dev.weather.example.com/docs/v2
  tutorials: https://dev.weather.example.com/guides
  repository: https://github.com/weatherexample/api-client
  

  这帮助LLM理解你的文档结构。

• 在 api.weather.example.com 部署 /.well-known/agents.txt (作为后备声明) :

  # agents.txt for Weather Example API
  User-Agent: *
  Allow: /v2/current
  Allow: /v2/forecast
  Disallow: /v2/admin
  Endpoint: /v2/current -> https://api.weather.example.com/v2/current?location={city}
  Endpoint: /v2/forecast -> https://api.weather.example.com/v2/forecast?location={city}&days=3
  Capability: weather-query
  

  这向通用智能体指明主要的、友好的API端点。

• 为高级用户提供MCP服务器 ： 开发一个MCP服务器，包装你的天气预报API。它暴露 get_current_weather 和 get_forecast 两个工具。用户安装后，可以直接在AI聊天界面问：“我周末去纽约的天气怎么样？” AI会通过你的MCP服务器获取数据。

• 安全措施 ： 所有 https://api.weather.example.com/v2/* 端点都要求有效的API密钥，并实施每分钟每密钥60次请求的速率限制。

5. 未来展望与生态观察

agents.txt 草案的过期，与其说是一个终结，不如说是一个清晰的信号： 通用、简单、安全的AI智能体服务发现，仍然是一个未解决的开放性问题 。IETF的进程是缓慢而审慎的，草案的消亡是机制的一部分，它淘汰了不够成熟或动力不足的方案。

真正的挑战在于，智能体生态的需求是多层次、多维度的：

1. 发现层 ： “有什么服务在那里？”（ agents.txt 的初衷）。
2. 身份层 ： “你是谁？我能否信任你？”（Web Bot Auth的目标）。
3. 描述层 ： “你能做什么？接口长什么样？”（OpenAPI/Swagger、MCP的部分角色）。
4. 交互层 ： “我如何调用你并得到结果？”（MCP、A2A）。

目前，没有一个单一标准能完美覆盖所有这些层。因此，我们看到的是一种“分层拼凑”的现状。 llms.txt 在文档发现描述层取得了进展；MCP在能力描述和交互层表现出色；而身份层仍在标准化进程中。

作为从业者，我的判断是 ：在未来12-18个月内，我们不会看到一个“一统江湖”的 agents.txt 2.0 。更可能的图景是：

• llms.txt 会在技术文档领域成为事实上的最佳实践。
• MCP 或其竞争协议（如OpenAI的类似倡议）会在“个人/企业工具增强AI助手”这个赛道上深化，成为连接AI与专用工具的核心协议。
• IETF 最终会产出某个关于自动化客户端身份验证的标准，这个标准可能会被其他上层协议（如未来的某个发现协议或MCP本身）所采用。

在这个过程中，保持灵活性和对底层问题的关注是关键。与其等待一个完美的标准，不如根据你的实际需求，采用上述组合策略，先解决眼前的问题，同时为未来的标准演进留好接口。毕竟，让智能体更好地与我们的服务交互，最终受益的是我们自己和我们的用户。 agents.txt 的故事提醒我们，构建未来基础设施的道路，往往是由一系列务实的、渐进式的实践铺就的，而非一个宏大的蓝图一蹴而就。