AI Agent项目纷纷烂尾？从Demo到生产的五个致命问题与实战解法

这两年我亲眼见证了一个颇有戏剧性的规律：越是Demo做得漂亮的AI Agent项目，越容易烂尾。会议室大屏上，Agent一键完成多系统联动操作，全场鼓掌；三个月后再去问，项目已经在角落吃灰，当初拍胸脯验收的负责人要么调了岗，要么假装这事没发生过。

这不是个别现象。我陆续接触过几十个企业Agent项目，真正能稳定运行超过半年的，一只手数得过来。剩下的，多数死在“Demo做完了，然后呢”这一步。

这篇内容不打算讲概念，也不吹Agent多神。我想把企业级Agent落地从“演示”到“生产”这段路上那些真实的坑、隐蔽的雷、还有我实测有效的打法一次说清楚。适合正在规划企业级Agent、或者手头项目已经陷入泥潭的负责人和技术同学。不管你是刚立项、在做PoC，还是已经上线但天天被业务吐槽，这篇文章多少都能让你对号入座。

1. 为什么Demo惊艳全场，生产环境却一地鸡毛

先讲个我常用来和客户解释差距的类比：Demo像演员在摄影棚里拍戏，导演喊卡就重来，一条不行拍十条，随时有提词器、有NG机会。生产环境是直播，没有提词器，脚本经常临时改，而且观众（用户）不但能实时看到你的失误，还会截图发到全员群。

1.1 Demo是“提词器效应”，生产是“裸考”

绝大多数Demo翻车，不是技术不行，而是Demo根本不具备“可复现性”。做演示的时候，输入是精心挑选的，问题是预调过的，知识库是手工整理过的，甚至模型输出温度调低到接近“标准答案”。一切都服务于“让演示成功”这个目标。

但生产环境根本不是这样。用户输入天然带着口语、错别字、简称、双关、甚至是故意让系统难堪的对抗性输入。知识库里堆的是几十个部门传来的、格式混乱的、Excel和PDF混杂的历史文件。权限体系是十多年前搭的，接口响应不稳定，数据库里一个字段名能有三套叫法。

我见过最典型的一个案例：某公司Demo阶段，Agent回答客服问题几乎零失误，业务方看完当场拍板要全面推广。结果上线第一周，Agent把一个“已停产但在库文档里仍标着在售”的产品推荐给了客户，还一本正经地给出了优惠方案。原因很简单，知识库里的旧文档没清理，模型忠实“背诵”了过期信息。这个锅算模型的吗？算Agent的吗？都不算。算Demo阶段的——因为Demo用的是人工挑过的新文档，根本没触发过这个场景。

这就是“提词器效应”：Demo给了你一个虚假的置信度，让你误以为系统已经成熟。实际上生产环境的每一条输入都在“裸考”，一次答错，用户不会给第二次机会。

1.2 三种典型的“烂尾死法”

复盘那些烂尾项目，死法其实高度集中，逃不出下面三类：

第一种，死在数据上。项目启动时，各方承诺“数据随时能用”，开挖之后发现：系统权限没申请下来、接口文档是五年前的、核心业务数据散落在ERP和一堆Excel里，连版本都对不上。Agent真正变成“没有数据的将军”，空有调度能力，却无内容可用。这类项目通常耗时最久，也最消磨士气。

第二种，死在评估上。没有制定“什么算答得好”的明确标准，上线后好坏全凭感觉。业务方觉得“偶尔答错可以接受”，技术方觉得“模型本来就该有幻觉”，双方对“可用”的定义完全不一致。争论着争论着，项目就没了推动力。这个问题我在后面第2章会细讲，它远比技术难，因为本质是管理者根本没有给Agent定义KPI。

第三种，死在权限和组织上。Agent需要调用的系统接口涉及跨部门数据权限，安全部门不放行，业务部门不想给，IT部门嫌麻烦。最后Agent只能在一个沙子堆成的“测试沙盒”里跑，跑得再好也落不了地。最讽刺的是，很多项目不是在技术上失败的，是在“批文”上失败的。

这三种死法各有各的解法，但有一个共同前提：你得先把Demo和生产的差距拉出来，让所有利益相关方承认“能演”不等于“能打”。

