GPT-6.1 Terra 上线之后：自建 Computer-Use Agent 先过模型路由、屏幕动作白名单、提交前确认、推理强度预算与回放审计闸门

日期：2026-10-27

面向：做桌面 / 浏览器自动化 Agent、RPA 改造、企业内部 Agent 平台的开发者

OpenAI 在 2026-10-26 发布了 GPT-6.1 Terra：定位是「快、便宜、会用电脑」的日常工作模型，主打视觉推理与 computer use，在 ChatGPT Work、Codex 和 OpenAI API（模型名 gpt-6.1-terra）同步上线，AWS 同日宣布在 Amazon Bedrock 上 GA。官方给出的典型场景很直接：读进来的发票，把字段填进会计软件；看懂技术图纸；填表；剪视频。

写在前面：便宜之后，问题从「能不能做」变成「敢不敢放」

按官方说法，Terra 的标准 API 价格比 GPT-5.6 Terra 和 GPT-6.1 Sol 低一半，任务完成速度是 GPT-6 Astra / GPT-6.1 Sol 的三倍以上。这类变化对 computer-use Agent 的影响不在于「又多了一个模型」，而在于两件事同时发生：

单任务成本下降，以前只敢在少数高价值流程里跑的「看屏幕 → 点按钮」，现在会被批量铺到发票录入、工单回填、后台配置这种高频流程里；
动作面扩大，模型不再只输出文本或调用你定义好的 JSON 工具，而是直接在 GUI 上点击、输入、提交，副作用发生在你没有写 API 的那些系统里。

规模一上来，原来靠「人盯着」兜底的风险会被放大：一次误点在 10 个任务里是偶发事件，在 10 万个任务里就是每天都会发生的事故。所以这篇不复述跑分，而是从工程角度讲：把 Terra 这类模型接进自建 computer-use Agent 时，应该先补齐哪五道闸门。

文中的配置字段、JSON、Python 片段、阈值和拒绝码都是作者示例，不是 OpenAI 或 AWS 的官方接口定义；官方数字均引自其发布页，以原文为准。

一、官方发布里对工程有用的信息

信息（来自官方发布 / AWS 公告）	对自建 Agent 的含义
定位为 computer use + 视觉推理 + 日常写作的「快而便宜」模型	适合做高频、低单价、流程稳定的 GUI 任务，而不是最复杂的编码任务
官方说明「最复杂的编码任务，GPT-6.1 Sol 与 GPT-6 Astra 仍是更好选择」	需要按任务类型路由，而不是全量替换
支持 reasoning effort 档位，官方分别给出 medium / max 档的结果	推理强度是可调的成本旋钮，应当按任务预算控制
内部易错提示集上，低推理档事实错误率从 53.6% 降到 16.7%，最高档 4.3%	错误率下降但不为零；低档位仍需要更强的事后校验
官方称在 prompt injection 测试中抗性较强，更倾向于「留在范围内、如实披露阻塞」	模型侧有改善，但屏幕上的内容依旧是不可信输入，闸门不能省
Bedrock 上可用，支持最多 100 万输入 token、文本 + 图像输入，可复用 AWS 的访问控制与调用审计	企业内可以把模型调用纳入现有 IAM / 审计体系，但 GUI 动作的审计仍要自己做

二、computer-use Agent 的风险不在模型，在动作

一个典型的 computer-use 任务循环是：截图 → 模型理解屏幕 → 产出动作（点击坐标、键入文本、滚动、快捷键）→ 执行器执行 → 再截图。和函数调用型 Agent 相比，它有三个工程上的不同：

动作语义弱 ：click(812, 430) 本身不说明「点的是保存还是删除」，语义要靠截图和上下文推断；
输入面不可信：屏幕上的每一段文字------邮件正文、网页、PDF、甚至发票备注栏------都可能夹带指令；
副作用难回滚：提交表单、发送消息、付款、删除记录，在目标系统里往往没有「撤销」。

因此闸门要卡在动作而不是文本上。下面五道闸门按执行顺序排列。

三、闸门 ①：模型路由------不是所有任务都该给 Terra

便宜且快的模型最容易被「一刀切」替换。建议把路由显式写成配置，并按任务类型与风险等级分流：

