Demo证明的是Agent能完成一次任务；企业验收的是，它能否在权限、异常和旧系统的约束下，稳定、可控、可追责地完成一万次。
如果只看演示，企业AI Agent似乎已经无所不能。
一句话，它能查资料、分析表格、生成文档、调用系统、发送邮件，甚至自动规划出一整套流程。
会议室里，所有人都很兴奋。
可一进入生产现场，画风就变了。
ERP没有完整接口，库存系统只能导Excel；员工权限各不相同；一笔订单取消必须经过两级审批；网页弹窗一变，自动操作就失效；客户突然发来阿拉伯语材料，界面还要从右向左显示。
Demo里被隐藏的问题，开始排队出现。
于是很多团队得出一个错误结论：是不是模型还不够强？
其实不是。
Demo测试的是"Agent会不会做"；企业生产测试的是"这家公司敢不敢让它做"。
前者是一项AI能力，后者是一套企业系统工程。
01 Demo和生产，考的根本不是同一张试卷
Demo的目标是证明可能性。
它可以选择最干净的数据、最顺畅的流程、最稳定的接口和最配合的用户。失败了重来一次，不会有人损失订单，也不会触发审计。
生产环境的目标却是证明可持续性。
它必须面对脏数据、网络波动、接口超时、员工误操作、权限差异、规则变化和大量从未见过的例外。
一个Agent成功生成一封邮件，不难。
难的是它连续生成一万封邮件时，不能把A客户的报价发给B客户；遇到资料不全要停下；涉及敏感内容要申请审批；发送后要留下记录；出错后还要知道谁能撤回。
所以从Demo到交付，中间至少存在一道数量级变化：
从"偶尔成功"变成"可预期地成功"；从"结果看起来对"变成"过程能够解释"；从"它可以执行"变成"企业允许它执行"。
02 第一座桥：把"我要智能化"翻译成可验收流程
企业客户提出的Agent需求，通常不是需求，而是愿望：
- 能不能接ERP？
- 能不能自动处理仓储物流？
- 能不能帮我们审批、报价、客服？
- 能不能让员工少做一些系统操作？
"接ERP"听起来只有三个字，实际可能代表完全不同的七件事：查询订单、读取库存、生成报表、判断风险、修改状态、触发审批、联动仓储和消息通知。
复杂度和风险差异巨大。
如果没有拆清楚，技术团队可能交付一个问答助手，客户期待的却是让AI参与业务流转。双方都觉得对方变了需求。
一个可以进入开发的Agent场景，必须回答：
- Agent只读数据，还是能够写入？
- 它提供建议，还是直接执行动作？
- 哪些节点必须人工确认？
- 能读取哪些字段，不能触碰哪些数据？
- 执行失败能否重试、撤销或回滚？
- 全流程由谁维护、谁验收、谁承担责任？
企业Agent的第一项工程，不是写提示词，而是把业务语言翻译成流程语言。
03 第二座桥：企业不是没有系统，而是系统太多、太散、太旧
很多人以为企业上Agent，是为了补一套新系统。
现实恰恰相反：企业往往已经有ERP、仓储、物流、财务、审批、电商、即时通信、监控和行业系统。
问题是它们来自不同年代和供应商。
有的接口完整，有的只能查询不能写入；有的靠文件交换，有的只剩网页可以操作；同一个客户、商品或订单，在不同系统里还可能使用不同编码。
Agent真正适合的位置，不是替换所有旧系统，而是在它们上方增加一层受控的协同能力：
- 从多个系统读取状态；
- 依据业务规则作出判断；
- 调用合适工具生成或执行动作；
- 在关键节点请求人工审批；
- 把结果写回原系统并通知相关人员；
- 留下可追踪的过程记录。
这已经不是"聊天机器人"，而是跨系统流程协调员。
也意味着一个可交付平台不能只有模型调用，还要具备流程编排、权限控制、人工确认、异常处理和日志审计。
04 第三座桥：接入方式不是技术宗教，而是风险选择
系统集成最常见的争论是：应该调用API，还是使用浏览器自动化？
答案不是二选一。
接口稳定、长期高频的流程，适合API；需要实时事件触发，可以使用Webhook；数据结构清晰但没有接口，可能通过文件或受控数据同步；老系统没有接口但网页可操作，可以用浏览器自动化进行验证或过渡。
但每种方式都有边界。
浏览器自动化能快速跨过老系统障碍，却容易受页面变化、弹窗、登录状态和网络环境影响。它适合早期验证，不应被包装成无需维护的永久方案。
数据库或文件同步能解决读取问题，也不等于可以绕过系统权限直接修改生产事实。
API适合稳定运行，但接口开发、鉴权、测试和供应商协调都需要成本。
正确的接入方式，不是最先进的方式，而是在当前阶段兼顾速度、稳定、风险和成本的方式。
05 第四座桥：权限和审批，比"更自动"更重要
Demo之所以流畅，是因为演示环境里通常没有真实权限。
生产环境必须回答：谁允许Agent读取客户资料？谁允许它修改订单？它能否代表公司向客户发送消息？付款、取消订单、调整库存时，谁来批准？
企业不会因为Agent很聪明，就把生产系统的钥匙全部交给它。
更稳妥的方式，是让权限逐级开放。
第一级：只读查询
Agent帮助员工查找订单、库存、制度或客户信息，回答附带来源，不修改任何系统。
第二级：生成建议
Agent生成报价草稿、调拨建议、回复建议或待办计划，由员工确认。
第三级：低风险执行
对规则清晰、可撤销的动作自动执行，同时使用幂等机制防止重复操作，并回读结果确认成功。
第四级：高风险审批
付款、合同、库存调整、订单取消等动作必须进入审批流，批准后再执行，全程留痕。
第五级：固化系统集成
经过长期验证的流程再建设稳定接口，加入监控、告警、回滚和持续评测。
企业Agent成熟的标志，不是人完全退出，而是人只出现在需要判断、授权和负责的地方。
06 第五座桥：异常不是边角问题，而是系统主体
Demo按"正常路径"设计，生产系统却常常活在例外里。
订单缺字段怎么办？客户名称匹配到两个结果怎么办？库存刚刚被另一笔订单占用怎么办？Agent调用接口超时，但系统其实已经执行成功怎么办？审批人休假怎么办？
如果这些问题没有设计，自动化越深，事故传播得越快。
生产级Agent至少要有六项异常能力：
- 发现资料不足时明确拒绝继续；
- 区分可重试错误和必须人工处理的错误；
- 防止同一动作被重复执行；
- 执行后回读系统状态，不把"已发送请求"当成"业务已完成"；
- 记录使用了什么数据、调用了什么工具、在哪一步失败；
- 允许人工暂停、接管、修正和回滚。
模型的聪明决定上限，异常处理决定系统能否活过第一个月。
07 第六座桥：部署模式不是偏好，而是商业现实
企业经常问："数据能不能不出内网？"
这不是保守，而是数据责任。
低敏感、轻量场景可以使用在线服务快速验证；敏感资料和核心系统可能要求本地或离线部署；很多企业适合混合方案——核心数据留在本地，非敏感能力按规则调用云端。
选择部署方式要看四件事：
- 数据是否允许离开当前环境；
- 业务是否要求断网可用或稳定低延迟；
- 企业是否具备本地运维能力；
- 调用规模是否足以支撑长期自建成本。
本地部署不等于天然安全。账号、权限、补丁、日志、备份和模型更新没人负责，本地机房同样会产生风险。
08 海外落地，绝不是把中文翻译成另一种语言
当Agent进入沙特、中东等海外市场，多语言只是第一层。
真正的本地化至少包含：语言表达与行业术语、从右向左的界面排版、本地即时通信和内容平台、当地数据合规、现场交付团队，以及各行业不同的审批与责任习惯。
一个中文界面翻译成阿拉伯语，不代表流程已经适合当地员工；接入海外通信工具，也不代表消息发送权限和客户同意机制已经解决。
海外项目更依赖"本地交付 + 平台支持"的协作方式。
本地团队负责客户关系、需求调研、现场适配和持续服务；技术平台提供工作流、系统连接、部署能力和升级支持。
企业Agent不是卖完账号就结束，它需要长期驻留在客户的组织和流程中。
09 上线前，不要只验收答案，要验收整条轨迹
很多项目验收只看最终答案是否正确。
但Agent会调用工具、跨系统执行动作，只看答案远远不够。
生产验收至少要覆盖：
- 正确路径： 正常输入能否完成全流程？
- 无答案场景： 资料不足时是否拒答而不是编造？
- 未知类型： 遇到没见过的文件或业务状态是否转人工？
- 过期数据： 能否识别资料版本和数据时间？
- 越权请求： 无权限用户是否无法读取或执行？
- 重复执行： 网络重试会不会创建两张订单？
- 部分失败： 前三步成功、第四步失败后如何恢复？
- 长期漂移： 模型、规则、系统页面变化后谁发现？
真正需要验收的不是Agent说了什么，而是它为什么这么说、做了什么、出了错如何收场。
写在最后
企业Agent的定位，不是一个更会聊天的窗口，也不是一名拥有无限权限的数字员工。
它应该是业务流程里一个可靠、受控、可审计的执行节点。
从Demo到生产，必须跨过需求翻译、系统接入、权限审批、异常运维、部署与本地化这些桥梁。
少任何一座，演示都可能很漂亮，交付却很脆弱。
所以下一次看到惊艳Demo，不妨先别问模型是什么，也别急着问多久上线。
先问五个问题：
它接哪些系统？读写哪些数据？触发哪些动作？谁负责审批？失败以后如何恢复？
如果这五个问题没有答案，你看到的仍然只是一次成功表演，而不是一套可以进入企业生产的系统。
能跑一次，是能力。能稳定跑一万次，才叫交付。