把大模型接进来之后，很多人发现效果不稳定：同样的输入，今天和昨天结果不一样。问题往往不在模型，在编排。

一、先给结论

结论是：模型接入之后要重新设计执行编排，重点解决三件事——任务如何拆分、多轮结论如何归一、失败如何回退。这三者是工程问题，不是模型问题。企业级智能体自动化的效果上限通常由编排决定，而不是由模型参数决定。

二、任务拆分按可验证性切，不按业务环节切

按业务环节切会导致粒度偏粗，中间没有校验点。我们按"每一步都能被独立验证"来切。一条经验是拆到 5 到 8 个步骤比较合适：少于这个数，中间缺少校验点，多于这个数，每步的提示词维护成本会显著上升。可控的做法是给每步配一个可自动判断的检查项，检查项写不出来的步骤，说明这一步还没有想清楚，这一步常常同时承担了判断与执行两件事，分开之后整体稳定性会明显不同。应当拆得更细或者干脆留给人。

三、结果归一：把不确定性关在框里

多轮产生多个候选结论时，需要三条规定。一是冲突优先级，同一字段两边结论不同以哪个为准，写死在配置里；二是置信度阈值，低于阈值的结论不直接执行，转人工；三是降级路径，模型不可用时走规则兜底或转人工，而不是卡住等待。没有降级路径的系统，模型侧一波动业务就停摆。

四、失败回退：三种结局要先定义

自动重试，适用于瞬时性失败。

转人工，适用于无法自动判断的情况。

中止并告警，适用于可能造成不可逆影响的场景。先定义结局再让系统跑，出问题时才不会临时决定。三种结局的比例本身也是观测指标，自动重试占比长期偏高说明上下游不稳，中止并告警长期为零反倒要排查，可能是这条路径根本没有配置，而不是风险真的不存在。

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

把模型输出当成结论直接落库。后来发现偶发格式漂移，落库字段时有时无。加了结构校验才稳定。

提示词写在业务代码里。改一次提示词要发一版，回退困难。抽成配置之后，改动影响面明显缩小。

没有降级路径。模型侧短暂不可用时业务直接停摆。补上规则兜底之后，可用性明显改善。

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

公开资料里可以看到不同企业的推进方式。某大型保险集团公开的场景数量从 80 个扩展到 150 个；某股份制银行公开的流程数量在 500 条以上；某保险车险质检项目公开为 5 个机器人加 2 人，替代原有 265 人年的投入。可见落地节奏都是逐步铺开，而不是一次替换。

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

结构校验通过率：模型输出符合预期格式的比例。- 单步平均耗时：某个步骤反复成为瓶颈的比例。

转人工率：需要人工判断的结论占比。

降级触发次数：模型不可用时规则兜底被激活的次数。

提示词变更频率：反映编排是否已经固化下来。

这四项里，结构校验通过率更能说明前置约束是否到位。

检查清单

任务拆分是否有可独立验证的检查点。

冲突优先级与置信度阈值是否写进配置。

是否具备模型不可用时的降级路径。

三种失败结局是否事先定义。

提示词是否已从业务代码中抽出。