\n\n多数企业AI项目难以落地，并非技术无效，而是因为缺乏企业级的生产环境基础设施，且开发与运维环节严重脱节。解决之道在于构建从原型到生产的统一数据架构，并借助AI运维代理赋能数据库管理员，弥补人力短缺。
译自：Why most AI projects fail: It’s infrastructure and people
作者：Meredith Shubel
AI的唱衰者们热衷于抨击该技术无法产生显著的商业成果，并常引用诸如 MIT NANDA 的研究，该研究显示企业级 AI 解决方案的失败率高达 95%；或者引用 IDC 的报告，指出“在过去两年中，只有 9% 的 [欧洲、中东和非洲] 组织能够从其大多数 AI 相关项目中获得可衡量的业务成果。”
许多 AI 怀疑论者未能考虑到 AI 原型的实验性质；并非所有这些项目都旨在超越测试阶段。即便如此，5% 的成功率依然令人尴尬。
问题出在哪里？
原因有二。首先，大多数组织将 AI 原型建立在沙滩上；也就是说，他们构建早期应用所依托的数据基础设施无法支持后续向生产环境的迁移。同时，负责在生产环境中管理这些应用的运维团队，往往缺乏足够的人力来跟上工程部门日益增长的产出。
4 个原因：原型基础设施 ≠ 生产基础设施
当被问及为什么如此多的 AI 原型无法进入生产环境时，pgEdge 的联合创始人、首席产品官兼董事长 Phillip Merrick 告诉 The New Stack，数据基础设施很大程度上难辞其咎。
具体来说，他解释说原型环境无法满足大型企业对生产环境的要求，并指出了它们表现不佳的四个主要方面。
首先，Merrick 表示，原型环境缺乏组织从原型迁移到生产所需的部署灵活性。
他承认，供应商管理的云平台对于原型设计来说似乎是一个显而易见的选择，因为它们允许团队快速启动和运行。然而，他警告说，这些平台缺乏支持生产环境 AI 应用的技术能力，尤其是在安全性、合规性和治理方面。特别是对于医疗保健、金融或其他受监管行业的组织，供应商管理的云平台通常缺乏在自管云或本地环境中常见的严格控制措施。
“你必须能够选择最终将该 AI 原型置于何处进行生产。”
Merrick 断言，通过这种方式，灵活性和安全性是相辅相成的。“你必须能够选择最终将该 AI 原型置于何处进行生产。”
同样，当需要转向生产环境时，Merrick 表示，供应商管理的云平台可能会在企业和区域层面带来数据主权挑战。
“你的数据层显然是强制执行此操作的地方，”Merrick 指出。但他表示，大多数团队用于原型设计的环境模糊了界限：“如果它位于不知道哪个云、哪个区域的供应商管理平台上，那么你就失去了数据主权。”
最后，Merrick 提请人们关注可靠性，他解释说，如果没有高可用性的保证，AI 原型就无法进入生产环境。例如，当需要升级数据库或更换硬件时，是否可以在不造成停机的情况下完成？
“在供应商管理的云世界中，答案几乎总是否定的，”Merrick 说道，并重申了他的观点，即 将 AI 应用从原型迁移到生产需要企业级基础设施。
那么，为什么开发人员要在无法实现生产化的地方进行原型设计？
如果数据基础设施的选择是阻碍开发人员将 AI 原型推向生产的原因，那么为什么他们总是以错误的方式开始呢？
正如 Merrick 所解释的那样，许多人被供应商管理云平台的易用性所吸引。“这些原型环境确实让入门变得非常容易，”他说。但原型设计的捷径似乎在长期来看并不能带来回报，因为最终总有人要负责使这些原型具备生产就绪能力。
尽管如此，Merrick 并不责怪开发人员寻求简单的方法。相反，他说原型设计的“游乐场”和生产的“战场”之间存在脱节，这使得开发人员无法理解将来将原型生产化需要付出什么。
他说，多年前，工具决策主要是自上而下制定的，没有开发人员的投入：“然后，从 15-20 年前开始，开发人员非常正确地赢回了选择自己工具的权力。”
Merrick 声称，现在的问题是，开发人员完全为了原型环境而做出工具决策，而没有预见到生产需求。内部部门的划分意味着开发人员通常只负责构建原型，然后将接力棒传递给一个完全独立的运维团队进行生产：
“结果就是，在某些组织中，你真的没有一种贯穿始终的理解，即从最初开发人员做出选择开始，一直到最终生产环境的需求是什么。”
对 Merrick 而言，这种脱节正是 AI 项目开始分崩离析的地方，因为团队被迫试图将 AI 原型从可访问但不足够的供应商管理云平台，迁移到满足部署灵活性、安全性、数据主权和高可用性要求的企业级数据基础设施。
“但如果你做出了正确的数据基础设施选择，你就不会有这种脱节，”他说，“因为你将拥有从原型到生产的这条贯穿线。”
他称 Postgres 为 最能帮助开发人员弥合这一鸿沟的数据基础设施，称其为“数据库中的瑞士军刀”，因为它具有可扩展性、完全开源的特性，以及解决从非结构化数据、向量嵌入到地理空间数据等多样化数据管理问题的能力。
Merrick 指出，Postgres 运行的地点和方式也很重要，他再次提请注意许多供应商管理云环境的局限性，这些环境通常缺乏满足数据要求的治理控制和/或转向合规本地环境或自带云 (BYO cloud) 环境的部署灵活性。
但选择正确的数据基础设施只能解决一半的问题
Merrick 表示，等式中还有另一个大多数组织都在忽视的部分：人，或者更准确地说是数据库管理员 (DBA) 及其日益增长的工作负载。
根据 Stack Overflow 的 2025 年开发者调查，84% 的受访者使用 AI 工具，高于前一年的 76%。同时，Supabase 表示 其平台上有超过 60% 的数据库是“由某种 AI 工具”启动的。正如 Merrick 指出的那样，这种生产力的爆发带来了一个陷阱：没有足够的 DBA 来跟上进度。
“你的开发人员生产力实现了巨大的飞跃，”他解释说。“但你必须在生产端以某种方式管理它；这些数据库不能无人监控。” 他说，在代理工程 (agentic engineering) 增加更多数据库之前，运维和管理团队已经在努力追踪现有的 Postgres 数据库了：“谁来管理它们？”
他说，是时候让代理运维 (agentic operations) 跟上代理工程的步伐了。
AI DBA 代理可以赋予人类“超能力”
如果 Merrick 看起来是在建议组织寻找完全自主的 DBA 代理来接管工作，他表示行业还没有达到那个阶段：
“世界还没有准备好迎接由 AI DBA 代理管理的完全自主数据库。但存在巨大的资源短缺和生产力问题，DBA 只能管理有限数量的数据库，”他解释说。同时，新的“AI 应用需要更多的数据库投入生产。”
“世界还没有准备好迎接由 AI DBA 代理管理的完全自主数据库。”
那么，组织如何提高其运维能力？
Merrick 表示，DBA 应该关注新的 AI DBA 代理，不是为了让它们接管工作，而是为了赋予他们“超能力”，以更少的手动苦力去监控和管理更多的数据库。
pgEdge 的 Ellie 就是一个例子。作为 pgEdge AI DBA Workbench 的一部分，Ellie 是一个拥有 21 个 MCP 工具的 AI 代理，可以运行 EXPLAIN ANALYZE、检查模式、查询历史指标并完成多步诊断工作流程。当数据库出现故障时，Ellie 会发现问题、进行诊断，并以可执行 SQL 代码的形式提供解决方案，供人类 DBA 审查。“当你审查过并同意这是正确的行动方案时，你只需按下播放按钮，代理就会将该 SQL 代码执行到数据库中，你就解决了问题，”Merrick 解释道。
通过这种方式，Ellie 应该为运维团队带来更多的能力，Merrick 坚持认为组织目前正极其缺乏 DBA 专业知识。就他的观点而言，一些 行业预测 称，41% 的当今数据库专业人员打算在未来十年内离开该行业，其中一半选择退休，其余寻求其他工作。
“一个代理……实际上可以比人类更迅速、更高效地响应这些警报。”
Merrick 认为，如果没有 AI 代理，DBA 的工作将是枯燥、费力且耗时的。正如他解释的那样，一个数据库可能一直运行良好，但当出现问题时，麻烦可能会在多个应用中体现出来；这就需要 DBA 去梳理监控数据来观察和诊断问题，本质上是在大海捞针。
“一个代理，”他说，“实际上可以比人类更迅速、更高效地响应这些警报。”
更好的基础设施 AND 人：AI 原型成功率的提升缺一不可
在几乎任何背景下，AI 都会引发关于质量优于数量的问题，企业 AI 项目也不例外。代理工程意味着开发人员现在可以生产更多产品，但所有这些原型并不能直接飞入生产环境。基础设施和运维人力两方面的限制正在制造障碍，导致许多 AI 原型失败。
对于 Merrick 而言，缓解从原型到生产的过渡，不仅需要出色的 AI 工具，还需要生产就绪的数据基础设施，并辅以能够跟上代理工程繁荣发展的代理运维。全 工智能
