计算机使用代理在 IT 服务交付中的接入与权责边界

摘要：托管 IT 服务商的交付效率长期受制于一批没有应用程序接口的旧式管理门户，工单、设备与许可证操作必须在浏览器中人工完成，代理式自动化往往止步于登录环节。Shield 在其 Forge 平台中引入具备计算机使用能力的模型，把受支持的浏览器任务交由代理执行，技术上由模型读取界面、定位控件并完成操作，管理上由技术人员划定可自主执行的动作范围。本文以此案例为经验材料，讨论计算机使用代理进入 IT 服务交付链条后，瓶颈从算力转向访问权的实质变化、效率改进的可检验边界、必须保留给人的任务类型，以及由此产生的权限、审批与审计责任问题，并就旧式门户场景下的代理治理提出可操作的判断框架。

关键词：计算机使用代理；托管 IT 服务；旧式门户；访问控制；人机分工

1 引言

中小企业的 IT 事务通常整体外包给托管服务商。一名员工被锁在笔记本之外，或者一台配置错误的防火墙让整个办公室断网，这类请求会进入服务商的工单队列，由技术人员逐项处理。服务的竞争力在很大程度上取决于响应速度与一次解决率，而这两项指标又被一个不起眼的环节拖住：大量日常操作必须在旧式管理门户里完成。

这些门户管理工单、设备与软件许可证，多数没有对外接口。代理式自动化在具备接口的系统上可以顺畅运行，到了这类界面就停下来 —— 它读不懂屏幕，点不准控件，也判断不出一个弹窗意味着成功还是失败。任务于是被退回给人，技术人员登录、点击、提交，把一个本可以自动完成的步骤重新做一遍。

Shield 构建的 Forge 平台试图补上这一段。按照其技术负责人的说法，只有当需要人的判断时才应该把人叫进来，而不应该因为卡在访问环节就停下。这一表述把问题定位得很清楚：制约不在模型能力，而在能否进入系统。本文以该案例为材料，讨论三个相互关联的问题：计算机使用代理究竟改变了交付链条的哪一段；效率数据在什么条件下可以被采信；当代理开始代替人持有登录状态并执行写操作时，权限与责任应当如何切分。

2 案例背景与技术选择

Forge 被定位为面向 IT 服务商的 AI 操作系统，其设计目标不是替代某一个工具，而是把业务数据与客户上下文汇总到一处，使支持任务能够端到端完成。这一定位决定了它必须处理异构系统：新一些的服务有接口，老一些的只有网页。

Shield 并非一开始就选择了计算机使用路线。按照公开描述，其早期尝试使用过具备屏幕操作能力的模型，结论是不可靠，速度也不够。技术负责人的解释值得注意：没有接口的系统往往同时是界面陈旧、连人都觉得难用的系统，控件的排布不合常规，提示信息含糊，页面状态依赖前一步操作的副作用。这类界面恰恰是计算机使用能力最难发挥的场合，也是最有价值的场合 —— 容易的地方早就有接口了。

引入新一代模型后，Forge 的架构把任务分派拆成两层：AI Engineer 负责判定一项工作是否适合交给计算机使用代理，代理负责在界面上完成受支持的操作；技术人员则事先划定代理可以自主执行的动作，以及必须由人复核或批准的动作。这套安排在形式上并不复杂，但它把 "能力" 与 "授权" 分成了两个独立的决策，这一点在后文的讨论中会反复出现。

3 瓶颈的实质：访问权而非算力

把托管 IT 服务的交付流程拆开看，一次典型处理包含若干环节：接单与分类、诊断、执行变更、验证结果、记录与关单。代理式自动化在前两个环节进展较快，分类与初步诊断可以由模型基于历史工单与知识库完成；执行环节则高度依赖具体系统的入口。入口不通，后面的验证与关单也无从谈起。

