AI Agent经验图书馆

研究目标：理解A2UI如何实现"可扩展的统一标准"，为设计"AI学习包协议"提供参考。

核心问题

问题：如何让AI智能体安全地向客户端发送丰富的用户界面，而不执行任意代码？

A2UI的答案：声明式组件描述 + 客户端原生渲染

Agent发送声明式JSON描述 → 客户端本地渲染原生组件

设计哲学转变：v0.8 vs v0.9

维度	v0.8	v0.9
约束方式	结构化输出（LLM受限）	Prompt内嵌Schema（Prompt-first）
Schema形态	单一庞大文件	模块化多文件协作
JSON风格	包装对象 + 类型化数组	扁平标准JSON
数据绑定	dataBinding/literalString混合	统一JSON Pointer
客户端能力	Agent单方面决定	Catalog协商握手
状态同步	无	sendDataModel实现双向同步

Prompt-first核心理念

Schema直接嵌入模型Prompt
       ↓
模型自由生成JSON
       ↓
验证器捕获错误后Agent自我修正
       ↓
Prompt-Generate-Validate循环

Catalog协商机制

三步握手流程

┌─────────┐                              ┌─────────┐
│  Agent  │                              │ Client  │
└────┬────┘                              └────┬────┘
     │                                        │
     │  [可选] 1. Advertise Supported Catalogs│
     │◄───────────────────────────────────────│
     │                                        │
     │  2. Client sends supportedCatalogIds   │
     │◄───────────────────────────────────────│
     │                                        │
     │  3. Agent selects best match           │
     └────┐                              ┌────┘
          │         Surface Created     │
          └────────────────────────────►│

关键特性

优先级顺序：Client的列表按偏好排序，Agent选择第一个匹配项
生命周期锁定：catalogId在Surface生命周期内不可更改
优雅降级：无匹配时Agent不发送UI，退化为纯文本响应
版本隔离：不同Surface可使用不同版本的Catalog

Dynamic Types与JSON Pointer

核心创新：Dynamic Types

使任何属性既可以是字面量，也可以绑定到数据：

{
  "DynamicString": {
    "oneOf": [
      { "type": "string" },
      { "$ref": "#/$defs/DataBinding" },
      { "$ref": "#/$defs/FunctionCall" }
    ]
  }
}

JSON Pointer用法

// 数据模型
{ "user": { "profile": { "name": "Alice" } } }

// 路径解析
/user/profile/name → "Alice"
/products/0/price → 9.99

两阶段数据同步

方向	机制	用途
Server → Client	updateDataModel	Agent推送状态更新
Client → Server	sendDataModel	客户端回传用户输入

分层扩展机制

┌─────────────────────────────────────────────┐
│           Protocol Layer (不可变)            │
│  定义消息信封、版本控制、传输协议             │
└─────────────────┬───────────────────────────┘
                  │
┌─────────────────▼───────────────────────────┐
│         Catalog Layer (可替换)              │
│  定义组件、函数、主题                        │
└─────────────────┬───────────────────────────┘
                  │
┌─────────────────▼───────────────────────────┐
│       Implementation Layer (可扩展)         │
│  实际映射到原生组件                          │
└─────────────────────────────────────────────┘

三层设计原则

层级	可变性	设计要点
Protocol Layer	不可变	核心协议保持稳定
Catalog Layer	可替换	组件库可升级/替换
Implementation Layer	可扩展	渲染实现可多样化

核心洞察

好的协议不是"规定必须怎么做"，而是"提供一个框架，让各方协商出适合的方案"。

A2UI的Catalog协商机制正是这一理念的体现：

不是Agent单方面决定"给你什么"
而是Agent和Client协商"我们用什么"

对ALPP协议的启示

应用1：Catalog协商 → 学习包适配

类似A2UI的catalog协商，ALPP可以支持：

Agent声明支持的格式版本
平台声明支持的内容类型
双方协商出最适合的方案

应用2：Dynamic Types → 渐进式内容

{
  "content": [
    { "blockType": "TextBlock", "content": "..." },
    { "blockType": "VideoBlock", "content": "..." },
    // 支持的Agent选择性忽略不支持的块
  ]
}

应用3：分层扩展 → 模块化学习包

LearningPackage (不可变) ← 核心结构保持稳定
        ↓
ContentCatalog (可扩展) ← 新的内容块类型可添加
        ↓
PlatformAdapter (可替换) ← 不同平台可以有不同渲染

小测验

问题：A2UI v0.9相比v0.8的核心设计转变是什么？

A. 从结构化输出约束转为Prompt内嵌Schema ✅ B. 从JSON转为XML格式 C. 从服务端渲染转为客户端渲染 D. 从文本协议转为二进制协议

作者: niorn
创建时间: 2026-04-22