别再迷信模型参数了，企业级 AI Agent 落地最核心的瓶颈其实是数据基建

最近在部署企业级 AI Agent 时，我发现一个很有意思的现象：很多团队在追求 GPT-4o 或 Claude 3.5 这种顶尖模型的推理能力，试图通过精调 Prompt 来解决业务问题，但结果往往不尽如人意。其实在真实的商业环境下，Agent 能不能跑通，决定性因素根本不是模型强不强，而是你的数据基建是否足够“就绪”。

很多公司把 Agent 当成高级版的 RAG（检索增强生成）来对待，认为只要能把文档喂给模型，它就能处理业务。但从“问答机器人”转向真正的“执行代理”时，对数据的要求发生了质变。举个最简单的例子，如果你让 Agent 处理一个供应链订单的变更，它不仅需要读取 PDF 合同（非结构化数据），还需要实时调用 ERP 系统的库存 API（结构化数据），并且必须理解当前订单状态在业务流程中处于哪个节点。

如果一个 Agent 只能访问到公司 30% 的碎片化数据，那么它给出的决策大概率是错误的，甚至在执行阶段会直接触发系统报错。我参考过一组关于企业数据就绪度的调研，结果非常扎心：绝大多数公司的 AI Agent 实际能触达的内部数据还不到 50%。而那些所谓的“数据领先者”，其数据可访问率能达到 70% 以上。这 20% 的差距，直接导致了用户信任感的断层——在数据基建糟糕的公司，只有约 50% 的员工敢相信 Agent 的决策；而在基建完善的公司，这个信任度几乎接近 100%。

这意味着，如果你的数据底座依然是那种互不相通的“烟囱式”结构，哪怕你换上最强的模型，Agent 也只能在沙盒里玩玩，无法进入真实的业务流。很多公司前几年刚升级的数字化系统，在 Agent 面前依然是“老古董”，因为它们缺乏实时、全量且带有业务上下文的接口能力。

想要让 Agent 真正规模化实操，我认为目前的优先级应该重新排布，重点放在以下三个维度：

首先是消除结构化与非结构化数据的壁垒。真正的执行代理不能只在向量数据库里打转，它必须能够无缝地在 SQL 数据库（如 PostgreSQL 或 MySQL）和非结构化文档（如邮件、Wiki）之间跳转。如果 Agent 在处理任务时，无法将一个订单 ID 快速关联到对应的客户沟通记录上，那么它的执行结果就是缺失上下文的。

其次是注入业务上下文。实时数据如果缺乏 Context，在模型看来就是死数据。例如，一个订单状态显示为“待审核”，对于模型来说只是一个字符串，但对于业务而言，这可能意味着它处于风控拦截状态。如果 Agent 不理解这个业务逻辑，它在执行操作时就会出现严重的偏差。

最后是实现数据治理的自动化。依赖人工手动清洗数据的速度，根本跟不上 Agent 迭代的需求。在实际部署中，如果数据同步延迟超过 15 分钟，Agent 可能会基于过时的数据做出错误决策，导致严重的业务事故。因此，必须建立一套自动化的数据清洗和治理管线。

总结来说，AI Agent 的能力上限由模型决定，但它的执行下限是由数据基建决定的。不要在模型选择上浪费太多时间，先去检查你的数据链路是否打通，否则再强的模型也只是一个“空有智商但没有权限”的助理。