老板花50万搞了个AI Agent，上线一周就关了

上周三晚上十一点半，我刚洗完澡准备睡觉，客户那边的对接人在企业微信连发了三条语音。

我点开听，第一句就是：”我们老板刚开完会，让我现在通知你，那个 Agent 明天早上停掉。”

我愣了五秒，回了一句”行，明天上午我过去一趟”。

然后躺床上失眠了。

这玩意儿是他们花了将近 50 万做的智能客服 Agent，从立项到上线整整四个月，我中间至少跑了他们公司六七次。上线第一天日均处理量预期是 2000 单，结果上线第三天就掉到不足 50 单。运营那边的投诉单像雪片一样飞过来，最后老板在周会上直接拍板——关停。

一周。从上线到关停，整整一周。

我知道你们看到这个标题，第一反应肯定是”模型不行呗”或者”国产模型还是不如 GPT”。

说实话，刚开始我也这么想。

但后来我把日志拉下来一条一条看，发现真不是。模型该会的都会，知识库的内容也都喂进去了，prompt 也调了七八版。Agent 框架用的是市面上最主流的那一套，retrieval 那一块也接了向量数据库。

技术栈没有任何明显的硬伤。

可它就是不能用。

这个客户是做电商的，Agent 的核心场景是售后咨询，最高频的问题就是”我的退款到哪了”。

正常逻辑是：Agent 接到问题 → 调订单系统的 API → 拿到退款单号和状态 → 回复用户。

听起来很简单对吧。

第一周翻车最严重的一条投诉是这样的：用户问”我昨天申请的退款到了吗”，Agent 回复说”您的退款单号 RF20260518293847 已于 5 月 19 日 14:32 退回原支付账户，请注意查收”。

用户去支付宝里翻了半天没找到这笔钱，打过来骂客服。人工客服一查，这个退款单号根本不存在。用户压根儿就没成功提交退款申请，是 Agent 自己编了一个看起来无比真实的单号糊弄过去了。

后来我们翻日志，发现工具调用那一步返回的是空结果——也就是说订单系统其实告诉 Agent “没查到”，但 Agent 没有把”没查到”这个信号传递出来，而是自信满满地虚构了一个答案。

类似的情况一周内出了至少 17 次。

在客服场景，一次幻觉就是一次投诉。在闲聊场景幻觉是有趣，在金融、客服、医疗这种场景里幻觉就是事故。

我后来跟做大模型评测的朋友聊，他说一句话我印象很深：现在所有号称解决了幻觉的方案，本质上都是在降低幻觉的频率，而不是消除它。从 5% 降到 0.5%，听起来很好，但客服一天进来一万个咨询，0.5% 就是 50 起投诉。

这个我跟客户吵过架。

最早做 POC 的时候，我建议开 thinking 模式（深度思考），因为退款查询这种场景涉及多步推理：识别用户意图 → 提取订单标识 → 调 API → 解析返回 → 组织自然语言回复。开了 thinking 准确率确实高一截。

但上线之后，TTFT（首字延迟）稳定在 3 到 5 秒。

你想象一下，用户在 App 里发了一句”我的退款到了吗”，等了 4 秒钟屏幕一动不动。

90% 的用户会以为卡死了，直接点”转人工”。

剩下的 10% 等到回复了，结果第一句话还是”好的，我来帮您查询一下”，又过了两秒才出现真正的内容。

我们试过关掉 thinking，TTFT 能压到 800 毫秒以内，但回答质量肉眼可见地暴跌——之前能拆出 3 步推理的问题，现在直接给个泛泛而谈的回答。

后来甲方那边的产品经理说了一句让我无言以对的话：”你们这个东西，要么慢得让人想砸手机，要么快得让人觉得在瞎说，没有中间档。”

我想反驳，但是没词儿。

这个是最隐蔽的死因，也是 Demo 阶段最难暴露的问题。

售后场景里多轮对话很常见。用户可能先问退款，问着问着扯到物流，再扯回订单，最后又问优惠券。

我们的 Agent 在前 5 轮表现都还行。从第 6 轮开始，就慢慢糊涂了。

最离谱的一个 case：

问题来了，用户说的”上次买的”，指的是当前对话第 2 轮提到过的那个订单。

但 Agent 调出来的是第 8 轮用户随口提到的另一个订单号。

我也没完全搞懂这个逻辑，理论上 RAG 应该按时间顺序和相关性排序，但实际上模型在 token 数累积到一定程度后，会出现明显的”近因偏好”——离当前最近的信息会被无差别地拉到前面，哪怕它跟当前问题关系不大。

