流程画得再美，员工跑另一套？BPM死结与Agentic BPM破局

一张发票因为缺少采购订单编号，在某制造企业的审批系统里躺了三天。系统没有故障，也没有员工故意拖延，每一步流程都合规：财务系统提示异常后，自动流转到人工队列，处理审批的员工每天要处理两百多条这类例外，轮到这张发票时已经是第三个工作日。流程图上这叫“异常处理分支”，现实里却只能是“等人”。

很多企业的流程负责人都曾表达过类似的困惑：我们的BPM系统运行稳定，但前提是流程里不能出现未预设的情况。号称管理流程的系统，最怕的恰恰是流程本身的变化。传统BPM把流程管理变成了“路径设计”，却始终没解决“路径之外怎么办”的问题。AI Agent的出现，重新把这个搁置了三十年的行业痛点摆到了台前。

为何当前需要重新审视BPM？

从上世纪90年代算起，BPM这门学科已经走过了近三十五年的历程。但近两年，随着大模型驱动的智能Agent席卷全球商业领域，“重新讨论BPM”突然成为行业热点。根本原因在于：企业流程正在发生的深层变化，已经超出了传统BPM的假设边界。

过去三十年，企业流程管理的核心命题是标准化：把依赖口头约定和个人经验运转的混乱业务，转化为可复制、可监控、可审计的标准动作。BPM在这方面表现出色，流程管理套件、ERP系统、工作流引擎共同构成了企业数字化的底层骨架。

但近两年，流程本身的性质正在发生改变。越来越多原本需要人工判断完成的工作，被要求纳入流程管理范畴，而这些工作恰恰是传统流程建模最不擅长处理的领域。企业重新审视BPM，主要源于三个核心转变。

从流程自动化到工作自动化

这是一个容易被忽略的关键转变：过去我们自动化的是“任务”，现在要自动化的是“工作”。两者虽仅一字之差，指向的却是完全不同的管理对象。任务可以被放进流程图的方框，输入、输出和规则都能被提前定义；而工作则包含判断、权衡、沟通和协调，是一套需要主动思考的行为组合。

BPM过去三十年主要解决的是任务自动化的问题，而工作自动化始终游离在主流视野之外。有企业实践显示，引入Agentic AI后，原本需要持续人工干预的跨4个地区的复杂全球项目管理流程，实现了端到端自主运行，只有真正需要人类判断的例外情况才会上报。过去，“例外”是流程设计者最头疼的部分，因为它意味着无法预先建模；而现在，企业开始尝试让系统自主处理例外，而非将所有问题都甩给人工。

非结构化任务正在进入流程

传统BPM擅长处理结构化、重复性、规则明确的任务，比如报销审批、订单处理、请假流程等，这些任务的输入和输出都能被提前定义为表单和规则。但如今，越来越多需要被流程化的工作并不具备这些特征：客户投诉处理需要理解上下文、判断情绪并调取历史记录；供应商争议需要跨部门信息整合和协商；合规审查需要阅读非结构化文档并做出有依据的判断。这些工作过去只能依靠人工完成，因为它们需要的是“理解能力”，而非简单的“执行能力”。

判断、例外、跨系统协作成为新痛点

企业对BPM厂商的需求已经发生变化：十年前企业会问“能不能帮我把这个表单流程自动跑起来”，而现在则会问“能不能帮我接管那些需要人盯着的环节”。这说明企业真正想解决的，早已不是“让已知流程跑得更快”，而是三类长期存在的新问题：

• 判断类问题：比如一笔报销是否合规，不能仅靠简单的金额对比，需要结合政策、历史数据和具体情境进行综合判断；
• 例外类问题：比如发票缺少PO编号、客户信息不全、系统数据冲突等，这类“长尾琐事”占据了流程人员大量的时间；
• 跨系统协作类问题：以客户入职流程为例，可能需要同时触达CRM、ERP、合规系统和第三方征信接口，传统流程引擎只能调用这些系统，却无法理解它们之间该如何协同。

相关研究显示，BPM从业者当下最迫切的痛点集中在数据不一致、手动干预频繁、流程瓶颈难以识别、改进建议缺乏可执行性等方面。传统BPM能够绘制流程、跑通路径，但真正卡住企业效率的判断、例外和协作问题，恰恰是它天生的盲区。

AI Agent的出现，让自动处理这类判断类问题首次具备了技术可行性。过去面对这类问题，企业唯一的解法是增加人手，无论是外包团队还是内部“流程救火队”，本质都是用人力填补流程设计留下的空白。而现在，填补这道空白的不再是人力，而是能够理解目标、进行推理、调用工具的自主行动者。

