Demo能力为什么不能等同于生产能力

一个Agent演示可以连续完成几十步任务：读需求、查数据、生成方案、更新系统。现场效果很好，管理层很自然地希望尽快推广。真正接入生产以后，团队却遇到一系列新问题：历史数据不干净，权限远比Demo复杂，异常类型很多，人工兜底量迅速上升。

Demo证明的是可能性，生产需要证明可控性。

真实数据比演示数据复杂

演示通常使用准备好的上下文。生产环境里会出现缺失、冲突、旧版本、权限和噪音。AI对数据质量非常敏感。因此，Pilot阶段就要尽量使用真实数据分布，避免只准备“漂亮样本”。

长尾异常决定系统是否可靠

正常流程往往容易自动化。真正困难的是例外：客户给出模糊输入，系统字段缺失，外部接口超时，规则互相冲突。这些情况可能占比不高，却决定人工接管成本。如果Demo只测试Happy Path，很容易高估自动化率。

生产还需要权限和责任

Agent能否读写核心系统？谁批准权限？错误后谁停掉流程？这些问题在演示里不明显，上线后却是基本条件。NIST的生成式AI风险框架也强调治理、测量和风险管理需要贯穿生命周期。

Evaluation必须提前建立

不能等上线以后靠用户投诉判断质量。团队需要准备典型案例、边界案例和高风险案例，持续测试模型、Prompt和Context变化。人工Override也应该记录原因。这会形成后续学习资产。

Pilot要故意制造困难

成熟的Pilot不追求“成功率好看”。应该主动加入异常、模糊输入、权限限制和压力场景。把系统最容易失败的地方提前暴露。技术演示可以让企业看见未来。

生产准备度可以分层

不必要求所有场景达到同一标准。内部辅助、低风险任务可以更快上线；涉及客户、财务、隐私和安全的场景需要更严格Evaluation和Human Gate。风险分层能够避免两个极端：为了安全把所有创新拖慢，或者为了速度让高风险场景沿用Demo标准。

Demo成功后不要立刻承诺自动化比例

“这个流程可以自动化80%”是很危险的早期结论。演示环境通常看不到人工准备Context、异常处理和后续验证的成本。更好的表达是：当前在已测试场景中，AI可承担哪些步骤；进入Pilot后再测真实自动化率和人工介入。保守一点的承诺，往往更有利于建立长期转型信用。

生产设计则要求企业面对现实世界的复杂性。把两者分清，是避免AI项目从兴奋快速滑向失望的第一步。

生产能力要用真实分布检验

演示通常展示几条被精心选择的成功路径，生产系统面对的却是一种分布：常见请求、模糊输入、权限差异、历史脏数据、外部接口失败以及少量高代价异常。团队不能只问平均表现，还要知道最差情境发生什么、人工能否及时接管、错误是否会继续传播。

因此，Pilot应尽早引入经过脱敏的真实样本，并按业务分布抽样。评估集既要有高频正常案例，也要保留历史事故、专家争议和极端边界。NIST AI RMF强调评估条件应尽量接近部署情境，并在生产中持续监测系统行为。这个要求直接揭示了Demo与生产之间最容易被忽略的证据差距。

Agent还需要身份、权限和行动边界

能够生成答案的模型和能够改变业务状态的Agent，风险层级完全不同。Agent一旦可以发邮件、修改订单、提交代码或调用资金相关系统，组织就必须明确它以谁的身份行动、权限最小化到什么程度、哪些动作需要二次批准、日志能否还原决策链。

每个高影响动作都应拥有可验证的前置条件和停止机制。只读查询可以允许较宽的自主性；可回滚写入适合灰度与额度限制；不可逆、涉及客户权益或安全的决定需要正式Human Gate。权限不应跟着演示账号进入生产，而要由工作责任反推。

运行成本要包含人工兜底

模型调用费用只是总成本的一部分。Context准备、专家Review、异常调查、评估维护、供应商切换、合规证明和事故响应都会消耗持续容量。许多方案在Demo阶段显得便宜，是因为这些工作由项目成员临时吸收，没有进入单位成本。

生产评审可以追踪每百次任务的人工接管次数、平均处理时间、重复异常、失败恢复时间和质量门维护成本。若自动化率提高，却把大量复杂问题集中给少数专家，系统可能同时增加成本和人才风险。运行经济性必须沿完整工作链计算。

