技术思考问题5：Computer Use 能点所有按钮，为何不能直接接管生产系统？

反演思维与安全边际：Computer Use 的边界架构

会点鼠标不难，难的是让它在边界内做对事

[读者] 正在把 Computer Use / 浏览器自动化接入业务流程的架构师
[痛点] 模型已经会操作 UI，但写操作的错与越权没人敢签字
[现在读] 视觉执行器正从演示走向生产写路径，防线必须提前修
[读完] 会用反演思维倒推防线、用安全边际约束不可逆动作

[旧方案] 人工登录供应商后台导表、核对、标注
    |
    v
[新需求] 让执行器直接处理差异单，而不只是搬运数据
    |
    v
[冲突] 视觉执行器没有业务授权概念，也没有事务语义
    |
    v
[后果] 误退、重复处理、越权修改，且事后无法归因

我是老李，在一家供应链 SaaS 公司做平台架构。我们有一块“渠道对账”业务：客户把账单差异提上来，运营到供应商的旧后台里逐条核对、标注、发起差异处理。那个后台是供应商的，接口没开放，账号只有一个。

任务是让这条链路自动跑起来。团队第一反应是 Computer Use——模型看得懂屏幕、点得动按钮，供应商不开接口也能干活，看上去是绕开集成成本的捷径。演示确实漂亮：登录、翻页、导表，一气呵成。

但上线评审会上，财务问了一句：如果它把一条不该退的单退了，你怎么知道、怎么拦、怎么恢复？我们答不上来。那套演示里，没有一条防线是“假设它已经点错”来设计的——全都在假设它点得对。

那么，能不能一边放开自动化，一边让不可逆动作不失控？

如果必须在“能操作 UI”和“被业务授权”之间挑一个当前提，你挑哪个？

挑错了——把屏幕上“看起来成功”当成业务成功——到月底你打算怎么对账？

01、故事

运营每天早上第一件事是登录供应商后台，选租户、拉差异清单、导出 Excel，再回我们的系统逐条比对，然后在供应商后台把差异单标成“已处理”。三个运营轮着做，一天里大半的产能耗在切换系统和搬运数据上。

自动化这件事我们分了两步。第一步是只读：把差异清单抓回来落到数据仓库，运营不用再导表。这一步很早就用浏览器自动化做掉了，一直很稳——因为它错了，重来一次就行。

第二步才是变化所在：业务希望执行器直接“处理”差异单，也就是在供应商后台把单据状态改掉。这一步动了钱。任务是让机器走完这条写路径，并且在出问题时能被人接住。

冲突从这一刻开始。同一双手，点“导出”和点“标记已处理”，在模型眼里几乎没有差别——都是找控件、点下去、等下一页。可在业务上，一个错了是重导一次，一个错了要在月底的账上找回来，还得跟客户解释。

我们的第一版工具选择，几乎是本能地选了最“通用”的那个执行器。这恰恰是后面所有问题的起点。

导表错可重来
改单错要赔钱
同一双手点下去
后果隔着一条河

02、问题

旧方案是人工加手工导出。它的问题不是慢，而是“没有留下任何可以被程序判断的状态”——谁在什么时候改了哪条单，只存在于某个人的记忆里。

业务影响有三层：差错只在月末对账时暴露；越权操作无法归因到具体的人和具体的任务；一旦执行器出错，恢复成本远高于它省下的工时。

技术表现集中在四点：

• 视觉判定与业务真相脱节。点击成功、toast 弹出、按钮消失，都只是 UI 反馈，不等于业务态变更。
• 重试放大重复写入。只读路径重试是安全的，写路径重试是危险的。
• 执行器复用共享的“超人账号”。会话失效、权限回收、并发冲突都会在夜里集中爆发，而且审计里分不清是谁干的。
• 审计只剩一行“任务成功”。没有身份、没有租户、没有幂等键、没有前后截图。

可验证的完成标准（我把它写进了验收）：

1. 任一写操作都能在审计链中还原：身份、租户、单号、动作、幂等键、操作前后截图。
2. 相同幂等键重复提交，业务侧结果不变。
3. 不可逆动作全部有审批记录，且审批发生在执行之前。
4. 四个指标可被采集：误操作率、任务完成率、人工接管率、回滚成功率。至于目标值定多少，要靠灰度期采样后定，不靠拍脑袋。