2. 企业级Agent落地的五个隐形杀手

很多时候项目没有烂在明面上，而是糊里糊涂“被拖死”的。下面这五个问题，我几乎在每个项目里都见过，而且常常同时出现。

2.1 数据基础虚胖：RAG不是把文档丢进去就行

RAG（检索增强生成）是目前企业Agent最常见的知识底座。但太多团队把它想简单了：文档切一切、向量化、扔进向量库，完事。等上线就发现，检索出来的东西牛头不对马嘴，或者把毫不相关的段落拼凑在一起，生成一个错误答案。

我从实战里总结，RAG做不好主要有三个原因。

一是数据源本身是脏的。未经清洗就直接切块入库，表格被拦腰切断，编号和正文分离，单位、口径不统一。有一次我在某项目的知识库里搜一个产品型号，检索出五个相关片段，四个说的是旧版，只有一个是当前版本，模型理所当然选了信息量最大的旧版段落。

二是分块策略拍脑袋。有的团队固定512个token切一切就完事，完全不看文档本身的语义结构。合同、说明书、FAQ的合理切法完全不同。同一个知识库里混用多种切法，检索精度直线下降。

三是检索和生成的链路没有校验。RAG不是“检索到就给模型”，你必须对检索结果做相关性过滤、去重、排序，甚至要有“检索不到就不答”的兜底。我们后来规定：如果最高相关度分数低于阈值，Agent必须回答“我无法从现有资料中找到答案”，而不是硬编一个。

注意：RAG的核心不是“做没做”，而是“检索质量有没有量化”。不管用什么向量库，建议每天跑一遍检索准确率抽检样本，否则你根本不知道知识底座什么时候开始悄悄退化。

2.2 没有评估基线，就没有迭代方向

这是所有坑里最隐蔽、也最致命的一个。

一个小团队做Agent，开发周期两周，调优周期可能两个月。为什么？“这个回答感觉不对”“那个结果看着不太行”——全靠感觉调。模型换了、Prompt改了、文档重切了，到底有没有变好？没人说得清。

我见过一个项目，前后迭代了八个版本，每次都是把同样的100个测试问题人工跑一遍，两眼一瞪觉得差不多就发版。直到有同事提出把这100个问题变成自动化回归集，才发现一个版本在上一批问题里表现提升的同时，把另一批旧问题的正确率拉低了12个百分点。这12个百分点的回退，就是因为他们没有回归集，看不见副作用。

企业级Agent必须有“评估基线”这个概念。你不用建一个多么复杂的评测平台，至少要做到三件事：

1. 把核心场景的测试用例沉淀成固定的回归集，至少一两百条，覆盖正常、边界、对抗三类输入；
2. 每个问题定义好参考答案和判定标准（完全正确、部分正确、错误、不可答）；
3. 每次迭代跑一遍回归集，记录准确率变化，低于基线就不准上线。

有了这个机制，你才有资格谈“迭代”。否则就是开车不看仪表盘，全凭脚感。

2.3 工具调用断在“最后一公里”

Agent的核心价值之一就是调用工具、执行动作：查库存、下工单、回邮件、改配置。但工具调用恰恰是生产环境中翻车率最高的环节，而Demo恰恰最喜欢展示这个环节。

问题通常出在三个地方。

第一个，API质量根本达不到Agent所需的稳定度。演示时API是通的，生产时超时、限流、返回格式漂移，全都来了。Agent调一个库存接口，等了三秒没响，自己瞎猜了一个库存数字填进去，然后一本正经告诉你“有货”。这已经不是功能问题，是安全问题了。

第二个，入参校验缺失。Agent把对话里的“王经理”当成客户姓名传给了CRM，创建了一个脏数据。人填表单时尚且容易出错，让Agent去理解意图并填字段，更容易错。你不给工具入口加参数校验和约束提示，就是在放任Agent制造数据垃圾。

第三个，动作不可回滚。Demo里演示的是“Agent自动创建订单”，很酷；生产里一旦误创建，谁负责删除？不少系统根本没有为Agent这种高频调用者准备“反向操作”路径。

