2026.09.23 | FUNDA | AI Demand | Enterprise AI Spend Expert: Platform Consolidation
原标题：企业 AI 支出 Expert — 平台整合与工作负载带动效应
OKTAMSFTCRMNOWMDBSNOW
Expert · Strategy Executive, Top US telecom providerEthan WeiWooding
免责声明：本次访谈专家为行业专家。本文所引用的所有数据（包括但不限于增长率、客户规模、交易规模、地区拆分等）及前瞻性预测，均为受访专家基于既往行业经验给出的个人估算与回忆，不代表相关公司或其关联公司的官方披露，亦不构成任何非公开重大信息。本纪要内容仅供参考，不构成任何投资建议或商业决策依据。纪要观点仅代表相关观点发表者个人在特定时间点的看法，不代表 FUNDA 立场。作为独立运营的平台，FUNDA 保持中立第三方地位，不对纪要观点的准确性、完整性或适用性作出任何明示或暗示的保证。鉴于市场环境与技术趋势的快速变化，本纪要反映的是截至发布日之前的市场情况，相关信息可能随时间推移而失效。FUNDA 无义务对纪要内容进行实时更新。
摘要
- AI 安全仍是规模较小但快速增长的预算池 — 据该行业专家估计，AI 相关安全支出占整体安全支出的 5%-8%，其中智能体身份和非人类身份约占 20%，相当于整体安全预算的约 1%-2%。在另一个预算由 100 增至 110 的框架中，其将智能体身份支出设为 2025 年的 0.7/100，以及 2026-2027 年的约 1.5，对应小基数下 50%-100% 的增长。
- 运行时与数据保护主导 AI 安全支出分配 — 在智能体身份和非人类身份之外约 80% 的 AI 安全支出中，该行业专家将 25%-30% 分配给运行时与智能体安全，20%-25% 分配给数据安全与数据防泄漏，15%-20% 分配给治理、模型风险与红队测试，10%-15% 分配给网关、应用程序接口与防护栏，5%-10% 分配给可观测性。
- 身份需求更有利于扩容而非替换 — 截至该行业专家在原机构任职期间，Okta 与 Microsoft Entra 均已有部署，新的智能体身份和非人类身份正被纳入现有身份控制平面。已有 Okta 部署会优先评估增加身份治理、特权访问、智能体身份及非人类身份能力，而传统系统迁移则取决于续约周期、能力差距和迁移成本。
- Okta 支出增长 — 该行业专家估计2025 年的 Okta 支出增长为 10%-15%，2026 年约为 15%。
- 平台厂商受益于重叠产品的精简 — 方向性估计，Palo Alto Networks 与 CrowdStrike 的支出均可能增长 15%-25%，Microsoft Security 增长 10%-20%，Wiz 也被列为受益者。Tenable 和 Rapid7 的部分独立漏洞管理产品、独立云安全态势管理工具，以及重复的安全分析与自动化工具可能下降 10%-30%，部分产品甚至不再续约，但这并不意味着相关厂商整体必然失利。
- 开放权重模型降低推理支出但增加安全成本 — 据估计，开放权重模型占推理或Token消耗量的 40%，但仅占模型应用程序接口及推理支出的 25%-30%。若以完全托管的专有模型安全成本为 100，该行业专家估计托管式开放权重模型为 105-110，自托管开放权重模型为 115-120；在可比的生产环境工作负载下，后者的安全成本高出 10%-20%。
- AI 网关结合自有策略控制与商业检测能力 — 该行业专家在原机构任职期间，模型路由器和 AI 网关负责身份验证、授权、提示词注入检测、敏感数据控制、模型白名单、审计、防护栏及智能体权限。其估计 60%-70% 的能力来自商业云安全工具，30%-40% 来自自研的集成、路由和策略逻辑。
- 数据库带动效应由工作负载驱动 — 据该行业专家估计，原机构的直接 AI 年化运转率为 2,000 万-2,500 万美元，每 1 美元直接模型支出约带动 0.15-0.25 美元的数据库或数据平台支出，相当于每年估算约 300 万-600 万美元。需求涵盖向量搜索、文档数据库、数据湖、数据仓库、缓存和数据管线，而非单独设立的集中式 AI 数据库预算。
- 智能体工作负载按架构分化数据库需求 — 据该行业专家观察，MongoDB 更适合实时操作型智能体和记忆，Snowflake 更适合受监管的企业分析型智能体，Databricks 更适合高度依赖数据工程与机器学习的智能体。AI 部署更可能提高现有战略性数据供应商的钱包份额，而非要求引入新的数据库供应商。
- 每 1 美元模型支出带动更广泛的云消耗 — 该行业专家估计，每 1 美元直接 AI 模型支出约带动 0.30-0.50 美元的传统云支撑支出，且不包括模型应用程序接口本身。其中，计算占 10-15 美分，存储和数据传输占 8-12 美分，数据库、缓存和搜索占 5-10 美分，网络占 3-6 美分，可观测性、安全及其他平台服务占 3-7 美分。
- 云支出增长源于消耗组合而非普遍上调公开标价 — 据该行业专家估计，随着 AI 工作负载从试点走向生产环境，传统云支出在 2025 年增长 8%-12%，2026 年增长 12%-18%。其将更广泛云支出增长的 70%-80% 归因于用量和架构组合，20%-30% 归因于有效单位成本和定价效应。
- AI 推动开发工具经济性从席位转向工作量 — 该行业专家估计，未来 1-2 年开发人员数量仅增长 0%-5%，而软件产出和变更量增长 15%-30%，并预计 2026 年 80%-90% 的代码由 AI 生成。GitHub Copilot、Claude Code 和 Cursor 被列为第一波受益者，而 Atlassian、GitLab、Harness 和 Ansible 可受益于下游审查、测试、部署、安全和自动化工作量。
- 记录系统通过智能体执行实现商业化 — 该行业专家估计，Salesforce 支出增速将由 2025 年的 5%-8% 提升至 2026 年的 10%-15%，ServiceNow 则由 8%-12% 提升至 15%-20%。预期加速来自 AI 模块、智能体工作流用量、数据集成、治理和平台整合，而非仅依赖员工席位增长。
- 轻量应用层面临精简 — 该行业专家估计，未来 2-3 年，工作流、工单、知识搜索和基础自动化领域的外围 SaaS 单点方案存在 10%-20% 的支出精简空间。部分节省资金可能重新投入核心记录系统、AI 模块、智能体平台、集成应用程序接口、数据层和安全治理，从而减少供应商数量，同时提高核心平台的钱包份额。
核心观点
- 安全平台整合增速可超过整体预算增长 — 即使整体安全预算仅增长约 10%-15%，该行业专家认为，随着新身份需求与重叠单点产品的预算再分配叠加，核心身份平台支出仍可能增长 20% 以上。
- 直接模型支出低估 AI 的基础设施影响 — 该行业专家分别估计，每 1 美元模型支出带动 0.15-0.25 美元的数据库及数据平台支出，以及 0.30-0.50 美元的更广泛云支撑消耗。两者均被视为由工作负载驱动的关系，而非严格固定的附加比例。
- 托管式开放权重模型提供安全成本折中方案 — 安全成本指数从完全托管专有模型的 100，上升至托管式开放权重模型的 105-110，以及自托管部署的 115-120，这支持了该行业专家通过大型云平台使用开放模型的倾向。
- 现有平台部署基础决定 AI 受益者 — 数据库选择取决于工作负载架构，而当平台原生 AI 能满足 80%-90% 的需求时，通常会获得优先采用。这更有利于现有战略性身份、数据、工作流和记录系统供应商，而非新的单点方案。
- 工作流规模正在取代人数成为开发工具增长主线 — 在开发人员数量预计仅增长 0%-5%、产出增长 15%-30% 的情况下，该行业专家预计，能够对智能体、自动化和用量收费的工具将优于仅依赖人类席位的产品。
- 记录系统增强，轻量应用承压 — Salesforce 与 ServiceNow 支出预计在 2026 年加速，而外围 SaaS 单点方案在未来 2-3 年面临 10%-20% 的精简空间。该行业专家预计，应用供应商数量将减少，但掌握权威数据和事务性工作流的平台将获得更高的钱包份额。
EW
Ethan Wei
上次您提到与 AI 直接相关的支出大约占 8%，其中约 15% 到 20% 分配给了身份安全，是吗？
EX
Expert · Strategy Executive
对。在专门针对 AI 的安全支出中，我估计大约有 15% 到 20% 是投入在 Agent 身份上的。折算到整体安全预算，大约占 1.6% 左右（即 8% 乘以该比例）。因此，目前与 AI Agent 身份安全相关的投入，大致相当于整体安全预算的 1% 到 2%。
EW
Ethan Wei
假设以前的预算基准是 100，现在增加到了 110，其中有 1 到 2 分配给了与 Agent 相关的身份安全，那么在之前那 100 的预算中，分配给身份安全的部分大概是多少？
EX
Expert · Strategy Executive
关于这一部分，如果沿用我上次提到的100到110这个分析框架：如果是整个传统身份安全，比如IAM、PAM、IGA，它原本远不止1%到2%；Agent相关的身份安全在100中占1%左右。而到2026年的110中，我估计大概会上升到中位点1.5%到1.6%左右。所以它仍然属于一个“小基数、高增长”的类别，会有大约50%到100%的增长。 这并不意味着整个身份安全预算翻倍，而是因为该公司新增了Agent身份、NHI、Agent授权、凭据与机密管理、面向Agent的特权访问等需求。而且我其中并非全都是纯新增的厂商支出（net-new vendor spend），一部分是用于现有IAM、PAM平台的扩容或增加新模块，另一部分才是采购新兴的AI Agent专用安全产品。因此在做模型时，比如2025年可以设为0.7/100，2026到2027年设为1.5左右。
EW
Ethan Wei
该公司之前使用的是Okta，还是Microsoft Entra？
EX
Expert · Strategy Executive
公司曾使用Okta，同时也有Microsoft Entra ID的足迹。比如Okta，该公司用它做身份与访问管理，目前也在逐步增加AI Agent身份的用例。另外，像更完整的IGA、PAM等能力，也会有其他身份安全工具作为补充。因此在AI Agent兴起之前，这些平台主要管理的是人类身份、应用程序、服务账号以及传统的机器身份。
EX
Expert · Strategy Executive
现在最大的变化并不是把原有的IAM全部替换掉，而是把Agent身份和NHI纳入现有的身份控制平面。这意味着要为AI Agent赋予独立身份、明确所有者，实施最小权限原则、短期凭证，以及完整的授权与审计追踪。因此，从支出的角度来看，公司看到的更多是对现有身份平台的扩展，增加针对AI的增量特定能力，而不是重新采购一套完全独立的IAM技术栈。
EW
Ethan Wei
也就是说平台化整合在Okta上也是成立的，对吗？比如该公司可能会采购更多Okta的IGA或者PAM？
EX
Expert · Strategy Executive
可以理解为采购更多的Okta IGA或PAM。
EW
Ethan Wei
以Okta为例，请问公司对它的预算在2025年和2026年的同比增速分别大概是多少？比如虽然整体预算上只增加了一两个百分点的NHI身份预算，但如果Okta原本占比是10%的话，对Okta而言可能就意味着10%的增长。
EX
Expert · Strategy Executive
如果是指公司自身对Okta支出的增长率，而非Okta自身的收入增长，我预计2025年大概增长10%到15%左右。2026年可能类似，估计也在15%左右。
EX
Expert · Strategy Executive
2025 年的增长还是传统这种 workforce identity、SSO、MFA 以及 governance。到 2026 年，除了原有的 footprint 扩张以外，增量更多来自 IGA、privileged access、NHI、machine identity 以及 AI agent identity security。所以这里既有像正常的 license、usage expansion，也有刚才讲的 platform consolidation，像部分原来可能给 point solution 的预算逐渐迁移到 Okta platform。这个方向和 Okta 自己披露的数据也比较一致，但要注意的是，公司不能把它当做公司的 spend 验证。 据观察，其 subscription revenue 同比增速大致处于低双位数至中双位数水平。这可能是一些新产品组合的贡献，像 Okta Identity Governance 比较领先。该增速高于整体 security budget 增速，体现的不是整体预算激增，而是公司的 identity demand expansion 加上 AI、NHI，再加上 consolidation 和 share of wallet gain 等不同因素的影响。
EW
Ethan Wei
也就是说确实有一些预算再分配，出现了再加速的迹象，从 12% 到了 15%，同比增速实际上变快了一些。
EX
Expert · Strategy Executive
是的。不过我所说的 2025 年 12% 和 2026 年 15%，这种加速增长并不会来自整体 security budget 的增加。更重要的是来自于 budget reallocation 和 share of wallet expansion。一方面公司减少一些重叠的 point solutions，另一方面把更多像 IGA、PAM、NHI、machine identity 和 agent identity 的新增需求集中到 strategic identity platform 上。因此，即使 overall security budget 只增长约 10% 到 15%，某个核心 identity platform 的支出完全可能增长 20% 以上。
EW
Ethan Wei
在这与 AI 直接相关的 8% 预算中，如果 20% 分配给了身份安全，剩下的 80% 分别流向了哪些领域？
EX
Expert · Strategy Executive
AI spend 大约占 overall security budget 的 5% 到 8%，其中 20% 是 agent identity 和 NHI。剩下的 80% 里面：25% 到 30% 投向 AI runtime 和 agent security，包括 agent execution、tool/MCP calls、prompt injection、runtime detection 与 enforcement，这是目前最大的一块；20% 到 25% 投向 AI data security 和 DLP，主要是保护进入和离开模型的敏感数据，包括 data leakage、prompt 与 output inspection，以及 DSPM 相关的管控；15% 到 20% 投向 AI governance、model risk 和 red teaming，包括模型测试、AI red teaming、policy compliance、model/agent inventory 和 risk assessment；10% 到 15% 投向 AI gateway、API 和 guardrails，包括 model access control、prompt/output guardrails、API protection 以及跨模型的 policy enforcement；剩下的 5% 到 10% 投向 AI security observability，例如 monitoring、tracing、security telemetry、异常行为检测以及 SOC integration。
EX
Expert · Strategy Executive
这里公司做了一些预估，这些类别实际上肯定会有重叠。比如说一个 AI runtime 平台可能同时包含 guardrail 和公司所说的可观测性，所以采购合同未必会严格按照这几个不同的预算 bucket 去划分。
EW
Ethan Wei
具体来说哪些供应商是受益的，哪些供应商是实打实被砍了预算导致受损的？受益方上次您提到了 Palo Alto Networks、CrowdStrike 和 Okta，还有其他的吗？至于受损方，上次您提到了 CSPM、漏洞管理以及一些 SIEM，公司目前在削减这些单点解决方案。那么从供应商角度来看，哪些供应商的预算正在被削减？
EX
Expert · Strategy Executive
我会做一下区分，即公司自身 wallet share 的增减与这些公司整体业务的好坏并不是一回事。比如，行业本身确实在朝 consolidation（整合）方向发展，尤其是 CSPM 正在被完整的 CNAPP 吸收，而漏洞管理也越来越与 exposure management（暴露面管理）、云以及 runtime context 整合。在公司自身的支出中，除了前面提到的 Palo Alto Networks、CrowdStrike 和 Okta 之外，另外两个比较明显的受益者是 Microsoft Security 和 Wiz。Microsoft 的优势在于 Entra、Defender 以及 Purview 等产品，他们已经拥有庞大的企业 footprint（客户基础）。Wiz 则更受益于云安全从独立的 CSPM 向 CNAPP 等更广泛的云安全平台迁移。 至于被削减的部分，我更倾向于按照具体产品的 footprint 来说，而不是某家供应商整体受损。例如，在独立的漏洞管理上，公司会压缩 Tenable 和 Rapid7 等有重叠 footprint 的支出，因为漏洞扫描本身越来越能被 CrowdStrike、Wiz、Microsoft 或更大的 exposure management 平台覆盖。从行业层面也能看到，传统的专业漏洞管理厂商正面临来自平台型厂商在 exposure management 等衍生领域的竞争。 SIEM 也是类似的情况。公司会合理化一些独立的 SIEM、SOAR 以及重复的日志摄取（log ingestion）支出，但这并不意味着 Splunk 整体一定会被砍；在某些工作负载上它依然非常关键。真正容易被削减的是同一份 telemetry（遥测数据）被两三个产品重复摄取并重复收取检测许可费用的情况。Rapid7 在谈到 2026 年的趋势时，也明显提到了整合的速度，以及将不同工具的 telemetry 汇聚起来提供统一 context 的必要性。 从支出走向来看，Palo Alto Networks 可能会增长 15% 到 25%，CrowdStrike 增长 15% 到 25%，Okta 增长约 15% 到 20%，Microsoft Security 增长 10% 到 20%。而面临合理化削减的独立产品 footprint，例如 Tenable 和 Rapid7 的部分漏洞工具、独立 CSPM，以及重复的 SIEM 和 SOAR 工具，支出可能会减少 10% 到 30%（-10% 到 -30%），个别产品甚至会直接不再续约。但重要的一点在于，并不是说 Rapid7 或 Tenable 这类公司就一定会输。
EX
Expert · Strategy Executive
我觉得这些厂商也在推进平台化，比如像 Rapid7 正在将 Exposure、Cloud Security 和 SecurityOps 整合为一个统一平台。其实真正承受压力的是独立 SKU 和单点解决方案的预算。如果一个能力可以被现有的战略性平台满足 80% 到 90%，公司就越来越难以证明继续保留独立许可的合理性。
EW
Ethan Wei
公司目前有提供 Microsoft E7 吗？也就是 Copilot E7，或者说最高等级的订阅方案？
EX
Expert · Strategy Executive
对，不过首先，从部署角度来看，该公司拥有相当庞大的 Microsoft 企业级产品部署基础。但现阶段，公司认为 Microsoft E7 更适合有针对性地部署，而不是为所有员工全面升级。对于普通员工而言，保留现有的 E3、E5 和其他许可证更具经济性。对于大量使用 Copilot、构建和管理 AI Agents，或从事安全、身份管理和 IT 管理工作的高价值用户，公司可能会更积极地评估或采用 E7。 对该公司而言，最大的吸引力不仅仅是 Copilot 本身，而是 Agent 365 加上完整的 Entra 套件、Agent Security 和治理能力。在定价方面，根据估算，E7 的成本可能接近每位用户 100 dollars，而 E5 约为 50 到 60 dollars，不过官方定价尚未公开确认。为全体员工升级显然会带来非常高的增量成本，当然，这也取决于具体的企业协议。因此，如果 E7 能够将 Copilot、身份管理、非人类身份（NHI）、Agent 治理和安全能力打包在一起，确实可以替代目前分配给部分独立单点解决方案的预算。
EW
Ethan Wei
之前调研时您曾提到开源模型的使用量大概占 40%，当时我不确定这是指用例数量还是按 Token 的用量，此外支出占比可能是 API 支出的 30%。在使用开源模型时，该公司是否需要准备额外的安全支出？
EX
Expert · Strategy Executive
上次提到的 40% 是指 AI 工作负载、推理用量或 Token 消耗量中约有 40% 采用开源模型，而不是指 40% 的用例，因为单个用例之间的流量差异可能非常悬殊。在支出方面，由于开源模型独特的经济性，成本通常更低，因此即使消耗量占比约 40%，对应的模型 API 和推理支出占 25% 到 30% 也是合理的。 使用开源权重模型确实会产生新增的安全支出，最大的区别在于，使用闭源托管 API 时，模型提供商会替公司承担一部分模型托管、补丁更新、模型完整性以及平台安全；而如果公司自行部署或深度定制开源模型，这些责任就回到了公司自己身上。例如 OWASP 就明确将第三方模型的来源追溯、篡改、投毒、LoRA 低秩适配器、模型工件完整性以及 AI 供应链风险列为需要额外管控的领域。
WO
Wooding
具体来说，我认为额外投入主要有四个方面：第一是模型供应链安全（model supply chain security），包括模型溯源（model provenance）、权重扫描（weight scanning）、模型签名（signing）、AI 软件物料清单（AIBOM）以及 LoRA 适配器验证（adapter validation）；第二是红队测试（red teaming）与模型评估（model evaluation），因为公司不能完全依赖模型提供商做好的安全评估；第三是运行时护栏（runtime guardrails），包括提示词与输出检查（prompt and output inspection）以及模型行为监控；第四是底层基础设施安全（infrastructure security），包括自托管推理集群（self-hosted inference cluster）、容器、Kubernetes、模型注册表（model registry）和推理服务端点（serving endpoints），这些都需要自行防护。 开源工作负载的安全成本不会高出 30% 到 40%，那太高了；我预计在同等生产级工作负载下，开放权重或自托管部署的安全相关成本大约比完全托管的专有 API 高出 10% 到 20%，对于高度敏感或经过微调（fine-tuning）的模型可能还会更高。开源模型虽然降低了模型的单位推理成本，但其中的一部分节省会被安全、治理和运维开销所抵消。因此在权衡开源与闭源模型时，公司通常不会只比较每 token 的推理成本，而是会考量完整的总体拥有成本（TCO），涵盖推理、基础设施、安全、治理以及运维。
EW
Ethan Wei
即使未来该公司通过 AWS 或 Azure 调用开源模型，该公司也会额外准备一些自己的安全措施吗？
EX
Expert · Strategy Executive
对。但公司需要区分托管式开放权重模型（managed open-weight models）与自托管开放权重模型（self-hosted open-weight models）。例如，通过 Amazon Bedrock 或 Azure AI Foundry 调用开源或开放权重模型时，AWS 或 Azure 已经承担了底层基础设施、部分模型推理服务以及平台安全，因此公司的额外安全投入会明显低于完全自建部署的模型。但公司依然会保留自己的企业安全层（enterprise security layer）。因为云厂商保护的是底层平台，无法替公司决定哪些员工或智能体（agent）可以访问该模型、哪些企业数据可以进入提示词，或者模型输出是否可以触发特定工具与操作。因此，公司仍然需要 IAM、非人类身份管理（NHI）、DLP、数据安全态势管理（DSPM）、AI 安全网关、AI 护栏，以及提示词与输出的监控、审计日志和智能体治理。 如果要量化，假设完全托管的专有模型增量安全开销基准为 100，通过 Bedrock 或 Foundry 使用托管式开放权重模型大约在 105 到 110；如果公司自己在 EKS（Kubernetes）或 GPU 基础设施上自托管、微调和提供开放权重模型服务，开销可能会达到 115 到 120。所以对公司来说，开源模型并不等同于自托管。实际上，公司越来越倾向于通过 AWS、Azure、GCP 等超大规模云厂商的托管层来使用开放模型，这样既保留了模型选择灵活性与成本优势，又无需自行承担全部的安全与运维负担。
EW
Ethan Wei
这家公司自身是否有构建模型路由器（router）或网关（gateway）？如果有，是否会设置安全措施来检查通过的流量？这些安全检查能力是采用外部供应商的方案，还是更偏向于自建？
EX
Expert · Strategy Executive
公司自身确实构建了模型路由器（model router）和 AI 网关层（AI gateway layer）。
EX
Expert · Strategy Executive
后端在同时接入专有模型（proprietary model）、权重开放模型（open-weight model）以及不同云模型供应商时，这一层非常关键。它不仅承担路由功能——比如根据成本、延迟、模型能力和数据敏感度来选择模型，同时也是一个很自然的集中化安全执行点（centralized security enforcement point）。在安全层面，公司会在网关执行几类检查，包括身份验证（authentication）、授权（authorization）、提示词注入检测（prompt injection detection）、PII及敏感数据检测、DLP、模型白名单（model allowlist）、速率限制（rate limiting）、日志记录（logging）、审计（audit），以及部分输入输出安全护栏（guardrails）。针对智能体工作负载（agent workload），公司还会进一步关注工具与MCP权限（MCP permissions）、智能体身份（agent identity）和策略执行。 关于自建还是采用第三方方案，公司更倾向于混合模式（hybrid approach），而不是全部自研。像网关、路由编排（router orchestration）以及企业特定的策略层（enterprise-specific policy layer），公司更倾向于自主掌控，因为它与内部架构、模型选择以及成本路由深度耦合。但底层的安全检测能力，比如DLP、分类器、威胁检测、AI安全护栏和实时信号，公司不会去重复造轮子，而是直接调用现有云安全厂商的能力。如果一定要按比例划分，大约60%到70%依赖现有的商业云安全能力，30%到40%是自研的集成、路由和策略逻辑。长远来看，商业化方案的占比甚至可能会进一步提高。因为随着AI流量的增长，公司真正想要拥有的是策略和编排能力，而不是自己去维护每个检测模型。简而言之，公司拥有策略与路由层，但无需自行构建每一个安全控制点。我认为AI网关本身会成为推动AI安全支出增长的一个关键切入点（pull-through point）。
EW
Ethan Wei
关于数据库方面，公司目前在AI上的年支出大概在两千万美元左右，请问是否会专门为数据库额外划分预算？也就是说，针对AI对数据库的拉动，是否有专门的额外支出或独立的预算池？
EX
Expert · Strategy Executive
针对像MongoDB这样的数据库，关于你提到的“额外独立预算池”这种说法，公司目前直接的AI年化运转率（run rate），如果按之前讨论的每月约200万美元计算，一年大概是2000万到2500万美元。AI对数据库和数据基础设施确实有显著的拉动效应（pull-through），但公司通常不会设立一个名为“AI数据库预算”的完全独立的预算池，更多是在数据平台和云基础设施预算中，为AI工作负载进行增量分配（incremental allocation）。 如果按比例量化，我估计目前每1美元的直接AI模型支出，大约会带动0.15到0.25美元的数据库或数据平台支出。因此，按照2000万到2500万美元的AI总支出计算，与AI工作负载直接相关的增量数据库及数据平台投资每年大约在300万到600万美元的量级。但这并不局限于传统的关系型数据库，而是涵盖了向量搜索（vector search）、文档数据库（document DB）、数据湖、数据仓库、缓存以及支持数据管道的ETL。 AI拉动数据库预算主要有三个驱动因素：第一是RAG和企业知识库，需要存储向量嵌入（embeddings）、元数据以及大量非结构化数据；第二是智能体应用（agentic applications），因为智能体本身需要管理状态（state）、记忆（memory）、会话历史、工具调用结果以及运营数据；第三是推理越来越趋近于实时，对低延迟的检索与搜索层提出了更高要求。
EX
Expert · Strategy Executive
所以像 MongoDB 这样的平台，受益的不只是向量数据库（vector database）这一单点需求；实际上，AI 应用本身就需要操作型数据库（operational database）、文档存储（document store）与向量检索（vector search）的结合。类似地，现有的云数据库和数据平台也会分得这部分增量。其实预算的形成方式与刚才提到的安全（security）很像，并非在 AI 预算中预先固定划拨 20% 给数据库，而是在每个 AI 工作负载走向生产化（productionize）时，根据存储、检索、向量搜索、吞吐量和延迟要求来增加相应的数据库能力。因此，它更接近于工作负载驱动的带动效应（workload-driven pull-through），而非一个集中式统一拨款的 AI 数据库基金（fund）。
EW
Ethan Wei
考虑到该公司未来可能也会推进 AI 智能体（agent）及 AI 工作流的转型或扩大应用，像 MongoDB、Snowflake 和 Databricks 这些不同的数据库公司，在面对这类工作负载时各自有哪些独特的优势？比如 Snowflake 或 Databricks 在智能体工作流（agentic workflows）中是否会有更出色的表现？在您的观察和实际接触中，它们是在各自不同领域各有专长，还是说擅长的方面其实都差不多？
EX
Expert · Strategy Executive
智能体工作流（agentic workflow）并不会让所有的数据库厂商均等受益，因为智能体对数据层提出了几种截然不同的需求：既需要访问企业的历史数据进行推理（reasoning），又需要低延迟的数据检索（retrieval），同时还要保存状态（state）、记忆（memory）、对话历史（conversation history）以及工具调用结果（tool result）。因此，MongoDB、Snowflake 和 Databricks 实际上是在智能体架构的不同层级发挥优势。 我认为 MongoDB 的优势更偏向操作型与应用层（operational and application layer）。如果智能体需要高频的实时读写，例如保存会话状态（session state）、短期和长期记忆、对话历史、JSON 文档数据，同时需要一体化的全文搜索，MongoDB 是非常自然的选择，因为这些都可以统一存放在一个操作型数据库中。MongoDB 目前也在强化持久化智能体记忆（persistent agent memory）、向量检索、全文检索与实时操作型数据的结合。因此在客服智能体（customer service agent）、IT 支持智能体和个性化智能体等实时应用场景中，MongoDB 的拉动效应（pull-through）更直接。 Snowflake 的优势则更偏向企业分析型数据和受监管的智能体（enterprise analytical data and governed agents）。例如财务、销售或营销智能体在被问到“过去三个季度哪些客户细分群体的流失率上升了，原因是什么”时，需要访问大量的结构化企业数据、自动生成 SQL，并结合非结构化文档。Snowflake 的 Cortex Agents 目前可以将 Cortex Analyst、Cortex Search、工具调用（tool calling）以及多步编排（multi-step orchestration）整合在受监管的工作流（governed workflow）中。如果企业的核心海量数据本身就存放在 Snowflake，公司绝不会仅仅为了智能体而将数据全部迁移到另一个数据库中。 Databricks 在数据工程、机器学习工程（ML engineering）与智能体工作流的融合上表现尤为突出。如果智能体底层涉及湖仓数据（lakehouse data）、机器学习模型、特征工程、RAG 评估与治理，Databricks 是极其契合的。如今 Databricks 通过 Lakebase 等引入了托管的 Postgres，也具备了支撑智能体状态和记忆的能力，同时通过其 AI Search 提供向量检索。它实际上是从原有的分析与 AI 平台向操作型智能体数据层延伸。 因此，公司不会简单判定 Snowflake、Databricks 和 MongoDB 谁在智能体方面更胜一筹，而是取决于具体的工作负载（workload）：对于实时操作型智能体，MongoDB 更自然；对于企业分析与 BI 智能体，Snowflake 更自然；而对于重度依赖数据科学与机器学习的智能体，Databricks 则更契合。 此外，这三家厂商的能力边界正在迅速重合。例如 Databricks 的 Lakebase 已经提供 Postgres 结合向量与关键词搜索；Snowflake 正在大力加强 Cortex Agent；MongoDB 则将操作型数据、搜索与智能体记忆深度整合。 从采购的角度来看，有一点非常关键：AI 驱动的数据库拉动效应，并不一定意味着公司会引入新的数据库供应商；更多时候，是现有的战略性数据供应商在公司钱包份额（wallet share）中的占比增加。
EX
Expert · Strategy Executive
AI往往越往production走，公司给MongoDB、Snowflake和Databricks的spend都可能增加，分别被不同类型的workload拉动。
EW
Ethan Wei
关于传统云的问题，比如AWS或GCP的CPU、存储或其他功能：您是否观察到某种固定比例关系，比如公司每在AI功能上花1美元或100美元，就会对传统云产生固定比例的支出？也就是每花1美元的AI支出，需要额外花多少美分在CPU计算、存储或其他传统云功能上？
EX
Expert · Strategy Executive
公司确实能观察到这种现象，它在财务上不是一个严格固定的attach ratio，比如每花1美元模型API就一定对应0.3美元传统云。它更像是随着AI workload投入生产（productionization）而形成的一个相对稳定的pull-through关系。 从AWS自己的GenAI参考架构中也能看到，即使模型是通过API调用的，外围仍需要EC2、S3、CloudWatch、Lambda等服务；引入RAG后，又增加了向量存储（vector storage）、RDS、OpenSearch以及ElastiCache等。 按照公司目前的workload mix做管理层预估（management estimate），我认为每1美元直接的AI模型支出，大概还会带动0.3到0.5美元更广泛的传统云支出。这里所说的传统云支出排除了模型API本身，属于支撑性基础设施。 这30到50美分大致可以理解为：10到15美分用于计算（容器和Serverless等）；8到12美分用于存储和数据传输（data movement）；5到10美分用于数据库、缓存和搜索；3到6美分用于网络；3到7美分用于可观测性、监控、安全以及其他平台服务。并非每个workload都完全一样。
EW
Ethan Wei
今年以来，您是否有感觉到最近几个季度传统云里的CPU计算和存储单价都在上涨？它们单价都在涨吗？
EX
Expert · Strategy Executive
就今年和最近几个季度来看，确实能看到每个workload的有效云成本（effective cloud cost per workload）存在一定上行压力。但我会特别区分：这并不等于AWS、Azure、GCP等厂商全面上调了基础CPU或对象存储的公开标价（list price）。比如AWS目前仍强调S3等服务的阶梯定价（tiered pricing）、Savings Plans和私有定价（private pricing）；在很多场景下，用量越大单位价格反而可能下降。 从公司实际看到的账单来看，主要有三个驱动因素：第一，CPU和内存组合（memory mix）变贵。Agent workload除了推理（inference），还会产生编排（orchestration）、检索（retrieval）、前后处理（pre/post-processing）以及工具执行（tool execution）。因此即便vCPU标价没变，每个AI workload平均消耗的CPU和内存也在增加。第二，存储组合（storage mix）变贵。这不仅是简单的S3纯存储容量，而是更多使用了高性能存储、频繁读写、向量搜索、缓存、快照（snapshots）和数据复制（replication）。第三，往往最容易被忽视的是网络与数据处理。Agent工作流会产生大量东西向流量（east-west traffic）、跨AZ/跨Region调用、PrivateLink、NAT网关、Transit Gateway等数据处理费用，这些在AWS文档中也明确列出了额外收费项。 如果将价格效应与用量效应区分开，我估计公司今年更广泛的传统云支出增长中，可能有70%到80%归因于使用组合效应（usage mix effect），20%到30%归因于有效单位成本与定价效应（pricing effect）。也就是说，云账单增长较快并不是因为云巨头直接单方面涨价，而是因为AI workload消耗了更昂贵的计算、存储、数据库和网络服务组合。
EX
Expert · Strategy Executive
比如去年某一类 supporting cloud workload 花了 100，今年可能变成了 115 到 125，不是云厂商价格涨了 15% 到 25%，可能只有几个百分点来自 effective pricing mix，剩下大部分还是 consumption growth 加上 architecture complexity。公司现在做 AI TCO 的时候，越来越不只是看 cost per token，而是会看完整的 cost per AI task 和 cost per agent workflow，后者才会把 CPU、storage、database、network 和 observability 全部算进去。
EW
Ethan Wei
我可以理解为 2026 年传统云支出的增速可能会比 2025 年更高，存在一个轻微的加速，这主要是因为 AI 的广泛使用。可以这样理解吗？
EX
Expert · Strategy Executive
我觉得可以这么理解。在公司看来，2026 年传统云支出的增长相比 2025 年确实是一个温和的加速（moderate acceleration），而 AI 工作负载从试点（pilot）向生产环境（production）扩张是其中一个较重要的驱动因素。 我认为，2025 年的同比增速在 8% 到 12%，2026 年大概在 12% 到 18%。但这并不是说 CPU 或 storage 本身的价格涨了这么多，主要还是用量（usage）和工作负载结构（workload mix）在增长。Agentic AI 带来了更多像 CPU orchestration、storage、database、search、network traffic 以及 observability 的消耗。所以可以概括为，AI 不仅增加了直接的模型与 GPU 支出（direct model GPU spend），也在重新加速传统云的消耗（traditional cloud consumption）。我预计随着 agentic workload 进一步走向生产化，这种带动效应（pull-through）在未来几个季度肯定会更加明显。
EW
Ethan Wei
关于 Atlassian 的 Jira 和 Confluence 这类开发者工具。目前存在一个争议：一方面有一种悲观论调，认为随着 AI 效率提升，开发者人数可能会持平甚至减少，导致席位收入增速放缓乃至下滑；但另一方面也有观点认为，AI 赋予了每个开发者更大的杠杆，企业为了利用这种杠杆会雇佣更多开发者，从而带动开发工具收入增加。请问在该公司，您观察到的现象更偏向哪一种？
EX
Expert · Strategy Executive
从我个人了解到的情况来看，实际情况介于两者之间。AI 提效并没有导致研发人数（developer headcount）同比例缩减；更贴切的描述是工程团队人数保持相对平稳（relatively flat），处于低个位数增长（low single-digit growth），而产出增长得快得多。需要明确的是，生产力提升（productivity gain）并不会 1:1 转化为端到端交付提升（end-to-end delivery gain）。但对公司而言，AI 编程工具确实让单个开发者产出了更多代码、PR 和变更。很多代码现在都是 AI 写的，占比可达 60%、70%、80% 甚至 90%，但这反而极大地增加了下游工作量。公司现在面临更多的 code review、CI/CD 运行、安全扫描（security scanning）、测试、文档、工单（tickets）、部署以及可观测性需求。到了2026年，我认为大约 80% 到 90% 的代码都由 AI 生成，但同时也带来了许多工作流问题。 对于像 Atlassian 这样的厂商（Jira 和 Confluence），不能简单地将其收入按开发者席位（developer seat）来建模。实际上，Jira 和 Confluence 本身正在从单纯的人类开发者席位工具，转变为融合人类与 AI Agent 工作流的记录系统（system of record）。Jira 正在明显向管理人类与 AI Agent 的规划、治理和度量层（planning, governance, and measurement layer）推进。 而像 Ansible 这类工具则有所不同。AI 产生了更多软件工程基础设施变更后，公司反而需要更多的自动化（automation）、配置管理（configuration management）、策略执行（policy enforcement）和可重复部署（repeatable deployment）。
EX
Expert · Strategy Executive
核心不在于有多少开发者，而在于有多少基础设施和工作流任务需要自动化。如果对公司做一个方向性的量化，我认为未来一到两年内，开发者员工人数（headcount）的年增长率可能只有0%到5%，但软件产出和变更量可能会增长15%到30%。因此，传统的纯按人头席位（per-seat）收费的开发者工具将面临压力。但那些能够将AI Agent、自动化、工作流规模、安全治理以及基于用量（consumption-based）进行商业化变现的平台，反而有机会推动单开发者支出（spend per developer）上升。因此，真正的变化并不是AI导致开发者变少、进而引发开发工具支出下降；而是AI带来单开发者产出提高和更多机器生成的工作，促使开发工具定价逐渐从单纯的人类席位转向席位加Agent及用量收费。对于Jira、Confluence、CI/CD自动化和DevSecOps来说，这一趋势至关重要。
EW
Ethan Wei
目前从公司来看，有哪些开发者工具算是胜出者，或者表现出了正在捕获这种AI价值的胜出迹象？比如预算反而在上升的那些，说明他们可能正在捕获这种Agent工作流（agentic workflows）的价值。
EX
Expert · Strategy Executive
我看到的比较明显的趋势可以分为两类：一类是实现AI编码（AI coding）商业化变现的工具；另一类则是享受到AI带来的下游工作流拉动效应（downstream workflow pull-through）的工具。 第一类最直接的代表是GitHub Copilot、Anthropic的Claude Code，以及Cursor这类AI原生编码工具。它们直接拉高了单开发者支出，因此即使开发者人数不增长，AI许可证和用量本身仍能持续增长。 第二类包括Atlassian、GitLab、Harness以及Red Hat的Ansible这类工作流和DevOps平台。因为AI编码生成了更多的代码和PR，后续必然会带来更多的代码审查（review）、测试、CI/CD、部署、安全扫描、工单处理和自动化需求。因此它们捕获的并非单纯的席位增长，而是工作流规模（workflow volume）的增长。 举个例子，Atlassian就是一个典型代表。即使工程人员编制基本持平，如果每位开发者管理的工程项目、工单、AI生成的变更以及Agent工作流都在增加，那么公司对Jira和Confluence这类记录系统（system of record）及工作流平台的支出价值就不会下降。Atlassian自身也在将Jira拓展为面向人类与Agent的统一工作管理层。 如果总结我目前最明确的判断：AI原生编码工具无疑是第一波受益者；而工作流、CI/CD自动化和DevSecOps则是第二波拉动效应的受益者。真正面临压力的是那些纯按人类席位收费、功能单一、且无法对Agent、自动化或用量进行商业化变现的开发者单点工具（point tools）。因为未来开发者席位增长可能会非常缓慢，但机器生成的工作负载增长会非常迅速。
EW
Ethan Wei
对于公司而言，像Salesforce和ServiceNow这类的支出以及捕获AI价值的方式发生了怎样的变化？在这些记录系统中，哪些可能是赢家，哪些可能是输家？“赢家”是指捕获了AI价值、预算可能不降反增或至少不会明显下滑的企业；而“输家”则是指预算出现明显削减、甚至正被替代的企业。
EX
Expert · Strategy Executive
我认为这与刚才讨论的DevOps逻辑非常相似，但我认为记录系统（System of Record）的防御壁垒反而更强。因为AI虽然可以改变交互层（interaction layer），但Agent要执行真正的企业工作流，最终仍必须在CRM、ITSM、ERP、HR等权威记录系统中进行读取和回写。因此，关键不在于AI是否会取代记录系统，而在于厂商能否将自身的记录系统升级为Agent的执行与编排层（orchestration layer），并从AI使用量中获得增量商业变现。 以公司自身的情况来看，Salesforce和ServiceNow都是非常明显的受益者。例如在Salesforce方面，我看到其正从传统的CRM席位支出，向“CRM + Data 360 + Agentforce + 用量”的模式扩展。因为Agentforce已经不再是按席位收费，而是可以按照操作（action）、Flex Credits、对话（conversation）或混合模式计费。
EX
Expert · Strategy Executive
比如其公开定价为500美元购买10万个Flex Credits，而一个标准的Agentforce操作大约消耗20个credits。所以即使未来 Sales 或 Service 的 human seats 没有明显增长，随着 agents 承担更多的 case resolution、customer interaction 和 record update，Salesforce 仍然拥有新的 monetization unit。此外，Salesforce 亦表示其智能体相关业务增长非常迅猛。 ServiceNow 则更为典型，它本身就是 workflow 的 system of record。AI agent 最终要处理的诸如 password reset、IT tickets 等各类员工请求，都需要回到这种 workflow system 来执行。ServiceNow 今年已将 AI、data connectivity、workflow execution、security 和 governance 更深入地整合进整体 portfolio 中，其 AI Control Tower 甚至可以治理 ServiceNow 体系之外的 agents。 如果支出方向仅作为一个方向性的管理层预估，而非精确的财务披露，我认为 2026 年在 Salesforce 上的支出增速大概在 10% 到 15%，ServiceNow 约为 15% 到 20%。这些增长并不完全来自员工席位的增加，而是来自 AI module、agent workflow consumption、data 以及 platform consolidation。至于所谓的受害者/输家，我不会断言大型 SOR 厂商会被 AI 取代。 目前公司真正缩减的是外围的 point workflow、ticketing、knowledge 以及 standalone automation tools。如果某款产品仅仅是为人类用户提供一个 UI，而底层的 record、workflow 和 data 都沉淀在 Salesforce 或 ServiceNow 中，那么 AI agent 普及后，这个额外的 UI 层的价值反而会缩水。因此当前的格局是：system of record 本身未必会被 AI 去中介化，相反，AI 更可能去中介化附着在 system of record 之上的 thin application layer。从长期来看，要实现双赢格局，厂商必须长期掌握权威的企业数据、拥有事务性工作流权限，并具备对 agent activity 和 consumption 进行计费的平台能力。Salesforce 和 ServiceNow 目前都在朝着这个方向演进；相反，那些仅有面向人类的界面、而缺乏核心数据与工作流所有权的 SaaS 单点解决方案，面临的预算削减压力会显著得多。
EW
Ethan Wei
在相同口径下，2025 年 Salesforce 和 ServiceNow 他们的同比增速分别是多少？您提到 2026 年 Salesforce 可能是 10% 到 15%，ServiceNow 是 15% 到 20%，那么 2025 年在同口径下两者的增速大概是怎样的？
EX
Expert · Strategy Executive
2025 年 Salesforce YoY 大概是 5% 到 8% ，到 2026 年加速到 10% 到 15%。ServiceNow 2025 年大概是 8% 到 12%，到 2026 年可能加速到 15% 到 20%。这只是看到内部的一个 spend direction 和一些 management estimate。 但背后的两个因素是：2025 年还是以 seat expansion、正常的 renewal、workflow expansion 以及一些 early GenAI add-on 为主；而到了 2026 年，更多会有类似 AI use cases 进入 production，开始增加一些 agent workflow consumption、AI module、data integration 和 governance 方面的支出。如果看中位值（midpoint）的话，我认为 Salesforce 2025 年大概是 7%，2026 年是 12%；ServiceNow 2025 年假设是 10%，2026 年就是 17%。这里最重要的信号不是某一个具体的百分点，而是两者都出现了 AI 驱动的支出加速（AI-driven spend acceleration）。而目前我认为 ServiceNow 的 push-through 相对来说可能更明显。
EW
Ethan Wei
公司愿意使用他们提供的 AI 功能，并且愿意为此直接支出吗？
EX
Expert · Strategy Executive
公司是愿意的，而且并不把这视为一项独立的 AI 功能。我的经验法则是，如果某项 AI 能力可以直接利用企业现有的数据、权限和工作流上下文，并执行具体操作，而不只是生成内容，那么企业更有可能购买其现有记录系统供应商提供的 AI 能力。这正是 Salesforce 和 ServiceNow 的优势所在：数据和工作流已经驻留在它们的平台上。
EX
Expert · Strategy Executive
所以在那个平台里面，AI Agent 可以直接做 case resolution、ticket triage、knowledge retrieval、workflow execution 以及 record update 等。因此 integration cost 和 time to production 通常比重新引入一个独立的 AI point solution 更低。但公司也不是 vendor AI by default，公司还是会比较它与自建及第三方 AI solution 在 model quality、cost per task、security governance 的 integration 以及 ROI 方面的表现。如果平台原生的 AI 能满足大概 80% 到 90% 的需求，通常公司会优先采用原生的 capability；只有当 capability gap 比较明显时，才会引入 best-of-breed solutions。
EW
Ethan Wei
那该公司未来是否会考虑为了节省这些支出，利用这些 system of records 去构建该公司自己的抽象层或功能套件，从而不再为 Agentforce 或 Now Assist 付费？
EX
Expert · Strategy Executive
我觉得未来确实会考虑，但公司的方向并不是自己把这种 system of record 重新做一遍，而是保留 SOR，对上层一些重复的 application 和 workflow spend 进行 consolidation。像 Salesforce、ServiceNow 已经掌握了 authoritative data、permission、workflow 和 API，公司完全可以在它们之上建立自己的 agent abstraction layer。用户未来不一定需要进入五六个不同的 SaaS UI，而是可以通过统一的 enterprise agent 发起请求，再由 agent 调用 Salesforce、ServiceNow 或其他 SOR 来完成 transaction。这样公司就可以逐步减少一些 standalone workflow、ticketing、knowledge search、basic automation 以及 thin application layer tools。 如果量化的话，我认为未来两到三年（maybe two to three years），这类外围 SaaS 即 point solution spend 大概有 10% 到 20% 的 rationalization opportunity，但并不一定会全部砍掉。省下来的资金也不一定会直接转化为 cost savings，其中一部分可能会重新投入到 SOR 的 AI module、agent platform、integration API、data layer 以及 security governance 中。因此最终可能会出现一个很有意思的现象：application 的 vendor count 下降，但 Salesforce、ServiceNow 等核心 SOR 的 wallet share 反而上升。对公司而言，目标并非单纯少花钱，而是从众多 human-facing applications 转向更少的 system of record 加上一个 common agent interaction layer。