产品群里那天的日报特别扎眼我们做的AI智能体上线第七天调用量是个位数。更尴尬的是其中两条还是我们测试自己点的。三个月前立项时大家还很兴奋——要做一个什么都能干的智能助理上能查库存、下能开审批、中间还能自动生成邮件。三个月后这个被寄予厚望的东西安静地躺在系统导航栏里几乎没人点开。我复盘了很久问题根本不是模型不够强也不是团队不够努力。我们踩了一个特别典型的坑AI智能体的选型做急了。当时市面上到处是AI智能体应用案例媒体天天在讲多模态大模型新进展团队里弥漫着一种再不搞就被落下的焦虑。在这种氛围下做出来的东西表面上披着最新技术的外衣骨子里却既没有想清楚用户要什么也没有为真实使用场景做好工程兜底。这篇文章想把我们这三个月从选型、开发、上线到无人问津、再重新调整的完整过程拆开聊。重点不是说我们错了这种废话而是把那些表面是模型问题骨子里全是产品问题和工程问题的细节讲透。如果你也在做一个AI智能体或者正在纠结要不要上车、选什么技术路线这篇复盘应该能帮你省下不少时间和预算。1. 三个月热度和三天的冷却先把选急了的过程摊开看先交代背景。我们当时做的是一个内部业务线的智能助理定位是一站式AI帮手。立项非常快月度技术会上有人提了一句现在外面都在做智能体我们是不是也该有一个然后大家就开始聊功能清单。第一次讨论会结束时目标已经变成了支持多轮对话、能调用业务系统、自动处理审批流程。说实话这种起手式现在回头看几乎注定会翻车。1.1 选型会上没有人问用户到底要不要我后来翻了一下当时的汇报材料核心指标就三个用的是哪一代大模型、接了多少个工具、响应速度快不快。清一色都是从技术供给端出发的自嗨指标。业务侧同事其实反映过真实的痛——跨系统填单太麻烦数据要从A系统抄到B系统再贴到C系统但我们把它抽象成了做一个对话框替你把这些全干了。这中间隔着的不是技术难度而是巨大的交互鸿沟。当时市场上能找到的AI智能体应用案例大多展示的是你问我答式的demo看着很唬人。我们也照着这个范式做一个聊天窗口一个输入框告诉用户随便问。但没人想过用户打开一个空白的对话框时他该怎么描述自己的需求他不知道这个AI的能力边界不知道一句话会不会被理解错更不知道AI会不会乱操作。这个心理门槛比开发一个功能高得多。1.2 现在回头想真实需求其实长得很朴素真正的需求不是一个会聊天的AI而是让跨系统填单这件事别那么烦。这两者之间的差别是产品范式的差别。我们的脑回路是用AI替代所有手动操作但用户的高频动作其实就那么几个查一个数据、填一个表单、问一下进度。这些动作如果不涉及跨系统原系统两步就点完了如果涉及跨系统问题也完全可以靠一个更聪明的表单联动解决未必需要上自主决策的智能体。还有个信号特别能说明问题。后来产品上线时我们挂了个免费不限次数的标语想着至少能靠零成本吸引一波用户。结果免费和无限次也没用该没人用还是没人用。这就很说明问题用户不用的原因根本不在于价格、次数这些成本项而在于这个东西在他要干活的路径上不但没有变方便反而多了一道我该怎么跟你说的思考成本。1.3 模型会越来越强掩盖了一切风险团队当时还有个集体潜意识模型能力迭代那么快现在的某些不足下个版本自然就解决了。这句话理论上没错但它掩盖了三个当时没有意识到的问题第一模型变强解决的是理解和生成的问题解决不了业务系统要不要开放接口权限边界怎么设出错之后怎么补偿这些问题第二多模态大模型新进展确实日新月异但我们的业务场景根本用不到多模态追新指标纯粹是浪费精力第三所谓神秘模型上线这种新闻每个月都有但你永远不可能靠一次次换模型来弥补产品定位的失误。所以选急了的本质是我们把技术的进步速度当成了自家产品的进步速度把别人家demo的惊艳当成了用户会为它买单。这两个错觉叠加直接把项目推向了上线即遇冷的结局。2. 表面是没人用骨子里是这四层都没想明白产品上线没人用团队第一反应通常是是不是推广不到位是不是入口藏太深。这些是原因但不是根本原因。我把用户流失的原因拆成了四层从外到内分别是场景、信任、交互、反馈。这四层每一层都出了问题叠在一起才是真正的没人用。2.1 第一层场景不痛AI解决的是个伪需求伪需求不是说这个需求不存在而是说它不够痛或者已有的低成本方式完全可以覆盖它。我们的智能体号称覆盖二十几种能力什么查库存、查订单、生成周报、写邮件、发审批听起来很全。但仔细一算每种能力背后都有一个更轻量的替代路径查库存原来的系统两秒就能出结果生成周报模板改一改十分钟搞定发审批手机App上点一下确认。用户永远是懒惰的他会选择路径最短的那个方案。对他而言打开一个对话框、组织语言、等待AI理解、再等它执行是一条全新的、充满不确定性的路径。只要原来的路径没有断掉他就没有动机切换到AI上。AI能做这件事和用户愿意用AI做这件事之间差着一个这件事原本有多烦的阈值。我们没有做过任何用户调研来确认这个阈值。2.2 第二层信任断档一次出错就前功尽弃如果说场景不痛是用户没有来的理由那信任问题就是用户来了之后留不住的原因。在体验期内确实有些好奇的用户尝试过但反馈几乎都集中在同一个点上它答错过一次或者某个操作它执行错了从此就再也不想用了。这里有个特别残酷的规律传统软件出错用户会认为是bug愿意等修复AI智能体出错用户会直接认为是这AI不行然后彻底弃用。因为传统软件的行为是可预期的而AI本质上是概率输出天然有一种不靠谱的心理暗示。一旦它给出一次离谱的回答或者调用工具做了一件用户没预期的事信任就瞬间归零。事后复盘那次答错事件原因其实是我们数据库字段映射配错了跟模型智力没关系。但用户不会去区分他看到的是一次不可控的行为这就足够让他把整个产品拉黑。这个教训让我明白在智能体这种产品形态里出错容忍度比传统软件低一个数量级。做这个产品首先要想的不是能做得多好而是出错时怎么兜住。2.3 第三层交互太重对话框不是万能的上帝入口我们当时把对话框当成了唯一的交互形态觉得自然语言交互是最高级的交互。但现实中这个选择给用户带来了实实在在的认知负担。第一他不知道该说什么面对空白输入框他脑海里只有它到底能干嘛的疑问第二即使他知道了把一件事说清楚也要打半天字在内部工具场景里用户更愿意点按钮而不是打字第三AI的理解有延迟用户每句话发出去都要等模型响应这个等待本身就是一种成本。这个认知让我后来对对话框这个交互形态特别警惕。对话框适合的是开放式、无明确路径的探索式场景比如问一个知识、聊一个方案。但业务工具里的操作大多是有明确路径的用户要的是少想一步直接到达结果。这时候按钮、表单、快捷指令的体验天然优于一个自由文本框。我们后来把交互从聊天改成触达点即操作之后数据涨得比预期快得多后面会细说。2.4 第四层反馈黑洞团队根本不知道用户为什么离开最让我难受的是当时系统里连基本的行为埋点都没有。上线两周我们问自己用户到底卡在哪一步答案竟然是不知道。没有会话记录、没有用户输入日志、没有工具调用的轨迹。我们只能靠猜测也许是不想用也许是不会用也许是不知道入口。这个反馈黑洞的后果是灾难性的它让团队失去了迭代的抓手。产品陷入了一种瞎改状态今天把入口挪到首页明天改一下欢迎语后天换个提示词全是隔靴搔痒。直到后来我们补上了完整的会话日志和节点级监控才第一次看到真实的用户行为才知道大问题出在工具调用那一步。关于这部分这几乎是所有做AI智能体的团队最容易忽略、也最该优先做的事。3. 工程人必须自己背的锅LLM智能体的容错和可靠性前面说的都是产品层面的问题但工程侧的问题同样致命甚至更致命。因为产品问题可以通过调整定位、换场景来绕开而工程问题如果不在架构层面解决就算用户来了也会被赶走。这正好对应我自己最近反复琢磨的一个方向——LLM智能体的自主容错控制说直白点就是如何让一个AI智能体在真实生产环境里犯错了不闯祸、断掉了能恢复、看不懂的时候知道停下。3.1 多步任务断在中间却没有恢复机制我们的智能体接了工具之后设计了很多一条指令完成一串操作的流程。比如查一下库存如果小于安全线就生成一张采购单。这个流程至少包含三到四个步骤解析意图、调用库存系统、做判断、再调用采购系统。问题在哪里假设第二步库存系统超时了或者返回了一个非预期的JSON结构整个流程就死掉了。用户看到的是一条冷冰冰的我失败了然后没了。没有重试、没有降级、没有告诉他我已经查到了库存但生成采购单那步失败了你可以手动处理这个环节。一个能在半路死掉的智能体跟一个没有导航的车一样没人敢开。后来我们才明白多步任务必须有状态机设计。每一步都有明确的状态运行中、成功、失败、超时、人工介入。失败时要根据失败类型走不同的策略临时性故障就重试数据格式错误就停下来告诉用户权限不足就引导到人工流程。这个设计和后端开发里的分布式事务补偿是一个道理只不过做AI智能体时几乎每个从传统业务系统转过来的人都会下意识忽略掉。3.2 上下文污染前面的错误会传染给后面的判断第二个隐藏很深的坑是上下文污染。多轮对话时模型会把所有历史信息都当作判断依据包括它自己之前犯下的错。举个真实的例子用户在第二轮问那单子帮我改到5000块AI在第三轮执行前把第一轮里用户报错的旧数字当成了最新值。原因就是系统把第一轮的完整上下文原封不动地塞给了后续调用。这个问题在传统软件里不存在因为传统软件有明确的状态存储。但LLM天然是无状态的它的状态全靠上下文窗口里的token而这些token里既有正确信息也有历史错误信息甚至有用户随手输入的噪声。解决办法其实不难对关键信息做结构化抽取和存储对话开始时只注入当前可信的事实汇总而不是把所有原始聊天记录都丢给模型。同时在每一轮工具调用结束后主动做一次信息摘要把经过验证的结果回写进状态库把噪声从上下文里清理掉。这些事不复杂但需要有人真的去设计默认的对话框架可不会帮你做。3.3 工具调用的边界权限、幂等、超时一个都不能少工具调用是智能体最危险的部分因为它让AI从回答问题变成了执行操作。一个操作一旦涉及真实的业务系统就需要按对人操作的审计标准来约束AI。我们踩过的具体的坑我列个清单你可以直接对照检查自己项目工程问题具体表现补救方案超时未配置工具调用30秒没响应用户以为系统卡死所有外部调用必须设置超时上限超时按失败处理幂等缺失用户重试时生成了两张重复的采购单每次任务生成唯一请求ID目标系统做幂等校验权限过大智能体拥有超管权限有一次差点误发邮件到全员遵循最小权限原则按场景逐项授权不能给万能钥匙返回格式不可靠第三方系统返回了不符合预期的字段解析直接抛异常所有工具返回都要做结构化校验失败走降级分支这套东西听起来很后端但做AI智能体恰恰最缺的就是这个。很多人被大模型很聪明这件事迷惑了以为模型能自己处理好一切实际上模型只能处理理解和生成工具调用链的可靠性必须由工程代码来保证。我甚至建议如果团队没有做过多步系统集成的人先不要急着上智能体他会把业务系统搞乱。3.4 可观测性不是加分项是必需品最后也是一开始最亏的是我们没有任何针对LLM调用的日志体系。模型返回了什么、工具返回了什么、用户的原始输入是什么、哪一步执行失败全部没有记录。后来我们补了一套非常基础的观测方案思路是这样的给每一次用户请求生成一个全链路trace_id从输入进入开始每个环节意图识别、工具选择、工具调用、结果生成、用户确认都记录一条结构化日志包含输入输出摘要、耗时、错误原因。不要指望用户去描述刚才哪里出问题了而是通过日志你能自己看到100次请求里有37次卡在工具调用这一步其中25次是因为权限校验失败。这个观测系统上线后我们终于结束了靠猜来优化产品的状态。它是整个翻盘过程中性价比最高的一件事没有之一。十几行日志代码换来了对产品运行状态的完全掌控。4. 翻盘路线从没人理到有人用的调整记录讲完问题讲讲我们是怎么调整的。这个过程大概是收敛场景、嵌入流程、重建信任、灰度共研。每一条都不算高深但组合起来确实让数据一天天好起来了。从个位数日活到稳定两位数再到陆续有用户主动提需求前后大概花了一个月。4.1 收敛场景把智能助理砍成三件事我们做的第一件事是接受大而全的智能助理是一个伪命题这个现实把所有能力列成一张表逐条问三个问题业务是不是真的痛现有没有更轻的替代出错代价高不高最后砍到只剩三件事真正的P0场景是跨系统填单助手。为什么选它因为填单这件事用户确实需要在三个系统之间来回复制粘贴原路径很烦出错代价也可控填错了系统有校验不会造成真金白银的损失而且这是真实高频动作每天都会发生。至于查库存、生成周报这些统统下掉不做。这个决定做出来之后团队内部是有分歧的有人觉得智能体就该全知全能做成了一个只会填表的工具格局小了。但后来的数据证明把一个用户最痛的场景做到极致比做二十个没人用的功能有价值得多。现在回头看与其说是格局小不如说是定位准。4.2 从对话框到嵌入工作流交互上我们做了一个关键转变不再把智能体当成一个独立的聊天窗口而是把它嵌入到填单页面旁边做成了边栏助手。用户的路径从打开AI对话框→描述需求→等结果变成了正在填单→遇到要跨系统核对的数据→旁边助手主动提示需要我帮你跨系统核对吗→点一下确认。这个转变的本质是把用户主动找到AI变成AI出现在用户需要的地方。任何一种数字化工具都应该尽量贴着用户的既有工作流走而不是另外造一个中断工作流的入口。填单页侧边栏的方案让用户第一次感受到了这东西确实在帮我干活而不是又多了一个要伺候的窗口。4.3 可控性设计每一步都让用户看得懂、拦得住信任是智能体产品最不可绕过的一关。之前的黑盒式全自动操作用户不敢用。这一版我们做了两个在体验上变笨了、但实际效果更好的设计第一所有关键动作执行前必须展示一条明确的确认信息比如我将读取A系统的采购单号并与B系统的库存数据进行比对是否需要继续用户确认之后才会执行。多了一步操作换来的是我能掌控它的安全感。第二执行完成之后系统会输出一段像操作回执一样的摘要说明它刚才做了什么、结果是什么。这两处设计让整个智能体的行为变得可以预期用户的信任感就是这样一点点攒起来的。4.4 让真实用户教我们做产品最后一步是灰度。我们找了五个平时填单最多、愿意尝鲜的同事让他们在真实工作里使用我坐在旁边观察。这个过程非常打脸也极其有价值。最典型的发现是用户根本不会用完整的自然语言跟AI交流。他们说的话经常是那个帮我看看就上次那个单。我们最初设计的高级自然语言入口完全是给产品自己看的。于是我们加了一组常用操作按钮把用户最常做的几个动作直接做成可点击的快捷指令结果使用率暴涨因为用户不需要组织语言了点一下就行。从这之后我们形成了一个规矩任何新功能必须由至少三个真实用户用过并说好用才算上线不能只靠开发自测和演示demo。这个规矩救了我们后面很多次。5. 给准备上车的人三个问题先把刀架在自己脖子上如果你正在评估一个AI智能体项目或者已经开始了但总觉得哪里不对我建议先停下手里的事认真回答下面三个问题。回答不上来或者答案模棱两可那大概率又是在重复我们走过的弯路。5.1 砍掉AI用户的工作会塌方吗这是个反直觉但很有效的检验方法。你可以去问你的目标用户如果这个智能体立刻消失你会回到什么状态如果他回答回到原来的方式也还行那说明你的产品对他来说是锦上添花甚至是可有可无。真正的价值场景往往是用户回答那我又要每天花一小时在那几个系统之间反复贴数据了想想都烦。只有这种没有它就会感受到明显损失的场景才是智能体能站住脚的地方。别把希望寄托在用户只是还没养成习惯上。对于一个要学习新交互、还要承担AI出错风险的新产品用户转身的成本极低一旦感受不到显著收益他就会走。5.2 你的场景是替代人还是辅助人这是个战略定位问题。替代人的场景比如让AI自动判断并直接执行采购审批对可靠性要求极高因为它把决策权完全交给了机器。辅助人的场景比如帮用户把三个系统的数据汇总好再由用户自己判断和确认智能体只是缩短了路径但最终决策权仍在人手上。我们的经验是起步阶段一定要选辅助人的场景C端产品尤其如此。辅助人模式天然绕开了信任建设、责任归属、出错治理这三大最费力的工程难题。等团队积累够了容错控制能力和用户信任再去向替代人的场景演进会顺很多。5.3 出错一次代价是什么请在立项时就把这个问题写清楚落到纸面上。如果智能体执行错了是产生一笔虚假订单是发错一封邮件是给客户报错一个价格还是只是推荐内容不够准每一档错误对应的工程投入完全不同。你愿意花多少功夫去做容错、加确认、补审计直接取决于这个问题最坏情况的答案。我见过很多项目一上来就在全自动执行的方向上走结果做到一半发现自己根本承受不起出错代价全部推翻重做。如果早一点回答这个问题就能从一开始选择先做确认制、再慢慢自动化的路线省掉一个月的返工。5.4 附一套极简自检清单结合这三个月踩的坑我给你整理了一个可以打印出来贴在工位上的清单检查项通过标准场景痛点至少有10个目标用户亲口说过这个流程很烦替代路径原流程需要跨2个以上系统或操作超过5步出错代价最坏情况不涉及资金/合规损失或流程内有兜底校验使用频率场景属于日频/周频而不是偶尔想起才用一次数据可得所需业务数据有接口可读不需要靠模型猜测信任机制关键动作有人工确认执行结果有回执摘要工程兜底有超时、重试、幂等、日志和权限边界灰度计划能找到5个真实的种子用户且愿意花时间陪我们迭代这套清单没什么高深理论全是实打实的经验。我当时如果早点把它列出来可能就不会烧那三个月了。6. 写在最后这次失败值回票价的地方最近行业里每天都有人在讨论AI智能体是不是下一个风口新模型、新框架层出不穷让人很容易产生一种错失恐惧。但经过这个项目我最大的体会是技术名词会过时但用户对又好用又可靠的追求不会变。我见过太多团队把大量时间花在争论用这个模型还是那个模型上却不愿意花一个下午去真正观察用户是怎么干活的。模型能力自然重要但对大多数业务场景来说它早就不是瓶颈了。瓶颈是产品有没有长在真实的工作流里是工程上有没有把容错和兜底做到位是用户相不相信这个AI不会给他惹祸。这三个问题哪一个都比追最新大模型更值得投入。这次失败最值钱的部分不是我们最终把日活做起来了而是整个团队从此对AI落地这件事有了敬畏心。我们不再觉得接个大模型、写几个工具、套个聊天框就是做智能体了。我们开始明白决定一个智能体生死的东西恰恰是那些最不性感的部分场景判断、错误处理、日志埋点、权限边界。这些工作没有宣传的价值但它们决定了用户是把你当成助理还是当成一个华而不实的玩具。如果你也要做类似的智能体别被别人都在做绑架。先蹲在用户旁边看明白他到底卡在哪里再把AI精确地放进去。从口述到今天这是我能给出的最真诚的建议。
