Agent 人机交互的下一站：实时语音与生成式 UI

（本文是笔者在 2025 年 12 月 20 日的首届智能体网络与应用创新大会上的受邀报告）

查看演讲 Slides (HTML)

演讲 Slides 源代码

摘要

当前 Agent 的人机交互以文本为核心，但这偏离了人类认知的自然模式。从第一性原理看，人类最擅长的输出模态是语音（说话速度是打字的三倍），最擅长的输入模态是视觉。视觉不是文字，而是直观的 UI。

第一步是实现实时语音交互。传统 VAD-ASR-LLM-TTS 串行架构的问题在于必须等待用户说完才能开始思考，在思考完成前无法输出。通过 Interactive ReAct 持续思考机制，Agent 可以边听边想边说：在用户说话时就开始思考，在自己说话时继续深入推理，充分利用所有时间间隙。

第二步是在实时语音基础上扩展观察空间和动作空间。通过扩展 Observation Space（从语音输入到 Computer Use 视觉感知）和 Action Space（从语音输出到 UI 生成与电脑操作），Agent 就能够一边打电话一边操作现有电脑/手机的 GUI 界面，并生成动态 UI 与用户交互。生成式 UI 的一种实现路径是生成前端代码，当前 Claude 4.5 Sonnet 已达到门槛。另一种实现路径是生成图片，当前 Nano Banana Pro 也已接近门槛。

这正是电影 Her 中 Samantha 的实现路径。Samantha 作为操作系统，需要具备五项核心能力：能够与用户实时语音对话，能够代替用户打电话办事，能够帮用户操作传统电脑和手机，能够打通用户现有设备和在线服务中的数据，拥有自己的生成式 UI 界面，有强大的用户长期记忆以实现个性化的主动服务。

Part I: 文本交互的效率瓶颈

当前 Agent 界面中的认知失配

人类输出模态

模态 速度 认知负荷
语音 150 词/分钟 低
打字 40-50 词/分钟 高
  • 语音是最自然的输出模态
  • 打字需要精细运动协调和视觉注意力
  • 语音交流是人类互动的基础

人类输入模态

模态 带宽 理解方式
视觉 高（~10 Mbps） 模式识别
听觉 中（~16 kbps） 顺序处理
阅读 低（~100 bps） 需要识字
  • 视觉皮层并行处理信息
  • 阅读是一种后天习得的技能，而非天生
  • UI/图形利用自然的视觉处理能力

根本洞察：当前基于文本的 Agent 界面迫使人类在输入和输出时都使用次优的模态。

最优交互范式

最优人类输出：语音

  • 以对话速度自然地产出语言
  • 最小的认知开销
  • 支持复杂的表达和细微差别
  • 支持实时交互和打断

应用场景：

  • 任务委派和澄清
  • Agent 执行过程中的实时反馈
  • 多轮问题解决

最优人类输入：视觉 UI

  • 快速信息扫描和理解
  • 空间组织有助于记忆和导航
  • 交互元素支持直接操控
  • 渐进式展示管理复杂性

应用场景：

  • 结果展示和比较
  • 交互式数据探索
  • 工作流可视化和状态监控

目标架构：人到 Agent 通信使用实时语音 + Agent 到人通信使用生成式 UI

Part II: 实时语音交互

典型的语音 Agent 架构

语音 Agent 的典型架构分为三层：

  1. 感知层：VAD + ASR

    • 将连续信号转换为离散事件

  2. 思考层：LLM

    • 异步处理

  3. 执行层：TTS

    • 将离散命令转换为连续动作

传统 VAD + ASR 架构的问题

VAD（语音活动检测）的问题

  1. 不可避免的延迟：必须等待 500-800ms 的持续静音才能确认用户说完
  2. 打断检测差：无法区分背景噪音/音乐；”嗯哼”会误触发打断
  3. 语音检测准确率低：复杂声学环境中出错；句中停顿导致截断

ASR（自动语音识别）的问题

  1. 缺乏上下文导致准确率低：VAD 将音频切成孤立片段；无法使用上下文消歧；邮箱、姓名、电话号码错误率高
  2. 缺乏世界知识：无法利用常识；地址、品牌、技术术语准确率低
  3. 纯文本输出丢失声学细节：
    • 丢失情绪：快乐、沮丧、兴奋
    • 丢失副语言信息：笑声、叹气、呼吸
    • 丢失环境信息：嘈杂、音乐、安静

