5.5 智能自动化与机器人审计

5.5 智能自动化与机器人审计

执行类模式包括流程自动化（RPA加AI组件构成的"智能体"式流程）与物理机器人（含具身智能尝试）。本节审计它的成色：稳定环境里的确定性收益、维护悬崖、以及具身智能与演示视频之间的距离。

稳定流程里的印钞机

一家保险公司把理赔立案环节自动化：OCR读单证、规则引擎校验、分类模型路由案件，每件处理时间从十一分钟压到九十秒，准确率还略升。执行类模式在这种"高重复、强结构、稳定环境"的流程里成色极高，因为它的收益模型极其干净——省下的人力时间乘以件数，几乎不用辩论口径。审计这类项目的关键反而是别被平均数骗：处理时间的中位数漂亮，但百分之五的异常件要人工兜底，兜底队伍的规模和技能保持才是长期成本所在。

def automation_economics(cases_per_month=40_000, minutes_saved=9.5,
                        rate_per_hour=60, run_cost=8_000,
                        exception_rate=0.05, exception_minutes=25):
    """示意：含异常兜底的自动化账。"""
    straight = cases_per_month * (1 - exception_rate)
    exc = cases_per_month * exception_rate
    saving = (straight * minutes_saved / 60 * rate_per_hour
              - exc * exception_minutes / 60 * rate_per_hour * 0.3)  # 异常态省三成
    return saving - run_cost

print("月净节省: %.0f 元" % automation_economics())
print("异常率升到两成时: %.0f 元" %
      automation_economics(exception_rate=0.20))
# 异常率是这条业务线的脉搏：异常率翻倍时，净节省掉一大块。
# 监控异常率 = 监控这台印钞机的健康。
​

维护悬崖

执行类项目的名声坑叫维护悬崖。界面自动化（模拟人在老系统上点按）对目标系统的任何改版都极其脆弱：一个按钮挪位置，几十条流程脚本集体失效。悬崖来得很突然——上线后前六个月几乎零维护，某次系统升级后维护工时陡增，此时如果原开发团队已解散，项目就从资产变成负债。审计要点：数一数流程依赖的界面元素个数、问一句目标系统的改版计划、确认有没有专门留守的维护预算。凡是"做完就走"的交付模式，维护悬崖几乎必然发生。

def survival_curve(months=24, ui_change_prob=0.06, decay_after=0.35):
    """示意：界面自动化的存活概率——悬崖结构。"""
    alive, results = 1.0, []
    for m in range(1, months + 1):
        if alive > 0.5:
            alive *= (1 - ui_change_prob)          # 前期：小概率失效
        else:
            alive *= (1 - ui_change_prob - decay_after)  # 后期：维护缺位加速崩塌
        results.append(round(alive, 2))
    return results

curve = survival_curve()
print("第6个月存活 %.0f%% -> 第12个月 %.0f%% -> 第24个月 %.0f%%"
      % (curve[5]*100, curve[11]*100, curve[23]*100))
# 真实的悬崖不会出现在验收报告里——验收总在第六个月之前完成。
​

具身智能：演示与工地的距离

物理机器人是执行类的高峰也是审计最需要冷静的地方。演示视频里机器人叠布丁、拧螺栓、分拣杂物，背后往往是遥操作、海量尝试次数的剪辑、或专为演示布置的固定光照与物品排布。产业现场的判断标准朴素得多：循环时间（做一件事多少秒）、成功率（一万次里失败几次）、换产时间（换一个任务要重新示教多久）、部署环境是否要围栏。审计具身项目，让这四个数对上场景需求，比看任何演示视频都可靠。目前成色最好的物理自动化仍是结构化环境里的传统工机械臂——它证明了这条规律：执行类的成色与环境结构化程度正相关，大模型带来的通用灵活性在非结构化环境里还没跨过可靠性的门槛。

图：维护悬崖的形成过程

悬崖的教训推广到整个执行类模式：自动化的寿命等于"环境稳定期"与"维护在位期"的较短者。两个期限都可以在立项时谈判——把界面依赖写进与上游系统的升级协调流程、把维护预算写进合同而非省略，悬崖就能变成缓坡。可惜这两条恰恰是最容易被砍掉的"非功能性需求"，因为它们不影响验收测试的任何一项指标。

结果、解读与变式

背景（理赔流水线）、操作（异常率账本、存活曲线、四指标对照）、结果（维护悬崖与具身距离的量化口径）完整。解读：执行模式的成色规律是"环境越稳越像印钞机、环境越乱越像碎钞机"，以及维护预算决定寿命。变式：财务对账自动化、客服工单自动处置、仓储分拣机器人全部适用同一套审计动作。下一节是全册最后一站：失败模式年鉴。

智能体的新瓶与旧酒

近两年"智能体"概念把流程自动化重新包装：大模型理解指令、拆解步骤、调用工具、处理异常。审计视角下它解决了旧RPA最痛的两点——脆弱的界面依赖（改用接口与语义理解）与僵硬的异常处理（大模型能理解没见过的出错方式）。但它引入了新的不确定性：旧RPA错得确定（脚本到哪一步断掉一目了然），智能体错得随机（同一输入两次执行路径可能不同）。执行类场景对确定性要求极高，所以当下成色最好的形态是混合架构：主干流程仍是确定性脚本，大模型只负责异常分支的理解与路由。审计智能体项目时看这个比例——大模型管的分支越多，越要追问每类分支的失败率与兜底设计。

人机配比的最后一笔账

执行类项目收官时还有一笔人机配比账：全自动省人力，但保留少量人工席位可以维持技能存量与应急能力。全裁掉运维岗位的项目，在第一次大故障时就会发现会修系统的人已经走了。合理的配比没有通用数，但审计意见里应该写明保留哪些岗位、保留多少、他们的技能如何维持——这是执行类项目给自己买的保险，保费不高，理赔时救命。