我的经验是：Agent调用工具，必须分“建议模式”和“执行模式”。前期一律建议模式，只生成操作建议让人点确认；跑一段时间、积累了足够的调用日志和置信度数据后，再逐步放开低风险动作的自动执行。千万别Demo一结束就全自动。

2.4 权限模型模糊，Agent变成“失控实习生”

这一点和技术关系不大，但坑巨深。

当Agent接入企业系统时，它本质上是多了一个“数字员工”。问题是，这个员工该有多大权限？能看哪些数据？能改哪些记录？——很多项目压根没想过这些问题，直接给Agent开了个“管理员账号”。

后果就是：Agent在检索时无意访问了不该看的部门数据，或者调用工具时顺手改了一条只有主管才有权限改的记录。一旦出了这类问题，安全部门大概率直接叫停整个项目，而且是那种“永久暂停”的力度。

正确的做法是给Agent做最小权限映射：明确它到底需要哪些数据、哪几个接口、什么级别的能力，逐项申请，逐一审批。Agent的每一个动作都应该有操作人溯源——也就是说，用户让Agent做了什么，要有日志能让事后追溯。我们甚至要求过：Agent调工具前必须先经用户确认意图，所有关键动作留痕。这没有让效率低多少，但救过我们很多次。

2.5 Token账单与收益错配的账

很多项目死得悄无声息，是因为没人算总账。

Demo阶段，调用量也就几百次，费不了几个钱；全量上线后，Call量放大到百万级、千万级，Token账单一个月六位数人民币起步。业务部门发现省下的人力成本还没账单高，财务就发难了。Agent项目从“创新亮点”变成了“预算黑洞”，自然被叫停。

这个账其实不能只看表面。Token成本高的原因常常不是用量大，而是方案不合理：没有做路由（简单问题走便宜模型，复杂问题才走强模型）、没有做缓存（相同问题重复计算）、没有精简上下文（每次把几十页文档全塞进Prompt）。这些都是工程上能优化的。

但核心在于，立项时就必须把成本模型写进ROI测算里，而不是把它当“上线后再看的信封”。我见过最夸张的一个项目，预期每月省20个人日的人力，结果Token成本是那些人力折算金额的两倍，还加上了三个月烧掉的调优时间。这笔账从第一天就注定是亏的。

3. 实战秘籍：从“能跑”到“能扛”的落地路径

前面说的都是问题，接下来聊方法。这套路径是我从多个成功、半成功的项目中反复提炼出来的，未必最优，但一定“用得上”。

3.1 需求收敛：先砍掉九成伪需求

企业上Agent，最容易犯的错是“想做一个全能助手”。公文写作要能做，客服要能答，数据分析要能干，最好还能帮你订会议室。需求方提得很开心，技术方接得很痛苦，最后什么都做不成。

我每次接手项目，做的第一件事永远是问三个问题：

1. 这个Agent解决的到底是哪个高频痛点？日均发生多少次？
2. 如果只能解决一个场景，你选哪个？
3. 这个场景的数据、接口、权限，是不是都在我们可控范围内？

多数人回答完这三个问题，需求自动砍掉一半。剩下的一半里，再按“价值高、频率高、数据条件好”三条标准排序，只做前三名，甚至只做第一名。别怕格局小，一个场景跑通、跑稳、跑出真实业务价值，比十个场景瘫在那里强百倍。

我之前帮某制造企业做过一个Agent，全场讨论下来，聚焦点落在了“售后技术答疑”这一个场景上——因为他们的工程师40%的日常时间都在回答重复的售后问题。数据现成（过去五年的售后问答记录），专家愿意配合（他们也想少被重复打扰），价值清晰可见。只做这一个场景，两个月上线，效果立竿见影。这个项目的成功经验后来被复制到了他们其他部门。

3.2 知识库“精装修”：清洗、分块、索引三步走

如果第2.1节说“RAG不是把文档丢进去就行”，那这一节就讲到底怎么“行”。

我现在的标准流程是三步。

第一步，清洗。所有文档过一遍格式解析，把页眉页脚、水印、乱码、扫描件里的OCR错字全部处理掉；统一旧版与新版的标注；实在拿不准的段落直接标记为“待人工审核”，不要入库。这一步最枯燥，但收益最大。我接触过一个案例，单纯清理掉过期文档，就把检索准确率拉高了接近15个百分点。