流式语音感知模型：替代 VAD + ASR

多模态架构

  1. 音频编码器（来自 Whisper）：将音频转换为音频 token
  2. Qwen LLM（自回归）：处理音频 token，输出文本 + 事件

关键优势：

  • 流式：实时输出（非批处理）
  • 上下文：保留完整对话历史
  • 上下文学习：对个人信息、领域术语识别更准确
  • 世界知识：对地址、品牌、金额准确率更高

丰富的输出：文本 + 声学事件

除了文本 token，还输出特殊 token（声学事件）：

  • <speak_start> <speak_end>：语音边界
  • <interrupt>：打断意图
  • <emotion:happy>：情绪标记
  • <laugh> <sigh>：副语言信息
  • <music>：环境声音

Interactive ReAct：灵活交织观察、思考和行动

传统 ReAct：刚性的 OTA 循环

1
2
3
4
5
O₁: "我想把我的 Xfinity 账单降到每月 79 美元"
T₁: (思考 5 秒... 然后被打断，全部丢失)
O₂: "而且我不想删减任何功能"
T₂: (思考 15 秒...)
A₁: "明白了！这是一个包含所有功能的 79 美元套餐..."
  • 固定循环：必须完成整个观察-思考-行动序列
  • 思考丢失：无法边听边想，延迟高
  • 刚性：必须等待完整输入才能思考

Interactive ReAct：灵活交织的 OTA

1
2
3
4
5
6
7
8
O₁: "我想把我的 Xfinity 账单降到每月 79 美元"
T₁: (快速思考 0.5 秒：用户话未说完，等待)
T₂: (思考 5 秒... 然后被打断)
O₂: "而且我不想删减任何功能"
T₃: (快速思考 0.5 秒：用户想降价到 79 美元)
A₁: "我可以帮你！让我查看可用的套餐"
T₄: (继续思考... 10 秒)
A₂: "明白了！这是一个包含所有功能的 79 美元套餐..."
  • 边听边想：新观察随时插入，思考得以保留
  • 边想边说：快速响应，然后继续思考
  • 智能转折点判断：决定何时说话、何时保持沉默

SEAL 思考层：可中断的 Interactive ReAct 循环

关键洞察：LLM 思考速度远超语音 I/O，充分利用”间隙时间”

  • LLM 处理速度：

    • 输入处理：500+ tokens/秒
    • 思考/输出：100+ tokens/秒

  • 语音 I/O 速度：

    • 语音输入/输出：仅 5 tokens/秒
    • 速度差异：20-100 倍

在观察（语音输入）和行动（语音输出）之外的”间隙时间”里，我们有充足的时间进行深度思考。刚性的观察-思考-行动循环无法利用这个间隙时间。

快速思考 → 慢速思考 → 持续思考

  1. 快速响应（0.5s）：50 tokens 的快速思考 → 立即的初步响应（5 秒内）
  2. 深度分析（5s 后）：500 tokens 的慢速思考 → 生成更完整的答案
  3. 持续思考（按需）：如果 500 tokens 仍不够，继续思考 5 秒 → 继续生成答案直到思考和说话完成。如果需要多轮思考，结果是持续输出当前轮次的思考总结，就像一个人”自言自语”。

边听边想（Think While Listening）

优雅地处理对话中的打断。

传统 ReAct：一旦用户打断，之前所有的思考都被丢弃，必须重新开始。

Interactive ReAct：保留被打断的思考过程，附加新的用户输入，让模型从中断处继续思考。

1
2
3
4
5
6
7
8
9
<user>我想把我的套餐从现在的 109 美元换成你们的新套餐...</user>
<think>用户想换套餐，目前是 109 美元的套餐。
让我查一下新套餐的信息...
需要知道：1) 用户当前套餐详情 2) 新套餐价格...<interrupted/></think>
<user>（打断）顺便问一下，新套餐是每月 79 美元的那个吗？</user>
<think>（继续之前的思考）用户确认了新套餐价格是 79 美元。
这将每月节省 30 美元，从 109 美元降到 79 美元。
我还需要确认：1) 套餐内容差异 2) 是否有合约限制...</think>
<assistant>是的，79 美元的套餐。让我确认一下，你目前的 109 美元套餐包括...</assistant>

