Breezedeus.com https://www.breezedeus.com/ 善意的AI生产幸福❤ Sat, 08 Aug 2026 08:27:17 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN All rights reserved 2026, Breezedeus <![CDATA[模型如何边看边听、边回应：实时流式多模态模型技术路线]]> https://www.breezedeus.com/article/real-time-streaming-multimodal-models https://www.breezedeus.com/article/real-time-streaming-multimodal-models Sat, 01 Aug 2026 00:00:00 GMT
 
Home | GitHub | Twitter | Youtube | Bilibili
 
notion image
📌
从“每秒传一张图”到原生全双工 AV2AV：真正的实时，取决于状态是否增量更新、说话时机是否可学习，以及音视频输出能否因果生成。
 
把摄像头接到一个多模态模型上，不等于模型会“看直播”。
最简单的产品也可以每隔一秒截一张 JPEG，与连续音频一起发给云端；模型确实在不断收到新画面，但它可能每次都在重建上下文，并不知道两张图之间发生了什么。更进一步的系统会把新音视频块增量写入 KV Cache，让模型保留对现场的持续记忆。再往前，模型还要决定何时保持沉默、何时插话、用户打断后怎样续接。最激进的方案则连输出视频也放进同一个因果生成过程：模型不只是“看着视频说话”，而是在持续生成一个有声音、有动作、会回应的可见角色。
这些方案都可以被称为“实时多模态”，但它们解决的其实不是同一道题。
本轮调研覆盖 Qwen3.5-Omni、Gemini Live、MiniCPM-o 4.5、ROMA、DuplexOmni、ELLSA、Wan-Streamer，以及 Artic、vLLM-Omni、百度智能云 RTC 等系统层方案。一个贯穿全文的判断是：
当前流式视频模型的主要技术分野，不在于“有没有视频输入”，而在于把可流式性插入了哪一层：客户端采样、编码与缓存、跨模态时间轴、响应控制、思考调度、模态专家，还是原生音视频生成。
OpenAI Realtime、Moshi 等常被放进“实时多模态”名单，但没有列为本文重点玩家。以当前 gpt-realtime 为例，它支持实时音频和单张图片输入，官方模型页仍将 Video 标为不支持，产品说明也明确说图片不会被当作 live video stream。S18 这类系统可作为音频主导、按需看图的方案，却不满足本文“视频与音频都持续进入”的严格筛选条件。
下面先建立一把尺子，再逐个拆项目。

一、先定义问题：四种“支持视频”不是同一种能力

notion image
图 1：本文采用的 L0—L3 能力分级。三个“实时”——传输、推理和交互——只有同时成立，系统才接近持续在场。

L0：上传后理解

用户录完一段视频，服务端拿到完整文件后统一抽帧、编码和推理。这是视频理解，不是流式视频。它可以回答“刚才发生了什么”，却无法在杯子即将掉落时提醒，也无法在用户演示操作的中途纠错。

L1：稀疏视觉流

音频连续上传，视频在客户端被采成周期性图片。Gemini Live 明确把视频作为逐张图片发送，最高 1 FPS；Qwen Realtime 的官方建议也是 JPEG、480p/720p、每秒不超过 1 帧。S1S2
这一路线很实用：复用成熟的实时会话接口，视觉 token 成本可控，普通网络也扛得住。但它观察到的是一串视觉快照，不是 25 FPS 的连续运动。快速手势、视线变化、短暂遮挡和细粒度动作很容易落在采样间隙里。

L2：增量音视频理解

新帧与新音频块被分块编码，历史状态持续保存在 KV Cache 或其他循环状态中，模型不必每次从头读完会话。此时“流式”进入了模型内部：它能让一段尚未结束的事件逐步改变当前判断，并在合适时刻触发回复。
MiniCPM-o 的 streaming_prefill、ROMA 的一秒多模态单元、Qwen3.5-Omni Thinker 的 chunked prefill，都属于这一层的不同实现。S3S4S5

L3：原生全双工 AV2AV

输入和输出的音视频可以重叠进行。模型一边接收用户的声音和画面，一边生成自己的语音、表情或动作；用户插话后，输出可以中止、重规划并继续。
这里的 AV2AV 是 Audio-Video-to-Audio-Video，不是给语音助手外挂一个口型驱动数字人。后者通常要等语音或文本确定后再渲染头像，输出形象无法反过来参与同一条连续时间线。Wan-Streamer 是目前公开资料中最接近原生 L3 的代表。

三种“实时”必须分别测

产品文档常用一个“低延迟”覆盖三件事：
  1. 传输实时：摄像头和麦克风的数据能否持续抵达服务端；
  1. 推理实时：新到达的块是否增量进入模型状态，还是提问时重新拼接全部历史；
  1. 交互实时：系统能否感知停顿、保持沉默、主动开口、处理重叠语音并响应打断。
这也解释了为什么“接口支持 WebRTC”不能证明模型原生流式，“模型声称全双工”也不能保证弱网下的端到端体验。两边要同时成立。

二、所有路线都绕不开的五个技术问题

单看模型结构，很容易被不同项目的命名带跑。把名字拿掉，实时音视频系统最终都要回答五个问题。

1. 连续视频怎样压进可承受的 token 预算

16 kHz 单声道 PCM 每秒有 16000 个采样，经过音频编码后尚可压到个位数或几十个 token；视频则同时包含空间和时间两个维度。假设每秒只取 1 帧，每帧仍可能产生数百乃至上千个视觉 token。若真的按 25 FPS 处理，长会话很快会撞上显存、上下文和首包时延三重限制。
因此，现实系统通常组合使用：
  • 客户端降帧率、缩放、JPEG 压缩；
  • 服务端视觉 resampler，把一帧压成固定数量 token；
  • 相似帧过滤、关键帧选择或事件驱动采样；
  • 对静态背景建立持久表示，只发送变化；
  • 用连续 latent 而非离散视觉 token 生成输出视频。
“支持 1080p 输入”与“模型理解 1080p 的每一帧”是完全不同的说法。前者可能只是接口接收上限。

2. 音频与视频怎样共享时间

一段话和一个动作是否相关，取决于它们是否发生在同一个时间窗。离线模型可以把视频均匀抽帧后整体编码；在线模型没有完整未来，必须在数据到达时建立时间关系。
主流做法有两类：
  • 显式时间 ID：给音频 token、视频 token 和文本 token 标上统一时间坐标，例如 Qwen3.5-Omni 用 TMRoPE 和显式时间戳对齐动态帧率视频与音频；
  • 固定时间窗：把一秒或 160 毫秒内的视觉、音频和输出组织为一个流式单元，例如 MiniCPM-o、ROMA、Wan-Streamer。
时间窗越短，交互越灵敏，但序列更长、调度更频繁；时间窗越长，吞吐更好，却可能把 300 毫秒内发生的“抬手—停顿—开口”压成同一块。

3. 历史怎样留下，未来怎样不泄漏

离线 Transformer 可以看到整段序列。流式模型必须保证时间 的输出只依赖 之前的信息，同时又不能反复计算过去。
典型组合是：
  • encoder 使用 causal / chunk-causal attention；
  • backbone 持久化 KV Cache；
  • 语音和视频 decoder 只消费已确认的历史 latent；
  • 分块 prefill 将新输入追加进缓存；
  • 对长会话做滑窗、压缩记忆或分层状态。
如果接口在每次 query 时把缓冲区里的全部帧和音频重新拼成 prompt，即使数据通过 WebSocket 到达，它也仍然只是“流式传输 + 批式推理”。vLLM-Omni 当前的 Streaming Video API 就明确把 session KV reuse 与 incremental prefill 列为尚未实现的限制。S14

4. 模型何时开口

传统语音助手依赖 VAD 判断“用户说完了”。在视频场景里，轮次边界不再只由声音决定：
  • 用户可能沉默地演示一个动作，期待模型及时纠错；
  • 用户说“你看这里”，真正的信息在随后两秒的画面里；
  • 模型发现危险时应该主动打断；
  • 用户只是短暂停顿或转身拿工具，模型不应抢话。
这推动了三种机制：
  • 外部 VAD / 语义 VAD 决定 turn；
  • 在主干上增加 Speak Head，单独学习听或说；
  • 把 [listen]、[speak]、[interrupt] 等控制信号写进生成序列。
“回答什么”与“现在要不要回答”相关，但不是同一个预测任务。ROMA 把后者显式拆成二分类头，MiniCPM-o 把它做成流内控制。

5. 深度思考怎样不阻塞自然交流

人类对话里，简单回应可以立刻给出，复杂问题则会边说边想、查资料再补充。若模型必须完成整个 reasoning 或工具调用后才能发出第一段语音，它的能力越强，反而越像卡住。
DuplexOmni 的核心不是换一个视觉编码器，而是把低延迟 Interaction Layer 与可插拔 Thinking Layer 解耦。前者维持“我在听、我先回应”的节奏，后者异步完成复杂推理，再把中间结果逐步回灌。这是流式多模态从“模型结构问题”走向“认知调度问题”的一个明显信号。
<ins/>

三、路线一：客户端采帧，把视频降维成稀疏视觉事件

这是目前最容易产品化、也最容易被误称为“实时视频模型”的路线。

Gemini Live：一个持续会话，视频仍是逐张图片

Gemini Live 使用有状态 WebSocket。客户端持续发送 16 kHz PCM 音频，并将视频转成单张 JPEG 图片，官方限制最高 1 FPS；模型可返回 24 kHz PCM 音频，并支持打断。S1
从工程边界看，它的实时性主要落在会话协议与音频交互上：
这一设计有三个直接后果。
第一，视觉成本与原始摄像头帧率脱钩。手机仍可 30 FPS 采集，但只有少量代表帧进入模型。第二，客户端握有采样策略，产品可以根据运动强度、场景变化或网络状态动态取帧。第三，模型端看不到采样间隔中的真实运动，所谓“视频理解”更接近带时间顺序的多图理解。
因此它适合：
  • 用户举起商品、零件或作业本，让助手识别并讲解；
  • 桌面摄像头低频观察场景，音频承担主要交互；
  • 对动作时序不敏感的导览、陪伴与远程协助。
它不适合精细动作纠错、手语、快速安全事件、球类轨迹和依赖视听亚秒同步的任务。

Qwen Realtime：同样的 API 外形，背后连接 Omni 模型

Qwen Realtime 同时提供 WebSocket 与 WebRTC。WebSocket 模式下，音频先进入缓冲区，图片可作为本地文件或实时视频帧持续追加；官方建议 JPEG、480p/720p、单帧不超过 256 KB、每秒不超过 1 帧，并要求先发送音频。WebRTC 模式则直接使用 RTP 音视频轨道。S2
这组约束透露了一个重要的系统事实：即便底层 Qwen3.5-Omni 能处理动态帧率视频，公开实时 API 仍会在接入层把摄像头流约束为稀疏帧。模型能力与产品服务边界不能混为一谈。
官方还为会话设置了视频累计时长、轮次和音频时长上限；不同 Plus / Flash 版本数值不同。S17 这不是无关紧要的计费细节，而是状态管理策略的一部分：实时会话要控制缓存增长、排队和尾延迟。

这条路线真正值得优化的是采样器

固定 1 FPS 只是安全默认值，不是最优策略。更合理的客户端可以根据：
  • 帧间视觉相似度；
  • 光流或运动幅度；
  • 用户语言中的指示词，如“现在”“这里”“这个动作”；
  • 模型反馈的不确定性；
  • 网络带宽与排队长度；
动态决定何时送帧。也就是说，第一代实时视频助手的关键模块可能不是更大的 VLM，而是一个面向回答价值的视觉采样控制器。
Artic 的思路正沿这个方向推进：传输系统根据模型的响应能力和区域重要性调整码率与量化，而不再只优化人眼观看的 VMAF。后文会回到这一点。

四、路线二：分块编码与共享时间轴，让模型真正保留“正在发生”

稀疏帧解决了带宽，但没有自动解决持续状态。Qwen3.5-Omni 与 MiniCPM-o 4.5 给出了两种代表性实现。

Qwen3.5-Omni：Thinker–Talker 上的动态时间对齐

notion image
图 2：Qwen3.5-Omni 的 Thinker–Talker 架构。视觉与 AuT 音频编码结果进入 Hybrid Attention MoE Thinker，Talker 再生成多码本语音 token，并由因果流式 codec decoder 输出波形。来源：Qwen Team, Qwen3.5-Omni Technical Report, Figure 2，CC BY 4.0。
Qwen3.5-Omni 沿用了 Thinker–Talker 分工，但把流式能力推进到编码、注意力与语音生成链路。
输入怎样进入。 视觉编码器接收图片和动态帧率视频。AuT 音频编码器将音频下采样 16 倍，得到约 6.25 Hz 的音频 token——每个 token 对应约 160 毫秒，并用动态注意力窗口兼顾局部低延迟与较长语义。S3
时间怎样对齐。 模型使用 TMRoPE，把视频和音频映射到统一时间坐标。报告描述的关键做法是：视频可以是动态 FPS，音频和视频时间 ID 以 160 毫秒为分辨率推进，同时可加入显式 timestamp text。这使“某一帧”和“某一段声音”不必靠序列位置碰巧相邻。S3
状态怎样保留。 Thinker 并不会在每个时间点重新计算完整的音视频窗口。新到达的多模态块经过编码后，只对新增 token 执行 chunked prefill；历史则以 full-attention 层的 KV Cache 和 Gated DeltaNet 层的递归状态两种形式继续参与计算。S3
Chunked prefill：逻辑上看到全部历史，实际只计算新块
先区分“模型此刻能够利用的逻辑上下文”和“本次前向真正送入的 token”。假设音视频流被切成 三个时间块，普通无状态调用会反复提交完整输入；有状态的流式 prefill 则逐块追加：
处理 时，Thinker 在逻辑上可以利用 ，但送入主干做本次 prefill 的通常只有 新产生的 embedding。 和 已经进入主干缓存，不需要重新执行整条 Hybrid MoE 前向。
这里要把 encoder 和主干分开看。 的原始音频与视频仍需经过各自 encoder，才能变成新增 embedding；至于应用再次提交重叠帧时，历史原始帧会不会重新编码，则取决于运行时是否只摄取新数据、是否缓存 encoder 输出。技术报告确认音视频 encoder 能沿时间维输出 chunk、Thinker 支持 chunked prefill，但没有公开线上服务的视觉特征缓存策略。因此，可以确定的是“进入 Thinker 的历史 token 不做完整主干重算”，不能仅凭 chunked prefill 推导出“任何历史画面都绝不会再次经过视觉 encoder”。S3
“chunked”表示一次摄取一块新 token，而不是像自回归解码那样每次只处理一个 token。假设历史长度为 ，新块包含 个 token，模型会并行处理位置 到 。chunk 内仍使用因果 mask：第一个新 token 只能读取历史，第二个还可以读取第一个，依此类推。这样既保留了流式因果性，又能利用 GPU 的块状矩阵计算。
notion image
图 2.1：本文根据 Qwen3.5-Omni 报告与 Qwen3.5 Hybrid Attention 结构重绘。进入 Thinker 主干的新增 token 只做一次增量 prefill；full-attention 层追加 KV，GDN 层更新固定形状的递归状态。图中不假设服务端一定缓存视觉 encoder 输出。
Full attention：旧 token 保留 K/V，新 token 只计算自己的 Q/K/V
在 full-attention 层，历史 token 已经产生了 和 。新块到来时，只需计算：
随后，新 query 同时读取历史 KV 与本块前序位置：
处理完毕后， 被追加进 KV Cache，供下一个音视频块使用。旧 token 的 hidden state 不需要更新，因为因果模型中位置 的表示只依赖 及其之前的信息，未来 token 的到来不会改变它。
若忽略常数和头数，重新计算长度 的完整前缀需要约 的注意力计算；复用 KV 后，新块只需约 。它省掉了旧 token 之间已经完成的计算。不过，新 query 仍要读取历史 KV，因此上下文越长，full-attention 层的显存占用与 KV I/O 仍会增长。
Gated DeltaNet：历史被压进递归状态，而不是逐 token KV
Gated DeltaNet（GDN）走的是另一条路。它不会为每个历史 token 保存一对完整 K/V，而是把过去的信息连续更新到一个固定形状的状态 中。省略具体门控和 delta rule 后，可以把单步过程写成：
当一个包含 个 token 的新块到来时，GDN 从块开始前的 出发，依次吸收新块信息，最后得到 。实现时可以使用面向 chunk 的并行 scan / kernel，不必从第一个历史 token 重新递推。下一块只需要接着这个最终状态继续更新。
因此，两类层保存的“历史”并不相同：
  • full-attention 层保存随上下文增长的 token 级 K/V，能够让新 query 精确访问具体历史位置；
  • GDN 层保存固定形状的递归状态，避免在每一层搬运完整历史 KV；
  • Hybrid backbone 将二者交错：GDN 承担更便宜的长序列状态传播，间隔出现的 full attention 保留精确的全局 token 交互能力；
  • MoE 解决的是每个新 token 激活哪些前馈专家，降低计算量，但不负责会话状态的保存。
这就是报告所说 GDN 能降低长音视频推理中的 KV-cache I/O 的具体含义：它不是“把所有旧 KV 压缩后仍按 token 查询”，而是把一部分层改造成递归状态机。Qwen3.5 系列公开实现采用 GDN 与 full attention 的混合层布局；Qwen3.5-Omni 报告确认 Thinker 和 Talker 都使用包含 GDN 的 Hybrid MoE，但没有公开每个 Omni 版本的完整层数和服务端缓存配置。S3S19
套回滑动窗口： 到 是否重算
如果上一个时刻的逻辑窗口是：
当前窗口是：
那么在有状态流式推理里，不应把整个 当作一条新 prompt 再算一次。真正新增的只有 ：
如果应用每次都把完整 发给一个无状态接口，并且服务端没有 prefix cache，窗口内 token 才会被全部重新计算。
严格的固定长度滑窗还有一个边界。full-attention KV Cache 可以淘汰最旧位置，使新 query 不再访问它；但 GDN 的递归状态已经吸收了早期 token，一般不能精确地把某个最旧 token 的贡献“减掉”。因此，Qwen3.5-Omni 更适合被理解为前缀状态持续增长或累积，而不是每一步都执行可逆的固定 长度滑窗。256K 是模型训练和支持的最大逻辑上下文，并不表示每次流式更新都会重新计算 256K token；超过上限后采用截断、重建、摘要还是其他缓存回收方式，技术报告没有公开。S3
输出怎样流出。 Talker 不直接生成完整波形，而是通过多 token 预测生成 RVQ codec token，因果式 Code2Wav 再把已到达的 codec 块立刻解码成语音。ARIA（Adaptive Rate Interleave Alignment）用于协调文本 token 与语音 token 的不同生成速率，避免固定比例把语音节奏绑死。S3
这是一条非常典型的“统一理解主干 + 独立流式语音解码”路线。它能持续看和听，能低延迟说，但输出视频不在生成闭环里，因此属于 L2，而不是原生 AV2AV。
报告给出了视频输入在单并发下的首包时延：Flash 约 426 ms、Plus 约 651 ms；音频分别约 235 ms、435 ms。S3 这些数字只适合说明同一报告内的相对量级，不能与其他项目的“首个音频块”“模型侧 latency”直接横比，因为输入长度、网络、硬件和计时边界都不同。
<ins/>

MiniCPM-o 4.5：Omni-Flow 把输入和输出切到同一条流

