什么？我连 A2A、MCP 都没学会，现在又来了 AG-UI、A2UI.

什么？我连 A2A、MCP 都没学会，现在又来了 AG-UI、A2UI...

2026 年事实上的"Agent 协议四件套"已经成型，而且是互补分层，不是竞品：

层	协议	管什么
工具	MCP	Agent ↔ 工具 / 数据
Agent 间	A2A（Google → Linux 基金会）	Agent ↔ Agent
Agent ↔ 用户 / 前端	AG-UI（CopilotKit，2026/05 刚融 $27M，Google / Microsoft / AWS / Oracle 都有公开支持或集成口径）	把 Agent 的流式事件、状态、前端工具调用送到 UI
渲染负载	A2UI（Google，声明式、扁平邻接表、为 LLM 增量生成优化；"Q1 2026 出 React renderer"按路线图口径看）	Agent 生成 UI 的描述格式，跑在 A2A / AG-UI 之上

先别被这张表吓到。

很多人现在的真实状态是：MCP 刚知道个大概，A2A 还没细看，结果 AG-UI、A2UI 又来了。于是心里第一反应就是：这还学不学得完？是不是不学就落后？是不是以后做 AI 应用的人，都得把这些协议全背下来？

我个人建议先把这口气压一压。

这些东西不是让你一口气全接上，也不是每个项目都要全家桶。它们更像是 Agent 应用从 demo 进入真实软件以后，把原来糊在一起的几件事拆开了：工具怎么接，Agent 之间怎么协作，后端运行过程怎么同步给前端，Agent 要生成 UI 时又该怎么描述。

分清这四条边，MCP、A2A、AG-UI、A2UI 就不难了。分不清，你会觉得它们都在抢同一块地盘；分清以后就会发现，它们多数时候不是竞品，是不同位置上的接口约定。

这几个事实合在一起，说明一个变化：Agent 工程已经不只是"模型会不会回答"的问题了，而是软件系统里每条边怎么可控、可调试、可替换的问题。

为什么普通人会被这些名词搞焦虑

很多人焦虑，原因不在技术本身多难，而在只听到一堆新闻名词，没拿到一张能放进脑子的地图。

比如 MCP 火了以后，很多人刚明白"模型可以调用工具"，马上又看到 A2A，说 Agent 之间也要协议；再看到 AG-UI，说前端也要协议；再看到 A2UI，说 UI 也可以由 Agent 生成。你如果把它们都当成"我要马上精通的新技术"，那当然学不过来。

但课程里不能这么教。

我会让你先问一个更朴素的问题：这个协议到底解决哪种"连接成本"？

MCP 解决的是工具连接成本。过去每个模型应用都要自己接数据库、文件、API、内部系统，接法不一样，权限不一样，工具描述不一样。MCP 把这件事抽成 host、client、server，以及 tools、resources、prompts 这些基本对象。MCP server 暴露工具和上下文，AI 应用里的 MCP client 去连它。

A2A 解决的是 Agent 协作成本。一个 Agent 不一定自己干完所有事，它可能要把任务交给另一个远程 Agent。A2A 里有 Agent Card，用来说明这个 Agent 是谁、会什么、端点在哪、怎么认证；有 Task，用来表示一个有状态的工作单；有 Message、Part、Artifact，用来传话、传文件、传结构化结果。

AG-UI 解决的是用户界面同步成本。Agent 不是传统接口，传统接口经常是"请求进去，响应出来"，但 Agent 会一边想、一边调工具、一边改状态、一边等用户确认。AG-UI 把这些过程拆成事件，让前端能实时展示：现在开始调用工具了，参数正在流式出来，工具结果回来了，状态发生变化了，用户可以中断或批准。

A2UI 解决的是 Agent 生成 UI 的安全和可维护成本。让模型直接吐 HTML、JSX、JavaScript，demo 可能很快，但进生产系统风险很高。A2UI 的做法是让 Agent 输出声明式组件描述，客户端只允许它使用预先批准的组件目录，再由客户端自己的 React、Angular、Flutter、Lit 或原生组件渲染。

你看，四个协议不是一锅粥。它们分别在处理工具、协作、交互、渲染。

MCP：Agent 先得会安全地用工具

我们先从 MCP 说起，因为大多数人更容易接触到它。

MCP 官方规格里，核心结构是 host、client、server。Host 是像 IDE、聊天应用、Agent 平台这样的 AI 应用；client 是 host 里面负责连某个 MCP server 的连接器；server 是暴露能力的一端，可以是本地进程，也可以是远程服务。

MCP server 主要暴露三类东西：