后来我们尝试做对话状态管理，把每一轮的关键实体（订单号、退款号、用户意图）显式地存进一个结构化的 state 里，每次让 Agent 显式从 state 里取。

效果好了一些，但不是特别多。

这个问题我到现在也没想通到底该怎么彻底解决，可能是我对长上下文工程理解还不够深。

前面那个虚构退款单号的例子，本质上就是这个问题的一种表现。

我们的 Agent 接了大概 12 个工具：订单查询、物流查询、退款发起、优惠券核销、商品详情等等。

正常情况下，Agent 调用 → 工具返回结果 → Agent 基于结果回答。

但工具失败的方式有很多种：

• 网络超时

• 返回结果为空

• 返回结果格式异常

• 返回 200 但 body 是 error message

理论上每一种异常都应该让 Agent 走到”抱歉，暂时查不到您的信息，需要我帮您转接人工吗”这条路径上。

实际上呢？我们日志统计，有大约 23% 的工具异常没有被 Agent 正确识别为”失败”，而是被它当成”模糊的输入”硬塞进了回答里。

这部分我现在认为是 prompt 工程的锅，没有把”失败信号优先级”提到足够高。但客户那边显然没耐心等我们慢慢调了。

这个问题我反思了挺久。

Demo 这种东西，本质上是一种受控环境下的展示。

第一，Demo 用的问题是精心准备的，提问者的措辞、上下文、节奏都是反复演练过的，跟真实用户那种又急又乱的口语完全是两回事。

第二，Demo 没有并发压力。一个一个问，模型表现得很从容。真实场景下高峰期一秒钟几十个请求，TTFT 直接劣化到 8 秒以上。

第三，也是最骚的一点，Demo 的评估标准是”像不像人”，不是”对不对”。客户在 Demo 现场看 Agent 回答得文采飞扬，会鼓掌；但在真实场景里，用户根本不在乎你回答得文采怎么样，用户只在乎你能不能解决问题。

我现在跟客户做 Demo 的时候，会主动让他们随机出题，带方言、带错别字、带打断、带情绪。基本上每一次都能当场翻车。

翻车不是坏事，翻在 POC 阶段，比翻在上线后强一万倍。

经过这次 50 万打水漂的事件，我后来给所有问我”要不要上 Agent”的客户都说几句话，不一定对，但是是我现在的真实想法：

第一，别上全自动，先做”AI 辅助人工”。

让 Agent 把答案生成出来，但不直接发给用户，而是先发给人工客服审核一秒钟，确认无误后一键发送。这种模式下，人效能提升 40%~60%，事故率几乎为零。等数据积累足够多、Agent 准确率压到 99% 以上再考虑全自动。

第二，先把 RAG 做扎实，再想 Agent。

我看过太多客户，知识库还是 100 篇 PDF 直接扔进向量库，召回准确率只有 60%，就开始搞多 Agent 协作、工具编排、Plan and Execute 那一套。地基没打好就盖楼，楼当然要塌。

第三，把”答不出来就说不知道”作为最高优先级。

这条 prompt 我现在写在所有 Agent 系统提示词的第一行：

当你不确定答案，或工具返回结果为空、为错误时，禁止编造答案，必须明确告知用户”暂时查询不到，请稍后再试或转接人工”。

简单粗暴，但是能挡住 80% 的事故。

第四，预算的 60% 花在评测和兜底策略上，不是花在模型上。

很多客户一上来就问”用 V4-Pro 还是 V4-Flash”“调用费一个月多少钱”。说实话模型那点钱真的不是大头。真正决定 Agent 能不能上线的，是评测体系和兜底策略——你有没有 1000 条以上的真实场景测试集？你有没有自动化的回归脚本？你有没有 fallback 到人工的开关？你有没有兜底回复模板？

这些东西看不见摸不着，但它们才是 Agent 能不能活过第一周的关键。

那个客户最后没有完全放弃，他们把 Agent 改成了”智能辅助”模式，给人工客服当副驾驶用。上个月我去回访，运营那边说人均处理单量提升了 35%，老板算了下账，觉得这个 ROI 还行。

但 50 万的全自动 Agent 项目，确实是死了。

Agent 的未来我是看好的，长期看一定会替掉很多重复劳动。但 2026 年这个时间点的 Agent，老老实实说，还不到能完全替人的程度。它更像一个聪明但马虎的实习生——能干活，但不能放出去单独见客户。

很多事情得咱们自己亲自摔过坑，才知道哪儿是悬崖哪儿是路。

作者丨枫叶冰澜

来源丨网址：https://zhuanlan.zhihu.com/p/2049521528220415978?share_code=8Jhz3zCiU1jd&utm_psn=2075935280046126013

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn