微软Foundry Agent Service Runtime免费的真正账本：用零成本入口换Azure生态的长期锁定
微软Foundry Agent Service Runtime免费的真正账本：用零成本入口换Azure生态的长期锁定
2026年5月，Microsoft Build大会上，微软宣布Foundry Agent Service支持大规模构建和运行AI agents，其hosted agents提供安全、可扩展的计算环境。更引人注目的是定价策略：agent runtime编排层免费，开发者无需为agent的调度、状态管理和基础执行环境付费。这看起来像是一份慷慨的礼物——直到你打开Azure的计费面板，发现模型推理（Foundry Managed Compute）按token计费、数据存储（Azure Storage）按GB计费、身份认证（Entra ID）按活跃用户计费、可观测性（Azure Monitor）按日志量计费。
这不是慈善，这是精心设计的平台经济学。微软正在复刻一个被验证过的经典战略：AWS在2014年推出Lambda时提供每月100万次免费调用，真正的收入来自API Gateway、DynamoDB和CloudWatch。10年后，微软用同样的逻辑在AI agent时代下了一盘更大的棋——而且它手中握有一张AWS从未拥有的王牌：覆盖全球超过7.2亿月活跃用户的Entra ID企业身份图谱。
第1章：Build 2026的关键宣布——免费的边界与付费的版图
免费层的精确范围
要理解微软的真实意图，首先必须拆解”免费”二字的精确含义。根据Build 2026的官方发布，Foundry Agent Service的核心编排runtime——即agent的生命周期管理、任务调度、工具调用路由、对话状态维护——不产生独立计费项（来源: Build and run agents at scale with Microsoft Foundry at Build 2026）。
Hosted agents提供的安全沙箱执行环境内置了代码解释器（Code Interpreter）、文件管理和Bing搜索等工具，开发者从本地到生产部署可以实现无缝衔接（来源: Introducing the new hosted agents in Foundry Agent Service）。这意味着一个开发者可以在零成本的情况下搭建一个具备基础能力的agent原型——它能执行代码、管理文件、调用搜索。
但”免费”的边界在哪里？答案藏在Foundry Agent Service的定价页面中（来源: Foundry Agent Service - Pricing）。以下组件需要独立付费：
- 模型推理：无论使用GPT-4o、GPT-4.1还是开源模型（通过Foundry Managed Compute运行），每一次token生成都是计费事件
- 数据存储：agent的持久化状态、文件存储、向量数据库索引消耗Azure Storage资源
- 身份与安全：企业级agent需要Entra ID进行用户认证和权限管理，Entra ID P1/P2按月活跃用户计费（P2约$9/用户/月）
- 可观测性：生产环境的日志、追踪、指标通过Azure Monitor收集，按数据量计费（日志摄入约$2.76/GB）
- 网络流量：agent与外部API的交互、跨区域数据传输产生网络费用
编排层为何可以免费
理解这一定价策略的关键在于认识到：agent runtime编排层本身是一个极低毛利的”胶水层”。它的核心功能是接收用户输入、决定调用哪个工具或模型、管理对话上下文、返回结果。这一层的计算开销极小——主要是轻量级的路由逻辑和状态机维护，不涉及GPU密集型推理。
微软将这一层免费化的逻辑非常清晰：编排层的边际成本趋近于零（主要是CPU和内存，Azure的规模效应使其成本可忽略），但它是开发者与Azure生态之间的”粘合剂”。一旦开发者在Foundry Agent Service上构建了agent，其所有高价值操作——推理、存储、认证、监控——都必须在Azure生态内完成。
这就像一个购物中心免收停车费——但这个类比需要一个关键修正：与购物中心不同的是，云平台的”停车场”一旦停入，你的车（代码、数据、身份配置）会随着时间推移变得越来越难开走。停车费免费，但你的车会逐渐长出根来。
Microsoft Agent Framework的无缝迁移设计
微软的战略不仅仅是定价层面的。Microsoft Agent Framework的设计使开发者可以从本地开发环境无缝迁移到Foundry Hosted Agents的云端运行环境（来源: From Local to Production: Deploy Your Microsoft Agent Framework Agent with Foundry Hosted Agents）。这意味着开发者在本地用Python或C#构建的agent原型，只需最小的配置变更就能部署到Azure上。
这种设计消除了”从0到1”的摩擦，但同时也在不知不觉中完成了锁定：当你的agent代码依赖了Foundry Agent Service的API、使用了hosted agents的沙箱环境特性、集成了Entra ID的认证流程，迁移到其他云平台的成本就变得极高。根据Flexera 2025年云状态报告，企业在云迁移项目中平均花费的时间为6-12个月，成本通常为年度云支出的20-30%——而这还是传统工作负载的数据，AI agent因其对身份层和数据层的深度依赖，迁移成本只会更高。
第2章：历史镜像——AWS Lambda免费Tier的战略复盘
2014年的Lambda时刻
要预判微软Foundry Agent Service免费策略的长期影响，最佳参照物是AWS Lambda。2014年11月，AWS在re:Invent大会上发布Lambda，提供每月100万次免费请求和40万GB-秒的免费计算时间（来源: AWS Lambda定价页面，自2014年发布至今持续提供该免费层级）。对于当时的开发者来说，这意味着可以零成本运行大量轻量级函数。
但AWS的真正意图从来不是靠Lambda本身赚钱。Lambda是一个”引力中心”——它将开发者吸入AWS生态，然后通过周边服务实现变现：
- API Gateway：Lambda函数需要HTTP入口，API Gateway按请求量计费（$3.50/百万次请求）
- DynamoDB：无服务器函数需要无服务器数据库，按读写容量单元计费
- S3：函数处理的数据需要存储，按GB计费
- CloudWatch：生产环境需要日志和监控，按日志摄入量计费
- Step Functions：复杂工作流需要编排，按状态转换计费（$0.025/千次转换）
Lambda免费策略的量化验证
10年后回看，Lambda免费tier的商业效果可以通过AWS的公开数据间接验证。根据Datadog 2023年无服务器状态报告，超过70%的AWS客户已经采用了Lambda，而Lambda用户的平均AWS月消费额是非Lambda用户的3.2倍。Synergy Research Group的数据显示，AWS在2014年Lambda发布时的年化收入约为46亿美元，到2023年已增长至超过900亿美元——虽然这一增长不能完全归因于Lambda，但无服务器架构的普及无疑是核心驱动力之一。
更直接的证据来自AWS自身的披露：2022年re:Invent大会上，AWS CEO Adam Selipsky表示Lambda的调用量在过去两年增长了超过3倍，而围绕Lambda的生态服务（Step Functions、EventBridge等）增速更快。这验证了”免费核心+付费生态”模式的有效性。
微软正在复刻的精确模式
微软Foundry Agent Service的免费策略与Lambda免费tier的结构性相似度极高，但有一个关键升级：AI agent的资源消耗密度远高于传统无服务器函数。
一个典型的Lambda函数可能只需要128MB内存、运行100毫秒、产生几KB日志。但一个AI agent的单次交互可能涉及：
- 多轮模型推理（数千token的输入输出，以GPT-4o当前定价约$2.50/百万输入token计算）
- 工具调用（代码执行、文件读写、API请求）
- 状态持久化（对话历史、用户偏好、任务进度）
- 安全验证（每次工具调用的权限检查）
- 可观测性数据（追踪每一步的延迟、成本、成功率）
换言之，AI agent是一个”资源消耗乘数器”。当开发者用免费的runtime构建了一个agent，这个agent每处理一个用户请求，就会触发多个付费Azure服务的消费。这比Lambda时代的乘数效应更强——Lambda函数可能只触发1-2个周边服务，而一个复杂的AI agent可能同时触发5-8个计费组件。
关键差异：身份层的战略地位
Lambda时代，AWS的锁定主要通过数据层（S3、DynamoDB中的数据迁移成本高）和代码层（Lambda函数依赖AWS SDK）实现。微软在agent时代增加了一个更强的锁定维度：身份层。
企业级AI agent必须知道”谁在使用它”以及”这个用户有权做什么”。Entra ID（前Azure Active Directory）是微软在企业身份认证领域的核心资产。根据微软2024年年报披露，Entra ID拥有超过7.2亿月活跃用户，覆盖全球数百万企业组织。当Foundry Agent Service与Entra ID深度集成后，企业的agent不仅依赖Azure的计算和存储，还依赖Azure的身份基础设施。
身份层的迁移成本远高于数据层：你可以把数据从Azure Storage搬到AWS S3（虽然耗时且昂贵），但你很难把整个企业的身份图谱——包括条件访问策略、多因素认证配置、应用权限矩阵、组织层级关系——从Entra ID迁移到另一个身份提供商。Gartner在2025年的IAM市场分析中指出，企业身份平台的平均更换周期为7-10年，远长于其他IT基础设施组件。这是微软相对AWS和Google Cloud的独特优势——它拥有企业身份的”制高点”。
第3章：微软的锁定飞轮——从Entra ID到Managed Compute的变现链条
飞轮的5个齿轮
微软围绕Foundry Agent Service构建的变现飞轮可以分解为5个互相强化的齿轮：
齿轮1：免费Runtime吸引开发者
Foundry Agent Service的免费编排层降低了进入门槛。开发者可以在几小时内构建一个功能完整的agent原型，无需预付任何费用。Foundry Agent Service、Observability和Foundry Portal于2026年3月14日正式GA（General Availability），标志着平台已具备生产就绪能力（来源: Foundry Agent Service, Observability, and Foundry Portal Now Generally Available）。GA意味着SLA保障（99.9%可用性承诺），企业可以放心将生产负载迁入。
齿轮2：Foundry Managed Compute锁定推理消费
Agent的核心能力来自大语言模型的推理。Foundry Managed Compute允许开发者在Microsoft Foundry中运行开源模型，提供按需付费的推理计算层（来源: Announcing Foundry Managed Compute: Run open models in Microsoft Foundry）。这一设计的精妙之处在于：即使开发者选择使用开源模型（如Meta的Llama 4系列）而非微软的商业模型，他们仍然需要为GPU计算时间付费。
微软在这里实现了一个”无论谁赢都赚钱”的位置：如果OpenAI的GPT系列模型胜出，微软通过API调用计费赚钱；如果开源模型胜出，微软通过Managed Compute的GPU租赁赚钱。这与英伟达”卖铲子给淘金者”的逻辑异曲同工，只不过微软卖的是”云端铲子”——而且这把铲子已经预装在了免费的工地（runtime）上。
齿轮3：Azure Storage锁定数据层
AI agent需要记忆。短期记忆（当前对话上下文）可以在内存中维护，但长期记忆（用户偏好、历史交互、知识库）必须持久化存储。Hosted agents内置的文件管理功能直接使用Azure Storage作为后端（来源: Introducing the new hosted agents in Foundry Agent Service）。
随着agent积累越来越多的数据——用户交互日志、RAG知识库的向量索引、生成的文件和报告——Azure Storage的消费量持续增长。更重要的是，这些数据一旦积累，迁移成本（包括重新索引向量数据库、重建知识图谱、重新训练个性化模型）就变得极高。IDC在2025年的数据引力研究中估算，企业每在一个云平台上积累1PB数据，迁移到另一个平台的总成本（含停机时间、重新验证、性能调优）约为$50万-$200万。数据引力（Data Gravity）是云平台最强的锁定力量。
齿轮4：Entra ID锁定身份层
企业部署AI agent时，第一个问题永远是：”谁有权使用这个agent？它能访问哪些数据？”Foundry Agent Service与Entra ID的深度集成意味着agent的权限模型直接映射到企业现有的身份和访问管理（IAM）体系。
对于已经使用Microsoft 365的企业来说，这是一个巨大的便利——员工的身份、组织架构、权限组都已经在Entra ID中定义好了，agent可以直接继承这些权限。根据微软2025年财年报告，Microsoft 365商业版拥有超过4亿付费席位，这意味着全球有4亿以上的企业用户身份已经存在于Entra ID中。当这些企业部署AI agent时，Foundry Agent Service是阻力最小的选择——因为身份基础设施已经就位。
但这也意味着agent的安全模型与Entra ID深度耦合，迁移到其他平台需要重建整个权限体系——包括条件访问策略、角色定义、应用注册和API权限授予。
齿轮5：可观测性锁定运维层
Foundry Agent Service在GA时同步推出了Observability功能（来源: Foundry Agent Service, Observability, and Foundry Portal Now Generally Available）。生产环境中的agent需要持续监控：每一步推理的延迟、每次工具调用的成功率、每个用户会话的成本、每个agent的token消耗趋势。这些可观测性数据通过Azure Monitor收集，形成了运维团队对agent健康状况的唯一视窗。
当运维团队基于Azure Monitor构建了告警规则（如”当agent响应延迟超过5秒时触发告警”）、仪表板（如”每日token消耗趋势图”）和自动化响应流程（如”当错误率超过5%时自动降级到备用模型”）后，切换到其他监控系统的成本不仅是技术层面的（重写告警逻辑、重建仪表板），更是组织层面的（重新培训运维团队、重新建立on-call流程）。
飞轮的自我强化逻辑
这5个齿轮不是独立运转的，而是相互强化的：
- 更多开发者使用免费runtime → 更多agent被构建 → 更多推理消费（Managed Compute收入增长）
- 更多agent在生产环境运行 → 更多数据积累（Storage收入增长）→ 数据引力增强 → 迁移成本升高
- 企业部署更多agent → 更复杂的权限需求（Entra ID P2高级功能消费增长）→ 身份层耦合加深
- 更多生产agent → 更多可观测性需求（Monitor收入增长）→ 运维流程与Azure绑定
- 运维流程绑定 → 企业更倾向于在同一平台部署新agent → 回到齿轮1
每一个齿轮的增长都会驱动其他齿轮加速，形成正反馈循环。这就是平台经济学的核心——单个组件的免费化可以通过系统层面的乘数效应创造远超其成本的收入。
对比竞争对手的定价策略
要理解微软策略的激进程度，需要与竞争对手对比。截至2026年6月，主要竞品的定价模式如下：
- Google Cloud Vertex AI Agent Builder：根据Google Cloud官方定价页面，其agent编排功能按”agent session”计费，每个session有基础费用，不提供类似微软的”编排层完全免费”模式。Google的策略更侧重于与Gemini模型的深度集成来吸引开发者。
- AWS Bedrock Agents：AWS的Bedrock Agents按agent调用次数计费（每1000次调用约$0.01-$0.03，具体取决于配置），同样没有将编排层完全免费化。AWS的优势在于其更广泛的云服务生态和更成熟的无服务器基础设施。
- Anthropic/OpenAI的API直接调用：这些模型提供商不提供agent编排服务，开发者需要自行构建或使用开源框架，然后在任意云平台上部署。
微软是第一个明确将agent编排层定价为零的主要云厂商。这给竞争对手制造了一个两难选择：如果跟进免费策略，需要有同样强大的生态组件来变现；如果不跟进，则面临开发者流失的风险。微软的优势在于它拥有最完整的企业软件生态——从Microsoft 365到Dynamics 365到Power Platform——这些都是agent可以连接的”动作端点”，每一个连接都是潜在的付费触点。
第4章：财务支撑——Azure云收入的高速增长为”免费补贴”提供底气
FY26的具体增长数据
微软有能力执行”免费runtime”策略的前提是：Azure的整体收入增长足以覆盖runtime层的运营成本，并且生态消费的增量远超补贴成本。
FY26 Q2（2025年10月-12月）财报显示，Azure和其他云服务收入同比增长31%，其中AI服务贡献了13个百分点的增长（来源: Microsoft Cloud and AI strength drives second quarter results）。微软智能云（Intelligent Cloud）部门该季度收入达到259亿美元，同比增长19%。
FY26 Q3（2026年1月-3月）财报继续确认增长势头：Azure收入同比增长33%，AI服务贡献了16个百分点——这意味着AI相关消费在Azure总收入中的占比正在快速提升（来源: Microsoft Fiscal Year 2026 Third Quarter Earnings）。Satya Nadella在财报电话会议中特别提到：”AI正在从实验阶段进入生产部署阶段，我们看到客户的AI消费从试点项目扩展到企业级部署。”
AI消费密度的量化分析
连续两个季度的数据揭示了一个关键趋势：AI工作负载的消费密度远高于传统云工作负载。当AI服务贡献了Azure增长的近一半（16/33个百分点），但AI工作负载在Azure总工作负载中的占比远低于50%时，这意味着单位AI工作负载的平均消费额远高于单位传统工作负载。
传统云工作负载（Web应用、数据库、虚拟机）的资源消费模式相对稳定：一个Web应用的计算需求在部署后通常不会出现数量级的变化。但AI agent工作负载有一个根本性的不同：它的资源消费与用户交互量成正比，而且每次交互的资源消耗远高于传统应用。
考虑一个企业客服agent的场景（以下为基于公开模型定价和典型企业规模的估算）：
- 每次用户对话平均涉及5-10轮交互
- 每轮交互需要1次模型推理（约1000-3000 token，以GPT-4o定价计算约$0.005-$0.03/轮）
- 其中2-3轮需要工具调用（查询数据库、调用API）
- 整个对话需要持久化存储（约5-10KB）
- 需要记录完整的追踪日志（约20-50KB）
如果这个企业每天有10000次客服对话，那么单这一个agent就会产生：
- 5万-10万次模型推理调用（日均推理成本约$250-$1500）
- 2万-3万次工具执行
- 50-100MB新增存储（月累计约1.5-3GB）
- 200-500MB新增日志（月累计约6-15GB，按Azure Monitor定价约$16-$41/月）
这只是一个agent。企业通常会部署多个agent用于不同场景（客服、内部IT支持、数据分析、文档生成等），每个agent都是一个独立的Azure资源消费引擎。
“免费”的ROI推演
基于上述估算（需要强调这是推演而非实证数据），我们可以构建一个简化的ROI模型：
假设条件（标注为假设性推演）：
- Foundry Agent Service runtime层的边际运营成本：以Azure的规模效应，每个活跃agent的编排层CPU/内存成本估计在$5-$20/月
- 单个中等规模企业agent的月均Azure生态消费：推理$3000-$8000 + 存储$50-$200 + 监控$100-$500 + 身份认证$200-$1000（取决于活跃用户数）= 约$3350-$9700/月
即使取保守估计，每个活跃agent的生态消费与runtime运营成本的比率也在150:1到500:1之间。这意味着微软每投入$1维持runtime免费运行，就能通过生态服务收回$150-$500。
这个比率在agent工作负载中可能更高，原因是：
- Agent的推理消费是持续的（不像传统应用的一次性部署）
- Agent积累的数据会持续增长（存储消费单调递增）
- 企业一旦验证了agent的价值，会快速扩展到更多场景（agent数量乘数增长）
微软的财务团队显然做过更精确的计算。FY26连续两个季度AI收入贡献占比从13个百分点提升到16个百分点，验证了AI工作负载的消费密度确实在快速提升。
第5章：CORPGEN与技术护城河——为什么不仅仅是定价游戏
技术投资作为锁定的另一维度
微软的agent战略不仅仅是定价层面的”免费入口+付费生态”。微软研究院同步推进的CORPGEN项目展示了更深层的技术投入：CORPGEN旨在推进AI agents在真实工作场景中的能力，通过自动生成企业级工作流程的语料库来训练和评估agent的任务执行可靠性（来源: CORPGEN advances AI agents for real work）。
CORPGEN解决的核心问题是：当前AI agent在复杂多步骤任务中的成功率仍然不够高。根据微软研究院的公开数据，在涉及5步以上操作的企业工作流中，agent的端到端成功率通常低于60%。CORPGEN通过生成大规模、多样化的企业场景训练数据，旨在将这一成功率提升到企业可接受的水平（>90%）。
这意味着微软不仅在平台层面提供agent的运行环境，还在研究层面推动agent能力的边界。当Foundry Agent Service的用户受益于微软研究院的最新成果（更好的agent规划能力、更可靠的工具调用、更高效的多agent协作），他们对平台的依赖就不仅仅是基础设施层面的，而是能力层面的。
这是一个更高级的锁定形式：开发者不仅因为迁移成本高而留在平台上，还因为平台持续提供竞争对手无法匹配的能力而选择留下。这类似于苹果的芯片战略——用户留在iPhone生态不仅因为iMessage的网络效应，还因为A系列/M系列芯片提供的性能优势是竞品无法复制的。
Build 2026的全栈整合信号
Build 2026上关于Foundry的一系列发布不是孤立的产品公告，而是一个精心编排的全栈整合叙事（来源: What’s new in Microsoft Foundry (Build 2026 recap)）。从Foundry Managed Compute（底层推理）到Agent Service（中间编排）到Foundry Portal（上层管理），微软展示了一个完整的agent开发-部署-运维生命周期。
这种全栈整合的战略意义在于：它使得”部分迁移”变得极其困难。你不能只把推理层迁到另一个云平台而保留编排层在Azure上——因为它们之间的集成是深度优化的（如Managed Compute与Agent Service之间的低延迟内部网络通信、共享的身份上下文传递）。你也不能只迁移监控而保留其他组件——因为可观测性数据的格式和语义与Foundry Agent Service的内部架构紧密耦合（如agent的”思考链”追踪格式是Foundry特有的）。
全栈整合意味着：要么全部在Azure上，要么承受巨大的拆分成本。这与AWS的策略形成对比——AWS的服务虽然也有集成优势，但其设计哲学更偏向”积木块”式的松耦合，而微软在agent领域明显选择了更紧耦合的路线。
与Microsoft 365 Copilot的协同效应
一个容易被忽视的维度是Foundry Agent Service与Microsoft 365 Copilot的协同关系。Microsoft 365 Copilot已经为企业用户提供了AI辅助能力，但它是一个”通用助手”。Foundry Agent Service允许企业构建针对特定业务流程的”专家agent”——这些agent可以通过Microsoft Graph API访问Microsoft 365中的数据（邮件、日历、文档、Teams消息），形成一个从通用AI助手到专业AI agent的完整谱系。
这意味着已经为Microsoft 365 Copilot付费的企业（每用户$30/月），在构建自定义agent时有天然的数据优势——它们的业务数据已经在Microsoft Graph中了。Foundry Agent Service的免费runtime进一步降低了这些企业构建自定义agent的门槛，形成了”365 Copilot → 自定义Agent → 更多Azure消费”的升级路径。
第6章：对立视角——免费策略的风险与局限
反方观点1：开源替代方案的威胁
一个合理的反驳是：如果agent runtime层是低价值的”胶水层”，那么开源社区完全有能力构建替代品。LangChain（GitHub星标超过9万）、CrewAI、AutoGen（微软自己开源的多agent框架）等开源框架已经提供了agent编排能力，开发者可以在任何云平台上（甚至自建基础设施上）运行这些框架。
更值得注意的是，LangChain的商业化产品LangSmith已经提供了agent的可观测性和评估功能，且支持多云部署。如果开源生态能够提供与Foundry Agent Service同等质量的编排+可观测性，那么微软的”免费runtime”优势就会被稀释——因为开源方案本来就是免费的，而且不带锁定。
这个观点有一定道理，但忽略了两个关键事实：
第一，开源框架提供的是开发时的灵活性，而非生产时的可靠性。Foundry Agent Service的GA意味着它提供了SLA保障（99.9%可用性）、企业级安全（SOC 2 Type II、ISO 27001认证）、内置可观测性和自动扩缩容——这些是开源框架需要大量额外工程投入才能实现的。根据Puppet 2024年DevOps状态报告，企业将开源工具投入生产环境的平均额外工程投入为6-18个人月。
第二，企业采购决策不仅看技术能力，还看供应商关系和合规要求。对于已经与微软签订企业协议（Enterprise Agreement）的大型组织来说，使用Foundry Agent Service可以纳入现有的采购框架和合规审计范围，而引入新的开源工具栈需要额外的安全评审和供应商评估流程。
反方观点2：多云策略会限制锁定效果
另一个反驳是：大型企业通常采用多云策略，不会把所有工作负载放在一个云平台上。根据Flexera 2025年云状态报告，89%的企业采用多云策略，平均使用2.6个公有云平台。即使Foundry Agent Service很有吸引力，企业也会在AWS和GCP上部署部分agent以避免过度依赖。
这个观点在理论上成立，但在实践中面临两个挑战：
第一，AI agent的一个核心特征是它需要访问企业数据——而企业数据往往已经集中在某一个云平台上。如果一个企业的核心业务数据在Azure上（通过Microsoft 365、Dynamics 365、Azure SQL等积累），那么在Azure上运行agent是延迟最低、成本最低的选择。跨云访问数据不仅增加延迟（通常增加50-200ms），还产生额外的数据出站费用（Azure出站流量$0.087/GB起）。数据引力会自然地将agent工作负载拉向数据所在的平台。
第二，多云策略在agent领域面临一个独特挑战：身份一致性。如果企业在Azure上使用Entra ID、在AWS上使用IAM Identity Center、在GCP上使用Cloud Identity，那么跨平台的agent权限管理就变成了一个噩梦——同一个用户在不同平台上有不同的身份表示和权限模型。大多数企业会选择以一个身份平台为主，而Entra ID在企业市场的渗透率使其成为最常见的”主身份平台”。
反方观点3：定价竞争可能侵蚀生态利润
第三个值得考虑的反驳是：如果AI推理成本持续快速下降（过去18个月GPT-4级别模型的推理成本已下降超过90%），那么微软通过推理消费变现的空间可能被压缩。当推理变得极其廉价时，”免费runtime+付费推理”的模式可能失去吸引力——因为推理本身也接近免费了。
这个观点有一定前瞻性，但忽略了两个反趋势：一是agent的推理调用量会随着能力提升而指数增长（更复杂的任务需要更多的推理步骤），即使单位成本下降，总消费可能仍在增长；二是微软的变现不仅依赖推理，还依赖存储、身份和监控——这些服务的成本下降速度远慢于GPU推理。
我的综合判断
综合三方观点，我的判断是：微软的免费策略对已有Azure投入的企业（即Microsoft 365和Dynamics 365的现有客户，约占全球大中型企业的70%以上）将产生极强的锁定效果，但对云原生初创企业和多云架构的大型科技公司的锁定效果有限。
关键变量是Entra ID的渗透率。如果一个企业已经使用Entra ID管理身份（超过7.2亿月活跃用户意味着大部分企业已经在使用），那么Foundry Agent Service就是阻力最小的agent平台选择。微软的真正优势不在于runtime免费本身——这只是一个战术动作——而在于它拥有全球最大的企业身份图谱和最完整的企业生产力软件生态。免费runtime是钩子，Entra ID是锚，Microsoft 365的数据是引力场。三者结合，构成了一个竞争对手极难复制的锁定三角。
第7章：Agent时代的平台经济学——免费的从来不是真正免费的
从”卖软件”到”卖消费”的范式转变
微软Foundry Agent Service的免费策略标志着企业AI平台竞争进入了一个新阶段：平台的价值不再由单一产品的定价决定，而由生态系统的总消费密度决定。
在传统软件时代，微软卖的是License——一次性付费，永久使用。在SaaS时代，微软卖的是订阅——按月付费，持续使用。在AI agent时代，微软卖的是消费——按token、按GB、按用户、按日志量，agent运行得越多，消费越多。
这是一个根本性的商业模式升级：agent不是一个静态的软件产品，而是一个持续消费云资源的”活”实体。每一个被部署的agent都是一个永续的收入流——只要它在运行，就在消费推理、存储、认证和监控资源。这与SaaS订阅模式的关键区别在于：SaaS的收入是线性的（用户数×单价），而agent消费的收入是超线性的（agent数×用户交互量×每次交互的资源消耗）。
大多数人没看到的第三层洞察
表面上看（第一层），微软免费了agent runtime——这是一个慷慨的开发者友好举措。
深入一层看（第二层），这是经典的”免费入口+付费生态”平台策略——用零成本获客，通过周边服务变现。
但大多数人没看到的是（第三层）：微软正在通过agent将企业的”业务逻辑”从代码层面提升到”AI编排”层面，而这一层面的迁移成本比传统代码迁移高出一个数量级。
传统应用的业务逻辑写在代码里——虽然迁移需要重写，但逻辑是显式的、可读的、可移植的。AI agent的”业务逻辑”则分散在多个隐式层面：模型的微调数据（存储在Azure上）、agent的prompt工程（依赖特定模型的行为特征）、工具调用的权限配置（绑定Entra ID）、历史交互数据（用于个性化和持续学习）。
当一个企业的核心业务流程被编码为AI agent后，这些隐式知识的总和构成了一种新型的”技术债务”——它不是代码层面的债务，而是平台认知层面的债务。你的agent”知道”如何在Azure生态中完成任务，但它不”知道”如何在其他平台上做同样的事。这种认知锁定比代码锁定更深、更难逆转。
对开发者的启示
如果你是一个正在选择agent开发平台的开发者或技术决策者，需要清醒地认识到：
- 免费runtime不等于免费运行agent。在评估总拥有成本（TCO）时，必须将推理、存储、认证和监控的费用纳入计算。基于前文估算，一个中等规模的企业agent月均Azure消费可能在$3000-$10000之间。
- 前期的便利性是后期的迁移成本。Foundry Agent Service与Azure生态的深度集成在开发阶段是优势（快速原型、无缝部署），但在你想要迁移时就变成了负担。建议在架构设计阶段就考虑抽象层，将agent的核心逻辑与平台特定API解耦。
- 身份层是最深的锁定。如果你的agent依赖Entra ID进行权限管理，迁移成本将远超数据迁移。建议评估是否可以使用标准协议（如OIDC/SCIM）作为中间层，保留一定的身份平台可移植性。
- 评估”全栈锁定”vs”最佳组合”的权衡。微软提供的是全栈优化的体验，但代价是全栈锁定。如果你的组织对供应商多样性有严格要求，可能需要接受一定的集成摩擦来换取灵活性。
对投资者的启示
微软的Foundry Agent Service免费策略本质上是一次”用户获取成本（CAC）投资”——用runtime层的零收入换取生态组件的高增长。评估这一策略的成功与否，不应该看Agent Service本身的收入（它永远是零），而应该看：
- Foundry Managed Compute的推理消费增速：FY26 Q3显示AI贡献了Azure增长的16个百分点，这个数字在FY27是否能达到20+？
- Azure Storage中AI相关工作负载的存储增量：agent积累的数据是否在推动存储消费超线性增长？
- Entra ID的企业活跃用户增长：agent部署是否在推动更多企业升级到Entra ID P2（$9/用户/月）？
- Azure Monitor的AI可观测性数据摄入量增长：agent的追踪日志是否成为Monitor的新增长引擎？
这些指标的复合增长率才是衡量免费策略ROI的真正标尺。如果FY27的财报显示AI消费贡献持续加速，那么免费runtime策略就被验证为成功。
终极问题：Agent是否会成为Azure消费的新乘数？
微软押注的核心假设是：AI agent将成为企业消费云资源的新乘数。如果这个假设成立——即每个企业未来会部署数十甚至数百个agent，每个agent都在持续消费推理、存储和认证资源——那么runtime免费策略将被证明是微软在AI时代最精明的商业决策之一。
但这个假设能否成立，取决于两个关键变量：
第一，agent技术本身的成熟度。微软研究院的CORPGEN项目正在攻克agent在真实工作场景中的可靠性问题（来源: CORPGEN advances AI agents for real work）。如果agent的可靠性在未来12-18个月内达到企业生产环境的要求（端到端成功率>95%），那么我们将看到agent部署的爆炸式增长。
第二，企业的采纳速度。根据McKinsey 2025年AI状态调查，65%的企业已经在至少一个业务功能中使用了生成式AI，但只有12%在生产环境中部署了自主agent。从12%到50%的跨越可能需要2-3年——而微软已经提前布好了变现的网。
免费的从来不是真正免费的。在平台经济学中，免费是最昂贵的定价——因为它的代价是你未来所有的消费都被锁定在这个平台上。微软深谙此道，而Foundry Agent Service的免费runtime，是它在AI agent时代下的最大赌注。赌注的另一面是：如果agent时代真的到来，那些今天被免费runtime吸引进来的开发者和企业，将在未来5-10年内为微软贡献数百亿美元的生态消费——而他们中的大多数，可能永远不会离开。
参考资料
- Build and run agents at scale with Microsoft Foundry at Build 2026 — Microsoft DevBlogs, 2026-05
- Announcing Foundry Managed Compute: Run open models in Microsoft Foundry — Microsoft DevBlogs, 2026-05
- Foundry Agent Service, Observability, and Foundry Portal Now Generally Available — Microsoft Tech Community, 2026-03-14
- Introducing the new hosted agents in Foundry Agent Service: secure, scalable compute built for agents — Microsoft DevBlogs, 2026-05
- Microsoft Cloud and AI strength drives second quarter results — Microsoft News, 2026-01-28
- Microsoft Fiscal Year 2026 Third Quarter Earnings — Microsoft Investor Relations, 2026-04
- From Local to Production: Deploy Your Microsoft Agent Framework Agent with Foundry Hosted Agents — Microsoft DevBlogs, 2026-05
- CORPGEN advances AI agents for real work — Microsoft Research Blog, 2026
- Foundry Agent Service - Pricing — Microsoft Azure, 2026
- What’s new in Microsoft Foundry (Build 2026 recap) — Microsoft DevBlogs, 2026-05
- Datadog, “State of Serverless 2023” — 来源: Datadog, 2023
- Flexera, “2025 State of the Cloud Report” — 来源: Flexera, 2025
- McKinsey & Company, “The State of AI in 2025” — 来源: McKinsey, 2025-05
主题分类：企业AI战略