A2A 接入实例：发现、接口与限流

AI 助手替用户规划旅行时，可靠答案从哪里来？Vedar 堪察加门户的做法，是用 A2A 协议把本地旅游数据和申请流程开放给其他智能体，覆盖真实余位、火山状态、天气和行程规划。

这篇案例的价值，在于展示了一个业务网站如何成为智能体可发现、可调用的服务，同时把预订确认留给真人。对程序员来说，接口之外，能力描述、数据时效和用户授权同样值得看。

A2A 接入，先让其他智能体知道你能做什么

Vedar 是旅游信息门户，带有 AI 向导 Kuzmich，不是旅行社或旅游运营商。它不做预订、不收款，只把出行申请交给运营商、住宿业主或车辆承运方确认。

原文把两种协议的分工讲得很直观：MCP 连接智能体与工具，A2A 连接智能体与智能体。后者允许另一个助手把问题交给 Kuzmich，由它结合平台数据回答。

入口是 Agent Card，即描述服务能力的「智能体名片」。按作者在 2026 年 11 月 9 日核对的信息，该服务采用 A2A 1.0，通过 /.well-known/agent-card.json 发布名片，也为 0.3 客户端保留 /.well-known/agent.json。

服务提供 JSON-RPC 接口 https://vedarai.ru/api/a2a 和 HTTP+JSON 接口 https://vedarai.ru/api/a2a/v1，匿名访问，无需 API Key 或注册，仅按 IP 限流。它不使用流式响应和任务推送，任务在 SendMessage 响应中直接完成，保留一小时。

名片和技能描述，也是接口契约的一部分。

目录会原样复制名片字段，其他模型则会根据技能说明决定调用哪个工具。因此，描述必须交代能力边界，例如查询真实余位应使用 get_tour_availability。

自由提问之外，还要留一个精确调用入口

Vedar 提供 25 项技能：自由问答 kuzmich-chat，以及与 MCP 服务器一致的 24 个工具。自由文本以俄文或英文效果最好；需要确定调用哪个工具时，可以在消息的 DataPart 中放入 {"tool": "<工具名>", "arguments": {...}}，参数结构通过 /api/mcp 的 tools/list 获取。

下面两条命令分别查看名片、查询火山状态：

curl -s https://vedarai.ru/.well-known/agent-card.json | jq '{name, version, skills: [.skills[].id]}'

curl -s -X POST https://vedarai.ru/api/a2a \
  -H 'Content-Type: application/json' \
  -H 'A2A-Version: 1.0' \
  -d '{"jsonrpc":"2.0","id":1,"method":"SendMessage",
       "params":{"message":{"role":"ROLE_USER","messageId":"demo-1",
         "parts":[{"data":{"tool":"get_volcano_status","arguments":{}}}]}}}'

注意第二条命令中的 A2A-Version: 1.0 和 parts：前者指定协议版本，后者承载工具调用数据。

作者称，响应会返回 TASK_STATE_COMPLETED，包含 KVERT 航空颜色代码，以及俄罗斯科学院地球物理局堪察加分部的地震活动汇总，活跃度升高的火山附有观测日期。数据为俄文，可由调用方模型翻译。get_weather 使用参数 {"place": "Петропавловск-Камчатский"}；全区安全预警调用 safety_status。

已有 MCP 客户端也能接入。服务以 ru.vedarai/mcp 发布在官方 MCP Registry，在 Claude Code 中执行：

claude mcp add --transport http vedar https://vedarai.ru/api/mcp

这里的 --transport http 对应远程 MCP 服务，不需要先接入 A2A。

为什么开放申请，却不开放即时预订

堪察加的天气和火山活动可能改变路线。作者因此把智能体的权限停在「提交申请」，最终由了解路线的人确认。

申请接口按业务拆分：create_lead 用于尚未确定团队游或日期的咨询；create_booking_request 针对具体团队游和日期，先检查真实余位；create_stay_request 提交住宿日期和人数；request_charter 用于整车包车；create_car_rental_request 采用带确认码的两步租车流程。整趟行程使用 create_trip_request，以同一个行程编号关联团队游、住宿和车辆，各合作方可看到其他部分。

涉及姓名和电话时，必须提供 consent: true，智能体不得替用户同意。get_request_status 可查询状态，但不返回个人数据。除住宿外，申请工具支持 notify_url，变化通知使用按 Standard Webhooks 签名的 POST。

这里要区分两类通知：A2A 没有启用任务推送，业务申请仍可发送 webhook。

make_trip_plan 和 edit_trip_plan 则只保存匿名行程草稿，保留 7 天，不含姓名、电话，也不会发给任何人。

我的判断

我认同它对能力边界的处理：资料库没有某个地点，就明确拒答；敏感信息必须获得本人同意；行程确认交给真人。这些规则让调用方知道答案和操作的边界。

但原文没有提供调用成功率、回答准确率或与网页检索的对照数据。作者所说的收益，目前主要是实现经验，不能据此认定接入 A2A 就能带来更多用户或更可靠的答案。它已被 Global A2A Registry 和 a2a.directory 收录，前者完成域名 DNS 验证并由 Vedar 认领管理，但目录收录也不能替代效果验证。

一般团队还要考虑：如果业务只是几个确定的数据查询，已有 MCP 工具是否足够？需要另一个智能体承接领域判断和多步服务时，A2A 才更有讨论价值。原文也没有展开数据更新频率、限流额度和异常处理，生产接入前仍需核实。

能拿来做什么

• 给现有 AI 工具补齐「何时调用、何时换工具、何时拒答」的说明，尤其避免让模型用相近地点的数据填补缺失信息。
• 在 Node 服务中区分匿名草稿和正式申请，为后者校验 consent: true，并确保状态查询不泄露个人数据。
• 开发旅行助手时，先用上述命令核对名片和返回数据，再决定通过 MCP 调用工具，还是通过 A2A 把问题交给 Kuzmich。