MiniCPM-o 4.5 的实现更适合观察“流式模型内部到底存什么”。它不是简单地把图片和音频拼进 prompt，而是把环境输入与模型输出组织成连续时间窗。S4
先分清 MiniCPM-o 4.5 与 Omni-Flow
MiniCPM-o 4.5 是一套具体的多模态模型与推理系统，Omni-Flow 则是它实现全双工交互时采用的建模和执行范式。 前者回答“哪些模块负责理解和生成”，后者回答“输入、控制和输出怎样沿时间排列，状态怎样跨时间窗延续”。两者不是并列的两个模型，Omni-Flow 也不是一层可以单独画在网络结构里的神经模块。S4S20
因此，streaming_prefill 和 streaming_generate 是公开实现用来执行 Omni-Flow 的接口，不是 Omni-Flow 本身；而 Qwen3-8B、视觉与音频 encoder、语音 decoder 才是实际参与计算的模型组件。概念上可以把 Omni-Flow 理解为 MiniCPM-o 4.5 的“全双工运行规则”，公开代码中的状态结构和接口则是这套规则的具体落地。S20
先看实际结构：不是两套名为 Thinker–Talker 的大模型
这里需要先校正一个容易由术语产生的误解：Omni-Flow 不是一对叫作 Thinker 和 Talker 的模型模块，而是把输入、控制和输出排列到共享时间轴上的序列化与交互框架。 MiniCPM-o 4.5 的实际模型结构更接近“一个中心语义主干，加一条轻量语音生成链”。S4S20
notion image
图 3：本文根据 MiniCPM-o 4.5 论文与公开实现重绘的端到端结构。图中的 thinker-like / talker-like 只是功能类比，不是论文定义的模块名。
视觉和音频先由各自的 encoder 压缩成 embedding，再共同进入唯一的 Qwen3-8B 主干。这个主干承担三类工作：理解当前音视频和历史上下文；生成 <|listen|> / <|speak|> 控制；在需要开口时生成文本 token 及其 hidden states。论文给出的全双工文本解码速度约为每秒 3—4 个 token。S4
当主干决定说话时，新增文本 token 与对应的 LLM hidden states 会一起送入约 0.3B 的轻量 Llama 语音 token decoder。它不重新理解视频和音频，而是把主干已经形成的语义表示展开为约 25 token/s 的 S3 语音 token；之后，流式 flow-matching decoder 再结合参考音频，把这些语音 token 增量还原成可播放波形。TAIL 位于文本与语音时间线之间，负责限制文本前瞻并协调语音生成和实际播放进度。S4
因此，如果只讨论功能，可以把 Qwen3-8B 称为 thinker-like，把“语音 token decoder + 波形 decoder”称为 talker-like；但它和 Qwen3.5-Omni 的显式 Thinker–Talker 架构并不相同。MiniCPM-o 没有另一套与语义主干对称的 Talker Hybrid MoE，也不是两套大主干各自持续推理；它是中心 LLM 先给出控制、文本与 hidden states，轻量声学生成链再消费这些状态。所谓全双工主要来自跨时间窗的重叠：模型一边播放上一窗生成的语音，一边继续摄取下一窗的画面和声音。
视觉与音频先被压到相近量级
MiniCPM-o 4.5 使用约 0.4B 的 SigLIP 视觉模块。一张图片可按 slice 处理，每个 slice 原本有 1024 个 token，再经 resampler 压缩为 64 个，压缩比 16 倍。全双工设置下单 slice 最大约 448×448。S4
音频侧使用约 0.3B 的 Whisper Medium。原始编码约 50 token/s，再压缩 5 倍到 10 token/s。这样音频和低帧率视觉可以在同一秒内进入主干，而不会让视觉 token 完全淹没其他模态。S4
Omni-Flow 不再把输入、回答当作两个阶段
上面的模型结构说明“由哪些模块计算”；接下来沿一个时间窗展开 Omni-Flow，看这些模块接收的输入和产生的输出如何进入同一条因果序列。
notion image
图 3.1：上半部分是本文根据 MiniCPM-o Omni-Flow 重绘的时间窗；下半部分是 ROMA 的显式 Speak Head。两者都把轮次问题改写为时间上的连续决策。
对时间窗 ，可以把流式单元抽象为：
其中 是环境视觉， 是环境音频， 是模型在该窗的文本/语音输出， 是 listen / speak 控制。模型没有输出时，不是留空，而是写入 [listen]。于是“沉默”也成为可学习的序列状态。
论文的消融值得注意：在其训练设置里，1.0 秒时间窗优于 0.2 秒和 0.1 秒；显式边界有帮助；独立的 Listen–Speak 控制也优于只靠文本内容暗示状态。S4 这说明更细的切片并不自动带来更好的实时性。调度次数、短块语义不足和训练分布都可能抵消理论上的低延迟。
TAIL 解决文本、语音和播放进度的错位
主干大约生成 3—4 个文本 token/s，语音 decoder 则约 25 个 speech token/s。如果机械地按固定比例交错，文本可能思考得太快，语音来不及播放；也可能文字不足，声音被迫等待。S4
TAIL（论文中的时间对齐机制）根据累计播放进度动态调整当前生成的文本量，并限制前瞻范围。目标不是让所有模态 token 一一对齐，而是保证可听见的输出时间线不被文本解码节奏拖垮。
推理接口暴露了真正的状态边界
有必要把 streaming_prefill 和 streaming_generate 展开，因为它们不是普通 chat API 的两个方便函数，而是 Omni-Flow 在推理时的直接落地。不过也要避免倒因为果：Omni-Flow 是训练和序列化范式，这两个接口只是公开实现用来执行每个时间窗的方法。
全双工模型先通过 as_duplex() 切换模式，再由 prepare() 初始化一次会话。prepare() 会清空上次交互状态，将 system prompt 和可选的参考音频预填进主干，并初始化 TTS、Token2Wav 与滑动窗口状态。此后，每个约 1 秒的时间窗都运行同一个循环：S5S20
这不是“先听完整段，再回答”的两阶段流程。prefill → generate 会在每个时间窗重复，前一个窗生成的输出和后一个窗新到达的环境输入都会进入同一条因果序列：
或者：
下一秒到来时， 直接追加在 后面。于是“监听”不是没有调用模型，也不是由外部 VAD 暂停生成，而是模型明确生成进历史的一种输出状态。
streaming_prefill 负责把当前环境写进状态。 源码会先判断这一窗属于 AUDIO、VISION、OMNI 还是 TEXT，然后写入 <unit> 边界。视频帧经 SigLIP 与 resampler 变成视觉 embedding；音频经过支持增量 KV Cache 的 Whisper encoder、投影和池化后变成音频 embedding。两类 embedding 随后被送进 Qwen3 主干。主干更新自己的 KV Cache，但此时不展开完整回答，只保存最后位置产生的 pending_logits。S20
可以把 pending_logits 理解为“模型看完这一秒以后，对下一个控制 / 内容 token 的即时分布”。它连接了摄取和决策，使 streaming_generate 不必再把这一秒的图像和音频重新前向一次。
streaming_generate 先决定 listen 还是 speak，再决定说什么。 它直接消费 streaming_prefill 留下的 pending_logits。在论文采用的显式 Listen–Speak 控制里，第一个关键输出是 <|listen|> 或 <|speak|>：
  • 若为 <|listen|>，该时间窗立即以 </unit> 结束，返回 is_listen=True 和静音波形；
  • 若为 <|speak|>，主干在该窗内继续生成一小段文本，公开实现默认最多生成 20 个 speak/text token；
  • 新文本 token 对应的 LLM hidden states 被送入轻量语音 decoder，后者复用自己的 TTS KV Cache，生成约一秒的语音 token；
  • Token2Wav 再把语音 token 增量转换为可播放波形；如果轮次尚未结束，TTS 和 waveform cache 会保留给下一时间窗继续使用。S20
一次循环实际维护的不只是“一个 KV Cache”，而是几组生命周期不同的状态：
状态
由谁更新
保存什么
何时重置或回收
LLM / Omni-Flow 状态
prefill 与 generate 都会更新
system prompt、历次 <unit>，以及视觉/音频 embedding、listen/speak 和文本产生的主干 KV
会话重置，或按 basic/context 滑动窗口回收
音频 encoder 状态
streaming_prefill
Whisper encoder 的历史 KV、尚未消费的音频 buffer、chunk 计数
encoder 上下文到顶或会话重置
pending_logits
prefill 产生，generate 消费
当前时间窗末尾的下一 token 分布
每个时间窗只消费一次
TTS 状态
streaming_generate
已生成语音 token 的 KV、文本进度和当前发言起点
一次发言结束后重置
Token2Wav 状态
streaming_generate
尚未合成为波形的语音 token、flow / vocoder cache
发言结束并 flush 后重置
这种拆分解释了“全双工”是怎样出现的：模型在第 秒生成的语音可以继续播放；第 秒的新画面和环境音频仍可进入下一次 prefill，模型再根据更新后的现场决定续说、结束或保持监听。输入与输出在墙上时钟中重叠，但在因果 token 序列里仍按“本窗输入在前、本窗决策与输出在后”的顺序组织。
公开实现还在每个 </unit> 后登记时间单元，并提供两种长会话回收策略：basic 只保留最近的 token；context 额外保护 system prompt 与最近上下文。这里的滑窗是推理系统的缓存管理，不是 Omni-Flow 的训练定义。S5S20
还要区分模型仓库里的另一组同名方法。半双工 streaming 示例使用 streaming_prefill(session_id, msgs, ...) 逐块摄取完整用户输入，等最后一个 chunk 到达后才调用一次 streaming_generate；它的目标主要是降低回答的首 token 延迟。全双工 Omni-Flow 使用的则是 as_duplex() 后的接口：每个时间窗都交替调用一次 prefill 和 generate，并在当窗输出 listen 或 speak。只看函数名，很容易把两者误认为同一种执行方式。S20
对外的 Realtime API 又隐藏了这层区别。客户端只需通过 WebSocket 连续发送 input.append——16 kHz 单声道 float32 PCM 和可选 JPEG 帧——并接收 listen、text、audio 三类 response.output.delta。Gateway 与 PyTorch 或 C++ worker 在内部驱动上述时间窗循环。S5
因此，这两个接口最值得读者记住的不是名称，而是状态边界：prefill 摄取当前一秒并留下下一 token 分布；generate 消费这份分布，完成 listen/speak 决策和当窗输出；两者共同把 Omni-Flow 的一个 写进持续会话。
作者还声称模型可在低于 12 GB RAM 的边缘设备运行。S4 这应理解为特定量化、后端与配置下的项目目标，不宜直接推导成所有实时视频工作负载都能在消费设备上满速运行。
<ins/>

五、路线三：把“何时说”从“说什么”里拆出来

共享时间轴让模型知道发生了什么，但并不能保证它学会自然轮次。ROMA 的设计很克制：它基本沿用 Qwen2.5-Omni，只新增一个很小的 Speak Head，把主动响应变成显式预测任务。S6

ROMA：一秒多模态单元 + 二分类触发头

ROMA 将每 1 秒音频和同一秒的视频帧组成一个 multimodal unit。视频与音频 token 按固定顺序包装，使用 chunked TMRoPE：S6
  • 同一单元内的视频 token 共享时间 ID；
  • 音频 token 按 40 ms 分辨率推进；
  • 后续单元延续全局时间 ID；
  • 历史通过持久 KV Cache 保留。
模型推理时以 2 FPS 读取视频，每帧像素数限制在 65,536 以内。论文报告单个流式单元的平均编码时间约 0.3697 秒，这让每秒一次的在线决策在其测试硬件上具备可行性。S6
Speak Head 是一个两层 MLP，与语言模型输出头并行。它不是只看最后一层 hidden state，而是对最后 层做加权组合，然后每个流式单元输出一次“触发 / 不触发”。这样做的直觉是：中间层可能保留更多音视频时序线索，最后一层则更偏向下一个文本 token。S6
训练分两阶段：
  1. 先做 streaming format alignment，让原本按完整轮次训练的 Omni 模型适应一秒一块的输入格式；
  1. 再用 timing BCE 训练 Speak Head，同时保留一个较小权重的问答语言模型损失，避免模型只学会时机却丢掉回答能力。
训练数据也围绕响应时机分层：约 2.7 万主动在线交互样本、10.9 万旁白样本、54 万反应式问答样本。这里“主动”不是营销标签，而是监督信号里真的存在“看见某事后，不等用户提问就开口”。S6

为什么一个小 Head 值得单列为路线

它提供了很强的工程可解释性：
  • threshold 可以按场景调节，安全提醒宁可敏感，陪伴对话可以更克制；
  • Speak Head 可以单独做 ROC、误触发和漏触发评估；
  • 主干模型与语音合成链路可以保持相对稳定；
  • 轮次数据量不够时，不必重训整套音视频生成模型。
代价也明显。每秒一次的二分类仍是粗粒度控制；它判断“现在是否说”，但重叠语音、被打断后的续接、后台工具调用等复杂交互仍需额外状态机。ROMA 更像是从回合制走向全双工的最小改造，而不是终点。

六、路线四：交互层与思考层异步，让“先接住话”不必等“完全想清楚”

notion image
图 4：DuplexOmni 将实时 Interaction Layer 与可插拔 Thinking Layer 解耦；Interaction Model 内部再以时间片驱动 Thinker–Talker。来源：DuplexOmni, Figure 2。
许多全双工模型的矛盾是：交互要求 500 毫秒内有反应，复杂推理却可能需要数秒。DuplexOmni 把这个冲突变成架构边界。S7

先分清两组容易混淆的名字

论文层面的 Interaction Layer / Thinking Layer，和 Interaction Model 内部的 Thinker / Talker 不是同一组模块：S7S21
  • Interaction Layer（S1） 是整套实时 DuplexOmni 模型，负责持续听、看、控制节奏并输出文本和语音；
  • Thinking Layer（S2） 是外接的慢速推理或工具服务，可以是更强的 LLM、检索系统或 Agent；
  • Thinker 是 S1 内部的多模态语言主干；
  • Talker 也是 S1 内部的语音 codec 生成模块。
因此，问“Interaction Layer 和 Thinking Layer 是否一起训练”时，答案是：没有证据表明 S1 与外部 S2 做了端到端联合训练。 S2 是通过 OpenAI-compatible endpoint 接入的可插拔服务；论文实验的默认配置甚至直接使用 Gemini-3.1-Flash-Lite 作为 Thinking Layer。训练的重点是让 S1 学会何时请求 S2、等待或取消，以及怎样把 S2 返回的片段组织成适合当前对话的表达，而不是把梯度反传进 S2。S7S21

真正进入训练流水线的是 S1 内部的 Thinker 与 Talker

DuplexOmni 从 Qwen3-Omni 初始化，进行两阶段 SFT：第一阶段用大规模语音交互数据建立基础的全双工听说能力，第二阶段用更高质量的复杂交互和视频通话数据强化打断、后台思考和视觉场景。S7
但 Thinker 与 Talker 也不是在同一个 step 里同时更新。论文描述的是交替优化：训练 Thinker 时冻结 Talker，只计算 Thinker 的交叉熵；训练 Talker 时冻结 Thinker，只计算 Talker MoE 与 MTP 的交叉熵，两部分数据比例为 1:1。公开训练 README 给出的标准路径更明确地采用先训练 Thinker，再从 Thinker checkpoint 训练 Talker，并注明不要求 joint training。两种表述的执行粒度略有区别，但共同点一致：Thinker 与 Talker 共享训练数据和接口约束，却没有同时接受一条端到端梯度。S7S21
可以把 Thinker 的监督写成 masked next-token cross-entropy：
其中 包括按时间片组织的音频、视频、历史和 S2 feedback； 是训练标签不等于 -100 的位置。目标 不只是普通回答文本，还覆盖数据中显式标注的交互控制与语义输出，因此 Thinker 会学习“现在继续听、开始说、停止播放、请求或暂停后台思考”等行为。公开实时实现把这些结果具体解析为 asr、tts、tts_control 和 system2_control。S7S21
Talker 的损失又分成两部分。主自回归分支预测每个 speech frame 的第 0 层 RVQ codec：
MTP / code predictor 再根据 Talker hidden state、第 0 层 codec 和已经生成的残差层，预测其余 RVQ codebook：
源码中的统一形式是：
公开 Talker recipe 设置 、、，同时冻结 language model 与 visual module，只训练 Talker；代码里最后一项变量仍叫 mlp_loss，实际计算的是各残差 RVQ codebook 的 MTP cross-entropy。Thinker 阶段则使用标准语言模型交叉熵。这里没有一项“Interaction–Thinking alignment loss”，因为外部 S2 根本不在这条梯度图里。S21

推理时，S1 与 S2 通过控制 token 和流式片段协作

每个约 480 ms 的时间片，Interaction Layer 持续接收当前音频、同时间片采样的视频帧、对话历史，以及此前已经到达的 S2 片段。它不会因为发起慢思考而暂停：
论文层面的协议是：S1 需要帮助时，把对话文本、视频信息与任务状态发给 S2；S2 用特殊控制 token 包装中间结果并流式返回；如果用户补充条件或任务已经变化，S1 可以停止当前 S2 输出，再用新上下文发起请求。S1 始终保留最终表达权——S2 返回的是“后台材料”，不是直接绕过 S1 播放给用户的答案。S7
公开实时服务给出了更具体的实现。S1 每片输出 system2_control：[THINK] 会创建一个异步 S2 streaming task，[WAIT] 会停止或取消旧任务。S2 输出被拆成 【…】 短片段放入队列，随后以 from_s2 字段逐片注入后续 S1 请求；实现还在相邻 S2 片段之间加入约 0.5—1.0 秒的调度间隔，避免后台模型一次吐出过多文字，压垮实时说话节奏。如果 S1 生成 [STOP]，服务会丢弃尚未播放的 Talker 音频并清空播放缓冲，用于处理打断。S21

S1 内部，Thinker 与 Talker 也按流水线解耦

在时间片 ，Thinker 生成 Assistant 文本 token、对应 embedding 和 hidden states 。二者分别投影后逐位置相加，形成 Talker 条件：
Talker 的 prefix 不只包含当前 ，还保留此前各时间片的条件序列和完整 RVQ codec 历史。它在当前片生成六个 codec frame，对应约 480 ms 语音，再由 Code2Wav 解码。公开服务进一步把 Thinker、Talker 和 orchestrator 拆成独立服务：Thinker 先返回文本、token id 与对齐 hidden states，orchestrator 将这些张量放入异步队列，Talker worker 随后生成音频。这样下一轮感知与文本决策可以继续推进，不必和上一片语音生成严格串行。S7S21
Talker 复用 KV Cache 与 codec history，Thinker 和 Talker 再配合图执行优化，目标是让实时因子 RTF 小于 1——即生成一秒语音所需计算少于一秒。外层的 S1–S2 异步解决“慢思考阻塞交互”，内层的 Thinker–Talker 流水线解决“文本决策阻塞语音生成”；这是 DuplexOmni 实际上存在的两级解耦。
<ins/>

训练数据必须包含“对话中的不完美时序”

DuplexOmni 使用 Writer–Director 方式构造包含重叠、沉默、补充、打断和延迟思考的训练场景。这个细节比模型参数量更值得关注：回合制语料里没有“用户在模型说到一半时插话”，结构再先进也学不会自然恢复。
公开模型卡显示权重采用 Apache-2.0 发布，Thinker 与 Talker 合计约 35B BF16；项目建议至少 8 张 H20 才能获得低延迟，并明确列出意外沉默和语音质量问题。S8 这给出了一个很现实的定位：DuplexOmni 展示的是强全双工交互架构，不是轻量生产方案。
论文表格给出约 0.506 秒 latency。S7 与 Qwen 或 Wan 的数字一样，应按该项目测量边界阅读，而非放进排行榜。

七、路线五：模态专家各算各的，但在同一个注意力空间里交流

notion image
图 5：ELLSA 的 Self-Attention Mixture-of-Experts。Speech Expert 与 Action Expert 保留各自参数，但产生的 K/V 按同一因果序列进入统一注意力上下文。来源：ELLSA, Figure 1。
ELLSA 面向的不只是视频通话，而是机器人与具身交互：输入有语音和视觉，输出除了语音，还可能是离散动作。它采用 SA-MoE（Self-Attention Mixture-of-Experts）避免让一个稠密主干同时承担所有模态计算。S9

第一步不是“融合特征”，而是把四条流排成一条因果时间线

ELLSA 默认以一秒为一个 time block。第 个块不是简单地把四种 embedding 相加，而是构造成一段有固定语法的交错序列：S9
这里的 <bos> 是 begin-of-speech，不是通常语言模型里的 begin-of-sequence；boi、bot、boa 分别表示 image、text 和 action 的开始。模态边界 token 同时承担两个功能：一是告诉模型当前区间该走哪个专家，二是把“什么时候说、什么时候动”变成可监督的序列预测问题。
具体到每个块：
  • 语音输入先经过 32 层、hidden size 2048 的流式 Mamba encoder，以 25 Hz 产生表示；每 5 帧拼接一次，下采样到 5 Hz，所以一秒最终只向主干送入 5 个 speech embedding。
  • 视觉输入由 Emu3-VisionTokenizer 离散化。在 LIBERO 设置里，每秒不是只有一张图，而是前视相机和夹爪相机各取一帧；时间采样仍然只有 1 Hz。
  • 文本输出每块最多生成 8 个 token。没有必要开口时，模型必须显式生成 <silence>，而不是依赖外部 VAD 替它决定。
  • 动作输出由 FAST tokenizer 表示。公开的一秒配置每块生成约 10 个 action frame 对应的 token；不应移动时则生成 dummy action。
固定顺序也确定了块内因果关系：当前动作可以依赖刚刚听到的语音、当前画面和本块生成的文本；文本可以依赖语音与画面，但不能反过来看到尚未生成的动作。跨块再按时间继续追加，因此整体仍是一条标准的 causal sequence。
语音输出是一个例外：它不作为第五段 codec token 塞回主序列。ELLSA 从 Speech Expert 生成文本时的 hidden states 中抽取条件，经两层 MLP 投影后交给 CosyVoice2-0.5B。TTS 模块每 8 个文本 embedding 生成 25 个 speech codec。这样，文本承担“这一秒说什么”的语义骨架，codec 模型承担“怎样发声”。S9S22

SA-MoE 不是常见的 Top-K MoE

“Speech Expert 与 Action Expert 共享注意力”很容易被理解成共享同一套 attention 权重，实际并不是。两套专家各自保留预训练得到的 Q/K/V projection、output projection、LayerNorm 和 MLP；所谓 unified self-attention，指的是它们产生的 K/V 按原始 token 顺序进入同一个因果注意力上下文。S9S22
对第 层、第 个 token，先由模态边界确定专家：
然后只用该专家的投影计算当前位置的 query、key 和 value：
但注意力读取的是此前所有专家写入的统一 K/V 序列：
最后，attention output projection 和 MLP 又按 路由回对应专家。以一个 text token 为例：它的 来自 Speech Expert，却能注意到前面由 Action Expert 编码的前视图和夹爪图 K/V；以随后生成的 action token 为例，它用 Action Expert 的参数计算，但可以读取刚刚的语音、视觉和回答文本。因此，“专家各算各的”与“跨模态共享状态”同时成立。
它与普通 MoE 有三个关键区别：
  • 没有学习型 router，也没有 Top-K、负载均衡或 expert capacity；模态区间直接决定路由。
  • 一个位置只激活一套专家参数，但 attention 的历史不按专家隔离。
  • 两个专家必须逐层对齐。ELLSA 恰好选择了配置相容的 Llama-3.1-8B-Instruct 与 Emu3-Base：都是 32 层、hidden size 4096、32 个 attention head 和 8 个 KV head，所以每一层都能直接交汇，构建 SA-MoE 本身不需要新增主干参数。两者保留各自的 RoPE 设置，但共享全局 token index。S9