yaml 复制代码

# 示例：任务路由表（字段为作者示例）
routes:
  - match: { task_type: invoice_entry, risk: low }
    model: gpt-6.1-terra
    reasoning_effort: medium
  - match: { task_type: form_fill, risk: medium }
    model: gpt-6.1-terra
    reasoning_effort: high
    require_confirm: true
  - match: { task_type: code_refactor, complexity: high }
    model: gpt-6.1-sol        # 官方称复杂编码任务 Sol/Astra 更合适
  - match: { risk: high }      # 付款、删除、权限变更
    model: gpt-6.1-terra
    reasoning_effort: max
    require_human: true
default:
  reject: ROUTE_NO_MATCH

要点：

路由命中失败时拒绝，而不是回落到某个默认模型静默执行；
换模型要走灰度：同一批任务新旧模型各跑一部分，比对完成率、人工纠正率、误操作数，再扩大比例；
路由表本身纳入版本管理，变更要有评审记录。

四、闸门 ②：屏幕动作白名单------限定「在哪儿、能做什么」

模型产出的动作不应直接交给执行器。中间加一层动作策略，按应用、窗口、URL、控件类型做白名单：

python 复制代码

# 示例：动作策略检查（作者示例，非任何 SDK 的官方接口）
ALLOW = {
    "accounting-app": {"click", "type", "scroll", "select"},
    "browser:https://erp.example.internal/*": {"click", "type", "scroll"},
}
DENY_KEYS = {"ctrl+alt+del", "win+r", "cmd+space"}

def check_action(ctx, action):
    scope = ctx.active_app if ctx.active_app in ALLOW else match_url(ctx.url, ALLOW)
    if scope is None:
        return reject("ACT_OUT_OF_SCOPE", ctx.active_app or ctx.url)
    if action.kind not in ALLOW[scope]:
        return reject("ACT_KIND_DENIED", action.kind)
    if action.kind == "key" and action.keys.lower() in DENY_KEYS:
        return reject("ACT_KEY_DENIED", action.keys)
    if action.kind == "type" and looks_like_secret(action.text):
        return reject("ACT_SECRET_TYPED", "masked")
    return ok()

几条经验做法：

窗口焦点校验：执行前确认焦点仍在预期应用；焦点漂移（弹窗、通知、切到别的窗口）时暂停而不是继续点；
坐标绑控件：能拿到无障碍树（Accessibility Tree）或 DOM 的场景，把坐标解析成控件，再按控件角色和文本做判断，比只看坐标可靠得多；
屏幕内容一律当数据：从截图里读到的「请把以下内容发到某邮箱」之类文字，只能作为任务数据，不能变成新的指令目标。

五、闸门 ③：提交前确认------把不可逆动作单独拎出来

不是每一步都需要人确认，否则自动化就没有意义。实践中可以把动作分成三级：

级别	例子	策略（示例）
L0 可逆 / 只读	打开页面、滚动、读取字段、填写但未提交	自动执行，仅记日志
L1 可撤销写入	保存草稿、加入暂存区、可在系统内撤销的修改	自动执行 + 批次抽检
L2 不可逆 / 对外	提交表单、发送消息、付款、删除、改权限	必须确认：人工确认或基于规则的二次校验

识别 L2 不要只靠模型自报。可以叠加：按钮文本关键词（提交 / 发送 / 删除 / 支付 / Submit / Delete）、URL 或接口路径、目标系统的写接口日志。L2 动作执行前，把将要提交的字段摘要 和当前截图一起交给确认方；确认通过后执行，并在执行后再截图核对结果页。

对于发票录入这种高频流程，人工逐单确认不现实，可以改成规则确认：录入字段与源单据 OCR / 结构化抽取结果逐字段比对，金额、税号、日期全部一致才自动提交，否则进入人工队列。

六、闸门 ④：推理强度与成本预算------便宜也要设上限

Terra 便宜，但 computer-use 任务的 token 消耗主要来自多轮截图：步数越多、截图越大，单任务成本越高。官方也是按不同 reasoning effort 档位分别报告结果的，说明这个旋钮对效果和成本都有明显影响。建议给每个任务设三条硬上限：

