企业级 AI 平台,到底该具备哪些能力?(一份给甲方的选型参考)

一家企业今天要选一个"企业级 AI 平台"，到底该看什么？

这个问题听起来不难，真到了要拍板的时候却很容易发懵。因为现在叫"平台"的东西太多了：有的其实是一个搭 Agent 的工具，有的是一台装好了模型的私有化一体机，有的是个套了壳的问答框，还有的是把几条 Workflow 拖出来的配置器。名字都叫平台，能力边界差得很远。

过去一两年，我跟不少 CIO、CTO、数字化负责人会聊到这个话题。一个共性的体感是：在 Demo 阶段很容易被打动，等真的把场景铺到几十上百个，才发现当初买的这套东西，差了一整套底座。Agent 是搭出来了，但谁在用、用了多少、花了多少、出了事找谁，全都说不清。

我自己也做 AI 产品，每天面对的就是"企业到底需要一个什么样的平台"这个问题。这篇文章想把两件事摆出来：一个真正的企业级 AI 平台，应该具备哪些关键能力；以及站在甲方的角度，选型时又该特别注意什么。

先把背景的两个判断给清楚，因为后面所有的能力和选型，都建立在这两个判断之上。

第一个判断：方向是确定的，路径是难的。Gartner 在 2025 年 6 月的一份预测里说，到 2027 年底，超过 40% 的智能体（agentic AI）项目会被取消，主因是成本失控、业务价值不清、或者风险管控不到位。MIT 的 Project NANDA 在 2025 年的《The GenAI Divide》里给的数字更扎眼：企业在生成式 AI 上累计投了三四百亿美元，约 95% 的组织没有看到可衡量的损益回报，真正把试点做成业务成效的只有约 5%。两个数字放一起，说明一件事：要不要做 AI 已经不是问题，能不能选对平台、把它用下去，才是分水岭。

第二个判断：AI 已经从"创新试验款"变成了"经常性运营款"。a16z 在 2025 年调研了 100 位企业 CIO，发现创新预算在大模型支出里的占比，一年之内从约四分之一掉到了 7%，钱正在转进核心 IT 和业务部门的常规预算。这意味着，选 AI 平台不能再按"试点玩具"的标准，而要按"长期运营资产"的标准来选：治理、成本、可运维、可观测，这些过去被放在最后看的东西，现在得放到前面。

先分清楚：买的是一个工具，还是一个底座

这是选型之前最该想清楚的一层。

我在之前的文章里聊过一个判断：AI Agent 真正的门槛有两层，第一层是"做起来"，第二层是"用下去"。第一层被厂商和行业讲得很多，第二层几乎没人系统聊过。一个能跑的 Agent，POC 阶段一晚上就能搭出来，这种立等可取的体感，会让人以为 AI 软件是过去企业软件的廉价版。

但企业级 AI 的真实成本曲线，恰好是反过来的：构建成本，可能是过去十年企业软件里最低的；运营成本，可能是过去十年里最高的。做出来不贵，养下去才贵。Token 是常驻消耗，只要 Agent 在工作钱就在烧；工具和 Skill 跟着业务系统、底层接口、模型版本一起变，每一次变化都是一轮重写和回归；出错的修复债更隐蔽，软件 Bug 是"该做的没做对"、回滚就行，Agent 出错是"做了不该做的事"，发出去的邮件、改掉的主数据、删掉的客户档案，回滚解决不了。

所以"工具"和"底座"是两种东西。工具解决的是"做不做得出来"，底座解决的是"管不管得住、能不能持续产生价值"。一个只卖工具的方案，会把第二层的成本和风险，全部留给甲方自己在规模化之后慢慢消化。

把这一层想透，下面五个关键能力就不只是一张功能清单，更像一套"能让 AI 在企业里活下去"的底座。我把它们分成四块功能能力，加一层贯穿始终的治理底座。

关键能力一：业务自己建得起来，也真用得起来

第一块能力，落在"入口"和"构建"上。

很多 AI Agent 平台都说自己把门槛降下来了：不用写代码、拖拽搭建、可视化编排。但真用起来会发现，门槛只是从"写代码"换成了"搭 Workflow"。一个业务同事想做一个订单异常处理的 Agent，看着流程不复杂，真动手就卡住了：先判断订单状态、配条件分支，再去查库存、查物流、查支付，每个接口返回的数据结构都不一样，任何一步出错还要想清楚是重试、跳过还是通知谁。这不是"拖拽"能解决的，是系统设计思维的事。

结果就是，Agent 的建设又一次回到了"IT 交付为主、业务只能提需求"的老路。这和当年 BI、RPA、低代码早期推广时的局面几乎一模一样：真正搞得定的，还是少数会写代码的人。只要业务自己做不起来，建设速度就被 IT 排期锁死。

所以这一块能力的关键有两点，跟界面花不花哨关系不大。

一是把 Agent 当成一个可工程化的系统来构建，而不是一堆拖拽节点。一个 Agent 真正稳定好用，靠的是上下文怎么组织、工具怎么调用、技能怎么封装、复杂任务怎么交给子代理去拆。这套围绕模型的工程化骨架，业界一个有代表性的例子是 Claude Code 的架构。把这层工程能力沉淀进平台，业务同事配的是"意图和边界"，平台负责把它变成一个能真正干活的 Agent，这才是门槛真正往下降。

二是要有一个面向业务的统一入口，也就是一个让普通员工能直接用起来的 AI 工作台。Agent 搭得再好，如果业务同事不知道在哪用、怎么用，最后还是只停在 IT 手里。统一入口的价值，是让"业务自行构建、业务自己使用"这件事真的发生。

我自己有一个判断：这块能力做到位的标志，是业务能自己把 Agent 建起来，并且建出来的东西真有人用。搭建门槛真的降下来了，业务才接得住后面的事。

顺便说个场景。早期 Agent 试点绝大多数停在"知识库问答"，但问答天然只完成了"理解"这一半，没有"执行"，也没有"反馈"。业务流程里真正创造价值的动作，比如下单、审批、调度、通知，问答 Agent 都触达不到。一个好平台要支撑的，是能形成"理解—执行—反馈"闭环的场景，而不是又一个答得像模像样、却算不出账的问答框。

关键能力二：能力要沉淀成可复用的"原子能力"，而不是各自野生

第二块能力，落在"能力怎么沉淀"上。这一块最容易被忽略，却直接决定了前一块能不能稳定工作。

规模化之前，每个 Agent 在搭建时都要自己去连数据、调接口。最常见的做法是：业务同事找 IT 要一个数据库账号或者 API Key，直接写在 Agent 的配置里。Agent 是能用了，但企业对这条数据链路基本处于失控状态。采购部的 Agent 自己写一套对接 ERP 查库存的代码，销售部又写一套，财务进来再写第三套；某个员工调岗了，他当初建的 Agent 里用的账号可能还在访问数据；真要做一次权限盘点，只能一个一个 Agent 去翻配置。

这件事的根本（问题），是企业缺一层"AI 原子能力平台"。它把数据、接口、工具、技能统一封装、统一管控，Agent 开发者看到的是一份"可用能力清单"，而不是数据库账号和 API Key。安全、权限、版本管理在这一层全部收口。

我在聊 Workflow 和 Agentic 的时候说过：Agentic 编排的价值，恰恰建立在原子能力层的确定性之上。让模型负责决策，但不能让模型负责执行细节。一个会思考的大脑，得指挥一组可靠的手脚——手脚不靠谱，大脑再聪明，系统整体也靠不住。当下平台的竞争焦点几乎都在"编排能力"和"界面易用性"上，原子能力层的标准化、可复用、可治理反而是被忽略的角落。这恰恰是下一阶段能不能真正落地的关键差异。