这也是作者把 speech 与 text 合成一个专家、vision 与 action 合成另一个专家的原因：前者尽量继承 Llama 的语言能力，后者尽量继承 Emu3 / UniVLA 的视觉—动作能力。论文的三专家消融显示，继续把 speech/text 或 vision/action 拆开并没有带来稳定收益。

推理时，一秒钟内实际发生什么

可以顺着一个“机器人一边放碗、一边回答问题”的时间块看：
  1. Mamba encoder 增量编码这一秒新到达的语音，得到 5 个 speech embedding。
  1. 系统抽取当前前视图和夹爪图，视觉 tokenizer 将两张图变成离散 token。
  1. SA-MoE 对“语音 → 图像”做 causal prefill，把两种专家产生的 K/V 写入同一缓存。
  1. Speech Expert 自回归生成最多 8 个 text token；若听到普通问题就回答，若无人说话则生成 <silence>，若听到打断命令可生成 Action Cancelled。
  1. 文本 hidden states 同时送往 CosyVoice 条件接口，生成该段话的 speech codec。
  1. 插入 <boa> 后切换到 Action Expert，自回归生成 FAST action token。动作专家能看到本块文本，因此可以区分“继续动作并回答”和“停止动作并确认取消”。
这里的“同时说和做”是同一时间块上的并发输出语义，不意味着 GPU 在一个瞬间并行采样两串 token。公开参考实现仍按“文本在前、动作在后”的块内顺序解码；随后语音和动作覆盖同一个输出时间段。固定顺序换来的好处是因果关系明确，代价是动作必须等本块文本决策完成。
ELLSA 对不同历史采用不同保留策略：语音输入与文本输出保留完整会话历史，以维持对话连贯；视觉与动作只保留最近两秒，避免每秒数百个图像 token 让上下文迅速膨胀。这不是把过去画面“总结”进一个专门记忆模块，而是直接承认具身控制更依赖近期观测，语言对话更依赖长期历史。S9

两个专家怎样训练到能彼此读懂

ELLSA 不是把 Llama 和 Emu3 拼起来后直接端到端全量训练，而是分三阶段降低能力互相覆盖的风险。S9
第一阶段：分别建立专家。 Mamba speech encoder 先在 LibriHeavy 与 GigaSpeech 上预训练 300k steps；随后连接 Llama-3.1-8B，在 ASR 和 speech QA 上训练 40k steps，此时只训练连接器和 Llama LoRA，encoder 与 Llama 主体冻结。Action Expert 则直接继承 UniVLA：其 Emu3-Base 已经过 world-model post-training 和 policy learning，最后 1,024 个词表位置被替换成 FAST action token。
第二阶段：训练 SA-MoE 的跨专家协作。 两个专家都挂 rank 256、scale 1.0 的 LoRA，在 ASR、语音问答、语音条件机器人控制、边说边做、场景问答、错误指令拒绝和 action barge-in 的混合数据上训练。论文配置为 batch size 1024、学习率 、500 steps。输入 speech embedding 和 image token 的 label 被 mask，只监督模型应该生成的 text 与 action token。S9S22
公开实现将主损失写成按有效 token 数归一化的两路 next-token cross-entropy：
其中：
和 分别是未被 -100 mask 的文本与动作位置； 对应代码里的 action_loss_weight。关键不只是“同时有两个 loss”，而是两路梯度都要穿过共享的跨专家 attention 信息流：文本 loss 会迫使 Speech Expert 学会读取视觉 K/V，动作 loss 会迫使 Action Expert 学会读取语音和文本 K/V。
第三阶段：接入语音生成。 主 SA-MoE 冻结，随机初始化的两层 connector 把 Speech Expert hidden states 投到 CosyVoice2-0.5B 的输入空间，只微调 synthesizer 的 language-model 部分。此时优化目标切换为 speech codec 的生成 loss：
论文配置训练 20k steps。公开代码在这一阶段把原 SA-MoE loss 乘零，只保留 CosyVoice 返回的 codec loss，因此“会不会说、做什么”与“声音怎样合成”在训练上也是分开的。S9S22

为什么选择一秒，而不是更细的时间块

一秒块看起来不够“实时”，但它是语音响应速度和动作连续性之间的折中。论文在 A100 上测得一秒配置每块 speech-to-speech 约 854 ms、speech-to-action 约 786 ms，能在下一块到来前完成。作者也训练了 0.48 秒版本：语音每块改成 4 个文本 token，动作改成 5 帧，延迟降到约 455 / 428 ms；但动作专家的 LIBERO LONG 成功率从 94.0% 降到 81.0%，整套 SA-MoE 的 LONG 成功率从 84.4% 降到 71.6%。作者推测，动作片段太短会削弱时间连续性。S9
这个消融揭示了 ELLSA 与视频聊天模型不同的实时约束：聊天模型通常希望块越小越好，机器人策略却需要一段足够长的 action chunk 才稳定。块长度不是纯粹的系统延迟参数，它也改变了学习目标。

这条路线解决了什么，又没有解决什么

ELLSA 真正解决的是：多输入、多输出怎样共享一条因果状态，同时避免每个 token 都穿过全部模态参数。 对具身系统，它允许语言专家和动作专家分别继承已有能力，再通过统一 K/V 时序学会协作。
但它还不是高帧率视频理解方案。默认每个相机每秒只取一帧，适合桌面操作、慢速导航和状态问答，不足以捕捉快速手势或细粒度运动。图像 token 也远多于语音 token：论文估计一张图约 300 token，而十秒语音只有约 50 个 token，这种长度失衡会让跨模态对齐偏向视觉。SA-MoE 合并后，相比独立专家，论文报告 speech 与 action 性能仍分别有约 10.3% 和 6.4% 的相对下降。S9
项目在 2026 年 4 月公开模型与推理代码，仓库采用 Apache-2.0；但官方 README 仍将完整训练支持列为待办，当前代码更适合复现实验和理解架构，而不是直接作为成熟的实时机器人 serving stack。S10S22
<ins/>

八、路线六：原生因果 AV2AV，让输出视频进入同一条时间线

前面五条路线的输出主要是文本和语音。Wan-Streamer 把问题推到更难的一层：模型除理解用户音视频之外，还要连续生成自己的声音、画面和行为。S11

v0.1：单 Transformer 混合离散文本与连续音视频 latent

Wan-Streamer v0.1 使用严格因果的音频 / 视频 VAE、encoder 和 decoder。时间被切成 160 ms 单元，目标输出视频为 25 FPS。S11
在同一个 Transformer 内：
  • 文本是离散 token，用 next-token prediction；
  • 音频和视频是连续 latent，用联合 conditional flow matching；
  • 输入、历史输出和当前待生成 latent 通过 block-causal attention 连接；
  • 一旦当前块完成生成，其 clean latent 会被提交到历史，供下一块条件化。
这与“LLM 先写文本—TTS 合成声音—数字人再驱动嘴型”有本质差异。后者是串联流水线，前一阶段的延迟会累积，且视频动作只被动跟随已确定的语音；Wan-Streamer 让声音和画面在同一生成状态中共同演进。

为什么要用 flow matching，而不是把视频全离散化

视频若全部变成离散 token，25 FPS 输出会形成极长序列；连续 latent 更适合保留细节，但每个块需要多步去噪。Wan-Streamer 用三阶段训练降低这个成本：
  1. 文本、音频、视频能力分别预训练；
  1. 用双工互动数据训练共同的流式行为；
  1. 用更多 solver steps 和 classifier-free guidance 的教师蒸馏出更快的学生，并通过 rolling distillation / self-forcing 缓解训练与自回归推理的分布差异。
这里的难点已经不只是 token 数，而是必须在下一个 160 ms 截止前完成当前块的多步连续生成。

v0.2 / v0.3 的 Thinker–Performer：训练是一个模型，部署才拆成两条计算路径

notion image
图 6：本文根据 Wan-Streamer v0.2 Figure 2 重绘，v0.3 原样继承这套部署流水。单 GPU Thinker 在处理当前输入 和更新 的同时，解码上一块 ；多 GPU Performer 并行生成当前块 latent。
先明确一个边界：Thinker 和 Performer 不是两套分别训练、用文本协议串起来的模型。Wan-Streamer 训练时仍是一个端到端 Transformer；只有实时 serving 时，才按照计算特征把同一模型拆成单 GPU Thinker 和多 GPU Performer。v0.3 没有重新设计这套部署拓扑，而是完整继承 v0.2。S12S23
Thinker 负责延迟敏感但序列较短的路径：
  • 用因果 audio / video encoder 编码当前 160 ms 用户输入 ；
  • 运行较短的 token-causal Transformer pass，更新语言、行为和交互状态；
  • 为每一层产生本块新增的、Performer-compatible K/V slice；
  • 接收 Performer 上一块返回的 clean audio / video latent ；
  • 用因果 decoder 把 解码成可以立即发送的 RGB 帧与音频波形。
Performer 只负责计算最重的 latent generation：
  • 接收 Thinker 刚生成的 ，写入各 GPU 已经预分片的历史 KV Cache；
  • 用 conditional flow matching 为下一输出单元 迭代去噪；
  • 将高分辨率 video latent 的长序列切到多个 rank 上，执行 Ulysses-style context parallel attention；
  • 生成完成后把 clean latent 交回 Thinker，而不是自己做最终像素与波形解码。
两者之间真正传输的主要是：
语言与行为 token 不需要作为另一条长序列发送给 Performer，因为它们已经被折叠进 Thinker 构建的 K/V 条件。边界因此比“LLM 输出一大段 prompt，再交给视频模型”紧凑得多。

Ulysses 并行到底并行了什么

640×368 视频的 latent 序列明显长于同一 160 ms 内的音频 latent。v0.2 / v0.3 因此只对视频序列做 context parallel：每个 Performer rank 保存一部分预分片 KV，并持有当前 video latent 序列的一段；attention 前后通过 Ulysses all-to-all / gather 交换所需分片，使一次去噪 step 能利用完整上下文。音频 latent 很短，若也切分，通信开销可能比计算收益更大，所以保持不分片。S23
这里的并行对象不是“四帧分别给四张卡生成”。160 ms 在 25 FPS 下恰好对应约 4 帧，但视频帧已经编码成一条联合 latent sequence；Ulysses 沿这条序列分片，并在 attention 内交换信息，所以跨帧运动和音视频条件仍处于同一次联合生成中。

相邻三个时间块怎样重叠

把图中的 unit 展开，会看到三项工作同时发生：
  1. Thinker 编码当前用户输入 ，并将新增语义写成 ；
  1. Thinker 解码 Performer 已经完成的上一响应 latent ，立即对外播放；
  1. Performer 用 和历史 cache 去噪生成下一响应 latent 。
到 unit 时， 被送回 Thinker 解码，Performer 已经开始算 。因此，系统不是按下面的串行路径运行：
而是形成跨块流水：
实时吞吐的硬约束是 Performer 计算、Thinker–Performer 传输和 Performer 组内通信必须大体装进一个 160 ms cadence；否则未完成的 latent 会逐块积压。端到端 signal-to-signal latency 则从 可用开始，经过编码、状态更新、latent generation 和解码，到对应响应可以发送为止，论文报告约 200 ms。两者不矛盾：160 ms 是稳定流水的吞吐节拍，200 ms 是一个信号穿过整条流水线的延迟。S23

v0.3：把长期不变的 World 与不断变化的 Event Stream 分离

notion image
图 7：本文根据 Wan-Streamer v0.3 Figure 2 与 World–Event formalization 重绘。角色、场景、声学与音色等持久 World context 只预填一次，之后每个时间块持续追加用户输入、语言形式的事件和同步音视频 realization。
v0.3 将条件分成两类：
  • World：场景、角色身份、外观、音色、声学环境等长时间稳定的信息；
  • Event Stream：用户当前声音、画面、行为文本和即时事件。
World 可以写成一个字段可变的结构化记录：
其中可以包含 scene、layout、character identity、appearance、persona、ambient sound 和 voice timbre。它不是每 160 ms 重复拼进 prompt，而是在会话开始时 tokenization 并 prefill 一次。官方 v0.2 演示页给出的部署口径是 Thinker 与 Performer 都会完成场景 prefill，约 0.5 秒后新场景进入实时状态；v0.3 延续这条机制，只是 World 描述比早期单一角色 prompt 更结构化。S12S23
随后，每个时间局部事件写成：
是事件生效区间， 指向 World 中的角色或“无角色”事件， 用自然语言描述说话、动作、镜头移动、环境变化或声音。多个事件可以时间重叠，例如一个角色边说话、边转头，同时背景里有门关闭。
流式生成的概率分解为：
其中 是到当前为止的用户文本、音频和视频。离散的语言与行为 directive 继续做 next-token prediction；连续的 audio / video latent 在同一个 clean context 下做 conditional flow matching。当前块得到的 clean latent 会提交回历史，下一块不仅能看到用户做过什么，也能看到智能体自己上一刻的表情、姿态和声音。S12

World/Event 怎样落到 Thinker–Performer 上

World/Event 是建模语义，Thinker/Performer 是部署切分，两者并不是平行的四个模块。对应关系可以这样理解：
状态
会话中怎样更新
主要落点
World tokens
建立会话时 prefill，之后通常不重复编码
Thinker 的 token/state history；对应 K/V 同步到 Performer cache
用户 Event 输入
每 160 ms 由新文本、音频和视频追加
Thinker encoder 与 token-causal pass
语言形式的 agent event
Thinker 预测说话内容和行为 directive
Thinker 的语言/状态流，并写入新增 K/V
Audio/video realization
Performer 根据 World、历史和 flow-matching 生成
Performer latent path；完成后交回 Thinker 解码
因此，World“只 prefill 一次”并不意味着 Performer 后续不再使用它。World 的影响已经固化在双方的前缀 KV Cache 中；每个新块只需传播增量 ，而不是重新传整份角色和场景描述。

自由行为为什么没有引入新的慢路径

v0.3 不建立一个单独的动作规划器，而是在智能体语言流里交错两类 token：
括号内是开放词表行为，括号外是真正说出的内容。Thinker 在同一 token-causal pass 中预测二者，它们一起进入 ；Performer 随后把“拿杯子、望向窗外”和“说出这句话”共同渲染成同步音视频。因此行为不是 TTS 完成后再由动作模型补上的后处理，也不需要新增一条 latency-critical RPC。S12
模型输出仍为 640×368、25 FPS，每 160 ms 一个同步音视频单元。v0.3 改变的是预训练目标和表达空间，而不是 v0.2 已经确定的分辨率、时间块和 Thinker–Performer serving topology。S12
这个设计揭示了长时视频交互的另一条主线：不要把“这个角色长什么样”和“他此刻抬起了左手”以同样频率重复编码。持久世界与瞬时事件分离，既节省上下文，也减少角色漂移。
<ins/>

原生 AV2AV 的代价

Wan-Streamer 接近能力阶梯的 L3，但成本最高：
  • 训练数据必须包含同步输入输出音视频和自然重叠；
  • 因果视频 decoder 的画质与延迟直接冲突；
  • 任何流式误差都会进入历史并持续累积；
  • 打断不再只是停止音频队列，还要安全终止视频 latent 并重建动作连续性；
  • 服务端必须同时满足高吞吐 Transformer 与低尾延迟 flow solver。
因此，原生 AV2AV 不会立刻替代语音输出型 Omni 模型。它更可能先用于虚拟角色、远程呈现和高价值陪伴，再逐步下沉。

九、模型之外：实时视频最终是 RTC、推理服务与反馈控制的共同问题

notion image
图 8：生产系统参考架构。模型侧首包只是总延迟的一段；终端采样、网络、排队、播放缓冲和打断清理同样决定体验。
把模型部署成一个 WebSocket endpoint 只是起点。端到端延迟可以粗略拆成：
如果用户在模型说话时打断，还要加上 VAD / 语义判断、服务端 cancel 传播、客户端播放队列清空和回声闭环隔离。

Artic：传视频不是为了好看，而是为了让模型答对

传统 RTC 的 ABR 主要优化分辨率、帧率、卡顿和 VMAF。视频助手的接收者是模型：有些区域即使人眼觉得模糊，模型仍能答对；另一些看似轻微的压缩却会抹掉标签、手势或工具细节。
Artic 提出两类机制：S13
  • ReCapABR：根据模型“回答能力随码率何时饱和”来限制视频码率，为网络波动留出余量；
  • ZeCoStream：利用模型反馈定位与当前回答相关的区域，客户端在低带宽时调整量化参数，把比特留给关键区域。
作者在 DeViBench 上报告，相比基线准确率提升 15.12%，延迟降低 135.31 ms。S13 这仍是特定数据集与网络轨迹下的结果，但方向很重要：未来的视频传输控制目标会从“像不像原视频”转向“足不足以支持当前决策”。
这里也有明显风险。模型此刻认为不重要的区域，可能在十秒后变成推理关键。因此 ZeCoStream 只在带宽紧张时激进压缩，并需要保留足够的未来上下文。

vLLM-Omni：接口流式不代表计算增量

vLLM-Omni 的 Streaming Video API 提供 /v1/video/chat/stream WebSocket endpoint。客户端可发送 base64 JPEG/PNG 帧和可选的 16 kHz PCM 音频，服务端返回 text / audio delta；还可用 EVS 阈值过滤近重复帧。默认每次使用 4 帧，最大缓冲 50 帧。S14
但当前文档明确指出：session KV reuse 与 incremental prefill 尚未实现，每次 query 会从缓冲的帧和音频重建 prompt。S14
这正好提供了选型时必须追问的边界：
  • 帧是到达即编码，还是提问时统一编码？
  • 同一帧会不会在多次 query 中重复 prefill？
  • 长会话显存随时间怎样增长？
  • 相似帧过滤发生在解码前还是视觉编码后？
  • 多租户 batching 会不会破坏每个会话的时间节奏？
如果这些问题没有答案，“支持流式视频 API”仍不能推导出稳定的低延迟。

百度智能云 RTC：生产链路会保留级联系统

百度智能云的多模态互动 RTC 将端侧 SDK、云端 RTC、降噪 / 分离 / 声纹 / VAD、智能打断，以及 ASR—LLM—TTS 或多模态模型连接成一套服务；产品页还强调智能抽帧，并支持文本、图片、语音流、视频流输入。S15
这代表另一种务实路线：生产系统不会因为端到端 Omni 模型出现，就立刻删除所有可观测、可替换的组件。级联链路在很多场景仍有优势：
  • ASR 文本便于审计、检索和规则控制；
  • 独立 VAD 与打断模块更易调参；
  • TTS 可稳定复用品牌音色；
  • 视觉模型只在必要时唤起，控制 GPU 成本。
厂商给出的 1.4 秒语音端到端和 0.8 秒内打断属于产品侧口径，应该在自己的地区、网络、并发与终端设备上复测。S15

十、训练数据与评测：今天的瓶颈越来越不像“模型不够大”

流式数据不能由离线问答直接替代

离线 VQA 常见格式是“完整视频 + 问题 + 答案”。全双工训练至少还需要：
  • 每段输入的真实时间戳；
  • 模型应该沉默的区间；
  • 主动开口的触发点；
  • 用户和模型重叠说话；
  • 用户中途打断；
  • 说到一半发现新视觉证据后的修正；
  • 输出语音、动作或视频的同步轨迹。
ROMA 用主动、旁白和反应式数据训练时机；DuplexOmni 专门合成 overlap、silence、supplement、interruption 和 delayed thinking；Wan-Streamer 还要构造双向同步音视频。三者的共同结论是：轮次和时间本身就是监督信号。

只测“视频问答准确率”会掩盖两类崩溃

VideoFDB 收集 237 段双人互动片段，覆盖 11 类非语言动态，用来评估 AV2AV 全双工会话代理。作者将其称为首个面向该任务的视听全双工 benchmark。S16
论文观察到两种典型失败：
  1. captioning collapse：模型不断描述画面，而不是参与对话；
  1. visual-stream ignorance：模型在显式 VQA 时会用视觉，一进入持续对话就主要依赖音频，忽略正在变化的画面。
这说明“单轮问图能答对”并不等于“长会话里会持续看”。真实评测至少要分开测：
维度
应测问题
常见错误
时间定位
能否把声音与同一时刻动作关联
用错帧、提前使用未来信息
持续视觉
没有显式提问时是否仍跟踪画面
只听音频、视觉状态停滞
响应时机
该沉默时沉默，该提醒时提醒
抢话、漏报、机械等 VAD
打断恢复
被插话后能否停止并续接
旧音频继续播放、重复回答
长时一致性
数分钟后是否记得对象与位置变化
KV 膨胀、身份漂移、背景重算
弱网鲁棒性
降帧、丢包、抖动时是否保住关键判断
画面虽流畅但答案错误
输出同步
语音、字幕、动作、视频是否同拍
口型和语义错位、动作滞后