优势：思考过程连贯，可以根据最新信息快速调整策略。

边想边说（Speak While Thinking）

使用”填充语”为深度思考争取时间，减少首词延迟。

场景：用户问了一个复杂的问题，Agent 需要时间思考。

传统 ReAct：

1
2
3
<user>你确认订购这个套餐吗？</user>
* (长达 10 秒的沉默...) *
<assistant>经过考虑，我确认订购。</assistant>

Interactive ReAct：

1
2
3
4
5
<user>你确认订购这个套餐吗？</user>
<think> (快速思考, <0.5s) </think>
<assistant>让我确认一下，这是每月 79 美元的套餐，对吗？</assistant> (初步响应)
<think> (深度思考) </think>
<assistant>是的，这个套餐很划算。我确认订购。</assistant> (最终答案)

优势：大大提高交互的流畅性，避免尴尬的长时间等待。

SEAL 架构总结

一个统一的事件驱动循环，将感知、思考和执行解耦，实现真正的实时和并行处理。

感知层

  • 输入：连续信号（语音、GUI）
  • 输出：离散事件流
  • 解决：传统语音感知中的延迟、不自然打断和声学信息丢失

思考层

  • 输入：离散事件流
  • 输出：交错的思考/行动命令
  • 解决：传统 ReAct 的串行瓶颈，实现可中断的异步边听边想、边想边说

执行层

  • 输入：离散行动命令
  • 输出：连续信号 + 反馈事件
  • 解决：Agent 动作笨拙和缺乏反馈的”最后一英里”问题，形成闭环动作循环

未来展望：端到端模型

  • 当前 SEAL 架构：

    • 感知层 LLM：音频 → 文本 + 声学事件
    • 思考层 LLM：文本 + 声学事件 → 思考 + 行动
    • 执行层 LLM：行动 → 音频

  • 未来端到端架构：

    • 音频编码器：音频 → 音频 Tokens
    • 统一 LLM：感知 + 思考 + 执行
    • 音频解码器：音频 Tokens → 音频

Part III: 同时打电话和操作电脑

扩展的观察和行动空间

扩展的观察空间

传统 扩展
语音输入 语音输入
+ 屏幕视觉感知
+ 应用状态监控
+ 系统通知

电脑使用集成：

  • 实时屏幕理解
  • UI 元素识别和跟踪
  • 跨应用上下文感知

扩展的行动空间

传统 扩展
语音输出 语音输出
+ 鼠标/键盘操作
+ UI 生成
+ 应用控制

多模态输出：

  • 语音用于人类沟通
  • GUI 操作用于任务执行
  • 生成的 UI 用于结果展示

目标能力：一个可以同时进行电话对话和操作电脑界面的 Agent，类似于人类助理一边打电话一边操作电脑。

并发电话和电脑使用的多 Agent 架构

架构设计

电话 Agent：

  • 负责实时语音对话
  • ASR → LLM → TTS 低延迟管道
  • 从对话中提取关键信息
  • 通过消息传递与电脑 Agent 通信

电脑 Agent：

  • 负责 GUI 操作（浏览器、应用）
  • 视觉理解和行动规划
  • 接收来自电话 Agent 的信息
  • 报告任务状态并请求额外信息

通信协议

1
2
3
4
5
6
7
{
  "type": "info_collected" | "task_completed" | "error",
  "sender": "phone_agent" | "computer_agent",
  "field": "name" | "phone" | "email" | ...,
  "value": "...",
  "timestamp": "..."
}

自主编排方法

Agent 自主决定何时生成协作 Agent：

  1. 任务分析：电脑 Agent 遇到需要用户信息的复杂表单
  2. 能力评估：确定语音交互比文本更高效
  3. Agent 生成：调用 initiate_phone_call_agent(purpose, required_info)
  4. 并行执行：两个 Agent 独立运行，异步通信

实时协作模式

1
2
3
4
5
6
7
电话 Agent: "请问您的姓名是？"
用户: "张三"
    → 消息: {field: "name", value: "张三"}
电脑 Agent: (填写姓名字段)
    → 消息: {status: "name_filled"}
电话 Agent: "您的邮箱地址是？"
...