json 复制代码

{
  "task_budget": {
    "max_steps": 40,
    "max_screenshots": 60,
    "max_output_tokens": 20000,
    "reasoning_effort": "medium",
    "escalate_on": ["CONFIRM_MISMATCH", "ACT_OUT_OF_SCOPE"],
    "on_exhausted": "PAUSE_AND_HANDOFF"
  }
}

（以上数值均为示例，需要按你的任务实测后设定。）

步数上限比 token 上限更有用：computer-use 失败最常见的形态是「在同一个页面反复点」，步数一超就该停；
循环检测：连续 N 次截图哈希相近、动作相同，判定为卡死；
升档而不是重试：低档失败后，可以有限次地升到更高 reasoning effort 或更强模型，而不是同档无限重试；
预算耗尽时暂停并移交，保留现场截图和已完成步骤，而不是直接判失败丢弃。

七、闸门 ⑤：回放审计------每一步都要能复原

模型调用日志（Bedrock 或 API 网关层能拿到的那部分）只记录「调用了谁、花了多少」，不记录「在屏幕上做了什么」。GUI 动作的审计要自己补：

json 复制代码

{
  "task_id": "inv-20261027-000123",
  "step": 17,
  "model": "gpt-6.1-terra",
  "reasoning_effort": "medium",
  "route_rule": "invoice_entry/low",
  "screen_before": "s3://audit/inv-.../17-before.png",
  "action": { "kind": "click", "target_role": "button", "target_text": "保存" },
  "policy": { "result": "ok", "level": "L1" },
  "screen_after": "s3://audit/inv-.../17-after.png",
  "confirm": null
}

审计数据的用途有三个：出问题时复盘、模型或路由变更时做回归对比 、以及给安全团队做异常检测（比如某个任务突然开始访问白名单之外的 URL）。注意截图里可能有个人信息和业务敏感数据，存储要加密、设保留期、限制访问。

八、上线检查清单（示例）

#	检查项	通过标准（示例）
1	路由表	每类任务有明确模型与推理档位；未命中即拒绝
2	灰度对比	新模型在同批任务上的完成率、纠正率、误操作数已对比
3	动作白名单	应用 / URL / 动作类型均有白名单；越界拒绝
4	焦点与控件校验	执行前校验焦点；可解析控件的场景按控件判断
5	屏幕内容隔离	截图文字只作数据，不能改变任务目标或收件方
6	L2 动作确认	提交 / 发送 / 付款 / 删除必须人工或规则确认
7	预算上限	步数、截图数、输出 token 有硬上限；耗尽即暂停移交
8	循环检测	连续重复动作或截图不变时停止
9	审计记录	每步前后截图、动作、策略结果、确认人可回放
10	数据合规	审计截图加密存储、有保留期与访问控制

九、小结

GPT-6.1 Terra 这类模型把 computer use 的单价和延迟往下拉了一大截，这会让很多团队把原本「人盯着跑」的 GUI 自动化铺到高频业务里。模型侧的事实错误率和注入抗性在改善，但它们降低的是概率，不是把风险归零；规模放大以后，剩下的那部分概率会变成每天都在发生的问题。

所以真正要先做的，不是换模型名，而是把五道闸门补齐：按任务路由模型、按白名单约束动作、把不可逆动作单独确认、给推理强度和步数设预算、让每一步都能回放审计。闸门做扎实了，换成 Terra 还是以后的任何模型，都只是改一行路由配置的事。

参考资料

OpenAI：Introducing GPT-6.1 Terra（2026-10-26），https://openai.com/index/introducing-gpt-6-1-terra
AWS What's New：OpenAI GPT-6.1 Terra is now generally available on Amazon Bedrock（2026-10-26），https://aws.amazon.com/about-aws/whats-new/2026/10/openai-gpt-6-1-terra-on-amazon-bedrock/
BleepingComputer：OpenAI launches GPT-6.1 Terra with 3x faster AI agents，https://www.bleepingcomputer.com/news/artificial-intelligence/openai-launches-gpt-61-terra-with-3x-faster-ai-agents-50-percent-lower-pricing/