一个 Demo 和一个系统之间,隔着四道工程鸿沟

现在,用一个通用智能体平台搭出一个像样的 AI demo,可能只要一个下午。也正因为如此,几乎每家公司都不缺 demo——缺的是能天天用、用得住的系统。公开讨论中反复出现的数字令人警醒:大量企业 AI 项目卡在了从 POC(概念验证)到生产的"最后一公里",演示时惊艳、上线后失灵。一个 demo 和一个系统之间,到底隔着什么?我们的答案是四道工程鸿沟:数据要治理、数据要分发、智能体之间要协同、输出要有一致性和确定性。这四道坎,每一道都不是"模型更聪明一点"能解决的,而是要靠扎实的工程能力去填。这也是为什么,靠通用平台把 demo 拼装起来、中间靠人搬运数据的做法走不远——你需要的是一个 all in one 的行业智能体平台,让所有环节在高度自动化下运转。

Demo 证明的是"技术上可能",系统要回答的是"业务上可靠"。

一、为什么 demo 那么容易,系统那么难?

因为 demo 和系统要满足的条件,根本不是同一种东西。

一个 demo 要成立,只需要:挑选过的输入、理想的环境、跑通一次。演示的人可以选那条最漂亮的数据、避开所有边界情况,只要台上的三分钟顺利,demo 就成功了。

一个系统要成立,需要的是:任意的真实输入、复杂的真实环境、每天成千上万次地跑,而且每一次都要对。真实世界的数据是脏的、缺的、格式各异的;真实的用户不会按演示脚本提问;真实的业务出了错是要有人负责的。

这个差距,业界看得越来越清楚。公开讨论中,"多数企业 AI 项目死在 POC 阶段"已经成为共识级的观察;工程社区总结的原因高度一致:POC 阶段的数据是被人为筛选和优化过的,而生产环境里的数据不是;demo 只需要验证"技术上可能",而生产要求"规模上可靠"。换句话说,demo 的成功几乎不构成对系统成功的任何承诺。

我们在物业与设施管理行业看到的情况完全一致。用通用平台给一个巡检场景搭 demo,半天就能让它"看起来能用";但要让它接住一个真实项目每天几百条巡检记录、对接十年前的老系统、出的报告能直接给甲方看——那是另一个量级的事。中间隔着的,是四道具体的工程鸿沟。

二、第一道鸿沟:数据要治理

Demo 用的是干净数据,系统要面对的是真实数据——而真实数据,几乎总是没法直接用的。

在物业行业,这个问题尤其典型:巡检记录是纸质单据或微信群里的照片,设备台账在 Excel 里且三年没更新,工单散在几个互不相通的系统里,同一个设备在不同表里有三个名字。这样的数据直接喂给智能体,出来的只能是垃圾——垃圾进,垃圾出,再强的模型也改变不了这条定律。

所以从 demo 到系统的第一步,永远是数据治理:把散落各处的数据收上来、洗干净、对齐口径、建立结构。这一步没有捷径,也没有多少"智能"可言,纯粹是工程的苦活——但它决定了后面一切的上限。(数据治理为什么是 FDE 工作里最重的一段,我们在《什么是 FDE》里展开过。)

三、第二道鸿沟:数据要分发

治理好的数据,还要能在正确的时间、以正确的形态,流到正确的智能体手里——这是 demo 里根本不存在的问题。

Demo 里的数据是演示者手动喂进去的。系统里没有这个"手动"的人:巡检数据产生后,要自动流向负责分析的智能体;分析结果要自动流向生成报告的智能体;异常要自动触发工单流程。数据在整条链路上的流转、订阅、权限、时效,都需要工程化的管道。

这正是"靠人搬运"模式的死穴。如果你的智能体是散落在几个通用平台上的 demo 拼装,那么每一个拼缝处都需要人:把 A 的输出导出来、整理一下、粘贴给 B。人肉搬运不仅慢,而且每一次搬运都是一个出错点、一个延迟点、一个责任模糊点。搬运的人一休假,整条"智能"流程就停摆——这样的自动化,名不副实。