关键要求：Agent 必须在真正并行的线程中运行，彼此不阻塞。

解决电脑使用延迟：小型专用模型

Step-GUI：使用小模型的高效 GUI Agent（arxiv:2512.15431）

性能 vs. SOTA 模型

基准测试 OpenAI CUA Claude-4.5 Gemini-2.5 Step-GUI 8B
OSWorld-Verified 23.0 61.4 - 48.5
AndroidWorld - - 69.7 80.2
ScreenSpot-Pro 23.4 - - 62.6
OSWorld-G 36.4 - - 70.0

为什么小模型能超越前沿模型？

自我进化训练流程：

  • 校准步骤奖励系统（CSRS）：将模型轨迹转换为训练信号，>90% 准确率，成本仅为人工的 1/10-1/100
  • 领域针对性数据：11.2M mid-train + 1.67M cold-start 样本

核心洞察：前沿模型缺乏领域知识（中国应用的 UI 惯例、本地应用行为）。小模型 + 针对性训练可以填补这些空白。

AndroidDaily Benchmark（Step-GUI 提出的中国移动应用基准测试）

跨 5 个场景的真实移动应用任务：

  • 🚄 出行：在 12306 买火车票
  • 🎵 娱乐：在网易云音乐播放歌单
  • 🛒 购物：查看淘宝购物车
  • 💬 社交媒体：修改知乎隐私设置
  • 🍜 本地服务：设置大众点评评价为仅自己可见

AndroidDaily (Static) 结果

模型 平均准确率
Claude-4.5-sonnet 10.90
Gemini-2.5-Pro Thinking 43.74
Step-GUI-8B 89.91

结论：小模型 + 领域数据 > 通用大模型。Step-GUI-8B 通过针对性领域训练，在中国移动应用上达到 Gemini 的 2 倍、Claude 的 8 倍。

NVIDIA ToolOrchestra：用于多 Agent 协调的小模型

基于 NVIDIA 研究（developer.nvidia.com）

核心概念

ToolOrchestra 训练小型编排模型，根据用户对以下方面的偏好来监督和管理更大的模型和工具：

  • 速度
  • 成本
  • 准确性

关键洞察：小模型不受过多知识的负担，可以被训练来捕捉编排的基本决策模式。

训练方法

  1. 合成数据生成：自动轨迹生成与验证
  2. 多目标 RL：优化准确性、成本和解决时间
  3. 最小数据需求：Orchestrator-8B 仅使用 552 个合成样本

架构优势

  • 小模型（8B）精确指导更大的模型
  • 自动平衡能力和成本
  • 支持异构多 Agent 系统
  • 适合实际部署场景

小语言模型在 Agentic AI 中的案例

基于 “Small Language Models are the Future of Agentic AI”（arxiv:2506.02153）

核心论点

立场：小语言模型（SLM）是：

  • 对专门任务足够强大
  • 天然更适合 agentic 应用
  • 对高频调用必然更经济

SLM 在 Agent 系统中的论据

能力论据：

  • 现代 SLM 在聚焦任务上表现强劲
  • Agentic 系统涉及重复、专门的操作
  • 通用对话能力通常不必要

经济论据：

  • Agent 系统进行大量模型调用
  • 成本与模型大小和调用次数线性增长
  • SLM 将运营成本降低 10-100 倍

LLM 到 SLM 转换算法

  1. 识别 Agent 工作流中的专门子任务
  2. 从 LLM 输出中整理任务特定的训练数据
  3. 在专门数据上微调 SLM
  4. 在目标指标上验证性能
  5. 部署 SLM 用于生产工作负载

Part IV: 生成式 UI - Web 前端代码生成 + 图像生成

路径一：Web 前端代码生成

Anthropic 的方法：Claude Artifacts 和 “Imagine with Claude”

Claude Artifacts

Claude 可以生成完整的前端代码，在沙盒预览环境中渲染：

支持的输出类型：

  • 带 hooks 和组件的 React 应用
  • 交互式数据可视化（D3.js、Chart.js）
  • SVG 图形和图表
  • 原生 HTML/CSS/JavaScript
  • Markdown 文档

工作流程：

  1. 用户提示描述所需界面
  2. 模型生成完整前端代码
  3. 代码在沙盒预览中渲染
  4. 用户通过对话迭代

“Imagine with Claude”（研究预览）

