摘要：当 Agent 从回答问题走向操作真实软件，“暂停”“继续”和“停止”只是最基本的控制。新的研究和开源实践把注意力放到了任务状态、需要保留的条件、执行证据，以及发生错误后究竟能恢复多少。
想象一下，你让 Agent 帮忙调整一天的会议安排：把下午的两场会议错开，向有关同事发出更新，但不要动上午已经确定的客户会议。
Agent 操作完日历，告诉你“已完成”。你真正想确认的是：下午的时间有没有调整正确，上午那场会议有没有被误改，通知万一发错了还能怎样补救。
一串鼠标点击记录可能很详细，却不一定回答得了这些问题。
以前我们用聊天框告诉 Agent“继续”或“停下来”，现在这类交互要承载真实世界的修改，显然不够用了。
10 月 14 日公开的论文 Task-State Governance 提出了 TaskVM。它把一项 GUI Agent 任务拆成三部分：期望达到的结果、必须保留不变的条件，以及当前观察到的应用状态。
这样的设计看起来很简单，却把用户的监督对象换了一个角度。原来用户需要跟着 Agent 看：“第一步打开什么，第二步点击哪里。”现在可以直接检查：“这个结果是否已经达成，那几个字段是否保持原状。”
举个例子，修改日历是目标；不得更改某个客户会议是约束；页面上新旧时间及通知状态是观察结果。Agent 可以自行选择操作顺序，但最后要对这些明确的任务条件负责。
TaskVM 还要求通过新的独立观察核对结果，而不是直接接受执行 Agent 自己说的“我完成了”。这很重要：模型对自己操作过程的描述，本身不能代替验收证据。
本周开源项目 Zavora Computer Use MCP v7.6.1 增加了桌面状态卡：用户能看到 Agent 正在执行的动作、暂停、恢复或停止。暂停后会拒绝新的修改操作，也尝试中止正在执行的动作；读取操作仍可继续。它还特意避免让 Agent 的截图包含控制卡片本身。
这是一个很实用的方向，不过要留意实现边界：这一版的状态卡默认不开启，项目报告的桌面实测主要来自 macOS，Windows 状态卡仍缺少真实桌面验证。更重要的是，暂停只能限制接下来的操作。已经发出的邮件不会因为按下停止按钮而自动消失，已提交的订单也不会自动回滚。
TaskVM 进一步把操作区分为三类：可以直接撤销的、需要额外补偿动作的，以及不可逆的。比如撤销尚未提交的输入可能比较容易；发错消息后的补救也许只能是再发一条更正；已经产生外部不可逆影响的操作，系统就必须明确告知用户无法完整恢复。
图：以日历调整为例说明任务状态及恢复决策。属于概念示意，不代表 TaskVM 能对所有外部系统自动撤销或回滚。
“停止继续执行”和“撤销已经造成的变化”，是两项完全不同的能力。 产品如果把两者都展示成一个含糊的“撤销”，反而容易制造错误的安全感。
TaskVM 的研究有三种评估：受控任务上的技术检查、37 人的用户实验，以及 14 人返回参与的实时模型探索。
在 37 人的被试内实验中，研究者使用受控回放，两种界面的底层执行轨迹保持一致。TaskVM 在“我是否能控制错误恢复”的主观评价中平均得到 5.56 分，对照聊天界面为 4.63 分（七分量表）。研究中 TaskVM 还提供了基线界面缺少的显式恢复操作，因此参与者使用这些操作更多，并不能单独证明真实自主执行时的恢复成功率更高。
这说明显式任务状态和恢复入口可以改善用户的控制体验。但主要用户研究不是两组实时自主 Agent 完成任务的对照，不能写成“TaskVM 已证明能提高生产环境任务完成率”。视觉检查也只能证明当时可观察的界面状态，不能天然证明所有后台操作的最终一致性。
换句话说，这项研究给出了交互设计上的方向和初步证据，工程可靠性仍有不少问题需要解决。
另一个有意思的变化来自本周的 Deep Agents 更新。异步子任务现在可以把状态报告给主 Agent，明确标出正在等待人工输入的任务，并把子任务执行记录关联到父任务的追踪信息。
这些能力看上去不像新的模型能力，却很关键。如果任务挂在后台运行，用户甚至不知道哪个子任务在等审批、哪个已经失败，任何上层“任务控制台”都很难把事实说清楚。
Munim Computer Use 同期还在解决另一个朴素的问题：用户与 Agent 同时用同一台电脑时，输入焦点会互相争抢。对真实桌面而言，能不能在用户继续工作的同时避免误操作，比一次截图识别分数提升更容易被用户感知。
图：相关能力分属不同层次，Munim、Deep Agents、Zavora 与 TaskVM 均是独立研究或项目，并未组成同一套完整系统。
这几个项目解决的不是同一个层面：底层输入隔离、任务运行状态、用户控制入口，以及对最终状态的独立验证。要把它们连起来，才能形成完整的任务监督能力。
我倾向于把控制界面收束到四类信息：任务希望达到的结果、必须保留的约束、目前已观察到的事实，以及失败后的恢复选择。用户需要时可以展开步骤和原始证据，但不必被迫盯着每一次点击。
一旦任务风险升高，系统还应该清楚标出确认点：哪些操作可以自动执行，哪些需要用户授权，哪些一旦提交就难以补救。
这套思路同样适用于 Coding Agent。用户可能不关心 Agent 中间运行了多少条命令，却关心它是否改动了授权范围外的文件、测试是否真的运行、部署是否触发，以及遇到失败后能否回到可核查的状态。
如果下一次设计 Computer Use 产品，我会先问四个问题：任务状态能不能被独立核对，哪些约束必须一直成立，暂停以后还会发生什么，以及已经造成的变化能恢复到哪一步。最后一个问题尤其不能含糊——停止、撤销和补偿，应该是三种清楚区分的操作。
用户不需要时时盯着 Agent 的每一步，但在关键节点必须看得懂、接得住、能纠错。比起再多展示一段执行动画，这样的控制能力更接近日常工作真正需要的可靠性。
《企业研发 AI 自动化》是我持续记录 AI 进入真实研发流程后的实践系列。
它关注的不只是 AI Coding 工具本身，而是从需求输入、任务表示、Agent 执行到自动化验证的完整链路：AI 如何在真实工程系统里稳定运行，并逐渐形成可复用的研发自动化能力。
欢迎关注和交流～