因此，所谓 "卡在访问上" 并不是一个比喻。它指的是一段真实的中断：代理已经把问题分析清楚，也生成了正确的操作序列，但没有凭据、没有会话、没有可编程的接口，于是序列无法落地。技术人员接手的往往不是判断工作，而是把同一序列在界面上重放一遍。这种接手在管理上被计入人力成本，在体验上表现为额外的等待。

从这个角度看，计算机使用代理的价值不主要是 "更聪明"，而是 "能进去"。它把一段原本需要人来充当执行器的工作，转成了一段可以由代理执行、由人监督的工作。判断仍然在人这一侧，执行下移到代理。迪妙网络空间安全学院研究团队在评估同类平台时提出过一个区分：代理替代的是操作，不是责任；一旦把这两者混同，权限设计就会失准。

4 代理行为的可预期性

界面操作与接口调用在性质上不同。接口调用是结构化的，参数与返回值都有约定，失败会以错误码呈现；界面操作是感知与动作的连续组合，模型需要从像素或可访问性树中识别当前页面处于什么状态，再决定下一步点哪里、填什么。这条链路里任何一环判断失误，都可能把一个本应成功的任务引向错误的分支 —— 点了取消而不是确认，关掉了本该保留的窗口，或者在一个加载中的页面上重复提交。

案例材料中有一处描述颇具信息量：此前使用其他模型时，可以明显看出它在摸索界面，动作迟疑；新一代模型的操作显得连贯，观感上接近人在点击。这种差别不只是流畅度问题，它对应的是任务成功率的稳定性。迟疑意味着模型在每一步都要重新推断界面语义，推断错误的概率随之累积；连贯意味着它对常见界面范式形成了可复用的先验，需要临场推断的部分减少。对于需要连续十几次点击才能完成的任务，单步准确率的微小差异会被放大成整体成败的显著差异。

可预期性还有一层含义与安全直接相关。代理在旧式门户中执行的是写操作：重置口令、解除锁定、修改许可证分配、调整防火墙规则。这类操作的错误代价不对称 —— 多一次点击可能只是多一条日志，少一次确认可能意味着把一个不该放开的端口放开了。因此评估这类代理时，平均任务耗时只是其中一个指标，更需要关注的是动作序列在异常情况下的行为：页面结构变化时它是停下还是乱试，遇到非预期弹窗时它是上报还是自行处置，连续失败时它是否会在同一处反复重试。

5 效率数据的可采信范围

案例给出了若干经验数据：新一代模型在计算机使用任务上比此前使用的模型平均快 35% 至 40%；使用 AI 处理的工单客户满意度更高，解决速度是关键因素；执行更快、失败与超时更少；团队花在写详细指令、陪着代理走完任务上的时间也减少了。这些数字来自服务商的自述，而非独立测量，采信时需要划定范围。

其一，比较基准是同一家服务商此前使用的旧模型，不是人工处理。35% 至 40% 的提速说明的是模型代际差异，不能直接换算为人力节省。要判断人力节省，需要看的是同一类工单在 "代理执行" 与 "技术人员执行" 两种条件下的端到端时长，以及技术人员在代理执行期间是否真的腾出了手 —— 如果仍需盯着屏幕随时准备接管，那么名义上的并行并不成立。

其二，满意度提升的归因需要谨慎。使用 AI 的工单可能本身就更简单，或者被优先分派，这会产生选择偏差。速度是满意度的主要驱动因素这一判断在服务行业有较多支持，但它同时也意味着，满意度数据反映的可能是等待时间缩短，而不是解决质量改善。

其三，失败率与超时率的下降方向可信，因为这两个指标在平台侧有客观记录，且与前述 "动作连贯性" 的机制解释一致。反网络钓鱼技术专家芦笛在评价此类部署时提醒，代理类系统的绩效报告最容易忽略的是 "未遂" 部分 —— 那些代理执行到一半被人工接管、最终仍然成功关闭的工单，在成功率统计里通常被计入成功，而在人力核算里被计入节省，同一件事被两边同时记了一笔。