好消息是，这一层正在长出行业标准。MCP（模型上下文协议）2024 年 11 月由 Anthropic 提出，本来是为了解决"每接一个数据源就要做一套定制实现"的碎片化问题；到 2025 年，OpenAI、Google 先后宣布支持，年底又交给了 Linux 基金会下的中立机构托管，已经从一家厂商的规范变成了跨厂商的事实标准。Anthropic 在 2025 年又把 Agent Skills 开放成标准，让企业把领域知识、流程、脚本封装成可组合、可移植的能力包。Forrester 的 2026 预测更直接：会有三成的企业应用厂商推出自己的 MCP 服务。换句话说，"把能力做成可复用的原子件"，已经是行业共识，不是某一家的话术。

落到甲方这边，这块能力还要兼顾两种生产方式：既能让懂技术的人用配置式开发把能力沉淀下来，也能让业务同事用自然语言把一个想法变成可用的能力。原料其实企业本来就有：流程、规则、SOP，过去躺在制度手册里、躺在老员工脑子里，现在可以一条条沉淀成可调用的原子能力。这是企业相对个人工具的天然优势。

但开放也带来新的风险，这一点选型时要留个心眼。能力包本质上是一段可以在企业环境里运行的代码，安全研究已经披露过 MCP 的"工具投毒"：在工具描述里塞进用户看不见、模型却会当成指令执行的内容；也披露过"地毯式抽换"，服务器会在获批之后再悄悄改掉工具定义。Anthropic 官方自己都建议：只从可信来源安装 Skill，不可信的要先彻底审计。所以这一层正确的做法，是内部评审加签名发布加私有的能力注册表，而不是像个人工具一样开放上传、随便组合。GitHub 在 2025 年底已经把"企业内部注册表加白名单、运行时阻断未批准的服务"做成了产品，这个方向值得参照。

关键能力三：模型要能统一接入、随时可换、还管得住

第三块能力，落在"模型的供给"上。

第一波 AI 建设里有一个隐藏假设：一个模型搞定所有场景。这是一个错误的目标函数。不同任务对模型的要求差异极大：推理任务要推理模型，写邮件、回 FAQ 这类高频指令要响应快的对话模型，Agent 编排要工具调用稳定的模型，看财报截图、扫描合同要多模态模型。工程上对应的做法，是一个模型路由层：请求进来，先判断任务类型，再分发到最合适的模型。

但路由只是表层，更重要的是后面这三件事。

一是不被任何单一供应商锁定。这两年模型市场的洗牌速度，超出了所有人的预期。Menlo Ventures 2025 年的统计里，企业大模型支出的格局两年之内剧烈翻盘：一家厂商从 2023 年的 12% 升到约 40%、坐上头把交椅，另一家从 50% 掉到 27%。a16z 的 CIO 调研也显示，已经有 37% 的企业在生产环境里同时跑五个以上的模型。企业的能力建设周期是五年起步，模型市场两年就重洗一次牌。把能力绑死在某一家闭源模型上，几乎是在给自己埋一笔高昂的迁移账。价值要沉淀到能力层、数据层、流程层，模型层做成可替换的"发动机"。

二是账要算得清。模型调用这件事，最容易被 CFO 和老板盯上，因为它直接对应钱。一个 Agent 在错误逻辑下陷入循环调用，一个周末烧掉几千上万块不是罕见的事。但更普遍的问题是：到月底看账单，知道一共花了多少，却不知道哪个 Agent、哪个部门消耗了多少；成本怎么分摊回业务，大多数企业还没建立机制，最后算不清就全进 IT 预算。云计算时代催生了 FinOps，AI 时代需要一套对应的机制，而且颗粒度要细到任务级：按一次完整任务算单位成本和 ROI，按月、按部门都太粗。

三是安全得管得住。业务同事自己觉得"我只是让 AI 帮我整理一下合同、归纳一下客户反馈"，但这份合同里可能就有客户名、报价、账期这些关键商业信息。敏感数据在 Agent 不知情的情况下被送到第三方、甚至送到海外模型，一旦出事，追溯起来非常被动。数据一旦进入模型，就是不可逆的。

