MCP 解决了 Agent ↔ 工具，谁来解决 Agent ↔ Agent？

上一篇讲了 MCP：一个 Agent 通过标准协议连接工具服务。工具是被动的——它等待被调用，执行，返回结果。怎么说呢，

使用者痛点：在实际项目中。很多业务流程需要多个具备自主决策能力的 Agent 协同工作，而不是单纯调用工具。缺乏统一的协作机制会导致：

• 代码里硬编码各种 Agent 名称，维护成本高；
• 跨团队、跨服务的 Agent 难以发现和调用；
• 业务需求变更时需要改动 orchestrator，风险大且容易出错。

但有些场景里你需要委托的不是一个工具。而是另一个有自主决策能力的 Agent：

• 你有一个研究型 Agent，擅长收集和分析技术资料；
• 你有一个写作型 Agent，擅长把分析结论转化成可读文档；老实说，
• 你有一个代码审查 Agent。擅长发现安全问题，不过，

当这三个 Agent 需要协作时它们之间怎么沟通？谁知道谁的存在，怎么传递工作？不过，这就是 A2A协议 要解决的问题。

MCP： Agent ←→ 工具/数据源
再看A2A，Agent ←→ Agent 

A2A 的三个主要概念

AgentCard：Agent 的"名片"

每个 Agent 发布一张 AgentCard描述它能做什么：

from a2a.types import AgentCard。AgentSkill
def make_skill:
s = AgentSkill
s.id = skill_id
s.name = name
s.description = description
s.tags.extend
return s
research_card = AgentCard
research_card.name = "research-agent"
research_card.description = "Gars factual background on technical topics"
research_card.skills.append(
make_skill
)

AgentCard 的关键字段：namedescriptionskills。 这就像是 OpenAPI Spec 的 Agent 版本——机器可读的能力声明。

Task的观点是，工作单元

Agent 间传递的不是函数调用，而是 Task

from a2a.types import Task,TaskState,Message,Part。Role
import uuid
task = Task
task.id = str)
task.status.state = TaskState.TASK_STATE_SUBMITTED
# 输入：User 角色的 Message
msg = Message
msg.role = Role.ROLE_USER
part = Part
part.text = "Should I use Python or Go?"
msg.parts.append
task.history.append

Task 有生命周期状态：SUBMITTED → WORKING → COMPLETED / FAILED. 完成时Agent 把结果追加为 ROLE_AGENT 的 Message。

Registry：Agent 的黄页

AgentRegistry 存储所有注册的 AgentCard,支持按 tag 发现：

class AgentRegistry:
def register -> None:
self._agents = AgentEntry
def discover -> list:
"""返回所有 skill 包含指定 tag 的 Agent"""
...
def delegate -> Task:
"""创建 Task 并通过注册的 handler 执行"""
...

Demo ：直接调用——简单但耦合

Pain Point：If you hard‑wire orchestration logic,any change in an agent forces you to modify orchestrator code – even across services.

def direct_orchestrator -> str:
research = research_agent_fn # 硬依赖
analysis = analysis_agent_fn # 硬依赖
answer = writing_agent_fn # 硬依赖
return answer

实测结果：

→ calling research_agent
→ calling analysis_agent
→ calling writing_agent
再看Answer。Choose Python if you need rapid development with broad libraries.
Select Go if performance and concurrency are critical...

The functionality works,but orchestrator is tightly coupled to three concrete agents. Replacing any one of m requires code changes – impossible when orchestrator lives in anor service.

Demo ：A2A AgentCard 注册表

Simplify discovery and delegation by using registry:

 registered: research-agent
registered: analysis-agent
registered: writing-agent

Pain Point 消除：No hard‑coded names in orchestrator;new agents can be added without touching business logic.

researchers = registry.discover
# → Found: research-agent — Gars factual background on technical topics
writers = registry.discover
# → Found: writing-agent — Composes clear technical prose from analysis output

The orchestrator now only works with tags:

def a2a_orchestrator -> str:
researchers = registry.discover
t1 = registry.delegate
analysts = registry.discover
t2 = registry.delegate)
writers = registry.discover
t3 = registry.delegate)
return task_output

→ delegating to research-agent
→ delegating to analysis-agent
→ delegating to writing-agent
再看Answer，Choose Python for rapid development;Go for high‑throughput performance...

Pain Point 消失：If you later register writing-agent-v2,which carries same “writing” tag,orchestrator automatically picks it up – zero code changes.

Demo ：LLM 驱动的 Agent 路由

The most powerful use case is letting an LLM read Agen​tCard catalog & decide which agents to call and in what order.

Available agents:
research-agent:
description: Gars factual background
skills的观点是。analysis-agent:
description: Analyzes research notes
skills这方面，writing-agent:
description: Composes technical prose
说到skills，

L​LM 输出执行计划：

The runner n follows that plan:

Executing agents:
→ delegating to research-agent
→ delegating to analysis-agent
→ delegating to writing-agent
Final answer: Choose Python for rapid development;Go for high‑throughput...

This demonstrates A2A’s ultimate goal – no pre‑written orchestrator is needed;LLM dynamically composes collaboration chain based on task requirements.

MCP vs A2A vs ANP：协议选型矩阵

Task #耦合方式

维度 / 协议	MCP	A2A
解决什么问题	Agent ↔ 工具/数据源	Agent ↔ Agent
发现机制	list_tools	discover	工作单元 Tool call

MCP 与 A2A 对比要点:

• MCP: 被动工具服务。调用同步,适合“同一代码库内、已知工具”。
• A₂Ａ: 主动代理。可发现、可组合,解耦跨团队或跨组织场景。

四种协作方式完整选型表 :

场景	推荐方法
同一代码库，调用确定	直接函数调用
Agent 需要 调用外部工具  ​ ​ ​   ​ ​ ​

---

STOP

---