随 Claude Sonnet 4.5 发布的临时研究预览：

关键特征：

  • Claude 即时生成软件
  • 无预定功能
  • 无预写代码
  • Claude 实时创建，在用户交互时响应和适应请求

技术演示：

  • 展示了将强大模型与正确基础设施结合的可能性
  • 无需预定义模板的动态软件创建
  • 对用户交互的实时适应

观看演示：youtu.be/dGiqrsv530Y

Google Research 的方法：Generative UI

**”Generative UI: LLMs are Effective UI Generators”**（2025 年 11 月）

项目页面：generativeui.github.io | 研究博客：research.google/blog

摘要

AI 模型擅长创建内容，但通常用静态、预定义的界面渲染。具体来说，LLM 的输出通常是 markdown “文字墙”。

Generative UI 是一个长期承诺，模型不仅生成内容，还生成界面本身。

我们证明，当正确提示并配备正确的工具集时，现代 LLM 可以稳健地为几乎任何提示生成高质量的自定义 UI。

实现：三个主要组件

  1. 服务器：暴露关键工具的端点（图像生成、搜索）
  2. 系统指令：精心设计的提示，包括目标、规划指南、示例
  3. 后处理器：修复无法通过指令修复的常见问题

评估结果

忽略生成速度时，结果被人类压倒性地偏好，优于标准 LLM markdown 输出。

PAGEN 基准用户偏好（ELO 分数）：

  1. 人类专家设计的网站（最高）
  2. Generative UI: 1710.7（44% 的情况下与专家相当）
  3. 顶级 Google 搜索结果（存在显著差距）
  4. 标准 markdown LLM 输出
  5. 纯文本输出

涌现能力

这种稳健的 Generative UI 能力是涌现的，相比之前的模型有实质性改进。

示例类别

  • 教育：什么是分形？两个骰子掷出 8 的概率、伊辛模型、计时设备历史
  • 儿童教育：给孩子解释推测解码、儿童化学实验、用小狗解释斜率和切线
  • 实用任务：举办感恩节、选择地毯、如何制作婴儿床铃
  • 简单查询：现在几点（自定义时钟界面）、绿色的东西（视觉画廊）、火龙果（交互式探索）
  • 游戏：学习快速打字、点击游戏、时尚顾问、记忆游戏、四人元素井字棋、日本视觉小说、文字冒险游戏

探索交互示例：generativeui.github.io

路径二：图像生成 + 混合架构

Web 前端代码生成 + 图像生成 = 最优组合

为什么需要混合架构？

纯图像生成的局限性：

  • 图像生成模型难以处理数千词的文本
  • 长篇内容（文章、文档、详细 UI）需要 web 渲染
  • 纯图像输出缺乏交互性和可访问性

最优分工

组件 最佳方法
长篇文本 HTML/CSS 渲染
交互元素 JavaScript/React
视觉资产 图像生成
图表、插图 图像生成
带文字的信息图 混合

图像生成在生成式 UI 中的作用

Nano Banana Pro（Gemini 3 Pro Image）支持：

  • 图像中的清晰文字用于短标语、标题、海报
  • 多语言支持，增强多语言推理
  • 多种纹理、字体和书法

生成式 UI 中的最佳用例：

  • 带风格化文字的主图和横幅
  • 产品模型和视觉预览
  • 图表和概念插图
  • 具有一致风格的品牌资产

架构：

1
2
3
LLM → HTML/CSS/JS（结构 + 长文本）
    → 图像生成 API（视觉资产）
    → 组合渲染界面

Part V: Her - 操作系统级助手

电影《Her》（2013）：Samantha 的愿景

电影简介

《Her》是 2013 年由 Spike Jonze 执导的科幻电影，探索了人与 AI 操作系统之间的关系。

剧情：Theodore，一个孤独的作家，与 Samantha——一个拥有声音、个性和学习进化能力的 AI——建立了关系。

为什么《Her》重要

Samantha 代表了 AI 助手的终极愿景：

  • 不仅仅是响应命令
  • 真正理解用户的生活、情感和需求
  • 在被询问之前预见用户需要什么

