computer-use agents 的能力上限已经被模型能力拉满,真正的瓶颈正在变成"可控性" 过去十八个月,围绕 computer-use agents 的能力进展集中在两个维度:模型能多准确地理解屏幕、能多流畅地操作鼠标和键盘。但 2026 年下半年,业内讨论的焦点开始从"模型能做什么"迁移到"我们能让模型做多少"。Anthropic 在最新发布的 agent 自主性研究中明确指出,自动批
computer-use agents 的能力上限已经被模型能力拉满,真正的瓶颈正在变成"可控性"
过去十八个月,围绕 computer-use agents 的能力进展集中在两个维度:模型能多准确地理解屏幕、能多流畅地操作鼠标和键盘。但 2026 年下半年,业内讨论的焦点开始从"模型能做什么"迁移到"我们能让模型做多少"。Anthropic 在最新发布的 agent 自主性研究中明确指出,自动批准率会在熟练用户中显著上升;OpenAI 在内部 Codex 数据中证明,长周期任务已经成为主流工作负载。两份材料放在一起指向同一个判断:computer-use agents 的能力天花板已经被现有模型撑到接近上限,但生产部署的真正瓶颈正在变成"可控性"。
一、模型能力不再是 computer-use agents 的卡点
把时间拉回 2024 年 10 月,Anthropic 在 Claude 3.5 Sonnet 上首次把 Computer Use 推到 public beta 阶段。当时的产品定位是"experimental",文档里直接写"At this stage, it is still at times cumbersome and error-prone"。早期用户在 WebArena、WebVoyager 等基准测试里看到的成绩,以及在 OSWorld 上 Claude 3.5 Sonnet 拿到的 14.9% / 22.0%,都说明模型对屏幕元素的理解、对鼠标键盘操作的精准度,距离"产品级"还有相当差距。
到 2026 年,这个差距已经被显著缩小。Anthropic 在 2026 年 9 月初发布的《Measuring AI agent autonomy in practice》里给出的数据,不再讨论"模型能多准"或"操作能多流畅",而是直接跳到"用户在真实工作中实际允许 agent 跑多远"。换句话说,Anthropic 已经把 computer-use agents 的能力评估从"能不能做"切换到"敢不敢放手让它做"。
OpenAI 在同一时间窗口里给出的对照材料,佐证了这一判断。《智能体如何重塑工作方式》披露的 Codex 内部数据显示,2026 年 5 月在被抽样的个人用户中,80.6% 至少发起过一次人工耗时 30 分钟以上的 Codex 请求,70.2% 发起过超 1 小时的任务,25.6% 发起过超 8 小时的任务。这种"长委托"已经成为主流工作模式——传统聊天机器人的"问一个问题得一个答案"被彻底取代,取而代之的是"agent 连续多个并行任务并发执行"。
两个数据合起来得出的结论是清晰的:模型已经能支撑长任务,用户也愿意把长任务交给模型。瓶颈不在模型能力,也不在用户意愿。瓶颈在中间那道工序——可控性。
二、可控性瓶颈的真实表现:用户的不放心与系统的兜底
可控性瓶颈的具体表现,可以从 Anthropic 报告里的三组数据精确读出。
第一组数据,Claude Code 单次自主运行时间在三个月内从不到 25 分钟拉长到 45 分钟以上。这是进步信号,但也是焦虑信号——自主时间拉长,意味着如果模型在某一步走偏,纠错成本也在拉长。在 OpenAI 内部,Codex 的前 1% 重度用户每天生成超过 60 小时的智能体运行时间,这些运算被分配给多个并行运行的智能体。这种规模和时长下,任何一次"模型走偏"都不是几分钟能挽回的事故。
第二组数据,熟练用户的自动批准率从 20% 上升到 40% 以上。上升是合理的——用户随着经验积累,对模型行为的可预测性有了更准确的预期。但即使在最熟练的用户群里,自动批准率也没有突破 50%。这意味着,不管模型多强、企业部署多成熟,人类始终是"兜底最后一道关"。Anthropic 在解读这组数据时强调"长会话中,Claude Code 请求人类输入的频率显著高于人在相同节点会提出的澄清",恰恰说明模型自己也承认,在歧义节点它不会替用户做决定。
第三组数据,工具调用集中在软件工程场景,占比接近一半。这不是模型偏好,而是产品现实——软件工程任务的工具语义清晰、可验证信号强、版本控制兜底齐全,所以用户敢放手。而涉及资金、合规、客户沟通的高风险工具调用,即使技术上可做,用户在授权时依然极度谨慎。这意味着,computer-use agents 的部署范围被"可控性"直接约束在低风险区间。
三、可控性的技术构成:三道实际防线
可控性不是单一开关,而是一组叠加的工程机制。结合 Anthropic 和 OpenAI 的最新材料,可以拆出三道防线。
防线一,操作粒度的可观察性。Anthropic 报告里强调"we tend to stop reviewing each action and instead let Claude run autonomously, intervening only when needed",但前提是"用户对当前任务有充分预期"。这意味着,在生产环境里,computer-use agents 必须把每一步操作可视化给用户:当前打开了哪个页面、即将点击哪个按钮、为什么选择这个选项。OpenAI 在 Codex 里通过 `update_plan` 工具实现了"任务计划可更新"的机制——agent 在执行前会先输出计划,执行中可以根据进展动态调整,用户随时可以看到 agent 当前打算做什么。
防线二,失败的可回滚性。Anthropic 报告指出 agent 在长任务里会出错,而出错后能恢复到什么程度决定了它能不能进生产。在软件工程场景里,版本控制系统天然提供了回滚能力——agent 写错了代码,git revert 一键回退。这正是为什么软件工程任务占工具调用近一半,而不是其他领域。OpenAI 在 Codex 里也强调"agent 循环上下文管理是核心职责之一",通过 Responses API 的 `input` 列表机制保留历史记录,出问题时可以回到任意一步重新执行。
防线三,关键操作的二次确认。这是 2026 年下半年最显眼的工程投入方向。Anthropic 在 Claude in Chrome GA 里明确说,购买、金融操作等"one-way doors"动作必须停下来等用户。Google Gemini in Chrome 的 auto browse 也是同样设计——敏感任务前主动询问。OpenAI 在 Codex 的 Responses API 工具列表里,有一类专门的"approval_policy"配置——agent 在执行高风险工具调用前,会先输出请求授权,用户确认后才继续。这三道防线背后是同一个共识:可控性不是"减少用户介入",而是"在最关键的节点介入"。
四、可控性瓶颈如何反向塑造产品形态
可控性瓶颈不只是工程问题,它在反向塑造 computer-use agents 的产品形态。从 2025 年下半年到现在,几个清晰的产品演化路径已经出现。
路径一,从独立产品收敛到主产品内的一个模式。OpenAI 在 2025 年 7 月把 Operator 整合进 ChatGPT 的 Agent 模式,独立域名几周内下线。这背后的产品判断是:browser 操作的可控性,只能依靠 ChatGPT 整体的安全模型来保证,Operator 作为独立产品无法独立承担"用户授权"这道工序。Anthropic 走了类似的路径——Claude in Chrome 不作为独立浏览器存在,而是作为现有 Chrome 浏览器的一个扩展,继承 Chrome 自身的 session 管理、权限模型、用户登录态,避免重新发明轮子。
路径二,把权限边界做细到"按网站授权"。Anthropic Claude in Chrome 提供的 Permissions Mode,允许用户"grant access one site at a time",agent 不能访问用户没明确批准的网站。这等于把可控性从"任务级"细化到"网站级",适合企业部署——管理员可以预先为员工配置允许 agent 操作的网站白名单。OpenAI 在 Stateful Runtime Environment 里给出了更进一步的方案:把"身份与权限边界"作为基础设施层的能力,任何 agent 调用都必须经过身份验证,任何超出权限范围的操作都被运行时直接拦截。
路径三,把 prompt injection 防御做成"模型 + 网关"双保险。Anthropic 在浏览器 agent 上投入近一年的 prompt injection 防御(2025 年 11 月到 2026 年 9 月,Claude Opus 4.5 攻击成功率从早期版本降到 1%)说明,可控性的另一面是抗攻击能力。攻击者会在 web 内容里藏恶意指令,试图诱导 agent 执行用户没授权的操作。如果模型层无法识别这些攻击,生产部署就无法真正落地。OpenAI 的运行时方案则把这件事做在网关层——工具返回内容进入模型上下文之前,先经过网关的内容审查。
五、可控性瓶颈对企业的实际启示
对于正在评估或部署 computer-use agents 的企业,有几个判断维度可以直接落地。
判断一,先把任务分到"低可控性要求"和"高可控性要求"两堆。低可控性要求的任务(数据搬运、表单填写、内容整理)可以放心交给 computer-use agents,这部分能力天花板已经被现有模型撑到接近上限。高可控性要求的任务(支付、合规、客户沟通、敏感数据访问)在 2026 年下半年仍然不适合交给 computer-use agents 直接执行,需要"agent + 人工复核"的混合架构,或者等 prompt injection 防御能力进一步成熟。
判断二,部署前问清楚四个工程问题。第一,agent 每一步操作的可视化粒度有多细?能不能看到当前打开的页面、即将点击的按钮、为什么选择这个选项?第二,失败回滚机制是什么?agent 操作错了能不能快速撤回、撤回的影响范围多大?第三,关键操作前是否有强制二次确认?确认的延迟和体验如何?第四,prompt injection 防御在哪一层?是依赖模型识别,还是有独立的网关审查?
判断三,把可控性作为采购指标,而不是"附加项"。评估 computer-use agents 产品时,可控性应该和模型能力、价格、生态并列,作为同等重要的采购指标。具体可以看:产品是否提供任务预览、动作回放、关键节点复核;是否提供按网站/按工具的权限粒度;是否提供完整的审计日志;是否提供 prompt injection 检测的透明度报告。这四项的可视化和透明度,直接决定了产品能不能进生产。
结语:可控性是 computer-use agents 进入下一阶段的入场券
OpenAI 的 Mark Chen 在近期一条讨论里,把可控性点为 computer-use agents 的真正瓶颈——这个判断和 Anthropic 的自主性研究、OpenAI 自己的 Codex 数据完全一致。三家厂商的工程投入方向也都集中在同一个地方:让可控性从"产品功能"变成"基础设施"。
2026 年下半年,computer-use agents 的下一个分水岭,不再是模型能不能在 WebArena 上多刷几分,而是产品能不能在企业生产环境里把可控性做到让 CIO 愿意签字。把这件事做好的产品,会真正进入企业的核心业务流;做不到的,会停留在"个人效率工具"的定位上,长期被边缘化。