只读错了重来
写入错了成账
标准要能验证
不能靠感觉收工

03、原理

只讲这一篇需要的两个模型。

反演思维：不要问“怎么让它别出错”，而要问“假设它已经错了，我怎么知道、怎么拦、怎么退”。设计顺序因此被倒过来：先设计证据链与回滚，再设计执行路径。落到这里，就是先回答“错了如何被发现和复原”，再决定“用什么工具去点”。

安全边际：给不可逆动作设置权限、审批与恢复余量。注意，安全边际不提高成功率，它降低单次失败的代价。一个动作如果不可逆，就要么给它加审批，把决策权交回人；要么把失败窗口缩到“一定能被独立回读出来”。

反直觉判断：Computer Use 的可靠性上限不由模型能力决定，而由动作的可逆性决定。同一个模型，在只读路径上可以很激进，在写路径上必须被约束到几乎笨拙。我们后来的工具分级，本质就是沿“可逆性”这条轴切开的。

反直觉判断：视觉置信度高，不等于业务成功。置信度回答的是“我看清了吗”，而故障往往发生在“我看清了，但我说了不算”——没有权限、会话过期、请求被前置校验拦下、异步状态还没落库。

先假设已经点错
再倒推需要什么
边际不在成功率
在失败的价格

04、架构

[输入] 差异处理任务（租户 + 单号 + 动作意图）
    |
    v
[模块] 编排器：工具分级路由 + 策略校验 + 审批闸门
    |
    v
[数据/状态] 幂等登记表 + 任务状态机 + 审计流水（含截图）
    |
    v
[处理] 执行器：API/MCP → 结构化选择器 → 视觉兜底
    |
    v
[输出] 业务系统变更 + 回读证据 + 可补偿的逆操作

边界说明：

• 编排器是唯一能发起写动作的入口，执行器不允许自己决定“下一步做什么”。
• 工具按可逆性排序：API/MCP 最优先，有事务语义和错误码；其次是结构化选择器，有 DOM 契约；视觉兜底只用于没有稳定结构、且动作只读或可逆的场景。
• 审批闸门只拦不可逆动作清单里的动作，不做全量审批，否则吞吐会被拖垮。
• 回读数据源必须独立于本次会话：能读列表就读列表，能读对账文件就读文件，绝不读“刚才那个页面自己说自己成功了”。

收益：写动作有唯一入口，可归因、可去重、可回读、可补偿。

代价：多了一次回读往返，多了一张幂等登记表，多了一个审批队列；工具分级也抬高了实现复杂度——同一条业务动作要准备两到三种执行路径。

适用条件：目标系统没有稳定 API，但业务语义清晰且结果可回读。如果目标系统本身提供了带事务语义和幂等能力的 API，直接用它，不要为了“通用”退回视觉执行。

入口只留一个
路径按可逆排
视觉只管去看
不管拍板定案

05、实战一次

环境与版本：Python 3.11、Playwright（Python 版）。Playwright 的几项核心能力正好咬合这个场景——自动等待、面向用户可见行为的断言、浏览器上下文隔离、Trace Viewer，这些都在官方 Introduction 里被列为它要解决的问题。

依赖安装：

python -m venv .venv && source .venv/bin/activate
pip install playwright pyyaml
python -m playwright install chromium

配置：

# config.yaml
base_url: "https://vendor.example.com"
tenant: "acme"
identity: "svc-recon-acme"        # 独立身份，不复用运营账号
allow_visual_write: false         # 写路径禁止纯视觉判定
tool_ladder: ["api", "mcp", "browser-structured", "computer-use"]
readback: ["list", "detail"]      # 写后回读来源，独立于本次会话
approval: ["refund", "delete", "finalize_status"]
audit_dir: "./audit"

核心实现（V1：只读全开 + 写路径窄口 + 本地文件占位幂等）：

# reconcile_v1.py
import hashlib
import pathlib

import yaml
from playwright.sync_api import sync_playwright, expect

CFG = yaml.safe_load(open("config.yaml", encoding="utf-8"))
AUDIT = pathlib.Path(CFG["audit_dir"])
AUDIT.mkdir(exist_ok=True)
SUBMITTED = pathlib.Path("submitted")
SUBMITTED.mkdir(exist_ok=True)


