夜雨聆风
昨晚我在手机上瞄了一眼：Codex 还在我那台 Mac 上跑。屏幕已经锁了，它还在“代操作”。
我第一反应不是“真爽”，而是一个老程序员的条件反射：真正危险的不是 Agent 做不出来，而是它在你锁屏后做出来了、做错了，你第二天还没人能复盘。
如果你们也准备把 Computer Use（代操作）这类能力接进真实工作流，这篇你先收下——我把它拆成一个你能执行的清单。
阅读地图（先看这 5 个点）
1) 这次到底改变了什么：从“值守”到“无人值守”
2) 为什么风险会被放大：责任/审计/回滚断层
3) 上线前 7 条护栏清单（可照抄）
4) 最小可控试点流程：先可控，再扩面
5) 最常见翻车点与补救：复盘材料、止损与禁区
一句话说清楚：Codex 锁屏远程 Computer Use 是什么？
Computer Use 不是“写代码更快”，而是 Agent 能看屏幕、点鼠标、打字，替你完成一段 UI 操作。
而“锁屏远程”这一步，最关键的变化在于：它把很多人的使用形态从 “人盯着它点” 推到了 “人不在它也能继续跑”。
能力上看像是“更方便了”；运维上看，其实是控制回路被拿掉了——你得用制度/门禁把回路补回来。
官方口径（只写你能确认的事实）
• OpenAI 的官方更新与文档把这类能力描述为：在满足条件的情况下，Mac 锁屏后仍可继续 remote computer use。
• 该能力存在资格/区域限制等边界（不要默认“所有人都能用”）。
• 官方强调的前提之一是：主机需要保持在线/可用（否则“远程继续跑”无从谈起）。
（更细的启用流程与 UI 以官方为准；这篇重点讲“上线前护栏”。）
什么时候适合先试点？什么时候应该先禁用？
一句话建议：先从“低风险、可回滚、可验证”的任务试点；凡是“不可逆 + 影响外部/生产/资金/客户数据”的场景，没有护栏就先禁用。
你可以粗暴地按两类切：
• 适合先试点：整理材料、跑测试、生成草稿、批量 UI 重复点击（且有回滚/可验证）
• 建议先禁用：付款/转账、改权限、发布到生产、删除云资源、对外发送邮件/IM、批量导出敏感数据
如果你只能做一件事：最小护栏是什么？
如果你现在只能补一件事，我建议优先补这三个“最小闭环”：
1.高风险动作必须人工审批（不可逆动作先停下来）
2.全量审计日志（第二天能复盘）
3.回滚点（出了事能止损）
其它护栏都重要，但这三个能把事故从“不可控”拉回“可控”。
这次到底改变了什么：从“值守”到“无人值守”
很多人第一次玩 Computer Use，心智模型是这样的：
• 我坐在屏幕前，看它点错了就打断
• 我看到它要做危险动作（删库/付款/发邮件）就阻止
• 我看完结果，顺手把输出复制到别处
这叫“值守”。值守本身就是一层极强的护栏。
当你允许它在锁屏后继续跑，事情会变成：
• 它能在你不盯着时继续做更多步
• 错误发现从“秒级”变成“小时级/隔天级”
• 风险从“单次误点”变成“连续误操作 + 扩散”
这就是为什么我说：这不是一个新功能，是一个新运维形态。
我踩到的那个坑：翻车通常不是模型，是“复盘材料缺失”
我见过太多自动化翻车，复盘时第一句话永远是：
“我也不知道它刚才点了什么。”
你可以把它理解为：当 Agent 开始代操作，你需要的不是“更强模型”，而是三样东西：
1.审计：它做过什么？按什么顺序？关键输入输出是什么？
2.回滚：出了事，能不能止损，能不能回到安全状态？
3.责任：谁审批、谁值守、谁复盘？
少任何一样，事故就会从“工程问题”变成“政治问题”。
为什么风险会被放大：责任/审计/回滚断层
核心机制很简单：
• 值守 = 人类实时纠错（强反馈回路）q
• 锁屏远程 = 反馈回路变弱（延迟发现/无人打断）
• 无人值守要成立，你必须用“门禁 + 审计 + 回滚 + 值守制度”替代人类盯屏
【图片 2：trend or mechanism】
所以你会发现：Computer Use 越强，团队越不能省治理。
上线前 7 条护栏清单（可照抄）
下面这 7 条，你可以直接复制进团队 wiki / 试点评审表里。它们不是“最佳实践”，而是“最低生存线”。
1.权限 allow/deny（先写禁区）
• 明确列出“绝对禁止”的动作：付款、提交工单到生产、删除云资源、改权限、导出敏感数据……
• 对“允许”的动作做 allowlist：只允许在某些 app、某些目录、某些账号下操作。
• 白话解释：allowlist 是“只准做清单里的事”；比“黑名单”更安全。
高风险 denylist（示例，按你们业务裁剪）：
• 资金类：付款、转账、开通付费、绑定支付方式
• 权限类：改角色/权限、导出密钥、打开密码管理器
• 生产类：发布到生产、删除云资源、改防火墙/网关规则
• 外联类：对外发送邮件/IM、提交外部表单、上传客户数据
• 数据类：批量导出、下载敏感文件、复制大量内容到剪贴板
1.高风险动作必须人工审批（两人规则更稳）
• 所有不可逆动作：删改生产数据、发布、转账、发送外部邮件、改权限……必须停下来等人点“同意”。
• 你要的不是“更聪明的 Agent”，是“更清晰的责任边界”。
1.成本/额度/超限熔断
• 给任务设预算（时间/调用/次数），超限就停。
• 夜间无人值守尤其要有“熔断”：宁可停，也别悄悄跑一晚上。
• 白话解释：熔断就是“超过阈值自动断电”，避免小问题滚成大事故/大账单。
1.全量审计日志（可复盘）
• 至少要能回答三件事：它做了哪些关键动作、每步看到什么、输出写到哪里。
• 复盘不是为了追责，是为了止损与改规则。
最小审计 schema（示例，够用就行）：
| 字段 | 说明 | 例子 |
|---|---|---|
| runid | 本次运行唯一 ID | run2026-05-25_2215 |
| actor | 谁触发/审批 | agent / human:alice |
| timestamp | 时间戳 | 2026-05-25 22:16:04 |
| app/window | 操作对象 | browser / terminal / mail |
| eventtype | 事件类型 | view / click / type / filewrite / send |
| target | 关键目标 | config.yaml / prod-console |
| intent | 这一步想达成什么 | “更新配置并提交” |
| diff/summary | 结果摘要 | “修改 3 行，保存成功” |
| artifactpath | 输出落点 | workspace/output/run42/ |
| rollbackref | 回滚点引用 | git:abc123 / snapshot:rp001 |
你不一定一次做全，但至少要做到：可定位（知道改了哪）+ 可复现（知道怎么发生）+ 可止损（知道怎么回滚）。
1.回滚点（git/snapshot）
• 任何会改变状态的工作，都要有回滚点：代码有 git，配置有版本，数据有快照。
• 没回滚点就别上“无人值守”。
1.数据与密钥隔离（最小暴露）
• 用专门的账号/专门的机器/专门的工作区跑试点。
• 密钥不要散落在桌面与剪贴板；能不用就不用。
1.值守与告警（夜间策略）
• “锁屏远程”不等于“没人管”：你仍然需要值守人、告警阈值、夜间策略（比如只跑低风险任务）。
• 一句话：能跑 ≠ 该跑。
【图片 3：workflow】
最小可控试点流程：先可控，再扩面
如果你要把它从“个人玩具”推进到“团队试点”，我建议按这个顺序来：
1.先选任务，不选功能：只选“低风险、可回滚、可验证”的任务（比如整理材料、跑测试、生成草稿、做 UI 重复点击）。
2.先隔离环境：专用机器/专用账号/专用目录；不要一上来就进生产账号和主力环境。
3.先写禁区与审批点：把“必须停下来等人确认”的动作写清楚（第 1、2 条护栏）。
4.先把审计打通：先能复盘，再谈提效（第 4 条护栏）。
5.先做 1 周试点复盘：每天看一次日志与失败样例，反向把规则写得更严格。
6.再扩大范围：能稳定跑 3 个低风险任务，再考虑加新任务。
你会发现：这个流程最大的价值，是把“试试看”变成“可控试点”。
最常见翻车点与补救：复盘材料、止损与禁区
【图片 4：scenario】
1.越权事故：Agent 顺手点进了不该碰的系统/账号
• 补救：更强的禁区 + 更严格的账号隔离。
1.不可逆事故：一键删除/发布/发送外部消息
• 补救：所有不可逆动作强制人工审批 + 回滚点。
1.不可复盘事故：出了问题，但你不知道它做过什么
• 补救：把审计作为第一优先级；没有审计就不做无人值守。
我的判断：Computer Use 越强，治理越要前置
我不反对尝鲜，甚至我觉得你应该早点试：越早试，你越早知道“这东西到底能不能变成生产能力”。
但我非常反对一种常见做法：把它当成一个“更强自动化脚本”，直接丢进生产里跑。
Computer Use 这种能力，一旦进入锁屏远程/无人值守形态，你真正要建设的不是“提示词库”，而是：
• 权限边界（能做/不能做）
• 审计与复盘（做过什么）
• 回滚与止损（出事怎么办）
• 值守与升级（谁负责）
你把这四件事补齐，Computer Use 才可能从“惊艳 demo”变成“可控生产能力”。
结尾：你们团队最难落地的是哪条护栏？
如果你已经在团队里推进过类似能力，或者你最担心的是某一种事故类型，欢迎留言说说：
• 你们最难落地的是哪条护栏？为什么？
• 你们最怕的“背锅事故”是什么？