获课：xingkeit.top/18067/

完结｜AI Agent 落地踩坑，从 0 到 1 定制开发企业实战经验

三个多月前，我们启动了一个面向内部客服场景的AI Agent项目。从最初拿着大模型API兴奋地跑demo，到后来被各种工程化问题折磨得怀疑人生，再到上周终于完成灰度上线。这趟从0到1的旅程，踩过的坑比我过去一年的开发经历加起来都多。这里把我认为最值得分享的教训整理出来，给正在或准备落地AI Agent的同行一些参考。

坑一：把大模型当“万能大脑”，业务边界没想清楚

项目刚开始时，团队士气高涨，觉得有了大模型加持，Agent什么都能干。产品需求文档上列了十几个能力：回答咨询、查订单、退换货、投诉处理、情感安抚、主动营销……仿佛一个Agent就能取代半个客服团队。

第一个月就撞了南墙。 模型在开放域对话中表现尚可，但只要涉及具体业务操作，比如查询某个订单的物流状态，它就开始了“幻觉式回答”——编造单号、编造时间，看起来煞有其事，实际上全是错的。

教训很直接：Agent不是万能大脑，而是需要明确边界和工具支撑的执行体。 我们后来把Agent的能力收敛到三个核心场景：知识库问答、订单状态查询、退换货流程引导。每个场景背后都对接了真实的业务API和知识库，模型只负责理解意图和调用工具，不再依赖它“记住”任何业务数据。边界清晰之后，准确率从最初的60%出头提升到了90%以上。

坑二：RAG 做成了“高级搜索引擎”，知识检索全是噪声

知识库是客服Agent的命脉。我们早期把几百份产品文档、FAQ、工单记录一股脑塞进向量数据库，觉得RAG（检索增强生成）会自动搞定一切。结果用户的简单问题，Agent经常从完全不相关的文档里摘一段话拼凑答案，牛头不对马嘴。

问题出在知识没有分层，检索没有策略。 同样的用户问“怎么退货”，有的是针对7天无理由，有的是针对质量问题，有的是针对已过保产品。但我们的检索系统只做语义相似度匹配，无法区分场景，召回的片段混乱不堪。

后来我们做了三件事： 一是知识库按业务场景切分，不同场景建立独立的索引；二是在检索前加了一层意图分类器，先判断用户问题属于哪个场景，再去对应的知识库里检索；三是在检索结果上做了重排序，把置信度最高的片段排在前面。这三步做完，答案的准确性和相关性明显改善。

坑三：对话状态管理一片混乱，用户说第二句模型就忘了第一句

早期的Agent是“无状态”的——每轮对话独立处理，模型既不记得用户刚才说了什么，也不知道上下文里提到了什么信息。用户说“我要查订单”，模型问“订单号是多少”，用户说完订单号，下一轮模型又问“您要查什么”。

我们低估了多轮对话的状态管理复杂度。 后来引入了会话记忆机制，把用户的历史消息、已收集的槽位信息、当前会话阶段都在服务端维护起来。每次调用模型时，把压缩后的对话摘要和当前需要完成的任务一并传给模型。这里有个经验：对话上下文不是越长越好，超过一定轮次的历史信息反而会干扰模型判断，适度摘要比全量记忆更有效。

坑四：幻觉问题防不住，用户信任被一次次消耗

AI Agent最致命的问题是“一本正经地胡说八道”。有一回用户问“你们公司北京有几个售后网点”，Agent回答“海淀区有3个”，实际上只有2个。用户按着错误信息跑了一趟，回来就投诉了。

解决幻觉没有银弹，我们用的是组合策略。 首先在系统指令里明确要求：不确定的信息必须说“我不确定”或“建议您以官网为准”，严禁编造具体数字和时间。其次，所有对外输出的答案，关键事实都要走一遍知识库的引用校验——如果生成的内容在知识库里找不到依据，直接拦截，不输出。最后，上线初期设置了人工兜底，高风险场景（涉及金额、地址、时间）的回复要先经人工审核再发出。

坑五：效果评估全靠人工，迭代速度慢到崩溃

项目最痛苦的阶段是测试期。每次改完prompt或调整检索策略，团队三个人轮番上阵，手动构造几十个测试用例，一个一个看回复质量。一轮测试下来半天就没了，一天最多迭代两版。

后来建立了自动评估体系： 构建了包含数百条典型问题的测试集，每条标注了预期答案和关键信息点。每次变更后自动跑一遍，用模型对答案质量打分，同时人工抽检。有了这套机制，迭代速度从每天两版提升到了每小时都能跑一轮，效率提升显著。

写在最后

AI Agent的落地，本质上是一个工程问题大于算法问题的项目。模型能力固然重要，但真正决定上线效果的，是知识库质量、工具链稳定性、状态管理设计、幻觉防控机制和评估体系的完善程度。

三个月的实战给我最大的体会是：先让Agent做一件小事做到95分，再考虑让它做十件事。 范围扩张的速度一定要慢于能力沉淀的速度。稳扎稳打，比追求大而全重要得多。

希望这篇踩坑记录能帮到你。Agent这条路还在继续，欢迎交流。