为什么国内企业的 AI Agent demo 跑得好但上线失败

「我们的 agent demo 跑一万次都精准，怎么上线第三天就开始崩？」——这个问题涌意在客户对接中听过太多次。Demo 跑得好和能上线是两件事，技术债务被 demo 阶段的「漂亮数据集」掩盖，真实生产数据会把所有漏洞翻出来。

总结下三个最常见根因。

根因一：数据完整性陷阱

Demo 用整齐的脱敏数据集——所有字段都全、时间戳连续、没有租户混淆。生产数据有时间延迟、有缺失字段、有跨租户数据隔离要求。

一个实际场景：某制造业客户的 IoT Agent 在 demo 时 100% 传感器在线。生产环境上线后，5% 的传感器在凌晨周期性掉线（运维事先没说，因为他们以为「不重要」）。Agent 在数据缺失时直接读到默认值 0，把它当成「传感器读数为 0」上报到下游决策——告警系统因此漏掉了一次真实的低压报警。

修复成本：重写数据接地层 + 加缺失值显式标识。两周工程量。如果上线前做就是一天的事。

根因二：审计不可追溯

Demo 时大家盯着 agent 给出最终答案。上线后某天回复出了事故，复盘第一个问题是：「那条回复用的什么 prompt？调了什么工具？哪个模型版本？返回数据是多少？」如果没有按步骤记下 prompt + tool args + model version，根因永远找不到。

某金融客户出过这事——客服 agent 给客户回了一个错误利率，要补救要解释。但日志只有最终回复，没有中间过程。事故定责拖了两周，最后只能默认认错赔偿。

修复成本：补一套带 run ID 的全链路日志层，包含 prompt、tool args、model version、返回 data。如果上线前做就是初始架构的一部分。

根因三：成本失控

没有模型路由、没有 token 预算、没有失败重试上限。Demo 时一次会话花不了多少；上线后总会有用户卡在死循环。

某客服 Agent 上线第二天，一位用户问了一个 agent 答不出来的问题，agent 反复调相同的 tool 想找答案，调了 47 次后会话被 timeout 砍掉——单次会话烧掉 ¥300。月底账单出来，CTO 在群里 @ 了全员。

修复成本：加 token 预算和 tool 调用上限，加 fallback 模型路由。也是初始架构问题。

不是不能上线，是缺一个清单

这三个根因都不是技术上不能解决的问题——都有标准做法。问题在于：demo 阶段没人逼你做这些，上线时没有清单告诉你哪些必须做完。涌意把这个清单产品化了。

想知道您的 agent 卡在哪一关？→ 10 题自检