延迟指标必须写清计时边界

目前论文里的 latency 可能分别指：
  • 单个多模态单元编码耗时；
  • 最后一个输入包到首个文本 token；
  • 最后一个输入包到首个 codec token；
  • 服务端收到数据到首个可播放音频块；
  • 包含网络的用户端到用户端；
  • 平均值、P50 或 P95；
  • 单并发或满载。
因此，本文没有制作“谁最快”的排行榜。一个更有用的实验表应该同时报告：硬件、输入帧率与分辨率、音频块长度、并发、上下文长度、首文本、首音频、RTF、P95、网络与播放缓冲。
<ins/>

十一、横向比较：六条技术路线分别在优化什么

notion image
图 9：主流方案的差异可以理解为“把可流式性插在哪一层”。现实系统通常同时采用其中两到四层。
路线 / 代表项目
视频怎样进入
状态怎样保留
谁决定何时响应
输出
最强项
主要边界
客户端采帧：Gemini Live、Qwen Realtime
JPEG，通常 ≤1 FPS
云端有状态会话，内部细节不完全公开
VAD / 语义 VAD / 服务事件
文本、语音
产品化快、带宽低
快速动作与细粒度视听同步不足
分块编码：Qwen3.5-Omni
动态 FPS 视觉 + AuT 音频 token
chunked prefill、Hybrid Attention MoE、长上下文
模型与服务控制
文本、流式语音
统一理解、强通用能力
公开服务仍可能限制到稀疏帧；不输出视频
共享时间轴：MiniCPM-o 4.5
压缩视觉 slice + 10 audio token/s
Omni-Flow、streaming prefill、KV
Listen–Speak 控制
文本、语音
开源、状态边界清晰、可边缘化
视觉帧率和窗口粒度仍有限
显式触发：ROMA
每秒单元、2 FPS
chunked TMRoPE、持久 KV
两层 Speak Head
文本、语音
时机可单测、改造成本低
触发粒度粗，复杂重叠仍靠系统
异步思考：DuplexOmni
连续音视频进入 Interaction Model
前台交互状态 + 后台思考反馈
时间片控制与 Interaction Layer
文本、语音
深推理不阻塞即时回应
35B、硬件重、公开版本仍有沉默与音质问题
模态专家：ELLSA
每秒一帧 + 一秒语音
共享 attention / KV，模态专家分算
<silence> 与流内生成
文本、语音、动作
具身 MIMO、模块可替换
视频稀疏，专家边界可能限制细粒度融合
原生 AV2AV：Wan-Streamer
因果音视频 latent，160 ms 单元
block-causal attention、历史 clean latent、World/Event
单模型内生控制
文本、语音、25 FPS 视频
输入输出音视频在同一时间线
训练、推理和部署成本最高
这张表也说明，“哪一个项目最好”没有统一答案。不同场景真正需要的能力不同。

如果做手机或网页视频助手

优先从 L1 开始：WebRTC / WebSocket + 连续音频 + 自适应 JPEG 采帧。先建立端到端延迟和视觉采样收益曲线，再决定是否需要模型内部增量 prefill。Gemini Live 或 Qwen Realtime 一类托管服务适合验证产品。
关键投入不应只是 prompt，而是：
  • 运动和语义共同驱动的采帧；
  • 客户端时间戳；
  • 打断队列管理；
  • 每一段延迟的埋点；
  • 视频缺帧时的降级行为。

如果做本地或私有化实时助手

MiniCPM-o 4.5 的接口形态更值得参考：将输入摄取与输出生成显式拆开，持续维护 KV。若现有 Omni 主干已经稳定，ROMA 式 Speak Head 是加入主动性的低风险方式。
不要一开始就追求原生 25 FPS。先验证 1—2 FPS 是否覆盖任务；对真正需要高速视觉的局部模块，可外挂轻量追踪器、姿态模型或事件检测器，把结构化结果作为高频流送给主干。

如果做机器人

ELLSA 的模态专家和共享注意力适合动作空间复杂、模块需要替换的系统；MiniCPM-o / ROMA 更适合以语言交互为中心的设备。安全控制仍应留在独立的确定性回路，不能让大模型的 1 秒时间窗直接承担毫秒级制动。

如果做虚拟角色或远程呈现

Wan-Streamer 的 World / Event 分离和 Thinker–Performer 流水线是更接近目标的架构。若成本暂时不可接受，可以采用过渡方案：Omni 模型流式输出语义和语音，低延迟表情 / 动作模型消费同一时间戳流。但要清楚，这仍不是原生 AV2AV，打断时需要跨组件回滚。

如果复杂推理和实时对话同样重要

优先借鉴 DuplexOmni 的异步分层，而不是盲目压缩一个大 reasoning model 的首 token。让前台交互模型负责承接、澄清和短反馈，后台模型负责检索、工具和长推理；两者通过可中断、可版本化的中间状态通信。

十二、给实现团队的一套选型检查表

与供应商或模型团队沟通时，可以直接逐项追问。

输入链路

  • “视频流”是 RTP 视频轨道，还是客户端转 JPEG？
  • 推荐和硬上限分别是多少 FPS、分辨率、单帧大小？
  • 音频与视频是否使用同源时间戳？
  • 快速运动是否有事件驱动采样或专用视觉前端？

模型状态

  • 每个新块是否 incremental prefill？
  • KV Cache 是否跨 query / turn 复用？
  • 长会话如何滑窗、压缩或持久化？
  • 静态画面会不会重复产生视觉 token？
  • 模型在不提问时是否持续更新视觉状态？

轮次与打断

  • 只用 VAD，还是有语义 VAD、Speak Head 或流内控制 token？
  • 用户与模型重叠说话的数据是否进过训练？
  • cancel 到音频真正停止播放的 P95 是多少？
  • 打断后保留哪些已生成文本、语音和视频状态？

性能与部署

  • latency 从哪里开始、在哪里结束？
  • 是否报告首文本、首音频、RTF、P50 与 P95？
  • 测试硬件、并发、输入长度和帧率是什么？
  • batching、prefix cache 和多租户排队怎样影响单会话节奏？
  • 弱网下优先降帧、降分辨率还是降音频质量？

评测

  • 是否测试视觉在长会话中的持续贡献，而不只是单轮 VQA？
  • 是否包含沉默演示、主动提醒、快速打断和画外音？
  • 是否检查 captioning collapse 与 visual-stream ignorance？
  • 是否用回答正确率反馈采样和码率策略？
如果这些问题没有被量化，模型 demo 再自然，也很难推导出生产表现。

结语：未来的竞争点，是谁能维持一个低成本、可打断的“现在”

过去的多模态模型把图片和音频变成更多 prompt token；今天的流式模型开始把时间本身变成一等公民。
近半年的项目已经形成六条清晰路线：
  1. 用客户端采帧把视频降成稀疏视觉事件；
  1. 用分块编码、增量 prefill 和 KV Cache 保存正在发生；
  1. 用共享时间轴和显式触发学习何时开口；
  1. 用异步 Interaction / Thinking 分层兼顾反应速度与推理深度；
  1. 用模态专家和共享注意力承载具身多输入多输出；
  1. 用因果音视频 latent 与 flow matching 走向原生 AV2AV。
它们不是互斥替代关系。一个成熟系统很可能同时使用：端侧自适应采帧、RTC 拥塞控制、模型内共享时间轴、独立 Speak Head、异步工具层和流式语音 decoder。只有对虚拟角色等场景，才值得进一步承担原生视频生成的成本。
真正稀缺的也不再只是更强的视觉问答能力，而是一个能够长期维持、持续更新、知道何时沉默、允许随时打断的“现在”。谁能用更低的 token、更少的重算和更稳定的尾延迟守住这个现在，谁才更接近真正的实时多模态。

AI Agents 知识星球

GUI Agents 技术发展迅猛，想紧跟 GUI/AI agents 技术前沿？我们的知识星球会介绍 Agents 相关的最新项目和工具，并以视频方式解读最新论文，为你开启技术新视野，快来加入吧！
加入知识星球，每周获取会员专享视频👇
notion image
 
扫码加微信小助手为好友，备注「agent」，小助手会定期邀请入群👇
notion image
当前星球包含的专享视频包括：
 
<ins/>

参考资料

  1. Google AI for Developers, Live API 与 Live API capabilities。
  1. Alibaba Cloud Model Studio, Qwen Realtime multimodal speech。
  1. Qwen Team, Qwen3.5-Omni Technical Report, 2026。
  1. OpenBMB, MiniCPM-o 4.5: A GPT-4o Level MLLM for Vision, Speech, and Full-Duplex Multimodal Live Streaming on End Devices, 2026。
  1. OpenBMB, MiniCPM-o model documentation 与 Realtime API overview。
  1. ROMA: Real-Time Omni Multimodal Assistant with Speak-Time Prediction, 2026。
  1. Muye Huang et al., DuplexOmni: Real-Time Listening, Seeing, Thinking, and Speaking for Full-Duplex Interaction, 2026。
  1. Muye Huang et al., DuplexOmni model card。
  1. Siyin Wang et al., End-to-end Listen, Look, Speak and Act, ICLR 2026。
  1. ByteDance Research, SALMONN / ELLSA official repository。
  1. Alibaba Wan Team, Wan-Streamer v0.1: End-to-end Real-time Interactive Foundation Models, 2026。
  1. Alibaba Wan Team, Video = World + Event Stream 与 Wan-Streamer v0.3 项目页, 2026。
  1. Artic: AI-Oriented Real-Time Interactive Communication for Video Assistants, 2026。
  1. vLLM-Omni, Streaming Video Chat API。
  1. 百度智能云, 多模态互动 RTC。
  1. VideoFDB: A Benchmark for Full-Duplex Audio-Visual Conversational Agents, 2026。
  1. Alibaba Cloud Model Studio, Qwen Realtime limits and specifications。
  1. OpenAI, GPT-Realtime model 与 Introducing gpt-realtime and Realtime API updates for production voice agents。
  1. Hugging Face Transformers, Qwen3.5 model documentation。
  1. OpenBMB, MiniCPM-o 4.5 official model card 与 official modeling_minicpmo.py。
  1. Muye Huang et al., DuplexOmni official repository、training framework、E2E loss computation、loss aggregation 与 realtime S1–S2 implementation。
  1. ByteDance Research, ELLSA official branch、SA-MoE implementation and loss computation 与 training entry。
  1. Alibaba Wan Team, Wan-Streamer v0.2: Higher Resolution, Same Latency 与 v0.2 project page, 2026。
]]> <![CDATA[企业 AI 转型路线图：从单点试验到可规模化能力]]> https://www.breezedeus.com/article/enterprise-ai-transform-roadmap https://www.breezedeus.com/article/enterprise-ai-transform-roadmap Sat, 25 Jul 2026 00:00:00 GMT
 
Home | GitHub | Twitter | Youtube | Bilibili
 
notion image
目录：
引子：为什么 AI 演示越来越多，能稳定运行的系统却不多一、先判断自己在哪里：把 AI 成熟度画成一张矩阵二、从第一个业务问题开始一个贯穿示例：客服工单分流三、规模化的核心：让每次交付都留下可复用资产四、把信任变成可以检查的系统证据五、技术可以快速复制，组织的工作方式不能一键安装六、一条可执行的三阶段路线第一阶段：选定一个问题，定义“成功”和“不能失败”第二阶段：把试点当成生产系统的早期版本第三阶段：复制经过验证的交付模式结语：不要问“我们上线了多少 AI”，要问“我们学会了什么”AI Agents 知识星球参考文献
 
真正值得规模化的不是某个 Agent，而是一套能够重复交付业务结果的组织能力

引子：为什么 AI 演示越来越多，能稳定运行的系统却不多

很多企业已经不缺 AI 想法。
客服希望自动分流和回复，销售希望生成商机洞察，法务希望加快合同审查，IT 希望让 Agent 处理服务台工单。做出一个可演示的原型通常也不再困难。真正困难的部分发生在演示之后：谁为结果负责？系统应该访问哪些数据？错误率达到什么水平才能上线？成本是否会随着调用量失控？一旦 Agent 能够调用工具，谁来管理它的身份、权限与行动记录？
这些问题解释了为什么“做出一个 AI 应用”和“把 AI 变成企业能力”之间隔着很长一段路。
微软在《The AI Strategy Roadmap》中把后一种变化称为 Frontier Transformation：AI 不再停留在零散的效率工具，而是进入关键业务流程，与人的判断、组织的规则和现有系统共同工作。报告将这套转型拆成五个相互依赖的驱动因素：业务战略、技术与数据、AI 交付经验、组织与文化、治理与安全。
这份报告的依据包括 70 位企业 IT 与业务决策者的深度访谈，以及微软自身和客户项目中的经验。访谈覆盖 AI 应用进展较快、推进谨慎和相对滞后的组织，时间集中在 2026 年 2 月 23 日至 3 月 13 日。它适合用来识别反复出现的组织模式，但由于样本是定性访谈且研究由微软赞助，不应把其中的经验直接当成全行业的因果定律。
如果把报告的 66 页压缩成一句话，最值得保留的判断是：
企业 AI 规模化的真正单位，不是“又上线了一个用例”，而是“又验证并沉淀了一套可复用的交付模式”。
一个成功用例若只留下了一段代码，它仍然是孤岛；如果它同时留下业务指标、数据契约、评测方法、权限边界、监控告警、人工接管规则和复盘记录，下一个团队才有可能更快、更稳地复制成功。

一、先判断自己在哪里：把 AI 成熟度画成一张矩阵

报告把企业 AI 准备度分为五个阶段：探索、规划、实施、规模化和价值实现。
阶段
组织的典型状态
下一步真正要解决的问题
探索
各团队零散试用，价值主要靠案例讲述
选定一个业务问题，停止无边界试验
规划
开始排用例优先级，建立初步指标与护栏
让业务、技术、数据和风险团队共同负责
实施
少量用例进入真实流程，开始积累运行数据
证明可靠性、安全性、采用率和业务价值
规模化
共用平台、资产、生命周期管理和培训体系逐渐形成
把单次成功变成可重复交付能力
价值实现
AI 成为日常业务能力，价值持续测量和改进
让组织从每次运行中继续学习，而不是停在“已上线”
notion image
五维成熟度矩阵：组织不一定在所有维度处于同一阶段，应优先修复最先截断业务闭环的短板。
这五级看似是一条阶梯，实际更像一张矩阵。同一家企业可能已经有成熟的数据平台，却仍然没有清晰的用例组合；某个业务部门可能在规模化 Agent，另一个部门还在学习基本使用方法；安全团队可能建立了严格审查，却没有足够的可观测性来判断系统上线后的真实行为。
 
因此，成熟度评估不应只问“我们属于第几级”，而要沿着五个维度分别提问：
  • 业务：每个用例是否对应明确的业务问题和基线指标？
  • 数据与技术：系统能否稳定取得可信数据，并以可预测的成本运行？
  • 交付：团队是否能持续评测、部署、监控和改进 AI 系统？
  • 组织：员工是否知道为什么使用、如何使用，以及何时必须依靠人的判断？
  • 治理：从审批、上线到变更、事故和退役，责任是否清楚、过程是否可审计？
短板往往不是平均分最低的那一项，而是最先截断业务闭环的那一项。

二、从第一个业务问题开始

报告反复强调“从小处开始”，但“小”很容易被误解成便宜、简单或不重要。更准确的含义是：边界足够清楚，结果可以观测，风险可以控制，团队能够在一次交付中完成学习闭环。
一个适合作为起点的用例，通常应同时满足几项条件：
判断维度
需要回答的问题
可留下的证据
业务价值
它解决的是哪一个具体摩擦、成本或风险？
当前基线、目标指标、受影响流程
用户体验
谁会使用或受到影响？他们为什么愿意改变原有做法？
采用率、完成率、人工接管率、反馈
技术与数据
所需数据是否可得、含义一致、质量可控？
数据清单、接口依赖、质量报告
风险
错误会造成什么后果？是否可以发现、阻断和恢复？
风险分级、权限边界、升级与回退方案
扩展性
成功后能否复用到相邻流程，而不必推倒重来？
可复用组件、评测集、模板与文档
这比“哪个部门最想用 AI”更接近正确的优先级判断。
例如，客服助手的首要指标未必是“生成了多少条回复”，而可能是首次响应时间、转人工比例、问题解决时长和错误升级率；合同审查工具也不应只计算节省了多少小时，还要观察漏检、误报、审查覆盖率以及法务最终采纳情况。报告列举客服、销售、人力、法务和 IT 场景的意义，就在于把 Agent 的动作与业务结果放进同一张表。
先选一个窄用例，还有一个更重要的作用：把那些在会议中看不见的问题提前暴露出来。数据字段可能含义不一致，权限审批可能没有负责人，模型输出可能无法被现有系统接收，用户可能根本不信任结果。试点除了验证“AI 能做什么”，还要用较低成本找出企业为了让它稳定工作所缺的条件。
所以，好的第一个用例应该像一辆探路车。

一个贯穿示例：客服工单分流

假设一家企业先把范围限定为“将已登录客户的售后工单分到正确队列”，不让 AI 直接退款或回复客户。上线前，团队记录当前的错分率、平均转派次数和首次分派耗时，再从脱敏的历史工单中构建评测集。验收规则也一并写清：涉及退款、账户安全或低置信度的工单，必须转交人工。
受控试运行中，业务团队判断分类结果是否可用，工程团队监控延迟与成本，数据团队检查字段质量，安全团队审查访问权限和日志。只有预设阈值达标后，系统才逐步放量。项目结束时，团队留下分类标签、数据契约、评测集、权限模板、监控规则和人工接管流程。下一个“客户邮件分流”用例便可复用其中一部分，而不必从头建设。

三、规模化的核心：让每次交付都留下可复用资产

试点进入生产后，企业很容易掉进第二个陷阱：每个团队重新选模型、接数据、写提示词、做安全评审、搭监控。项目数量增加了，交付速度却没有变快，风险还在重复出现。
报告把数据准备视为关键路径。企业首先要知道有哪些数据、谁能访问、哪些字段缺失、不同系统如何定义“客户”“订单”“区域”等核心实体，以及当多个来源互相矛盾时谁是可信版本。没有这些约定，模型拿到的数据越多，未必越聪明，也可能只是更有把握地输出不一致的答案。
数据之外，还需要一层共享基础设施，但建设顺序很重要。报告并不主张在第一个用例之前就完成一座庞大的“AI 中台”，而是建议先通过有限用例验证可靠性，再逐步沉淀共用能力：
  • 统一的身份、权限与数据访问模式；
  • 模型、工具和业务系统的连接规范；
  • 版本管理、评测、监控、成本与生命周期管理；
  • 可复用的提示词、组件、参考架构和治理模板；
  • 故障时的降级、隔离、回退和人工接管路径。
这也改变了“买、扩展还是自研”的判断。标准化、没有差异化价值的能力可以优先购买；已有平台能够安全扩展的部分，不必从零重建；只有真正构成业务差异、且组织有能力长期运营的部分，才值得承担全栈自研的成本。4
据此，本文建议每个投产用例至少沉淀七类资产：
  1. 业务目标与指标基线；
  1. 数据来源、定义、质量标准与访问规则；
  1. 代表真实任务的评测集和验收阈值；
  1. 模型、提示词、工具与流程的版本记录；
  1. 安全护栏、异常升级和人工接管机制；
  1. 延迟、可靠性、采用率、风险和成本等运行数据；
  1. 复盘结论，以及哪些部分可以被下一个用例复用。
notion image
可复用交付模式：代码只是资产之一。每次交付还要留下指标、数据、评测、治理与复盘，才能让后续用例更快、更稳。
这套做法接近报告所说的 GenAIOps 和 Agentic DevOps：管理对象从代码扩展到模型、数据、提示词、Agent 逻辑、评测和集成关系。5 当这些资产进入版本化的公共知识库，企业得到的就不只是一个应用，而是一条越来越成熟的“AI 交付流水线”。

四、把信任变成可以检查的系统证据

企业谈 AI 采用时，常把“信任”理解成用户愿不愿意尝试。实际上，信任至少有三层：
  • 结果可信： 系统在什么任务上表现可靠，误差和边界是否被测量？
  • 过程可控： 它访问了什么数据、调用了什么工具、采取了什么行动，能否观察和阻断？
  • 责任可追： 谁批准上线，谁监控运行，谁有权修改，发生事故时谁接管？
这三层都不能靠培训或宣传替代。
尤其当 Agent 从“生成建议”走向“代表企业行动”后，治理对象已经不只是模型输出。Agent 可能拥有独立身份、跨系统权限、持续记忆和工具调用能力，也可能遭遇提示注入、敏感数据泄露、越权行动或不可控扩散。报告建议为 Agent 建立身份与最小权限、统一资产清单、上线前安全评测、持续监控、完整审计和从批准到退役的生命周期管理。
这与 NIST AI 风险管理框架的思路一致。NIST 把风险管理组织为 Govern、Map、Measure、Manage 四类活动，并明确要求在 AI 系统的整个生命周期持续开展，而不是上线前做一次检查就结束。其生成式 AI 专项框架进一步提醒组织，要根据具体场景、风险承受能力和法律要求调整措施。
“人在回路”也需要具体化。它不应只是流程图上一个表示谨慎的方框，而要明确：
  • 哪些决定必须由人批准；
  • 人能看见哪些依据和运行记录；
  • 系统不确定到什么程度时必须升级；
  • 审核人是否有时间、能力和激励真正检查；
  • 当调用量扩大十倍时，人工审核是否仍能承受。
