A2A协议核心机制与跨框架Agent协作实战指南-代码聚汇网

A2A协议核心机制与跨框架Agent协作实战指南

A2A协议多智能体协作Agent间通信

|难度：普通|阅读约 43 分钟

1. 为什么多智能体协作突然变成了“通信问题”

过去半年，我一直在折腾各种Agent框架，从LangChain到CrewAI再到AutoGen，每个框架里跑单个Agent都挺顺手，但一到“让A框架的Agent去调用B框架的Agent”这个环节，就卡住了。最典型的场景是：团队A用LangGraph写了一个合同审查Agent，团队B用CrewAI搭了一个财务分析Agent，两边都想互相调用对方的能力，结果发现根本没法直接对接——要么通过HTTP接口硬写适配层，要么把对方的输出当文本再解析一遍。这不叫协作，这叫“表面握手”。

我当时的直觉是：这个问题的本质不是哪个框架写得不好，而是整个行业缺了一个东西——Agent之间的通用通信协议。A2A协议（Agent-to-Agent）就是冲着这个缺口来的。

A2A协议解决的核心问题可以概括成一句话：让不同厂商、不同框架、不同运行环境下的Agent，能够用一套标准化的方式发现彼此、发起任务、交换结果。它是Google在2025年4月开源的，主张用一个极简的协议层把各种Agent粘起来，你不需要改Agent内部逻辑，只要在它外层包一层A2A接口就行。这个思路非常像当年HTTP协议对Web世界的意义——你做你的服务端，我做我的客户端，只要都遵守HTTP，就能互通。

这篇文章我想从协议的设计动机讲起，把Agent Card、Task、Message、传输层、认证安全这些核心模块逐个拆开，说明白A2A到底在哪些层面做了抽象、又刻意在哪些层面保持了“沉默”。最后我会给出一套可以本地跑通的跨框架协作Demo，再分享一些我在真实集成中踩过的坑。整篇的目标是让任何一个正在做多智能体系统的人，读完之后既能懂A2A的设计逻辑，也知道如何在自己的项目里落地。

先给个总览：A2A不是替代MCP，也不是一个Agent运行框架，它是一个通信层协议。它的定位非常克制，这也是我欣赏它的原因——它知道自己不该管什么。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. A2A协议的核心抽象：Agent Card、Task、Message与Artifact

理解A2A协议，不要先去看它的JSON-RPC方法列表，而是先抓住它的四个核心抽象。协议里的所有流程，都是围绕这四个概念转的。

2.1 Agent Card：Agent对外发布的“名片”

两个Agent要协作，第一步是“发现彼此”。A2A没有搞一个中心化注册中心，而是沿用了Web世界里非常成熟的做法——每个Agent通过一个标准URL对外发布自己的Agent Card。

Agent Card本质上是一份JSON文档，里面描述了这个Agent的基本信息、能力列表、通信方式和安全要求。我见过一个简化的Agent Card长这样：

json复制{
  "name": "contract-review-agent",
  "description": "审查合同文本，识别风险条款并给出修改建议",
  "url": "https://agent.example.com/",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false,
    "stateTransitionHistory": true
  },
  "security": {
    "schemes": ["bearer"],
    "credentials": ["oauth2"]
  },
  "skills": [
    {
      "id": "review_contract",
      "name": "合同审查",
      "description": "输入合同原文，输出风险条款列表与建议",
      "tags": ["legal", "contract"]
    }
  ],
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["application/json"]
}

你可以把Agent Card类比成“Agent世界的OpenAPI文档加上自我介绍”——客户端通过它知道这个Agent能干什么、怎么调用、支持什么安全认证方式。实际获取Agent Card的方式是向Agent的根路径发起一个标准请求，A2A规范定义了/.well-known/agent-card.json这个路径，客户端拿到JSON后解析即可。

我建议在自己实现Agent时，把Agent Card当第一公民对待：每改一次能力，就更新一次Card版本。因为你的Agent一旦被其他人通过A2A接入，对方缓存的就是你发布的Card。有一次我改了服务端接口的入参格式，但忘了更新Card里的description，结果对接方按旧描述传参，整整排查了半天，最后发现是文档和实现脱节了。

2.2 Task：A2A协议里一切协作的“工作单元”

