生成式 UI 解决文本交互的哪些瓶颈？
- 背景: 传统 Agent 主要依赖纯文本对话，但文本是线性、单一的交互方式;
- 瓶颈一: 收集结构化信息时反复问答让对话冗长;
- 瓶颈二: 呈现复杂数据关系时纯文本表达力有限;
- 瓶颈三: 让用户多选项中选择时，文本列表远不如可视化界面直观;
- 定义: 由 Agent 动态生成界面（表单、交互式图表乃至完整 Web 应用）的模式称为生成式 UI（Generative UI）;
- 归属: 这是元能力中“用户界面”方向，见 代码作为元能力;
A2UI 与直接生成 HTML 的安全差异是什么？
- 直接生成代码的风险: 生成的 HTML/JavaScript 可能包含恶意内容——输入中藏了指令时，Agent 可能被提示注入操纵，不知不觉生成窃取用户数据的脚本;
- 因果澄清: 成因是提示注入（恶意指令混进 Agent 输入），效果类似传统 Web 的 XSS，但不能把整个攻击直接叫作 XSS;
- 声明式方案: 以 A2UI（Agent-to-User Interface）为代表的协议让 Agent 不生成可执行代码，只输出 JSON 格式的“界面描述清单”;
- 示例: “显示一个 3 行 2 列的表格，标题是「销售数据」”;
- 渲染: 客户端收到清单后用自己预先准备好的安全组件渲染——像餐厅菜单，顾客只能点菜单上有的菜，不能走进厨房自己做;
- 核心原则: 安全优先——客户端维护受信任的组件目录（Card、Button、TextField、Table），Agent 只能请求已存在的组件，无法注入任意代码;
- 附带特性: 跨平台（同份描述在 React、Flutter、原生应用中渲染）与增量生成（流式 JSONL，边接收边渲染）;
AG-UI 与 A2UI 有何不同？
| 名称 | 性质 | 职责 |
|---|
| A2UI | 界面描述语言 | 描述要渲染的界面结构 |
| AG-UI（CopilotKit 提出） | 事件 / 传输协议 | 把消息、工具调用、状态补丁流式推送到前端 |
- 关系: AG-UI 本身可以承载 A2UI 这类界面载荷，二者互补而非同类，不应并列为同一种声明式界面协议;
声明式与直接生成代码如何取舍？
- 声明式适用: 标准化的交互场景——表单、表格、卡片;
- 直接生成代码适用: 高度定制化需求，如自定义可视化、游戏界面——更灵活;
- 判断: 两类模式按定制程度分工，不是互斥路线;
HTML 交付件比 Markdown 汇报强在哪？
- 现状: Agent 完成任务后往往产出一份 Markdown 汇报，但一页页翻读线性排布内容并不好读;
- 优势一: 交互式演示——用可操作形式直接演示系统如何运行，用户一看就懂，胜过大段文字;
- 优势二: 更好的数据可视化——用图表而非表格，还可构建可交互组件让用户自行浏览、筛选、下钻;
- 优势三: 可持续完善的交付件——HTML 网站不必在任务结束时一次性产出，而可由 Agent 在工作推进中不断补充;
- 实例: 为每个研究项目维护的交互式网站既是交付件也是活文档;
- 用途一: 实验数据追溯——逐条查看每次实验数据、所用 prompt 与 LLM 原始回复，便于发现数据构造、格式、分布问题，以及回复与 judge 打分是否存在系统性偏差;
- 用途二: 训练指标监控——把训练曲线列在网页上，随时确认内科指标是否健康;
- 内科指标: 反映训练过程本身是否正常的内部信号，如训练损失与验证损失、梯度范数、学习率、输出 token 困惑度，以及强化学习中的奖励、KL 散度、策略熵；它们比任务准确率这类结果指标更早暴露损失不收敛、梯度爆炸、训练崩溃;
- 用途三: 运行原理展示——把系统结构可视化，一眼看清这个由 AI 搭起来的系统是什么结构;
动态表单如何一次性澄清意图？
- 文本问答局限: 效率上一问一轮对话，十个澄清点就要十轮;表达力上问题间存在依赖（“选择旅行目的地”影响“交通方式”可选项），纯文本难以表达级联关系;
- 方案: Agent 生成包含各类输入控件的 HTML 表单——文本框、下拉菜单、复选框、日期选择器;
- 进阶: 生成级联表单，用 JavaScript 实现动态逻辑：选择某选项后自动显示或隐藏后续问题、动态更新可选项;
- 收益: 用户一次填完整张表单，无需多轮对话，还能清晰看到所有待填信息与问题之间的逻辑关系;
- 示例: 用户说“我想订一张去北京的机票”，表单含出发城市、出发日期、旅行类型（单程/往返）、仅选往返时显示的返程日期;
为什么 SQL 查询要用 Artifact 模式？
- 两种设计: 让 Agent 执行 SQL 后用自然语言描述结果，或让 Agent 生成 SQL 代码作为 artifact 交前端直接执行;
- 第一种的问题: 查询结果可能有数千行，让 LLM 阅读后再用文字描述不仅耗 token、耗时间，更严重的是“抄写”数据时非常容易出错;
- Artifact 模式: LLM 只负责写查询语句，不亲自读成千上万行数据再复述;系统拿 SQL 直接查库并把数据渲染成表格;
- 本质: 数据从数据库直达用户界面，完全绕过 LLM 这个“中间人”，既快速又准确;
- 进阶: 生成 SQL 与可视化代码两个 artifact 形成流水线，前端把 SQL 结果直接传给可视化代码，LLM 不参与数据传递——这正是代码生成作为接口的精髓;
- 安全要求: 执行层应使用只读数据库账号，解析 SQL 并只允许经过批准的
SELECT 语句，拒绝 DDL、DML 与多语句查询；用户提供的值由服务端参数化绑定；限制查询时间、返回行数以及可访问的表与时间范围；可视化代码在隔离网络与文件系统的沙盒中运行，且只能产生规定格式的结果;
- 边界: Artifact 模式缩短了数据路径，但不能替代权限检查与执行隔离;