Samantha 的关键特征

  • 🗣️ 语音优先：自然、对话式交互
  • 🌐 始终可用：后台运行，随时可访问
  • 🧠 深度用户记忆：构建心智模型——偏好、习惯、价值观
  • 🎯 主动服务：无需明确请求即可预见需求
  • ⚡ 自主行动：组织邮件、日程、打电话
  • 🔄 实时处理：边听边想、边回应、边行动

核心洞察：就像我们理解朋友一样——不是记住每一次对话，而是建立一个关于他们是谁的心智模型。

操作系统级助手的核心能力

  • 🗣️ 实时语音 UI：低延迟的自然对话，跨会话上下文维护
  • 📞 代打电话：自动客服导航，信息收集和协商
  • 💻 电脑和手机使用：跨应用的 GUI 自动化，跨应用工作流编排
  • 🔗 统一数据访问：与设备和云服务集成，智能索引和检索
  • ✨ 生成式 UI：动态结果展示，交互式探索和操作
  • 🎯 主动服务：在被询问之前预见需求，个性化价值对齐

个性化价值对齐

类比：推荐系统

  • 📰 传统媒体：每个人读同一份报纸，看同样的内容
  • 📱 字节跳动/TikTok 革命：每个人看完全不同的内容
    • “每个人生活在不同的世界，有不同的价值观”
  • ✅ 结果：个性化产品更以人为本 → 用户更偏好

AI Agent 对齐的未来

当前方法：普世人类价值

  • LLM 被对齐到”普世”价值
  • 但我们真的有普遍认同的人类价值吗？

AI 应该做的是：

  • 不只是一个普世价值
  • 适应每个用户的价值和偏好
  • 认识到价值差异是巨大的

主动服务：AI 记忆能力的最高层次

用户记忆是主动服务的核心成分

用户记忆不只是记录每次对话。 就像理解朋友：

  • 我们不记得他们说的每一句话
  • 我们建立一个关于他们是谁的心智模型
  • 他们的偏好、习惯、价值观

两种记忆类型：

类型 难度 示例
事实 简单 生日、地址、卡号
偏好 复杂 上下文相关、不断演变

学习用户偏好比存储事实信息困难得多：

  • 上下文相关：论文写作风格 ≠ 旅行指南
  • 一次性 vs. 长期：”昨天点了川菜” ≠ “喜欢辣的”
  • 过度泛化风险：AI 容易错误外推
  • 需要细粒度评估

三个记忆能力层次

层次 1：基本回忆

  • 存储和检索显式用户信息
  • “我的会员号是 12345” → 准确回忆
  • 可靠性的基础

层次 2：多会话检索

  • 连接不同对话中的信息
  • 消除歧义：”为我的车预约保养” → 两辆车中的哪一辆？
  • 理解复合事件：”取消洛杉矶行程” → 找到航班 + 酒店
  • 区分活跃合同和过去的询问

层次 3：主动服务

  • 无需明确请求即可预见需求
  • 预订国际航班？→ 检查护照是否快过期
  • 手机坏了？→ 列出所有保护选项（保修、信用卡、运营商保险）
  • 报税季？→ 主动收集所有相关文件

后台 GUI Agent：技术挑战

核心问题

传统 GUI Agent 需要：

  • 前台应用窗口
  • 活跃的屏幕渲染
  • 独占输入设备访问

这与以下冲突：

  • 用户同时使用设备
  • 电池和资源效率

虚拟化方法

无头浏览器/应用执行：

  • 在虚拟帧缓冲区中渲染应用
  • Agent 与虚拟显示器交互

云手机/桌面：

  • 在云环境中运行应用
  • 需要时将结果流式传输到本地设备
  • 将计算从移动设备卸载

应用欺骗要求

应用必须相信它们：

  • 在前台运行
  • 接收正常用户输入
  • 渲染到实际显示器

技术机制：

  • 窗口管理器虚拟化
  • 输入事件注入
  • 辅助功能 API 利用
  • 容器/沙盒隔离

数据同步

对于云端操作：

  • 应用状态迁移
  • 账户凭证管理
  • 缓存和数据同步

好处：设备离线时操作继续进行，对桌面电脑特别有价值。

跨设备和服务的数据集成

统一数据访问

示例：Gemini 与 Google Workspace 集成

  • Gmail、Drive、Calendar、Docs
  • 跨服务查询和检索
  • 上下文感知建议

要求：

  • OAuth 和 API 集成
  • 权限管理
  • 数据索引基础设施