第二步，分块。不同文档类型用不同策略。合同按条款编号分块，FAQ按“问题-答案”成对分块，操作手册按章节和步骤序列分块。每块之间保持语义自洽，必要时添加标题前缀和元数据标签（如“部门：售后”“版本：2025Q1”），这能显著提升后续检索的匹配质量。

第三步，索引与校验。切完的块做一遍自检：随机抽50条检索query，人工确认top3返回片段是否切题。不切题的，回头调分块参数或清洗规则。这一步要重复两到三轮，直到检索准确率达到你心里那条线（我们内部一般是80%以上才允许往下走）。

做完这三步，RAG才勉强算“能用”。

3.3 搭好评估基线与回归集，先过及格线再谈上线

第2.2节讲了评估的重要性，这里给出具体搭建方法。

第一步，收集真实用户query。从历史工单、客服记录、内部论坛里捞至少300-500条真实问题，人工去重、脱敏、清洗。真实数据比专家编的问题有价值得多，因为里面有真实的脏话、口语和隐含语境。

第二步，定义判分标准。我习惯用四档：完全正确（可以直接回复给用户）、部分正确（有可用信息但有错漏）、错误（核心内容不对）、不可答（资料不足时拒绝回答也算对）。注意，不可答在很多场景里是正确行为，能拦下错误答案本身就是价值。

第三步，固化为回归集。把一两百条代表性的用例固定下来，绑定一个简单的自动化脚本：每次改完Prompt、换完模型、调完RAG，跑一遍脚本，输出准确率报表。准确率高于上一次基线的，才允许进入下一阶段。

第四步，设置上线红线。我自己的经验是：核心场景“完全正确”的比例至少要过60%，且“错误”的比例要控制在一定范围内（比如10%以内），才具备灰度资格。达不到就继续迭代，宁可不发版也不要让业务方用一个不靠谱的东西。

这套体系不用花太多成本，但它是项目所有讨论的“共同语言”。有了基线，业务方和技术方不再凭感觉互相扯皮，而是站在数据面前理性决策。

3.4 灰度发布：小流量、人工兜底、反馈闭环

评估过了红线，也不能直接全量放开。我坚持三步灰度。

第一步，内部小圈子试用。找5-10个对这个场景最熟悉的深度用户，让他们当“第一批小白鼠”。他们既要真的用，又要每天反馈哪里不对。这一个阶段跑两周左右，主要看稳定性和真实调用中的异常。

第二步，定向部门灰度。选一个配合度最高、业务量适中的部门，放开真实流量，但所有Agent输出必须经过一个人工确认环节才能真正生效。这个环节很关键，它既是安全阀，也是数据收集器——人工确认过程中的每一次“修改”，都是对Agent模型的免费微调数据。

第三步，全量上线+持续监控。全量之后不是结束，是开始。每天盯三个核心指标：调用成功率、用户反馈率、人工干预率。任何一项指标异常，立刻回滚到上一个稳定版本。我有一套很朴素的原则：Agent系统版本回滚要像吃饭喝水一样正常，不要有“好不容易上线了不能退”的心理包袱。

4. 常见问题与排查技巧实录

实际操作中遇到的问题五花八门，但高频问题是可以穷举的。下面这个表是我自己长期使用的问题速查清单，分享出来给大家当排查手册用。

4.1 高频问题速查表

这张表解决的是“能感知到”的问题。更多时候问题是悄无声息的——比如某天检索召回质量退化2个百分点。这类问题只能靠每天的自动化巡检发现，所以我说监控和评估体系是项目的生命线，不是“有余力再搭”的周边设施。

4.2 三个让我印象深刻的踩坑现场

说三个我自己踩过的、也是最有代表性的坑。

第一个坑：把“数据都接好”当成“数据能直接用”。某项目，数据团队说“ERP库存接口已经接通”，我们直接开始开发。上线当天发现，接口返回的“可用库存”在业务口径里应该是“可承诺库存”（扣掉了备料占用），而我们直接当成现货库存推给了销售。那个下午，销售拿着错误库存数据跟客户许诺交期，后果可想而知。从那以后，每次接数据源，我们要求业务方出书面口径说明，并且用真实单据对账，绝不做“技术侧单方面理解”。

