目前的 Agent 能力大家认识较多的一般可见于后端的 Agent 协议，比如 MCP ，A2A 等等，大部分的 Agent 框架对这些协议做了很好的封装，可是对于广大的前端程序员而言，前端的开发和工程化手段貌似没有太大的变化，其实不然，目前的 Agent 协议已经是全面发展，不再仅仅局限后端一个领域。我们写这篇文章就是希望能刷新大家的一些固有的认知：Agent 不止后端程序员的专享。

在 ChatGPT 刚刚兴起的时候，我的一个固有认知就是 LLM 对于前端同学而言，只需要一个对话框就够了，所以把更多的精力和工程化的手段放到了 Prompt，Workflow 等事情上。

后面随着 MCP 的兴起，再加上 Google 发布 A2A 等行业标准协议的确立，才让我有了对于前端一些更多的思考：难道前端就真的不需要参与其中？现在看起来，前端不仅需要参与，其实它一直在演进，下面的表格我们梳理了一下大致的脉络。

阶段	时间	特征	事件
早期	2023 年底	工具连接重复造轮企业自研中间件泛滥 “M×N集成地狱”凸显	大模型能力溢出，传统GUI无法承载开发者70%时间消耗于胶水代码
前期	2024 年	首个通用开放标准出现	2024.02：MCP开源（Anthropic）— “AI世界的USB-C"，11 月发布规范第一版
中期	2025 年	继续构建协议矩阵形成“能力-协作-通信-呈现”四层架构	2025.03：A2A发布（Google）— Agent协作语言，引入Agent Card能力发现 2025.05：AG-UI发布（CopilotKit）— 人机事件通信标准化 2025.09：A2UI开源（Google）— 声明式UI生成+安全沙箱，与AG-UI闭环
现在	2026 年	协议深度协同集成	2026.01：MCP Apps 第一个稳定版本发布

—

早期，全行业卖胶水

2023年底，大模型能力呈现爆发式增长，但传统GUI（Graph User Interface）无法承载大模型具备的推理、规划、记忆等复杂能力，静态界面无法做出展示，用户面临“功能可见性低”、“控制感缺失”等问题。

Function calling 与 Tool Use 概念相继出现，开发者面临"M×N集成地狱"：M个Agent × N个工具 = M×N次重复开发，开发者大部分时间消耗于"胶水代码"，而非创造核心价值。

本质问题是 AI Agent 已能做“智能决策”，但技术生态不成熟，前端仍停留在传统 GUI 。

—

前期，开始有人提标准

2024 年初提出 MCP（Model Context Protocol）概念并在 2024 年 11 月确定了 MCP 规范的第一个版本，这标志首个工具连接的开放通用标准 MCP 出现。解决“工具连接”混乱这一最基础、最普遍的痛点，推动业界从“自研”向“标准化”转变，加速生态建设。

MCP

MCP 被喻为“ AI应用的USB-C接口”，支持安全高效地连接AI系统与企业数据和工具，为LLM与外部工具和数据源无缝集成的提供了开放标准。

它的核心作用：

标准化上下文接入：统一的协议规范让 LLM 模型能够标准化地访问各种数据源和工具。从文件系统到数据库，从API到本地服务，一套协议解决所有上下文集成需求。实现“即插即用”的工具集成，避免M×N重复开发。
安全可控架构：基于宿主应用的安全代理模式，确保AI对数据的访问完全可控。支持细粒度权限管理和完整的操作审计，满足企业级安全要求。
轻量高效协议：采用JSON-RPC作为通信基础，支持多种传输层实现。协议设计简洁高效，易于理解和实现，同时保证了良好的扩展性和兼容性。

它的架构：

MCP Host：用于协调和管理一个或多个 MCP 客户端的 AI 应用程序.
MCP Client：一个维护与 MCP 服务器连接并从 MCP 服务器获取上下文以供 MCP 主机使用的组件。
MCP Server：一个为 MCP 客户端提供上下文信息的程序。

—

中期，发现了更多可做的事情

2025 年随着 Agent 研发工程方法的不断深入与演进，大家认识到在工程过程中还存在很多“摩擦点”。从“能力-协作-通信-呈现”四层架构来分析，各层需要协同工作，但不同层间还缺少对应协议。这需要一些新的协议/框架来补充生态，如：Agent协作、动态UI生成。

A2A

2025年 3 月 google 发布了A2A（Agent2Agent Protocol），它的目标是实现 Agent 与 Agent 间的无缝通信和协作。

它的核心作用：