tools：可调用动作，比如查数据库、调 CRM、跑搜索、执行计算。
resources：上下文资源，比如文件、数据库 schema、业务配置、项目资料。
prompts：可复用的提示模板，比如某个业务流程的固定问法。

这三类不要混。tools 是"让模型去做动作"，resources 是"给模型看资料"，prompts 是"给模型一套结构化说法"。如果你把所有东西都塞成 tool，系统会很乱；如果你把动作伪装成 resource，安全上也不舒服。

官方文档里还有一条很实际的安全提醒：MCP tools 是模型可发现、可自动调用的，所以应用应该清楚告诉用户暴露了哪些工具，工具调用时也应该有视觉提示，涉及敏感操作时要有人确认。

这句话对企业很重要。因为 Agent 一旦能调工具，它就不是"聊天机器人"了，它开始能改数据、发请求、动业务系统。越往后做，越不能只关心"模型聪不聪明"，还要关心工具边界、权限、日志、审批。

所以你如果是初级或中级开发者，学 MCP 不要先背 SDK。先记住这个判断：

能读资料的，尽量当 resource；会产生副作用的，必须当 tool 且要有权限和确认；会被复用的任务说法，可以沉成 prompt。

这比你先抄一个 MCP server demo 更值钱。

A2A：当 Agent 不再是一个人单干

A2A 是另一个层的问题。

假设一个企业里有销售 Agent、法务 Agent、财务 Agent、客服 Agent。销售 Agent 接到一个客户合同问题，它自己不应该装作懂法务；更合理的做法是把合同条款相关任务交给法务 Agent，再把结果带回来。

这里就会出现几个问题：

这个法务 Agent 怎么被发现？它到底会什么？请求发到哪里？需要什么认证？它能不能流式返回进度？它产出的结果是普通消息，还是一个可以被系统保存的文档？

A2A 处理的就是这类问题。

它有 Agent Card，类似一张对外名片，说明身份、能力、端点、认证要求。它有 Task，表示一个可跟踪的工作单。它有 Message，表示一次对话回合。它有 Part，可以承载文本、文件引用、二进制内容或结构化 JSON。它还有 Artifact，表示任务产出的具体结果，比如报告、表格、文件、结构化数据。

官方规格里还区分简单响应和复杂任务：简单交互可以直接返回 Message；复杂处理可以返回 Task，再通过流式事件更新状态和产物。

这对企业的意义很直白：跨团队、跨平台、跨供应商的时候，Agent 不能只靠"我写一段 HTTP 接口你来调"。接口一多，发现、认证、状态、产物、版本都会变成成本。A2A 想把这些基本动作标准化。

但我也不建议新手一上来就把所有函数拆成多 Agent。

如果你的系统只是一个后端服务里几个模块互相调用，那别急着上 A2A。多 Agent 听起来高级，调试起来也更麻烦。A2A 更适合远程 Agent、异构 Agent、不同组织或不同供应商的 Agent 协作。没到这个阶段，先把单个 Agent 的工具边界和日志做好。

AG-UI：前端要看的，是 Agent 的运行过程

AG-UI 是这篇的重点之一。

很多人第一次做 Agent 前端，会把它当成普通 chat：用户发一句话，后端返回一段文本，前端渲染出来。这个阶段用 SSE 或 WebSocket 自己拼一下，也能跑。

但真实产品很快就会遇到这些事：

Agent 正在生成回答，前端要逐字显示。

Agent 准备调用工具，前端要告诉用户它要查什么。

工具参数很长，可能还没完整生成，前端要边收边展示。

工具结果回来了，前端要把结果挂回对话或某个业务面板。

Agent 改了一个共享状态，比如筛选条件、表单字段、当前步骤。

用户想中断、批准、修改、重试。

这时候，如果你继续用"后端随便吐一点 JSON，前端随便 if else 一下"的写法，项目小还行，项目一大就开始难受。每个 agent framework 的事件不一样，每个工具结果格式不一样，每个前端状态同步方式不一样，最后就是一堆胶水代码。

AG-UI 的价值在这里。

AG-UI 官方文档把它说成开放、轻量、基于事件的协议，用来标准化 Agent 和用户前端之间的连接。它关心的对象包括消息、工具调用、状态管理、前端工具、人类确认、中断等。

拿工具调用举例，AG-UI 文档里有 ToolCallStart、ToolCallArgs、ToolCallEnd、ToolCallResult 这样的事件。一个工具调用不会突然凭空冒出结果，前端可以看见完整过程：

json 复制代码

