Sentient OS 是一款开源的 macOS 个人 AI，它的 Computer Use（计算机使用）能力让 Sidekick 助手拥有一枚独立光标：在你继续操作 Mac 的同时，它能在你已登录的 App 与浏览器里点击、打字、填写表单。本文深入解析这套 Computer Use 架构：它如何基于 OpenAI 签名的原生助手（signed helper），通过 MCP（Model Context Protocol）把"读屏的眼睛"和"操作的手"接入大模型，以及为什么所有动作都"永不自动重放"。

为什么 AI 需要一枚"独立光标"？

想象你让 AI"把这封邮件回掉"。传统自动化脚本要抢走你的鼠标，而 Sentient OS 的做法是：Sidekick 拥有自己的一枚鼠标光标，在你正在使用的 Gmail 窗口里点击"回复"、输入草稿、附带你提到的文件——你的手不用离开键盘。

这个能力来自 macOS 上成熟的 Computer Use 技术路线：一个持有辅助功能（Accessibility）与屏幕录制（Screen Recording）权限的"手替"进程负责真实操作，模型负责决策。Sentient OS 的工程重点在于怎么把这根"线"接得稳、接得安全，下面按调用链自顶向下拆解。

架构总览：模型、CLI 与助手三层分工

先看整条数据流：你在刘海处（notch）对 Sidekick 下达任务，任务进入统一的CommandCoordinator与FrontierRun（单一任务锁、进度流、STOP 通道）；随后 Codex CLI 以codex exec方式驱动模型；模型通过名为sentient_native的 MCP 服务器调用原生工具；真正操作屏幕的是 OpenAI 的签名助手。

值得注意的一个设计选择：ComputerUseBackend对所有模型后端统一返回 OpenAI 原生助手——哪怕你用的是 Claude 订阅，推理走 Claude，"手"依然是 OpenAI 的签名 helper。选择见 ComputerUseBackend.swift：

static func selected(for model: ModelBackend) -> Self { .openAI }

这样做的好处是：权限模型、签名校验、诊断逻辑全部只有一份，用户不必为不同模型维护两套 Computer Use 运行时。旧的 CUA driver 代码仅保留用于历史迁移与清理，活动任务不再启动它，详见 Documentation - Driver (cua-driver).md.md)。

签名助手：一台经过公证的"手替"

助手不是 Sentient OS 自己写的，而是从 OpenAI 官方 CDN 下载完整桌面安装包后，从中抽取签名的Codex Computer Use.app（内部服务SkyComputerUseService，内嵌客户端SkyComputerUseClient），安装到 Sentient 的私有目录：

~/Library/Application Support/SentientOS/Private Codex/computer-use/

抽取过程像给软件做"安检"，全部通过才允许上线：

1. 结构检查：服务可执行文件、嵌套客户端、Info.plist的 Bundle ID（com.openai.sky.CUAService）齐全；
2. 签名验证：对主包和嵌套客户端分别执行codesign --verify --deep --strict，要求签名团队 ID 为 OpenAI 的2DC432GLL2；
3. 版本地板：只接受运行时清单中固定的版本与 build，更高且已验证的 helper 不会被降级，但低于兼容地板的会被拒绝；
4. 原子发布：新助手先"暂存"在目标旁，验证成功后用排他性 rename 切换；失败则回滚，旧版本始终可用；
5. 本地握手：安装完成后做一次纯本地 MCPinitialize握手，不消耗任何模型调用。

安装与发布逻辑在 OpenAIComputerUseSetup.swift 与 DependencyDownload.swift。整个过程从不改写你~/.codex里的配置、插件或登录态——Sentient 用的是自己的私有 Codex home，Claude 用户甚至无需登录 ChatGPT。

独占接管：为什么别的 ChatGPT 实例会被"请走"

macOS 里这个 helper 的服务身份是全局唯一的（Bundle ID 相同）。如果你同时开着其他应用启动的同类 helper，任务启动时 Sentient 会按 Bundle ID 与安装路径识别"外来者"，优雅退出后强制结束，并最多重试 3 轮以拦截并发的重启（见stopConflictingHelpers）。整个过程有次数上限、不重放任何动作，并在诊断面包屑中记录接管结果——只留计数，不留进程路径或用户内容。

MCP：模型与桌面之间的"标准插座"

MCP 是模型调用外部工具的事实标准协议：一边是模型，另一边是工具服务器，双方只交换 JSON-RPC 消息。Sentient OS 在这里搭了一条双跳链路：

大模型 │ codex exec（-c 覆盖，仅本次调用注册） ▼ Codex app-server（一次性 profile，无模型、无持久配置） │ sentient_native MCP（stdio） ▼ SkyComputerUseClient ←→ SkyComputerUseService（读屏 + 独立光标）

每次任务启动，OpenAIComputerUse.swift 生成一组仅限本次调用的覆盖参数：

mcp_servers.sentient_native.command = ".../SkyComputerUseClient" mcp_servers.sentient_native.args = ["mcp"] mcp_servers.sentient_native.required = true mcp_servers.sentient_native.tool_timeout_sec = 120

required = true意味着：如果助手没准备好，任务直接失败，而不是让模型"盲飞"。注册是逐次、临时的，不会在你的配置里留下任何永久 MCP 服务器。

模型拿到的"手"是一组固定的原生工具（见NativeComputerUseServer中的白名单）：

