用A2A协议开放网站能力

大多数所谓的「AI 集成」，仍然意味着由人类阅读文档，再编写客户端。A2A 则把这个过程反了过来：另一个 Agent 会读取一份简短的机器可读描述，了解你的服务能做什么，然后直接调用它——不需要浏览器、不需要抓取，也不需要人类参与其中。我在自己运营的一个小工具（免费的 llms.txt 验证器）上接入了 A2A，结果发现它远没有那些缩写听起来那么复杂。下面就是完整实现，以及真实的请求示例。

A2A（Agent2Agent）是一种开放协议，目前已归入 Linux Foundation。它允许 AI Agent 通过普通 HTTP 相互发现和调用。你可以把它理解为面向 Agent 的公共 API：你不再发布供人类阅读的 OpenAPI 文档，而是发布一份机器可读描述，让其他 Agent 可以理解并调用你的服务。

它只有两个组成部分：

• Agent card——一份用于发现服务的文档。

• Skill——一个可调用的 JSON-RPC 端点。

仅此而已。只需要一个 Skill 和一个方法，你就能提供一套真正有用的 A2A 接口。

第一部分——Agent card（服务发现）

你需要在 /.well-known/agent-card.json 提供一个 JSON 文件，用来描述你是谁，以及你能做什么。必填字段包括 name、description、version、url（你的端点），以及至少一个 Skill：

{
  "protocolVersion": "0.3.0",
  "name": "llms.txt Validator",
  "description": "Validate a website's llms.txt and return a score with findings.",
  "url": "https://llms-txt-validator.dev/a2a",
  "skills": [{
    "id": "validate_llms_txt",
    "name": "Validate llms.txt",
    "description": "Given a domain or URL, fetch and validate its llms.txt."
  }]
}

这张 Agent card 是一份契约，而不是一个 meta 标签。Agent 获取它后，会看到一个 validate_llms_txt Skill，从而知道你提供了什么能力，以及应该到哪里调用。

第二部分——端点（可调用的 Skill）

Agent card 中的 url 指向一个 JSON-RPC 2.0 端点。Agent 使用一条消息调用 message/send 方法；你的服务完成实际工作，并返回一个 Task。下面是一次对我的 Agent 发起的真实调用：

POST /a2a
{ "jsonrpc": "2.0", "id": "1", "method": "message/send",
  "params": { "message": { "role": "user",
    "parts": [{ "kind": "text", "text": "validate llmstxt.org" }] } } }

……下面是返回结果：一个已经完成的 Task，其中既包含适合人类阅读的摘要，也包含调用方 Agent 可以直接使用的结构化数据：

{ "result": { "kind": "task", "status": { "state": "completed" },
  "artifacts": [{ "parts": [
    { "kind": "text", "text": "Validated llmstxt.org: score 100/100..." },
    { "kind": "data", "data": { "ok": true, "report": { "scores": { "overall": 100 } } } }
  ] }] } }

没有 HTML，不需要解析，也不用猜测。Agent 用自然语言提出问题，然后准确拿到了自己需要的数据。你也可以亲自使用 curl 调用它。

最小可用的 A2A

你不需要一开始就实现完整规范。选择你的服务真正能够完成的一件事，然后：

• 在 /.well-known/agent-card.json 提供一张有效的 Agent card，其中包含一个 Skill。

• 实现同步的 message/send 方法，用它封装这项能力。

• 返回一个已完成的 Task，并将结果作为 artifact 放入其中。

流式传输、任务历史记录和推送通知全都是可选功能——将 capabilities.streaming 设置为 false，等到真正需要时再添加它们。

A2A、WebMCP 与 MCP（它们不是竞争对手）

• A2A——让网络中的 Agent 通过 HTTP 调用你的服务，也就是本文介绍的内容。

• WebMCP——让运行在浏览器中的 Agent 调用当前已打开页面上的工具。

• MCP——将工具连接到单个模型或应用，通常运行在本地。

它们可以相互叠加，而不是彼此竞争：A2A 面向网络中的 Agent，WebMCP 面向浏览器内的 Agent，MCP 则把工具接入某一个模型。

唯一的原则：不要发布一张无法兑现的 Agent card

为了显得更现代，直接放上一张 Agent card，却让端点始终返回 501，这种做法确实很诱人。但不要这么做。Agent 获取你的 card 并调用一个无效的 url 后，对你的信任只会降低——你白白浪费了它的一次调用。你声明的每个 Skill，都应该对应真实、可用的行为。（这也是为什么我开发的验证器只有在实时端点确实能够响应 message/send 时，才会把 A2A 信号报告为「存在」。）

如果你发布了 A2A 服务，欢迎把你的 Agent card 发到评论区——我很想调用看看。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。