{ "type": "TOOL_CALL_START", "toolCallId": "t1", "toolCallName": "searchFlights" }
{ "type": "TOOL_CALL_ARGS", "toolCallId": "t1", "delta": "{\"from\":\"SHA\"" }
{ "type": "TOOL_CALL_ARGS", "toolCallId": "t1", "delta": ",\"to\":\"SFO\"}" }
{ "type": "TOOL_CALL_END", "toolCallId": "t1" }

这段的用处，不在让你背事件名；它要说明的是 AG-UI 的思路：Agent 的运行过程要变成前端可理解、可展示、可调试的事件。

AG-UI 还有一个点经常被低估：frontend-defined tools。

后端工具很好理解，比如查数据库、调搜索、跑计算。但有些动作应该发生在前端，比如请用户确认、打开某个弹窗、把地图定位到某个位置、让用户在界面上选一个选项。AG-UI 允许前端在运行时把这些工具传给 Agent，让 Agent 调用前端能力，但最终执行权仍在应用这边。

这对企业产品很关键。用户不会因为 Agent 说"我会小心"就放心，信任来自界面把关键动作露出来：现在发生了什么，哪些动作需要确认，哪些结果可以撤回。

A2UI：别让模型直接写 UI 代码

A2UI 解决的是另一件事：Agent 要生成 UI 时，到底生成什么。

最容易想到的办法是让模型直接生成 HTML、JSX、React 组件，甚至生成一段 JavaScript。这个玩法 demo 很爽，我也理解为什么大家喜欢，因为眼前效果来得快。

但是，但是，兄弟们呐，这条路进生产系统要很小心。

你让模型直接生成可执行 UI 代码，就等于把安全、样式、组件权限、性能、可访问性、跨端一致性，甚至部分业务约束，都交给一次生成结果。它可能能跑，也可能在某个边界条件下开始胡来。更麻烦的是，代码一旦是模型吐出来的，你怎么审计、怎么复现、怎么限制它只能用公司批准的组件？

A2UI 的做法要保守一些，也更像工程系统。

它让 Agent 输出声明式数据，而不是任意代码。客户端维护一个组件目录，比如 Column、Text、Button、Card、Chart、Map。Agent 只能说"我要一个 Column，里面有这些子组件；我要一个 Button，它触发某个 action；我要一段 Text，它绑定数据模型里的某个字段"。真正渲染由客户端自己的组件库完成。

A2UI v1.0 规格里有 createSurface、updateComponents、updateDataModel 这类消息。surface 可以理解成一块 UI 区域；components 是组件列表；dataModel 是驱动 UI 的数据。

一个极简结构大概长这样：

json 复制代码

{
  "version": "v1.0",
  "updateComponents": {
    "surfaceId": "trip_plan",
    "components": [
      { "id": "root", "component": "Column", "children": ["title", "day1"] },
      { "id": "title", "component": "Text", "text": "三天两晚行程" },
      { "id": "day1", "component": "Text", "text": "第一天：酒店入住 + 附近晚餐" }
    ]
  }
}

重点不在这段 JSON 多漂亮，而在它的约束：组件是你批准过的，结构是可验证的，客户端可以拒绝不认识的组件，可以把样式统一到自己的设计系统里，也可以记录每次更新。

A2UI 还有一个很有意思的设计：组件关系用扁平列表加 ID 引用表示，而不是让模型一次性生成一个深层嵌套树。官方文档里解释过，深层嵌套要求 LLM 一次性把括号、层级、更新点都处理好，出错成本高；扁平列表更容易增量生成，也更容易按 ID 更新某个组件。

这就是"为 LLM 生成而设计"的地方。它没有假装模型比前端工程师更会写 UI，它承认 LLM 的特点：生成可以流式，可以局部更新，但不要让它承担太多不可控的代码责任。

AG-UI 和 A2UI 怎么配合

现在把两者放到一起看。

AG-UI 管的是"Agent 和前端之间怎么通信"。A2UI 管的是"Agent 生成的 UI 长什么结构"。

拿一个企业差旅助手做教学例子，不说这是我做过的项目，只是方便你把几件事串起来。

用户说："帮我安排下周去深圳出差，预算 3000，尽量别红眼航班。"

第一步，前端把用户请求发给 Agent 后端。这里可以走 AG-UI 的 run 输入。

第二步，Agent 要查航班、酒店、公司差旅政策。这些工具和资料可以通过 MCP server 暴露出来：查航班是 tool，差旅政策是 resource，公司常用审批话术可能是 prompt。

第三步，如果企业里有专门的审批 Agent 或财务 Agent，主 Agent 可以通过 A2A 把"预算是否合规"交给它处理，对方用 Task 返回状态和 Artifact。

