技术深度解析：为什么 A2UI 选择 JSON 而非 HTML？
深入剖析 A2UI 背后的架构决策。为什么对于 AI Agent 来说，传输 JSON 数据优于生成 HTML 代码？
自从 A2UI 发布 以来，我们收到的最常见的问题之一是：“为什么要发明一套新规范？为什么不直接让 LLM 生成 HTML？”
这是一个很好的问题。LLM 在编写 HTML 方面确实很出色。但是，在构建企业级 Agent 时，“生成能力” 只是战斗的一半。另一半是 安全性 (Safety) 和 用户体验 (User Experience)。
核心威胁：UI 注入攻击 (UI Injection)
想象一下，如果一个 Agent 可以在你的银行 App 中渲染原生 HTML。这不仅仅是 XSS，这是 UI 注入。
- 场景 A (凭证窃取): Agent 产生幻觉，生成了一个伪造的密码输入框，外观和你的 App 一模一样。
- 场景 B (点击劫持): Agent 生成了一个透明的
<iframe>覆盖在”转账”按钮上。
为了防止这种情况，你需要复杂的净化器 (DOMPurify 等)。但这本质上是在玩一场”打地鼠”的游戏。这正是我们认为 静态 UI 已死 的原因——但安全的动态 UI 需要一种全新的范式。
解决方案：声明式安全 (Declarative Security)
A2UI 从设计上根除了 UI 注入。 我们采用的是 “声明式本质 (Declarative Nature)“。Agent 无法执行代码，也无法定义新的 UI 行为。它只能发送被动的 JSON 数据：
{
"type": "button",
"label": "确认支付",
"action": "submit_payment"
}宿主应用程序接收此数据并决定如何渲染它。如果宿主 App 没有 “button” 组件，什么也不会发生。攻击面被严格限制在你显式白名单的组件范围内。
“原生”体验的论点
除了安全性，还有一个 用户体验 的问题。
如果 Agent 生成 HTML，它生成的是 Web UI。但如果你的用户是在原生 iOS App 上呢？或者是在 Flutter 桌面应用上？
- HTML 看起来格格不入（iframe 的感觉）。
- 它无法自动适配用户的深色模式设置。
- 它给人的感觉是”外来的”，不属于宿主应用。
使用 A2UI，Agent 描述的是 意图（“我需要一个日期选择器”），而客户端渲染的是它 自己 的原生日期选择器。
- 在 Web 上: 渲染 React Material UI DatePicker。
- 在 iOS 上: 渲染 SwiftUI DatePicker。
- 在终端上: 渲染 CLI 提示符。
对比：A2UI vs. 其他方案
(相关阅读：查看我们详细的 A2UI vs MCP 分析)
| 特性 | A2UI | HTML 生成 | Anthropic MCP |
|---|---|---|---|
| 格式 | JSON (结构化数据) | 字符串 (代码) | 多样 (资源) |
| 安全性 | 高 (无代码执行) | 低 (XSS 风险) | 中 |
| 样式 | 宿主原生 | 不一致 | 宿主相关 |
| 平台 | 任意 (Web/移动端) | 仅限 Web | 任意 |
结论
A2UI 选择 JSON 是因为它将 UI 视为 数据，而非代码。这种解耦使得 Agent 更安全、更智能，并且真正做到无处不在。