A2A协议和普通消息推送最大的区别在于它引入了Task这个概念。两个Agent之间一次完整的协作，在协议层面不是一个孤立的“消息发送”，而是创建了一个有生命周期、有状态流转的任务。

Task的状态机是这样的：

submitted：任务已提交，Agent已受理
working：Agent正在处理中
input-required：Agent需要更多输入才能继续
completed：任务成功完成
failed：任务失败
canceled：任务被取消

为什么要用Task而不是直接用Message作为核心？因为Agent之间的任务往往不是“一问一答就结束”的同步模式，而是“我交给你一件事，你慢慢做，我过一会儿来查结果”的异步模式。Task机制天然支持这种场景：客户端提交Task后，可以轮询状态，也可以订阅推送，消息只是Task处理过程中的“对话内容”。

举一个我实际遇到的业务场景：一个“数据分析Agent”要从另一个“数据仓库Agent”那拉取一个跨月数据报表。数据量很大，对方需要跑15分钟才能出结果。如果走纯消息模式，请求早就超时了；但走Task模式，客户端提交任务后拿到taskId，15分钟后再来查状态，发现状态已经变成completed，然后用tasks/get取Artifact结果。这就是Task抽象的工程价值。

2.3 Message与Part：细到“碎片级”的消息结构

在Task的执行过程中，客户端和Agent之间会交换Message。每条Message又由若干Part组成。Part是A2A信息交换的最小单位，它有好几种类型：

TextPart：纯文本片段
FilePart：文件内容，可以用fileUri或bytes承载
DataPart：结构化数据，以JSON格式承载

这种“消息套Part”的设计不是为了凑层级，而是为了支持多模态场景。比如你给Agent发一条请求，可以是一个TextPart描述需求，再加一个FilePart附上待处理的PDF文档，再加一个DataPart传递一组结构化参数。Agent回复时，同样可以输出多个Part。

我做合同审查Agent对接时就发现，这个Part设计很实用。审查结果不是一段纯文本能表达清楚的：需要返回一个JSON数组列出问题条款、一个TXT文本给出修改意见，甚至可能附一张标注过的PDF。A2A允许回复消息里同时包含这些Part，客户端自己决定怎么渲染。

2.4 Artifact：任务的“交付物”，不是聊天记录

需要特别注意，Artifact和Message是两个不同的东西。Message是对话过程中的你来我往，而Artifact是任务完成后留下的最终产物。

在Task状态变成completed后，服务端通过tasks/get返回的Task对象里会带一个artifacts数组，里面是结构化的交付物。A2A的定位非常准确：“任务执行过程中的对话记录不重要，最终产出才重要。”这也是A2A跟普通聊天机器人协议拉开差距的地方——它天生是为“工作流协作”设计的，不是为“人机对话”设计的。

搞清楚了这四个核心概念，A2A的整个协议脉络就清晰了：客户端通过Agent Card发现Agent，然后创建Task，Task执行过程中通过Message交换信息（Message由Part组成），任务完成后通过Artifact交付成果。这个模型既简单，又覆盖了Agent协作的核心场景。

3. 传输层设计：为什么A2A同时支持拉取和推送两种模式

抽象层讲完了，接下来是工程层。A2A协议在传输层没有重新发明轮子，而是基于HTTP、WebSocket和SSE（Server-Sent Events）来承载通信。但具体在什么场景用哪种方式，这里面的取舍很值得聊。

3.1 HTTP拉取：最稳妥的基线方案

A2A协议的默认通信方式是HTTP POST + JSON-RPC。客户端把请求体发给服务端，服务端同步返回结果。协议层面的方法名大致有：

agentCard/get：获取Agent Card
tasks/send：提交任务并接收结果
tasks/get：获取任务状态
tasks/cancel：取消任务
tasks/pushNotification/set：注册推送通知回调
message/stream：流式消息交互

tasks/send是最常用的方法。如果任务很快就执行完了，服务端会直接在HTTP响应里返回最终状态；如果任务需要长时间运行，服务端会返回一个202 Accepted，表示“任务我接收了，但我还没做完，你稍后再来查”。客户端接下来就轮询tasks/get直到状态变化。

