为什么你的 Agent 演示很惊艳，上线两周就没人用了

过去一年我们复盘了十几个 Agent 落地项目——包括我们自己交付的，也包括客户找我们 来接手的烂尾项目。有一个规律非常一致：失败的原因几乎从来不是模型能力不够。

演示阶段效果惊艳、上线两周后使用量归零，这个曲线我们见过太多次了。 下面是四个真实的杀手，按出现频率排序。

一、没有人定义过「什么算对」

这是最常见、也最致命的。项目启动会上大家都很兴奋，讨论的是「用什么模型」 「要不要做知识图谱」，没有人问一句：系统给出什么样的回答，我们认为是对的？

结果是上线之后没有人能判断系统好不好。业务部门说「不太准」， 技术团队问「哪里不准」，业务部门举了两个例子，技术团队改了提示词， 下周业务部门又举出两个新例子。这个循环会持续到所有人放弃。

如果你不能用数字回答「现在的准确率是多少」， 那你其实不知道系统在变好还是变坏。

解决办法不复杂但很枯燥：在写第一行代码之前，和业务专家一起标注 100–300 条 测试样本，明确每一条的期望输出。这件事通常需要两三次半天的会议， 过程中会暴露出大量业务部门内部本来就没有共识的问题—— 这恰恰是最有价值的部分。

二、权限没做对，所以不敢真正开放

第二个常见死法：系统做完了，但只敢开放给一个小范围试点， 因为没人能保证 A 部门的人搜不到 B 部门的敏感文档。

试点范围小 → 反馈样本少 → 优化没方向 → 效果不达预期 → 更不敢扩大范围。这是一个自我强化的死亡螺旋。

技术上这不难：检索层按调用者身份做过滤，向量库的每条记录带上权限标签， 查询时先过滤再召回。难的是组织上要先把「谁能看什么」梳理清楚， 而这件事在很多企业里本来就是一笔糊涂账。我们的建议是把它当成项目的前置条件， 而不是上线前才发现的障碍。

三、答案没有出处，所以没人敢用

在专业场景里，一个没有出处的答案价值接近于零。值班工程师不会因为 系统说「应该更换密封圈」就去更换密封圈——他需要知道这句话出自哪份规程的哪一条， 因为出了事故是他签字负责。

这一点在演示时体现不出来（演示的时候大家看的是回答流畅不流畅）， 但决定了上线后有没有人真的敢依赖它。做法很直接：强制引用、可点击跳转原文、 并且允许系统说「不知道」。

# 反例：把检索结果直接塞进 prompt，不做任何约束
prompt = f"根据以下资料回答问题：\n{chunks}\n\n问题：{q}"

# 改成：明确要求引用、允许拒答、限定范围
prompt = f'''你是设备缺陷处置助手。只依据【资料】回答。

规则：
1. 每个结论后用 [n] 标注来源编号，n 对应资料序号。
2. 【资料】中找不到依据时，直接回答"资料中未涵盖，建议联系专业工程师"。
3. 不要推测、不要合并不同型号的处置方案。

【资料】
{numbered_chunks}

【问题】{q}'''

第 2 条规则尤其重要。绝大多数团队的提示词里没有明确的拒答许可， 模型就会倾向于编一个看起来合理的答案——这在专业场景里比不回答危险得多。

四、上线之后没有人负责

项目验收、乙方撤场、皆大欢喜。然后：

• 规程更新了，但没有人把新文档同步进知识库
• 用户遇到答错的情况，不知道该找谁反馈
• 模型供应商发布了新版本，没有人评估该不该升级
• token 费用月月上涨，没有人看得懂账单构成

三个月后，系统还在跑，但没人相信它了。这不是技术问题， 是交付方式的问题——把 AI 系统当成一次性工程项目来交付， 本身就是错的。它更接近于一个需要持续运营的产品。

我们现在的做法是把运维责任在合同里写清楚：谁负责文档同步、 badcase 走什么流程、多久做一次效果复盘、模型升级谁来评估。 不一定要我们做，但必须有人做，而且要在验收之前就定下来。

一个可以直接用的自查清单

如果你手上正有一个 Agent 项目，可以用这五个问题快速体检：

1. 现在的准确率是多少？能说出一个数字吗？
2. 这个数字是用多少条评测样本算出来的？样本是谁标的？
3. 系统能不能说「我不知道」？上个月说了多少次？
4. 用户发现答错了，反馈路径是什么？上个月收到几条？
5. 下个月的 token 费用预计多少？涨了还是跌了，为什么？

五个问题都能答上来的项目，通常活得不错。答不上来三个以上的， 建议先停下来补这些，而不是继续调提示词。