引言

桌面 AI 助手的核心价值在于"看见"用户的屏幕、"操作"用户的应用。当前主流 Agent 普遍具备文本生成、代码执行、浏览器自动化等能力，但在两个关键环节存在明显短板：一是无法直接感知屏幕上正在显示的内容，二是无法像人一样打开桌面软件并对其进行操作。这两项缺失直接限制了 AI 在远程协作、实时辅助、文档协同处理等高频场景中的应用深度——用户不得不反复截图、手动描述操作步骤，才能让 AI 理解当前的状态和遇到的问题。

豆包（Doubao）客户端已在屏幕共享和应用共享这两项能力上搭建了相对完整的技术体系。WPS 灵犀 Claw 在分析豆包客户端安装文件夹时，从其核心组件中提取了相关技术信息。本文基于这些分析结果梳理其技术实现路径，并据此探讨 Claw 引入同类功能的可行方向。

一、屏幕共享的技术原理

屏幕共享要解决的核心问题很直接：怎样又快又清晰地把屏幕画面从本地传到远端。这涉及画面采集、压缩编码、网络传输三个环节。豆包的方案基于 Chromium 内置的 WebRTC desktop_capture 模块，为不同 Windows 版本准备了一套三级降级策略——优先使用最快的方式，行不通再换稍慢的，最后用兼容性最好的方式兜底。

1.1 画面采集：三级降级

第一级 WgcCapturerWin 依赖 Windows 10 1803 引入的现代图形捕获接口（Windows.Graphics.Capture）。它的工作方式非常高效：直接从显卡的显存中读取画面数据，整个过程中 CPU 几乎不参与拷贝，因此延迟最低、资源占用最少。但这种接口有版本门槛，老版本的 Windows 无法使用。

第二级 ScreenCapturerWinDirectx 利用 DirectX 11 提供的桌面复制功能（Desktop Duplication API）。该接口同样可以直接从 GPU 获取画面，走的是 DXGI 通道而非 WinRT。它的兼容性比 WGC 更好，只要系统支持 DirectX 11 即可运行，覆盖了大部分 Windows 10 和 Windows 11 设备。

第三级 ScreenCapturerWinGdi 是最传统的方式，即通过 GDI 的 BitBlt 函数完成屏幕截图——本质上就是让 CPU 把显卡画面逐像素拷贝到内存中。这种方式性能最弱，CPU 占用较高，但几乎兼容所有 Windows 版本，是前两级都不可用时的最后保障。

在实际运行时，系统会自动检测当前环境并选择最合适的引擎。这种降级策略确保了无论用户的电脑配置如何、运行哪个版本的 Windows，屏幕共享功能都能正常工作。如果用户只想共享某个窗口而非整个屏幕，采集逻辑会自动切换到窗口模式：同样优先使用 WGC 的窗口捕获能力，不满足时回退到 GDI 窗口捕获，还可以先截取全屏画面再裁剪出目标窗口区域。系统通过 EnumWindows、GetForegroundWindow 等 Win32 API 遍历当前所有窗口，供用户选择。

1.2 编码与传输

采集到原始画面后，需要压缩编码再通过网络发送出去。豆包支持 H.264（OpenH264）、VP8、VP9 和 AV1（libaom）四种视频编码格式，优先启用 D3D11 显卡硬件加速以降低 CPU 占用。这意味着在大多数配备独立显卡或现代集成显卡的电脑上，编码过程几乎不消耗 CPU 资源，不会影响用户同时进行的其他工作。

传输层基于 WebRTC 标准协议栈——SRTP 负责音视频流的加密，ICE 负责在复杂网络环境下建立连接（包括 NAT 穿透），DTLS 负责密钥协商。在此基础上，火山引擎 ByteRTC SDK 提供了多项增强能力：采用 SFU（选择性转发单元）架构实现多端分发，当多个人同时观看时由服务器统一管理媒体流而非让每个观看者都与发起者建立点对点连接；支持 Simulcast 多码率分层编码，同时发送高、中、低三种画质的视频流，由接收端根据自身网络状况动态选择最合适的码率；此外还有实时 QoS 监控机制，持续跟踪延迟、丢包率和带宽利用率，自动调整传输策略以应对网络波动。

二、应用共享的技术原理

应用共享是屏幕共享的进阶形态。屏幕共享解决的是"让别人看到我的屏幕"，而应用共享更进一步——不仅传递画面，还要让 AI 能够远程操控桌面上的应用程序。这相当于给 AI 装上了一双虚拟手。

豆包的实现基于一套本地代理架构，核心代码位于 aha\saman\chrome\browser\app_proxy\ 目录下。

2.1 App Proxy 架构

这套架构的核心思路是在用户的电脑上运行一个 WebSocket 服务器，充当 AI 与桌面应用之间的通信桥梁。具体流程如下：

1. AI 生成一条操作指令（例如"打开 WPS Word 并在第二行插入一段文字"）；

2. 指令经 WebSocket 发送到本地的代理服务器；

3. 代理服务器根据目标应用类型，将指令路由到对应的应用代理（ApplicationProxy）去执行；

4. 应用代理调用目标应用的接口完成操作，执行结果原路返回给 AI。

从代码结构看，指令通过 neotix::appshare 命名空间下的 Shell API 下发，核心接口包括 setShareInfos（设置共享的应用信息）、startTargetApp（启动目标应用）和 callProxyFunc（调用代理函数执行具体操作）。整个过程完全在本地完成，数据不经过外部服务器，延迟极低。

2.2 Script 与 Plugin 双模式

应用代理支持两种执行模式，分别应对不同的操作场景：