如果这些问题没有答案，“人会把关”只是把系统风险转移给一个没有准备好的岗位。

五、技术可以快速复制，组织的工作方式不能一键安装

《The AI Strategy Roadmap》把组织与文化列为五个核心驱动因素之一，这部分并非可有可无的软性补充。微软 2026 Work Trend Index 对 10 个市场的 2 万名在工作中使用 AI 的知识工作者进行了调查。其分析显示，在受访者自报的 AI 影响中，组织环境因素——包括文化、管理者支持和人才机制——相对重要性为 67%，个人心态和行为因素为 32%。研究明确说明这是统计关联，不是因果效应；但它仍提示企业，员工会不会使用 AI，并不只取决于个人是否上过培训。
真正影响采用的，是周围的系统是否允许新工作方式发生：管理者是否亲自示范，绩效指标是否仍然奖励旧流程，员工是否可以安全试验，出现错误时能否得到支持，团队有没有时间把经验写成标准。
这也是 AI 卓越中心（Center of Excellence，CoE）最容易被设计错的地方。一个成熟的 CoE 不应包办所有 AI 项目，也不应成为新的审批瓶颈。它更适合承担四类工作：
  • 统一优先级、原则、标准和责任边界；
  • 提供共享平台、模板、评测与治理能力；
  • 连接业务、技术、数据、安全、法务与合规团队；
  • 收集项目经验，让局部成功转化为组织资产。
微软在内部实践中也经历了这次调整：其 AI CoE 最初主要提供咨询，随后发现重复建设、标准不一和治理不均，于是转向协调优先级、护栏、交付路线与采用方式。与此同时，IT 的角色从逐个把关，转向维护可信数据源、连接器、身份权限、Agent 生命周期和共享运行平台。
培训也需要从“一次全员课程”转向按角色建设能力。业务负责人需要学会定义问题和指标，开发团队需要掌握评测与运行管理，安全和法务需要理解 Agent 的数据流与行动边界，一线员工则需要知道如何判断结果、何时升级以及怎样反馈。AI champion 或内部实践社区可以加快经验传播，但不能替代正式责任人。
当新的工作方式进入指标、权限、流程和日常管理时，文化变化才算真正发生。

六、一条可执行的三阶段路线

本文将五类能力和五级成熟度整理为一条三阶段行动路线。这里不设固定工期，每个阶段对应一个必须闭合的管理问题。
notion image
三阶段行动路线：每个阶段都有证据门槛。没有证明价值、边界与可控性，就不急于扩大范围。

第一阶段：选定一个问题，定义“成功”和“不能失败”

选择一个边界清晰、可测量、风险可控的真实流程。记录现状基线，明确业务指标、系统指标和风险指标；组建包含业务、产品、工程、数据、安全与合规的最小跨职能团队；列出数据来源、系统依赖、权限、人工接管和停止条件。
这一阶段需要同时交付原型和一个可以被检验的业务假设。

第二阶段：把试点当成生产系统的早期版本

从第一天就加入日志、评测、用户反馈、成本和性能监控。先让可信的内部用户在受控环境中使用，收集失败案例，修正数据、流程和护栏。只有当业务价值、可靠性、采用率和风险都达到预设阈值，才扩大范围。
这一阶段最重要的成果是证据：系统在哪些条件下有效，在哪些条件下必须交给人。

第三阶段：复制经过验证的交付模式

把经过验证的数据契约、集成方式、评测集、权限模型、监控规则和复盘结论放入公共资产库。用统一框架管理用例组合，定期继续、加码、调整或停止项目。共性能力进入共享平台，CoE 负责加速复用和维护边界，培训则跟随岗位与流程变化持续更新。
到这一步，企业才真正开始获得复利：第二个用例不再重复第一个用例走过的全部弯路，第三个用例又在前两个用例的资产上继续改进。

结语：不要问“我们上线了多少 AI”，要问“我们学会了什么”

AI 转型最容易被看见的是模型、Agent 和演示，最难被看见的却是决定它们能否长期工作的那套系统：业务优先级、可信数据、交付纪律、组织责任与持续治理。
企业当然需要开始行动，但“尽快开始”不等于“尽快铺开”。更稳健的顺序是：先用一个真实问题建立证据，再把证据变成标准，把标准变成平台和日常工作方式。
下一次评审 AI 项目时，与其只问准确率多高、用了什么模型、什么时候上线，不如再加四个问题：
  1. 它要改变哪一个业务结果？
  1. 我们凭什么相信它在真实流程里有效？
  1. 出错时谁能看见、阻断并负责？
  1. 这次交付会为下一个用例留下什么？
能持续回答这四个问题的组织，才是在建设 AI 能力，而不只是积累 AI 项目。
 
<ins/>

AI Agents 知识星球

GUI Agents 技术发展迅猛，想紧跟 GUI/AI agents 技术前沿？我们的知识星球会介绍 Agents 相关的最新项目和工具，并以视频方式解读最新论文，为你开启技术新视野，快来加入吧！
加入知识星球，每周获取会员专享视频👇
notion image
 
扫码加微信小助手为好友，备注「agent」，小助手会定期邀请入群👇
notion image
当前星球包含的专享视频包括：
 
<ins/>

参考文献

[1]  Microsoft, The AI Strategy Roadmap: Five drivers of successful AI transformation，2026 年 7 月 21 日；The AI Strategy Roadmap: How organizations are achieving Frontier Transformation，2026，尤其见第 2—8 页；路线图介绍页。
[2]  同上，第 3、66 页。研究包含 70 次深度访谈，每次 30—45 分钟；访谈由 Emerald Research Group 代表微软开展，属于定性研究。
[3]  同上，第 9—19 页。报告将首个用例的重点放在明确业务问题、可测量结果、可控风险和逐步扩展。
[4]  同上，第 20—29 页。相关章节讨论数据成熟度、统一语义、共享平台、成本与韧性，以及买入、扩展和自研之间的选择。
[5]  同上，第 30—37 页。相关章节讨论跨职能团队、受控试验、可复用资产、GenAIOps、Agentic DevOps 与多维指标。
[6]  同上，第 47—57 页。相关章节讨论 Agent 身份与权限、数据过度共享、提示注入、持续监控、上线前评测和生命周期治理。
[7]  NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, 2024；以及 NIST AI RMF Playbook。AI RMF 1.0 正在修订，应用时应检查最新版本。
[8]  Microsoft, 2026 Work Trend Index Annual Report, 2026。调查覆盖 10 个市场的 2 万名在工作中使用 AI 的人；67% 与 32% 来自模型中特征重要性的归类，结果基于自报数据，只表示关联。
[9]  Microsoft, The AI Strategy Roadmap，第 58—62 页。“微软自身实践”属于厂商自述案例，本文未将其结果外推为所有企业都能复现的效果。
]]> <![CDATA[AI Agent 中的上下文工程 (Context Engineering)]]> https://www.breezedeus.com/article/ai-agent-context-engineering https://www.breezedeus.com/article/ai-agent-context-engineering Fri, 28 Nov 2025 00:00:00 GMT
 
Home | GitHub | Twitter | Youtube | Bilibili
 
notion image
目录：
背景介绍Context Engineering：跨越认知鸿沟的熵减工程Context Engineering 为什么有必要Prompt Engineering从 Prompt Engineering 到 Context Engineering：从静态到动态的进化上下文工程的核心原则与实践1. 上下文缩减：压缩与摘要的艺术2. 上下文检索：文件系统工具的回归3. 上下文隔离与多智能体设计4. 上下文卸载与分层行动空间5. More: 长期记忆、规划与模型适应性6. 安全与评估结论：简化胜于过度工程AI Agents 知识星球参考文献
 

背景介绍

AI 智能体（AI Agents）的迅速发展带来了管理其处理海量信息的新挑战。其中最关键的一项是上下文工程（Context Engineering），这是一门专注于优化智能体系统中大型语言模型（LLM）信息流的技术。本文综合了 LangChain 的 Lance 和 Manus 联合创始人兼首席科学家 Peak 在一场网络研讨会上的关键见解，旨在全面解析上下文管理的高级技术，特别是 Manus 的创新方法。
Context Engineering：其他系统与大模型之间的沟通桥梁
Context Engineering：其他系统与大模型之间的沟通桥梁
 

Context Engineering：跨越认知鸿沟的熵减工程

Context Engineering 2.0: The Context of Context Engineering 这篇论文把 Context Engineering 这个概念放在更大的背景下看待，很有意思。
人类智能与机器智能的发展轨迹持续存在 "Intelligence Gap"（智能鸿沟）。这条鸿沟的本质，是信息熵的不对称。人类在交流时拥有天然的"熵减能力"——我们能够通过共享的文化背景、情感线索、情境感知来主动补全对话中的缺失信息，将高熵的、模糊的意图转化为低熵的、清晰的理解。而机器，至少在目前，熵减这种能力还不够好。
Context Engineering 正是为了弥补这一熵减能力差距而存在的系统工程。 当我们与AI交互时，如果只是抛出一个简单的问题，AI面对的是一个高熵状态：缺乏背景、没有记忆、不了解你的意图偏好。Context Engineering 的核心工作，就是主动为机器进行熵减预处理——通过构建知识库、维护记忆系统、部署RAG检索、集成外部工具，我们将原本高熵的、碎片化的信息转化为结构化的、低熵的上下文表示，让机器能够"理解"。
notion image
上图展示了 Context Engineering 从1.0到4.0的演进路径，揭示了一个核心规律：随着AI智能水平的提升，其上下文处理能力不断增强，人机交互成本持续降低。
  • Context 1.0 - Context as Translation（上下文作为翻译）| Era 1.0: Primitive Computation (1990s-2020)
      • 在这个阶段，机器仅能处理结构化输入和简单的环境线索，缺乏对意义和意图的深层理解。AI表现为"被动执行者"（Passive Executor），人机交互依赖于刚性的、预定义的格式——菜单选择、简单传感器数据等。虽然超越了二进制命令层面，但所有上下文仍必须由人类显式准备并"翻译"成机器可直接处理的格式。此时人机交互成本最高，人类需要投入大量精力来适应机器有限的理解能力。
  • Context 2.0 - Context as Instruction（上下文作为指令）| Era 2.0: Agent-Centric Intelligence (2020-Present)
      • 2020年GPT-3的发布标志着 context engineering 的转折点。机器展现出中等智能水平，能够理解自然语言输入并推断部分隐含意图，成为"主动代理"（Initiative Agent）。上下文不再局限于显式定义的信号，可以包含模糊性和不完整信息。AI通过先进的语言理解和情境学习（in-context learning）主动推理上下文缺口，提供更自适应的交互。人类可以用对话方式表达需求，系统能解释大部分潜在含义，人机协作变得切实可行。
  • Context 3.0 - Context as Scenario（上下文作为场景）| Era 3.0: Human-Level Intelligence (Future)
      • 随着预期的突破，智能系统将接近人类水平的推理和理解能力，AI进化为"可靠协作者"（Reliable Collaborator）。Context engineering 超越当前模式，使AI能够像人类一样感知上下文并吸收高熵信息。可解释上下文的范围显著扩展，包括社交线索、情绪状态和更丰富的环境动态。通过知识库、记忆系统和RAG检索，AI能够在复杂场景中持续协作，实现真正自然的人机协同，AI将作为知识丰富且高效的伙伴存在。我们目前正处于从Era 2.0向Era 3.0的过渡阶段。
  • Context 4.0 - Context as World（上下文作为世界）| Era 4.0: Superhuman Intelligence (Speculative)
      • 当智能系统超越人类能力，它们将拥有"上帝视角"，比人类自己更深刻地理解人类意图，成为"深思熟虑的大师"（Considerate Master）。传统的主客体关系发生反转：机器不再被动适应人类定义的上下文，而是主动为人类构建新的上下文，发现隐藏需求，引导人类思维。这一转变的迹象已经出现——在围棋领域，职业棋手正在向AI学习超人类的新策略。此时，机器成为洞察和灵感的来源，从根本上重新定义了人机协作的本质。
这一演进过程的本质，是AI逐步接管人类原本需要承担的"上下文熵减工作"。随着 Context Engineering 能力的提升，人类可以用更自然、更高熵的方式表达意图，而将复杂的信息结构化、情境理解和知识整合工作交给AI系统来完成。这正是 Context Engineering 作为系统工程的价值所在：不是让人类学会如何更好地与机器对话，而是让机器学会如何更好地理解人类——最终，在Era 4.0，机器甚至能比人类更好地理解人类自己。
 
从1963年的 Sketchpad 到1999年的 Ubiquitous Computing，再到今天的 Langchain、Claude Code、Cursor 等工具，Context Engineering 一直在努力缩小智能鸿沟。下图中的紫色区域标注了 "Human = Machine" 的交汇点，那将是 Context Engineering 的终极目标：当我们成功将人类的高熵意图系统化地转化为机器可理解的低熵表示时，人机协作的效率将达到前所未有的高度。这不仅是技术的进化，更是一场持续的熵减革命。
notion image
 
在模型微调和后训练日益普及的今天，Context Engineering 是应用和模型之间最清晰、最实用的边界。Manus 认为，初创公司应避免过早陷入模型专门化的陷阱，因为这会将产品的创新速度与模型的迭代速度捆绑在一起。即使是使用强大的基础模型进行微调，也可能因为 AI 领域快速的技术颠覆而变得危险。例如，MCP（Manus Code Playground）的推出彻底改变了 Manus 的设计，从一个紧凑的静态行为空间转变为一个几乎无限扩展的开放域环境，这种变化对于已经专门训练过的模型来说是极难适应的。因此，坚定地依赖通用模型和上下文工程，是保持产品灵活性和未来适应性的关键策略。
<ins/>
 

Context Engineering 为什么有必要

接下来回到 AI Agents 架构中的上下文工程理解视角。为什么从 2025 年3月份开始，上下文工程越来越受到大家的重视？
AI 智能体通过自主与工具交互并积累观察结果，交互轮次变长后会导致“上下文腐烂（Context Rot）”现象。每次工具调用都会生成一个观察结果并附加到聊天历史中，导致消息数量不受限制地爆炸式增长。这种不断增长的上下文长度会降低 LLM 的性能，形成一个悖论：智能体需要大量的上下文，但更长的上下文会损害其效率和准确性。
AI 智能体能做的事情越来越复杂，交互轮次越来越多。
AI 智能体能做的事情越来越复杂，交互轮次越来越多。
 

Prompt Engineering

Prompt Engineering 是我们与AI交互的起点——通过精心设计静态的提示词结构（角色、任务、格式、约束、示例、输入），让AI理解我们的需求并给出准确答案。这种方法简单直接，但每次对话都是独立的"单次任务"，AI没有记忆，也无法访问外部知识。
常见的 Prompt 结构：
  1. 角色定义 - 设定身份
  1. 任务描述（整合了背景信息）- 说明要做什么
  1. 输出格式 - 规定输出形式
  1. 约束条件 - 硬性限制
  1. 示例 - 参考模板
  1. 输入数据 - 实际内容
notion image
 
一个示例：
notion image
 

从 Prompt Engineering 到 Context Engineering：从静态到动态的进化

Context Engineering 可以理解为 Dynamic Prompting 的系统化升级。它的核心思想是：不再手动编写固定的提示词，而是根据对话情境、历史记忆、知识库内容，动态组装最适合当前任务的上下文。当用户提出问题时，系统会自动从知识库检索相关信息（RAG）、调取历史对话记忆、整合外部工具的数据，然后将这些动态获取的上下文与用户的问题结合，形成一个"信息丰富、情境完整"的增强提示词。
这不仅仅是提示词的动态化，更是整个交互架构的升级：
  • 知识库提供领域专业知识和事实依据
  • 记忆系统维护对话历史和用户偏好
  • RAG检索按需获取最相关的上下文片段
  • 工具集成连接数据库、API等外部资源
  • 系统级设计确保一致性和可扩展性
简单说，Prompt Engineering 是"手工制作每一个提示词"，而 Context Engineering 是"搭建一个能自动生成最优提示词的智能系统"。这就是从手动到自动化、从静态到动态、从单次任务到系统工程的进化。
notion image
 

上下文工程的核心原则与实践

上下文腐烂（Context Rot）是指在长上下文场景中，当上下文窗口超过某个"腐烂阈值"（Pre-rot threshold）后，AI模型对远端信息的理解和利用能力急剧下降的现象。如图所示，在0-128K token范围内（绿色区域），模型能够有效处理上下文信息；当进入128K-200K范围（橙色区域）时，性能开始衰减，这就是"腐烂阈值"；而超过200K之后的大部分上下文（白色区域）则几乎被模型"忽略"，无法有效利用。
notion image
这一现象揭示了上下文过程面临的核心挑战：即使模型声称支持百万级token的上下文窗口，实际可用的有效上下文往往远小于这个数字。因此，上下文过程不仅要构建丰富的知识环境，还必须通过智能检索（RAG）、上下文压缩、记忆管理等技术，确保关键信息始终处于模型的"有效感知区域"内，避免重要上下文在长对话中"腐烂"而失效。
 
面对上下文腐烂的挑战，Context Engineering 形成了几大核心原则：上下文优化 —— 通过缩减与检索技术，提取最相关信息而非盲目堆砌；上下文隔离 —— 借助多智能体设计，为不同任务建立独立上下文空间，避免信息混杂；上下文分层 —— 通过卸载与分层行动空间，将系统知识、历史记忆、当前任务按生命周期分层管理。这些原则通过四大核心技术得以落地实践。
notion image
 

1. 上下文缩减：压缩与摘要的艺术

上下文缩减（Context Reduction） 旨在压缩或总结信息。Manus 将其细分为两种形式：
  • 压缩（Compaction）：一个可逆的过程，将可以从外部状态（如文件系统）重建的信息（例如，用文件路径代替完整文件内容）从上下文中剥离。这样，没有任何信息真正丢失，只是被外部化了。这种可逆性至关重要，因为智能体可能在后续步骤中需要依赖早期的精确行为。Manus 的工具调用和工具结果都存在完整和紧凑两种格式，紧凑版本会剥离可从文件系统或外部状态重建的信息，例如，一个文件写入操作在执行后，其内容字段可以被安全移除，只保留文件路径。当智能体需要时，可以通过路径再次检索。
      • notion image
  • 摘要（Summarization）：一个不可逆的过程，用于浓缩信息。Manus 对此非常谨慎，通常在摘要前会将关键上下文部分卸载到文件中，并始终保留最后几次工具调用的完整细节以保持连贯性。
      • notion image
      为了使摘要过程更可靠，Manus 避免使用自由形式的提示，而是采用结构化模式 (Schema)。通过定义一个包含特定字段（如“修改的文件”、“用户目标”、“上次停止的位置”）的表单让 AI 填写，可以确保输出的稳定性和一致性。这种方法强制 AI 概括特定信息，而非随意生成，从而提高摘要的质量和可控性。
Manus 通过跟踪上下文长度阈值来管理这两种方法。当上下文接近“腐烂前”阈值（通常为 128k-200k Token）时，首先触发压缩。只有当压缩的收益变得微乎其微时，才会转向摘要。在压缩时，Manus 可能会选择压缩最旧的 50% 工具调用，同时保留较新的调用记录的完整细节，以确保模型仍有新鲜的少样本示例来学习如何正确使用工具。在进行摘要时，Manus 总是使用完整版本的数据，并保留最后几次工具调用和结果的完整细节，以帮助模型平滑地继续工作，避免风格和语气上的突然变化。
notion image
<ins/>

2. 上下文检索：文件系统工具的回归

上下文检索（Context Retrieval） 侧重于高效地获取相关信息。与依赖索引和语义搜索的系统不同，Manus 在其瞬时沙盒会话中优先使用更简单的基于文件的搜索工具，如 glob 和 grep。Peak 解释说，由于会话的瞬时性，动态构建索引是不切实际的，因为每次会话都是一个全新的环境，没有时间去动态构建索引。因此，依赖于对基于行的文本格式（如纯文本而非 Markdown）进行操作的成熟命令行工具，是更高效的选择。Manus 倾向于使用纯文本，因为 Markdown 有时会导致模型输出过多的项目符号，且基于行的格式更利于 grep 和按行范围读取。
notion image
然而，对于需要长期记忆或访问大型企业知识库的场景，外部向量索引仍然是必要的。
对于简单的搜索，Manus 会直接将完整的搜索结果附加到上下文中，并依赖压缩机制来管理。但对于需要整合多个查询结果的复杂搜索，Manus 会启动一个子智能体（即“智能体即工具”），由该子智能体负责处理、整合信息，并以主智能体预定义的固定输出模式返回结果。
notion image
 

3. 上下文隔离与多智能体设计