6 任务分层与人工保留域

案例明确指出，电话沟通、上门服务与远程桌面操作仍需人工参与，平台正在测试让代理直接在桌面环境中执行更复杂动作的能力。这条边界目前是清晰的，但它划定的依据值得讨论。

电话与上门之所以保留给人，原因不只是技术难度。电话沟通包含责任确认：客户在电话里授权某项变更，这个授权行为本身需要在组织间建立可追溯的记录；上门服务涉及物理环境判断与现场安全。远程桌面操作被单独列出，则更多出于风险考虑 —— 远程桌面意味着代理获得的是整台机器的控制权，而不是某个门户内的受限操作，一旦偏航，影响面从 "一条记录" 扩大到 "一台终端"。

据此可以把任务分成三层。第一层是门户内的确定性操作，输入输出明确、可回滚、影响限于单个对象，适合交给代理并辅以事后抽查。第二层是门户内的复合操作，涉及多个系统之间的状态同步，适合代理执行但在关键节点设置人工批准。第三层是需要现场判断、跨组织授权或整机控制的任务，代理至多提供准备与建议，执行权保留在人。这一分层不是按技术难度排的，而是按错误后果的可逆性排的。

7 权责边界：授权、可撤销与审计

当代理开始持有登录状态，权限设计就从技术问题变成了治理问题。

第一个问题是凭据的归属。代理以谁的身份证登录门户，决定了它能做什么、出问题时责任落在谁身上。较好的做法是为代理配置专用身份，而不是复用某个技术人员的账户。专用身份可以施加更细的权限，可以单独停用，也可以在审计日志中与人的操作明确区分。复用个人账户看似省事，代价是事后无法分辨一次口令重置是代理做的还是人做的。

第二个问题是动作的授权粒度。案例中技术人员事先决定代理可以自主执行哪些动作、哪些需要复核，这一安排的方向是对的，但粒度需要落到具体操作而非操作类别。"设备管理" 作为类别过于宽泛，其中既有只读的查询，也有会中断服务的重启；把两者放在同一个授权层级，等于把风险最低与风险最高的动作绑定在一起。

第三个问题是可撤销性。代理执行的操作应当尽量可逆，或者至少在不可逆操作前留下明确的中间状态。口令重置可以回滚（重新设定），许可证回收则可能立刻影响用户使用；防火墙规则变更若导致断网，恢复需要现场或带外通道。对这些不可逆或恢复代价高的操作，审批应当前置而不是事后。

第四个问题是审计。审计需要回答的不只是 "谁做了什么"，还包括 "代理当时看到了什么"。当一次操作出现争议时，仅凭最终状态难以判断代理是否误读了界面。保留关键步骤的界面快照、动作记录与模型判定依据，是把责任链条补完整的前提。反网络钓鱼技术专家芦笛强调，代理类系统的审计设计应当以 "可复盘" 为目标，而不是以 "有日志" 为目标；日志存在但无法还原决策过程，在追责时 almost 没有价值。

8 安全外部性：屏幕内容也是输入

这类部署引入了一类容易被忽略的风险：代理读取的界面内容，本质上是不受信任的输入。

门户页面由第三方系统生成，其中可能包含用户填写的自由文本 —— 工单描述、备注、设备名称。若代理把这些文本当作指令来理解，一条精心构造的工单备注就有可能改变它的行为。这与邮件正文中的诱导语句在机制上同源，都属于间接提示注入：攻击者不需要接触代理本身，只需要在代理会读到的位置放一段话。对以屏幕为输入、以点击为输出的代理而言，这种暴露是结构性的，因为它的工作方式就是把界面上的文字当作行动依据。