实现跨厂商、跨框架智能体的标准化协作
解决“各说各话”的信息孤岛问题

它的关键技术：

Agent Card：JSON格式描述智能体能力
任务管理：支持任务分解、状态同步、回调机制
合作机制：允许交换上下文、回复、工件或用户指令

A2A 与 MCP 的集成协作方式如图：

AG-UI

2025 年5月CopilotKit发布了AG-UI（Agent-User Interaction Protocol），它的目标是成为面向用户的应用程序与 Agent 之间的通用双向连接。

它的核心作用：

标准化智能体与前端界面之间的实时事件流传输
解决“每个Agent重写前端逻辑”的痛点

它的设计原则：

事件驱动通信（Event-driven）
支持SSE、WebSocket等多种传输方式
16种标准化事件类型（如message, tool_call, state_update）

它的架构：

Application：面向用户的应用（例如聊天或任何人工智能应用）。
AG-UI Client：通用通信客户端HttpAgent或用于连接现有协议的专用客户端。
AI Agent：后端 AI 代理，用于处理请求并生成流式响应。
Secure Proxy：提供额外功能并充当安全代理的后端服务。

它与 MCP、A2A 集成协作方式如图：

A2UI

2025年 9 月 Google开源了A2UI(Agent to UI Protocol)，是一种用于 Agent 驱动的声明式 UI 协议。它的目标是 Agent 能够生成丰富的交互式用户界面，这些界面可以在 Web、移动设备和桌面设备上原生渲染，而无需执行任意代码。

它的核心价值：

安全性：声明式数据，而非代码。代理从客户端的可信目录中请求组件。不存在代码执行风险。
原生体验：不使用 iframe。客户端使用自己的 UI 框架进行渲染。继承应用程序的样式、可访问性和性能。
可移植性：一个代理响应即可在任何地方使用。相同的 JSON 可在 Web（Lit/Angular/React）、移动设备（Flutter/SwiftUI/Jetpack Compose）和桌面设备上渲染。

它的设计原则：

兼容LLM：扁平化的组件列表，带有ID引用。易于增量生成、纠错和流式传输。
与框架无关：代理发送抽象组件树。客户端映射到原生组件（web/移动/桌面）。
关注点分离：三层架构——用户界面结构、应用程序状态、客户端渲染。支持数据绑定、响应式更新和清晰的架构。

它与 A2A、AG-UI、MCP Apps 之间集成协作关系是:

A2UI 与 A2A：可以通过 A2A 直接向客户端前端发送 A2UI 作为数据格式的消息。
A2UI 与 AG-UI：可以通过 AG UI 直接向客户端前端发送 A2UI 作为数据格式的消息。
A2UI 与 MCP Apps：A2UI 采用“原生优先”的方法，这与 MCP Apps 的资源获取方式不同。A2UI Agent 不会像 MCP Apps 那样获取不透明的有效负载并在沙盒中显示，而是发送原生组件的蓝图。这使得 UI 能够完美地继承宿主应用的样式和辅助功能。

—

现在，前后端开始集成融合

从 MCP 到 MCP Apps 协议，Agent 有更多的互操作性，可以看到 Agent 生态系统协议在不断扩展，且是在原有协议上进行原生的深度集成融合。

MCP Apps

2025 年 11 月正式发布了 MCP Apps 扩展提案（SEP-1865），为 MCP 引入标准化的交互式 UI，然后在 2026 年 1 月发布了第一个稳定版本。这一扩展由 OpenAI、Anthropic、MCP-UI 核心维护者联合主导，标志着 MCP 从纯文本与结构化数据交互，迈向支持富交互体验的 Agentic App 的关键一步。

MCP Apps 让 MCP 工具能够返回富交互式界面，而不仅仅是纯文本，构建可在 MCP 主机（例如 Claude Desktop）中渲染的交互式 UI 应用程序。当工具声明一个 UI 资源时，宿主（Host）会在沙盒化的 iframe 中渲染它，用户可以直接在对话中与之交互。

MCP Apps 的架构依赖于两个关键的 MCP 原语：

带有 UI 元数据的工具：工具包含 _meta.ui.resourceUri 字段，指向 UI 资源
UI 资源：通过 ui:// scheme 提供的服务器端资源，包含打包的 HTML/JavaScript


// 带有 UI 元数据的工具
{
  name: "visualize_data",
  description: "将数据可视化为交互式图表",
  inputSchema: { /* ... */ },
  _meta: {
    ui: {
      resourceUri: "ui://charts/interactive"
    }
  }
}