锁屏之后它还在点鼠标：智能体离席作业要补的四组语义｜洹拓科技
一、第一组语义：执行体绑在哪个登录会话上
一款桌面助手客户端的公开升级里有两件事值得工程侧单独看：录制技能的覆盖范围从浏览器扩展到桌面软件，演示一遍操作流程、再口述几句约束，就能把步骤与讲解存成个人技能；桌面端新增锁屏执行，在一个名为“允许在锁屏时工作”的开关打开后，需要操作电脑的任务可以在锁屏状态下继续跑，用户从手机下发任务并查看结果，回到电脑前解锁随时接管。
先把运行形态定性。界面级自动化通常经由图形会话里的无障碍接口或事件注入完成，也就是说，动作要发给一个正在登录的桌面会话。所以“锁屏后仍在跑”不是把任务交给了一个可迁移的作业队列，而是把执行体绑死在一个具体的登录会话上。这个区分决定了后面所有事情的性质：队列是可重建的，会话不是；队列有明确的作业标识，会话只有“谁的、哪台、还在不在”。
公开说明给了三个前提：设备保持开机、保持联网、客户端持续运行且处于唤醒状态。把这三条逐条翻成失效表现，问题就从“能不能跑”变成了“失效时任务有没有留下明确状态”，而后者更要紧。
| 前提 | 典型失效表现 | 用户在手机上能否立刻知道 |
|---|---|---|
| 保持开机 | 合盖或闲置进入休眠，执行体随会话一起停住 | 不能，通常要回来解锁才发现；有公开实测提醒，锁屏工作不等于合盖也能工作，长时间合盖且电量低于设备设定阈值时该能力不可用，这个实测只作失效举例，不作为本篇结论 |
| 保持联网 | 任务在本地继续跑，结果送不回手机 | 不能，只能靠结果缺失反推 |
| 客户端持续运行 | 内存压力或用户手动退出把客户端回收 | 不能，任务状态停在最后一个上报点 |
| 会话仍在 | 注销或切换用户后，那个登录会话不存在了 | 不能，没有任何界面提示会话已经消失 |
| 锁屏本身 | 输入注入的目标不再是桌面，而是解锁界面 | 能，但这只说明动作被拦下，不说明任务为什么停 |
另一处缺口来自入口本身。从手机向这台机器下发任务，是第二条控制通路，它带来一个必须显式建模的归属问题：一个任务对象要同时写下哪个账号、哪台设备、哪个会话，三样缺一样，同一账号下的多台设备就会出现“谁在跑这个任务”说不清；设备下线之后，这三元组还要能查到历史，否则事后无法定位当时那次执行落在哪台机器上。
二、第二组语义：接管到底能接哪一层
“回来解锁随时接管”是一句功能描述，不是接口定义。要落到可判定，得先回答四个问题，缺一问它就只是一个界面入口。
- 接管的是什么：当前这一步、整个任务，还是只能事后看结果？
- 接管瞬间任务处于什么状态：暂停、终止还是继续运行？
- 已经写入的文件与已经发出的动作怎么处理：回滚到哪个边界，还是保留现场等人工判断？
- 接管之后再交回去，从哪里续：当前步、上一个检查点，还是从头重跑？
这四问在人在屏幕前时不像问题，因为用户可以看见哪一步正在跑、可以手动停掉。锁屏期间人不在屏幕前，手机侧能给的往往只有“停止”这一个动作，于是“接管”与“终止”被混成同一个按钮。要在交付时把它们分开：停止是放弃后续步骤并保留已产生的现场；接管是接手执行位置、保留进度并继续推进。二者对已写入文件的要求完全不同，前者要留现场，后者要能说明哪些步骤由智能体完成、哪些由人接手。
还需要一条明确的状态语义：接管动作发生时，正在执行的那一步要能被判成“已完成”“已撤销”或“结果未知”三种之一。“结果未知”不是可有可有的第三态，它对应的正是最麻烦的情形：动作已经发给应用，进程在写文件时被接手。缺这个态，事后就只能靠猜。
三、第三组语义：无界面期间要留的最小作业记录
锁屏期间用户看不到屏幕。如果对外说法是“在手机上下发并查看结果”，那手机看到的是结果，不是过程，而事故恰恰发生在中间态。所以无界面期间必须留下的最小作业记录是六项，一项都不能省。
- 每一步的目标窗口与控件：写窗口标题与控件路径，而不是只写“点击某处”；
- 界面结构快照或截图：作为该步动作的现场依据；
- 动作时间戳：与设备时钟同源，跨端对照时要能看出先后；
- 被创建与被修改的文件清单：路径、动作类型、修改前后大小；
- 失败时的重试次数与停止原因：区分“重试后成功”“放弃这一步”“整单终止”；
- 任务结束时的汇总：步骤数、耗时、失败项与产物位置。
六项要落在哪里也要定：只存在客户端本地，设备回收或重装后就查不到；只回传摘要，中间态仍然缺失。稳妥的做法是过程记录留在设备侧并保留可导出接口，摘要与产物清单回传到账号侧，两边用同一个任务标识对上。
通道设计要跟上。命令通道与结果通道必须分离，否则一条通道中断时既无法判断指令有没有发出，也无法判断结果有没有回来。结果回传到手机这一格还有内容边界：整屏截图可能带进邮件正文、文档内容甚至凭据输入框，所以要定义回传粒度，分成文字摘要、控件级结果、整屏图三种粒度，默认取最小的一种，由任务显式声明才允许升级。这一步不是体验取舍，是数据外流面的取舍。
四、第四组语义：录一遍形成的技能是不是一条规则
录制技能的公开用法是：用户演示一遍操作流程，通过语音补充处理范围与命名规则，比如只整理指定文件夹、按日期命名，录制结束后客户端把步骤与讲解整理为个人技能，后续处理同类任务时直接调用并指定新的处理对象，减少重复说明。这里的关键失真在于：演示是一条具体路径，不是一个规则。落成技能前必须回答四问。
- 这次演示里哪些是常量，哪些是参数？演示时随手点开的那个目录，是固定路径还是每次都要换的输入？
- 口述约束有没有变成可断言的作用域？“只整理指定文件夹”要落成一条边界检查，而不是留在语音记录里。
- 换了新对象后哪些前置假设会失效？同名文件是否已存在、目录层级是否一致、窗口尺寸与控件位置是否变化、目标软件版本是否还按原来的界面布局响应。
- 失败时按什么策略停止？遇到第一个不符预期的对象就停，还是跳过继续、最后汇总。
四问有答案之后，技能才算一个可交接的东西。交付物清单六件：作用域声明、输入参数表、允许读写的位置白名单、幂等与回滚说明、失败样例与预期表现、该技能末次验证通过的记录。这六件里最容易被省略的是作用域声明与白名单，因为它们不影响功能跑通，只影响跑错时跑多远。至于如何为技能构造回归集，那是另一件事，本篇不展开。
五、四组语义共同的前提：会话级控制权与高危动作的独立确认
上面四组都建立在同一条事实上：用户授权后，客户端可以自动查看屏幕并模拟鼠标键盘。这等价于把该会话下所有应用的操作权一次性交出。与逐应用授权相比，多出来的不是几个权限项，而是“无边界”这一性质：会话里没有“这个应用不给看”的层次，屏幕上出现什么，就在可读范围内。
因此高危动作要单列，不能沿用同一次授权。
| 高危动作 | 为什么单列 | 独立确认通道要满足什么 |
|---|---|---|
| 删除与覆盖文件 | 现场不可复原，且常常是批量执行 | 确认对象要写明路径与数量上限 |
| 发送对外消息与邮件 | 一步之后内容已离开本机 | 确认与执行不在同一会话内完成 |
| 支付与转账 | 产生外部不可逆后果 | 确认有有效期，过期重取 |
| 修改系统设置与凭据 | 改变后续所有动作的前提 | 未确认时任务进等待态，不得超时自行决定 |
判据是这一条：确认通道要与执行通道不同源、能表达对象范围、有有效期、并且在人不在场时也能被触发。锁屏作业期间人本来就不在电脑前，“用户先前授权过一次”不能顶替这四条。
六、企业终端侧要回答的三件事，以及界面自动化的准入
企业终端管理侧对这类客户端要能回答三个问题：它在哪个会话里执行、用的是谁的凭据、有没有把内网系统的界面内容送进模型上下文。第三个问题最容易被漏，因为直觉上会想用出口域名清单去管，而按域名清单拦不住它：它读的是屏幕像素与控件，不是某个接口地址，域名清单管的是网络目的地，管不住“屏幕上有什么就被读到什么”。
这张对照对甲乙双方是同一张。我们交付给客户的东西，被这类客户端操作时会出现：界面上的数据被整屏读走；批量动作把审批流一次点完，每一级审批都由同一个执行体按下；报表页被当成导出通道使用；用户登录后的会话被代客操作。因此接入企业流程的界面自动化要有明确准入，写成两句可执行的声明：按系统声明哪些界面可被自动操作、哪些动作必须人工确认；在服务端把“由自动化工具发起”作为一类可识别的来源记录下来，落到请求字段上，而不是只写在注意事项里。来源一旦可识别，事后追责与限流都有依据。
四组语义验收下来，交付物其实是四份东西：会话绑定表、接管状态定义、离席作业记录规范、技能交付物清单。洹拓在给客户做智能体落地时把这四份当作前置件，而不是上线后的补充材料，原因很直接：一个能读屏、能动鼠标、能在人不在时继续工作的执行体，缺的不是能力，是这几个字段的名字。