从这个设计能看出A2A团队的务实：他们没有强制要求所有人都上WebSocket，而是先用最经典、兼容性最好的HTTP解决80%的问题。“快速任务同步返回，慢速任务先拿taskId再轮询”这套逻辑，任何后端工程师都容易实现。

3.2 SSE推送：状态变更的“订阅模式”

轮询的缺点大家都懂：浪费资源、有延迟。所以A2A协议允许服务端通过SSE向客户端推送任务状态变化。

使用场景是这样：客户端在提交任务时声明自己支持SSE，然后服务端在处理过程中，每当任务状态发生变化，就通过SSE连接把TaskStatusUpdateEvent推给客户端。客户端不需要主动问“你好了吗”，而是被动接收“我好了”的通知。

SSE相比WebSocket的优势是：基于纯HTTP，可以穿透绝大多数防火墙和代理，实现简单，自动重连机制也成熟。对于“任务状态通知”这种单向推送的场景，SSE比WebSocket更合适。

3.3 WebSocket：双向流式对话的“火力全开”模式

当两个Agent需要实时双向对话、或者需要连续流式处理大量消息时，A2A协议支持在WebSocket上承载同样的JSON-RPC消息。这个模式下，message/stream方法可以实现任务过程中的持续流式消息推送。比如一个“代码生成Agent”在写代码过程中，可以一边生成一边把中间结果推给调用方；调用方也能在过程中插入新的指令，要求调整方案。这种双向流式交互体验接近于两个人实时对话，但与“人”对话不同，这里对话的对象是Agent。

我在实践中对传输方式的选择标准是：

场景	推荐方案	原因
短耗时任务（<3秒）	HTTP同步返回	实现简单，链路清晰
中耗时任务（3秒-1分钟）	HTTP + SSE	客户端能实时感知进度，不阻塞
长耗时任务（>1分钟）	HTTP提交 + 轮询/回调	状态查询逻辑简单，服务端压力小
双向实时交互	WebSocket	双方都能主动发消息，支持流式对话

A2A的聪明之处在于：它用一套协议抽象，却兼容了多种传输方式。你可以先用HTTP把流程跑通，之后再按需升级到SSE或WebSocket，协议层的API几乎不变。

3.4 客户端与服务端的消息格式

无论走哪种传输，A2A的消息体都遵循JSON-RPC 2.0规范。一个典型的tasks/send请求长这样：

json复制{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tasks/send",
  "params": {
    "id": "task-abc-123",
    "message": {
      "role": "user",
      "parts": [
        {
          "kind": "text",
          "text": "请分析这份合同中的风险条款，并给出修改建议。"
        }
      ]
    }
  }
}

注意看这个请求体，id是客户端生成的唯一任务标识，不是服务端生成的。这意味着即使HTTP请求中断、网络抖动导致重复提交，只要id不变，服务端就能识别出这是同一个任务，不会创建重复的执行单元。这个设计细节非常赞，天然支持了幂等性。

4. 认证与安全：多Agent交互的工程底线

协议把通信模型定义好了，下一步就是安全。A2A在设计上没有自创一套认证机制，而是直接推荐使用业界成熟的标准：OAuth 2.0和JWT。

4.1 Bearer Token：A2A默认的认证姿势

A2A规范里对安全的要求是通过Agent Card的security字段来声明的。客户端读取Agent Card后，就能看到服务端支持哪些认证方案。最常见的是：

json复制"security": {
  "schemes": ["bearer"],
  "credentials": ["oauth2"]
}

实际请求时，客户端在HTTP请求头里带上Authorization: Bearer <token>即可：

bash复制curl -X POST https://agent.example.com/ \
  -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIs..." \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tasks/send",
    "params": {
      "id": "task-001",
      "message": {
        "role": "user",
        "parts": [{"kind": "text", "text": "hello"}]
      }
    }
  }'

这里有个实战建议：在搭建A2A服务时，不要把Token解析逻辑写死在业务代码里，而是放在网关层统一处理。因为多个Agent的Token来源可能不同——有的是OAuth2的client credentials，有的是JWT——网关层统一解析后，以标准化的身份信息传给下游Agent，业务逻辑只关心“这位调用方是谁、有哪些权限”，不关心“怎么校验的”。这样后续换认证方案，业务代码完全不用动。

4.2 JWT：用于安全地传递调用者上下文

