十年前建了一堆"信息烟囱"，花了五年补课。今天如果 Agent 一个个单独上，这个弯路会再走一遍——而且这次的坑更深。

老故事，新角色

做过企业信息化的人，对下面这个画面不会陌生：ERP 管财务和供应链，CRM 管销售，MES 管车间，OA 管审批——每个系统各干各的，跑起来都挺顺，但一旦跨系统拉数据就要命。同一个订单号，三个系统三种格式；生产排程想拿到销售预测，得先导 Excel，再手工导入。

后来企业花了三五年建数据中台，本质上就是给当年"先上应用、不管打通"的决策补课。

今天，AI Agent 正在重演同样的剧本。

各部门各搞各的：法务上了一个合同审核 Agent，客服部署了一个售后知识库问答 Agent，采购做了一个供应商情报 Agent，人事又搞了一个制度问答 Copilot……每个项目单独汇报都能讲出价值，但放到一起看，老问题全回来了。

不过如果仔细看，这次比十年前更麻烦。数字化时代的孤岛只是"业务数据不通"，Agent 时代的坑有三层。

比"打通"复杂得多的三层挑战

想想看：合同审核 Agent 要读合同文本（非结构化），但也得查客户的历史回款记录（结构化）和之前的合同条款审批意见（Agent 自己产出的数据）。三种数据，来自三个不同的地方。这还只是一个 Agent。

问题是，当你有五个、十个 Agent 同时在跑的时候，每个 Agent 都在跟多种结构化和非结构化数据源做交叉调用。这些调用关系不是一条直线，而是一张网。结构化数据好歹在上一代数据平台里有迹可循——表在哪、字段什么含义、谁有权限访问，多少有点底子。但非结构化数据从来没有被统一管理过，哪些合同在哪个目录、哪些图纸是最新版本、邮件附件散落在谁的收件箱里——这些东西一旦开始被 Agent 网状调用，链路多做几个就几乎无法再理清。不是"复杂度提高了"，是直接失控了。

不建数据底座，Agent 会掉进哪些坑

我们过去两年在几十个客户现场做 Agent 落地，踩过或见过的坑，归纳起来就这六个：

底座与智能，同步建设

说到数据平台和业务应用的关系，过去十年的数据中台建设其实留下过两种典型的走弯路姿势，今天在 Agent 领域又开始出现了：

第一种是 IT 思维主导的"先修路再通车"。 觉得必须先把数据平台建得大而全——主数据治理做完、数据质量全部清洗干净、指标体系搭建完毕——然后再让业务来用。听起来很严谨，但实操中这种项目经常建了两年还在"治理"，业务那边早就等不及自己搞了。结果平台建完了，业务已经在各种零散工具上跑了一堆流程，回头再迁移成本比从头建还高。

第二种是业务思维主导的"先跑起来再说"。 完全不考虑数据平台，哪个部门需要就给哪个部门上一个 Agent，数据接入各搞各的。前三个场景确实快——但到第四个、第五个的时候，问题就全暴露了：数据口径不一致、权限管不住、Agent 之间经验不共享。越往后坑越多，越建越慢。

这两种思维背后其实是同一个错误假设：认为底座建设和业务建设是分开的两件事，要么先做完一个再做另一个，要么干脆只做一个。

我们的经验是：底座和智能必须同步建设。 尤其是对于数据基础本身不是很理想的企业来说，正确的做法是——挑一个高价值的 Pilot Agent 场景先跑起来，在这个过程中把数据底座建设起来。Agent 跑通了，业务价值闭环了，数据管道和权限策略也就跟着闭环了。然后第二个场景接进来的时候，底座上已经有了可复用的能力，速度自然就快了。不是先建完路再通车，也不是在荒地上硬跑——是边修路边通车，路和车一起长出来。

2024 年初，我们就在客户现场观察到了 Agent 烟囱化的苗头，也因此做了一个产品决策：推出 MatrixOne Intelligence（MOI）——不是另一个独立的 Agent 工具，而是一个以数据平台为底座的 AI 数据智能平台。它把 Agent 运行时需要的能力和底层的数据存储、集成、加工整合在一起，让团队从第一个场景起就能同时积累业务价值和数据资产。

