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 多自信，都必须先展示待执行的参数，等人类确认后才能执行；第三，全链路可追溯，每一次工具调用、模型生成、人类操作，都要有日志留痕，出问题时才能回溯。
有一个让我印象深刻的案例：某电商项目的智能客服 Agent，Demo 时客户满意度很高，结果内部灰度时发现，它对优惠券系统有一次调用了错误参数，一口气作废了用户账户里所有未使用优惠券。幸亏只是灰度环境，团队反思之后，把所有具有“不可逆影响”的工具调用都加上了双重确认。虽然每次确认员工要多点一下鼠标，但谁也不敢省这一步了。
5.3 记忆与状态管理：从会话续接开始
Agent 在企业里的价值，很大一部分体现在“跨会话记忆”——上次和这个客户聊到哪了、这个工单之前处理到什么进度、这位同事偏好的汇报风格是什么。但是，记忆边界一旦没设好，很容易出现“越权信息泄露”或者“上下文继续错乱”。
具体的做法是：把“短期工作记忆”和“长期用户画像记忆”分开存储。短期记忆放在会话上下文中，超过时间窗口或会话结束后自动清理；长期记忆统一进向量数据库，但同时必须绑定权限标签，任何一次检索都先过权限过滤器。索引和数据权限，至少要分开建两张表，权限判定一律走后端服务而不是模型的自由发挥。
5.4 可观测性：别等用户投诉才发现出错
Agent 的“黑盒感”是落地的最大障碍之一。业务方用的是决策结果，但每次结果是怎么算出来的？依据了哪些数据？他们需要一个可解释的“过程回放”。
我的建议是：在设计阶段就要求每条 Agent 输出自动附带一张“决策卡片”，包含输入摘要、检索命中的文档片段、模型推理的关键步骤、最终输出。这张卡片不一定展示给最终用户看，但至少要展示给内部管理员和审核员看。没有这套可观测机制，等业务方跑过来问“这个结论怎么来的”时，你已经来不及后悔了。
6. 从 Demo 到生产的路线图：少踩常见坑的实操节奏
走完前面的场景筛选和评测设计，就该进入实操履行阶段了。这里我给出一份自己项目中提炼出来的、相对稳妥的三阶段路线图。
6.1 阶段一：容器化 Demo（1-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 阶段拼的是灵感，落地阶段拼的是工程纪律、组织协调和对业务的耐心。希望这篇指南能让你少趟几个浑水，把力气花在真正能跑起来的事情上。