def idem_key(task_id: str, bill_no: str, action: str) -> str:
    raw = f"{task_id}|{bill_no}|{action}".encode()
    return hashlib.sha256(raw).hexdigest()[:16]


def read_diffs(page):
    page.goto(f"{CFG['base_url']}/diff/list")
    page.get_by_role("button", name="查询").click()
    rows = page.locator("table#diff tbody tr")
    expect(rows.first).to_be_visible()
    out = []
    for i in range(rows.count()):
        r = rows.nth(i)
        out.append({
            "bill_no": r.locator("td[data-field=bill_no]").inner_text().strip(),
            "status": r.locator("td[data-field=status]").inner_text().strip(),
        })
    return out


def write_status(page, bill_no: str, key: str, action: str):
    marker = SUBMITTED / key
    if marker.exists():           # 注意：check-then-act，V1 的已知弱点
        return "skipped"
    row = page.locator(f"tr[data-bill='{bill_no}']")
    if row.get_attribute("data-status") != "PENDING":
        return "stale"
    page.screenshot(path=str(AUDIT / f"{key}-before.png"), full_page=True)
    row.get_by_role("button", name=action).click()
    page.get_by_role("dialog").get_by_role("button", name="确认").click()
    # 写后回读：以列表态为准，而不是以本次会话的反馈为准
    page.get_by_role("button", name="查询").click()
    expect(page.locator(f"tr[data-bill='{bill_no}']")).to_have_attribute(
        "data-status", "PROCESSED", timeout=15000
    )
    page.screenshot(path=str(AUDIT / f"{key}-after.png"), full_page=True)
    marker.write_text(key)
    return "done"


def main(task_id: str):
    with sync_playwright() as p:
        browser = p.chromium.launch(headless=True)
        ctx = browser.new_context(storage_state="auth.json", locale="zh-CN")
        ctx.tracing.start(screenshots=True, snapshots=True, sources=True)
        page = ctx.new_page()
        for item in read_diffs(page):
            if item["status"] != "待处理":
                continue
            key = idem_key(task_id, item["bill_no"], "markProcessed")
            print(item["bill_no"], write_status(page, item["bill_no"], key, "标记处理"))
        ctx.tracing.stop(path=str(AUDIT / f"{task_id}-trace.zip"))
        browser.close()


if __name__ == "__main__":
    main("T-20240917")

启动：

python reconcile_v1.py

示例输出（未在当前环境实测，以下为预期结果）：

{"task": "T-20240917", "read": 12, "done": 12, "skipped": 0, "stale": 0}

验证：

• 只读一致性：清单条数与页面一致，重复运行不产生副作用。
• 写路径回读：每条单在 audit/ 下都有 before/after 两张截图，且 after 截图里状态列已变为“已处理”。
• 幂等（V1 能力有限）：同一 key 连续调用第二次返回 skipped。
• 证据链：{task}-trace.zip 可以用 Trace Viewer 打开，回放每一步动作。

V1 跑通了，但它带着两个明确的伤口：本地文件做幂等是 check-then-act，并发下不成立；写后回读依赖 data-status，一旦供应商改版、结构没了，就只能退到视觉兜底——那正是下一章要出事的地方。

先让它跑起来
再逼它露破绽
能复现的证据
才算真正的结论

06、排查

排查一：同一条单被处理了两次

现象：灰度第二天，客户侧看到同一条差异单有两条处理记录，金额相同，时间相差不到两秒。

怀疑：页面双击，点击动作被重放。

检查：翻审计目录，发现两个不同 task_id 都生成了该单的 before 截图；再看进程，白天为了赶时间起了两个实例，共享同一个 submitted/ 目录。

证据：submitted/ 下该 key 的写入时间与两次点击时间完全吻合，但两次 marker.exists() 都返回 False——判断与写入之间没有任何互斥。

根因：本地文件占位是 check-then-act，不是幂等；而业务侧对同一单的状态变更没有唯一约束。重试和并发一起把这个窗口撑开了。

修复：幂等上移到编排器，用幂等登记表的唯一索引先占位、后执行；同一 key 抢不到占位就直接返回“已在处理中”，不再进入执行路径。

排查二：任务报成功，业务里状态没变

现象：某天一批单在日报里显示“完成”，但供应商后台列表里仍是“待处理”。

