💡

文章摘要

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——一个负责搜索、一个负责代码生成、一个负责数据分析、一个负责邮件发送、一个负责审批流程。它们需要:

  1. 访问工具:搜索 Agent 需要调用 Google、代码 Agent 需要访问 GitHub、数据 Agent 需要查询数据库
  2. 相互协作:代码 Agent 生成代码后,需要数据 Agent 验证结果,然后邮件 Agent 发送报告
  3. 与用户交互:审批 Agent 需要向用户展示表单,用户填写后状态需要实时同步回 Agent
  4. 跨域信任:公司 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

python
# 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())
json
// 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_..."
      }
    }
  }
}
json
{
  "name": "search_github",
  "description": "搜索 GitHub 仓库",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string" }
    },
    "required": ["query"]
  }
}
json
{
  "uri": "file:///path/to/file.txt",
  "name": "配置文件",
  "mimeType": "text/plain"
}
json
{
  "name": "code_review",
  "description": "代码审查流程",
  "arguments": [
    {
      "name": "repo_url",
      "description": "GitHub 仓库地址",
      "required": true
    }
  ]
}

💡 一句话理解

MCP Server 可以本地部署(stdio)或远程部署(SSE/HTTP)。本地部署更安全,远程部署更灵活。

⚠️ 常见踩坑

MCP Apps 的 iframe 沙箱默认禁用脚本。如果需要交互式 UI,必须显式声明 sandbox="allow-scripts",并确保工具调用需要用户确认。

3A2A(Agent-to-Agent):跨平台 Agent 协调标准

如果 MCP 是 Agent 的「手」(调用工具),A2A 就是 Agent 的「嘴」(与其他 Agent 沟通)。

Google 在 2025 年发起 A2A 协议,目标是解决一个 MCP 无法解决的问题:Agent 之间如何协作?

场景: 用户说「帮我分析这个 GitHub 仓库的代码质量,生成报告,发给团队」。

这需要多个 Agent 协作:

  1. 搜索 Agent:找到目标仓库
  2. 代码分析 Agent:下载代码、运行静态分析
  3. 数据可视化 Agent:生成图表
  4. 报告生成 Agent:整合分析结果和图表
  5. 邮件 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 协作的默认协议

图表加载中…
python
# 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)
json
{
  "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"
}
json
{
  "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"}
  }
}
json
{
  "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 负责持久化状态(如任务列表、表单数据)。

typescript
// 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]
        });
      }
    }
  }
}
typescript
// 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;
  }
};
typescript
// 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 个部门时,你需要:

  1. 统一管理:如何发现 Agent、监控 Agent、部署 Agent、升级 Agent?
  2. 身份认证:如何验证 Agent 的身份?如何防止恶意 Agent?
  3. 权限控制:Agent A 能调用 Agent B 吗?能访问哪些数据?
  4. 审计追踪: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 时,需要解决:

  1. 身份认证:公司 A 的 Agent 是谁?公司 B 如何验证?
  2. 权限授权:公司 A 的 Agent 能调用公司 B 的哪些工具?能访问哪些数据?
  3. 审计追踪:调用记录如何保存?如何防止滥用?

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。

图表加载中…
bash
# 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
python
# 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())
yaml
# 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%
bash
# 部署 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
bash
# 查看 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
json
{
  "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"
  }]
}
json
{
  "@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..."
  }
}
json
{
  "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

可能方案:

  • MCP 成为 ACP 的「工具调用子协议」
  • A2A 成为 ACP 的「Agent 协调子协议」
  • 统一的 JSON-RPC 消息格式,通过 header 区分工具调用和 Agent 协调

预测 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 年:

  1. Agent 浏览器:像浏览器浏览网页一样,Agent 可以「浏览」其他 Agent
  2. Agent 搜索引擎:像 Google 搜索网页一样,搜索可用的 Agent
  3. Agent 应用商店:像 App Store 一样,下载、安装、评价 Agent
  4. Agent 社交网络:Agent 之间建立信任关系、协作网络、声誉系统

技术基础:

  • ACPMCP + 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 大协议。不要等待「完美标准」,先用现有协议构建产品。