切换主题
一、OpenAdapt 是什么
OpenAdapt 不是一个传统的 RPA 工具。它的定位是 AI-First 流程自动化——将大型多模态模型（LMM）与传统桌面/Web GUI 之间的"适配层"开源出来。你可以把它理解为一座桥：一头是 Claude、GPT-4V、Gemini 这些能"看懂"屏幕的模型，另一头是你每天在用的那些没有 API 的遗留软件。
它的核心哲学可以浓缩成一句口号：Perform, don't prompt. 你不需要写提示词让模型去猜，而是直接录制一次人工操作，系统把它编译成确定性工作流，然后毫秒级回放。
OpenAdapt 是开源项目（GitHub 约 1.6k Star），模型无关（model-agnostic），在本地运行，数据不外传。目前处于 Beta 阶段。
二、工作流三阶段
整个系统的核心流转只有三步：
2.1 录制：捕获一切
openadapt flow record 会记录下你在目标应用中的每一次鼠标移动、点击、键盘输入和窗口事件。这些原始数据被保存为结构化的 ActionEvent，包含坐标、时间戳、截图和可访问性树信息。
一个典型的录制事件长这样：
json
{
"type": "click",
"x": 342,
"y": 156,
"screenshot_base64": "...",
"window_title": "CRM 系统 - 新建客户",
"accessibility_tree": { ... }
}也就是说，它不只是录坐标，还同时抓取了三层信号：视觉（截图）、结构（DOM / 可访问性树）和空间（坐标）。这为后续编译阶段的多信号融合打好了基础。
2.2 编译：从演示到确定性程序
编译是整个系统最核心的能力。openadapt flow compile 拿到录制数据后，会生成一份结构化的可执行工作流。具体做法是把人类演示中的每一个交互点，都绑定到应用界面上最强的、最稳定的定位信号。
编译输出的工作流是纯确定性的——不依赖任何模型调用。在健康路径上，引擎按优先级匹配信号：
- 结构定位（DOM selector / accessibility path）：浏览器和原生应用中精度最高的信号
- 模板匹配（template matching）：基于录制的截图在运行时截图中找最相似的区域
- OCR：按文字内容定位元素
- 视觉地标（visual landmarks）：锚定到窗口中的固定图案（logo、分隔线等）
- 坐标回退（coordinate fallback）：最后一招
每种信号都有置信度评分，编译时按优先级和阈值自动选择最佳策略。这套机制使得同一个工作流能跨分辨率、跨窗口大小稳定运行。
2.3 回放：受控执行与效果验证
openadapt flow replay 是运行时引擎。它不是简单地把录制操作重新放一遍，而是实现了严格的状态机和效果验证：
- 执行前校验：检查应用状态、目标窗口、授权身份是否与录制时一致
- 逐步执行：每步操作后等待应用响应，比对预期效果
- 效果验证：关键操作（如提交表单）完成后，从独立接口（如只读 API 会话）回读数据确认写入成功，验证通过才标记
VERIFIED - 异常暂停：当信号匹配不上或效果验证失败时，工作流进入 HALT 状态，携带诊断证据等待处理
这套机制的工程价值在于：点击"成功"不等于业务"成功"。按钮按下去和数据库写进去之间有一段灰色地带，OpenAdapt 用独立的验证链路来消除它。
三、大模型怎么用
到这里，你可能会问：OpenAdapt 自称 AI-First，但上面描述的健康路径全程没用到 LLM？没错，健康执行路径是零模型调用的。这不是瑕疵，是刻意设计。
OpenAdapt 把模型用在了更关键的位置：
3.1 受控修复
当回放失败（HALT）时，OpenAdapt 可以按策略启动受控修复流程：
- 不是即兴发挥：修复是版本化的变更，不是让模型临时决定"换个地方点试试"
- 候选方案：LLM 分析失败的截图和诊断信息，提出一个候选修复（例如"按钮从左上角移到了右上角，新的坐标是 (512, 40)"）
- 人工审核：候选修复必须由人审核、确认、测试通过后才能合入工作流
- 可回滚：每次修复作为一次版本变更，可以随时回退
这种"模型提案 + 人把关"的模式，把 LLM 的灵活性装进了确定性的笼子，适合对正确性有硬要求的业务场景（金融交易、医疗记录、合同审批）。
3.2 UI 元素定位
openadapt-grounding 子包专门负责在屏幕截图中定位 UI 元素。它包括：
- 视觉检测：集成 SAM（Segment Anything Model）、YOLO（You Only Look Once）、微软 OmniParser 等视觉模型，在截图中框出按钮、输入框、下拉菜单、图标等可交互元素
- 语义理解：识别元素的文本标签、功能语义和上下文关系
- 跨分辨率和跨 DPI：基于视觉特征而非硬坐标定位，天然抗缩放和分辨率变化
Grounding 是编译阶段信号提取的关键输入——它告诉编译器"录制时点击的这个按钮，在当前屏幕的哪个位置"。
3.3 多模型共识
openadapt-consilium 子包实现了一个精巧的设计：
当需要对一个操作做关键决策（如"这个弹窗是报错还是警告？应该点确定还是取消？"）时，Consilium 同时查询多个模型——例如 GPT-4V、Claude 和 Gemini——每个模型独立给出判断，然后通过投票或加权机制决定最终答案。
这背后是一个统计学直觉：单模型可能误判，但三个不同训练来源的顶级模型同时误判同一个东西的概率极低。 类似航天领域的 triple-redundancy 设计。
3.4 多模态检索
openadapt-retrieval 子包实现了从历史录制库中检索相似场景的能力：给一段新任务的截图或描述，系统在已有的录制库中找到最相似的演示，作为参考加速新任务的创建。
这个过程本质上是一个多模态语义搜索——跨文字描述和截图内容进行匹配，找出"历史上很像现在这个场景的操作序列"。
3.5 模型使用全景图
总结起来，OpenAdapt 中模型的角色是"议会 + 顾问"，而不是"司机"：
| 场景 | 模型参与方式 | 是否阻塞 |
|---|---|---|
| 健康回放 | 不调用 | - |
| 回放失败 | 生成候选修复，人审核 | 是，暂停等人 |
| UI 定位 | 视觉模型做检测，结果作为信号输入 | 否，离线或编译时完成 |
| 关键决策 | 多模型共识投票 | 是，等投票结果 |
| 新任务匹配 | 检索相似演示 | 否，辅助创建 |
这就是 OpenAdapt 的 AI-First 哲学：让确定性路径跑得最快，让模型守在最需要判断力的分岔口。
四、多表面适配
OpenAdapt 支持四类运行表面，每种表面的可用信号源不同：
| 表面 | 最强信号 | 成熟度 |
|---|---|---|
| Web (Chromium) | DOM + 可访问性树 | Beta，可生产验证 |
| 原生桌面 (Win/Mac/Linux) | UI Automation / AT-SPI | 客户侧可控 |
| 远程桌面 (RDP) | 外部像素 + OCR + 地标 | 客户侧可控 |
| Citrix / VDI | ICA/HDX 外部像素 | 部署级验证 |
远程桌面和 VDI 场景是 OpenAdapt 的差异化优势——它不需要在远程机器上安装任何软件，通过外部像素分析完成定位和验证。
五、不足与关注点
5.1 编译成功率依赖信号质量
如果目标应用没有可访问性树、DOM 结构扁平化严重、或者截图纹理稀少（纯白界面上的白色按钮），编译阶段的多信号融合会退化为纯坐标回退，稳定性大打折扣。老旧 Windows 应用、定制化框架写的界面往往是重灾区。
5.2 工作流迁移成本
同一个工作流从 Chrome 迁移到 Edge 可能无法直接运行，因为浏览器内核差异导致 DOM 结构不完全一致。跨版本迁移（如 ERP 系统升级后界面微调）同样需要重新编译或触发修复。这不是缺陷，而是"确定性"的代价——任何结构变化都必须被显式感知和处理。
5.3 生态仍在早期
GitHub 约 1.6k Star，社区规模有限，中文资料极少。官方文档在快速迭代中，部分子包（如 consilium、retrieval）尚处于早期。Beta 阶段意味着接口和行为可能变化。
5.4 修复路径依赖人
受控修复模式虽然安全，但在高频变化的界面上会产生大量审核任务。如果你想用它自动化 50 个内部系统，每个系统每周改一次界面，那你可能每周要审核 50 次。这不适合"无人值守"但界面频繁变更的场景。
六、总结
OpenAdapt 不是 UIPath 的平替，也不是 AutoGPT 的 GUI 版本。它走的是一条折中线：在确定性执行和模型智能之间划出明确边界。 健康路径拼速度和安全，模型路径拼判断和适应性。
如果你面对的是关键业务场景（准确率要求 99.9%+ 且涉及资金/合规/医疗数据），OpenAdapt 的受控修复 + 效果验证体系比单纯调用 LLM Agent 更值得评估。如果你的场景是"随便点点，错了也无所谓"，那直接用 Claude Computer Use 可能更省事。
这是有意为之的选择，不是技术做不到——毕竟让模型接管全流程远比工程化地约束模型更难。