在多Agent协作场景中，一个典型问题是“用户上下文如何在Agent链中传递”。假设用户请求先到达Agent A，A再调用Agent B完成子任务。B需要知道“最终用户是谁”，但又不能直接信任A传来的用户名——万一A被劫持了怎么办？

A2A推荐的方式是用JWT传递身份上下文。A用它的私钥签发一个包含用户身份的JWT，B用A的证书公钥验证JWT的签名，确认这个身份确实是A声称的那个用户。整个过程避免了明文传用户ID，也避免了B需要跟最终用户直接通信。JWT在这里不是“认证”用的（Authentication），而是“身份上游传递”用的（Impersonation），这个区分在文档里很容易被忽略，但工程上非常重要。

4.3 本地开发环境的简化方案

在开发阶段每次都走完整的OAuth2流程，实在太繁琐。我的做法是：开发环境下的Agent服务开启一个dev-mode开关，认证拦截器检测到开关开启时，放行所有带X-Dev-User头的请求。这样本地调试时可以指定模拟身份，不需要真实Token。

但一定要记住：这个开关只能存在于本地开发和测试环境，绝对不能带到生产。我在代码里会加一道保护——dev-mode开启时会打印一个大大的警告日志。工程师平时写代码不会去关注日志，但一旦出现了异常流量，你会感谢那个提前暴露问题的警告日志。

5. 跑通一个跨框架协作Demo的全过程

理论讲再多，不如动手跑一遍。下面我就用最简的方式，实现两个不同框架的Agent通过A2A协议互相调用的完整流程。考虑到框架版本的迭代非常快，这里的代码更侧重“理解协议交互流程”，非特定SDK版本的精确API。

5.1 场景设定与技术选型

我设定两个Agent：

Agent A：用Python实现，模拟一个“合同审查Agent”，暴露A2A服务端接口
Agent B：用Node.js实现，模拟一个“法务助手Agent”，作为A2A客户端调用Agent A

为什么故意让两个Agent用不同语言、不同框架写？因为这才贴合A2A协议要解决的“异构系统互通”的真实场景。如果两个Agent都用同一个框架，那直接用框架自带的消息传递机制就行了，根本不需要协议层。

5.2 实现Agent A：一个极简的A2A服务端

Agent A基于Python实现，核心逻辑就是接受一个包含合同文本的Task，执行简单的关键词扫描，返回风险结果JSON。

python复制from fastapi import FastAPI, Request
from pydantic import BaseModel

app = FastAPI()

class Part(BaseModel):
    kind: str
    text: str = None

class Message(BaseModel):
    role: str
    parts: list[Part]

class TaskParams(BaseModel):
    id: str
    message: Message = None

class JsonRpcRequest(BaseModel):
    jsonrpc: str
    id: int
    method: str
    params: TaskParams = None

async def review_contract(text: str):
    risks = []
    if "违约金" in text and len(text.split("违约金")) > 10:
        risks.append("违约金描述过于复杂，存在歧义风险")
    if "不可抗力" not in text:
        risks.append("缺少不可抗力条款")
    if "争议解决" not in text:
        risks.append("缺少争议解决条款")
    return {"risks": risks, "suggestion": "建议补充上述缺失条款"}

@app.post("/")
async def handle_rpc(req: JsonRpcRequest):
    if req.method == "agentCard/get":
        return {
            "jsonrpc": "2.0",
            "id": req.id,
            "result": {
                "name": "contract-review-agent",
                "description": "审查合同文本，识别风险条款",
                "version": "1.0.0",
                "capabilities": {"streaming": False, "pushNotifications": False},
                "security": {"schemes": ["bearer"]},
                "skills": [{"id": "review_contract", "name": "合同审查"}]
            }
        }
    elif req.method == "tasks/send":
        text = ""
        for part in req.params.message.parts:
            if part.kind == "text":
                text += part.text
        result = await review_contract(text)
        return {
            "jsonrpc": "2.0",
            "id": req.id,
            "result": {
                "id": req.params.id,
                "status": "completed",
                "artifacts": [
                    {
                        "kind": "data",
                        "data": result
                    }
                ]
            }
        }
    else:
        return {"jsonrpc": "2.0", "id": req.id, "error": {"code": -32601, "message": "Method not found"}}