AI Agent并非只是更快的自动化工具，而是能够理解目标、自主推理、调用工具，并在没有明确指令的情况下自行决定下一步行动的“行动者”。过去仅在学术圈小范围讨论的BPM理论，近两年被反复重新审视，核心原因就在于填补“模型-现实鸿沟”的技术终于出现了。这条鸿沟指的是：企业绘制的流程模型，和员工实际执行的流程从来都不是一回事。流程图是静态的，而现实是动态的，每一个例外都需要人工干预，而在真实企业中，例外才是常态而非意外。

BPM的核心本质与演进脉络

业务流程管理（Business Process Management），简言之是一套方法论：识别、绘制、定义、监控并优化企业内重复发生、有明确起点和终点的工作。它既是一种管理理念，也发展出了对应的技术工具。

BPM诞生的背景十分朴素：早期企业运营高度依赖“老师傅经验”和“口头约定”，效率低下、风险高，人员变动后业务极易陷入混乱。BPM的目标就是将这种“手艺活”转化为“工程活”，通过BPMN等标准化图形语言将流程可视化，配合ERP系统，让企业运营从依赖经验的艺术，转变为可复制的标准化工程。

BPM的管理范畴与生命周期

BPM关注的是端到端的业务流程，而非零散的单个任务，比如从客户下单到货物交付、从员工入职到权限开通、从采购申请到付款完成等。它关心的核心问题包括：这件事谁来做、什么时候做、按什么规则做、完成后交给谁。

BPM有一个经典的五阶段闭环模型，从90年代沿用至今，几乎所有BPM教材和工具都围绕这个模型展开：设计→建模→执行→监控→优化。设计阶段确定流程的标准形态；建模阶段用BPMN等工具将流程可视化；执行阶段让流程真正运转起来；监控阶段跟踪流程运行状态；优化阶段则根据监控结果反向调整流程设计。

这个闭环看似完美，但有一个重要前提：设计与现实之间的偏差足够小。如果偏差过大，闭环就会卡在“监控”和“优化”之间，因为很少有企业有精力频繁重新建模。

BPM与工作流的关系

BPM和Workflow（工作流）常被混淆，但二者是包含与被包含的关系。简单来说，Workflow负责管理单个任务的流转，比如谁审批、谁处理、下一步交给谁；而BPM是更高层级的管理框架，Workflow只是BPM落地执行的手段之一，BPM还涵盖流程治理、绩效分析、持续改进等更宏观的内容。可以将BPM比作公司的管理制度，而Workflow则是具体的审批单流转路径，制度决定“要不要审批、谁有权审批”，流转路径则决定“这张单子具体怎么走”。

传统BPM的核心局限

传统BPM能够成立的核心假设是：流程的执行路径可以在事前被完整定义。这个假设是整套BPMS设计的基础，在重复性、规则明确的业务场景中完全可行。但一旦遇到未被预见的情况，比如新的客户类型、新的合规要求、系统间的数据冲突，这个假设就会崩塌。传统BPM的应对方式是将这些情况标记为“例外”，转交人工处理。这个结构性问题，传统BPM用了三十年都没能真正解决：它假设世界是静态的、可预定义的，但企业运营的真实世界从来都不是。

从BPM到BPMS：流程进入软件时代

有了方法论之后，需要将其转化为可落地的工具。BPMS（Business Process Management Suite，业务流程管理套件）就是将BPM方法论转化为可执行软件系统的平台。2000年前后，Oracle、IBM、SAP等厂商陆续推出商业BPMS平台，让BPM第一次从管理理念变成了企业可以直接购买部署的软件产品。

一个成熟的BPMS平台通常包含六大核心模块：

这套架构首次让“流程”能够被软件系统完整承载，而不只是停留在纸面上的制度文档。但问题也随之而来：整个BPMS的运转逻辑，仍然建立在“规则引擎能够穷举所有情况”的假设之上。规则引擎编写得越细致，系统看起来越“聪明”，但这种聪明有明显的天花板——企业现实的复杂度，永远比规则引擎能覆盖的分支要多。

BPMS在实际落地过程中也面临诸多困境。相关数据显示，传统BPM系统的实施周期普遍需要6到18个月才能交付有实际价值的成果，而真正达到“流程定义成熟”标准的企业比例仅有38%。很多企业的BPMS项目，还没等到规则引擎开始发挥威力，就已经在冗长的实施周期中耗光了耐心。