上下文隔离（Context Isolation） 通过多智能体架构实现。Manus 借鉴了 Go 语言的并发哲学，提出了两种不同的隔离模式：
  • 通信模式（Communication Mode）：适用于简单的、指令清晰的任务。主智能体向子智能体发送指令，子智能体的上下文仅限于该指令。这种模式适用于主智能体只关心最终输出，不关心中间过程的任务。
      • notion image
  • 共享上下文模式（Shared Context Mode）：适用于复杂的、依赖历史的任务。子智能体可以访问完整的先前上下文，包括所有的工具使用历史。这种模式在需要完整历史记录的场景下避免了信息检索的延迟和成本，但代价是每次子智能体调用都需要预填充更大的输入，且由于系统提示和行为空间不同，无法重用 KV 缓存。
      • notion image
Manus 的多智能体系统设计避免了基于角色（如设计师、程序员）的划分，认为这种拟人化类比效率低下。相反，系统由少数几个专业智能体组成：一个庞大的通用执行器、一个规划器和一个知识管理器。知识管理器智能体的作用是回顾用户和智能体之间的对话，并判断哪些内容应该被存入长期记忆。大多数子任务通过“智能体即工具”的范式实现，即一个子智能体被封装成一个工具供主智能体调用。在这种模式下，主智能体通过定义输出模式来确保从子智能体获得结构化、可靠的结果，而子智能体则使用一个特殊的“提交结果”工具，通过约束解码来强制执行该模式。这种设计在 Manus 的“Wide Research”（内部称作“智能体版 MapReduce”）功能中得到了应用，通过共享同一个沙盒，文件系统在主子智能体之间共享，信息传递仅需传递不同的文件路径。这种“智能体即工具”的设计使得主智能体向子智能体传递信息变得容易，更重要的是，通过定义输出模式和子智能体的“提交结果”工具，确保了从子智能体获得的输出是结构化且可靠。这种模式解决了多智能体通信中的信息同步难题，尤其适用于复杂任务，它利用共享沙盒和文件系统，通过传递文件路径实现主子智能体间的信息共享。
<ins/>

4. 上下文卸载与分层行动空间

上下文卸载（Context Offloading） 的核心思想是：并非所有信息都需要保留在智能体的消息历史中，而是可以将其存储到上下文窗口之外，在需要时再检索回来。另外，随着系统变得越来越复杂，特别是如果集成了 MCP，工具本身会占用大量上下文。上下文中工具过多会导致混乱，出现“上下文混淆”(Context Confusion)，模型可能会调用错误的工具，甚至是不存在的工具。
卸载最流行的实践是利用文件系统——将工具输出、搜索结果等消耗大量 Token 的完整内容转储到文件中，只向智能体返回必要的摘要信息，这样既保持了信息的可访问性，又避免了上下文窗口的持续占用。
Manus 正在试验新颖的分层行动空间（Layered Action Space）方法处理工具过多的情况。在分层行动空间设计中，上下文卸载不仅体现在工作内容的外部存储，更延伸到对工具本身的分层管理：通过将大量命令行工具和 API 能力卸载到第2层和第3层，保持核心函数调用层（第1层）的简洁和稳定，从而避免因工具过多导致的"上下文混淆"问题。
notion image
分层行动空间（Layered Action Space）具体思路：
  • 第 1 层：原子函数调用（Atomic Function Calls）：Manus 仅使用一小组（10-20个）固定的原子函数，如读写文件、执行 shell 命令、在互联网和文件中搜索，以及一些浏览器操作。这些函数因约束解码而模式安全，且数量有限，避免了缓存失效和混淆。Manus 刻意避免使用与现有模型训练中工具名称相同的命名，以防止模型混淆不同工具的参数和预期行为。如果自定义函数与现有模型训练中学习到的工具具有相同的名称，可能会导致模型混淆参数和预期行为，从而影响其性能。
  • 第 2 层：沙盒实用工具（Sandbox Utilities）：在完整的 VM 沙盒中，Manus 可以执行预装的命令行工具。LLM 通过系统提示得知这些工具的存在，并被鼓励使用 -help 标志来查询用法。例如，Manus 会被告知在 /usr/bin 目录下有许多命令行工具。对于最常用的工具，其名称会以紧凑格式注入到系统提示中。这极大地扩展了智能体的能力，而无需修改其核心函数调用空间。这些工具的好处在于，它们可以直接处理大输出（例如写入文件或分页返回结果），并可利用 Linux 工具（如 grep、cat、less）进行即时处理。
  • 第 3 层：软件包和 API（Packages and APIs）：此层允许编写并执行 Python 脚本来调用预授权的 API 或自定义软件包。这对于内存密集型计算（如分析大量股票数据）是理想的，因为计算过程在 Python 运行时内存中完成，只有最终的摘要结果返回给模型。Manus 预装了大量的 API 密钥，用户无需单独购买和配置。这种方式虽然不具备模式安全性，但代码的高度可组合性允许在单一步骤中链接多个操作，例如在一个 Python 脚本中完成获取城市名称、城市 ID 和天气等多个任务。
 
notion image
 
从模型的角度来看，所有三个层的操作最终都通过少数几个核心的原子函数（如 shell 和 file）来执行，从而为 LLM 维护了一个简单、缓存友好且正交的接口。这种混合模式，即结合了直接的工具调用和沙盒中的代码执行，平衡了约束解码的安全性与代码执行的灵活性。Peak 认为，只要是可以在编译器或解释器运行时内部处理的事情，都应该用代码来做；否则，就使用沙盒工具或函数调用。
<ins/>

5. More: 长期记忆、规划与模型适应性

  • 长期记忆：Manus 采用一种显式的“知识”概念，需要用户确认才能将信息（如偏好设置）存入长期记忆。例如，用户可以告诉 Manus 每次都以 Excel 格式交付结果，系统会弹窗询问是否接受此项作为长期知识。这种“知识”系统类似于一种显式记忆，用户可以主动选择接受或拒绝 Manus 从对话中学习到的偏好。同时，系统也在探索利用集体用户反馈进行无参数的在线学习，以实现自我改进，例如通过识别用户对字体问题的共同修正来提升数据可视化能力。这种无参数的学习方式，旨在利用用户对智能体行为的纠正（如数据可视化中的字体问题），实现智能体的自我改进，而非依赖传统的参数化训练。
  • 规划：Manus 已经从最初使用 todo.md 文件（被证明 Token 效率低下，浪费了大量交互轮次和 Token）演变为使用一个独立的、结构化的规划器智能体。还有一个独立的智能体作为“外部审查员”，能够从不同视角审视计划，甚至可以利用不同模型（如 Claude Haiku）的独特见解，从而显著节省 Token 并提高规划质量。它通过“智能体即工具”的范式实现，作为一个独立的工具供主智能体调用，不再像早期那样通过频繁更新 todo.md 文件来浪费 Token。
  • 适应模型演进：为了应对 LLM 的快速迭代，Manus 采取了一种独特的评估策略：固定其智能体架构，然后在不同的模型（从弱到强）之间进行切换。如果一个架构从较弱的模型切换到较强的模型后能获得巨大提升，那么在某种程度上，该架构就更具未来适应性。Manus 通常每隔一两个月就会进行一次这样的架构审视，并经常在内部使用开源模型或提前试用专有模型，以便为下一个版本的模型发布做好准备。
  • 模型选择与成本：Manus 目前没有使用开源模型，主要是因为在 Manus 的规模下，分布式 KV 缓存的实现难度和成本。与前沿 LLM 提供商合作，利用其强大的基础设施，有时反而比自建开源方案更经济。Manus 不仅使用 Anthropic 模型（认为其最适合智能体任务），也关注 Gemini 和 OpenAI 的进展，并进行任务级别的路由，根据子任务的特性选择最合适的模型（例如，Claude 擅长编码，Gemini 擅长多模态，OpenAI 擅长复杂数学和推理）。Manus 会利用模型提供商的输入缓存（Input Caching）功能，以优化 KV 缓存管理。
 

6. 安全与评估

  • 安全与防护：Manus 在沙盒环境中投入大量精力进行防护，例如阻止信息泄露（如 Token）到沙盒之外，并对出站流量进行检查。Peak 强调，如果用户被提示注入，系统会对出站流量进行检查，确保敏感信息如 Token 不会离开沙盒。对于浏览器内的敏感操作（如登录持久化）或沙盒内的敏感操作，Manus 会要求用户手动确认或接管，因为网页内容本身可能存在提示注入的风险。Manus 与模型提供商紧密合作，共同增强防护措施。Peak 承认，设计一个完美无缺的解决方案非常困难，这是一个循序渐进的过程，目前 Manus 倾向于让用户在敏感操作时接管，并期待模型本身的防护能力增强。
  • 评估策略：Manus 采用多维度的评估方法。首先是用户评分（1-5星），这是衡量实际用户体验的黄金标准。其次是自动化测试，包括内部创建的、带有可验证结果的数据集，以及侧重于执行性或交易性任务的定制基准。最后，也是最重要的是真人评估，通过实习生评估网站生成、数据可视化等涉及品味和美观的任务，因为这些难以通过奖励模型进行自动化评估。
  • 强化学习与工具调用智能体：Peak 认为，对于支持 MCP 这种非固定行为空间的智能体，难以设计有效的奖励函数进行强化学习。他指出，如果行为空间不固定，就很难设计好的奖励函数，生成的部署和反馈也会不平衡，这实际上是在重复构建基础模型提供商已经完成的工作。因此，Manus 倾向于无参数的在线学习方式，例如利用集体用户反馈进行自我改进，而不是投入大量资源进行强化学习，因为模型公司已经在基础模型层面做了类似的工作。

结论：简化胜于过度工程

尽管上下文工程的技术多种多样，但 Manus 最大的进步往往来自于简化——移除不必要的复杂性，并给予底层 LLM 更多的信任。上下文工程的真正艺术在于，在多个可能相互冲突的目标（如性能、成本、延迟、可逆性）之间找到微妙的平衡，并始终追求更简单、更稳定、更智能的智能体架构。他总结道：“少做加法，多做理解 (build less and understand more)。”
<ins/>
 

AI Agents 知识星球

GUI Agents 技术发展迅猛，想紧跟 GUI/AI agents 技术前沿？我们的知识星球会介绍 Agents 相关的最新项目和工具，并以视频方式解读最新论文，为你开启技术新视野，快来加入吧！
加入知识星球，每周获取会员专享视频👇
notion image
 
扫码加微信小助手为好友，备注「agent」，小助手会定期邀请入群👇
notion image
当前星球包含的专享视频包括：
 
<ins/>
 

参考文献

  1. Context Engineering for AI Agents with LangChain and Manus - YouTube
  1. Context Engineering for Agents
  1. [2510.26493] Context Engineering 2.0: The Context of Context Engineering
 
]]> <![CDATA[GUI Agents（智能体）最新论文]]> https://www.breezedeus.com/article/awesome-ui-agents https://www.breezedeus.com/article/awesome-ui-agents Sat, 09 Nov 2024 00:00:00 GMT
 
Home | GitHub | Twitter | Youtube | Bilibili
 
notion image
目录：
UI Agents 知识星球UI Agents 综述资料【Update 2025.03.22】UI Agents 论文列表【Update 2025.03.22】Policy ModelsTraining-based ModelsTraining-free ModelsEnhanced KnowledgesData SynthesisDatasets / BenchmarksTools / EnvironmentsOthersUI Agents 其他汇总信息
 

UI Agents 知识星球

UI Agents 技术发展迅猛，想紧跟 UI agents 技术前沿？我们的知识星球每周以视频方式解读最新论文，为你开启技术新视野，快来加入吧！
加入知识星球，每周获取会员专享视频👇
notion image
 
扫码加微信小助手为好友，备注「agent」，小助手会定期邀请入群👇
notion image
当前星球包含的专享视频包括：
 
<ins/>

UI Agents 综述资料【Update 2025.03.22】

 

UI Agents 论文列表【Update 2025.03.22】

⛔
知识星球每周会从此列表中选出一到两篇论文通过视频方式讲解。大家对哪些论文感兴趣欢迎加入星球并留言说明。
 

Policy Models

Training-based Models

 
Reinforcement Learning
 

Training-free Models

Multi-Agents Framework
 
Single-Agent Framework
 

Enhanced Knowledges

 

Data Synthesis

 

Datasets / Benchmarks

 

Tools / Environments

 

Others

 
 
<ins/>

UI Agents 其他汇总信息

 
<ins/>
 
]]> <![CDATA[AI Agent 性能优化：核心策略与实战技巧]]> https://www.breezedeus.com/article/ai-agent-perf-tips https://www.breezedeus.com/article/ai-agent-perf-tips Mon, 13 Oct 2025 00:00:00 GMT
notion image
 
目录：
1. Prompt 工程：塑造智能体的“思维模式”1.1 系统 Prompt 优化1.2 LLM 搜索优于 RAG 搜索1.3 可控性与行为引导2 上下文工程：精细化管理智能体的“记忆”2.1 KV-cache 命中率优化2.2 上下文长度管理与外部化记忆2.3 注意力机制操纵2.4 上下文检索与 Agentic 搜索2.5 长周期任务的上下文工程3. 工具设计与管理：为智能体打造高效“武器库”3.1 工具设计原则3.2 动态工具选择与约束3.3 工具分层3.4 Agent Skills：构建可组合、可扩展的专业能力4. 控制循环与架构：构建稳定高效的智能体骨架4.1 保持一个主循环4.2 使用小型模型5. 评估与适应：持续改进智能体性能5.1 原型构建与综合评估5.2 错误恢复与适应5.3 多样性与泛化结论参考文献
 
随着人工智能技术的飞速发展，AI Agent 在处理复杂任务方面的能力日益增强。然而，要充分发挥其潜力，优化是不可或缺的一环。本文将综合分析多篇前沿文章，提炼出 AI Agent 中行之有效的优化手段，涵盖Prompt 工程、上下文工程、工具设计、控制循环与架构以及评估与适应等方面，旨在为构建更高效、更稳定的智能体提供指导。

1. Prompt 工程：塑造智能体的“思维模式”

Prompt 工程是引导 LLM 行为的关键技术，尤其是在构建复杂 Agent 时。

1.1 系统 Prompt 优化

  • 清晰简洁的语言：系统 Prompt 应该非常清晰，使用简单、直接的语言，以“恰当的高度”呈现思想，既要足够具体以有效指导行为，又要足够灵活以提供强大的启发式方法 [4]。
      • 在光谱的一端，我们看到脆弱的 if-else 硬编码提示，在另一端，我们看到过于笼统或错误地假设共享上下文的提示。
      在光谱的一端，我们看到脆弱的 if-else 硬编码提示，在另一端，我们看到过于笼统或错误地假设共享上下文的提示。
  • 结构化 Prompt：建议将 Prompt 组织成不同的部分（如 <background_information>、<instructions>、## Tool guidance、## Output description 等），并使用 XML 标签或 Markdown 标题来划分这些部分 [4]。
    • 尽量用最少的话术列出对模型的所有预期：最佳做法是先用可用的最佳模型测试初版包含所有预期的最少话术的 prompt，以查看其在任务上的表现，然后根据初始测试中发现的失效模式添加清晰的指令和示例来改进性能。
  • 详细的启发式规则和示例：Prompt 中应包含详细的启发式规则、示例和重要提醒，例如使用 <good-example> 和 <bad-example> 来明确区分可取和不可取的行为路径 [3]。
    • 团队通常会往提示中塞满各种边缘情况，试图阐明 LLM 在特定任务中应遵循的每一种可能规则。不推荐这样做。相反，建议提供一组多样化、规范化的示例，这些示例能够有效地展现代理的预期行为。对于 LLM 来说，示例就是胜“千言万语”的“图片”（the “pictures” worth a thousand words）。
  • 用户上下文和偏好管理：可以使用 claude.md 或类似文件来传递无法从代码库推断的上下文和严格偏好，例如强制 LLM 跳过某些文件夹或使用特定库 [3]。

1.2 LLM 搜索优于 RAG 搜索

在某些场景下，直接利用 LLM 的代码理解能力进行搜索可能优于传统的 RAG（Retrieval-Augmented Generation）方法 [3]：
  • 利用 LLM 理解代码：Claude Code 通过复杂的 ripgrep、jq 和 find 命令搜索代码库，利用 LLM 对代码的深刻理解，使用复杂的正则表达式查找相关代码块，甚至使用小型模型读取整个文件。这种方法避免了 RAG 引入的新的（隐藏的）故障模式 [3]。

1.3 可控性与行为引导

有效引导 AI Agent 的行为，使其符合预期，是 Prompt 工程的重要组成部分 [3]：
  • 明确的语气和风格控制：在系统 Prompt 中明确定义 Agent 的语气、风格和主动性，并提供具体的指令和示例。这有助于 Agent 在交互中展现出一致且合宜的行为 [3]。
    • 示例：避免不必要的前言或后语，除非用户明确要求；如果无法提供帮助，不要解释原因或可能导致的后果，以免显得说教；除非用户明确要求，否则避免使用表情符号 [3]。
  • 强调式指令：使用“IMPORTANT”、“VERY IMPORTANT”、“NEVER”和“ALWAYS”等强调词来引导模型避免特定行为或强制执行关键规则。这在模型尚未完全可控时尤为重要 [3]。
    • 示例：IMPORTANT: DO NOT ADD ***ANY*** COMMENTS unless asked；VERY IMPORTANT: You MUST avoid using search commands like find and grep. Instead use Grep, Glob, or Task to search. [3]。
  • 编写清晰的决策算法：识别 LLM 需要执行的最重要任务，并为其编写清晰的算法。通过角色扮演 LLM 并遍历示例，明确所有决策点，并以流程图的形式进行结构化。这有助于 LLM 遵循指令，避免“一锅粥”式的 Do's and Don'ts 列表，从而减少冲突和提高可维护性 [3]。
    • Claude Code 的系统 Prompt 中，“Task Management”、“Doing Tasks”和“Tool Usage Policy”等部分清晰地阐述了要遵循的算法，并包含大量启发式规则和各种场景示例 [3]。
<ins/>

2 上下文工程：精细化管理智能体的“记忆”

上下文是 AI Agent 进行决策和行动的基础，对其进行高效管理是优化的核心。上下文工程超越了传统的 Prompt 工程，它关注在 LLM 推理过程中如何策划和维护最佳的 token 集合，以持续实现预期结果 [4]。

2.1 KV-cache 命中率优化

KV-cache（Key-Value Cache）的有效利用对提高 LLM 的运行效率至关重要。优化策略包括：
  • 保持 Prompt 前缀稳定：LLM 的自回归特性意味着即使是单个 token 的差异也会使缓存失效。避免在系统 Prompt 开头包含精确到秒的时间戳等易变信息 [1]。
  • 上下文追加模式：避免修改历史动作或观察结果，确保序列化过程的确定性，以维持缓存的有效性 [1]。
  • 明确标记缓存断点：对于不支持自动增量前缀缓存的模型或推理框架，需要手动插入缓存断点，并确保断点包含系统 Prompt 的末尾 [1]。
notion image

2.2 上下文长度管理与外部化记忆

现代 LLM 拥有巨大的上下文窗口，但过长的上下文仍可能导致性能下降和成本增加。上下文腐烂（Context Rot）现象表明，随着上下文长度的增加，模型回忆信息的能力会降低 [4]。因此，有效的上下文管理至关重要：
  • 文件系统作为外部化记忆：将文件系统视为无限大小、持久化的外部记忆，允许模型按需读写文件，将其作为结构化的外部化记忆使用 [1]。
  • 可恢复的压缩策略：在缩短上下文长度时，采用可恢复的压缩策略，例如仅保留网页 URL 而非完整内容，或保留文档路径而非完整文档内容，从而在不永久丢失信息的情况下减少上下文 [1]。
notion image

2.3 注意力机制操纵

Manus 通过持续重写待办事项列表，把目标复述到上下文末尾。这样能让全局计划处于模型当前关注范围内，避免出现 “中途迷失” 的问题，减少目标不一致的状况。实际上，这是借助自然语言将自身关注点引向任务目标，而无需对架构进行特殊改动。
  • 动态重写待办事项列表：通过不断更新和重写待办事项列表（todo list），将全局计划推入模型的近期注意力范围，减少目标偏差 [1, 3]。
notion image

2.4 上下文检索与 Agentic 搜索

Agentic 搜索强调 Agent 自主地检索和加载上下文，而非预先处理所有相关数据 [4]：
  • “即时”上下文（“just in time”）策略：Agent 维护轻量级标识符（如文件路径、存储的查询、网页链接等），并使用工具在运行时动态加载数据到上下文中。例如，Claude Code 使用此方法对大型数据库进行复杂数据分析，模型可以编写有针对性的查询、存储结果，并利用 Bash 命令（如 head 和 tail）分析大量数据，而无需将完整数据对象加载到上下文中 [4]。
  • 元数据利用：引用（如文件路径）的元数据提供了有效细化行为的机制。文件系统中的文件夹层级、命名约定和时间戳等都提供了重要的信号，帮助 Agent 理解何时以及如何利用信息 [4]。
  • 渐进式信息披露：允许 Agent 通过探索逐步发现相关上下文。每次交互都会产生上下文，为下一个决策提供信息。Agent 可以逐层构建理解，只在工作记忆中保留必要的信息，并利用笔记策略进行额外持久化 [4]。
  • 混合策略：在某些情况下，最有效的 Agent 可能会采用混合策略，预先检索部分数据以提高速度，并根据需要自主探索。例如，Claude Code 预先将 CLAUDE.md 文件直接放入上下文中，同时允许通过 glob 和 grep 等原语即时导航环境和检索文件 [4]。
