1. Demo光环背后的四种致命幻觉做AI Agent的这几个月我身边至少有三个团队折在了从Demo到生产这条路上其中两个到今天还在原地打转。说90%翻车率一点都不夸张。为什么Demo阶段永远看起来很美好因为它身处的环境被精心呵护过。演示的数据是挑过的对话轮次是可控的LLM偶尔抽风你可以悄悄再来一次——生产环境根本不给你这个机会。我总结了一下几乎所有死在Demo里的Agent项目都栽在这四件事上。1.1 看起来能跑和真的能跑差了多远先讲个真实经历。某团队做了个智能客服AgentDemo演示的时候特别顺——用户问一句Agent答一句中间再调几个内部系统查查库存、看看订单状态全场掌声。结果一上生产第一个星期就崩了三回用户一句话里带了三四个意图Agent完全分不清该调哪个工具用户问了个Demo里没出现过的问题Agent直接编了个答案回复客户再后来一个简单的时间查询请求Agent连续调了八次工具把上游系统打挂了。问题出在哪Demo阶段的Agent本质上是在记忆正确答案。演示的每一条用户问题背后都是你反复调试过的Prompt路径。你看着它在思考其实它只是在一棵你修剪好的树上走路。生产环境用户说的话千奇百怪这棵树根本覆盖不住。Demo只证明了一个事情在输入可控的前提下这条链路能跑通。它证明不了在输入不可控的前提下系统还能保持正确。这就是第一重幻觉把演示成功当成了能力具备。1.2 三个最容易忽略的隐藏假设第二个幻觉是你根本不知道自己做了多少隐藏假设。我梳理了一下常见的有三个假设一上下文总是干净的。Demo里每次对话都是新开的但生产环境里用户的上下文可能跨越几周。上次对话的残渣、无关的历史信息、过期的意图全部会灌进Agent的上下文窗口里。它会记住很多不该记住的东西然后做出莫名其妙的决定。假设二工具调用总会成功。你在Demo里调内部API网络是通的数据是完整的鉴权是放行的。生产环境里API可能超时、可能返回错误码、可能数据格式变了。Agent面对这些失败时不会像你一样冷静它可能会重试三次然后编造一个答案告诉你成功了。假设三评价标准是结果对不对。这是最致命的。Demo阶段你只看最终有没有答对问题。但生产环境里调用了多少个工具才答对、花了多少token、额外调了哪些不该调用的接口这些才是真正决定系统能不能活下去的指标。一个能答对但每次要烧掉20万token、调用15次工具的Agent放在生产环境就是一颗定时炸弹。1.3 90%翻车率的真实构成我和几个同行的朋友聊下来90%这个数字不是拍脑袋拍的。它的构成大致是大约30%的项目连Demo阶段的边界都没跨过去一接触真实流量就暴露了上下文污染、工具调用不可靠的问题大约40%的项目能处理部分真实场景但Prompt和逻辑之间的耦合太严重每次迭代某个模块都牵一发而动全身最后在无穷无尽的调参中团队失去信心剩下20%的项目技术链路跑通了但可观测性为零出了错没人知道Agent当时在想什么最后被合规和稳定性压垮换句话说死在Demo里不是因为你模型选得不好而是你在用一个建实验楼的方式盖写字楼。前者的承重墙是代码逻辑后者的承重墙是工程体系——评测、监控、版本管理、降级策略。这些东西在Demo里一样都没有生产环境一个都不能少。2. 第一道突围把不确定性关进笼子跨过Demo到生产的第一道坎核心就一句话不能让LLM的即兴发挥接触到生产环境的确定性需求。模型可以灵活但业务的边界必须刚硬。2.1 tool call的确定性控制很多Agent项目翻车翻在最基础的tool call上。Demo里你给Agent定义了五六个工具它用得很准。一上生产工具列表扩大到三十个它开始犹豫——有时候调错工具有时候干脆不调用工具直接开始胡编。这里有个很反直觉的结论工具越多Agent越容易犯错不是模型能力不够是它的决策空间变大了。人尚且会在一排按钮面前犹豫模型更会。我在项目里做了一件很土但是很有效的事给每个工具前加上一长串描述明确写出什么时候该用这个工具、什么时候绝对不要用。别小看这件事模型真的是靠描述在理解工具边界的。描述写得模糊它就模糊描述写得精确它就精确很多。另一个关键操作是对tool call参数做严格的JSON Schema校验。Agent要调函数参数先过一层校验器类型不对重新生成字段缺失就报错。你可能会觉得这是多此一举但实测下来这个校验器能挡住至少20%的错误调用。模型会一本正经地生成一个格式完美但数值完全离谱的参数没有校验层这个错误会直接打穿到业务系统里。2.2 结构化输出与失败重试策略Demo阶段你让Agent返回纯文本它返回纯文本你和前端都对格式心知肚明跑得挺好。生产环境纯文本就是灾难——下游系统解析不了异常处理无从谈起。我的建议是一切Agent的输出先转成结构化数据再进入业务流程。要么用function calling把结果直接映射成JSON要么让模型输出JSON再强行校验。这个动作把Agent从会话机器变成了决策引擎——它输出的是一份可以被程序消费的数据而不是一段需要人去理解的文字。关于重试有个大家容易犯的错模型一报错就重发同样的请求。结果就是同样的错再来一遍白白烧token还拖慢响应。正确做法是重试时只截取错误发生之前的上下文配合错误信息重新生成。比如JSON解析失败就把上面这段对话之后的JSON格式不正确请修正后重新输出作为附加上下文让它知道错在哪。2.3 弹性区与硬逻辑区的隔离这是我做了几个项目之后才提取出来的关键设计原则。简单说任何一个Agent系统的内部都可以切成两个区域弹性区LLM的决策、推理、工具选择这部分允许各种输出依靠Prompt和模型能力管理硬逻辑区业务规则、状态流转、权限校验、数据持久化这部分代码写死不允许模型插嘴举例来说一个订单处理Agent判断用户是不是在问订单状态是弹性区的事但订单状态从待付款流转到已付款必须经过支付回调就是硬逻辑区的事。模型不能因为用户语气急迫就帮你把订单状态置为已发货。很多翻车项目就是把这两个区混在一起让模型去管理本该由代码管理的业务规则。结果模型做了一个看似合理但违反业务规定的操作你连锅都不知道该甩给谁。3. 第二道突围状态、日志与可观测性生产环境里的Agent最大的噩梦不是它做错了而是它做错了你却不知道它为什么这么做。模型是黑盒但工程体系不该是黑盒。3.1 Agent状态序列化让每次决策可回放Demo阶段Agent跑在Jupyter里所有状态都在内存中打印一下就能看到。生产环境Agent跑在微服务里每次请求可能横跨多个节点、多个外部系统。它为什么调了那个工具为什么不调这个工具你完全没有头绪。我的做法是引入事件溯源式的日志把Agent的每个关键决策点作为一条结构化记录写进事件流里。每一条记录都包含当前轮次的完整输入摘要模型输出的完整内容包括中间思考过程如果能拿到的话Agent选用了哪个工具、传入了哪些参数工具返回了什么结果、Agent如何解读这个结果有了这套事件流出了线上问题你可以像回放录像一样把Agent的整个决策过程拉出来看。它不是一份冷冰冰的错误报告——调用了查询库存工具时参数非法——而是一份完整的决策轨迹——Agent在第3轮判断需要查询库存传入参数仓库IDabc这个ID是从上一轮用户消息中解析出来的解析逻辑是……状态序列化的另一个好处是可以做决策回放实验。同一个输入换了新版Prompt之后Agent的决策路径发生了什么变化这些变化是更好还是更坏没有序列化的状态你连对比分析的素材都没有。3.2 人机协同的确认点设计Agent在生产环境里最让人不放心的一点是它在自动化地做一些有后果的事情。发邮件是小事但如果它认为用户想要退款然后直接调用了退款接口呢解决方式不是给Agent绑手绑脚而是在关键动作前面设确认点。确认点的位置要根据动作的影响范围分级只读操作查库存、查状态无需确认Agent自由执行写入操作创建订单、修改资料需要经过规则引擎校验校验通过就执行高影响操作退款、删数据、对外发消息强制进入人工审批流Agent只负责准备审批材料这个设计有点像给Agent装了一套刹车系统。Demo里你不需要刹车因为你是驾驶员随时可以踩停。生产环境里驾驶员变成了代码本身刹车必须变成系统的一部分。3.3 可观测性指标与告警日志做好了之后还需要把日志变成可度量的指标。我建议每个Agent项目至少盯住这几项每轮对话的工具调用次数。健康值在1到2次之间。高于5次说明Agent在瞎折腾可能陷进某种循环里出不来。这个指标很灵敏一旦飘高基本就是Prompt或者工具描述出了问题。单次请求的Token消耗。生产环境下成本是硬约束。如果一个请求的token消耗比上周同期涨了30%大概率是Prompt上下文被撑爆了又或者Agent在反复尝试同一个失败路径。工具调用的成功率与失败模式。不是所有失败都值得告警。如果90%的失败集中在某一个工具上那基本上这个工具的描述、参数定义或者上游服务有问题。如果失败分布得很散可能就是Agent本身的决策出了问题。端到端延迟。Agent调用链太长必然导致延迟升高。跟踪每一步的耗时定位是LLM推理慢、工具调用慢、还是排队等资源。这四个指标是底线不是全部。超过阈值的告警一定要配。我见过太多团队Agent跑出了问题复盘的时候翻日志翻到凌晨三点只因为日志打得够全但没有同步配置告警。生产环境慢半拍损失可不会等你翻完日志。4. 第三道突围评测体系是路线图而非打分器其实说句公道话Demo阶段很多做Agent的人不是不努力。改Prompt改到凌晨的情况我也干过。但问题在于没有评测体系的时候调Prompt就像开着没有仪表盘的飞机盲飞。你觉得加了这句话之后效果变好了但你说不出变好了多少、在哪些场景下变好了、哪个参数变了导致变好的。4.1 离线评测集与生成式评判第一步是建一个离线评测数据集。不用多我的建议是至少100个case起步覆盖三种路径正常路径标准提问、标准场景大概占60%边界路径问法刁钻、含义模糊、跨场景混淆的情况占20%异常路径工具调用失败、信息不足、用户情绪化等情况占20%有了数据集之后怎么判断Agent的输出好还是坏传统做法是人工标注但迭代一快人工根本跟不上。这里我强烈推荐用LLM-as-a-judge的方式让模型当裁判去评估Agent的输出。实测下来的经验是让裁判模型把评估理由写出来而不是只给一个分数。有了理由你才能知道Agent到底哪一步走偏了。评判维度要多方面不只是最终答案对不对。还要看过程中有没有做多余的工具调用、有没有捏造工具不存在的返回结果、在信息不足时有没有强行编造答案。很多Demo效果良好的Agent在过程合理性这个维度上惨得一塌糊涂只是没人拿尺子量过。4.2 线上badcase回流闭环离线评测集能防住你想到的问题防不住用户真实抛出来的问题。所以必须建立badcase回流机制。具体做法是在线上给每个Agent请求增加一个分流位让用户可以对回答满意/不满意做反馈同时自动抓取那些工具调用失败、重复调用、响应超时的请求汇聚成一个badcase池。每周固定把这批badcase丢进评测集里重跑看Agent是否犯了同样的错误。这个过程的价值在于你的评测集是活的不是建完就扔的。它随着线上真实情况不断生长每长一批caseAgent就多了一层防护网。我见过有团队把线上用户反馈了回答太敷衍的case交给Agent重跑发现Agent在面对一个三小时前的历史对话时状态丢失完全忘了用户之前提过什么。这个case如果只靠离线集根本发现不了但回流闭环一建它是第一批浮出来的问题。4.3 用评测驱动Prompt迭代评测体系最大的价值是用数据驱动Prompt迭代而不是拍脑袋。我之前某个项目里同事改了一段Prompt信誓旦旦说这样改更好结果评测一跑整体得分反而下降了8%。如果不是评测体系拦着这个版本就上线了线上必然又是一轮翻车。正确做法是每次Prompt改动先跑离线评测集对比新旧版本的得分变化。得分上升上线得分下降回滚。同时记录下改动了什么、为什么改、效果如何慢慢形成团队自己的Prompt迭代日志。评测体系不应该只是开发阶段的一个环节它应该嵌入到CI/CD流程里。每次Agent的Prompt或代码有改动自动触发评测形成合入门槛。达不到门槛代码合不进去。这套流程建立起来之后Agent的质量曲线就会开始稳步向上——不是靠运气是靠机制。5. 第四道突围架构解耦与降级生存评测体系解决的是Agent做得好不好的问题。架构设计解决的则是Agent挂了之后系统还活不活得下去的问题。对于后者我见过太多项目完全没有任何预案。5.1 Agent服务与业务服务的解耦Demo阶段最典型的写法是一个FastAPI应用里既有数据库操作、又有LLM调用、又有工具逻辑全揉在一起。跑起来没问题上了生产LLM服务一抖动整个业务链路跟着瘫痪。正确做法是把Agent单独拆成一个服务和业务服务分开部署。业务服务接收用户请求之后通过消息队列把Agent任务丢过去Agent跑完之后再把结果写入任务结果表业务服务查询结果返回给用户。好处有三个Agent服务可以独立扩缩容LLM的高峰不会拖垮主业务Agent的崩溃被限制在边界之内不会影响主链路的健康度Agent服务的日志、监控、告警可以单独做一套体系不用和业务日志混在一起。5.2 异步化与缓存生产环境里Agent调用LLM是典型的慢操作。如果每次用户请求都同步等待Agent跑完在线的体验会非常差。这个阶段就需要异步化改造。从我自己的经验来看适合Agent的生产交互模式是用户提交任务之后立刻返回任务已受理的确认Agent在后台异步执行完成后通过推送/回调/查询等方式通知用户结果。这种模式对用户体感极其友好也让Agent有时间做多轮工具调用、外部系统查询这些耗时的操作。与此同时一定要建缓存。相同的用户请求、相同的上下文前缀不应该每次都重新调用LLM。实测下来缓存命中率如果做到20%以上模型成本能省下可观的一笔。注意缓存key的设计要小心别把不同用户的上下文串了。建议按用户ID和任务类型做前缀隔离。5.3 依赖失效时的降级策略LLM服务挂掉、工具API超时、模型返回格式错误——这些在生产环境里不是如果是必然。面对必然的失败你至少需要两套降级预案。预案一LLM挂了走规则引擎。不是说规则引擎能解决所有问题而是至少在LLM失效的窗口期系统还能处理一部分高频、简单、可规则化的请求。比如订单查询、物流跟踪这种完全可以写死逻辑走模板返回。规则引擎能顶住2小时LLM服务可能就恢复了你不至于全线停摆。预案二Agent进入只读模式。如果检测到工具API大面积超时系统自动把Agent的可用工具集缩为只读工具禁止它执行写入操作。这个机制能避免一个失控的Agent在故障期间反复重试失败工具、引发更严重的系统动荡。降级策略的关键是演练。别等到故障来了才临场应变。每月模拟一次LLM服务宕机让整个系统自动走降级路径检查哪里还有遗漏。这套流程跑顺了真的遇到故障时你会感激之前练过的每一轮。6. 上线前对照清单与资源配置所有原理都讲完了最后给你一份可以直接抄的清单。这不是一个应该做的清单而是一个不做就会出事的清单。我建议你在上线前逐条打勾。6.1 一份可以抄作业的Checklist这份清单按模块划分覆盖从模型到工程的各个层面模型与提示词[ ] 所有工具定义有精确描述明确何时该用、何时禁止用[ ] tool call参数经过严格JSON Schema校验[ ] 系统Prompt没有诱导模型编造信息的措辞[ ] 所有输出规范化结构化输出优先纯文本兜底状态与可观测性[ ] 每个Agent决策点都有结构化事件日志[ ] 有完整的事后回放能力事件流 日志快照[ ] 配置了Token消耗、延迟、工具调用次数等基础指标[ ] 关键路径配置告警超阈值能第一时间触发评测体系[ ] 离线评测集至少100个case覆盖正常/边界/异常三类路径[ ] 有自动化的模型评判机制不只是人工抽查[ ] 线上badcase回流通道已建立[ ] CI流水线接入了评测门槛架构与稳定性[ ] Agent服务与业务服务解耦部署[ ] 异步化改造完成长任务不阻塞HTTP请求[ ] LLM调用有缓存命中逻辑验证过[ ] 依赖LLM和工具的降级预案已经演练这份清单挂在会议室墙上每次上线前对一遍。我敢说能把这份清单打完整勾的项目翻车率会降到一个让人安心的数字以下。6.2 人力和算力怎么分配很多团队做Agent项目的时候有个共性误区初期把全部人力砸在调Prompt上等上线出问题了才急急忙忙补工程。效果自然不好。我的建议是反过来先花时间搭工程骨架再花精力调模型效果。至少要有一个人专门负责评测体系和可观测性从项目启动的第一天就建。Prompt迭代是持续性的工作但评测和工程是地基不考虑地基的迭代就是盖危楼。算力层面不要一上来就上大模型、配一大堆高并发资源。先用小模型把链路跑通评测集跑及格之后再考虑升级模型或者扩展并发。以当前主流开源基座模型的能力配合一套好的工程体系完成大部分业务场景的Agent任务是完全够用的。这个选择能帮你省下大部分预算投入在更需要打磨的工程质量上。6.3 从第一个线上case到稳定运行上线之后第一个星期是最需要绷紧神经的时期。这时候你的工作重心主要是盯坏请求。每天早晚各看一次badcase池把每一个失败案例归类、分析、定位快速修正后加入回归集。不要想着要准备到完美才上线。第一个线上case永远比第一百个测试case更有价值。原因是线上的输入分布和任何测试集都不一样。你带着一套评测体系上线上线前就跑过几十个case但从第一个真实用户请求开始这套体系才能真正被检验。上线第一周谁的Agent稳定运行谁不是靠运气。靠的是上线前工程骨架够硬上线后回流闭环跑得够快。把这套机制建立起来一个Agent项目才算真正完成从Demo到生产的跨越——不是说代码上线了就完成了而是说这个系统拥有了持续演进、持续发现错误、持续修正自身的能力。到了这一步你的Agent才算真正活在了生产环境里而不是活在PPT和演示录像里。我在几个项目里反复验证下来的体会是Demo是起点生产是战场评测和可观测性就是你的侦察兵和医疗兵。没有它们你的Agent走得再快也走不远。
