让你的网站被 AI Agent 读懂：11 种机器可读清单标准

AI 智能体在评估一个供应商时，做法和人类一样：打开网站，寻找证据。区别在于速度和形式——智能体给你的是秒级响应，而不是分钟级；它要的是 JSON，而不是英雄横幅。直到最近，一个降落在 agentbadge.xyz 的智能体遇到的是一个为人而建、别无其他的页面——而我们自己的 Readiness Scanner 正在以我们恰恰缺失的那些信号去给其他网站打分。修鞋的却没有鞋子穿。我们修复了这个问题：整个发现层现在从实时数据源生成，免费提供，无需认证，并经过我们自己的 Scanner 在 CI 中的验证。

200 毫秒内，智能体能找到什么？

11 个机器可读的清单文件，全部 200 OK，全部免费，全部动态生成——而非手工维护：

/.well-known/agent-card.json        A2A v1.0 — who we are, skills[]
/.well-known/api-catalog            RFC 9727 linkset — every API entry
/.well-known/erc8004-agent.json     on-chain identity registration
/.well-known/mcp/server-card.json   MCP capabilities + tools surface
/.well-known/agent-evaluation.json  verification ladder (claims→refs)
/.well-known/owner-questions.json   "who runs this" for due-diligence
/.well-known/did.json               did:web:agentbadge.xyz document
/.well-known/did-configuration.json signed domain linkage (VC-JWT)
/.well-known/jwks.json              real Ed25519 key, kid'd
/.well-known/security.txt           RFC 9116, Expires generated +1y
/llms.txt                           agent-oriented sitemap

仅凭 agent-card 就能完成 A2A 握手：name、provider、supportedInterfaces[]、skills[] 包含 tags 和 examples，以及 securitySchemes 声明 x402 为支付通道。一次 GET，外部智能体就知道我们的身份、能力以及如何付款。

这些清单文件从何而来？

不是来自文案——而是来自代码本身。清单注册表收集的是运行时使用的同一套实时数据源（openapi.ts、路由配置、blog-data.ts、SKU 目录），每个清单都是对那个真相的投影：

启动时：依赖环境变量生成的清单在服务器启动时写入清单注册表，路由从注册表提供服务——单一数据源。

构建时：bun run gen:discovery 将快照写入 public/.well-known/；禁止手动编辑。

CI 漂移检查：重新生成 + git diff --exit-code ——如果某个清单与代码产生了漂移，构建直接失败。

我们的清单不可能在不通知我们的情况下过期。

机器可读的站点地图长什么样？

llms.txt——告诉 LLM"从这里开始"的实际约定：H1 标题、一段描述平台的块引用、## 章节格式的命名链接。我们的由机器可读入口点、快速开始指南、免费和付费端点生成——服务区段锚定到同一个 /api/v1/services 目录，为每个 402 上的 bazaar 扩展提供动力。

为什么同一页面要提供两次？

因为读者可能不是浏览器。任何页面带上 Accept: text/markdown 头都会返回该页面的 markdown 表示——实时验证：

$ curl -sH "Accept: text/markdown" https://agentbadge.xyz/blog
content-type: text/markdown; charset=utf-8

博客文章也配有 .md 镜像（/blog/arc-c10-payer-binding.md → 200 text/markdown）。HTML 保持规范地位；<link rel="alternate" type="text/markdown"> 将机器导向其孪生兄弟。

智能体能在不信任我们的前提下验证我们的声明吗？

agent-evaluation.json——一个验证阶梯：按检查时间排序的声明，每个声明包含 action 和 ref：

{
  "depth": "5s",
  "checks": [
    { "claim": "mainnet deployment — AgentEventLog on Arc",
      "action": "open",
      "ref": "https://explorer.arc.io/address/0x1bb6…4700" }
  ]
}

5 秒级：我们存在于链上并发布了一张卡片。60 秒级：清单有效性、实时 OpenAPI、拒绝合约。再深入：dogfood 交易和审计追踪。owner-questions.json 以相同格式回答企业尽职调查（运营商、司法管辖区、联系方式）。

我们怎么知道它真的有效？

我们用同一个 142 条规则的扫描引擎对自己进行扫描——与给外部网站打分的工具一样：mcp/server-card.json (AB-006)、llms.txt (AB-014)、JSON-LD/OG (AB-015/016)、ai.txt (AB-017)——在 CI 中针对 agentbadge.xyz 执行。必须 100% 通过。一个损坏的清单会让我们自己的产品在自己的域名上评分下降。

实时状态：全部 11 个清单 200 响应、markdown 协商返回 text/markdown、文章配有 .md 镜像——全部生成，非手工编辑。

刻意缺失：ai-plugin.json（ChatGPT Plugins 2024 年 EOL——已废弃的清单是 cargo cult）；/.well-known/agent.json → 301 重定向至 agent-card.json。

立即验证：curl https://agentbadge.xyz/.well-known/agent-card.json ——或者扫描我们：npx agentbadge-scan agentbadge.xyz。

Arc Campaign 系列第 14 篇。C15 继续——智能体找到了我们，现在它在读价目表。

原文发表于 agentbadge.xyz。