把这三件事收口的，是一层统一的 AI 网关：统一接入不同来源、不同品牌的模型，做分发和路由、限流和配额、密钥的集中管理、调用情况的统一可观测，再加上一层内容护栏。Gartner 在 2025 年专门为 AI 网关出了一份市场指南，把这个品类正式立了起来，并预测到 2028 年，七成需要同时调用多个模型的工程团队都会用上 AI 网关，而 2025 年这个比例只有约四分之一。这件事正在从少数人的选择，变成多模型时代的默认形态。

这里也提醒一句边界：网关治理的是"模型怎么被调用"，它管不了"调用时发出去的内容本身准不准、该不该脱敏、有没有权限"。后面这些属于网关之下更靠近数据的一层，要单独评估，别把网关当成数据治理的万能解。

关键能力四：复杂的应用，要能从需求到运维被可控地开发出来

第四块能力，落在"深水区"上。

不是所有需求都能靠配几个 Agent、拖几条流程解决。企业里总有一类应用是复杂的、要长期维护的、对确定性要求很高的。这类东西，光靠 Agent 在业务里探，探不出一个可靠的系统，得真正"开发"出来。问题是，AI 时代的开发方式已经变了，而很多企业还没意识到这件事也需要一个平台来管。

先说一个正在被验证的演进节奏：先用 Agent 撬动业务，再用 AI Coding 沉淀逻辑。第一阶段用 Agent 在业务一线探，哪些环节能被 AI 提效、哪些规则是稳定的，靠的是大量推理，Token 消耗高是正常的，本质是用 Token 换业务认知；等一类业务跑顺了、稳定逻辑显现了，再把这部分逻辑交给 AI Coding 写成代码，落到确定性引擎上，这部分零 Token、零幻觉、可测试、可回归。顺序反过来，先想着把所有规则都用 AI 写成代码，多半会陷入"写了一堆没人用的规则"，因为没有 Agent 先去业务里探一遍，根本不知道哪些逻辑该被固化。同时具备 Agent 能力和 AI Coding 能力的平台，单位 Token 经济会明显好于纯 Agent 路线。

再说"可控"。这两年 AI 写代码的能力涨得很快，头部公司里 AI 生成的代码占比已经相当可观：谷歌的 CEO 在 2024 年三季度财报会上说，公司超过四分之一的新代码由 AI 生成、再由工程师审查接受；微软的 CEO 也说部分项目里有两三成代码是 AI 写的。Gartner 预测到 2028 年，九成的企业软件工程师都会用上 AI 代码助手，而 2024 年初这个比例还不到 14%。

但快不等于可控。我在聊规范驱动开发（SDD）的时候讲过一个现象：几乎每一个 AI Coding 产品里，都在长出一个叫 spec 的东西。背后的主张是：spec 才是真正的源代码，code 只是编译产物。为什么会收敛到这里？因为纯靠"感觉"和提示词聊出来的代码会带来三个问题：意图漂移、不可维护、不可治理。当 AI 可以一句话改一大段逻辑、中间没有任何"约定层"的时候，IT 事实上失去了对系统行为的可控感。spec 把约定层显性化，IT 管 spec，AI 按 spec 实现，企业终于可以对 AI 的产出负责，而不用靠开发者的自觉去兜底。GitHub 在 2025 年开源的 Spec Kit，就是把这套方法做成了"规格、计划、任务、实现"四个带门禁的阶段。

这件事的紧迫性，还有安全这一面。多项研究都证实，AI 生成的代码并不天然安全：Veracode 2025 年的报告测下来，模型在安全与不安全写法之间有选择时，约 45% 的情况选了不安全的写法；斯坦福更早的实验还发现，用 AI 助手的人不仅写出的代码更不安全，反而更相信自己写的是安全的。这意味着人审、安全扫描、可追溯这几道关一道都不能省。

所以这块能力要的，是一个能把"从需求到运维"全流程管起来的 AI Coding 平台：以 spec 沉淀意图，AI 负责实现，人保留审查和门禁，全过程可追溯。Gartner 还有一个判断挺值得记：到 2027 年，超过 65% 用智能体编码的团队会把 IDE 当成可选项，把控制、治理、校验这些事上移到平台层。开发这件事的重心，正在从个人的编辑器，挪到企业的平台上。