四、第三道鸿沟:智能体要协同(A2A)

真实的业务流程几乎从不是单个智能体能覆盖的,而是多个智能体接力与协作的结果——agent 到 agent(A2A)的协同,是系统区别于 demo 的又一道坎。

以一份月度运营报告为例:一个智能体汇总工单数据,一个智能体分析设备状态,一个智能体核对费用,最后一个智能体把三者的结果整合成给管理层的报告。这条链上,任何一环的输出格式、口径、时序错了,下一环就接不住。

让多个智能体可靠地协同,需要的是统一的调度、统一的数据契约、统一的异常处理——这些能力只能长在平台层,不可能靠把几个孤立的 demo "拼"在一起获得。单个智能体聪明不聪明是模型问题,一群智能体能不能把一件事接力做完,是工程问题。业界的共识也在向这里收敛:让一个 agent 跑起来是 demo,让一群 agent 可靠地、可管理地为企业服务,才是生产。

五、最重要的一道:一致性和确定性

四道鸿沟里,最不显眼、也最致命的是这一道:B 端的行业应用,对输出的一致性和确定性有着近乎苛刻的要求——而这恰恰是大模型天生的短板。

大模型的输出本质上带有随机性,同一个问题问两次,答案可能不同。这在 C 端的聊天场景里无伤大雅,甚至是"创造力"的来源;但在 B 端的业务场景里,它是不可接受的。

算一笔工资、出一份账单,第一次和第二次的结果必须一样——这是业务的底线,不是技术的选项。

想一想这些场景:算一笔工资、做一个账单,第一次算和第二次算的结果不一样——财务敢用吗?给领导的周报,格式定下来之后,这一周和上一周长得不一样——管理层还会信任它吗?对甲方的月度考核数据,重跑一次数字就变了——合同还怎么结算?在 B 端,不一致就等于不可信,不可信就等于不可用。

要在天生带随机性的模型之上,构建出输出一致、结果确定的业务系统,需要投入大量的工程能力:该走规则的环节就不走模型(计算、汇总用确定性代码,而不是让模型"心算");该约束的输出就严格约束(固定模板、锁定口径与版本);该校验的结果就层层校验(关键数字复核、异常拦截)。工程社区把这类做法总结为"确定性与非确定性能力的分层"——模型负责理解和生成,规则负责计算和把关。这套分层架构,是每一个严肃的 B 端 AI 系统都绕不开的,也是任何通用平台上搭的 demo 都不会替你做的。

六、结论:这就是为什么需要 all in one

把四道鸿沟放在一起看,结论自然浮现:如果你的"智能化"是靠一堆通用平台上的 demo 拼装、中间靠人搬运衔接,那大智能体的意义就没有了——你既没有省下人,也没有获得可靠性。

数据治理、数据分发、智能体协同、一致性与确定性——这四种能力有一个共同点:它们都只能长在平台层,而不是单个智能体身上。这就是我们说的 all in one:模型 all in one(统一调度)、软件 all in one(业务操作在平台内完成)、数据 all in one(治理与流转在平台内闭环)、技能 all in one(行业能力内置为积木)。只有所有环节都在一个底座上,整条业务流程才能在高度自动化下,同时获得高的一致性和确定性——这是行业级智能体平台和通用平台的分水岭,也值得我们下次专门写一篇细讲。

所以,回到开头的问题。一个 demo 和一个系统之间隔着什么?隔着数据治理的苦活、数据分发的管道、智能体协同的调度、一致性与确定性的工程分层——一言以蔽之,隔着一整套平台级的工程能力。Demo 帮你看清"值不值得做",这一步很重要,我们甚至专门做了 Demo Day 来帮企业完成它;但看清之后,请对下一步的分量有清醒的预期:把 demo 做成系统,是一段真正的工程,需要专业的人用专业的方法去走。(这段路怎么走、按什么节奏交付,见我们的 FDE 服务。)