怀疑：异步落库延迟。

检查：看 after 截图，页面右下角有一个绿色 toast；但同一张截图的状态列仍然是“待处理”。

证据：这批单当天走的是视觉兜底路径——供应商当天改版，table#diff 的 data-field 属性没了，结构化选择器失效，编排器降级到截图识别；视觉判定把“出现绿色 toast”当成了成功。

根因：视觉路径没有业务态回读，把 UI 反馈当成了业务真相。

修复：所有写操作后强制回读，且回读数据源必须独立于本次会话（列表页重新查询、详情页、供应商对账文件三选一）。截图只作为证据留痕，不作为判定依据。

排查三：夜间跑批大面积“元素找不到”

现象：凌晨批次全部失败，报错都是等待元素超时。

怀疑：供应商页面改版。

检查：打开失败时刻的截图，右上角账号显示为共享运维号，页面上叠着一个“权限已变更，请重新登录”的弹窗。

证据：运维号当天下午做过权限回收，共享账号的会话在夜间失效。

根因：执行器复用共享的“超人账号”，会话生命周期不受编排器控制；而且共享身份导致审计无法归因到具体任务和租户。

修复：每个任务/租户使用独立服务身份，按租户作用域做白名单；会话失效即失败即告警，不做静默重试。

错误尝试： 在排查二之后，我们先把视觉置信度阈值从 0.6 提到了 0.9，以为“看得更准”就能消掉误判。为什么错：置信度管的是“我看清了吗”，而这两次故障一次来自并发抢占（同一动作被执行两次），一次来自“UI 反馈不等于业务态”。阈值再高也拦不住这两类问题；副作用却是低置信度的动作更多地落到人工，而我们当时连一个人工接管队列都没有。

先看证据再说
别先猜模型笨
根因不在阈值
在没人管边界

07、优化

V2 只做四件事，每一件都对应前面的一条根因。

根因一：check-then-act 的本地占位不是幂等。修改：幂等登记表加“先占位、后执行”。原因：唯一索引是原子的，抢不到就不执行，天然挡住并发与重试。新行为：同一 key 只会有一条执行记录。验证：手动同时起两个实例跑同一批单，业务侧只应出现一条处理记录。

根因二：把 UI 反馈当业务真相。修改：写后强制回读，回读来源独立于本次会话；视觉只作为证据。原因：UI 反馈由前端决定，业务态由后端决定，两者在网络异常、异步状态、权限拦截时必然分叉。新行为：回读不到目标态即判失败，任务进入人工接管队列。验证：在测试环境构造“假成功”——点击确认后让真实提交返回半成功，任务应当被判失败而不是成功。

根因三：共享身份导致越权与不可归因。修改：独立身份加租户作用域、白名单与沙箱。原因：最小权限是安全边际的第一层，身份也是审计的主键。新行为：跨租户单号会在路由层被拒绝。验证：用不属于该身份的租户单号发起任务，观察是否在执行前就被拒。

根因四：不可逆动作没有恢复余量。修改：审批闸门加补偿脚本，执行前保存状态快照。原因：反演思维的落地形态就是“先写好退路再动手”。新行为：退款、删除、终态变更先入审批队列，审批通过后由编排器执行，逆操作脚本随任务一起注册。验证：在测试环境走一遍“执行—撤销”，确认状态能回到执行前。

配套的工具分级策略，写进配置而不是写进代码：

tool_ladder:
  - api            # 有事务语义与错误码，首选
  - mcp            # 结构化工具协议，具备参数校验
  - browser        # 结构化选择器，有 DOM 契约
  - computer_use   # 无结构接口时的兜底，仅限只读或可逆动作
write_policy:
  require_readback: true
  readback_sources: ["list", "detail", "settlement_file"]
  forbid_visual_verdict: true
  approval_required: ["refund", "delete", "finalize_status"]

幂等要先占位
回读要另一条路
身份要能归因
退路要提前写好

08、演进

[同一输入]
    |
    +--[V1] 本地文件占位 + UI 反馈判定 / 代价：并发重复写、假成功无法识别
    |
    +--[V2] 登记表占位 + 独立回读 + 审批闸门 + 补偿脚本 / 代价：多一次回读延迟、多一张表、不可逆动作多一段人工等待
    |