Script 模式通过 Windows 的 COM 脚本接口（IActiveScriptParse）执行 JScript 代码来操控应用。具体来说，AI 会根据操作目标自动生成一段脚本代码，然后交给 Windows 内置的脚本引擎去执行，从而驱动目标应用完成指定动作。例如，要让 Word 在某段文字后插入表格，AI 会生成对应的 JScript 代码，由系统脚本引擎调用 Word 的 COM 接口执行。当某些操作需要更高的系统权限时，会启用 Ghost Helper 机制——将脚本执行器注入到 explorer.exe（Windows 资源管理器）进程中运行，以获取桌面级的访问权限。Script 模式的优势在于不需要在目标应用中预装任何插件，只要有 COM 接口就能驱动，覆盖面广。

Plugin 模式则是让目标应用内预先安装的原生插件通过 WebSocket 与代理服务器通信。这种模式适用于需要更深层次交互的场景，比如直接调用应用的内部 API 完成文件级操作，或者访问应用内部的实时状态数据。相比 Script 模式，Plugin 模式的性能更好、功能更强，但需要为每个目标应用单独开发和安装插件。

目前该架构定义了 6 种交互类型：browser（浏览器）、code（代码编辑器）、excel（电子表格）、file（文件管理）、samantha（AI 内部交互）和 word（文字处理），并为 WPS Word、WPS Excel、WPS PDF、Chrome、Microsoft Excel 等应用编写了专用的代理程序。

2.3 与屏幕共享的协同

应用共享和屏幕共享并非独立运作。启动应用共享时，屏幕共享通道通常也会同时激活。这样 AI 在通过代理下发操作指令后，可以通过屏幕画面实时确认操作结果是否正确——形成"看到画面 → 分析判断 → 下发操作 → 验证结果"的完整闭环。如果操作出错，AI 可以根据屏幕反馈及时修正指令，而不需要用户介入描述问题。

三、对 WPS 灵犀 Claw 的建议

基于上述分析，结合 Claw 当前的技术架构（桌面端运行、具备浏览器自动化和 MCP 工具调用能力），提出以下三项分层建议。

建议一：引入屏幕共享基础能力

目标：使 Claw 能够捕获当前屏幕或指定窗口的画面，并将其传递至多模态 LLM 进行视觉理解与分析。

技术路径：Claw 本身是 Windows 桌面应用，可以直接调用系统的 Windows.Graphics.Capture API 或 DXGI Desktop Duplication API 进行画面采集，无需依赖 Chromium 内置的 desktop_capture 模块。采集到的画面经编码后以图像形式传递给具备视觉理解能力的多模态大模型。

实际价值：Claw 目前能读写本地文件，但无法感知屏幕上正在显示的非文件形态内容——例如用户的操作状态、系统弹窗信息、在线仪表盘数据、未保存的设计稿等。屏幕捕获能力将补齐这一感知缺口，使 Claw 能够基于屏幕实际状态做出更精准的判断，减少用户反复截图描述的沟通成本。例如，当用户说"这个报错怎么解决"时，Claw 可以直接读取弹窗内容并给出针对性建议，而非让用户手动复制错误信息。

建议二：引入应用共享的本地代理架构

目标：使 Claw 能够通过结构化接口操控本地应用程序，突破当前仅限文件读写和浏览器操作的边界。

技术路径：参照豆包的 App Proxy 模式，在 Claw 进程内嵌入轻量级 WebSocket 服务端，通过 MCP 协议暴露应用操作接口。对于 WPS 系列应用，可利用已有的宏（VBA/JS）和 COM 接口作为脚本执行层；对于其他应用，可通过 Windows Accessibility API（UI Automation）或窗口消息机制实现基础操作。

与现有能力的区别：Claw 目前的浏览器自动化只能操控网页内容。引入本地代理架构后，操控范围将扩展到整个桌面应用层，尤其是 WPS 自家产品线，使 Claw 从"Web Agent"升级为真正的"Desktop Agent"。例如，用户可以直接对 Claw 说"帮我把这个 Excel 里的数据做成柱状图"，Claw 会自动打开 WPS Excel 并完成操作，而非在后台默默改完文件让用户自己打开查看。

建议三：WPS 文档操作的深度集成

目标：利用 WPS 原生的文档处理能力，实现超越文件级读写的精细化操作。

技术路径：豆包已为 WPS Word、Excel、PDF 编写了专用代理（如 win_wps_word_proxy.cc），通过 JScript 脚本在文档内执行格式调整、数据填充、图表生成等操作。作为 WPS 自研的 AI 产品，Claw 具有天然优势——可直接调用 WPS 的内部 API（如 WPS JS Macro API）或通过 COM 接口与 WPS 客户端实时交互，无需像第三方工具那样走通用的脚本注入路径。这不仅能获得更好的性能和更丰富的功能，还能确保与 WPS 未来版本的功能保持同步。

实际价值：目前 Claw 对 WPS 文档的操作主要通过 python-docx、openpyxl 等第三方库进行文件级处理——改完之后用户需要重新打开文件才能看到效果，且无法利用 WPS 内置的模板库、样式库、协同编辑等高级功能。若能直接与 WPS 客户端通信，则可支持实时预览、在线协同编辑、模板即时套用等更贴近用户实际工作流的能力，显著提升用户体验。

以上技术原理均基于 WPS 灵犀 Claw 对豆包客户端安装文件夹的分析结果，具体实现细节以豆包官方文档为准。建议部分基于 Claw 已公开的技术架构进行合理推演，实际可行性需结合 Claw 团队的技术评估。