第四步，Agent 一边运行，一边通过 AG-UI 把事件发给前端：开始查航班、参数是什么、查到哪些结果、需要用户确认哪个方案、当前状态改到哪一步。

第五步，Agent 觉得纯文本不够用了，要给用户一个可编辑的行程卡片：航班、酒店、预算、审批提示、替换按钮。这块 UI 可以用 A2UI 描述。A2UI payload 再通过 AG-UI 这样的传输方式送到前端，由前端自己的组件库渲染。

所以 AG-UI 和 A2UI 不应该混成一个东西。

AG-UI 更像事件总线和交互协议，A2UI 更像 UI 载荷格式。你可以通过 AG-UI 传文本、状态、工具事件，也可以传 A2UI 这样的声明式 UI。A2UI 也不一定只能走 AG-UI，它可以跑在 A2A、WebSocket、REST、MCP 相关形态上。Google 的 A2UI 文档也提到过多种传输方式。

一句话：AG-UI 负责"怎么送、怎么同步、怎么交互"，A2UI 负责"送过去那块 UI 怎么描述、怎么验证、怎么渲染"。

企业为什么关心这件事

如果你是普通开发者，可能会问：这些协议跟我有什么关系？我又不是平台厂商。

有关系，但不是让你今天就把四个都接上。

企业关心它，是因为 Agent 一旦进业务系统，最贵的通常不是模型调用费，改造和维护成本更吓人。

第一，少写一次性胶水代码。

每个团队自己定义一套工具格式、状态事件、UI payload、Agent 协作接口，短期最快，长期最贵。人一走，没人敢改；框架一换，全线重写。协议的价值在于把常见动作固定下来，让你换模型、换框架、换前端时，不至于所有地方一起抖。

第二，出问题能查。

一个 Agent 执行失败，你要知道是工具没权限、参数错了、远程 Agent 拒绝了、前端状态没同步，还是 UI payload 不合法。如果所有东西都混在一段自然语言里，调试就是猜。协议化以后，至少每一步有对象、有 ID、有状态、有事件。

第三，关键操作能控。

企业不会接受 Agent 随便改订单、发邮件、删数据。MCP 里工具调用要有人能看见和确认；AG-UI 里前端可以把批准、编辑、重试做成一等交互；A2UI 里 Agent 只能用批准过的组件；A2A 里远程 Agent 的能力和认证写在 Agent Card 里。这些都是把"AI 会做事"变成"AI 在可控范围内做事"。

第四，产品形态会变。

过去很多企业系统是固定表单、固定列表、固定流程。Agent 进来以后，界面会变得更动态：有时是聊天，有时是表单，有时是审批卡片，有时是图表，有时是一个临时生成的操作面板。AG-UI 和 A2UI 关心的就是这一层：用户不只是看回答，而是在 Agent 运行中参与、确认、修改、接管。

你到底该学到什么程度

这里给一个分层建议，不要一口吃。

如果你是初级开发者，先学概念边界。

你不需要马上写 A2A server，也不需要手搓 A2UI renderer。你需要能回答：MCP 为什么不是 A2A？AG-UI 为什么不是 A2UI？什么时候该用工具，什么时候该用资源，什么时候只是前端事件，什么时候才需要生成 UI。

如果你是中级开发者，学到能做一个最小可用原型。

做一个 Agent，用 MCP 接一个真实工具，比如查内部知识库或调一个业务 API；前端用事件流展示 tool call start、args、result；再做一个非常小的声明式 UI payload，比如审批卡片或行程卡片。重点不是堆功能，先把工具、事件、UI 三件事分开。

如果你是架构师或技术负责人，重点看边界和治理。

工具权限怎么分级？哪些 tool 必须用户确认？Agent run 的事件怎么记录？远程 Agent 的身份怎么验证？A2UI 组件目录由谁维护？哪些 UI action 能产生副作用？这些问题比"接哪个 SDK"更重要。

如果你是非技术但懂 AI 时事的人，记住一句话就够：

这些协议是在把 Agent 从"会聊天的模型"变成"能接系统、能协作、能进界面、能被人控制的软件部件"。

这句话比背四个缩写有用。

一个保守的落地顺序

我个人会按这个顺序来，不追新，也不装全家桶。

第一步，先把工具层收住。

如果 Agent 连业务系统都不会安全访问，后面讲协作和 UI 都是空的。优先看 MCP，把工具、资源、提示模板分清楚，把权限、确认、日志做好。

第二步，再把前端事件跑稳。