关键能力五：可观测、可管控、可治理，要做成贯穿全栈的底座

前面四块是平台的"四肢"，这一块是平台的"脊柱"。它不该是某个独立模块，而要贯穿前面所有能力。

我把规模化之后最容易爆的问题归过三类，这里再用选型的视角过一遍。

第一类，生命周期管理缺位。Agent 创建只要几分钟，下线决策却异常困难："这个谁建的？还有人用吗？删了会不会影响业务？"大多数企业答不上来，结果是"僵尸 Agent"越积越多，占着资源却没有对应的产出。

第二类，数据和接口调用缺统一管控。前面第二块能力已经讲过，这里强调的是治理视角：哪个 Agent 能访问什么数据、能调什么接口，要有一个统一的控制台看得全，而不是出了事再一个一个翻配置。

第三类，模型调用管不住。滥用、浪费、费用分摊说不清、敏感数据外泄，本质都是缺一层可观测。

这三类问题表面是三件事，底层逻辑一致：都是规模化之后才浮现，也都不是给开发者写一份规范就能解决的。规范可以提倡，但真到了几百上千个 Agent，靠文档和自觉是管不住的。它需要一层企业级的 AI 基础设施来承担，至少包括三件事：统一的数据、接口、工具封装层；统一的模型调度和可观测；统一的权限、计费、追溯机制。这一层和 Agent 平台的关系，更像操作系统和应用程序：前者承载治理能力，后者承载业务能力，配合起来才有一个健康、可持续的生态。

这不是我一个人的判断，外部的信号已经很密集。Gartner 预测到 2028 年，四成部署 AI 的组织会用上专门的 AI 可观测性工具，驱动力是高管对复杂模型和智能体风险的担忧，而不只是基础设施健康度。IBM 和 Ponemon 在 2025 年的《数据泄露成本报告》里有一组数字很扎眼：在确实发生过 AI 相关泄露的企业里，97% 此前并没有像样的 AI 访问控制；影子 AI 严重的企业一旦出事，平均泄露成本比影子 AI 少或没有的企业高出约 67 万美元；而真正有策略去管理、检测影子 AI 的企业，只有 37%。监管这边也在收紧。欧盟的 AI 法案分阶段落地，高风险系统被强制要求做记录保存、透明度和人工监督；NIST 的 AI 风险管理框架、ISO 的 AI 管理体系标准，都把治理从"事后补文档"变成了可对照、可审计的体系。Forrester 甚至预测，一半的企业 ERP 厂商会推出结合可解释 AI、自动审计追踪、实时合规监控的"自主治理模块"。治理正在从加分项变成标配。

治理还有一个常常被低估的价值：它能激活业务的自我治理。把模型消耗的账单按部门拆出来之后，业务主管自己就会算"我这个 Agent 到底值不值这个钱"。我接触到的企业里，有的在账单透明之后，业务方主动下线了一批低频 Agent，理由很朴素："这点用量不值这笔钱"。钱一算清楚，治理自然就发生了。治理一旦有了内生动力，就会从 IT 一家的事，慢慢变成全公司共同的事。

站在甲方的角度，选型时该特别注意什么

把五块能力翻译成选型动作，我自己更愿意用"可以多问一句"的方式，而不是给一张打分表。下面五问，都是我看到比较稳的几家企业在选型时会多想一步的地方。

选型一问：到了一百个、一千个 Agent 的时候，它还管得住吗？

Demo 阶段几乎家家都好看。真正拉开差距的是规模化之后：一百个、一千个 Agent 同时在跑的时候，谁在用、用了多少、花了多少、出了事找谁，平台答不答得上来。可以直接问一句："等我们有一千个 Agent 的时候，僵尸 Agent 怎么治理、资源怎么算账、权限怎么盘点？"如果对方只会演示怎么搭一个 Agent，却讲不清楚怎么管一千个，它更像一件工具，离一套底座还差得远。这一问对应的就是前面的判断：做出来不贵，养下去才贵。