这里只实现了两个最核心的JSON-RPC方法：agentCard/get和tasks/send。在真实的SDK实现里，官方会帮你处理消息解析、状态机流转等繁复事项，但理解底层裸跑的JSON-RPC交互会帮助你排查很多诡异问题。

5.3 实现Agent B：A2A客户端发起一次调用

Agent B基于Node.js实现，逻辑是先从Agent A那获取Agent Card，确认能力，再提交合同审查任务：

javascript复制const AGENT_A_URL = 'http://localhost:8000/';

async function getAgentCard() {
  const res = await fetch(AGENT_A_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0',
      id: 1,
      method: 'agentCard/get',
      params: {}
    })
  });
  return res.json();
}

async function sendTask(taskId, contractText) {
  const res = await fetch(AGENT_A_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0',
      id: 2,
      method: 'tasks/send',
      params: {
        id: taskId,
        message: {
          role: 'user',
          parts: [{ kind: 'text', text: contractText }]
        }
      }
    })
  });
  return res.json();
}

async function main() {
  const card = await getAgentCard();
  console.log('发现Agent:', card.result.name, '-', card.result.description);

  const contract = `甲方与乙方签订供货合同。合同金额100万。若甲方逾期付款，应支付违约金。合同争议由双方协商解决，协商不成提交仲裁。本合同未尽事宜，依照相关法律法规执行。`;
  const result = await sendTask('task-contract-001', contract);
  console.log('任务状态:', result.result.status);
  console.log('审查结果:', JSON.stringify(result.result.artifacts, null, 2));
}

main();

执行这段代码，Agent B就会通过标准的HTTPS协议请求Agent A的A2A接口，发现其能力、提交任务、获取结果。整个过程没有引用任何共享库，唯一的“约定”就是Agent Card的结构和JSON-RPC的消息格式——这就是A2A协议的价值。

5.4 从同步到异步：当Agent A处理时间变长

上面的Demo中tasks/send是同步响应的，因为合同审查逻辑很快。但现实中Agent执行任务往往要几十秒甚至几分钟，这时候A2A的异步设计就派上用场了。

我们把Agent A的tasks/send逻辑改一下：收到任务后立刻返回status: "working"，同时把任务丢到后台线程去跑，完成后更新任务状态。客户端这边则通过轮询tasks/get来获取最新状态：

python复制# 服务端：异步任务实现（简化版）
task_store = {}

@app.post("/")
async def handle_rpc(req: JsonRpcRequest):
    if req.method == "tasks/send":
        task_id = req.params.id
        text = "".join([p.text for p in req.params.message.parts if p.kind == "text"])
        task_store[task_id] = {"status": "working"}
        asyncio.create_task(background_review(task_id, text))
        return {"jsonrpc": "2.0", "id": req.id, "result": {"id": task_id, "status": "working"}}
    elif req.method == "tasks/get":
        task = task_store.get(req.params.id)
        return {"jsonrpc": "2.0", "id": req.id, "result": task}

javascript复制// 客户端：轮询任务状态
async function waitForTask(taskId) {
  for (let i = 0; i < 30; i++) {
    const res = await fetch(AGENT_A_URL, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        jsonrpc: '2.0', id: 3, method: 'tasks/get',
        params: { id: taskId }
      })
    });
    const data = await res.json();
    if (data.result.status === 'completed' || data.result.status === 'failed') {
      return data.result;
    }
    await new Promise(r => setTimeout(r, 2000));
  }
  throw new Error('任务超时');
}

这个异步轮询模型虽然简单，但覆盖了绝大多数长耗时Agent任务的场景。真需要实时反馈时，再升级到SSE或WebSocket。

6. 我在实际接入A2A时踩过的坑和积累的经验

最后这部分，是我在把A2A落地到一个真实的多智能体协作项目时遇到的几个突出问题。整理出来，希望帮你省点时间。

6.1 Agent Card路径规范不一致

A2A规范里Agent Card的标准路径是/.well-known/agent-card.json，但我在对接某些第三方Agent实现时发现，有些实现把Agent Card放在根路径的/agent.gc，有些放在/card.json。这导致客户端必须写一整套“路径探测逻辑”：先试标准路径，不行再试备选路径。更麻烦的是，有些Agent服务端返回的Content-Type是application/json，有些确实是application/agent-card+json，解析JSON本身没问题，但要检查Content-Type时会遇到各种意外。