Workflow Automation：让流程自动运行

BPMS解决了流程软件化的问题，下一步需要解决的是“让流程自动运行”，这就是Workflow Automation（工作流自动化）。其核心逻辑是：流程决定谁在什么时候做什么。

Workflow Automation的运转方式可以概括为四个关键词：

• 规则驱动：每一步的流转方向由预先设定的规则决定，比如“金额超过5万元，流转给部门总监审批”；
• 固定路径：整个流程的走向在设计阶段就已确定，运行时系统只是按照预设路径执行，没有“动态改变路径”的空间；
• 人机协作：自动化将人员从流转和提醒等机械工作中解放出来，但判断和签字等环节仍需人工完成，这是传统工作流自动化最常见的协作模式；
• 自动任务分派：系统根据角色、负载和优先级，自动将任务分配给具体的人或部门，减少了大量人工协调的时间成本。

这一代自动化确实带来了真实的效率提升，但本质并未改变：流程还是那个被提前设计好的流程，自动化只是让它跑得更快、更稳定，并没有让流程本身变得更“聪明”。一旦遇到规则未覆盖的场景，工作流自动化系统的反应始终一致——卡住，然后转人工处理。

Workflow Automation能够真正普及，离不开一套“既能绘制、也能直接运行”的标准。前面提到，BPMN在2004年由BPMI提出时，更多只是供人阅读的图形符号；直到2011年OMG发布BPMN 2.0，流程图才被赋予可执行语义，引擎可以直接读取模型驱动流程流转，无需再为“设计”和“执行”维护两套不同的模型。这也解释了为何固定路径式的工作流在企业中应用最广：它足够简单、可控，适合那些步骤明确、少有例外的流程，但一旦流程中混入判断和例外场景，它的短板就会暴露无遗。

RPA：自动化延伸至系统操作层

Workflow Automation留下的空白，正是RPA出现的契机。Workflow Automation解决的是“流程内部的任务流转”问题，但企业运营中还有大量时间消耗在另一项工作上：在不同系统之间搬运数据。比如财务人员需要将ERP系统中的数据导出，粘贴到Excel表格后再上传到报表系统；客服人员需要将客户信息从CRM系统复制到工单系统。这些操作并不属于“流程设计”的范畴，而是流程执行过程中大量重复的纯手工“体力劳动”。

RPA（Robotic Process Automation，机器人流程自动化）的解决方案是：不改动底层系统，而是像人类一样操作界面，通过点击、输入、复制、粘贴等动作，将这些重复性的手工操作交给软件机器人完成。2010年代初，UiPath、Automation Anywhere、Blue Prism等厂商将这个赛道做大，企业第一次发现，“自动化”可以不用改造底层系统架构，直接在界面层面就能实现。这种“不打扰现有系统”的特性，正是RPA落地速度快的原因——不需要等待IT部门排期改造接口，购买后即可直接使用。

RPA和BPM的关系更偏向互补而非替代：BPM负责定义流程的整体逻辑和路径，RPA负责执行流程中那些重复、规则明确的具体操作。可以说BPM是“大脑”，而RPA曾经被寄予厚望成为“手脚”。但RPA很快暴露出明显的局限性：它的工作方式是“录制-回放”，一旦界面发生细微变动，机器人就可能直接宕机；遇到从未见过的页面布局或数据格式，它完全没有应对能力。更重要的是，RPA完全不理解业务目标，只是精确地重复预设的操作步骤，给什么指令就执行什么指令，不会主动思考。

RPA让机器能够操作系统，但并没有真正理解业务目标。很多企业在部署RPA后，会产生“流程自动化已经完成”的错觉。实际上RPA只是替换了“人的手”，流程背后的判断逻辑仍然完全掌握在人类手中。一旦涉及“这个异常该怎么处理”“这笔数据该流向哪个系统”等问题，RPA立刻失灵，只能将任务扔回人工队列。系统性文献综述总结的RPA在BPM中的应用局限性显示，RPA缺乏对业务语境的理解能力，在流程发生变化时适应性极差。它解决的只是执行层面的重复劳动，而非认知层面的判断难题，这也构成了它和后续AI Agent之间的根本分野。

Process Mining：让企业“看见”真实流程

前面的内容大多在讲流程如何设计、如何执行，而Process Mining（流程挖掘）则换了一个角度，关注流程实际上是如何运行的。Workflow Automation和RPA关心的是“流程有没有跑通”，而Process Mining关心的是“企业真实运转的流程到底长什么样”，这件事在过去只能依靠管理层的主观想象。