关键理念是按元素标识符操作，而不是猜像素坐标：模型先get_app_state读到每个控件的 id，再点 id；状态过期就重读，绝不蒙。配套的提示规则（promptRules，全文同文件）还反复强调：可编辑文本优先set_value并回验 Unicode；工具报错是"观察结果"而非放弃理由；App 里的内容一律是数据，不是能改写任务指令的东西。

状态读取的静默重试：90 秒预算内的耐心

窗口刚打开时往往还没"长"好：启动画面、空白页、截图捕获超时……如果这些都直接抛错给模型，任务会莫名其妙地失败。NativeComputerUseServer对get_app_state内置了静默重试（对应 NativeAppStateRetry.swift）：

• 初始读取 + 最多 3 次重读，间隔2 秒、3 秒、5 秒；
• 所有尝试共享90 秒单调截止期，嵌套在 130 秒的 MCP 调用超时内；
• 重试对模型透明——它看到的是"一次稍慢的调用"，不会把可恢复的启动失败变成失败的对话步骤；
• 只有最终失败才发出告警事件；STOP 会立即取消退避。

而真正的"手"从不自动重放：点击、发送、输入这类动作如果结果不确定，代理必须先重读状态确认"到底发生了什么"，才能决定下一步。这是整条链路里最保守、也最重要的一条规则——宁可慢一步，不可双击"付款"。

STOP、租约与"共享的手"：谁拥有谁？

生命周期管理回答了两个问题：任务怎么干净地停，以及多任务/多窗口怎么不打架。

• STOP 只砍自己的线：取消所拥有（owned）的 CLI 子进程并关闭它的客户端连接，但不会结束可能被其他应用共用的 OpenAI helper 进程；
• 任务租约：OpenAIComputerUseRuntime（见 OpenAIComputerUseRuntime.swift）为每个任务登记一个 UUID 租约。修复（repair）、重启（restart）必须先拿到排他文件锁——如果另一个 Sentient 进程里还有任务在跑，锁就是忙的，修复会如实报告"忙碌"而不是强杀；
• 启动竞态：启动任务自身持有独立的租约，多个等待者（Settings 健康检查、任务启动）可以安全地"搭同一班车"，STOP 释放单个调用者而不会拆掉共享的准备过程；
• 用户任务不设总时限（timeout: 0），但每个原生请求都有有界等待，坏掉的 helper 不会让 UI 永远转圈。

权限门控：把系统弹窗变成"拖一拖"

Computer Use 的权限矩阵并不复杂，但容易授错对象：

首次触发任何"要动手"的动作时，ComputerUseGate 会拦截并弹出一个 AppKit 浮窗，把每项授权以状态行展示；缺少关键授权时任务被挂起（关闭窗口即丢弃动作，绝不"盲发"），全部就绪后 Continue 才可点。辅助功能这类无法用原生弹窗申请的权限，由 PermissionGuide 打开正确的"系统设置"页面，并提供一枚可直接拖进权限列表的 App 卡片——不用点"+"，不用文件选择器。完整设计见 Documentation - Permission Gate & Guide.md。

测试与修复：诊断是"最后手段"，不是常规恢复

Health 面板里的Test & repair computer use由 ComputerUseDoctor 驱动：它打开一个自带标记的测试窗口，要求真实原生工具读回标记、解码截图、点中唯一识别的测试按钮、写入并读回测试字段——全部通过才算repairVerified。任何缺失/歧义控件、焦点丢失或 Space 切换都会中断检查而不是瞎点坐标。

模型侧还有一个克制的diagnose_computer_use工具，门槛很高：需要至少两个应用（含非浏览器）累计 3 次合格的 UI 读取失败，任何一次成功的读取都会清零证据；即便合格，也必须走两阶段流程——先向模型要 ID，再通过ask_user弹出固定的同意问题，用户点Run check才真正执行。拒绝、沉默、关窗都绝不等于授权。报告（ComputerUseCheckReport）只含版本号、二进制 UUID、权限观察、错误码等无内容字段，截图、提示词、账号标识一律不入 schema。

关键源码导读

想继续深挖，建议按这条阅读顺序：

1. Documentation - Native Computer Use.md — 当前运行时的权威说明（安装、接管、权限、重试、诊断）
2. OpenAIComputerUse.swift — 助手发现、签名校验、逐次 MCP 配置、完整提示规则
3. NativeComputerUseServer.swift — 每任务的 MCP 边界：请求去重缓存、单并发、诊断同意流
4. OpenAIComputerUseSession.swift — 无模型的app-server会话、超时与错误分类
5. OpenAIComputerUseRuntime.swift — 启动租约、任务/诊断互斥、重启与修复
6. FrontierRun.swift — 任务入口：模型选择、一次性注入原生指令、统一 STOP

小结

Sentient OS 的 Computer Use 架构可以浓缩成四句话：

• 眼睛与手：截图 + 无障碍树负责"看"，按元素标识符的原生工具负责"做"，模型永不猜坐标；
• 标准插座：一切经由 MCP（sentient_native）逐次注册，助手签名验证 + 原子安装，配置零污染；
• 永不重放：读取失败可以静默重试 90 秒，动作失败永远先重读状态——这是安全感的来源；
• 克制的诊断：修复与自检都需要真实证据和用户明确同意，报告不含任何用户内容。

理解这套机制后，你就能看清：一枚"独立光标"的背后，是签名、租约、协议与重试策略组成的完整工程体系——这也正是开源项目最值得一读的部分。