[Trade-off]
{得到可归因、可去重、可回读、可撤销；失去一部分吞吐与“零接口也能改”的灵活性；适用边界是目标系统没有稳定 API 但业务语义清晰且结果可回读}

比较：

• 正确性：V1 把“点击成功”等同于“业务成功”，正确性依赖界面稳定性；V2 用独立回读锚定业务态，正确性依赖后端契约。后者更接近真相。
• 稳定性：V1 在界面改版和并发下都会翻车；V2 在界面改版时降级但不会误判，因为回读兜住了，并发则由唯一索引兜住。
• 复杂度：V2 多出编排器、幂等表、审批队列、补偿脚本，实现成本和运维面都明显上升。这是主动付出的代价，不是意外。
• 成本：每一次写操作多一次回读往返；不可逆动作多一段人工审批延迟。省下的是售后与对账成本。
• 适用范围：目标系统有幂等且带事务语义的 API 时，直接用 API，不要退回视觉执行。Computer Use 的合理位置是“没有结构化接口时的兜底执行器”，而不是“绕开业务权限的万能钥匙”。
• 遗留问题：人工接管队列的 SLA 还没定；补偿脚本只覆盖了状态回退，对“已经发给客户的通知”这类外部副作用还没有处理方案。

同一条业务动作
两条执行路径
换来的不是更快
是错得起

09、洞见

9.1 反演思维决定的是设计顺序

常规做法是先设计执行路径，再补监控和告警。反演思维要求反过来：先把“错了怎么发现、怎么拦、怎么退”写清楚，再决定用什么工具去点。V1 的失败几乎都能追到同一个源头——防线是事后补的，所以补在了执行器内部，而不是执行器之外。而执行器内部的防线，会随界面改版一起失效。

反直觉判断：一个自动化系统的安全性，取决于它外部有多少独立于它的证据源；证据源越独立，系统越容易被判错，也就越安全。

9.2 能被 UI 点到的动作，不等于被业务授权

屏幕上的按钮是给人看的，它的可见性只代表“这个会话在当前页面能点到”，不代表“这个身份对这条数据有这个权限”。把二者混同，等于把权限体系整体绕过：执行器一旦拿到一个高权限会话，它就能做那个人能做的所有事，包括不该做的。

反直觉判断：给执行器更高权限，通常不会让它做得更好，只会让它的错误走得更远。最小权限在自动化系统里不是合规要求，而是错误半径控制器。

9.3 视觉置信度不是安全边界

置信度、OCR 准确率、点击命中率，都是感知层指标。而线上事故发生在语义层：动作发出去了，业务没变；动作发出去了，业务变了两次。感知层再准，也管不了语义层。真正需要被度量的是误操作率、任务完成率、人工接管率和回滚成功率。

9.4 安全边际买的是“错得起”

给不可逆动作加审批、加回读、加补偿，都会让流程变慢。这笔投入换来的不是更快的执行，而是“允许出错”的空间。判断一个动作该不该上安全边际，只需问两个问题：这个动作可逆吗？如果不可逆，恢复要多久、要谁签字？答案决定了它走快路径还是慢路径。

感知再准也没用
语义错了就是错
边际买的是余量
不是更快的速度

10、系统落地

原来有什么：一份手工流程（运营登录、导表、比对、标注）、一个共享的运维账号、零散的浏览器脚本，以及月末才暴露的差错。

本篇新增了什么：编排器作为写操作的唯一入口；按可逆性排序的工具分级；编排器侧的幂等登记表；独立于会话的业务态回读；不可逆动作的审批闸门与状态快照；以及一条能还原身份、租户、单号、幂等键与前后截图的审计链。

现在能做什么：差异清单的抓取全自动；差异单的写操作具备去重、可回读、可归因、可审批、可补偿的能力；界面改版时任务会降级并转人工，而不是悄悄做错。

还缺什么：人工接管队列的 SLA 和值班规则；补偿对“外部副作用”的处理（已发出的通知、已生成的凭证）；审批闸门与业务侧审批系统的对接；以及灰度期的指标采样——验收用的目标值必须来自采样，不能拍脑袋。

下一步如何演进：把审批闸门从“会话内的人工确认”升级为可配置的策略引擎，按动作类型、按金额、按租户分级；把回读从列表轮询升级为对账文件比对；把补偿脚本纳入常规演练，每次发版都跑一遍“执行—撤销”。

