在 Windows 上用 Codex CLI 调用 Computer Use，却卡在桌面端装不上，尤其是 Windows Server 环境。文章先厘清 CLI 与桌面端的分工，再梳理应用商店缺失、系统更新被禁等常见原因，给出从检查 Appx 包、修复依赖服务到规避高风险脚本的排查清单，并对比三条可行路线。
把图形界面操作接进命令行工作流，是不少人想试的组合：在终端里描述任务，让模型自己看屏幕、点按钮、填表单。但真到 Windows 上动手，第一道坎往往不是模型能力，而是桌面端装不上——系统是 Server 版，应用商店默认不存在，双击安装包要么没反应，要么直接提示不支持当前系统。
这类问题的关键，是先分清「命令行」和「桌面端」各自负责什么。分不清这一点，就会一直在 CLI 的参数和配置里找答案，而真正的缺口在系统层面。
CLI 只是入口，屏幕操作靠桌面端
把调用链拆开看会更清楚：
- 在 CLI 里发起一个需要操作图形界面的任务；
- CLI 把意图交给本地桌面端进程；
- 桌面端负责截屏、识别控件、注入鼠标键盘事件；
- 结果回传给 CLI，再由模型决定下一步。
也就是说，CLI 里的 Computer Use 更像一个遥控器。桌面端没装或没跑起来，遥控器按下去也没有接收方。所以「装不上 app 就只能用 CLI」这个前提本身就走不通——两者不是替代关系，而是上下游关系。想绕开桌面端直接让 CLI 接管屏幕，目前没有可行的做法。
装不上的五类原因
先别急着认定「Server 版就是不支持」，同一个报错背后可能是完全不同的原因：
- 系统本身不带商店：Windows Server 默认不预装 Microsoft Store 以及它依赖的一整套 Appx 框架，这是设计如此，不是故障。
- 系统更新被关掉：商店和 Appx 部署依赖 Windows Update、AppXSvc、ClipSVC、InstallService 等服务，其中任何一个被禁用，安装都会静默失败。
- 组策略或精简镜像：有人用策略项直接屏蔽商店，或者用了第三方精简镜像，组件在打包时就被删掉了。
- 安装包形态不匹配：
.msix/.msixbundle需要系统里已有 App Installer（应用安装程序），缺了它双击没反应。 - 权限与账户：非管理员运行、需要交互式登录会话、区域与账户类型限制。
顺带一提，判断原因前要先弄清「装不上」具体是哪一步：是下载不下来、安装器拒绝运行，还是装完启动闪退。三种现象对应的排查方向完全不同。
按顺序排查的检查清单
以下命令在管理员身份的 PowerShell 里执行，仅作示例，实际参数请按自己的系统调整。
第一步：确认桌面端和商店到底在不在
Get-AppxPackage -Name *Store* | Select-Object Name, Version, Status
Get-AppxPackage -AllUsers | Where-Object { $_.Name -like "*Desktop*" }
如果第二条查不到任何结果，说明桌面端确实没装上，问题出在系统而不是 CLI。
第二步：尝试重新注册商店
wsreset -i
这条命令会重走一遍商店的注册流程。如果提示找不到命令，或者执行后毫无变化，基本可以判定商店组件本身缺失，需要先补齐组件而不是反复重试。
第三步：检查依赖服务
Get-Service wuauserv, AppXSvc, ClipSVC, InstallService, TokenBroker |
Select-Object Name, Status, StartType
Stopped 且 StartType 为 Disabled 的，先把启动类型改回手动或自动再启动。更新服务长期被关掉是最常见的隐形原因，很多人以为和 Server 有关，实际只是镜像出厂就把更新掐了。
第四步：检查策略与镜像痕迹
reg query "HKLM\SOFTWARE\Policies\Microsoft\WindowsStore"
Get-ComputerInfo | Select-Object WindowsProductName, OsBuildNumber
策略里若有屏蔽商店的项，先移除再重启。同时确认系统构建号，避免在过于陈旧的构建上折腾。
第五步：看部署日志，别靠猜
Get-WinEvent -LogName "Microsoft-Windows-AppXDeploymentServer/Operational" -MaxEvents 20 |
Select-Object TimeCreated, Id, Message
安装失败的具体错误码都在这里，比反复重装高效得多。
第六步：修复系统组件
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
组件库损坏时，前几步都会反复失败，这一步用来排除系统文件层面的问题。
三条路线怎么选
| 路线 | 适合场景 | 代价与风险 |
|---|---|---|
| 修复本机商店与更新 | 系统是正常安装、只是更新被关 | 成本最低，但需要重启和逐项排查 |
| 手动部署商店组件 | Server 版、愿意承担维护成本 | 非官方支持组合，累积更新后可能失效 |
| 换一台能装桌面端的机器 | 只想尽快验证效果 | 需要额外设备或远程环境 |
社区里流传的一些「辅助安装」脚本本质上就是帮你把商店和依赖包塞进 Server 系统。它们确实能解决问题，但来源和内容往往不可验证，会写注册表、装一堆依赖。要用的话至少先通读脚本、校验哈希，并在快照或虚拟机里先跑一遍。更稳妥的做法是换一台普通 Windows 客户端来验证功能，本机继续当开发机。
如果这台机器本来就是长期开着的服务机，另一个思路是把「需要操作图形界面」这一段整体搬到一台能正常装桌面端、且长期在线的机器上，本地只保留 CLI 连接过去。比如按月租用一台放在机房的 Mac mini，远程连上去运行，本地环境就不必再和商店组件较劲了。
几个容易踩的坑
- 装完能用不等于长期可用：Server 加商店不是官方支持的组合，系统更新后组件失效是常见现象，重要任务别只押在这一台机器上。
- 远程会话会打断自动操作：锁屏、UAC 弹窗、切换用户都会让屏幕操作中断，跑长任务前先把电源与锁屏策略调好。
- 分辨率与缩放会影响坐标：多显示器、125%/150% 缩放容易导致点击位置偏移，建议固定单屏和 100% 缩放再测试。
- 权限要一次给够：屏幕捕获和模拟输入需要的权限如果没授予，表现往往是「能启动但什么都不做」。
- 版本与系统要求变化快：功能开关、安装包形态、最低系统版本都可能调整，遇到报错请以官方最新说明为准。
小结
Codex CLI 里的 Computer Use 不是独立能力，它依赖本地桌面端完成实际的屏幕操作，所以「只装 CLI」这条路走不通。遇到装不上，先判断卡在哪一步，再按「查包 → 重注册 → 查服务 → 查策略 → 读日志 → 修组件」的顺序排查，多数问题能在前三步定位。如果本机是 Server 且不方便长期维护，把桌面端放到另一台能正常安装、长期在线的机器上，通常比反复修系统更省事。