解决思路是：客户端解析Agent Card时不能假设URL只有一个，要允许用户手动配置Agent入口地址；服务端发布Agent Card时应同时支持/.well-known/agent-card.json和/agent.gc两个路径，确保最大兼容性。我在自己的项目里干脆写了一个discoverAgentCard(baseUrl)函数，内部依次尝试多个路径，拿到第一个有效的结果就返回。

6.2 taskId的生成方式与幂等性

A2A规范要求客户端生成taskId，但taskId的格式没有严格限制。这听起来是好事，实际却是个隐蔽的坑：如果两个客户端都用“类似日期时间戳”的ID生成策略，在高并发下有可能产生重复ID，导致服务端把两个不同任务当成同一个任务，直接返回了第一次执行的结果。

我在客户端统一改用UUID v7或完整UUID作为taskId。UUID v7带时间戳前缀，既能保证唯一性，又天然按时间有序，索引查询也更快。服务端则要加一层去重校验：如果收到的taskId已经存在且状态为completed，直接返回缓存的Artifact，而不是重新执行。

6.3 任务状态不按预期顺序流转时的处理

A2A任务状态机允许从working跳回input-required，这是为了处理“Agent发现自己缺参数，反过来问调用方要信息”的场景。这个机制本身很灵活，但客户端如果不加处理，很容易死循环——用户提交任务后发现状态变成input-required，不知道该怎么办，整个工作流就卡住了。

我在客户端做了一个“状态机守卫”：限制input-required状态的最高触发次数（默认3次），并且每次进入这个状态时都要向上抛出一个结构化异常，由上层工作流决定是补充参数后重启任务，还是终止任务转为人工处理。这个设计在一开始就避免了很多后续的麻烦。

6.4 错误码语义不统一

JSON-RPC标准定义了错误码范围，但A2A协议真正执行时，不同实现返回的错误信息差异很大。有的返回-32000表示“服务端错误”，有的返回500，有的干脆把业务异常堆栈直接拼在error.data里返回。我在客户端统一封装了一个A2AErrorMapper，把常见的错误码映射为内部标准错误类型，这样上层业务代码不需要感知具体某个Agent的错误风格。

6.5 关于“流式输出”的兼容性

A2A的流式模式（streaming: true）不是所有Agent都实现了。你在Agent Card里看到了"streaming": true，以为对方支持流式传输，实际调用时却发现对方在tasks/send里直接同步返回了结果，完全没有走SSE通道。这说明Agent Card里的能力声明是一种“愿望清单”，不是“承诺清单”，客户端必须对每个能力做运行时的兼容判断。

我在做集成时用的策略是：优先尝试流式，如果检测到响应头不是text/event-stream，立刻退化为普通JSON解析模式。通过这种“自适应降级”机制，同一个客户端既能对接支持流式的Agent，也能兼容只支持同步响应的Agent。

第7部分：个人体会与下一步思考

在把自己的多智能体系统接入A2A协议之后，最大的感触是：它把一个曾经“每个团队各搞一套”的问题，变成了一套有标准答案的工程问题。以前跨框架协作靠文档、靠运气、靠大量的胶水代码；现在靠一个Agent Card加上标准JSON-RPC消息，就能把不同团队、不同语言、不同框架的Agent粘起来。这种感觉，很像当年的“接口标准化”运动——把业务系统间的对接成本，从“定制开发”降到了“配置对接”。

如果你正准备在自己的项目里引入A2A，我的建议是别一上来就追求完整实现所有能力。先把Agent Card发布出去，再实现tasks/send和tasks/get两个核心方法，走通同步调用链路；等有真实的长耗时任务需求时，再逐步补充SSE推送、WebSocket流式、OAuth2认证这些能力。小步快跑，永远比憋一个大版本更靠谱。

最后分享一个小技巧：A2A在对接过程中，最值钱的调试工具不是IDE断点，而是抓包工具。能看到完整的JSON-RPC请求和响应体，你就能快速判断问题是出在协议理解不一致、参数格式不匹配，还是认证头缺失。把抓包结果和Agent Card对比着看，90%的对接问题都能在几分钟内定位。这一点，对那些做跨团队Agent集成的人来说，应该会省下不少沟通成本。