先把入口收拢
再给退出留门
能归因的系统
才配自动写

11、小结

Q1 → 能：前提是把写操作入口收进编排器，用登记表、回读、审批、补偿四道闸门，换取放开自动化的空间
Q2 → 选“被业务授权”：能操作 UI 只是执行能力，授权才是边界；把执行当授权，等于绕开权限体系
Q3 → 账会很难对：假成功会在月末集中暴露，且没有幂等键、没有回读、没有截图，无法归因到具体任务
状态 → 一条具备幂等、回读、审批、审计与补偿能力的 Computer Use 写路径，以及被明确划出的适用边界

一句话收拢：让机器会点鼠标很容易，让它有边界地做对事才是架构。

四个问题一条线
边界先于能力
写路径走得慢些
才敢让它走远

12、作业

12.1 理解题：为什么把视觉置信度从 0.6 提到 0.9，解决不了“任务报成功但业务没变”？

参考答案：置信度属于感知层指标，回答的是“我看清了吗”。而该故障的根因在语义层——执行器把 UI 反馈（绿色 toast、按钮消失）当成了业务态变更。界面改版后结构化选择器失效、降级到视觉兜底时，感知越“自信”，误判越容易通过。正确做法是写后强制回读，且回读来源独立于本次会话。

12.2 实战题：给一条“标记已处理”的写动作补上幂等与回读，写出最小改造点。

参考答案：三处改造。一，幂等键由“任务+单号+动作”派生，在编排器侧的登记表以唯一索引先占位，抢不到就直接返回“已在处理中”；二，写后回读业务态（列表重新查询或详情页），只有回读到目标状态才算成功；三，回读失败时不重试写动作，而是把任务推进人工接管队列，并保留前后截图与 trace 作为证据。

12.3 排障题：夜间批次大量“等待元素超时”，你如何判断这是页面改版还是会话失效？

参考答案：先看证据再看猜测。打开失败时刻的截图或 Trace：如果页面上有权限变更弹窗、账号显示异常、或跳转到了登录页，那是会话/身份问题，应检查执行器用的是不是共享账号、权限是否被回收；如果页面正常打开但选择器找不到，就取页面快照对比 DOM，确认是结构变化，应降级到备用选择器或视觉路径，且视觉路径仅限只读或可逆动作。两种情况都不应做静默重试。

12.4 架构判断题：目标系统既没有开放 API，也不支持幂等键，业务又要求自动化处理退款。你接不接？怎么接？

参考答案：可以接，但要把“不可逆”这件事在架构上补齐，而不是在提示词里补齐。幂等由编排器侧登记表实现（先占位后执行），回读靠独立数据源（列表、详情或对账文件），退款这类不可逆动作必须进审批闸门，并保留原始状态快照与逆操作脚本；执行器只承担“无结构化接口时的兜底执行”，且默认不具备退款权限，需要按租户作用域与白名单显式授予。如果连独立回读源都不存在，正确结论是拒接退款，只做只读与可逆动作。

题在纸上好答
难在敢说不
边界写在配置里
才算真的落地

13、思考

回到最初那个冲突：我们想让执行器“能干更多事”，而系统需要它“错得更少”。这两个目标在写路径上天然对立，缓解它们的不是更强的模型，而是更清楚的边界。

三条可复用的判断：

第一，按可逆性给动作分级，而不是按实现难度分级。只读动作可以激进，可逆写操作要回读，不可逆写操作必须审批加补偿。工具选择也跟着这条轴走：API/MCP → 浏览器自动化 → 桌面操作，能结构化就不要靠视觉。

第二，能操作 UI 不等于有业务授权，也不等于动作成功。授权要在路由层判定，成功要在业务态回读。屏幕只提供证据，不提供结论。

第三，先假设误操作和越权已经发生，再倒推防线；给不可逆动作留出权限、审批与恢复的余量。安全边际不提高成功率，它降低单次失败的代价——而自动化系统真正的可用性，取决于它错得起多少次。

Computer Use 是无结构化接口时的兜底执行器，不是绕开业务权限的万能钥匙。这句话在演示阶段像一句保守的劝告，在写路径上是一条硬约束。

一念辨可逆
一证定真伪
一闸拦越权
一退保平安