智能体编排：为什么业务自己搭比 IT 代建更可持续

让 IT 部门把业务需求翻译成智能体流程，是常见做法，但往往在几个月后陷入停滞：需求排队、改动缓慢、业务方觉得不好用。原因不在 IT 能力，而在流程知识与变更频率不匹配。把编排权交给业务、把平台能力交给 IT，是更可持续的分工。

流程知识在业务侧，翻译必然有损耗

业务方知道自己每天处理什么单子、哪些情况最常见、哪些需要特别小心。这些知识是长期积累的，很难通过一次需求调研完整传递出去。

翻译的损耗体现在两个环节。一是表达损耗，业务人员描述的是现象与经验，IT 接收后要转成可执行的规则，中间难免简化。二是验证损耗，IT 按理解做出的流程，要等上线后由业务方试用才能发现问题，反馈周期以周计。

结果就是流程能跑但不好用：覆盖了主要路径，忽略了许多实际存在的分支；能处理标准输入，遇到非标准情况就报错。

变更频率决定谁来维护

业务规则的变化频率远高于系统功能。审批额度调整、例外条件增删、对接部门变更，这些在业务看来是日常，在 IT 的排期里则是需求。

如果每次调整都要走需求流程，业务方会逐渐放弃使用，转而回到人工处理。反过来，如果业务方能直接调整流程配置，变化就能即时生效，工具才真正融入日常工作。

让业务侧能维护的前提是平台把复杂度收好。业务人员调整的应该只是流程的分支、字段与阈值，而不是底层逻辑。平台需要提供可视化的编排界面、明确的可配置范围，以及调整后的校验与发布机制。

分工的边界：业务管编排，IT 管能力与安全

放权不等于放手。合理的分工是三层。

业务层负责流程编排：定义有几个步骤、在哪些节点需要判断、字段如何流转、阈值怎么定。这一层的改动可以频繁，且应当能自助完成。

IT 层负责能力供给：提供可复用的组件与工具接口，保证调用的稳定性与性能，管理模型与版本。这一层的改动需要评审，因为它影响所有流程。

安全与治理层负责边界：谁能改什么、改动是否要审批、上线是否要灰度、运行数据如何留痕。这一层不参与具体业务，但决定整体可控性。

三层之间通过发布机制衔接。业务侧的调整先自我验证，再按规则走审批与灰度，既保证了效率，也保留了必要的约束。