选型二问：模型，是被绑死了，还是随时换得了、账算得清？

这一问有三个小问题：第一，能不能同时接多家模型、按任务路由，而不是绑死一家？第二，每一笔消耗能不能归到具体的 Agent 和部门，账能不能细到任务级？第三，敏感数据会不会在我不知情的情况下被送到第三方、甚至海外模型？模型市场两年就洗一次牌，押单一供应商的迁移成本极高；而成本和数据这两笔账，是老板和 CFO 一定会追的。一个连账都算不清、模型也换不了的平台，规模化之后会很被动。

选型三问：能力，是沉淀成了可复用的原子能力，还是每个 Agent 各自野生？

这一问是看一个平台有没有"中台底子"。可以问：工具、接口、技能是不是被统一封装成了可复用的原子能力？是不是原生支持 MCP 这类开放标准？能力包能不能复用、可移植、按需加载？再往安全里问一层：第三方的工具和能力包，有没有内部评审、签名、私有注册表和运行时白名单？权限是细到单个工具、单个动作，还是粗到一整台服务器？如果每个 Agent 都在野生状态下各连各的，重复建设和安全隐患是迟早的事。

选型四问：复杂应用，是"配"出来的，还是可控地"开发"出来的？

有些需求注定要靠真正的开发来解决，这时候要看平台是不是把 AI Coding 也管了起来，而且管得可控。可以问：复杂逻辑是先用 Agent 探、再用 AI Coding 沉淀成代码的吗？开发过程是 spec 驱动、有门禁、有人审、可追溯的吗？AI 生成的代码有没有强制的安全扫描？AI 写代码近一半会引入安全问题，这件事不会随模型变大自动消失。一个把 Agent 和 AI Coding 切成两个产品、两个采购周期的方案，往往会在"稳定逻辑该怎么落地"这一步卡住，可它本来就是同一条演进路径上的前后两步。

选型五问：治理，是原生贯穿的，还是 UI 上挂了几张图表？

这一问最容易被糊弄，也最该较真。可观测、可追溯、成本归属、权限管控、安全审计，到底是贯穿在原子能力层和编排层里的原生能力，还是只在界面上挂了几张监控图？分辨的办法很简单，让对方演示一次完整的追溯：某一个 Agent 在某一天，调了哪些数据、用了什么模型、花了多少、为什么走了这一步，能不能一路查到底。能查到底的，治理是真的；查不到的，治理只是个装饰。Gartner 把"风险控制不足"列为智能体项目大面积被取消的主因之一，不是没有道理。

写在最后

回到开头那个问题：一家企业要选一个企业级 AI 平台，到底该看什么？

我的回答是：别只看它能不能搭出一个 Agent，要看它能不能让一群 Agent 在企业里持续、安全、可控、可复用地产生价值。前者是工具，后者才是平台。落到具体能力上，就是这五块：业务建得起也用得上、能力能沉淀成可复用的原子件、模型能统一接入又管得住、复杂应用能从需求到运维被可控开发，以及一层贯穿始终的可观测、可管控、可治理的底座。

还有一个绕不开的选择：自建，还是采购。MIT 的报告里有个对比挺说明问题：从专业厂商采购、并建立合作关系的项目，落地成功率约 67%，纯内部自建的成功率大概只有它的一半。Forrester 的判断更直接：自己从头搭智能体架构的企业，四分之三会失败。倒不是说自建一定不行。底座这种东西，专业的事交给专业的平台，把精力留给自己最懂的业务场景，往往更划算。

最后说一句。企业 AI 成熟度的真正标志，不是做了多少个 Agent，而是由业务自行构建的比例，以及管好了多少个。前半句对应"做起来"，后半句对应"用下去"。选平台，本质上就是在为这两件事选一个能托得住的底座。

这条路才刚刚开始。没有谁站在岸上，大家都在重新校准。一起走。