真实情况往往出人意料：管理层认知中的流程，和员工实际执行的流程之间存在系统性偏差，也就是我们之前提到的“模型-现实鸿沟”。2018年到2022年前后，Process Mining技术逐渐成熟，以Celonis为代表的公司让企业第一次有能力从系统运行日志中，挖掘出真实的流程运行情况，不再依赖管理层的主观设想。

Process Mining的原始数据来自系统运行过程中产生的事件日志：每一笔操作、每一次状态变化、每一个时间戳都会被记录下来。这些原本用于排查故障的日志，如今成为了“看见真实流程”的第一手证据。将事件日志输入Process Mining算法后，系统可以自动“重建”出流程真实运行的路径图。这张图和企业原本绘制的BPMN流程图经常存在较大差异：有的预设分支从来没有人走过，而有的“例外路径”反而成为了日常操作中的主流路径。

Process Mining的核心价值体现在三个方面：一是流程发现，通过日志还原真实流程；二是一致性检查，将真实流程与设计流程对比，找出偏离标准的环节和原因，让“流程合规”从一句口号变成可量化的具体指标；三是流程优化，基于真实流程数据找到真正的瓶颈所在，让流程优化从依靠经验判断转变为有据可依的科学动作。

Process Mining在整个技术演进链条中的位置常常被低估。它表面上只是一个分析工具，但实际上为Agentic BPM的后续发展提供了最关键的基础设施——感知能力。没有能够实时感知流程真实状态的系统，AI Agent就无法做出合理的决策。这也是为何在后续的Agentic BPM架构讨论中，Process Mining会被反复提及为“代理感知与决策的基础”。

Intelligent Automation：自动化迈向智能化

将前面提到的BPM、Workflow Automation、RPA和Process Mining整合起来，就形成了业界所说的Intelligent Automation（智能自动化），这一融合在2018年前后开始显现。其核心思路是将AI能力（最初主要是机器学习模型，用于分类、预测、异常检测等）嵌入到自动化流程的各个环节，让系统不再只是单纯“按规则执行”，而是能够根据数据做出一定程度的智能判断。

但这个阶段的“智能”仍然是局部的、点状的。一个机器学习模型或许能够判断“这张发票大概率存在欺诈风险”，但它不会负责决定“接下来该如何处理这张发票”。决策权仍然掌握在流程规则和人类手中，AI只是在某个判断节点上充当“顾问”。

2019年，Gartner在“2020年十大战略技术趋势”中将“超自动化”列为首位，用来形容将RPA、AI、流程挖掘等多种技术组合在一起，覆盖“发现—分析—设计—自动化—度量—监控—再评估”全流程的自动化思路。在Gartner的定义中，智能BPM套件是超自动化的核心组件之一，因为它提供了将各类自动化技术整合编排的流程底座。Gartner同时预测，到2024年，企业通过将超自动化技术与重新设计的运营流程结合，可将运营成本降低30%。

Intelligent Automation并非某一项单一技术，而是一套“将前面所有技术模块整合起来”的组合方式。这套组合也直接引出了下一个阶段的问题：当生成式AI出现之后，AI能不能从“顾问”升级为“流程执行主体”？

AI-enabled BPM：AI正式进入业务流程

2023年到2024年，生成式AI浪潮全面爆发，BPM社区开始系统性探索大语言模型与流程自动化的结合方式，这一阶段通常被称为AI-enabled BPM。其典型应用方式包括：

• AI辅助决策：在审批节点，AI根据历史数据和当前上下文给出决策建议，由人类做出最终判断；
• 文档理解：将合同、发票、邮件等非结构化文本解析为结构化信息，大幅减少人工录入的工作量；
• 自动分类：将客户工单、投诉内容、申请材料等自动分类到对应的处理队列；
• 流程预测：基于历史流程数据，预测某个案件接下来大概率会走到哪个节点、需要多长时间；
• 异常检测：比传统规则引擎更灵活地识别出“看起来不太正常”的流程实例，主动发出预警；
• 智能推荐：为处理人员推荐下一步最可能有效的操作路径。

这些能力确实让流程“聪明”了不少，但一个关键问题也随之浮现：AI是在帮助流程，还是已经开始成为流程的执行主体？

AI-enabled BPM阶段的AI，无论能力多强，始终扮演的是“辅助”角色。它提供建议、预测结果和分类结果，但最终“做什么”和“怎么做”的决定权，仍然掌握在人类或预先设计好的规则引擎手中。AI没有“目标”，它只有“任务”：给它一份文档，它负责将信息提取出来，仅此而已，它不会主动思考“提取出来的信息接下来该如何使用，这个流程的终极目的是什么”。这个差别，正是接下来要讨论的AI Agent与前面所有阶段的本质区别。

