一个部门用起来顺手，铺到第二个部门时通常不会太顺利。这也是企业级智能体自动化从单点走向规模化时必然要过的一道坎。场景从几十个涨到上百个，管理方式如果不跟着换，先崩的往往不是技术，而是维护节奏：一个流程改动要通知十几个团队，改完还要逐个回归。
一、先给结论
结论是：场景数量翻倍，管理重心要从"建"转到"管"。真正需要建立的是三样东西——统一的场景台账、可复用的变更与回归机制、面向运营方本身的指标与告警。这是规模化之后能否持续跑下去的分水岭。
二、场景台账是治理的地基
没有台账，规模化之后连"一共有哪些场景"都答不上来。台账至少要记 6 个字段：业务归属、责任团队、上游依赖系统、日均运行量与耗时、当前状态、变更记录。我们建议由业务方维护业务归属与状态，运营方维护技术依赖，两边分摊，避免一份台账只有一个人能改。台账字段控制在 6 个以内是有意的，字段越多越容易失修。
三、变更与回归要按影响面分级
所有改动都做整批回归，成本承受不起；都不做回归，风险又攒着。我们的分级是按上游依赖的数量定。
- 依赖 1 到 2 个系统的小改动：本场景回归即可。
- 依赖 3 到 5 个系统的中等改动：相邻场景抽验。
- 依赖 6 个以上或涉及公共组件的改动：相关场景整批回归，并通知所有业务归属方。
分级之后，80% 的改动可以在最小范围内验证，剩下的高风险改动反而有资源做深。
四、指标与告警要看运营方真正关心的东西
给运营方的看板很容易做成"任务成功数"。但运营方真正担心的是三类事：某类场景是不是悄悄不跑了、运行耗时是不是悄悄变长、失败是不是集中在某几个系统。所以我们看三类指标加一个告警规则。 - 静默失败率：任务本身报成功但业务侧实际没有生效的比例。
- 耗时环比：同一场景前后两次运行的耗时对比，涨到设定倍数就告警。
- 失败集中度：失败是否集中在少数上游系统。
- 长尾场景数：连续多日零运行量的场景数量，用于清理僵尸场景。
五、我们踩过的三个具体坑
- 台账一个人维护。此人调岗之后台账停更，半年没人核对。改为业务方与运营方共同维护，各自认领字段。
- 所有改动都要求整批回归。团队被拖死，后来有人开始绕过流程私下改。分级之后回归压力下降，流程才被遵守。
- 只看任务成功数。一个场景因为上游停用了账号，每次都"成功"退出，运营方三个月后才发现。补了静默失败率才抓到。
六、行业里已经跑到什么规模
公开资料里可以看到规模变化的轨迹：某保险集团的自动化场景数量在两年内从 80 个增长到 92 个再到 150 个；另有保险集团累计上线的场景超过 600 个，累计运行时长 3.6 万小时；某保险集团采用 1 个总厂加 3 个分厂加 N 个分公司的布局，全集团运行机器人规模达到 2000 多个。规模从几十跨到几百，治理方式必须同步换档。七、怎么验证这套机制真的生效
- 台账完整率：字段齐全且 1 个月内更新过的场景占比。
- 回归覆盖率：按分级要求应回归的场景，实际完成回归的比例。
- 静默失败发现时长：从静默失败发生到被指标发现的平均天数。
- 僵尸场景占比：连续多日零运行量的场景占比，应随时间下降。
这四项里回归覆盖率很容易被忽略，但它是风险积累的直接指标。检查清单
- 台账是否覆盖 6 个字段并分配到不同维护方。
- 变更是否按上游依赖数量分三级回归。
- 指标是否包含静默失败率、耗时环比、失败集中度、长尾场景数。
- 是否有僵尸场景清理机制。
- 运营方是否参与指标定义与看板设计。
