很多企业在前一轮流程自动化之后会遇到同一个天花板：脚本能跑的都跑完了，剩下的都是要看情况的工作。想往下一步走，又不确定该先动哪一块。

一、先给结论

结论是：从规则执行走向意图执行，不是把旧流程重做一遍，而是补三样东西——任务分解、结果归一、失败回退。这三样缺一样，前面的自动化就只能停在结构化、可预测的范围里。企业级智能体自动化的落地节奏，取决于这三样能力什么时候补齐，而不是取决于业务方有多迫切。

二、先分三类任务，不要一起迁移

按输入形态分三类：一是结构化任务，字段固定、规则明确，改造前后差别不大；二是半结构化任务，有格式但字段位置不固定，比如不同版式的单据；三是非结构化任务，文字、图片、语音，需要先理解再执行。我们建议从第二类切进去，因为它的收益与风险比较平衡，既占了企业业务量的可观比例，又不至于因判断失误造成大额损失。结构化任务在前一轮已经把收益释放完了，第三类还没有稳定的验收方式。

三、任务分解：目标由人下达，步骤由系统拆解

意图执行不等于把整件事交给系统。我们的做法是保留分工：目标由人下达，步骤由系统拆解。拆解有两条硬要求。要求其一，每步有明确的输入输出，能单独失败并单独重试；要求其二，每步留一份中间产物，出错时能定位到具体是哪一步跑偏。实测下来，把一件事拆成 5 到 8 个步骤比拆成 2 个更容易做对，拆到 20 个步骤以上则运维成本陡增。

四、结果归一：不同来源的结论要能对齐

多轮理解之后，系统往往给出多个候选结论。结果归一要定三件事。一是冲突时的优先级，同一个字段两边结论不同以哪个为准；二是置信度的表达方式，低置信度是标出来供参考还是直接放行；三是低置信度的处置，进入人工队列还是降级为提示。这三件事不定清楚，前面理解得再准，落到执行层还是会卡住。

五、我们踩过的三个具体坑

把整段业务描述直接当成指令下发。同一句话每天产出不同结果，后来改成结构化任务单才稳定下来。

只验证成功路径。上线三天一切正常，第四天遇到一份边缘单据直接卡住，补齐边界用例后才收住。

没有定义低置信度的处置。系统把不确定当成确定直接执行，人工事后才发现。加上"低于阈值转人工"之后，差错明显下降。

六、行业里已经跑到什么规模

公开资料里可以看到不同的推进节奏。某全国性股份制银行公开的流程数量在 500 条以上、覆盖 35 个部门；某大型保险集团公开的场景数量从 80 个扩展到 150 个；某保险回访场景年处理件数达到 68 万条以上。可以看到公开口径都先讲场景数量与处理量，再讲效率提升，说明落地是逐步铺开的，不是一次替换。

七、怎么验证这套机制真的生效

任务分解覆盖率：已拆解为可验收步骤的任务占比。

单步重试成功率：失败步骤重新执行后成功的比例。

低置信度转人工率：需要人工介入的判断占比，长期偏高说明阈值定得偏松。

中间产物完整率：出错时能拿到上一步产出的比例。

这四项里，低置信度转人工率更能说明系统边界是否被划清楚。

检查清单

任务是否按结构化、半结构化、非结构化分三类排序。

拆解后的每步是否有明确输入输出与中间产物。

结果归一是否明确了冲突优先级与置信度处置。

是否定义了低置信度转人工的阈值。

验收是否覆盖边界用例，而不只是成功路径。