一、Demo很酷，上线很难
你花了两周搭了个AI Agent，Demo演示时老板连连点头。然后呢？然后就没有然后了。
这不是段子，是真实发生在银行、医疗、企业服务领域的普遍现象。AI Agent最大的坑，不是做不出来，而是上不了线。
原因很简单：Demo只回答"能不能做"，上线要回答"能不能信"。依据从哪来？权限合不合规？出了错谁负责？模型换了结果会不会变？——这些问题一出来，项目性质就变了。
二、三个包：场景包、知识包、评测包
我见过不少AI Agent项目从Demo走到生产，总结下来，真正能沉淀下来的交付物就三个包：
- 场景包——解决边界问题：AI服务谁、嵌入哪个流程、输出什么、哪些自动做、哪些必须人工确认
- 知识包——解决依据问题：AI引用什么材料、材料是否有效、口径是否一致、原文和解释怎么区分
- 评测包——解决信任问题：AI做得对不对、错在哪、能不能复查、换模型后是否稳定
只有场景包没有知识包，AI知道自己要做什么，但回答缺少可靠依据。只有知识包没有场景包，AI能查很多材料，却不知道该服务哪个流程。三个包合在一起，AI才有机会从"看起来有用"走向"真的敢用"。
三、场景包：别让AI停留在聊天窗口
很多项目启动时，习惯用"助手"来概括需求：知识助手、分析助手、报告助手……这个说法方便沟通，但也容易把注意力带到问答效果上——能不能问、能不能答、回答通不通顺。
但真正要上线的AI，不能长期停留在聊天窗口里。它要嵌入岗位、流程、系统和权限。
场景包要回答的具体问题：
- 用户在什么环节打开AI？读取哪些系统数据？
- 输出内容流向哪里？哪些动作可以自动完成？
- 哪些节点必须人工确认？人工修改是否留痕？
举个例子：客户风险摘要助手，表面上是输入客户名、AI生成摘要。但真到现场，你要追问——授信数据取哪个系统？预警信号是否已解除？AI建议能不能触发任务？生成结果能不能回写系统？
没有这些定义，AI输出越顺滑，业务人员反而越不踏实。
四、知识包：知识库≠依据体系
一说知识包，很多人马上想到：上传文档、切分段落、做向量化、接RAG。这些都有必要，但只是起点。
真正的问题在于：文档能召回，不等于引用是准确的；模型能带出处，不等于出处是当前有效的。
更危险的情况是——以前模型凭空编，现在模型带着一个看起来很正式的引用，给出一个过期或不适用的回答。用户看到"引用来源"后更容易相信它，这类错误反而更难发现。
所以知识包不能只停留在"把资料放进去"，还需要：
- 版本管理：制度有新旧版本，废止的文件还在库里
- 权限控制：某些材料只有特定岗位能看
- 口径统一：不同部门对同一指标可能有不同定义
- 区分原文和解释：哪些是制度原文，哪些只是模型整理后的表达
五、评测包：最被低估，最决定项目走向
三个包里，评测包最容易被忽视，但也最关键。
很多项目的"测试"就是项目组内部试几个问题，看看回答通不通、页面能不能跑。这些有用，但撑不住上线。
评测包要做的，是把"AI效果好不好"拆成一条条可检查的问题：
- 这条结论有没有数据依据？依据是不是权威来源？
- 引用版本是不是最新？用户有没有权限访问？
- 是否存在编造字段？是否遗漏关键信息？
- 换模型后结果是否稳定？上线后怎么持续监控？
这套标准一旦建立，会倒逼项目组提前定义：什么叫正确、什么叫不可上线、哪些问题AI不能答、哪些结论必须人工确认。
没有评测包，项目组很容易凭感觉推进——"效果还可以""摘要基本能用""Demo领导看了应该满意"。这些说法在早期有用，但很难支撑验收。
六、这件事对做AI Agent的人意味着什么
我觉得这个"三包"思路不只适用于银行，对所有想从Demo走向生产的AI Agent项目都适用。
AI项目最容易让人兴奋的是生成，最容易让人卡住的是交付。模型能生成但结果不可复核，RAG能引用但依据不可治理，Agent能执行但边界不可控——这就是从Demo到上线最常见的断点。
如果你正在做AI Agent项目，我的建议是：别急着优化生成效果，先把场景边界、知识依据和评测标准想清楚。这三个东西做扎实了，上线是水到渠成的事；做不扎实，Demo再漂亮也只能是Demo。
评论区