<ins/>

2.5 长周期任务的上下文工程

对于如大型代码库迁移或综合研究项目等需要跨越数十分钟甚至数小时连续工作的长周期任务 (long-horizon tasks)，Agent 必须在超出模型上下文窗口限制的情况下保持连贯性。仅仅等待更大的上下文窗口可能并非长久之计，因为所有尺寸的上下文窗口都可能受到信息污染和相关性问题的困扰。因此，直接解决这些限制的专门技术至关重要 [4]。
与撰写prompt这一离散任务不同，上下文工程是迭代性的，每当决定向模型传递什么内容时，都会进行筛选阶段。
与撰写prompt这一离散任务不同，上下文工程是迭代性的，每当决定向模型传递什么内容时，都会进行筛选阶段。
 
2.5.1 上下文压缩 (Compaction)
上下文压缩是在对话接近上下文窗口限制时，通过对内容进行总结，并用该总结重新启动一个新上下文窗口的做法。这是提高长期连贯性的首要手段。其核心在于以高保真度提炼上下文内容，使 Agent 能够以最小的性能衰减继续执行任务 [4]。
  • 实现方式：在 Claude Code 中，这一过程通过将消息历史传递给模型以总结和压缩最关键的细节来实现。模型会保留架构决策、未解决的错误和实现细节，同时丢弃冗余的工具输出或消息。随后，Agent 可以带着这个压缩后的上下文以及最近访问的五个文件继续工作，从而在不受上下文窗口限制的情况下保持工作的连续性 [4]。
  • 优化的艺术：压缩的难点在于精确选择保留与丢弃的内容。过于激进的压缩可能导致丢失那些重要性在后期才显现的微妙但关键的上下文。因此，在实现压缩系统时，建议在复杂的 Agent 轨迹上仔细调整 Prompt。应从最大化召回率开始，确保压缩 Prompt 捕获到轨迹中的每一条相关信息，然后通过消除多余内容来迭代提高其精确度 [4]。
  • 轻量级压缩：一种最安全、最轻量级的压缩形式是工具结果清理。一旦某个工具在消息历史的深处被调用过，Agent 通常不再需要看到其原始结果。清除这些结果可以有效减少上下文占用 [4]。
 
2.5.2 结构化笔记 (Structured Note-taking)
结构化笔记，或称智能体记忆 (agentic memory)，是一种让 Agent 定期将笔记持久化到上下文窗口之外的内存中的技术。这些笔记可以在后续的某个时间点被重新拉取到上下文中。这种策略以最小的开销提供了持久化记忆 [4]。
  • 简单模式：像 Claude Code 创建待办事项列表，或让自定义 Agent 维护一个 NOTES.md 文件一样，这种简单的模式允许 Agent 跟踪复杂任务的进展，保持那些在数十次工具调用中可能丢失的关键上下文和依赖关系 [4]。
 
2.5.3 子智能体架构 (Sub-agent Architectures)
子智能体架构为克服上下文限制提供了另一种途径。它不是让单个 Agent 试图维护整个项目的状态，而是让专门的子智能体在干净的上下文窗口中处理重点任务。主智能体负责协调一个高层计划，而子智能体则执行深入的技术工作或使用工具查找相关信息。每个子智能体可能会进行广泛的探索，使用数万甚至更多的 token，但最终只返回一个浓缩、精炼的工作摘要（通常为1000-2000个 token）[4]。
  • 关注点分离：这种方法实现了清晰的关注点分离——详细的搜索上下文被隔离在子智能体内部，而主导的 Agent 则专注于综合和分析结果。这种模式在处理复杂研究任务时，相比单 Agent 系统显示出显著的性能提升 [4]。
这三种方法各有侧重：上下文压缩适合需要大量来回对话的任务；结构化笔记在具有明确里程碑的迭代开发中表现出色；而子智能体架构则在并行探索能带来巨大收益的复杂研究和分析中大放异彩 [4]。
<ins/>

3. 工具设计与管理：为智能体打造高效“武器库”

工具是 AI Agent 与环境交互的关键接口。工具的设计质量直接影响 Agent 的效能 [2]。

