2026 Agent Readiness 现状报告
AI Agent 正在成为 Web 的新客户，但 99% 的网站还没准备好迎接它们。这份报告调查了剩下那 1% 做对了什么。
全文翻译
忠实翻译，术语保留英文原文，首次出现括号注释中文。
核心论点
文章指出，AI Agent（智能体）正在成为 Web 的新客户，但 99% 的网站还没有为此做好准备。报告深入调查了剩下那 1% 做对了什么。
近期行业背景
报告发布前有三件大事：
- Salesforce 推出 Headless 360 —— 将每一个 CRM 和 Commerce（商务）操作转化为 MCP（Model Context Protocol，模型上下文协议）工具
- 每个 Shopify 店铺默认成为 MCP Endpoint（端点）
- Cloudflare 举办了第一届 Agents Week
作者观察到，Agent 基础设施正在"大规模交付"。
方法论概述
ora 使用其 Deep Scan 工具扫描了数千个产品。报告中的每一个指标都来自真实 Agent —— 具体来说是 ChatGPT、Claude 和 OpenClaw —— 对每个网站运行完整 Session（会话），覆盖五个加权层级。该工具生成真实 Agent 并运行实际会话。每个 Protocol（协议）都通过真实握手（handshake）探测，而非字符串匹配。
他们在五个加权层上评估 110 项检查：
Discovery
发现层：Agent 能否找到网站的入口和能力声明？
Identity
身份层：网站如何向 Agent 声明自己的身份？
Auth & Access
认证与访问层：Agent 如何完成身份验证？
Agent Integration
Agent 集成层：MCP、A2A 等协议支持情况
User Experience
用户体验层：Agent 驱动的交互是否流畅？
加权评分
LLM 根据产品上下文审查，不相关的检查从分母中移除
覆盖的规范
| 规范/协议 | 内容 |
|---|---|
| RFC 8288 | Link Headers（链接头） |
| RFC 8414 | OAuth Server Metadata（OAuth 服务器元数据） |
| RFC 9309 | robots.txt |
| RFC 9421 | Web Bot Auth（Web Bot 认证） |
| RFC 9727 | API Catalog（API 目录） |
| RFC 9728 | OAuth Protected-Resource Metadata |
| MCP 全面覆盖 | Tool Descriptions、OAuth、PKCE、Streamable HTTP、Server Cards |
| A2A / ACP | Agent-to-Agent / Agent Communication Protocol |
| x402 / MPP | 支付协议 / 机器支付协议 |
| llms.txt | 为 LLM 提供网站结构化信息的声明文件 |
| agentskills.io | Agent 技能注册中心 |
评分机制
评分是 Relevance-aware（相关性感知）的。每次扫描后，LLM 会根据产品上下文审查结果，标记出真正不相关的检查（例如：对免费开源工具检查支付协议）。N/A 检查从分母中移除，因此网站不会因为缺少一个它没有理由实现的协议而被扣分。每个网站获得 0-100 分和一个字母等级。A 意味着 Agent 可以端到端完成任务，F 意味着它连首页都过不去。
排行榜 Top 50
榜单顶端由更新的、Agent-native（原生 Agent）公司主导：Attio、Tavily、AgentMail、Parallel、Fireworks 等。这些公司诞生于 Agent 成为品类之后，Agent-native 基础设施是默认起点，因此输出 MCP、Streaming（流式传输）和 Agent 级 UX 是默认而非迁移。
作者认为更有趣的信号是与它们并列的基础设施巨头。Stripe、Cloudflare 和 Vercel "早早读懂了紧迫性" —— 每一个新的 MCP 传输、Commerce 协议和 Agent Runtime（运行时）都运行在它们的轨道上，每一个新的 Agent 工作流都在复合它们的收入。支付和基础设施被描述为"承重结构"。
| 排名 | 公司 | 等级 | 分数 | 域名 |
|---|---|---|---|---|
| 1 | Telnyx | A | 91 | telnyx.com |
| 2 | Forter | A | 86 | forter.com |
| 3 | Attio | B | 79 | attio.com |
| 4 | AnomalyArmor | B | 78 | anomalyarmor.com |
（原文提供完整 Top 50，此处摘录前 4 名）
深度解读
工程级分析：协议栈拆解、评分架构、选型决策框架。
这篇文章回答的问题：网站需要具备哪些技术能力，才能成为 Agent 的合格"客户"？
这篇文章应该回答但没回答的问题：网站为什么需要迎接 Agent？Agent 流量对网站来说是机遇还是负担？
压力测试：三个最致命的假设
假设 1：Agent 需要专用协议才能与网站交互。现实是，大量成功的 Agent 集成并不使用这些协议。ChatGPT 的 Browse 功能、Claude 的 computer use 都是直接解析 HTML。如果 Agent 本质上是"会用工具的浏览器"，那协议层可能只是锦上添花而非必需品。这就像说"99% 的餐厅没有为外星人准备好菜单" —— 前提本身就值得质疑。
假设 2：用 ChatGPT/Claude/OpenClaw 作为评测 Agent 是客观的。这是循环定义 —— "Agent Readiness"的分数完全取决于这三个特定 Agent 能做什么，而非 Agent 一般需要什么。如果换一批 Agent 来测，排行榜可能完全不同。ora 用自家 Agent 来定义标准，再用自家工具来打分。
假设 3：ora research 是中立的观察者。ora.ai 出售 Deep Scan 工具。Agent Readiness 越重要，他们的产品越有价值。这不是阴谋论 —— 这是标准的 vendor research（供应商研究报告），读的时候需要打折扣。
一、五层评分架构拆解
ora 的 110 项检查分布在五个加权层上。这不是随机堆砌 —— 它们构成了一个Agent 与网站交互的完整调用链：
| 层级 | 实际运行位置 | 核心协议 | 失败后果 |
|---|---|---|---|
| Discovery | DNS / HTTP 层。Agent 发出第一个请求时 | llms.txt, robots.txt (RFC 9309), Link Headers (RFC 8288), API Catalog (RFC 9727) | Agent 连网站有哪些能力都不知道，只能盲猜 |
| Identity | HTTP 响应头 / 元数据端点 | OAuth Server Metadata (RFC 8414), Protected-Resource Metadata (RFC 9728) | Agent 不知道该信任谁、怎么建立安全通道 |
| Auth & Access | OAuth 授权服务器 / Token 端点 | OAuth 2.1 + PKCE, Web Bot Auth (RFC 9421), MCP OAuth | Agent 无法完成身份验证，所有需要登录的操作都卡死 |
| Agent Integration | 应用层端点（MCP Server / A2A Endpoint） | MCP (Streamable HTTP, Tool Descriptions, Server Cards), A2A, ACP | Agent 找到了门，但门上没有门把手 —— 知道有功能，但不知道怎么调用 |
| UX | Agent 执行操作后的响应处理 | Streaming, 结构化输出, 错误恢复, x402/MPP 支付 | Agent 能调用功能，但结果不可用（非结构化 HTML、无 Streaming、无支付能力） |
关键设计：Relevance-aware 评分。这是整个方法论中最聪明的部分。LLM 在扫描后审查结果，将与产品无关的检查从分母中移除。这意味着：
- 免费开源工具不会因为没有 x402 支付协议而被扣分
- 纯 B2B API 不会因为没有 Consumer-facing 的 Agent UX 而失分
- 分数真正反映的是"该有的是否都有了"，而非"所有协议都实现了一遍"
二、协议栈全景：谁定义了 Agentic Web？
报告引用的规范清单，实际上勾勒出了一个完整的Agent Web 协议栈。我们可以把它分三层理解：
发现与身份
llms.txt — 网站对 LLM 的"自我介绍"，类似 robots.txt 但面向 Agent
RFC 8288 — HTTP Link Headers，让 Agent 通过响应头发现相关资源
RFC 9727 — API Catalog，结构化列出网站所有可用 API
认证与信任
RFC 8414 / RFC 9728 — OAuth 元数据发现，Agent 自动找到授权端点
RFC 9421 — Web Bot Auth，专为 Bot 设计的认证方案
OAuth 2.1 + PKCE — MCP 的默认认证方式
交互与支付
MCP — Agent 调用工具的标准协议（Tool Descriptions, Streamable HTTP, Server Cards）
A2A / ACP — Agent 之间互相通信
x402 / MPP — 机器对机器的支付协议
三、Agent-native vs 迁移：两种路线的工程差异
报告揭示了一个关键分野：
Agent-native 公司（Attio, Tavily, Fireworks...）
- 默认输出 MCP：产品设计时就考虑了 Agent 调用场景
- Streaming 是默认：不需要"给 Agent 加一个流式接口"
- Agent UX 是一等公民：错误消息结构化、操作可回滚
- 零迁移成本：不需要给旧系统"打补丁"
基础设施巨头（Stripe, Cloudflare, Vercel...）
- 早期嗅到机会：在 Agent 成为品类前就开始布局
- 平台效应：每新增一条 Agent 轨道，所有下游用户受益
- 复合增长：Agent 工作流越多，平台收入越高
- "承重结构"定位：不做 Agent 产品，做 Agent 的基础设施
四、DIY vs Deep Scan：你自己能做什么？
| 维度 | 自己手动检查 | ora Deep Scan |
|---|---|---|
| 发现 llms.txt | curl 访问 /llms.txt | 自动探测 + LLM 语义解析 |
| MCP Server 端点 | 手动找文档中的 /mcp 端点 | 自动握手探测 + Server Card 验证 |
| OAuth 发现 | 查 /.well-known/oauth-authorization-server | 全链路 OAuth 元数据检查 + PKCE 验证 |
| Agent 会话测试 | 几乎不可能手动模拟 | 真实 Agent 运行完整 Session |
| Relevance 过滤 | 靠人工判断 | LLM 自动标记 N/A 项 |
| 成本 | 人工时间 + 维护成本 | 付费工具，但可规模化 |
五、选型决策框架
你应该关注这份报告
如果你的产品面向开发者 / B2B / 电商，且已有用户通过 Agent 访问你的服务。你不需要全部实现 110 项检查，但 Discovery + Auth + MCP 三层是底线。
你可以先观望
如果你的产品是纯内容型（博客、文档站），Agent 流量目前对你没有商业价值。但 llms.txt 和 robots.txt 的 Agent 规则是低成本投入，值得提前准备。
你可能不需要这个
如果你的用户群与 Agent 完全不重叠（C 端娱乐、本地服务）。但要注意：Agent 作为"中介层"正在渗透一切，今天不需要不等于明天不需要。
六、诚实限制
需要警惕的
- 利益冲突：ora 出售 Deep Scan 工具，报告天然有推广动机
- 评测 Agent 的偏见：只用 3 个 Agent 评测，结果可能不具普遍性
- "99%"是修辞：没有给出扫描了多少网站、什么类型的网站
- Top 50 不完整：原文只展示了前 4 名，完整的 50 名需要去原文查看
值得认可的
- Relevance-aware 评分：避免了"什么都得实现"的军备竞赛思维
- 真实 Agent 测试：不是静态分析，而是实际运行 Session
- 协议栈全景：第一次系统性地定义了 Agentic Web 的技术栈
- 基建公司视角：不只看 Agent-native 公司，也关注了 Stripe/Cloudflare 这类"卖铲子"的角色
Payments and infrastructure are described as "load-bearing for the agentic web."
支付和基础设施被描述为"承重结构" —— 每一个新的 Agent 工作流都在复合它们的收入。
An A means an agent can complete a task end-to-end. An F means it cannot get past the front page.
A 意味着 Agent 可以端到端完成任务。F 意味着它连首页都过不去。
苏格拉底对话
通过提问层层深入，发现报告背后的核心洞察。
学生：这份报告说 99% 的网站没准备好迎接 Agent，这听起来很吓人。我需要立刻给我的产品加上 MCP 支持吗？
老师：先别急。我问你一个问题：你上一次使用某个网站时，是通过浏览器直接访问，还是通过一个 Agent 帮你操作的？
学生：大多数时候还是直接用浏览器。只有偶尔让 Claude 帮我查个 API 文档或者抓个数据。
老师：这就是关键。报告说 Agent 是"Web 的新客户"，但 Agent 目前占你总流量的多少？如果 Agent 流量不到 5%，那"99% 的网站没准备好"这个数字，到底是危机信号还是市场教育？
学生：嗯……所以这份报告本身可能也是一种市场教育行为？ora 出售 Deep Scan 工具，他们天然有动力让"Agent Readiness"变成一个大家都关心的话题。
老师：没错。但这不意味着报告没有价值。关键是区分"事实"和"叙事"。事实是：确实有一套新的协议栈正在标准化（MCP、A2A、llms.txt 等）。叙事是：99% 的网站"落后"了。前者值得技术人关注，后者需要打折扣。
学生：那报告里最有价值的部分是什么？
老师：我认为是两件事。第一，它第一次系统性地画出了"Agent Web 协议栈"的全景图 —— 从 Discovery 到 UX 的五层结构。之前这些协议散落在各个 RFC 和提案里，没有人把它们串起来。第二，它揭示了一个有趣的分野：Agent-native 公司把这些协议当默认配置，而 Stripe/Cloudflare 这类基建公司把它当复合增长引擎。这两种策略完全不同，但都指向同一个方向。
学生：所以真正的问题不是"我的网站有没有准备好"，而是"Agent 流量什么时候会成为不可忽视的比例"？
老师：更准确地说，是"我的产品在 Agent 调用链路中扮演什么角色"。你是被 Agent 调用的工具（那需要 MCP 支持）？还是 Agent 的运行基础设施（那需要更深层的集成）？还是 Agent 的终端用户界面（那需要 UX 层优化）？这三个角色需要的准备完全不同。
学生：报告里的 Relevance-aware 评分机制也挺有意思。它承认了不是每个网站都需要实现所有协议。
老师：这是整个方法论中最聪明的设计。但它也暴露了一个问题：如果每个网站的评分子集都不同，那两个同为 80 分的网站实际上可能完全不可比。这让排行榜的"排名"变得可疑 —— 排名暗示了绝对优劣，但评分机制本身否认了这一点。
学生：所以如果我要做决策，应该怎么用这份报告？
老师：把它当作一份"协议栈地图"而非"成绩单"。不需要追排名，但需要理解每一层解决什么问题。然后根据你的产品角色，选择性地实现最关键的 2-3 层。llms.txt 和 robots.txt 的 Agent 规则是最低成本的起点，几乎零维护成本，但能让 Agent 知道你的存在。这才是真正的 ROI。
学生：最后一个思考：如果 99% 的网站都没准备好，那 Agent 目前是怎么工作的？它们是通过"暴力解析 HTML"来完成任务的吗？
老师：这正是最反直觉的地方。大多数 Agent 确实是靠解析 HTML、模拟点击来工作的 —— 这很脆弱，但能用。报告的价值不在于说"你必须立刻改造"，而在于描绘了一个未来状态：当协议栈成熟后，Agent 与网站的交互会从"暴力解析"升级到"结构化对话"。这个转变不会一夜发生，但提前了解地图的人不会迷路。
个性化洞察
基于你的身份和关注领域，提炼最有价值的发现。
1. 协议栈全景图值得收藏
报告第一次系统性地将 Agentic Web 的技术栈从 RFC 层面串起来。作为技术自媒体内容，这份"协议栈地图"本身就是高价值素材 —— 可以单独拆成一篇"Agent Web 协议栈入门指南"。你需要做的不是实现这些协议，而是理解每一层解决什么问题，然后在合适的时候写一篇通俗解读。
2. "卖铲子"比"挖金子"更稳
报告最有洞察力的观察是 Stripe/Cloudflare/Vercel 的策略：不做 Agent 产品，做 Agent 的基础设施。这对你的 AI 产品方向有启发 —— 与其做第 1000 个 Agent，不如做让 Agent 更好工作的工具。Agent-native 公司会死一批，但基础设施公司会持续增长。
3. llms.txt 是最低成本的 Agent Readiness 投入
如果你有个人网站或项目网站，写一个 llms.txt 文件（告诉 LLM 你的网站有什么能力、怎么调用）几乎是零成本的。这比实现完整的 MCP Server 简单 100 倍，但能让 Agent 在搜索时优先发现你。值得今天就做。
4. vendor research 的阅读框架
这份报告是一个经典的 vendor research 案例。ora 用"99% 的网站没准备好"制造紧迫感，用自家工具定义"准备好"的标准，再用排行榜展示"谁已经准备好了"。这个套路在 Gartner、Forrester 的报告中也很常见。下次读类似报告时，先问三个问题：谁出的？谁付费？标准是谁定的？
5. Agent 流量占比是关键先行指标
在决定投入多少资源做 Agent Readiness 之前，先搞清楚你的产品目前有多少流量来自 Agent。如果不到 5%，优先级可以放低。但如果你做的是开发者工具或 B2B API，这个比例可能已经在快速增长 —— ChatGPT 和 Claude 的 browsing 功能每天在你的文档上爬多少次？这个数据值得监控。