智能体从演示走向生产：三道坎

演示与生产的距离

演示环境里，智能体只需要在几十条路径里选对一条。生产环境里，它面对的是权限体系、脏数据、并发冲突和无法预料的用户输入。技术团队普遍反映，从原型到上线的时间，远大于把原型做出来的时间。

差距主要来自边界。一个会写代码、会调用接口、会操作后台的智能体，本质上获得了一份权限清单。这份清单如果没有收敛，风险就从模型幻觉转移成了真实操作失误。

第一道坎：把权限切细

可行做法是给智能体的每个工具单独授权，并且默认只读。写操作需要显式开通，且限定作用域，例如只允许修改草稿、不允许发布。再把高风险动作放进人工确认环节，让确认成本随着风险等级递增。

另一个细节是幂等。智能体重试很常见，接口如果不幂等，一次超时就会变成两笔订单。工程上通常要求所有写接口携带请求标识，由服务端做去重。

第二道坎：可回滚

生产系统里没有回滚能力的自动化，等于把偶发错误放大成事故。比较稳妥的结构是把智能体的动作记成事件流，每一步都有前置状态与后置状态，回滚时按逆序补偿。

补偿逻辑不可能覆盖全部情况，所以还需要一条兜底路径：当检测到状态不一致时，停止自动流程并转人工。这条路径平时几乎不走，但决定了故障时的损失上限。

第三道坎：能被评估

传统软件的测试用例是确定的，智能体的输出是概率性的。团队需要一批带标注的真实任务作为回归集，每次调整提示词或更换模型都跑一遍，看通过率而不是看几个漂亮样例。

评估指标要贴合业务。客服场景看首次解决率，编码场景看补丁是否通过测试，检索场景看引用是否可追溯。指标选错，优化方向就会跑偏。

把这三道坎跨过去之后，智能体带来的收益才比较稳定：不是替代人，而是把重复判断的成本压下来，让人集中在例外处理上。

组织层面的配套

技术之外，落地智能体还需要流程调整。谁负责审核它的输出，出错时谁承担后果，权限变更由谁批准，这些问题在项目启动前就应有答案。

一些团队设置了「智能体值班」角色，负责监控异常、处理转人工请求，并定期复盘失败案例。这个角色不需要很高级别，但必须熟悉业务流程，否则无法判断哪些动作该放行。