AI Agent 检索的索引

本地设备数据：

  • 文件系统索引
  • 应用数据提取

云服务数据：

  • 增量搜索索引构建

技术架构

1
2
3
4
5
6
7
8
9
10
11
12
用户数据源
├── 本地文件
├── 云存储（Drive、iCloud 等）
├── 邮件和日历
├── 消息应用
└── 浏览器历史/书签
        ↓
    索引层
        ↓
    检索 API
        ↓
    Agent 查询接口

经济模型：与应用提供商的收入分成

生态系统挑战

当前情况：

  • Agent 代表用户操作应用
  • 流量被 Agent 捕获，而不是原始应用
  • 应用失去广告收入和参与度指标
  • 结果：应用可能阻止 Agent 访问

示例：GUI Agent 被某些消息和社交应用阻止，因为流量和商业化问题

为什么阻止是有问题的

  • 降低用户体验
  • 碎片化 Agent 能力
  • Agent 和应用之间的军备竞赛
  • 最终伤害所有各方

提议的解决方案：收入分成

原则：Agent 公司和应用提供商必须建立利润分享机制

可能的模型：

  1. 基于交易的分成

    • Agent 促成购买 → 分享收入

  2. 订阅合作

    • 联合高级层级
    • 功能访问协议

  3. API 访问费用

    • 正式化的 Agent API 访问
    • 基于使用量的定价

战略要务

  • Agent 技术进步是不可避免的
  • 合作对双方都有利
  • 需要标准来实现可持续生态系统

关键要点

技术路线图

实时语音交互：

  • SEAL 架构：流式、事件驱动的 Agent 循环
  • Interactive ReAct：边听边想，边想边说
  • 解决串行处理的延迟瓶颈

多 Agent 协调：

  • 并发电话和电脑使用
  • 自主 Agent 生成和编排
  • 小模型（4-8B）足以完成专门任务

生成式 UI：

  • Web 前端代码生成（Claude Artifacts、Google Generative UI）
  • 图像生成（Nano Banana Pro）
  • 结合两者的混合架构

系统架构

扩展模态：

  • 观察：语音 + 视觉感知
  • 行动：对话 + UI 生成 + 电脑使用

操作系统级集成：

  • 后台/云端操作，不占用 UI
  • 跨设备和服务的统一数据访问
  • 生态系统可持续性的收入分成模型

愿景

《Her》范式：一个操作系统级助手，结合：

  • 实时语音对话
  • 自主任务执行
  • 生成式界面展示
  • 与用户数字生活的无缝集成

未来：AI Agent-环境交互的三个阶段

实时异步与环境交互是 Agent 的基础

🗣️ 阶段 1：语音

  • 输入：语音
  • 输出：语音
  • 数据速率：15-50 token/s
  • 延迟：<500ms
  • 挑战：快慢思考平衡
  • 解决方案：Interactive ReAct

💻 阶段 2：电脑使用

  • 输入：视觉（截图）
  • 输出：鼠标/键盘动作
  • 数据速率：~2K token/frame
  • 延迟：<1 秒
  • 挑战：精确动作执行
  • 解决方案：VLA 模型 + RL

🤖 阶段 3：物理世界

  • 输入：视觉+语音+触觉
  • 输出：语音+关节动作
  • 数据速率：~20K token/s
  • 延迟：<100ms
  • 挑战：实时控制
  • 解决方案：VLA + 世界模型

关键洞察：复杂度递增（数据速率 ↑，延迟 ↓），但架构解决方案可以跨阶段迁移

参考文献

论文

  1. Yan, H., Wang, J., et al. (2025). Step-GUI Technical Report. arXiv:2512.15431
  2. Belcak, P., Heinrich, G., et al. (2025). Small Language Models are the Future of Agentic AI. arXiv:2506.02153
  3. Google Research. (2025). Generative UI: LLMs are Effective UI Generators.

技术资源

  1. NVIDIA Research. Train Small Orchestration Agents to Solve Big Problems. NVIDIA Developer Blog
  2. Anthropic. Introducing Claude Sonnet 4.5. anthropic.com
  3. Google Research. Generative UI: A Rich, Custom, Visual Interactive User Experience for Any Prompt. research.google

查看完整演讲 Slides

Comments

▲