注意这张图的层级关系：业务场景在最上面，下面整个是 MOI。MOI 内部分三层：

Agent 运行时层

NL2SQL、RAG 检索、记忆管理、运行分析——这些是所有 Agent 都需要的公共能力，建一次就够了。新场景接进来不用重复搭建，直接调用。

数据集成与加工层

各种业务系统的数据通过 ETL/CDC 接入，文档通过 Embedding 向量化，结构化指标通过语义层构建变得可被自然语言查询。Agent 产出的运行日志也在这一层统一归集。数据只加工一次，所有 Agent 共享。

数据存储与管理层（MatrixOne）

最底下是 MatrixOne 云原生数据库，同时支持 HTAP 事务分析混合、向量检索、全文搜索。结构化数据和非结构化数据在一个引擎里管理，Agent 运行日志也存在这里。权限管控在这一层统一实现——行级、列级的数据权限和操作审计都在数据引擎层面定义，而不是让上面的每个 Agent 各管各的。十个 Agent 共用一套安全策略，而不是十套。

核心设计原则：Agent 上面的场景可以多种多样，但下面的数据底座是同一个。数据只接入一次、权限在数据层统一定义、记忆统一存储——无论将来加多少个 Agent，边际成本是递减的。

对比：两条路的差距有多大

落地验证：不同行业的实战样本

这套架构不是画在 PPT 上的概念图。从 2024 年开始，我们在多个行业的 AI Agent 项目中验证了这套"底座+智能"同步建设的路径。下面几个案例各有侧重，但共同点只有一个：数据平台是 Agent 真正跑起来的前提，不是锦上添花。

共同结论：在已落地的项目中，第二个 Agent 场景的上线时间普遍比第一个缩短 60% 以上——因为数据管道、权限策略、记忆框架和日志归集都是复用的。底座建得越早，后面的场景跑得越快。

五条踩过坑之后总结出来的经验

底座和 Agent 要同步起步，别走两个极端

别花两年建"完美的数据底座"再做 Agent——那是 IT 思维的老路，业务等不起。也别完全不管底座，每个部门各搞一个 Agent 先跑起来——那前几个快，后面会越来越慢。正确的节奏是：从第一个 Pilot 场景起就跑在可扩展的底座上，通过业务闭环带动数据闭环。

一个引擎管结构化和非结构化，不要拼凑

Agent 天然就要同时用这两种数据。如果结构化用一个库、文档用另一个库、向量再加一个库——那数据平台本身就变成了新的烟囱。选一个原生支持 HTAP + 向量检索 + 全文搜索的引擎，少走很多弯路。

Agent 产出的数据从第一天就要归集

对话记录、推理链条、决策日志、用户打分——这些数据是 Agent 进化的燃料。别等到上线半年后才想起来"好像应该分析一下效果"。从第一天起就让这些数据回流到统一平台，后面做效果评估和策略优化才有数据可用。

权限在数据层定义，不在 Agent 层各管各

Agent 越多，权限治理越重要。在底座层面统一做行级、列级的权限控制和操作审计，Agent 拿到的就是已经脱敏/过滤后的合规数据。十个 Agent 用同一套安全策略，而不是十套。这不是可选项，是合规底线。

先挑一个场景跑通，再横向复制

别想着一次性建一个"全能 Agent 平台"。选一个数据质量好、业务价值看得见的场景（比如售后知识库问答、合同条款审核），端到端跑通之后，第二个场景就快了——管道能复用、权限能复用、记忆框架也能复用。

写在最后

Agent 的价值没人怀疑，但价值能不能兑现，说到底还是看基础设施。

十年前那一轮数字化的教训其实很简单：应用好建，底座难补。今天的 Agent 时代，问题更多了一层——Agent 不光消费数据，还在不停产生数据；需要的数据不光是结构化的表和指标，还有合同、图纸、文档这些非结构化内容。三个维度叠在一起，没有底座的 Agent 只会越建越乱。

好消息是，这一次我们可以从第一个场景开始就把底座建对。不用等、不用补课——底座和智能一起长，才是正解。