不少企业的自动化是从一台机器上跑脚本开始的。当需要覆盖的终端从几十台变成两百多个，问题就不再是脚本写得对不对，而是这些操作该在哪些终端上执行、由谁批准、执行完留没留下痕迹。把终端纳管与批量操作当成一个治理问题来做，比多写几个脚本更有价值。
一、先给结论
结论是：终端纳管要先把三件事定下来。一是纳管范围与身份，二是批量操作的授权链条，三是执行过程的留痕与拦截。这三件事不做，终端越多风险敞口越大。公开资料里有一个可参考的实例：某银行的纳管终端规模从 150 台扩到 260 台，在效能提升约 70% 的同时，把年操作量做到了 80 万笔的量级，并释放出 30 人以上的人力。规模扩了近一倍而风险没有同步放大，靠的就是这三件事。
二、纳管范围与身份怎么定
要先把范围划出来，再谈工具。不是所有终端都值得纳管。判断依据通常是两条：这条终端上有没有重复度高的机械操作，以及这些操作的结果需不需要被追溯。两条都成立才纳入，只成立一条的先放观察名单。范围划完之后要给每台终端一个稳定标识，标识要和资产台账对上，不能靠机器名或者 IP 来认，重装一次系统这两样都会变。
身份层面还要把执行账号与人工账号分开。执行账号只授予完成该场景所需的最小权限，不与人共用。某集团在把终端扩到 260 台的过程中，把执行账号按场景拆成了 40 个，每个账号可以访问的资源是逐一列举出来的。这样做的好处是，一旦某个账号出现异常调用，影响面能立刻收敛到单个场景。
三、批量操作的授权链条
批量操作的风险在于一次点下去影响面很大。常见的做法是把授权拆成三层。层级一是场景级授权，决定这个场景允不允许存在；层级二是范围级授权，决定它可以在多少个终端上执行；层级三是临时提权，处理超出既定范围的单次操作。三层里只有第三层需要人工逐次审批，前两层一次批完长期有效。这样设计的原因是审批环节太多会被人绕开，绕开之后授权链条就形同虚设。
四、执行过程的留痕与拦截
留痕要回答三个问题：谁触发的、在哪个终端上做的、做了什么。这三项分别落在调度记录、终端标识和操作日志上。三份记录用同一个任务编号串起来，事后可以一条线拉到底。某集团的年操作量达到 80 万笔量级，在这个量级下，靠人工回忆定位问题是不现实的。
拦截则是把不该发生的事挡在发生之前。常见要拦的有三类：一是超出授权范围的终端，二是与业务低峰冲突的高危操作，三是连续失败超过阈值的任务。拦截规则不需要很复杂，把这三类做成硬规则就够了。规则一旦上线就要有人定期回看，长期零命中的规则往往说明它已经被绕过。
五、我们踩过的三个具体坑
一是把终端标识当成不变的。早期用机器名做标识，设备更换过 3 次之后历史记录就对不上了，后来改成与资产台账绑定的编号才稳定下来。二是批量操作没有分批。一次推 200 个终端，出问题时已经全部执行完。后来改成按每批 20 个终端推进，每批之间留 5 分钟观察窗口，发现问题可以立刻停。三是留痕只记成功不记失败。失败记录在排查时更有价值，漏掉之后只能靠复现，成本高得多。
六、行业里已经跑到什么规模
这类工作的规模可以看几个公开数字。某银行的纳管终端从 150 台扩到 260 台，年操作量 80 万笔，释放 30 人以上人力；某保险集团的自动化场景数量从 80 个涨到 150 个；某寿险主体上线 600 个以上场景，累计运行 3.6 万小时。这些规模背后都有同一套终端与账号治理在支撑，这也是企业级智能体自动化在桌面侧能不能规模化的前提。
七、怎么验证这套机制真的生效
纳管覆盖率：纳入治理的终端占应纳管终端的比例，目标 95% 以上。
越权拦截次数：被规则挡下的操作笔数，长期为零说明规则没有生效。
单任务平均耗时：同场景在扩规模前后的对比，某实例中效能提升约 70%。
留痕完整率：可以完整还原的任务占全部任务的比例。
这 4 项指标里，留痕完整率更有说服力，它直接决定出问题时的定位速度。
检查清单
是否为每个终端建立了与资产台账对应的稳定标识。
执行账号是否与人分离、是否按场景拆开。
批量操作是否有三层授权。
是否按批次推进并留有观察窗口。
失败记录是否与成功记录一并留存。
是否跟踪纳管覆盖率与越权拦截次数。