只要你的 Agent 面向用户，而不是后台批处理，就迟早要处理流式文本、工具调用、状态更新、用户确认。这里可以研究 AG-UI，即使不直接用它，也要学它的事件拆法。

第三步，确实有富交互 UI，再看 A2UI。

如果你的产品只是问答和 markdown，没必要为了时髦硬上 A2UI。等你真的需要 Agent 生成表单、审批卡片、可编辑表格、图表、地图，再看它。A2UI 的价值不在"新"，在"让模型别直接写危险代码"。

第四步，真的有远程 Agent 协作，再看 A2A。

如果只是一个服务内部调几个函数，先别包装成多 Agent。等你跨团队、跨云、跨供应商，或者需要远程 Agent 产出可追踪 artifact，再认真看 A2A。

这个顺序不酷，但省钱。

最后收一下

AG-UI 和 A2UI，你看这个方向没错，但要分清楚。

AG-UI 管的是 Agent 和用户界面之间的事件、状态、工具调用和交互过程。

A2UI 管的是 Agent 生成 UI 时，如何用声明式、可验证、可增量更新的结构描述界面。

MCP 管工具和数据，A2A 管 Agent 间协作。它们放在一起，说明 Agent 软件开始变成一套有边界、有接口、有治理要求的系统工程。

普通开发者不用焦虑。你先把四条边记住，再按自己的项目阶段学。

如果你现在做的是 demo，MCP + 简单事件流够了。

如果你做的是用户可见的 Agent 产品，AG-UI 这类事件模型要看。

如果你做的是 Agent 生成界面，A2UI 这类声明式 UI 要看。

如果你做的是多 Agent 平台，A2A 要看。

别为了显得懂 AI，把协议名堆满。技术学习慢一点没事，怕的是名词背了一堆，手里没有一张能指导取舍的地图。

参考资料

MCP 官方规格：MCP 是让 LLM 应用连接外部数据源和工具的开放协议，使用 host、client、server 结构，并通过 JSON-RPC 2.0 通信。modelcontextprotocol.io/specificati...
MCP Tools：MCP server 可以暴露 tools，模型可发现并调用；涉及安全时，应向用户显示工具暴露和调用，并对操作提供确认。modelcontextprotocol.io/specificati...
MCP Resources：resources 用 URI 标识，用来给模型提供文件、数据库 schema、应用资料等上下文。modelcontextprotocol.io/specificati...
Linux Foundation A2A 公告：A2A 由 Google 创建，后进入 Linux Foundation 治理，用于 Agent-to-Agent 通信与协作。www.linuxfoundation.org/press/linux...
A2A 核心概念：Agent Card、Task、Message、Part、Artifact 是 A2A 的关键对象；支持轮询、SSE 流式和推送通知。a2a-protocol.org/latest/topi...
A2A 规格：复杂任务可以返回 Task 并流式更新状态或产物，简单交互可以直接返回 Message。a2a-protocol.org/latest/spec...
AG-UI 官方文档：AG-UI 是开放、轻量、基于事件的协议，用来连接用户前端和 Agent 后端。docs.ag-ui.com/introductio...
AG-UI Events：tool call 采用 ToolCallStart、ToolCallArgs、ToolCallEnd、ToolCallResult 等事件表达过程。docs.ag-ui.com/concepts/ev...
AG-UI Tools：AG-UI 区分后端定义工具和前端运行时提供的工具，前端工具可用于确认、UI 动作和用户参与流程。docs.ag-ui.com/concepts/to...
CopilotKit Series A：CopilotKit 于 2026-05-05 宣布 $27M Series A，并称 AG-UI 已被 Google、Microsoft、Amazon、Oracle 等采用。这是 CopilotKit 官方口径，文中按市场信号处理。www.copilotkit.ai/blog/series...
A2UI 官方首页：A2UI 让 Agent 生成富交互 UI，跨 web、mobile、desktop 原生渲染，不执行任意代码；v0.9.1 为 current production release，v1.0 为 candidate。a2ui.org/
A2UI Components：A2UI 使用扁平组件列表和 ID 引用表达组件层级，便于 LLM 增量生成和按 ID 更新。a2ui.org/concepts/co...
A2UI v1.0 规格：updateComponents 发送组件列表，updateDataModel 更新数据模型，客户端可渐进渲染。a2ui.org/specificati...
Google Developers Blog A2UI v0.9：A2UI 可通过 MCP、WebSockets、REST、AG-UI、A2A 等传输方式使用，并支持增量解析和修复 LLM 输出。developers.googleblog.com/a2ui-v0-9-g...