Agentic BPM：BPM的下一个转折点

MIT Sloan与BCG的联合调查显示，2023年已有35%的受访企业部署了AI Agent，另有44%的企业计划在近期部署。Gartner预测，到2026年底，将有40%的企业应用集成AI Agent，相比2025年不足5%的比例，增长接近八倍。这组数字背后，反映的并非只是某一个工具的流行，而是一种能力的质变。

这种质变到底新在哪里？要看清这一点，需要先拆解AI Agent与前面那些AI能力之间的区别。AI Agent的完整链路可以分为六个环节：LLM（大语言模型）→推理→工具调用→规划→行动→反馈。这条链路与AI-enabled BPM阶段的最大区别在于，它是一个闭环。

LLM不只是生成一段文本或者给出一个分类结果，它能够基于当前目标进行多步推理，判断需要使用什么工具（调用API、查询数据库、发送邮件等），规划出一套行动方案，执行这套方案，观察执行结果，再根据结果调整下一步计划。这个循环可以持续运转，直到目标达成或者遇到必须交由人类判断的边界。

这就是从“AI帮助人类完成任务”，走向“Agent能够代表人类完成任务”的核心转变。我们可以用开头的发票案例来具体说明这种转变的分量：如果将这张发票放入具备Agent能力的系统中，系统发现缺少PO编号后，不会直接将其扔进人工队列，而是会主动搜索关联邮件，尝试从历史记录中匹配出可能的采购单信息。如果匹配成功，就自动补全信息并继续流转；如果无法确定，再带着已经收集好的证据升级给人工处理。此时人类审批员拿到的不再是一张“缺信息的发票”，而是一份“已经完成大部分调查工作的待确认事项”。

IBM在描述其内部实践时这样总结：自动化曾经意味着替换一个手动步骤，而Agentic AI替换的是整个工作流，并且能够安全地做到这一点。BCG观察到的早期数据也印证了这种质变并非营销话术：早期仅停留在“自动化层”（如Copilot、机器人助手）的企业，平均只能实现10%到20%的生产率改进；而首批真正实现Agentic流程改造的客户，生产率提升了3倍，周期时间缩短了80%，长期成本降低了60%以上。这中间的差距，并非渐进式的效率提升所能解释，它更像是两种不同范式之间的鸿沟。

BCG的分析师在报告中写道：“当执行变得近乎即时，容量不再是约束时，设计问题就从‘我们如何优化流程’转变为‘我们如何治理结果’。”这也为后续的核心议题埋下了伏笔：当流程的执行主体从“人+规则”转变为“人+Agent”，企业管理者真正需要操心的事情，正在从“每一步该怎么走”切换到“如何确保结果不跑偏、过程可解释、责任可追溯”。

这股热潮也并非没有冷水。研究统计显示，目前真正将Agentic系统规模化部署到生产环境的企业占比仅为23%，而Gartner预测，超过40%的Agentic项目会在2027年之前被取消，原因集中在成本超支、业务价值不清晰、风险控制不足等方面。这些失败原因与传统BPM项目曾经踩过的坑高度相似，这说明如果没有一套新的治理框架去匹配这种新的自主能力，企业很可能会用新技术重复旧的失败模式。“Agentic BPM”这个概念，正是为了回答这个全新的问题：当流程的参与者具备了自主判断和行动的能力，企业该用什么框架去管理这种自主性？

写在最后

回到文章开头那张躺了三天的发票。它被卡住的原因，并非流程设计得不够细致，而是整个BPM范式从一开始就假设，流程路径可以被提前穷尽。三十年来，无论是Workflow Automation、RPA，还是Process Mining和AI-enabled BPM，所有的进步都只是在“让已设计好的流程跑得更快、更准、看得更清楚”，从未真正触及这个底层假设本身。

AI Agent的出现，第一次让打破这个假设成为了可能。如果说传统BPM解决的是“如何让企业按照设计好的流程工作”，那么Agentic BPM开始尝试解决的，是“如何让企业的流程理解目标，并在变化的环境中找到完成目标的方法”。

但这还只是问题的开始。Agentic BPM究竟与传统BPM有什么本质区别？它为什么叫“Agentic”？它是否只是“BPM+Agent”这么简单的叠加？下一篇将继续深入拆解这些问题。