RPA机器人编排的适用边界：脆弱性与不应替代核心业务流程

机器人流程自动化（RPA）解决的是没有API的传统应用问题——很多旧系统开发时没考虑远程连接需求，RPA工具通过屏幕抓取、图像识别、OCR自动操控现有图形界面，本质是更强大的宏录制工具。就BPMN流程而言，RPA机器人只是实现服务任务的一种方式，且机器人应该只实现单一功能。RPA机器人天生比真正的API调用更脆弱，因为它依赖的用户界面可能随时变化——原则上任何时候都应优先使用API，RPA只在系统确实不提供API、或IT开发资源暂时跟不上业务紧迫性时才作为权宜之计（例如计费系统入职数据录入延迟导致用户流失，业务部门等不及IT排期）；此时业务部门甚至可以在无需IT介入的情况下快速上线RPA机器人解决燃眉之急，但要清醒记录这是技术债务，后续应换回真正的API调用——正因为这种架构下机器人只是实现服务任务的一种可替换方式，切换到API调用时甚至可能完全不需要改动流程模型本身。可以用人工任务作为RPA机器人内部出错时的后备，把80%的正常案例交给机器人自动化、把异常情况路由给人工处理。最需要警惕的风险是：把RPA当作低代码流程自动化平台去实现核心业务流程，这是一个泥潭——RPA流程本身也是一种流程模型，但它把业务流程逻辑和用户界面控制顺序混在一起，[[低代码的局限性为什么它无法替代软件开发]]提到的所有缺陷在这里同样成立，工作流引擎才应该始终是控制整个流程的主要动力，RPA机器人只应承担其中因故无法调用API的某一个步骤。