第二个坑：人工兜底环节设计太弱。灰度期间我们设计了一个“人审工单”环节，本意是让人确认Agent生成的工单内容后再发送。结果上了之后发现，业务人员太忙，手机上一键点通过，根本没人看内容。等于兜底失效，Agent的错误直接被放行到了下游。后来改成“审核后必须手动点发送按钮”，把“默认通过”变成“显式操作”，情况立刻好转。设计兜底机制时，永远要假设执行者是最忙、最累、最不想看细节的状态。

第三个坑：模型一换，原来的Prompts集体失效。有一次为了降成本，按计划切换到一个更便宜的模型，跑回归集之前我们以为“同样的Prompt换个模型最多有些波动”，结果正确率直接从68%掉到44%。那之后我的规则是：任何模型更换，必须走完整回归流程，并预留至少两周的适配缓冲期。模型的差异不是“参数微调”，而是“行为体系重建”，这一点怎么强调都不过分。

5. 组织与流程：比技术更难的隐性成本

技术问题再难，总有个解法。组织问题才是企业级Agent落地的“终极BOSS”。项目死在技术和数据上的最多占一半，剩下的，几乎都死在组织协同和责任分配上。

5.1 责任归属：必须有人为Agent的错误兜底

Agent会犯错，这是所有从业者必须接受的现实。真正的问题不是“如何让Agent不犯错”，而是“Agent犯错之后，谁来负责”。

很多企业在这个问题上是模糊的。业务方说“这是AI做的，我们也没想到”；技术方说“数据是你们给的，错也是你们的错”；安全方说“反正不是我们批准上线的”。责任一模糊，一追责就互相推诿，项目推进自然停摆。

我的建议很直接：在立项之初就明确一个“业务负责人”。这个人必须是真实业务部门里对这个场景最在意的人，他要为Agent的最终业务效果负责，包括指标达标、风险承担、以及持续优化资源的落实。他不是“挂名支持”，而是“项目第一责任人”。技术团队是他的交付伙伴，而不是背锅对象。

我见过最健康的一个项目组配置是：业务方派了一名资深运营做“产品负责人”，技术方配了两名开发加一名算法，每周固定对一次指标。业务负责人对Agent输出的每一次重大错误都有“签字权”——这意味着他要真看数据，真做判断。这种机制下，Agent的质量意识从头到尾都被业务方盯着，技术方反而更好做事。

5.2 从项目制到产品制，Agent是长期运营系统

很多企业把Agent当成一个“项目”，立项、开发、验收、结项，四步走完，大家散伙。但Agent落地之后只是“开始”，它是需要持续运营的系统，要有人看监控、调Prompt、维护知识库、处理用户反馈、做版本迭代。

我常说一句话：Agent不是“盖一栋楼”，而是“养一个孩子”。楼盖完可以交给物业，孩子你得一直养着，而且会持续有变化、有惊喜也有麻烦。

所以组织上要做的转变是：把Agent的运营预算从“一次性项目经费”变成“持续性运营预算”。哪怕只是固定一个半人力负责维护也是好的。很多项目烂尾，不是因为技术不行，而是因为“没人养”了——知识库三个月没更新、模型Prompt半年没动过，系统自然越来越偏离业务现实。

项目制解决“从0到1”，产品制解决“从1到100”。只做前者不做后者，Agent注定是昙花一现的Demo。

最后说几句实在话

做企业级Agent这行，我最大的体会是：技术从来不是最难的那关，最难的是让所有人都对“AI的能力边界”保持诚实。

我见过太多团队，Demo阶段用最光鲜的样本给自己打气，生产阶段又用“模型幻觉”当所有问题的万能挡箭牌。这两种心态同样危险。Agent既不是无所不能，也不是不负责任的提线木偶，它是一套需要被量化、被约束、被持续修正的工程系统。

如果你手头也有一个Agent项目正在挣扎，我的建议很简单：先停下来，把“评估基线”搭起来，把自己从“感觉还行”拉回“数据说话”。有了基线，你就有了看清问题的基础；有了数据，你就有了和业务方理性对话的底气。这两件事做扎实了，项目就算慢一点，也不会烂尾。