上线之后仍需要持续的Evaluation

模型、Prompt、检索内容、业务规则和用户行为都会变化，发布前测试无法长期代表生产。每次重要变更都应运行回归集；线上记录要能够关联模型版本、Context、工具调用、人工修改和最终结果；出现重大偏差时，团队要有降级、回滚和暂停路径。

Evaluation也需要业务Owner参与。技术指标能够发现格式、稳定性和安全问题，只有领域人员能够判断答案是否适用于真实情境、是否遗漏关键判断、是否产生客户后果。生产质量是一项跨职能责任，不能在上线时移交给运维后结束。

把“自动处理工单”的Demo放进生产

演示中，Agent能够读取工单、查询知识库、生成解决方案并更新状态。进入生产前，团队应刻意加入知识冲突、客户信息缺失、权限不足、系统超时、错误分类和高优先级安全事件。每种情况都要定义系统如何识别不确定性、停止到哪一步、向谁升级以及客户看到什么。

如果Agent只在正常路径表现良好，却无法判断自己已经失去可靠Context，生产风险会随自主步骤增加。团队可以先限制为只读建议，由坐席确认；当特定类别的一次通过率、接管原因和客户结果稳定后，再开放可回滚写入。每扩大一种动作权限，都重新检查评估、监控和事故响应。

生产准备度应分阶段证明

第一阶段证明任务价值和基本可用性；第二阶段证明真实分布下的质量与人工负荷；第三阶段证明权限、可观察性、成本和恢复；第四阶段证明规模变化后的稳定性与Owner机制。每一阶段都允许停止或缩小范围，避免为了兑现早期承诺而跳过关键证据。

模型效果下降不一定来自模型。知识源过期、检索规则变化、业务政策更新、用户输入分布改变和工具接口异常都可能导致偏差。因此，运行看板要能把结果连接到完整系统，而非只显示模型成功率。

Demo仍然有不可替代的作用

Demo适合打开想象、对齐问题并快速排除技术不可行。真正的问题是把它承担不了的证据也压给Demo。管理层可以允许演示大胆，却应在对外承诺自动化比例、预算收益和推广时间前，明确哪些结论尚待Pilot和生产验证。

生产上线前做一次桌面事故演练

团队可以选择三个情境：模型输出明显错误但表达可信、工具调用部分成功后中断、权限配置让Agent访问了不应接触的数据。让业务、平台、风险和一线使用者按现有机制处理，观察谁先发现、谁有权暂停、日志能否还原、客户如何被告知、多久恢复。

演练的价值在于暴露接口，而非证明团队能救火。如果所有决定都依赖项目发起人，说明正式Owner尚未接手；如果日志只能看到最终答案，无法追踪Context和工具动作，说明可观察性不足；如果错误发生后大家先讨论责任归属，说明升级协议不清。问题进入上线清单，并由相应Owner关闭。

生产资格也需要退役条件

场景上线后不应默认永久运行。当业务规则变化、模型成本失去优势、人工接管长期过高、评估资产无人维护，或通用平台已提供更好方案时，应触发重新评审。生产能力包括安全退出，不能只包括安全进入。退役时保留必要日志、决策和高价值评估，把可复用组件转移，关闭权限与数据流，并向使用者说明替代流程。完整生命周期能够避免企业几年后积累大量无人负责的Agent和模型依赖。

管理层还可以要求项目在上线前提交一页“生产事实”：已覆盖与未覆盖的任务分布、当前人工接管、已知失败模式、权限范围、完整成本、事故Owner和下一次复核。它不追求把风险写完，而是防止演示叙事掩盖尚未证明的条件。随着证据变化，这一页持续更新，成为扩大范围的共同依据。

从观点到管理动作

一个项目真正获得生产资格时，管理层看到的应当是一组可重复的证据：在真实分布下达到可接受结果，异常不会无限传播，责任人能够解释并干预，运行成本仍符合价值假设。Demo提供方向，生产能力决定企业是否可以相信并扩大它。

延伸依据：NIST AI RMF Core：评估条件与生产监测、NIST Generative AI Profile、NIST AI Metrology Center