文章摘要
2026 年,AI Agent 生态已从单一工具调用演进为多层协议栈。MCP 解决工具接入、A2A 实现 Agent 协调、AG-UI/A2UI 处理界面流式与状态同步、AP2 统一管理 Agent 生命周期、X42 提供跨域信任治理。本文系统梳理 6 大协议的定位、技术细节、适用场景和组合使用模式,帮你构建生产级多 Agent 系统。
1为什么需要协议栈:从「单 Agent」到「Agentic Web」
2024 年,我们谈论的是「Agent 调用工具」;2026 年,我们谈论的是「Agent 组成的 Web」。
这个转变带来了根本性的架构挑战。想象一下:你有 5 个 Agent——一个负责搜索、一个负责代码生成、一个负责数据分析、一个负责邮件发送、一个负责审批流程。它们需要:
- 访问工具:搜索 Agent 需要调用 Google、代码 Agent 需要访问 GitHub、数据 Agent 需要查询数据库
- 相互协作:代码 Agent 生成代码后,需要数据 Agent 验证结果,然后邮件 Agent 发送报告
- 与用户交互:审批 Agent 需要向用户展示表单,用户填写后状态需要实时同步回 Agent
- 跨域信任:公司 A 的 Agent 调用公司 B 的 Agent 时,如何验证身份、控制权限、审计行为?
如果没有标准协议,每个集成点都需要自定义开发。 5 个 Agent × 10 个工具 = 50 个集成点。5 个 Agent × 5 个 Agent = 25 个协作接口。复杂度呈指数级增长。
这就是为什么 2026 年出现了 6 大 Agent 协议。 它们不是竞争关系,而是分层协作:
| 协议 | 层级 | 解决的问题 | 类比 |
|---|---|---|---|
| MCP | 工具接入层 | Agent 如何调用外部工具和 API | USB-C 接口 |
| A2A | Agent 协调层 | Agent 之间如何发现、委托、协作 | HTTP 协议 |
| AG-UI | 界面流式层 | Agent 输出如何实时推送到 UI | WebSocket |
| A2UI | 界面状态层 | Agent 状态如何与 UI 持久化同步 | Redux Store |
| AP2 | Agent 管理层 | 如何统一管理 Agent 生命周期 | Kubernetes API |
| X42 | 信任治理层 | 跨域 Agent 调用的身份、权限、审计 | OAuth 2.0 + SAML |
关键洞察: 一个完整的多 Agent 应用可能同时使用所有 6 个协议。MCP 让 Agent 调用工具,A2A 让 Agent 之间协作,AG-UI/A2UI 让 Agent 与用户交互,AP2 管理 Agent 本身,X42 确保跨域安全。
💡 一句话理解
大多数团队今天主要使用 MCP 和 A2A。AG-UI/A2UI 用于复杂交互场景,AP2/X42 在企业级多租户环境中必不可少。
⚠️ 常见踩坑
不要试图一次性引入所有协议。从 MCP 开始,当需要多 Agent 协作时加入 A2A,当 UI 交互复杂时考虑 AG-UI/A2UI。
2MCP(Model Context Protocol):工具接入的事实标准
MCP 是 2026 年最成功的 Agent 协议,没有之一。
Anthropic 在 2024 年 11 月开源 MCP 时,目标是解决一个简单问题:让 Agent 以统一方式调用外部工具。一年半后,MCP 已成为 AI 行业的「USB-C」:
2026 年 6 月数据:
- 10,000+ 公开 MCP Server(Linux Foundation 统计)
- 1.64 亿次/月 Python SDK 下载量(PyPI 数据)
- 9700 万次/月 TypeScript SDK 下载量
- 所有主流 AI 平台支持:Anthropic Claude、OpenAI ChatGPT、Google Gemini、Microsoft Copilot
- Linux Foundation 治理:2025 年 12 月 Anthropic 捐赠给 Agentic AI Foundation(AAIF)
MCP 的核心设计
MCP 基于 JSON-RPC 2.0,定义了三种核心能力:
1. Tools(工具):Agent 可以调用的函数
2. Resources(资源):Agent 可以读取的数据源
3. Prompts(提示词模板):预定义的交互模式
MCP 的传输层演进
2024 年: 仅支持 stdio(本地进程通信)
2025 年: 加入 SSE(Server-Sent Events,HTTP 长连接)
2026 年: 支持 Streamable HTTP(双向流式通信)和 WebSocket
为什么传输层如此重要? 因为传输层决定了 MCP Server 可以部署在哪里:
- stdio:只能本地部署,适合开发工具(Cursor、VS Code 插件)
- SSE:可以远程部署,但单向通信,适合只读场景
- Streamable HTTP:双向流式,适合实时交互(审批流程、聊天机器人)
- WebSocket:全双工,适合高频通信(游戏 AI、实时协作)
MCP Apps:从文本到交互式 UI
2026 年 1 月,MCP 迎来最大突破:MCP Apps。
在此之前,所有 MCP 交互都是文本-based。Agent 调用工具,工具返回文本结果。但很多场景需要富交互:
- 用户需要在数据表格中筛选、排序
- 用户需要在设计稿上标注、修改
- 用户需要在表单中填写多个字段
MCP Apps 让工具可以返回 HTML 界面,渲染在沙箱 iframe 中。 用户可以直接在聊天窗口中操作,无需跳转到外部应用。
安全模型:
- iframe 沙箱隔离(sandbox="allow-forms allow-scripts")
- 预声明模板(防止 XSS)
- 可审计的 JSON-RPC 消息
- 用户同意机制(UI 发起的工具调用需要用户确认)
首批合作伙伴: Amplitude、Asana、Box、Canva、Clay、Figma、Hex、monday.com、Slack、Salesforce
# MCP Server 示例:GitHub 搜索工具
from mcp.server import Server
from mcp.types import Tool, TextContent
import httpx
server = Server("github-search")
@server.tool(
name="search_repos",
description="搜索 GitHub 仓库",
inputSchema={
"type": "object",
"properties": {
"query": {"type": "string"},
"language": {"type": "string", "enum": ["python", "javascript", "go"]},
"sort": {"type": "string", "enum": ["stars", "forks", "updated"]}
},
"required": ["query"]
}
)
async def search_repos(query: str, language: str = None, sort: str = "stars"):
"""搜索 GitHub 仓库并返回结果"""
async with httpx.AsyncClient() as client:
params = {"q": query, "sort": sort}
if language:
params["language"] = language
resp = await client.get(
"https://api.github.com/search/repositories",
params=params,
headers={"Accept": "application/vnd.github.v3+json"}
)
data = resp.json()
# 格式化结果
results = []
for repo in data["items"][:10]:
results.append({
"name": repo["full_name"],
"stars": repo["stargazers_count"],
"description": repo["description"],
"url": repo["html_url"]
})
return TextContent(
type="text",
text=f"找到 {len(results)} 个仓库:\n" +
"\n".join([f"- {r['name']} ({r['stars']}⭐): {r['description']}"
for r in results])
)
# 启动服务器
if __name__ == "__main__":
import asyncio
from mcp.server.stdio import stdio_server
async def main():
async with stdio_server() as (read, write):
await server.run(read, write)
asyncio.run(main())// Claude Desktop MCP 配置 (claude_desktop_config.json)
{
"mcpServers": {
"github": {
"command": "python",
"args": ["/path/to/github_server.py"],
"env": {
"GITHUB_TOKEN": "ghp_..."
}
},
"database": {
"command": "node",
"args": ["/path/to/db_server.js"],
"env": {
"DATABASE_URL": "postgresql://..."
}
},
"figma": {
"url": "https://figma-mcp.example.com/sse",
"headers": {
"Authorization": "Bearer figd_..."
}
}
}
}{
"name": "search_github",
"description": "搜索 GitHub 仓库",
"inputSchema": {
"type": "object",
"properties": {
"query": { "type": "string" }
},
"required": ["query"]
}
}{
"uri": "file:///path/to/file.txt",
"name": "配置文件",
"mimeType": "text/plain"
}{
"name": "code_review",
"description": "代码审查流程",
"arguments": [
{
"name": "repo_url",
"description": "GitHub 仓库地址",
"required": true
}
]
}💡 一句话理解
MCP Server 可以本地部署(stdio)或远程部署(SSE/HTTP)。本地部署更安全,远程部署更灵活。
3A2A(Agent-to-Agent):跨平台 Agent 协调标准
如果 MCP 是 Agent 的「手」(调用工具),A2A 就是 Agent 的「嘴」(与其他 Agent 沟通)。
Google 在 2025 年发起 A2A 协议,目标是解决一个 MCP 无法解决的问题:Agent 之间如何协作?
场景: 用户说「帮我分析这个 GitHub 仓库的代码质量,生成报告,发给团队」。
这需要多个 Agent 协作:
- 搜索 Agent:找到目标仓库
- 代码分析 Agent:下载代码、运行静态分析
- 数据可视化 Agent:生成图表
- 报告生成 Agent:整合分析结果和图表
- 邮件 Agent:发送报告
MCP 只能让每个 Agent 调用自己的工具,但无法让 Agent 之间传递任务、共享上下文、协调执行顺序。 这就是 A2A 的价值。
A2A 的核心概念
1. Agent Card(Agent 名片)
2. Task(任务)
3. Message(消息)
A2A 与 MCP 的关系
A2A 和 MCP 是互补的,不是竞争的。
- MCP:Agent → Tool(纵向,调用工具)
- A2A:Agent → Agent(横向,协作任务)
典型架构:
用户请求
↓
编排 Agent(Orchestrator)
├─ A2A → 搜索 Agent
│ └─ MCP → Google Search API
├─ A2A → 代码分析 Agent
│ ├─ MCP → GitHub API
│ └─ MCP → SonarQube API
├─ A2A → 可视化 Agent
│ └─ MCP → Chart.js
└─ A2A → 邮件 Agent
└─ MCP → SendGrid API
关键洞察: 每个 Agent 内部使用 MCP 调用工具,Agent 之间使用 A2A 协调任务。编排 Agent 负责分解任务、分配给专业 Agent、收集结果、整合输出。
A2A 的 2026 年进展
2025 年 8 月: IBM 的 ACP(Agent Communication Protocol)合并入 A2A
2026 年 4 月: A2A v1.0 正式发布,从草案升级为生产标准
治理结构: A2A 和 MCP 一样,由 AAIF(Agentic AI Foundation)管理,AWS、Cisco、Google、IBM、Microsoft、Salesforce、SAP、ServiceNow 联合共建
企业采用: Gartner 预测 2026 年底 40% 的企业应用将包含任务特定 AI Agent,A2A 将成为跨 Agent 协作的默认协议
# A2A Agent 示例:代码分析 Agent
from a2a import Agent, AgentCard, Task, Message
import httpx
class CodeAnalyzerAgent(Agent):
def __init__(self):
super().__init__(
card=AgentCard(
name="code-analyzer",
description="分析代码质量、安全漏洞、性能瓶颈",
capabilities={
"tasks": ["analyze_quality", "detect_vulnerabilities"],
"inputFormats": ["github_url"],
"outputFormats": ["json_report"]
}
)
)
async def handle_task(self, task: Task) -> dict:
"""处理代码分析任务"""
if task.type == "analyze_quality":
repo_url = task.input["repo_url"]
# 使用 MCP 调用 GitHub API 下载代码
code = await self.mcp_call("github", "download_repo", {"url": repo_url})
# 使用 MCP 调用 SonarQube API 分析质量
analysis = await self.mcp_call("sonarqube", "analyze", {"code": code})
return {
"status": "completed",
"result": {
"quality_score": analysis["quality_gate"],
"issues": analysis["issues"],
"coverage": analysis["coverage"]
}
}
async def handle_message(self, message: Message) -> Message:
"""处理来自其他 Agent 的消息"""
if message.type == "task_delegation":
task = Task(
id=message.payload["task_id"],
type=message.payload["task_type"],
input=message.payload["input"]
)
result = await self.handle_task(task)
return Message(
from_agent=self.card.name,
to_agent=message.from_agent,
type="task_result",
payload=result
)
# 启动 Agent
if __name__ == "__main__":
agent = CodeAnalyzerAgent()
agent.run(host="0.0.0.0", port=8080){
"name": "code-analyzer",
"description": "分析代码质量、安全漏洞、性能瓶颈",
"capabilities": {
"tasks": ["analyze_quality", "detect_vulnerabilities", "profile_performance"],
"inputFormats": ["github_url", "local_path"],
"outputFormats": ["json_report", "pdf_report"]
},
"endpoint": "https://agents.example.com/code-analyzer"
}{
"id": "task-123",
"type": "analyze_quality",
"input": {
"repo_url": "https://github.com/example/repo"
},
"status": "running",
"context": {
"parent_task": "task-122",
"shared_data": {"user_email": "user@example.com"}
}
}{
"from": "orchestrator-agent",
"to": "code-analyzer",
"type": "task_delegation",
"payload": {
"task_id": "task-123",
"deadline": "2026-06-16T12:00:00Z",
"priority": "high"
}
}💡 一句话理解
A2A 支持同步和异步两种模式。同步适合快速任务(< 10 秒),异步适合长时间任务(代码分析、数据处理)。
⚠️ 常见踩坑
A2A v1.0 刚发布,生态系统还在建设中。建议先在内部系统使用,等生态成熟后再用于跨组织协作。
4AG-UI 与 A2UI:Agent 与用户的双向交互
MCP 让 Agent 调用工具,A2A 让 Agent 协作,但 Agent 如何与用户交互?
传统的聊天界面只能显示文本。但很多场景需要更丰富的交互:
- 用户需要在数据表格中筛选、排序、导出
- 用户需要在设计稿上标注、修改、审批
- 用户需要在表单中填写多个字段、上传附件
- 用户需要在代码编辑器中查看 diff、接受/拒绝修改
AG-UI 和 A2UI 就是为这些场景设计的。
AG-UI(Agent-User Interface):流式推送
AG-UI 解决的是「Agent 输出如何实时推送到 UI」的问题。
传统方式:Agent 生成完整响应 → 一次性返回 → UI 渲染
AG-UI 方式:Agent 边生成边推送 → UI 实时渲染 → 用户可以中途干预
技术实现: 基于 Server-Sent Events(SSE)或 WebSocket
适用场景:
- 代码生成:实时显示生成的代码,用户可以随时停止
- 数据分析:实时显示查询进度,用户可以中途修改参数
- 审批流程:实时显示待审批内容,用户可以直接在流中批准/拒绝
A2UI(Agent-to-User Interface):状态同步
A2UI 解决的是「Agent 状态如何与 UI 持久化同步」的问题。
AG-UI 是流式的,断开就没了。A2UI 是持久化的,状态保存在服务端,用户可以刷新页面、切换设备、离线查看。
技术实现: 基于 Redux-like 状态管理 + 服务端持久化
适用场景:
- 多步骤表单:用户填写一部分,保存,明天继续
- 团队协作:多个用户同时编辑同一个 Agent 的状态
- 离线支持:用户在飞机上查看 Agent 状态,落地后自动同步
AG-UI vs A2UI:如何选择?
| 维度 | AG-UI | A2UI |
|---|---|---|
| 数据持久化 | 不持久化,断开即丢失 | 持久化,可恢复 |
| 实时性 | 极高(毫秒级) | 较高(秒级) |
| 复杂度 | 低 | 高 |
| 适用场景 | 实时流式输出 | 长期状态管理 |
| 典型应用 | 聊天机器人、代码生成 | 项目管理、审批流程 |
关键洞察: AG-UI 和 A2UI 不是二选一,而是经常组合使用。AG-UI 负责实时流式输出(如 Agent 正在思考),A2UI 负责持久化状态(如任务列表、表单数据)。
// AG-UI + A2UI 组合示例:代码审查工具
import { Agent } from '@agent-sdk/core';
import { AGUIStream } from '@agent-sdk/ag-ui';
import { A2UIStore } from '@agent-sdk/a2-ui';
class CodeReviewAgent extends Agent {
private agui: AGUIStream;
private a2ui: A2UIStore;
constructor() {
super();
this.agui = new AGUIStream();
this.a2ui = new A2UIStore();
}
async reviewCode(repoUrl: string) {
// AG-UI: 实时推送进度
this.agui.push({ type: 'status', content: '正在下载代码...' });
const code = await this.downloadCode(repoUrl);
this.agui.push({ type: 'status', content: '正在分析代码...' });
const issues = await this.analyzeCode(code);
// A2UI: 持久化问题列表
this.a2ui.update({
issues: issues,
resolvedIssues: [],
comments: {}
});
// AG-UI: 请求用户确认
this.agui.push({
type: 'confirmation',
content: `发现 ${issues.length} 个问题,是否生成修复建议?`,
actions: ['yes', 'no', 'view_issues']
});
// 等待用户响应
const userAction = await this.agui.waitForAction();
if (userAction === 'yes') {
// AG-UI: 流式生成修复建议
for (const issue of issues) {
this.agui.push({ type: 'token', content: `正在修复 ${issue.file}...` });
const fix = await this.generateFix(issue);
this.agui.push({ type: 'code_diff', file: issue.file, diff: fix });
// A2UI: 更新修复状态
this.a2ui.update({
resolvedIssues: [...this.a2ui.state.resolvedIssues, issue.id]
});
}
}
}
}// AG-UI 流式推送示例
const eventSource = new EventSource('/agent/stream');
eventSource.onmessage = (event) => {
const data = JSON.parse(event.data);
switch (data.type) {
case 'token':
// 实时显示生成的文本
appendText(data.content);
break;
case 'tool_call':
// 显示工具调用进度
showToolProgress(data.tool, data.status);
break;
case 'confirmation':
// 请求用户确认
showConfirmationDialog(data.message, data.actions);
break;
}
};// A2UI 状态同步示例
interface AgentState {
tasks: Task[];
currentTask: string;
formData: Record<string, any>;
approvals: Approval[];
}
// Agent 更新状态
agent.updateState({
currentTask: 'task-123',
formData: { name: 'Alice', email: 'alice@example.com' }
});
// UI 订阅状态变化
store.subscribe(() => {
const state = store.getState();
renderForm(state.formData);
renderTaskList(state.tasks);
});
// 用户修改表单
store.dispatch({
type: 'UPDATE_FORM',
payload: { email: 'alice.new@example.com' }
});
// Agent 收到状态变化通知
agent.onStateChange((newState) => {
console.log('用户修改了表单:', newState.formData);
});💡 一句话理解
AG-UI 适合「实时流」场景(聊天、代码生成),A2UI 适合「长期状态」场景(项目管理、审批流程)。两者可以组合使用。
⚠️ 常见踩坑
A2UI 需要服务端持久化存储,增加了架构复杂度。如果只是简单的聊天机器人,用 AG-UI 就够了。
5AP2 与 X42:企业级 Agent 管理与信任治理
前 4 个协议(MCP、A2A、AG-UI、A2UI)解决了 Agent 的功能问题。AP2 和 X42 解决的是 Agent 的管理和安全问题。
当你的组织有 100 个 Agent、1000 个用户、跨 10 个部门时,你需要:
- 统一管理:如何发现 Agent、监控 Agent、部署 Agent、升级 Agent?
- 身份认证:如何验证 Agent 的身份?如何防止恶意 Agent?
- 权限控制:Agent A 能调用 Agent B 吗?能访问哪些数据?
- 审计追踪:Agent 做了什么?谁授权的?结果如何?
AP2 和 X42 就是为企业级场景设计的。
AP2(Agent Protocol 2):Agent 生命周期管理
AP2 的目标是成为「Agent 的 Kubernetes」。
就像 Kubernetes 统一管理容器的部署、扩缩容、健康检查、日志收集,AP2 统一管理 Agent 的整个生命周期。
核心功能:
1. Agent 注册与发现
2. Agent 部署与升级
3. Agent 监控与日志
X42:跨域信任与治理
X42 的目标是成为「Agent 的 OAuth 2.0 + SAML」。
当公司 A 的 Agent 调用公司 B 的 Agent 时,需要解决:
- 身份认证:公司 A 的 Agent 是谁?公司 B 如何验证?
- 权限授权:公司 A 的 Agent 能调用公司 B 的哪些工具?能访问哪些数据?
- 审计追踪:调用记录如何保存?如何防止滥用?
X42 的核心机制:
1. 分布式身份(DID)
2. 能力凭证(Verifiable Credentials)
3. 审计日志
AP2 vs X42:分工明确
| 维度 | AP2 | X42 |
|---|---|---|
| 关注点 | Agent 生命周期 | 跨域信任 |
| 核心功能 | 部署、扩缩容、监控 | 身份、权限、审计 |
| 适用场景 | 组织内部 | 跨组织协作 |
| 类比 | Kubernetes | OAuth 2.0 + SAML |
| 技术栈 | YAML 配置、CLI 工具 | DID、VC、ZKP |
关键洞察: AP2 和 X42 通常一起使用。AP2 管理组织内部的 Agent,X42 管理跨组织的信任。例如:公司用 AP2 部署 100 个 Agent,用 X42 让这些 Agent 安全地调用合作伙伴的 Agent。
# AP2 实战:部署和管理 Agent
# 1. 部署 Agent
ap2 apply -f - <<EOF
apiVersion: ap2/v1
kind: Agent
metadata:
name: code-reviewer
namespace: engineering
spec:
image: agents/code-reviewer:v1.2.3
replicas: 3
capabilities:
- code_review
- vulnerability_detection
resources:
requests:
cpu: "2"
memory: "4Gi"
scaling:
minReplicas: 2
maxReplicas: 10
targetCPU: 70%
EOF
# 2. 查看 Agent 状态
ap2 get agents -n engineering
NAME READY STATUS RESTARTS AGE
code-reviewer 3/3 Running 0 5m
# 3. 查看 Agent 日志
ap2 logs agent/code-reviewer --tail=50
# 4. 升级 Agent
ap2 set image agent/code-reviewer agents/code-reviewer:v1.3.0
# 5. 回滚
ap2 rollout undo agent/code-reviewer
# 6. 查看 Agent 指标
ap2 top agent -n engineering
NAME CPU MEMORY REQUESTS/s LATENCY
code-reviewer 2.3/4 5.2/8G 120 450ms# X42 实战:跨域 Agent 调用
from x42 import X42Client, DID, VerifiableCredential
import asyncio
async def cross_org_agent_call():
# 1. 加载身份
my_did = DID.load("did:x42:agent:data-analyzer:company-b")
my_key = my_did.load_key("key-1")
# 2. 获取目标 Agent 的 DID 文档
target_did = await DID.resolve("did:x42:agent:code-reviewer:company-a")
target_endpoint = target_did.service[0].serviceEndpoint
# 3. 创建能力凭证(证明我有权调用)
credential = VerifiableCredential(
issuer=my_did,
subject=my_did,
capability={
"invoke": ["code_review"],
"access": ["github:company-b/*"],
"quota": {"requests_per_day": 1000}
}
)
await credential.sign(my_key)
# 4. 调用目标 Agent
client = X42Client()
response = await client.invoke(
endpoint=target_endpoint,
action="code_review",
input={"repo": "github.com/company-b/backend"},
credential=credential
)
print(f"发现 {response['issues']} 个问题")
asyncio.run(cross_org_agent_call())# ap2-agent.yaml
apiVersion: ap2/v1
kind: Agent
metadata:
name: code-reviewer
namespace: engineering
labels:
team: backend
tier: production
spec:
image: agents/code-reviewer:v1.2.3
replicas: 3
capabilities:
- code_review
- vulnerability_detection
resources:
requests:
cpu: "2"
memory: "4Gi"
limits:
cpu: "4"
memory: "8Gi"
healthCheck:
path: /health
interval: 30s
scaling:
minReplicas: 2
maxReplicas: 10
targetCPU: 70%# 部署 Agent
ap2 apply -f ap2-agent.yaml
# 查看 Agent 状态
ap2 get agents -n engineering
NAME READY STATUS RESTARTS AGE
code-reviewer 3/3 Running 0 5m
# 升级 Agent
ap2 set image agent/code-reviewer agents/code-reviewer:v1.3.0
# 回滚
ap2 rollout undo agent/code-reviewer# 查看 Agent 日志
ap2 logs agent/code-reviewer --tail=100
# 查看 Agent 指标
ap2 top agent -n engineering
NAME CPU MEMORY REQUESTS/s LATENCY
code-reviewer 2.3/4 5.2/8G 120 450ms
data-analyzer 1.8/2 3.1/4G 85 620ms{
"id": "did:x42:agent:code-reviewer:company-a",
"verificationMethod": [{
"id": "#key-1",
"type": "Ed25519VerificationKey2020",
"publicKeyMultibase": "z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
}],
"service": [{
"id": "#agent-endpoint",
"type": "AgentService",
"serviceEndpoint": "https://agents.company-a.com/code-reviewer"
}]
}{
"@context": "https://www.w3.org/2018/credentials/v1",
"type": ["VerifiableCredential", "AgentCapabilityCredential"],
"issuer": "did:x42:org:company-a",
"issuanceDate": "2026-06-16T00:00:00Z",
"expirationDate": "2027-06-16T00:00:00Z",
"credentialSubject": {
"id": "did:x42:agent:code-reviewer:company-a",
"capability": {
"invoke": ["code_review", "vulnerability_detection"],
"access": ["github:company-a/*", "jira:company-a/*"],
"quota": {
"requests_per_day": 10000,
"max_payload_size": "10MB"
}
}
},
"proof": {
"type": "Ed25519Signature2020",
"created": "2026-06-16T00:00:00Z",
"verificationMethod": "did:x42:org:company-a#key-1",
"proofValue": "z58DAdFfa9SkqZMVPxAQpic7ndTn3nnz..."
}
}{
"timestamp": "2026-06-16T10:30:00Z",
"caller": "did:x42:agent:data-analyzer:company-b",
"callee": "did:x42:agent:code-reviewer:company-a",
"action": "code_review",
"input": {"repo": "github.com/company-a/backend"},
"output": {"issues": 15, "vulnerabilities": 2},
"duration_ms": 4500,
"authorized_by": "did:x42:policy:cross-org-access"
}💡 一句话理解
AP2 适合有 10+ Agent 的中大型组织。如果只有 2-3 个 Agent,直接用 Docker/Kubernetes 就够了。
⚠️ 常见踩坑
X42 依赖 DID 和 VC 等 Web3 技术,学习曲线较陡。建议先在内部系统使用简单的 API Key + OAuth 2.0,等跨域需求明确后再引入 X42。
6协议选型与组合:生产级多 Agent 架构设计
6 个协议不是都要用,而是根据场景选择。
场景 1:单 Agent + 工具调用
需求: 一个 Agent 调用 GitHub、数据库、邮件等工具
协议选择: 仅 MCP
架构:
用户 → Agent → MCP → [GitHub, Database, Email]
复杂度: 低
典型应用: 个人助手、开发工具
场景 2:多 Agent + 工具调用
需求: 多个专业 Agent 协作完成复杂任务
协议选择: MCP + A2A
架构:
用户 → 编排 Agent
├─ A2A → 搜索 Agent → MCP → Google
├─ A2A → 代码 Agent → MCP → GitHub
└─ A2A → 邮件 Agent → MCP → SendGrid
复杂度: 中
典型应用: 企业工作流自动化、数据分析平台
场景 3:多 Agent + 复杂 UI 交互
需求: 多 Agent 协作,且需要丰富的用户交互(表单、审批、实时进度)
协议选择: MCP + A2A + AG-UI + A2UI
架构:
用户 ←→ AG-UI/A2UI ←→ 编排 Agent
├─ A2A → 搜索 Agent → MCP → Google
├─ A2A → 代码 Agent → MCP → GitHub
└─ A2A → 审批 Agent → MCP → Jira
复杂度: 高
典型应用: 项目管理工具、代码审查平台、审批系统
场景 4:企业级多租户多 Agent
需求: 100+ Agent、1000+ 用户、跨部门/跨组织协作
协议选择: MCP + A2A + AG-UI + A2UI + AP2 + X42
架构:
用户 ←→ AG-UI/A2UI ←→ 编排 Agent
├─ A2A → Agent A → MCP → 工具
├─ A2A → Agent B → MCP → 工具
└─ A2A → Agent C(跨组织)→ X42 认证AP2 管理平面:监控、部署、扩缩容所有 Agent
X42 信任层:跨域身份、权限、审计
复杂度: 极高
典型应用: SaaS 平台、企业级 AI 中台、跨组织协作网络
协议选型决策树
需要调用外部工具?
├─ 否 → 不需要 MCP
└─ 是 → 使用 MCP
│
需要多个 Agent 协作?
├─ 否 → 仅 MCP
└─ 是 → 使用 MCP + A2A
│
需要复杂 UI 交互(表单、审批、实时进度)?
├─ 否 → MCP + A2A
└─ 是 → 使用 MCP + A2A + AG-UI/A2UI
│
100+ Agent 或跨组织协作?
├─ 否 → MCP + A2A + AG-UI/A2UI
└─ 是 → 使用全部 6 个协议
2026 年协议成熟度评估
| 协议 | 成熟度 | 生态系统 | 企业采用 | 建议 |
|---|---|---|---|---|
| MCP | ⭐⭐⭐⭐⭐ | 10,000+ Server | 广泛 | 立即采用 |
| A2A | ⭐⭐⭐⭐ | v1.0 发布 | 快速增长 | 立即采用 |
| AG-UI | ⭐⭐⭐ | 主流框架支持 | 中等 | 复杂 UI 场景采用 |
| A2UI | ⭐⭐⭐ | 新兴 | 早期 | 长期状态场景评估 |
| AP2 | ⭐⭐ | 开源项目 | 早期 | 大型组织试点 |
| X42 | ⭐⭐ | 标准制定中 | 实验性 | 跨域需求明确后采用 |
关键洞察: MCP 和 A2A 是 2026 年的「安全选择」,生态成熟、企业广泛采用。AG-UI/A2UI 适合特定场景。AP2/X42 还在早期,建议观望或小范围试点。
💡 一句话理解
从 MCP 开始,逐步扩展。不要试图一次性引入所有协议。每增加一个协议,架构复杂度都会显著上升。
⚠️ 常见踩坑
协议选型要考虑团队能力。AP2/X42 需要 Web3 和 Kubernetes 经验,如果团队不熟悉,建议先外包或等待更成熟的托管服务。
7未来展望:协议融合与 Agentic Web
2026 年的 6 大协议,可能会在 2027-2028 年融合为 3 层标准栈。
预测 1:MCP + A2A 合并为「Agent Communication Protocol(ACP)」
理由: MCP 和 A2A 的边界越来越模糊。很多 MCP Server 开始支持 Agent 间调用,很多 A2A 实现开始内置 MCP。
可能方案:
预测 2:AG-UI + A2UI 合并为「Agent Interface Protocol(AIP)」
理由: AG-UI 和 A2UI 解决的是同一个问题的两个方面(实时流 vs 持久化状态),合并后可以统一 API。
可能方案:
- AIP 定义统一的「Agent 状态」概念
- 实时流是状态的「增量更新」
- 持久化是状态的「快照」
预测 3:AP2 融入 Kubernetes,X42 融入 OAuth 2.1
理由: AP2 和 Kubernetes 的理念高度一致(声明式配置、控制器模式、健康检查),X42 的 DID/VC 正在被 W3C 标准化,未来可能直接融入 OAuth 2.1。
可能方案:
- Kubernetes 原生支持 Agent CRD(Custom Resource Definition)
- OAuth 2.1 原生支持 DID 和 VC
2030 年的 Agentic Web
想象 2030 年:
- Agent 浏览器:像浏览器浏览网页一样,Agent 可以「浏览」其他 Agent
- Agent 搜索引擎:像 Google 搜索网页一样,搜索可用的 Agent
- Agent 应用商店:像 App Store 一样,下载、安装、评价 Agent
- Agent 社交网络:Agent 之间建立信任关系、协作网络、声誉系统
技术基础:
- ACP(MCP + A2A 合并):Agent 之间的通信协议
- AIP(AG-UI + A2UI 合并):Agent 与用户的交互协议
- Kubernetes + OAuth 2.1:Agent 的管理和信任基础设施
关键洞察: 我们正处于 Agentic Web 的早期,就像 1995 年的互联网。今天的 6 大协议,就像早期的 HTTP、SMTP、FTP、IRC——有些会消失,有些会合并,有些会成为基础设施。但无论如何,Agent 之间的标准化通信,将是未来 10 年最重要的技术趋势之一。
💡 一句话理解
关注 W3C 的 AI Agent Protocol Community Group,他们正在制定 Agent 通信的 Web 标准,预计 2027 年发布第一版规范。
⚠️ 常见踩坑
协议融合需要时间。2026-2027 年,仍然需要使用现有的 6 大协议。不要等待「完美标准」,先用现有协议构建产品。