3.1 工具设计原则

  • 选择合适的工具：审慎决定哪些工具需要实现，哪些可以省略 [2]。
    • 建议针对特定的高价值工作流程，精心打造一些适用的工具，使其与评估任务相匹配，再以此为基础逐步拓展。就通讯录场景而言，可以考虑实现 search_contacts 或 message_contact 工具，而非 list_contacts 工具。
    • 工具可以整合各类功能，在内部处理多个可能离散的操作（或 API 调用）。例如，工具可以利用相关元数据丰富回复内容，或者通过一次工具调用完成频繁串联的多步骤任务。
    • 一些示例：
      • 相较于分别实现 list_users、list_events 和 create_event 工具，不妨考虑实现一个 schedule_event 工具，它既能查找可用时间，又能安排活动。
      • 与其实现 read_logs 工具，不如实现 search_logs 工具，该工具仅返回相关日志行及部分周边上下文。
      • 不要分别实现 get_customer_by_id、list_transactions 和 list_notes 工具，而是实现一个 get_customer_context 工具，它能一次性整合客户所有近期相关信息。
    • 要确保每个构建的工具都有明确且独特的用途。工具应让智能体像人类在拥有相同底层资源时那样，对任务进行细分并解决，同时减少因中间输出而消耗的上下文。
    • 工具太多或其功能重叠，可能会干扰智能体采用高效策略。因此，认真且有针对性地规划要构建（或不构建）的工具，会带来显著成效。
  • 工具命名空间：为工具定义清晰的功能边界，避免混淆 [2]。
    • 通过设置命名空间（把相关工具归到相同前缀下），有助于在众多工具间明确界限，MCP 客户端有时会默认这么做。比如，按照服务（像 asana_search、jira_search）和资源（例如 asana_projects_search、asana_users_search）对工具进行命名空间划分，能帮助智能体在合适的时机选择合适的工具。
    • 选择基于前缀或后缀的命名空间方式，会对工具使用评估产生不可忽视的影响。而且不同的 LLM 受影响的情况各异，所以建议根据自身评估结果来选择命名方案。
    • 智能体可能会出现调用工具错误、用错参数调用正确工具、调用工具数量不足，或者错误处理工具回复等问题。实现工具时有针对性地设置它们的名称体现任务的自然区分，这样既能减少加载到智能体上下文中的工具数量和描述信息，还能把智能体计算的工作从上下文转移到工具调用本身，从而降低智能体犯错的整体风险。
  • 返回有意义的上下文：工具的输出应向 Agent 提供简洁且有意义的上下文信息 [2]。
    • 在实现工具时，要注意只向智能体返回关键信息。应更注重上下文的相关性，而非追求灵活性，同时避免使用底层技术标识符（比如 uuid、256px_image_url、mime_type 等）。像 name、image_url 和 file_type 这类字段，更有助于直接引导智能体开展后续行动并做出回复。
    • 相较于晦涩的标识符，智能体处理自然语言命名、术语或标识符时，往往更加得心应手。仅需将随意的字母数字 UUID 转换为语义更清晰、更易解读的表述（甚至只是采用从 0 开始编号的 ID 方案），就能减少幻觉现象，显著提升 Claude 在检索任务中的精准度。
    • 在某些情形下，若只是为了触发后续工具调用（例如 search_user (name=’jane’) → send_message (id=12345) ），智能体可能既需要与自然语言输出交互，也需要与技术标识符输出交互的灵活性。可以在工具中设置一个简单的 response_format 枚举参数，让智能体能够选择工具返回 “concise” 还是 “detailed” 的回复（如下所示）。
      • 甚至工具的回复结构，如 XML、JSON 或 Markdown 等，都会对评估性能产生影响，不存在一种适用于所有情况的解决方案。最佳回复结构会因任务和智能体的不同而差异巨大。建议根据自身评估情况，选择最合适的回复结构。
    • 优化工具回复的 token 效率：减少工具回复的 token 数量，以降低成本并提高处理速度 [2]。
    • Prompt Engineering 工具描述和规范：精心设计工具的描述和规范，使其更易于 Agent 理解和使用 [2]。
      • 编写工具描述和规格时，不妨设想一下如何给团队新成员介绍该工具。思考那些可能默认提及的上下文信息，比如专业的查询格式、特定术语的定义、底层资源间的关系等，并将它们清晰呈现出来。要通过清楚描述（并借助严格的数据模型加以规范）预期的输入与输出，避免出现模糊不清的情况。尤其要注意，输入参数的命名务必清晰准确，比如别用 user 这样的参数名，改用 user_id 会更好。
      • 利用数据集评估效果，能更确切地衡量提示工程带来的效果。哪怕只是对工具描述做些细微调整，都可能大幅提升性能。
    <ins/>

    3.2 动态工具选择与约束

    避免在迭代过程中动态添加或移除工具，因为这会影响 KV-cache 并可能导致模型混淆 [1]。更优的策略是：
    • 上下文感知的状态机：“状态机” 可理解为 Agent 的 “工具权限开关系统”，它会预先定义不同 “状态”（比如 “浏览网页”“处理文件”“生成报告” 等任务场景），每个状态对应一套 “允许使用的工具列表”。而 “上下文感知” 则是让状态机能实时判断当前处于哪个场景（比如检测到用户需求是 “查天气”，就判定为 “信息检索状态”），进而自动激活对应状态下的工具权限。通过状态机管理工具可用性，例如通过掩码 token logits 来约束动作空间，从而在不修改工具定义的情况下限制 Agent 的选择 [1]。
    • 一致的动作名称前缀：设计具有一致前缀的动作名称（例如，所有浏览器工具以 browser_ 开头），以便于在特定状态下对工具进行分组约束 [1]。
    notion image
    在实际应用中，大多数模型供应商和推理框架都支持某种形式的回复预填充（response prefill）功能，借助该功能，无需修改工具定义就能限制动作空间。函数调用一般有三种模式（这里以 NousResearch 的 Hermes 格式为例）：
    • 自动（Auto）：模型可自行决定是否调用函数。具体通过仅预填充回复前缀来实现：<|im_start|>assistant
    • 必需（Required）：模型必须调用函数，但具体调用选择不受约束。通过预填充到工具调用令牌来实现：<|im_start|>assistant<tool_call>
    • 指定（Specified）：模型必须从特定的函数子集中选择调用。通过预填充到函数名开头来实现：<|im_start|>assistant<tool_call>{"name": “browser_
    基于此，可以通过直接屏蔽 token logits 来限制动作选择。Manus 还特意将动作名称设计成具有统一前缀，例如所有与浏览器相关的工具均以 browser_ 开头，命令行工具则以 shell_ 开头。这样一来，无需借助有状态的 logits 处理器，就能轻松保证智能体在特定状态下仅从某一组工具中做出选择。

    3.3 工具分层

    结合使用不同抽象层次的工具，可以提高 Agent 的灵活性和效率 [3]：
    • 低、中、高层工具结合：例如，低层工具（Bash、Read、Write）、中层工具（Edit、Grep、Glob）和高层工具（Task、WebFetch）。对于频繁使用的操作，可以封装为单独的工具，同时保留通用命令以处理特殊情况 [3]。
    • 详细的工具描述：工具描述应包含详细的 Prompt 和大量示例，系统 Prompt 应包含“何时使用工具”或如何在功能重叠的工具之间进行选择的信息 [3]。
    <ins/>

    3.4 Agent Skills：构建可组合、可扩展的专业能力

    Agent Skills 是 Anthropic 刚发布的一种通过结构化文件和文件夹来构建专业化 Agent 的新方法，它将指令、脚本和资源组织起来，使 Agent 能够动态发现和加载这些能力，从而在特定任务中表现更优 [5]。
    一个 Skill 是一个包含 SKILL.md 文件的目录，该文件包含组织好的指令、脚本和资源文件夹，为智能体提供额外的能力。
    一个 Skill 是一个包含 SKILL.md 文件的目录，该文件包含组织好的指令、脚本和资源文件夹，为智能体提供额外的能力。
    notion image
    • 核心理念：Agent Skills 就像为新员工准备的入职指南，它通过将专业知识打包成可组合的资源，将通用 Agent 转化为满足特定需求的专业 Agent [5]。
    • 渐进式披露（progressive disclosure）：一个 Skill 是一个包含 SKILL.md 文件的目录。SKILL.md 必须以 YAML Frontmatter 开头，包含名称和描述等元数据。这些元数据会在 Agent 启动时预加载到系统 Prompt 中，提供第一层级的渐进式披露。如果 Agent 认为该 Skill 与当前任务相关，它会加载完整的 SKILL.md 到上下文中，这是第二层披露。对于更复杂的 Skill，可以捆绑额外的文件（如 reference.md 或 forms.md），Agent 可以根据需要进一步导航和发现这些文件，实现更深层次的渐进式信息披露 [5]。
        • 可以将更多上下文（通过附加文件）整合到技能中，然后根据系统提示由 Claude 触发。
        可以将更多上下文（通过附加文件）整合到技能中，然后根据系统提示由 Claude 触发。
        notion image
    • 代码执行能力：Agent Skills 可以包含代码，供 Agent 根据任务性质作为工具执行。大型语言模型在许多任务中表现出色，但某些操作（如排序列表）更适合传统的代码执行，因为代码能提供更高的效率和确定性。例如，一个 PDF Skill 可以包含一个预先编写的 Python 脚本，用于读取 PDF 并提取所有表单字段，Agent 无需将脚本或 PDF 加载到上下文中即可运行，确保了工作流程的一致性和可重复性 [5]。
        • 技能还可以包含代码，Claude 根据任务性质自行决定这些代码是否作为工具被执行。
        技能还可以包含代码，Claude 根据任务性质自行决定这些代码是否作为工具被执行。
    • 开发与评估最佳实践：
      • 从评估开始：通过在代表性任务上运行 Agent，识别其能力差距，然后逐步构建 Skill 来弥补这些不足 [5]。
      • 结构化以适应规模：当 SKILL.md 文件变得难以管理时，将其内容拆分为单独的文件。如果某些上下文是互斥的或很少一起使用，分开存放可以减少 token 使用。代码既可以作为可执行工具，也可以作为文档，需要明确 Agent 是直接运行脚本还是将其作为参考加载到上下文中 [5]。
      • 从 Agent 视角思考：监控 Agent 在实际场景中如何使用 Skill，并根据观察结果进行迭代。特别关注 Skill 的名称和描述，因为 Agent 会根据这些信息决定是否触发该 Skill [5]。
      • 与 Claude 迭代：在与 Claude 共同完成任务时，让其捕获成功的路径和常见的错误，并将其转化为 Skill 中可重用的上下文和代码。如果 Agent 在使用 Skill 时偏离轨道，让其自我反思问题所在，这有助于发现 Agent 真正需要的上下文 [5]。

    4. 控制循环与架构：构建稳定高效的智能体骨架

    Agent 的控制循环和底层架构设计对其稳定性和效率至关重要。

    4.1 保持一个主循环

    • 简化架构以提高可调试性：优先考虑可调试性，而不是复杂的、多智能体的系统。例如，Claude Code 采用一个主线程，通过周期性地使用不同类型的 Prompt 来总结 git 历史、合并消息历史或生成 UX 元素。对于分层任务，它通过生成一个不能再生成子智能体的子智能体来处理，其结果作为“工具回复”添加到主消息历史中 [3]。

    4.2 使用小型模型

    • 成本效益与效率：对于读取大文件、解析网页、处理 git 历史和总结长对话等操作，超过 50% 的重要 LLM 调用都使用 claude-3-5-haiku 等小型模型。小型模型成本更低，可以大量使用，从而提高整体效率 [3]。

    5. 评估与适应：持续改进智能体性能

    Agent 的持续改进离不开有效的评估和适应机制。

    5.1 原型构建与综合评估

    • 快速原型与本地测试：快速构建工具原型并在本地测试，尤其是在使用 Claude Code 编写工具时，提供详细的文档（如 LLM-friendly 的 llms.txt 文件） [2]。
    • 生成评估任务：创建大量基于真实世界用例的评估任务，避免过于简单或肤浅的“沙盒”环境。强评估任务可能需要多次工具调用 [2]。
    • 系统 Prompt 指导：在评估 Agent 的系统 Prompt 中，指导 Agent 不仅输出结构化的回复块，还要输出推理和反馈块（在工具调用和回复块之前），以触发思维链（CoT）行为 [2]。
    • 避免过度指定或过拟合：允许 Agent 有多种解决任务的有效路径，避免过度指定或过拟合策略 [2]。

    5.2 错误恢复与适应

    智能体难免会犯错，这并非缺陷，而是客观存在的情况。语言模型可能出现幻觉，环境可能返回错误信息，外部工具也可能运行异常，各种意外的边缘情况随时都可能出现。在多步骤任务中，失败并非个别现象，而是任务循环中的常见环节。
    根据经验，改进智能体行为的一个极为有效的方法，实则相当简单：把错误的步骤保留在上下文当中。当模型看到某个动作失败，以及随之产生的观察结果或堆栈跟踪信息时，会不自觉地更新其内部认知。这会使模型在后续决策中，减少选择类似动作的可能性，从而降低重复犯错的概率。实际上，错误恢复能力是衡量智能体是否具备真正智能行为的重要指标之一。
    • 不隐藏错误：将失败的动作和观察结果（如堆栈跟踪）保留在上下文中，让模型通过观察错误隐式更新其内部信念，从而减少重复犯错的可能性。错误恢复是衡量真正 Agentic 行为的关键指标 [1]。
    notion image

    5.3 多样性与泛化

    少样本提示是改善大语言模型（LLM）输出的常用方法，但在智能体系统里，它可能会以不易察觉的方式带来负面影响。
    语言模型很擅长模仿，会依照上下文中的行为模式进行输出。要是上下文里有大量相似的动作-观察（action-observation）组合，模型就容易遵循这种模式。
    在那些需要重复做决策或行动的任务中，这种情况很可能引发问题。比如说，用 Manus 去批量审阅 20 份简历时，智能体经常会形成一种惯性，只是因为在上下文中看到了类似行为，就重复相似的操作。这就可能导致偏离目标、过度泛化，甚至产生幻觉。
    要解决这个问题，关键在于增加多样性。Manus 通过在动作和观察中引入少量的结构化变动，像是采用不同的序列化模板、变换措辞，或者在顺序与格式上制造些微干扰。这种适度的随机性能够打破固有模式，调整模型关注的重点。也就是说，别让少样本提示把自己限制住，上下文越单一，智能体就越容易出问题。
    • 避免过度模仿：在 few-shot prompting 中，避免过度模仿导致模型陷入重复模式。通过引入结构化的多样性（如不同的序列化模板、替代措辞、格式噪声）来打破模式，提高模型的泛化能力和鲁棒性 [1]。
    notion image
     

    结论

    AI Agent 的优化是一个多维度、系统性的工程。从巧妙的 Prompt 工程倒精细的上下文管理，从高效的工具设计到稳定的控制循环，再到持续的评估与适应，每一个环节都对 Agent 的最终性能产生深远影响。通过采纳这些优化手段，我们可以构建出更智能、更鲁棒、更具适应性的 AI Agent，从而在现实世界中解决更复杂的挑战。
    <ins/>

    参考文献

    1. Context Engineering for AI Agents: Lessons from Building Manus
    1. Writing effective tools for AI agents—using AI agents \ Anthropic
    1. Minusx | What makes Claude Code so damn good (and how to recreate that magic in your agent)!?
    1. Effective context engineering for AI agents \ Anthropic
    1. Equipping agents for the real world with Agent Skills \ Anthropic
     
    ]]>         <![CDATA[Mobile-Agent-v3：新的 GUI Agents 开源王者]]> https://www.breezedeus.com/article/ui-agent-mobile-agent-v3 https://www.breezedeus.com/article/ui-agent-mobile-agent-v3 Sat, 06 Sep 2025 00:00:00 GMT
     
    Home | GitHub | Twitter | Youtube | Bilibili
     
    notion image
    目录：
    [2508.15144] Mobile-Agent-v3: Foundamental Agents for GUI Automation, AlibabaGUI-Owl：端到端的多模态GUI智能体创新一：大规模环境基础设施与自我进化轨迹生产创新二：多样化的基础智能体能力构建创新三：可扩展的环境强化学习与TRPOMobile-Agent-v3：协同工作的多智能体框架卓越的性能表现1. 端到端模型性能：GUI-Owl的领先地位2. 超越专有模型：GUI-Owl-32B的强大实力3. 消融研究与关键技术贡献结论与展望AI Agents 知识星球
     

    [2508.15144] Mobile-Agent-v3: Foundamental Agents for GUI Automation, Alibaba

     
    阿里巴巴通义实验室的研究团队推出了Mobile-Agent-v3框架及其核心模型GUI-Owl。本文将深入剖析Mobile-Agent-v3背后的创新技术和方法，揭示其如何成为GUI自动化领域的革新力量。

    GUI-Owl：端到端的多模态GUI智能体

    Mobile-Agent-v3框架的核心是GUI-Owl，一个专为GUI自动化设计的端到端多模态智能体模型。它旨在将UI感知、元素定位（grounding）、复杂推理、任务规划以及最终的动作执行等一系列能力，统一到一个单一的策略网络中，其实就是统一的智能体模型（Agent Model）了。GUI-Owl基于Qwen2.5-VL模型进行微调，并通过海量且多样化的GUI交互数据进行后训练，使其能够无缝地与各种操作系统（包括移动端的Android、PC端的Ubuntu、macOS和Windows）上的图形用户界面进行交互。这使得GUI-Owl不仅能够自主执行多轮GUI交互任务，还能泛化到诸如问答、图像描述、任务规划和元素定位等特定应用场景。
    notion image
    GUI-Owl的强大之处在于其能够像人类一样，通过观察屏幕截图（当前环境观察）和回顾历史操作，来理解当前状态并决定下一步的行动（采用 Qwen 的函数调用格式）。在每个决策步骤中，模型会从预定义的动作空间中选择最合适的动作。值得一提的是，为了提升模型的适应性和处理复杂任务的能力，GUI-Owl在执行任何实际动作之前，都会先进行“推理”（Reasoning）。这种显式的推理过程，使得模型能够更好地适应动态和复杂的GUI环境。同时，为了避免对话历史过长，模型还会生成一个简洁的“结论”来概括当前步骤的关键信息，并将其存储在历史上下文中，确保了长期交互的效率。最终，GUI-Owl输出的抽象动作会被翻译成具体的设备操作命令，例如针对Android设备的ADB命令，或针对桌面环境的pyautogui代码，从而实现对GUI的精准控制。
    notion image
    GUI-Owl的另一个重要特性是其在多智能体框架中的灵活性。它不仅可以作为一个独立的智能体完成任务，还可以作为Mobile-Agent-v3框架中的一个专业模块，与其他智能体协同工作，共同解决更复杂、更长期的自动化工作流。这种模块化和协作能力，为构建更高级的GUI自动化系统提供了可能。
    <ins/>

    创新一：大规模环境基础设施与自我进化轨迹生产

    传统的GUI自动化数据收集往往依赖于耗时耗力的人工标注，这极大地限制了模型训练的规模和多样性。Mobile-Agent-v3团队为了解决这一瓶颈，构建了一个大规模环境基础设施，并在此基础上提出了Self-Evolving GUI Trajectory Production（自我进化GUI轨迹生产）框架。这一创新是Mobile-Agent-v3能够实现高性能的关键之一。
    该基础设施充分利用了云计算的优势，在阿里云上部署了大量的云手机和云计算机，从而能够模拟并支持Android、Ubuntu、macOS和Windows等多种主流操作系统环境。这意味着研究人员可以在一个高度可控且动态变化的虚拟环境中，进行大规模的GUI交互数据收集和模型训练，极大地提升了实验效率和数据多样性。
    notion image
    自我进化GUI轨迹生产pipeline是这一基础设施的核心。它通过一个精巧的自动化流程，实现了高质量交互数据的持续生成和优化，具体包括以下四个关键环节：
    1. 高质量查询生成（High-quality Query Generation）：系统能够模拟真实用户的行为模式，自动生成多样化且具有挑战性的交互查询。这些查询旨在覆盖各种复杂的GUI操作场景，例如特定应用程序内的多步骤任务、跨应用程序的协作任务，以及需要复杂逻辑判断的场景。通过精细设计的查询模板和生成策略，确保了生成数据的广度和深度。
    1. 模型试运行（Model Rollouts）：在虚拟环境中，GUI-Owl和Mobile-Agent-v3会根据生成的查询进行实际操作，产生一系列的交互轨迹。这个过程是全自动的，模型会尝试完成任务，并记录下每一步的观察（屏幕截图）和执行的动作。这些轨迹包含了模型在不同场景下的决策过程和执行结果，是后续数据处理的基础。
    1. 严格的正确性判断（Rigorous Correctness Judgment）：系统内置了强大的评估机制，能够对生成的轨迹进行严格的正确性判断。这不仅仅是简单的任务成功与否的判断，还包括对轨迹的效率、合理性以及是否符合预期行为的评估。只有高质量、符合预期的交互数据才会被纳入训练集，从而避免了低质量数据对模型性能的负面影响。这种机制有效地过滤了无效或错误的轨迹，保证了数据质量。
    1. 特定查询指导生成（Query-specific Guidance Generation）：该模块借助成功的轨迹创建引导，以提高模型性能。这一过程包含以下步骤：(1) 动作描述：VLM 依据参考轨迹，针对每个动作的结果生成描述。其输入包括动作前后的屏幕截图以及动作决策。对于基于坐标的动作，作者会突出交互点，帮助 VLM 进行分析。(2) 质量控制：针对模型生成的轨迹，VLM 会参照模型的决策依据，验证步骤的有效性，筛选掉次优动作。(3) 引导合成：将动作描述串联起来，输入到 LLM 中，由该模型总结完成查询所需的关键步骤，进而生成特定查询引导。这些指导可以帮助模型更好地理解任务，并在后续的试运行中生成更优的轨迹。例如，当模型在某个特定步骤陷入困境时，系统可以提供额外的提示或示范，引导模型走出困境，从而生成更完整的成功轨迹。
    这种“自我进化”的机制形成了一个强大的正反馈循环：模型生成数据，数据反哺模型，模型能力提升后又能生成更高质量的数据。这不仅显著减少了对人工标注的依赖，还使得Mobile-Agent-v3能够持续地学习和适应新的GUI环境和任务，从而在不断变化的应用场景中保持领先地位。这种数据生成范式对于解决GUI自动化领域长期存在的数据稀缺问题具有重要意义。

    创新二：多样化的基础智能体能力构建

    GUI-Owl 不仅能作为原生智能体，独立与 GUI 进行交互，还提供多种基础能力，以支持下游的独立调用，或集成到多智能体框架中。为此，作者收集并构建了各类能力（如定位（grounding）、图像 caption 和 planning）的数据集。在训练过程中，这些数据集会与通用指令数据混合。作者发现，该模型不仅具备零样本 GUI 问答能力，还能针对未见任务，具备通用的指令遵循能力。
    notion image
    为了使GUI-Owl具备更强大的泛化能力和适应性，研究团队在数据构建方面下足了功夫，引入了多个下游数据构建pipeline，旨在全面提升智能体的基础UI能力。这些能力是GUI-Owl能够理解复杂GUI环境并执行精细操作的基石。
    1. UI元素定位（Grounding）pipeline：
        • 目标：使GUI-Owl能够精确识别和定位屏幕上的任何UI元素，无论是基于其功能（如“提交按钮”）、外观（如“蓝色方框”）还是布局（如“左上角的图标”）。
        • 实现细节：通过构建包含大量UI元素及其对应位置、属性信息的数据集，训练模型将自然语言描述与屏幕上的视觉元素进行关联。这包括对按钮、文本框、图片、链接等各种UI组件的精确识别和边界框定位。此外，还支持细粒度的单词/字符定位，这意味着模型不仅能识别一个按钮，还能识别按钮上的具体文字，这对于需要精确文本交互的任务至关重要。
        • 重要性：精确的定位能力是GUI自动化的基础，没有它，智能体就无法知道要操作哪个元素，也无法理解界面上各个组件的含义。
    1. 任务规划（Task Planning）pipeline：
        • 目标：让GUI-Owl能够将复杂、长期的任务分解为一系列可执行的子步骤，并理解这些步骤之间的逻辑关系，从而实现高效的任务完成。
        • 实现细节：研究团队从大量的成功历史轨迹中提炼出程序化知识，并结合LLM的强大推理能力，构建了任务规划数据集。这些数据包含了从高层任务目标到具体操作序列的映射，例如“预订机票”可能被分解为“打开订票应用”、“选择出发地和目的地”、“选择日期”、“选择航班”等一系列子任务。这使得模型能够学习到在不同场景下完成任务的最佳路径和策略，即使面对跨应用程序协作（如从邮件中提取信息并在浏览器中搜索）的任务也能有效应对。
        • 重要性：规划能力是智能体处理复杂任务的关键，它决定了智能体能否高效、准确地完成多步骤操作，尤其是在需要多轮交互和状态转换的场景下。
    1. 动作语义（Action Semantics）pipeline：
        • 目标：使GUI-Owl能够理解其执行的每个动作所带来的界面变化和潜在影响，从而形成对环境的深刻理解。
        • 实现细节：通过捕捉动作执行前后的UI观察（屏幕截图），模型学习动作与状态转换之间的因果关系。例如，点击一个按钮后，界面可能会出现新的弹窗、内容更新、页面跳转等变化，模型需要理解这种变化是由于其点击动作引起的，并能预测不同动作可能导致的结果。这有助于模型建立一个内部的世界模型，从而进行更深层次的推理和反思。
        • 重要性：理解动作语义有助于模型进行更深层次的推理和反思，从而避免无效操作，并在出现错误时进行自我纠正，提升了智能体的鲁棒性和适应性。
    除了上述三种核心能力，研究团队还特别关注了推理与反思（Reasoning and Reflecting）能力的构建。他们通过多种数据合成技术，如离线提示引导拒绝采样（offline hint-guided rejection sampling）、从多智能体框架中蒸馏知识（distillation from a multi-agent framework）以及迭代在线拒绝采样（iterative online rejection sampling），来生成丰富的推理和反思数据。这种监督机制使得GUI-Owl不仅能够进行独立的逻辑推理，还能在Mobile-Agent-v3这样的多智能体框架中，与其他智能体进行复杂的协作推理，并根据其在框架中扮演的角色调整其推理风格。这极大地增强了GUI-Owl在面对未知或复杂情况时的适应性和鲁棒性，使其能够处理更具挑战性的开放式任务。
    <ins/>

    创新三：可扩展的环境强化学习与TRPO

    为了进一步提升GUI-Owl在真实世界GUI自动化任务中的表现，研究团队引入了强化学习技术。他们开发了一个高度可扩展的训练框架，其核心在于一个统一的多任务训练接口，该接口能够标准化单轮推理任务和多轮智能体任务之间的交互。这一设计使得模型能够在一个统一的范式下学习不同复杂度的任务。
    该框架的一个关键创新是将经验生成与策略更新解耦。这意味着模型在与环境交互生成经验（即操作轨迹）的同时，可以独立地进行策略更新。这种解耦提供了对策略遵循的细粒度控制，使得训练过程更加灵活和高效。更重要的是，这种设计支持完全异步训练，极大地加速了训练过程，并能更好地将模型的决策与实际用户在真实世界中的使用习惯对齐，从而提升了模型的实用性和泛化能力。
    notion image
     
    在强化学习领域，处理长且可变长度的动作序列一直是一个挑战，尤其是在在线环境中。传统的强化学习方法在处理稀疏和延迟奖励时往往效率低下。为了解决这一问题，论文引入了轨迹感知相对策略优化（Trajectory-aware Relative Policy Optimization, TRPO）。
    其中，  为批次中 token 的总数，  是轨迹  的轨迹级优势，而  是当前策略与旧策略下一个 token 的概率比。这种经过裁剪的目标函数，在稳定训练的同时，能够有效利用整体轨迹级奖励信号，以应对长期的 GUI 自动化任务。
    TRPO是一种新颖的强化学习算法，它具有以下特点：
    • 轨迹级别奖励（Trajectory-level Rewards）：TRPO不再仅仅关注单个时间步的奖励，而是利用整个轨迹的奖励信息来计算每个时间步的优势（advantage）。具体来说，它使用轨迹的准确性和格式奖励之和来计算一个归一化的优势估计，并将这个优势均匀地分配给轨迹中的每一个动作。这种全局视角使得模型能够更好地理解长期行为对最终结果的影响，从而做出更明智的决策，尤其是在GUI自动化这种任务成功往往需要一系列正确操作的场景中。
    • 重放缓冲区（Replay Buffer）：为了提高强化学习的稳定性和数据利用效率，TRPO采用了重放缓冲区。它将历史上成功的轨迹存储起来，并在训练过程中随机采样这些经验进行学习。这有助于打破数据之间的相关性，减少训练过程中的方差，并使得模型能够从更广泛的经验中学习，从而加速收敛并提高策略的稳定性。
    • 策略优化目标：对于高分辨率的GUI屏幕截图，完整的轨迹会被分割成单步数据实例用于策略更新。损失函数会根据原始轨迹中的总步数进行缩放，以平衡优化过程。这种细致的优化策略确保了模型在处理复杂视觉信息和长序列操作时的有效性。
    通过TRPO，GUI-Owl能够更有效地从实际交互中学习和优化其行为策略，尤其是在面对那些需要一系列复杂、连续操作才能完成的GUI自动化任务时。这种强大的强化学习能力，使得Mobile-Agent-v3在处理真实世界中的动态和不确定性方面表现出色，为构建鲁棒的GUI智能体提供了坚实的技术支撑。
    notion image
    <ins/>

    Mobile-Agent-v3：协同工作的多智能体框架

    Mobile-Agent-v3不仅仅是一个单一的GUI-Owl模型，它更是一个精巧设计的多智能体框架，通过协调多个专门的智能体来进一步提升GUI-Owl的性能，以应对更复杂、更长期的自动化工作流。这个框架将复杂的任务分解给不同的智能体，每个智能体各司其职，并通过协作机制共同完成目标。
    notion image
    Mobile-Agent-v3框架主要由以下四个核心智能体组成：
    1. 管理智能体（Manager Agent, M）：
        • 角色：战略规划者。
        • 职责：负责将用户给定的高层指令分解为一系列有序的子目标列表。它利用外部知识（通过检索增强生成RAG模块，例如使用维基百科、搜索引擎和用户提供的文档）来获取相关信息，并动态地根据执行结果和反馈更新规划。这意味着Manager Agent能够根据任务的进展和遇到的问题，灵活调整后续的步骤，确保任务能够顺利进行。
    1. 工作智能体（Worker Agent, W）：
        • 角色：战术执行者。
        • 职责：根据Manager Agent提供的子目标，结合当前的GUI状态、历史反馈和累积的笔记，选择并执行最相关的可操作子目标。它会生成一个动作元组，其中包含其思考过程（thought）、具体的动作命令（action command）以及对当前步骤的总结（summary）。Worker Agent是直接与GUI环境交互并执行操作的智能体，它将GUI-Owl的能力转化为实际的GUI操作。
    1. 反思智能体（Reflector Agent, R）：
        • 角色：自我纠正机制。
        • 职责：负责评估Worker Agent执行动作后的结果。它会比较Worker Agent预期的结果与实际的界面状态变化，将结果分类为成功、中立或有害，并生成详细的因果反馈。Reflector Agent的关键作用在于提供实时的、有指导性的反馈，帮助系统识别并纠正错误，从而提升整体的鲁棒性和学习效率。
    1. 笔记智能体（Notetaker Agent, C）：
        • 角色：持久化上下文记忆维护者。
        • 职责：仅在Reflector Agent判断为成功或中立时被触发。它负责从当前屏幕中提取并存储关键元素作为笔记，从而维护一个持续的上下文记忆。这些累积的记忆（包括关键UI元素、任务进展等）将支持Manager Agent未来的规划和Worker Agent的执行，避免重复探索和遗忘关键信息。
    Mobile-Agent-v3框架以一个循环的方式运作：从用户指令开始，Manager Agent初始化规划，然后Worker Agent执行动作，Reflector Agent评估结果，Notetaker Agent更新记忆，最后Manager Agent根据反馈更新规划，直到任务完成或达到预设的停止条件。这种精巧的多智能体协作机制，使得Mobile-Agent-v3能够处理单一智能体难以完成的复杂、长周期和需要持续适应的任务，展现了多智能体系统在GUI自动化领域的巨大潜力。
    notion image
    <ins/>

    卓越的性能表现

    Mobile-Agent-v3框架及其核心模型GUI-Owl在多个主流GUI自动化基准测试中展现了卓越的性能，证明了其作为基础智能体的强大能力。这些基准测试全面评估了GUI-Owl在UI元素定位、单步决策、通用问答以及在线环境交互等方面的能力。论文通过一系列实验，不仅验证了GUI-Owl和Mobile-Agent-v3的有效性，还深入分析了各项创新技术对性能的贡献。

    1. 端到端模型性能：GUI-Owl的领先地位

    GUI-Owl作为端到端的多模态GUI智能体，在多个开放源代码模型中取得了新的SOTA（State-of-the-Art）性能。论文主要在以下两个关键基准上进行了评估：
    • AndroidWorld：这是一个针对Android移动设备GUI自动化任务的基准。GUI-Owl-7B模型在此基准上取得了66.4%的成功率，显著超越了同等规模的其他开源模型。
    • OSWorld：这是一个涵盖桌面操作系统（如Ubuntu、macOS、Windows）GUI自动化任务的基准。GUI-Owl-7B在此基准上取得了29.4%的成功率，同样表现出强大的泛化能力。
    notion image
    值得注意的是，当GUI-Owl与Mobile-Agent-v3框架结合时，其性能得到了进一步的显著提升：
    • 在AndroidWorld上，成功率提升至73.3%。
    • 在OSWorld上，成功率提升至37.7%。
    这充分证明了Mobile-Agent-v3多智能体框架在复杂任务协调和执行方面的强大增益效果，使得GUI-Owl能够更好地发挥其潜力。

    2. 超越专有模型：GUI-Owl-32B的强大实力

    除了与开源模型的对比，论文还展示了GUI-Owl-32B（更大规模的模型）在性能上甚至超越了一些强大的专有模型，这在GUI自动化领域是一个里程碑式的成就：
    • MMBench-GUI：这是一个综合性的GUI理解和交互基准。GUI-Owl-32B在此基准上表现出色，其性能优于包括GPT-4o和Claude 3.7在内的所有模型。
    • AndroidControl：这是一个专注于Android设备控制的基准。GUI-Owl-32B同样在此基准上取得了领先地位，再次证明了其在复杂移动GUI操作上的卓越能力。
    • UI元素定位能力：在专门的UI元素定位评估中（如ScreenSpot V2/Pro, OSWorld-G, MMBench-GUI L2），GUI-Owl-32B不仅超越了所有同等规模的开源模型，而且与专有模型相比也具有极强的竞争力，这得益于其精细的Groundingpipeline训练。
    notion image
    这些结果表明，GUI-Owl不仅在开源领域树立了新的标杆，也为整个GUI自动化领域带来了新的可能性，证明了通过大规模数据和先进训练方法，开源模型也能达到甚至超越商业闭源模型的性能。
    <ins/>

    3. 消融研究与关键技术贡献

    论文还通过详细的消融研究（Ablation Studies）验证了Mobile-Agent-v3中各项关键技术组件的有效性：
    • TRPO策略的有效性：实验结果显示，引入轨迹感知相对策略优化（TRPO）策略显著提升了模型在在线环境中的表现。例如，在OSWorld-Verified基准上，TRPO策略将成功率从27.1%提升到了34.9%以上，这强调了其在处理稀疏奖励和长序列动作方面的优势。
    • 在线过滤、重放缓冲区和经验管理：消融研究证实，这些机制对于训练的稳定性和效率至关重要。在线过滤确保了高质量数据的输入，重放缓冲区则有效利用了历史经验，减少了训练过程中的方差，使得模型能够更稳定地学习。
    • 历史图像数量和交互步长预算：实验表明，模型的性能与所使用的历史图像数量以及交互步长预算呈正相关。这意味着提供更丰富的上下文信息和允许更长的交互序列，有助于模型做出更准确的决策。
    • 推理数据合成：论文详细分析了推理数据合成策略（包括离线提示引导拒绝采样、多智能体框架蒸馏和迭代在线拒绝采样）对GUI-Owl推理能力的增益。这些方法共同作用，逐步增强了GUI-Owl的推理能力，使其能够处理更复杂的逻辑和任务。
    notion image
    notion image
    这些深入的实验分析不仅展示了Mobile-Agent-v3和GUI-Owl的卓越性能，也为未来的GUI自动化研究提供了宝贵的经验和方向，证明了其创新方法在提升智能体能力方面的关键作用。

    结论与展望

    Mobile-Agent-v3框架及其核心模型GUI-Owl的发布，无疑为GUI自动化领域注入了新的活力。通过其在大规模环境基础设施、多样化的基础智能体能力构建以及可扩展的环境强化学习这三大方面的创新，研究团队不仅提升了GUI智能体的性能上限，更重要的是，为构建能够真正理解并操作复杂GUI环境的通用智能体奠定了坚实的基础。
    GUI-Owl作为一个端到端的多模态智能体，其在多平台、多任务上的卓越表现，以及在多智能体框架中的灵活集成能力，预示着GUI自动化将不再局限于简单的重复性任务，而是能够处理更具挑战性、需要复杂推理和规划能力的场景。特别是“自我进化GUI轨迹生产”框架的提出，为高质量、大规模的GUI交互数据收集提供了一条可持续的路径，有望解决长期以来困扰该领域的数据瓶颈问题。
     

    AI Agents 知识星球

    GUI Agents 技术发展迅猛，想紧跟 GUI/AI agents 技术前沿？我们的知识星球会介绍 Agents 相关的最新项目和工具，并以视频方式解读最新论文，为你开启技术新视野，快来加入吧！
    加入知识星球，每周获取会员专享视频👇
    notion image
     
    扫码加微信小助手为好友，备注「agent」，小助手会定期邀请入群👇
    notion image
    当前星球包含的专享视频包括：
     
    <ins/>
     
    ]]>