1. 先搞清楚一个问题你的项目其实不是在“做 Demo”是在“躲验收”这几年我混迹在各类企业的智能体项目评审现场有个很扎心的共识十个 Agent 项目里至少有七个走完 POC 就没了下文。有的团队烧了几个月算力最后的产出是一段精心剪辑的录屏有的是老板在周会上看过一眼炫酷的操作演示然后就没有然后了。剩下那三成能活的也不是靠运气而是从第一天起就把“落地”当成一场工程问题来打而不是把“演示效果”当成及格线。先给个定义免得后面聊岔了。我这里说的“死于 Demo 阶段”指的是项目完成了概念验证或者原型演示客户看过、领导也点头了但迟迟没法进入真正的生产环境或者试运行两三周就被悄悄叫停最后PPT里多了一页“经验教训”。为什么会这样因为做 Demo 的时候默认的潜规则是“给 Agent 一个表现机会”。你会给它挑最简单的任务、最干净的输入、最理想的环境甚至任务失败后的重试路径都已经在脚本里铺好了。做 Demo 的人关注的是“它能做成什么”而企业真正关心的问题是“如果让它天天做它会搞砸什么”。这两个问题之间的落差就是 70% 项目死亡的真实原因。我在某制造企业的质检场景里看过一个典型的例子团队花两周把自己训练的小模型包装成多智能体系统现场演示时机械臂抓取、视觉识别、异常上报行云流水。可一问到“断电续跑”“网络抖动时调度指令会不会丢”“识别置信度低于某个阈值时谁来兜底”整个团队沉默了。后来这个项目果不其然停在 Demo 阶段你说技术不行吗其实单点能力都不差差的是没有人用企业运行的视角去审视它。所以这篇指南不想跟你聊怎么把 Demo 做得更炫而是想聊聊怎么从一开始就别让自己死在 Demo 这个温柔乡里。核心就三件事找对场景、建好评测、做好人机边界。文章里所有经验都来自我亲眼见过、或亲自参与过的项目复盘能帮你省下至少一轮试错。2. 死因解剖四类死法几乎覆盖了九成失败项目2.1 死法一拿“技术能做到”去回答“业务需要吗”这是最冤的死法。技术团队看到某个大模型能力很强比如能写 SQL、能总结文档、能自动填工单兴奋得不得了于是想尽办法把这些能力塞进业务场景。问题是很多业务需求根本不需要那么强的“智能”。举个例子某零售企业想做一个客服工单自动分类的 Agent。业务方的真实痛点是什么是每天两千张工单靠三个运营手动打标签又慢又容易漏。结果技术团队做了一个基于大模型的智能体能理解语义、能识别情绪、还能自动回复一部分常见问题。听起来很厉害可一上线发现工单分类的准确率还不如人家原来那个基于规则引擎的系统因为规则引擎是领域专家多年调教出来的大模型在面对某些行业黑话时反而容易发飘。而且更要命的是原来运营人员处理工单时顺便还能发现一些流程上的问题比如某类客诉突然暴增背后往往是产品或者配送环节出了异常。Agent 把“分类”这步自动化之后没人再看内容了这个“附带情报功能”也就没了。这里要记住一个原则Agent 应该去补业务的短板不是去秀模型的长板。技术团队眼里“昨天还做不到今天做到了”的进步在业务负责人眼里往往不值一提。立项前先花至少一周时间蹲在业务现场搞清楚哪些环节的业务人员最痛苦、哪个环节的容错率最高、哪些数据已经规整到模型可以直接消费——这三条缺一不可。2.2 死法二把 Demo 环境当成生产环境的缩影做 Demo 的时候整个技术栈是高度“减配”的。向量数据库用的是开源的小规模实例知识库文档是精心挑选的几百篇API 调用用的是沙箱密钥并发量最多也就测试脚本里那三五路。可到了生产环境所有问题都会同时找上门数据源接口不稳定、权限体系按部门隔离、存量文档格式五花八门、同一份资料在多个系统里口径不一致。更隐蔽的一个坑是“时间尺度不一样”。Demo 环境里文档更新频率是周级甚至月级Agent 的检索结果自然新鲜。但生产环境里的知识库有的数据每分钟都在变比如价格表、库存表、排班表。如果 Agent 没有设计增量更新和缓存失效机制它回答出来的内容里全是过期信息业务人员用两天就会失去信任一旦失去信任这个项目在组织内部就永远翻不了身。还有一个我在金融行业反复见到的场景Demo 的时候用的是脱敏数据、Mock 接口一切顺利上了生产业务部门要求的合规审计日志、操作留痕、敏感词过滤、模型输入输出的安全审核链路一样都没提前做。等安全团队介入了项目只能停下来补齐这些“不产生业务价值但不上不行的功能”一补就是两三个月业务等不起项目自然死掉。所以做架构设计时第一天就应该追问这个 Agent 在生产环境要对接哪些真实系统数据从哪来、多久更新一次、中间要经过哪些安全审查如果这些问题答不上来就说明还没有进入“可落地”的状态。2.3 死法三没有为非预期输入准备任何退路Demo 的另一个潜规则是输入空间是封闭的。你问什么它就答什么你给的格式不对你根本就不会这样去测。但真实业务里用户输入是没有边界的。我见过一个保险行业的智能理赔助手项目内部的模型评测跑得很漂亮常见问题问答准确率做到了 92%。可小范围放量之后业务人员问的是什么呢“猫抓伤算意外医疗吗”“昨天买今天出险能赔吗”“我有社保但单位还给我买了补充医疗两个能一起报吗”这些问题的特征是看似是简单问答实际上需要结合具体的保险条款、理赔规则、甚至当年的监管政策才能回答。模型硬答了几次被客户投诉了两轮项目就停了。这类死法的背后是团队把“模型能力”等同于“产品能力”。模型能生成自然语言但产品必须知道什么时候该生成、什么时候不该生成、不确定时怎么表达。一个合格的落地型 Agent必须内置好三类退路不确定时主动说不知道并提供人工通道、输入超出边界时转接人工、任务执行失败时给出可追踪的失败原因而不是自作聪明地强行输出一个看似合理的答案。2.4 死法四只证明“能做”没证明“能稳定地做”最后一个死法最容易被忽略团队在 Demo 阶段评测的是“最好成绩”而生产环境在意的是“最差表现”。Demo 里跑十次成功九次那自然没问题。但生产环境里的真实情况可能是高峰期并发一上来调用延迟从 500 毫秒变成 8 秒某个外部接口偶尔吐出一堆乱码Agent 就当场崩溃某一轮对话中上下文太长Token 超限整个会话就直接断掉。很多技术负责人其实心里清楚这些问题但他们觉得“这些是运维层面的事等上线前再优化”。等真到了上线前发现问题远比想象中复杂不是单纯加机器就能解决的而是要在应用层做降级设计、重试机制、超时控制、状态持久化。回头改代码工期半个月起步。所以我的建议是从 Demo 的第一天起就用生产环境的输入分布、并发模型和故障注入来跑评测。哪怕只是模拟也要在架构上预留好兜底方案别让性能和稳定性问题成为项目上线的 Killer。3. 场景筛选方法论从“能做”到“必须做”的四象限判断聊完了死法接下来是正题什么样的场景值得做我这里有一套自己在项目里反复验证过的四象限筛选法分享出来给大家参考。判断一个场景值不值得用 Agent 来做就看两个维度任务的标准化程度和业务价值密度。横轴是任务的标准化程度从“高度统一、规则明确”到“非结构化、依赖大量判断”纵轴是业务价值密度从“单次操作价值低但频率极高”到“单次操作价值极高、错误容忍度极低”。四个象限里最优的场景是标准化程度中等偏高、业务价值密度中等偏上——比如工单分类、客服意图识别、报告初稿生成、代码辅助评审。这类任务规则不是完全死的会有各种变体刚好是需要模型理解力的地方同时它做得好不好对业务有明显影响但又不是那种错一次就出大事的场景方便你在迭代中积累信任。第二佳的象限是低标准化、低价值密度的长尾任务比如大量零散的办公流程自动化单个流程跑通的价值很小但汇总起来能省不少人。不过这类场景的项目往往算不过来账因为开发成本摊到单个流程上太高我的建议是用一个 Agent 平台把多个同类长尾场景包起来做而不是只做一个点。最需要警惕的象限是“高标准化 低价值密度”。这种场景里规则引擎或传统脚本往往两三周就能搞定既便宜又稳定完全没必要上 Agent。非要用反而引入了大模型的不确定性纯属给自己找麻烦。至于“低标准化 高价值密度”的场景比如医疗诊断辅助、金融投资决策、法律意见出具这是 Agent 的“高风险区”。不是说不能做而是做之前必须设计好人机边界Agent 只做信息收集、整理、初筛最终决策必须由人来下。而且这类场景的评测周期很长至少要积累三个月以上的真实运行数据才能看出效果不适合作为第一个吃螃蟹的项目。我拿一个自己经手的物流行业项目举例团队一开始想做全自动调度助手直接替代调度员做车辆排线。这个场景属于低标准化、极高价值密度调度员要考虑天气、限行、货物急迫度、司机休息时间等各种因素一个错误的排线安排可能让一车货迟到。后来我们调整了方案让 Agent 做信息聚合和路线推荐调度员来拍板。上线以后调度员每人每天省出两小时而且 Agent 推荐的路线在 70% 的情况下可以直接采纳但剩下的 30% 都指向了一个共同原因——有几条特殊路段的临时管制信息数据源里没有。这个信息差恰恰是人工经验的价值所在。这四象限的方法能不能直接用可以但有三个前提需要先确认第一业务方愿不愿意为这个场景设一个明确的负责人。没有负责人的项目上线后所有问题都是“协同问题”最后谁都不管Agent 就成了摆设。第二企业的数据基建够不够支撑这个场景。数据没汇总、口径不一致、接口没有Agent 再聪明也是“巧妇难为无米之炊”。先花力气打通数据比调 prompt 重要十倍。第三有没有一个“灰度期”的容错空间。第一版 Agent 的准确率大概率在 80%-90% 之间剩下那 10% 谁来兜底是人工复审还是直接对外不可用这个要在上线前说清楚而不是等出了事故再讨论。把这三个前提确认完再去做技术选型和架构设计心里就有底多了。4. 评测体系设计先有“尺子”再谈“做得更好”4.1 基于规则的自动评测保底用的“硬指标”很多团队给 Agent 做评测就是把测试集拿来跑一遍然后肉眼看看结果“像不像”。这种搞法最大的问题是没有量化基准你根本说不清楚这个版本比上个版本好在哪、坏在哪。最稳的做法是无论你最终的 Agent 表现看起来有多“生成式、多智能”评测的第一层永远要是“能用规则算清楚”的硬指标。包括但不限于任务完成率代码类任务能否通过编译/单测问答类任务能否命中标准答案要点格式合法率输出的 JSON 是否能被下游正常解析生成的内容是否符合模板字数限制耗时与成本单次任务的平均调用次数、Token 消耗、端到端延迟拒绝率该拒绝的任务里有没有正确地“不回答”而不是硬答这类硬指标可能撑不起一整套智能的想象但它们是所有软性指标的“地基”。地基塌了上层多漂亮都没用。4.2 基于大模型判官的评估批量跑测试集的一把好手硬指标没法评的那部分——比如“回答是否贴合上下文”“总结是否忠实于原文”“代码是否有隐性 bug”——就得靠大模型来当“裁判”了。具体操作上我见过比较成熟的做法有两种一是多 Agent 互评让两个 Agent 互相生成、互相对比打分再由第三个人类专家抽检二是单一大模型裁判把测试用例的输入、Agent 输出、参考标准答案一起喂给一个不参与执行的大模型让它按一套评分标准打分。我不太建议一上来就用大模型裁判做唯一标准。它的评分稳定性在楼层之间会有波动如果标准问题太模糊它可能给出忽高忽低的分数。更好的用法是大模型评分 定期人类抽检校准。比如每周抽 30 条人类专家判过的案例用来检验评分模型是不是“跑偏”了。4.3 黄金数据集花两周时间建长期资产这里要专门提一下“黄金数据集”。它指的是从真实业务中抽出来、经过人类专家仔细批注的测试集数量不必多几百条就够但每条的质量必须高。这套黄金数据集是项目最有价值的“不动产”之一。它不仅用于日常评测还用于每次模型版本升级前的回归测试。没有它你换了个更强的底座模型之后根本不知道老功能会不会被“升级升没了”。建黄金数据集有几个细节值得注意一是要覆盖典型任务和边缘任务边缘任务占比最好在 20% 左右二是每条数据必须标注来源、难度、预期行为以及它和某一类已知 bad case 的关联三是数据要持续更新随着真实用户的反馈进来不断补进新鲜案例。切忌“建完就扔在一边”好好维护它它会回报你无数次。4.4 线上灰度评测让真实流量当裁判离线评测做得再细也只是“考试”不是“实战”。真实用户的提问习惯、真实环境的数据噪声、真实场景的流程切换离线环境都模拟不出来。所以一旦 Agent 达到了基本可用状态尽早搭建线上灰度评测通道。常见手段包括“影子模式”和“小流量放量”。影子模式Agent 在后台跑但不直接对用户输出决策输出结果与人工处理结果做对照间接评估准确率、召回率。小流量放量把 5% 左右的真实请求切换给 Agent人工随时待命接管。这一阶段的目标不是追求高准确率而是通过真实的输入样本发现离线评测没覆盖到的场景、错误模式快速补回黄金数据集。如果一开始就把评测体系建得很全后面每次迭代都会快很多。我最怕的就是看到有些团队一上来就调 prompt、加工具做了一堆改动却说不清哪次改动让表现变好了哪次反而破坏了已有能力——那就是在沙滩上建城堡。5. 架构设计的生存法则为真实环境的不完美而设计5.1 别贪“全智能”先做“人机交互闭环”很多 Agent 项目最开始的设计都过于“野心勃勃”恨不得让 Agent 全自动搞定一切人类只在旁边看。但在真实企业环境里全自动往往意味着全事故。建议第一版架构直接默认“人机协同”模式Agent 负责信息收集、方案生成、初筛分类、文档起草人类负责最终决策、审批、修正和异常兜底。这个模式有几个好处人类在闭环里出了问题能第一时间发现并纠正Agent 的“错误成本”被限制在可控范围人类每次修正都是免费的“训练数据”来源可以持续反哺评测集业务方更容易接受——他们不用担心“被机器替代”而是看到“机器在帮我减负”项目推进阻力小很多5.2 工具调用的可控性能约束就不要放任自由发挥Agent 项目在生产环境中最常见的形态是“调用外部工具”。比如发个请求查库存、调个接口改订单、触发一条审批流。这种情况下工具调用的权限控制是生死线。至少要做三件事第一白名单机制Agent 能调用的工具、能访问的数据源必须在配置里明确列出来未注册的一律拒绝第二参数校验与确认机制对于写操作修改、删除、审批无论 Agent 多自信都必须先展示待执行的参数等人类确认后才能执行第三全链路可追溯每一次工具调用、模型生成、人类操作都要有日志留痕出问题时才能回溯。有一个让我印象深刻的案例某电商项目的智能客服 AgentDemo 时客户满意度很高结果内部灰度时发现它对优惠券系统有一次调用了错误参数一口气作废了用户账户里所有未使用优惠券。幸亏只是灰度环境团队反思之后把所有具有“不可逆影响”的工具调用都加上了双重确认。虽然每次确认员工要多点一下鼠标但谁也不敢省这一步了。5.3 记忆与状态管理从会话续接开始Agent 在企业里的价值很大一部分体现在“跨会话记忆”——上次和这个客户聊到哪了、这个工单之前处理到什么进度、这位同事偏好的汇报风格是什么。但是记忆边界一旦没设好很容易出现“越权信息泄露”或者“上下文继续错乱”。具体的做法是把“短期工作记忆”和“长期用户画像记忆”分开存储。短期记忆放在会话上下文中超过时间窗口或会话结束后自动清理长期记忆统一进向量数据库但同时必须绑定权限标签任何一次检索都先过权限过滤器。索引和数据权限至少要分开建两张表权限判定一律走后端服务而不是模型的自由发挥。5.4 可观测性别等用户投诉才发现出错Agent 的“黑盒感”是落地的最大障碍之一。业务方用的是决策结果但每次结果是怎么算出来的依据了哪些数据他们需要一个可解释的“过程回放”。我的建议是在设计阶段就要求每条 Agent 输出自动附带一张“决策卡片”包含输入摘要、检索命中的文档片段、模型推理的关键步骤、最终输出。这张卡片不一定展示给最终用户看但至少要展示给内部管理员和审核员看。没有这套可观测机制等业务方跑过来问“这个结论怎么来的”时你已经来不及后悔了。6. 从 Demo 到生产的路线图少踩常见坑的实操节奏走完前面的场景筛选和评测设计就该进入实操履行阶段了。这里我给出一份自己项目中提炼出来的、相对稳妥的三阶段路线图。6.1 阶段一容器化 Demo1-2 周目标把“演示脚本”包装成“可部署的 Demo 包”。具体动作将 Agent 代码、依赖、模型配置、外部服务连接信息全部 Docker 化并提供一键启动脚本。这阶段不追求高并发但必须做到“换一台干净机器拉镜像就能跑起来”。做得好的团队在这一阶段通常还会顺手把核心链路的调用日志打全方便后面做评测穿跑调优。如果连这步都做不到后面的灰度根本不用想。6.2 阶段二与真实系统联调2-4 周目标与真实数据源、业务系统、权限体系完成对接。这一阶段最容易出问题的是假设前置——假设某个接口的字段叫 name结果真实接口叫 customerName假设文档接口支持分页结果只支持前 100 条。每一条“假设被打破”都意味着一次设计返工。所以联调开始前把所有外部依赖梳理成一张清单接口文档、认证方式、频率限制、超时时间、错误码。逐项核对清楚后再动手编码。宁可多花三天做系统调查也别在联调时被一个个意外打乱节奏。6.3 阶段三小范围灰度与迭代4-8 周目标用真实的业务输入反复打磨直到关键指标稳定达标。灰度的第一批用户非常关键。想清楚“谁会最先受益、谁愿意给你反馈、谁能承受一定的不完美”然后和这些人提前沟通好灰度期的目标、范围、回退机制。反馈通道也必须提前建好最好是一个群加一张在线表单用户遇到问题直接拍屏上报。灰度期要盯的核心指标就是上一节说的那些任务完成率、格式合法率、需要人类介入的比例、以及单次任务的平均耗时和成本。每周做一次复盘把新增的 bad case 补进黄金数据集然后调整 prompt 或工具配置重新评测。坚持迭代四轮以上指标会慢慢稳定下来。等到关键指标连续两周达到预设阈值、且没有出现新的重大模式性错误就可以考虑逐步扩大放量到 30%、50%直至全量开放。注意即使全量开放也永远保留人工接管的通道这是企业级 Agent 的底线。7. 我个人的一些实操心得和继续延展的方向最后再分享几条自己踩坑换来的体会希望能帮后来者少走弯路。第一条Demo 阶段的“包办婚姻”式成功常常是毒药。如果现场演示时所有流程一次跑通、没有任何意外未必是好事——这可能意味着测试集太窄、问题太简单或者演示脚本为了稳定性做了太多隐性的“代劳”。反过来如果你能在演示时主动制造一两个“意外”并展示系统如何优雅降级、如何人工接管、如何从失败中恢复那才会真正让业务方眼前一亮。买保险不如卖保险卖稳定性的样子才是最有力的。第二条项目经理要敢于向业务方说“不”。很多项目死掉不是技术不行而是需求方想要的太多。今天要全自动明天要全渠道后天要全模态最后做出来一个哪儿都能碰一下、哪儿都做不深的四不像。作为技术负责人你有责任在需求评审时把“不要做什么”和“要做什么”一样坚定地讲清楚。第三条给“解释”留出足够的产品化空间。Agent 项目上线后真正消耗团队精力的往往不是模型能力而是“让各方理解模型在做什么”。你给业务方准备的材料不应只是技术架构图而应该是“在什么情况下它会怎么做、在什么情况下它需要人介入”的行为说明。把这一页写清楚比一百页技术文档更有用。如果这个项目最终全量落地并稳定运行后续可以继续延展的方向还有不少比如把沉淀下来的黄金数据集和评测流程开放给其他业务线复用把 Agent 的可观测数据和业务指标打通做成高层的“智能化运营看板”还可以把“人机协同”的交互模式抽象成标准组件沉淀到公司内部的中台里让下一个 Agent 项目不再从零开始。坦白讲没有一个 Agent 项目是容易的。Demo 阶段拼的是灵感落地阶段拼的是工程纪律、组织协调和对业务的耐心。希望这篇指南能让你少趟几个浑水把力气花在真正能跑起来的事情上。