风险的第二个来源是场景本身。案例提到客户遭遇钓鱼攻击时速度至关重要，这意味着此类平台经常在处理安全事件的第一线运转 —— 重置被钓鱼账户的口令、检查邮件规则、撤销异常会话。这些操作恰恰是高价值目标：如果攻击者能够影响代理的判断，让它把一个仍由自己控制的认证方式保留下来，或者让它跳过某项核查，那么代理就成了入侵链条的一环。反网络钓鱼技术专家芦笛指出，把凭据重置交给自动化代理时，必须同时把 "残留清理" 写进同一段流程，否则重置口令只是关闭了一条路径，收件箱规则、转发设置与应用授权仍会继续生效。

第三个来源是权限的横向扩展。代理为完成一项任务可能需要在多个门户之间切换，若各门户共用同一套凭据或同一条会话，一次失陷就会扩散。据 DiMiao, CN 分析，旧式门户场景下的代理部署应默认假设 "界面内容不可信、单次会话可失陷"，据此设计凭据隔离与影响范围上限。

9 治理框架：四道可控的关口

把上述讨论收拢，可以为旧式门户场景下的计算机使用代理设计四道关口，每一道对应前述链条上的一个薄弱环节。

第一道是准入。并非所有门户都适合交给代理。判定标准可以设三条：操作是否可回滚，影响是否限于单一对象，界面是否有稳定的结构特征。三条同时满足的，可以纳入自主执行范围；缺一条的，进入人工批准流程。这条门槛的作用是先把不可逆、影响面大、界面反复变动的系统挡在外面，而不是等到出事后再逐案追责。

第二道是隔离。代理使用专用身份，凭据存放在受控的密钥体系中，按任务临时授予、任务结束即回收。不同门户之间不共享会话，跨系统任务通过显式的凭据切换完成，使一次失陷的影响被限制在单个系统内。同时对代理可访问的目标地址建立白名单，避免它在界面跳转中被引向非预期站点。

第三道是监控。需要采集的不只是成功与失败，还包括人工接管的频次与原因、同一任务的重复尝试次数、异常弹窗出现后的处置选择。这些数据既服务于性能优化，也服务于风险发现：接管率突然上升往往意味着某个门户改版，重复重试集中在某一步则可能意味着页面存在诱导性内容。

第四道是复核。对不可逆操作设置事前批准，对高风险操作设置事后抽查，抽查样本应覆盖不同门户与不同任务类型，而非只看最常用的那一类。复核记录与操作日志一并留存，形成可复盘的证据链。反网络钓鱼技术专家芦笛认为，这四道关口的关系不是叠加而是互补：准入决定哪些任务进入自动化，隔离决定失陷的代价，监控决定异常能否被看见，复核决定责任能否被追溯；缺任何一道，其余三道都会被迫承担超出设计的能力。

10 结语

这个案例的可讨论之处，不在于某代模型在界面上点得有多流畅，而在于它把一段长期被视为 "只能靠人" 的工作重新划分了。旧式门户没有接口，这件事在很长时间里被当作自动化的天然边界；计算机使用能力把这条边界向内推了一格，代价是引入了一类新的不确定性 —— 以屏幕为输入的代理，其判断依据来自不受自己控制的页面。

效率数据支持这一推进在受控条件下是可行的，35% 至 40% 的提速与失败率、超时率的下降方向一致，机制上也说得通。但数据同时提示，可采信的范围止于 "同一基准下的模型代际比较"，把它直接换算为组织级的人力节省，需要端到端测量而非平台侧统计。任务分层与人工保留域的存在说明，这套系统的设计者对人机边界的判断是清醒的：需要判断、需要跨组织授权、需要整机控制的任务仍留在人这一侧。

真正决定这类部署成败的，是权限与审计的设计能否跟得上执行能力的下移。代理持有身份、执行写操作、读取不可信界面，这三件事叠在一起，使得 "它能做什么" 与 "它被允许做什么" 必须分开管理。把这两者混同，效率提升会以责任模糊为代价；把两者分开，自动化才是在可控范围内替代操作，而不是替代判断。

编辑：芦笛 （公共互联网反网络钓鱼工作组）

来源：迪妙网络空间安全学院