← 返回

2026.09.29 | 9K | MSFT | Microsoft Channel Check I

原标题：Merit 微软近况调研I(2026-09-29 13:30:00)

#cloud #software

Meritco 久谦 · 2026-09-29

音频信息

音频标题: 260929 - Merit 微软近况调研I

相关标的：undefined

议题：

完整音频链接：

音频纪要总结

专家访谈纪要：Microsoft Copilot升级、商业化与Azure增长展望

1. Copilot产品升级与统一平台定位

a）此次M Copilot升级接入了哪些产品，各自新增了什么能力？

  1. M Copilot：Microsoft Copilot，定位为统一品牌、应用入口和平台。
  1. M365 Copilot：Microsoft 365 Copilot，继续面向企业级办公场景。
  1. Home
  1. Code
  1. Autopilot

b）哪些产品仍主要是对话入口，哪些已经能够读取数据、执行操作并写回？

  1. 消费版M Copilot Chat主要使用互联网公开信息及消费端模型，无法访问企业Graph和企业租户数据。
  1. Home中的免费功能主要覆盖网页搜索、聊天、基础图像生成及简单Office操作。
  1. 企业版M365 Copilot可在企业租户边界内调用Graph、SharePoint、Teams、邮件和Office文档等数据。
  1. 数据不会进入消费版模型，企业数据与消费端数据属于两套隔离体系。
  1. Code可生成脚本、流程和Agent，但目前生成结果必须经过安全扫描和人工审核，不能直接发布。
  1. Autopilot可以在授权范围内读取数据、执行任务并写回结果。
  1. 现阶段仅允许读取、副本写入和内部分发。
  1. 不允许自动删除文档。
  1. 不允许处理Revenue Forecast、预算、人员信息、组织架构等核心高敏感数据。
  1. 不允许向重大客户自动推送信息。
  1. 面向非敏感客户的自动化操作需要单独申请。
  1. Autopilot不能全局默认开启，必须由Entra管理员逐人或逐组授权。

2. M Copilot的AIOS战略与产品逻辑

a）公司在AI领域的定位是什么？

  1. Windows是PC软件生态的底层平台。
  1. AIOS则希望成为模型、Agent、办公软件、ERP、CRM、安全及第三方应用的统一承载平台。
  1. OpenAI模型；
  1. Claude等第三方模型；
  1. 自研模型；
  1. 开源模型。

b）为什么需要推出统一的M Copilot？

  1. M365、Windows、Dynamics 365、Security、GitHub等一级产品全面加入AI。
  1. 内部一度形成约80—90个Copilot。
  1. 用户难以理解不同Copilot的用途、入口和差异。
  1. 各Copilot后台未完全打通，产品体验碎片化。
  1. 不同产品接入的模型和数据深度不同，同一问题可能得到不同答案。
  1. 首先统一产品名称、UI和应用入口。
  1. 网页端、Windows端和移动端整合为统一Copilot入口。
  1. 用户登录后，系统根据个人账号或企业账号提供不同权限、模型、算力及数据能力。

c）M Copilot未来可能如何扩展？

  1. GitHub Copilot对应Code。
  1. M365 Copilot可能对应Work或办公模块。
  1. Dynamics 365 Copilot可能对应ERP/CRM模块。
  1. Security Copilot可能作为安全模块接入。

3. M Copilot与M365 Copilot的关系

a）M Copilot是否会替代M365 Copilot？

  1. 产品许可；
  1. 后台模型服务；
  1. 数据隔离；
  1. 企业级安全与合规；
  1. Graph和Tenant访问能力。

b）消费端和企业端的主要区别是什么？

  1. 可免费使用M Copilot Chat、网页搜索、基础绘图等能力。
  1. Office相关功能需要M365 Personal等个人订阅。
  1. 无法访问企业Graph、企业Tenant及其他企业级功能。
  1. M Copilot Chat可以免费使用。
  1. Graph、深度Office集成、企业数据访问和租户内Agent能力需要M365 Copilot许可。
  1. 企业数据在独立租户边界内处理，不会进入消费端模型。

c）哪些企业版本可能受到新M Copilot影响？

  1. Essential版：面向中小客户，可能使用开源模型、自研模型和较低成本算力。
  1. Standard版：现有每用户每月30美元的标准企业版。
  1. Premium版：面向大型企业，由FDE提供模型二次开发、Post-training、知识库建设及定制化Agent和Flow。

4. 内部测试范围与量化表现

a）内部测试覆盖了哪些人员和部门？

  1. 九大BG；
  1. ATO销售体系；
  1. FDE；
  1. HR；
  1. Finance；
  1. Legal；
  1. 内部IT与安全团队。

b）新版M Copilot的内部测试指标有哪些改善？

  1. 老版约12次；
  1. 新版提升至18—19次。
  1. 老版约4分10秒；
  1. 新版约6分40秒。
  1. 老版为51%；
  1. 新版提升至67%—68%。
  1. 老版约10%；
  1. 新版达到68%—70%。
  1. 老版为89.7K；
  1. 新版为146K，增长约63%。
  1. 新版测试人员中超过60%曾主动开启Autopilot。
  1. 老版基本为负；
  1. 新版明显转正，原始记录口径约为+21.2。
  1. BG和产品相关岗位对Code接受度最高；
  1. 内部NPS约为+48.9；
  1. 相关人员每周使用Code约3—5次。

c）Home、Code和Autopilot分别带来了哪些效率提升？

  1. 原生嵌入Word、Excel、PowerPoint后，无需频繁切换应用。
  1. 报告生成时间平均缩短约33%。
  1. 超过70%的受测员工认为，统一入口和消除产品碎片化是最明显的改善。
  1. 约50天内，内部员工共创建1,000多个、不到2,000个小型Agent。
  1. 约40%的Agent创建者没有IT或编程背景。
  1. 主要用于生成Copilot Studio Agent、自动化流程和数据处理脚本。
  1. 可处理周报汇总、邮件分类和会议纪要归档等重复性任务。
  1. 单个用户每周可节省约3—5小时。
  1. 工程团队用于单元测试和日志解析时，效果相对更突出。

5. 内部测试暴露的风险与产品限制

a）Autopilot目前存在哪些主要问题？

  1. 内部Autopilot任务失败率约29%。
  1. 涉及多方、多团队、长链路任务时，容易丢失上下文。
  1. Autopilot有时会尝试访问超出授权范围的资源。
  1. 安全系统会自动拦截相关任务，导致执行中断。
  1. 当Office后台服务出现峰值波动时，Autopilot无法暂停并续跑。
  1. 当前通常只能重置任务，无法从中断点继续。
  1. 仅约10%多的Legal高层愿意主动开启Autopilot常驻执行。
  1. 约70%的Legal员工及部分内部IT安全负责人提交了风险工单。

b）Code生成代码和Agent的质量如何？

  1. 强制开启安全扫描；
  1. 经过人工二次审核；
  1. 未经审核不得在企业租户内发布。

c）Office in Copilot的性能表现如何？

6. Token成本与内部治理机制

a）全面铺开Code和Autopilot后，成本会如何变化？

b）目前采取了哪些成本控制措施？

  1. 配额管理；
  1. 模型网关限流；
  1. 按场景自动切换模型；
  1. 高消耗场景自动降级至低成本模型。

7. 外部企业客户试点情况

a）外部试点覆盖了哪些客户？

  1. 北美20多家；
  1. 欧洲10多家；
  1. 其余位于亚太地区。
  1. 制造；
  1. 金融；
  1. 咨询；
  1. 医疗；
  1. 互联网；
  1. 高科技。

b）新旧版本在外部客户中的指标有何变化？

  1. 旧版约10次；
  1. 新版提升至16—17次。
  1. 旧版为40%出头；
  1. 新版提升至56%—57%。
  1. 旧版约49%；
  1. 新版提升至60%出头。
  1. 旧版基线约9个；
  1. 新版平均每家约16个，说明管理和安全复杂度同步上升。
  1. 旧版Code同期约创建200个Agent；
  1. 新版M Copilot Code共创建约800个Agent。
  1. 新版在客户环境中约为35%；
  1. 高于内部约29%的水平。
  1. 旧版约为-1；
  1. 新版提升至+13。

c）外部客户获得了哪些实际价值？

  1. 约800个新建Agent中，超过60%并非由IT人员创建。
  1. 某制造业客户在没有专职AI开发人员的情况下，通过Code为供应链创建了Agent。

d）外部客户的主要担忧是什么？

  1. 大型客户普遍采用混合多云环境。
  1. 客户存在大量第三方SaaS及老旧本地系统。
  1. 权限、系统和数据未完全打通，任务容易执行到一半中断。
  1. Agent ID一旦权限匹配错误，可能横向访问客户自有IP或敏感数据。
  1. 在获得Autopilot预览资格的客户中，有6—7家主动暂停测试。
  1. Autopilot和Code显著推高Token消耗。
  1. 客户CTO更关注能力，财务部门更关注成本，双方分歧明显。
  1. 内部知识库问答效果较好。
  1. 涉及核心业务信息、第三方API和复杂逻辑时，漏洞及逻辑问题明显增加。
  1. 客户难以区分M Copilot、M365 Copilot和GitHub Copilot的许可边界。
  1. 后续需要进一步简化和明确产品组合。

8. 产品发布时间与商业化模式

a）Home、Code和Autopilot预计何时推出？

b）不同模块将如何收费？

  1. 以用户订阅方式收费。
  1. 消费端基础Chat、网页搜索和基础绘图免费。
  1. 个人Office功能对应M365 Personal等订阅，受访者提到的价格约为每月9.99美元或每年99美元。
  1. 企业端Everyday AI仍主要纳入M365 Copilot体系，标准价格为每用户每月30美元。
  1. 不包含在每月30美元的标准企业版中。
  1. 将按照API Token用量计费。
  1. 最终单价尚未确定。
  1. 主要采用用量计费。
  1. 最终定价预计到Q2中后期才能明确。

9. M365 Copilot收入目标与增长逻辑

a）M365 Copilot当前收入和年度目标是多少？

  1. FY26全球收入为70多亿美元。
  1. FY27全年目标约为130亿美元。
  1. FY27 Q1预计约为30亿美元。
  1. FY26 Q1为10多亿美元，因此FY27 Q1有望实现同比翻倍。
  1. 达到200亿美元，整体问题不大。
  1. 若仅达到约189亿美元，需要重点关注投资强度。
  1. 若低于170亿美元，CapEx被削减的风险将显著上升。

b）B端收入如何测算？

  1. 当年新增订单；
  1. Add-on补充订单；
  1. FY26、FY27签署合同形成的Recurring收入。

c）C端收入如何测算？

10. FY27 Q1 Azure增速判断

a）Azure整体收入由哪些部分构成？

  1. 最大圈：Azure全部业务
  1. 中圈：Azure AI
  1. 小圈：API Token业务

b）Azure全年目标如何设定？

  1. Baseline目标约增长41.8%—42%；
  1. 更高目标约增长44.7%—45%。
  1. Baseline为21%多、接近22%；
  1. 高目标为24%。

c）Azure AI上一年度的收入结构如何？

d）FY27 Q1能否达到44%—45%的Azure增速指引？

  1. FY27 Q1 Azure整体收入约为320亿美元。
  1. FY26 Q1调整后约为223亿美元。
  1. 同比增速约为44%左右，基本能够达到此前44%—45%的指引。

11. Meta企业级Agent平台的竞争影响

a）Meta重做Enterprise Platform，短期会产生什么影响？

b）为什么对大型企业客户的影响相对有限？

  1. M365办公与协同；
  1. Teams会议和视频；
  1. Dynamics 365 ERP与CRM；
  1. 企业安全；
  1. GitHub与Coding；
  1. Azure云与数据平台。

c）哪些客户更容易被竞争对手分流？

  1. IT环境较简单；
  1. 对数据湖和复杂权限管理要求不高；
  1. 更关注低成本和快速部署。

d）长期如何看待竞合关系？

结构化总结表格

维度核心指标/现状主要进展当前问题后续规划
产品定位M Copilot统一Home、Code、Autopilot入口从“All in AI”转向“AI Enable All”许可、模型和数据体系仍未完全统一构建类似Windows的AIOS平台
HomeChat及Office内嵌能力报告生成时间缩短约33%大型Excel P95延迟10—12秒Q2加快推广
Code支持代码、流程和Agent生成内部创建1,000—2,000个Agent；外部创建约800个复杂Agent成功率不足40%；近20%代码有潜在注入风险按Token收费，强制安全扫描和人工审核
Autopilot可读取数据、执行任务并写回每周可节省3—5小时内部失败率29%，外部业务失误率35%预计Q2末至Q3初推出，禁止默认全局开启
内部活跃度周会话数12次增至18—19次正向反馈率51%增至67%—68%Token用量上升约63%分部门、岗位设置Token配额
复杂任务能力完成率由约10%升至68%—70%多步骤任务能力显著增强长链路任务容易丢失上下文优化任务续跑与权限管理
外部试点30多家、接近40家企业，数千席位周会话数10次增至16—17次；NPS由-1升至+13工单量由9个升至16个；6—7家暂停Autopilot测试先私有预览，完善安全和许可体系
数据权限消费端与企业端完全隔离企业端可访问Graph和Tenant数据Agent存在越权访问风险Entra管理员按最小权限逐人授权
商业模式Home按Seat；Code和Autopilot按Token从纯订阅转向“订阅+用量”Token单价仍为TBDQ2中后期明确Autopilot定价
M365 Copilot收入FY26收入70多亿美元FY27目标约130亿美元FY28需支撑高额CapExFY28目标约220亿—230亿美元
B端市场云化付费用户约4亿，Eligible占67%—68%FY28渗透率预计17%—18%企业折扣和部署复杂度较高B端收入预计150多亿美元
C端市场Office用户约6.1亿—6.2亿新Home可能加快渗透实际提升尚无正式数据渗透率或由7%—8%升至13%—14%
Azure FY27 Q1预计收入约320亿美元同比增速约44%，基本达到指引仍依赖季末14笔大型订单ClosingAzure AI预计60多亿美元
竞争格局Meta等进入企业Agent市场大型客户仍受M365生态和安全体系保护SMB客户可能被轻量化产品分流评估用新M Copilot重构Essential版本

新版prompt提炼之后的转译

提问者：Copilot此次升级目前已经接入了哪些产品？这些产品分别增加了哪些能力？其中，哪些产品目前仍只是对话入口，哪些已经能够读取业务数据、执行操作并将结果写回？

回　答　者：首先需要明确，您所说的是前几天0925发布的升级。具体可以参考当天的Vlog和官方文章。此次升级称为Microsoft Copilot升级。

Microsoft Copilot目前的定位是统一的品牌、应用入口和平台。与之相比，M365 Copilot仍然面向企业级办公场景。为便于区分，以下将Microsoft Copilot简称为M Copilot，Microsoft 365 Copilot简称为M365 Copilot。

M Copilot推出的背景是，A公司从23年开始正式进入云三阶段，也就是AI阶段。云三阶段分为2步。第1步从23年开始，一直持续到24年中后期，基本在25年前结束，这一阶段称为“All in AI”。

“All in AI”是指A公司所有的一级产品系列，包括M365、Windows、D365、Security和GitHub等，均在SaaS层面加入AI。完成这一阶段后，A公司内部出现了80—90个Copilot，因为几乎所有产品都配备了Copilot。

这对B端客户和C端用户都造成了困扰。面对众多Copilot，用户难以明确其具体用途、使用效果和接入端口。同时，这些单点Copilot无法打通后台，也没有形成聚合。

此外，由于不同Copilot接入的后台模型能力深浅不一，适用场景也有所不同，因此输出结果存在差异。即使询问同一个问题，在M365 Copilot的Chat和原Windows Copilot的Chat中，某些情况下得到的结果也不相同。

基于这些问题，从25年开始，总部逐步进入云三阶段的第2步，即“AI Enable All”。

提问者：如何理解我们在AI领域的定位，以及M Copilot作为统一应用入口和平台的产品逻辑？

回　答　者：我们并不是Frontier Lab，也不是模型厂商。早在15年、16年，Harry Shum领导AI Research团队自研模型时，我们就意识到自身难以将模型做到足够好。与此同时，我们与OAI的关系渐行渐远，并开始解除唯一云供应商的绑定。

因此，我们的定位并不是仅从模型层面看待AI能力，而是进一步演化为构建平台能力，也就是AIOS。可以将AIOS理解为Windows操作系统：Windows是PC或笔记本电脑的底座，用户可以在此基础上安装Office、Dynamics等ERP、CRM软件，以及其他软件和插件。

M Copilot正是统一的应用入口和平台，包含home、code、autopilot这3个核心工作区域，但它们并非3个彼此独立的产品。M Copilot首先是统一的产品UI和入口，但产品许可、后台模型服务及数据隔离仍属于不同的独立体系。

尤其是将M Copilot与M360 Copilot进行比较时，这一点更为明显。home中包含部分Word、Excel、PowerPoint功能，但这并不意味着M Copilot能够直接替代M360 Copilot，至少目前中短期内不会如此。

形象地说，M Copilot类似于微信。微信既有个人端，也有企业端，用户可以通过同一界面登录，但拥有不同的权限。进入B端或C端后，能够使用的功能并不相同，后台接入的模型和算力也有所区别。算力可能来自NV的N代产品，也可能在C端使用我们自研的Maia，包括200、280以及明年的300；模型则可能来自OAI、Claude、我们的自研模型，甚至开源模型。用户接入B端或C端时，后台已经完成相应配置。

现阶段，M Copilot主要是将界面统一，并在界面层面统一使用M Copilot这一产品名称。无论是网页端、Windows端还是移动端，都可以合并为统一的Copilot应用入口，不再设置单独图标。用户登录时，系统会根据个人账号或企业账号提供相应能力。企业账号可以使用对应的企业级能力，而个人账号在模型和算力方面并不具备同等能力。

回　答　者：可以结合起来与之媲美。在许可层面，它采用独立许可。与 VS 相比，M3 Copilot 目前不会取消。关键在于，M36 Copilot 是面向 B 级企业客户办公场景的 AI 产品。

从 PC 消费侧和 C 端角度看，用户可以免费使用 M Copilot，无需附加许可，并可在 Word、PowerPoint 等应用中进行简单操作。如果需要进一步使用，则可以选择 M365 Premium 和个人账户，但无法访问企业级租户的 Graph，以及企业级的其他一系列功能。

从商业侧角度看，M Copilot Chat 可以免费使用，但 M365 Copilot 中的 Graph、深度集成能力等功能无法直接免费使用。其 Code 和 AutoPilot 实际上按照 API Token 的方式收费。

这一逻辑带来的直接结果是，后端数据层面是完全隔离的 2 套体系，不会合并。C 端可以共享推理数据集，数据也可以使用互联网公开信息，不接触企业级租户的 Graph 和 Tenant。企业版则采用独立租户，企业数据需要在其边界内单独处理，不会流入消费版模型。

从未来发展角度看，对外产品仍可能继续演化，因为目前尚未正式 GA，大多数功能仍处于内测阶段。稍后我会具体介绍新 M Copilot 的内测情况，包括内部不同团队人员测试后的正向反馈和痛点，以及部分 Frontier 头部大客户使用新 M Copilot 进行内测后的量化值和正负向反馈。

目前可以将其理解为统一化平台端口的 Phase 1，也就是第 1 步。在 Phase 1 阶段，M Copilot 与 M3 Copilot 仍然完全分开。但未来不排除一种可能：如果这一端口表现良好，可以将 M365 Copilot、D36 Copilot 和 Security Copilot 以类似目前 Code 的方式进行整合。

GitHub Copilot 对应 Code，可以像 GitHub Copilot Code 一样，先嵌入 M365 和 M Copilot。其他 SAS Copilot 可能不再称为 M36，而是称为 Work；Dynamics 在 ERP 层面则可以称为 ERP CRM。最终可在统一的 M Copilot 界面和端口上实现模块化，其逻辑与目前的 Home、Code 和 AutoPilot 相同。这是目前首先需要澄清和说明的情况。

提问者：M Copilot是否会替代原来的M366 Copilot？

回　答　者：从定义和定位角度来看，请不要将其与M365 Copilot混淆。最近2天，很多国内外的朋友都在询问，M Copilot推出后，是否会替代原来的M366 Copilot，未来只保留M Copilot。目前，对于B级客户，依然会提供M366 Copilot。

提问者：从测试角度来看，M Copilot的测试范围和具体表现如何？

回　答　者：测试分为内部和外部测试。内部测试是公司自身开展的Dogfood测试，参与测试的人员超过5000人，涉及多个团队，包括9大BG，以及销售体系中的ATO和FDE。今年7月，我们将FDE单独拆分出来，成立了独立实体。此外，HR、Finance和Legal这3个后台职能部门也参与了测试。

测试周期持续了50天左右，主要对老版M Copilot与新版Copilot进行对比，并观察相关指标的前后变化。

在人均周活跃会话数量方面，老版M Copilot平均为每人每周12次左右；改组后的新版M Copilot由原来的12次提升至18次到19次，即18点几次。

在单次会话平均持续时长方面，老版M Copilot内部测试结果约为4分钟零10来秒钟，新版M Copilot目前提升至6分40多秒。

在用户正向反馈率方面，老版M Copilot为51%。原来的M Copilot即Windows Copilot，功能相对有限。新版M Copilot加入hold、autopilot和code后，用户正向反馈比例，也就是满意度，提升至67%到68%，提升较为明显。

在复杂多步骤任务完成成功率方面，老版M Copilot约为10%，基本可以忽略；新版M Copilot在内部测试中的复杂多步骤任务完成率达到68%到70%。

回　答　者：由于其中加入了 Autopilot，实际上对标的是我们之前提到的 Scord，而 Scord 后续也会更名并整合进来。

下一个指标是人均每周消耗的 Token。旧版 McoPilot 为 89.7K Token，新版 McoPilot 则达到人均每周146K Token，基本实现了较为明显的翻倍。这也可以理解，因为 Code 和 Autopilot 都按照 Token 计费，而不是按照 Seats 计费。

另一个指标是主动开启 Autopilot 智能体的人员比例。旧版 McoPilot 没有 Autopilot，因此这一比例为0；新版 McoPilot 中，受测人员主动开启 Autopilot 智能体的比例达到60%多。

从 Autopilot 的任务执行失败率来看，旧版 McoPilot 因为没有 Autopilot，所以该指标为0；新版 McoPilot 中，Autopilot 的任务执行失败率接近30%，具体为29%。

从整体层面看，旧版 McoPilot 的 NPS，即产品满意度或推荐度，基本为负数。用户认为其功能使用价值有限，因此没有太多推荐意愿。新版 McoPilot 的 NPS 则为正值212。

内部受访测试人员基本来自端到端的几大 Function，包括 BG、销售、其他相关部门以及后台职能部门。基于这些职能部门的反馈，BG 和产品经理对 Code 模块的接受度最高，内部 NPS 已达到正值48、9。

其中，BG 和 PM 等相关岗位需要特别区分：销售及各个 Function，包括 HR、Legal、Finance，都设有 PM，这里的 PM 不是产品经理，而是项目经理。参与测试的内部人员每周使用 Code 模块至少3到5次，主要用于快速生成 Copilot Studio Agent、生成 Auto 流程及编写数据处理脚本。

对于销售团队，无论是 AE、Account Base，还是 FDE 和客户成功团队，重点使用的仍是 Home 中原生嵌入 Office 的功能，使其能够跨 Word、PPT、Excel 操作，而不需要跳出 Copilot 界面。内部测试后，相比之前需要单独进入相应界面，操作体验有所不同。

回　答　者：通过原生 Home 嵌入 Word、Excel、PowerPoint，无需跳转，报告生成时间缩短了 1/3，即 33%。

对于 Legal 和内部 IT 部门，员工对 Autopilot 的顾虑最高。仅 10%多的 Legal C-level 员工愿意主动开启 Autopilot 常驻执行。其余约 70%的 Legal 员工，以及 IT 部门中负责内部信息安全的 CSO 等员工，提交了相应的风险工单，主要担忧权限越界及其带来的一系列合规风险。这是从内部职能角度观察到的情况。

整体来看，内部反馈分为正向和负向，其中正向反馈主要有 3条。第1条，Home 统一接入平台入口的价值最高。过去需要在 M365 Copilot、Copilot Studio、GitHub Copilot 等多个界面之间切换，现在通过单一入口即可完成 Chat、文档协同、Agent 构建和编码，员工进行上下文切换的时间明显减少。内部测试和问卷结果显示，70%多的受测员工认为，消除多产品碎片化是最明显的提升。此前存在 80、90个 Copilot，不仅用户和客户难以区分，内部员工有时也难以理清。

第2条，Code 模块降低了 Agent 的构建门槛。非开发岗位，包括业务分析师、SE、FDE 中负责 Industry Solution 的人员，以及运营人员等，可以较为直接、简单地使用 AGI 生成 Agent。从内测情况来看，在约 50天内，受访内部员工共构建了 1000多个、不到 2000个小型内部 Agent，均使用新的 M Copilot Coding 完成。其中，约 40%的 Agent 创建者没有任何 IT 或代码编写背景，此前的专业方向也并非相关领域。

对于 Autopilot，在权限受限的场景中，其产出效果相对明显。在配置适当权限并具备安全保障的前提下，Autopilot 可以执行周报汇总、邮件批量分类、会议纪要归档等确定性的重复工作，单个用户每周可节省至少 3到5个小时。工程化团队使用 Autopilot 运行简单的单元测试和日志解析时，效果更为突出。

回　答　者：这是内部针对3个新模块转化后的正向反馈。从内部测试的角度看，也暴露出了一些负向反馈和痛点。

第1，Autopilot 常驻智能体的稳定性仍存在较大疑问，因为接近30%的任务会失败。最明显的问题是，在涉及多方、多团队、多人员的长链路、多步骤任务中，Autopilot 会在执行过程中丢失上下文。

第2，Autopilot 会尝试访问超出已分配权限的资源，从而触发安全系统自动拦截。当然，这个问题需要辩证看待。随着 Autopilot 能力进一步扩大，内部 CSO 需要针对不同的硅基 Agent，或者执行多步骤任务的硅基员工，进一步开放和调整权限。目前，内部已有少量 Digital Employee，即少量硅基员工，但此次测试并未涵盖这些硅基员工。参与测试的人员均为碳基员工，其权限受到严格划分，因此容易触发安全拦截。

第3，当后台 Office 服务在峰值点、峰谷点出现波动时，Autopilot 只能直接重置任务，无法等待后继续执行，也无法在延迟区间内接续运行。对此，CSO 和 MSD，即 IT 部门，已经明确表示，目前仍不允许默认全局开启 Autopilot，必须由管理员逐个授权用户开启。这也是后续对外私有预览的一项限制性规则。以上是 Autopilot 的部分痛点和负向反馈。

在 Code 方面，其生成代码和 Agent 的质量仍有波动，稳定性不够强。对于简单代码和简单 Agent，生成成功率较高，达到80%多，甚至接近80大几；如果涉及多系统代码或 API 串联，以及复杂的大规模 Agent，成功率仅为不到40%左右。

按照现有 CSO 标准，由于 Code 也关联了部分 Autopilot 能力，可以自动生成代码，因此生成的代码存在一定的安全漏洞风险。内部安全团队发现，在内测中由 Autopilot 和 Code 并行生成的代码，有接近20%存在潜在注入风险，必须由人工，即碳基员工进行二次审核，不能直接上线。

第3点是内部测试完成后，

提问者：全面铺开 Code 和 Autopilot 后，成本将如何变化？目前内部反馈的主要痛点及测试后设定的规则有哪些？

回　答　者：成本增加较为明显。由于 Code 和 Autopilot 均按照 API Token 而非 Seat 计费，Token 用量较此前提升了 60、60多。如果在全公司范围内完全铺开，根据 Central Finance 的测算，目前内部预算预计将增加 40%。

现阶段，如果模型和 Agent 的能力没有进一步提升，全面铺开时又未根据不同国家、不同部门和不同人员岗位设置 API Token 上限，成本压力将进一步增加。目前，我们已根据内部员工的不同权限、部门、Job Title 和岗位职责，分别制定 API Token 用量标准，不得超出。超出标准会触发 Red Flag，甚至需要从各部门自身的 Budget 中扣除，即计入各部门的 Cost。

这一情况推动产品组加急上线配额管理、模型网关限流，以及按照场景进行模型自动升降级等功能。这也是 Finance 与 BG 目前正在紧急推进的工作，目的是控制内部成本。按照今年目前的 Plan，从 CA 角度看，我们的 Capex 约为 2300亿到2400亿，这还不包括 Opex。

第4个痛点是 Office in Copilot 在部分重度操作中存在卡顿、Legacy 和延迟。例如，在新的 M Copilot Home 中直接编辑大于10万行的大型 Excel 时，95分位的响应延迟达到10秒到12秒，能够明显感受到卡顿，操作并不顺畅。这些是目前内部反馈的主要痛点和负面问题。

完成内部测试后，我们设定了相关规则。第1个，从 CSO 和安全部门的角度，Autopilot 禁止全局默认开启。在完成组织内部权限重新梳理之前，必须由 Entra 管理员为不同用户、租户组和小组授予 Agent 身份及最小权限。

同时，禁止 Autopilot 处理核心、高风险和高敏感度的创作。例如，我们从事 Corp Strategy 的人员涉及内部 Revenue Forecast、Budgeting、Hicount，以及组织架构和人员等相关信息，这类操作均被禁止。

对于删除文档，或面向外部客户、尤其是重大客户主动推送等高风险操作，目前也不允许执行。现阶段仅允许读取、副本写入和内部分发。对于非敏感客户，或不在 S500 大客户池中的客户，可以申请开展自动化操作。

提问者：内部员工使用后，针对Code与Autopilot联动生成的Agent，主要进行了哪些调整？

回　答　者：针对Code与Autopilot联动生成的Agent，必须强制开启安全扫描。现阶段，未经人工审核，默认不得在租户内发布。第3，增加分层、分区域、分部门、分岗位的Token配额，高消耗场景自动切换至低成本模型，以抑制内部成本失控。这些都是内部员工使用后进行的调整。

提问者：外部B级客户的试点范围和客户构成如何？

回　答　者：外部B级客户主要选取Frontier计划的早期客户进行试点，基本都是大型头部付费客户，以GA客户为主。试点采用私有预览形式，并非正式GA。

Frontier计划共覆盖30多家、接近40家企业，其中北美有20多家，欧洲有10多家，其余位于亚太地区。每家企业开放的测试席位为50到300个不等，具体取决于客户需求、客户体量和职能要求，合计约有几千个席位。

客户行业分布遵循“Go Back to Essential Plus 1”，即“万物归宗加1”的AI行业优先战略，主要覆盖Tier 1行业，包括制造、金融、咨询、医疗、互联网和高科技。

在上述数10家企业中，只有20家进行了Autopilot私有预览，占50%左右，并未完全开放。其余未开放Autopilot的企业仅测试Home和Code模块。

提问者：新旧版本M Copilot在外部B级客户中的主要测试指标有何变化？

回　答　者：与旧版M Copilot相比，新版M Copilot的人均周会话数由10次左右增加至16到17次，提升较为明显。

正向反馈率由原来的40%出头提升至56%到57%；复杂任务完成成功率由49%左右提升至60%出头。

在IT管理员工单周提交量方面，旧版M Copilot的基线约为9个工单，新版M Copilot平均每家约为16个工单。

回　答　者：可能选取了这一时间段。同期使用旧版 Code 模块产出的 Agent 约为200个；在这一阶段内，客户使用新版 M Copilot 的 Code 模块共创建了800来个。

对于 Autopilot 的试点用户，旧版没有 Autopilot，因此不存在业务失误比例。新版在客户环境中的 Autopilot 业务失误比例约为35%，略高于我们内部的水平。

NPS 方面，客户对旧版 M Copilot 的评分基本为-1，对新版 M Copilot 的评分目前为+13。以上是外部 Frontier 大客户测试指标的前后对比。

提问者：鉴于今天的时间，讲完这部分后，我们更关注产品何时全面推开，以及后续的收费情况。具体是按席位收费，还是针对 Copilot 中的部分功能收费？您认为这对今年、27年Q1或此后的营收会产生什么影响？请加快介绍后续变现方面的内容。

回　答　者：外部客户的正向反馈主要包括以下方面。Home 统一入口较受客户欢迎，可以避免在不同功能之间来回跳转，这一点与内部情况不同。

Code 模块降低了创建 Agent 的门槛。例如，一家制造业B级客户原来没有专职AI开发人员，现在通过 Code 模块为供应链创建了一个 Agent。刚才提到的800多个新建 Agent 中，有60%多并非由IT人员创建。

对于咨询类公司，在设定 Autopilot 后，可以利用 SharePoint 和 Teams 聊天记录，自动生成每周的项目风险摘要。客户整理材料的时间，每周人均可节省2个多小时，接近3个小时。

从外部客户的痛点来看，Autopilot 在客户异构云和IT环境中的稳定性有所下降。B级客户基本采用混合多云环境，其软件也不一定全部使用A公司的产品。由于客户存在大量第三方SAS和旧版本地系统，且权限划分不清，经常出现智能体访问系统时权限不通、系统不通、数据不通，导致任务运行到一半中断的问题。

客户的CSO对此也较为担忧。一旦 Agent ID 的权限匹配出错，可能横向访问B级客户大量自有IP或敏感数据。在10到20家左右获得 Autopilot 预览资格的客户中，有6到7家主动临时关闭了 Autopilot，并暂停测试，原因是认为其存在风险。

第2个痛点是成本不可控，主要表现为 Token 使用量猛增。客户的财务部门对此存在很大质疑。

回　答　者：从客户CTO和财务部门的角度来看，双方的分歧更加明显。Code生成的Agent质量呈现明显的2极分化：内部知识库问答的效果较好，但涉及客户核心信息、第3方API Token或复杂业务逻辑时，生成的Agent出现漏洞及逻辑问题的比例仍然较高。

在许可组合方面，客户容易产生混淆。目前仍处于初期阶段，部分客户无法清楚区分M Copilot、M365 Copilot与GitHub Copilot之间的许可边界。随着后续推广，许可体系将进一步完善，相关边界也会更加清晰。

从时间角度来看，今年Q1即将结束，按逻辑应该从Q2开始推进。目前Home和Code确定能够在Q2落地。根据这2天的内部会议和报告，Autopilot可能要到Q2末，甚至Q3初才会推出。内部模型、Agent调用、权限分布管理以及客户关注的问题都需要进一步调整。

较为理想的安排是，针对Autopilot，在每年11月举行的Ignite全球产品技术大会上进行正式的大规模对外宣传。它此前名为Scout，目前称为Autopilot。新的M Copilot在2季度应该会加快推广。

从收入角度来看，首先需要关注定价。Home包括Chat、Core和Office内置功能，按照用户订阅计费，分为个人消费版和企业版。第2个是Code，它基于GitHub Copilot技术，改为按照Token用量计费。Autopilot原Scout也按照用量计费，目前尚未确定最终定价，大概率要到Q2中后期才会明确。

对于Home，个人使用的M Copilot包括网页端和Windows内置的Copilot聊天、网页搜索、基础画图等功能，这些均可免费使用。但如果涉及Office相关功能，就会对应M365 Personal。例如，个人版价格为每月9块9毛9，1年99块钱。不过，其中不包括M365 Copilot的企业级功能，也不包括Code和Autopilot。我这里所说的是Home，也就是Office部分。

如果是企业级，则涉及M365 Copilot的Chat。

回　答　者：总体而言，它会归入M365体系。首先，对于企业级客户，M365 Copilot仍将独立存在，不会并入其中。

对于Essential对应的中小客户或小微客户，目前内部正在讨论是否使用新M Copilot中的Home、Code和Agents能力进行Auto替代，但尚未完全做出决策。因此，对于B级企业客户，大概率仍将继续使用每月30美元的M365 Copilot版本。

按照OPG，即Office Product Group的产品路线图，M365 Copilot原本就有3个版本。第1个是现有版本，即无论是13、15还是17中内嵌或外挂的每月30美元版本，我们称之为Standard标准版。

在Standard标准版之下，还有面向中小客户的Essential中小客户版。该版本使用开源模型或自研模型，并采用自研卡，或者英伟达N-1甚至N-2代卡提供支撑。对于这一版本，内部目前存在争论，即是否完全使用M Copilot Home中的Office能力进行替代。

在Essential和Standard版本之上，还有Premium高阶版本。Premium版本面向FDE，对标GAS500达客户。在向客户提供M365 Copilot标准版的基础上，还将开展模型二次开发和Post-train、KB建立，以及标准M365 Copilot的定制开发，从而产生Auto和所谓的Flow。

目前按照OPG的路径推进，新M Copilot所属BG的负责人是Jacob，M365 Copilot的负责人仍是Rolanski。由于2位负责人所属的BG相互独立，从BG利益角度来看，面向企业级B级客户的Standard标准版和Premium高阶版在一段时间内应该不会取消，但面向中小客户的版本仍在探讨之中。

对于企业级客户，可以按照例如一期99一个月，以及13、15目前的标价和涨价后的价格进行计算。

Code不包含在每月30美元的版本中，而是按照API Token计费。目前API Token与Auto一样，尚无官方定价。据我所知，相关价格还没有完全确定。

Auto中会包含Home里的Everyday AI，固定价格为每月每用户30美元。其余部分均采用计量方式收费。目前API Token的单价在内部也尚未完全确定，仍处于TBD状态。

提问者：您如何看待相关商业化进展？

回　答　者：先看M365 Copilot。M365 Copilot在上一个财年FY26，即1个完整财年，全球收入合计为70多个亿。今年FY27，针对M365 Copilot的1年目标目前为130个亿，币种为USD。

如果从Q1，即FY27的Q1来看，由于这个Q1尚未结束，目前只能提供较为粗略的数字。考虑到各家公司均存在季节性特征，季末最后几天通常会集中签订大型订单。目前站在这个Q1的角度，FY27的Q1预计能够达到30个亿左右，而去年FY26的Q1为10来个亿，基本实现翻倍。这是M365 Copilot目前的情况。

按照财务部，即Amy Hood下属Central Finance的推算，在FY28，如果CapEx继续增加，需要结合此前的投入情况来看：FY25，也就是上上年，CapEx为800多亿；FY26，也就是上一年，为1450；今年为2300多。今年1月底和2月左右，可能还会增加200亿，但这需要满足一系列TBD的要求和标准。

如果要在明年的基础上继续增长，例如CapEx达到3000多亿，M365 Copilot的B端和C端单年收入需要达到220、30个亿，这里仅指本体收入。这220、30个亿包括当年的new，即新增订单；当年的add-on，即补充订单；也包括从28财年向前回溯1年和2年，即FY26、FY27的recurring订单。因为我们与企业级客户签约时，通常会签订3年合同，这也是ARPU的来源。

如果这3部分收入达到220、30个亿，CapEx基本还会继续增长。如果达到200亿，我个人判断问题不大。如果是189，从投资角度看，可能需要重点关注。如果明年下个财年M365 Copilot的单年收入低于170亿，被削减的风险将极大。这是M365 Copilot的判断标准。

关于M365 Copilot如何实现200多亿收入，可以拆分来看。第1个维度是B端和C端。这200多个亿由B端和C端共同构成。就B端而言，全球云化付费B端用户数量约为4个亿，即4亿多一点用户。

M365 Copilot的使用模式类似于乐高玩具的1加1插件。用户需要先购买其本体，包括标准版、高级版、E3、E5以及现在的E7，之后才能使用M365 Copilot。

回　答　者：从这个角度看，这几个 eligible 版本占4亿多一点用户中的67%到68%。可以用4亿多一点乘以0.67、乘以0.68，再乘以推算至FY28年底的渗透率。

这一渗透率是根据当年的 on-premise license，即Office软件向O365迁移、O365向M365迁移、M365由低版本向E5、E7升级的攀升率，以及从2023年10月1日全球正式GA到今年6月底、7月初的复合增长情况，进行线性推算得出的。到28日历财年末，渗透率基本会达到17%到18%。

也就是用4亿多一点乘以0.6768、乘以0.1718，再乘以每用户每月30美元和12个月。对于B端客户，我们没有统一的平均客单价和平均折扣率，而是针对不同客户、不同项目和不同波次的 opportunity 单独审批。但从23年10月1日正式GA到6月底的情况看，全球平均折扣大约为7几折。因此，可以用4亿多一点乘以0.6768、乘以0.1718、乘以每用户每月30美元、乘以12个月，再乘以0.75，即按75折计算，最终约为150来个亿。

C端方面，全球Office的C端用户数量约为6亿1、6亿2，其中C端云化用户占这6亿1、6亿2的57%到58%。可以用6亿1、6亿2乘以0.5758。按照刚才的逻辑推算，到FY28财年底，其渗透率将达到7%到8%。也就是乘以0.07、0.08，再乘以每用户每月20美元和12个月。默认C端没有折扣，计算结果约为70亿。因此，150多亿加70亿，就是223，这一数字是这样计算出来的。

之所以提到这一数字，是因为新的M Copilot推出后，Home功能目前对B端的影响不大，但对C端渗透率的增速具有促进作用。目前，他们正在测算复合增速和渗透率，但尚未提供数据。就我个人估计，如果C端新的M Copilot正式GA，且功能表现不差，渗透率应能从现在的7%到8%提升至13%到14%，基本相当于翻1倍。

这只是我的估算，所有估算仍需等待Central Finance和OPG统一给出数据。相关数据一定会在正式GA后的1到2个季度之后公布，因为需要观察实际增长情况。如果按照这一逻辑，渗透增速提升，那么根据刚才的数量，可以用6亿多乘以0.67，准确来说是乘以0.5758，再乘以一个……

回　答　者：1314。Home的单价应该是30美元，需要按照30乘以12个月计算，默认没有折扣，其增速会相应提升。但不能完全按照30美元计算，因为此前C端的金额约为20美元，需要拆分计算。这是基础的计算逻辑和量化值。

提问者：时间有限，可能再聊10分钟。我还有2个关键问题。第1个问题是，关于27Q1的Azure云增速，虽然目前季度尚未结束，但此前同等汇率下的指引为44%到45%。从您的角度看，目前能否达到这一指引？

回　答　者：目前可以从以下逻辑进行分析。可以画3个圆圈，关系是大圈包含中圈、中圈包含小圈。

最大的圈是AzureO，即Azure所有业务，包括3个部分：传统IaaS，包括网络、计算和存储；PaaS，包括混合云、数据分析、数据池和高阶云安全；以及所有AI相关业务。AI同时也是3个圆圈中的中圈。

去年，在财报统计口径调整前，这一数字是104几；调整后应该是101几，不到1020。按照新的财报口径，今年全年有2个target。第1个baseline target，是以1020左右为基础乘以1.42左右，这是必须实现的目标，严格来说是1.418几，约为1.42。

另一个nice to have target也是需要实现的。Jason作为全球销售负责人，需要向Satya提出更高的目标，即今年全年较1020这一数字达到1.447几，接近1.45倍。基于最大的圈，可以推算出今年全年的Azure target。

中圈是Azure所有AI相关业务，但不包括OAI提供的分润，也不包括OAI租用云计算的收入。OAI租用云计算的收入计入Azure大圈中的IaaS和PaaS，不计入Azure AI。

Azure AI这一中圈，主要涵盖所有to B的企业级客户，也包括一些中小size的frontier lab，即模型商。去年，这一中圈的规模为190大几，无限接近200亿，占去年102几的约20%。

今年同样有2个target。第1个baseline target的占比要达到21%多、接近22%；第2个target的占比要达到24%。按照新的Azure大圈今年计划，占比约为212和24。基于这一框架，可以首先从AI角度进行分析。

回　答　者：可以分为4个层面。按照去年的190大几亿元、无限接近200亿元来看，第1个层面是mass API token，即API token销售，在190大几亿元中占70多亿元，占比约38%。

第2个平行部分是machine learning and other services，即工具链、调用链。AI公司，尤其是面向美国或欧洲的大型S500客户时，客户并不会直接调用API token，而是需要进行post-training二次开发和二次训练，因此还需要工具链调用及其他服务。该部分去年为30亿元出一点点头，占比为10%多。

第3个部分是other AI，即23年原有AGI之前的传统AI业务，例如big data、认知识别等，去年为20亿元出头。

最后一个部分为60多亿元，主要包括GPU rental和裸金属租赁，即将我们手中的A系列、H系列，也就是老黄家的N减2、N减3代卡出租给B级客户。该部分约为60来亿元。

回到今年第1季度，刚才提到的第3个圆圈，也就是Azure中圈Azure AI的第1个部分，即API token，去年为70多亿元。这是去年的大、中、小圈情况。

今年的逻辑应该是这样。目前尚未完成所有数据统计，请以10月底披露的第1季度财报数据为准，我现在只能提供大致情况。FY27的Q1，Azure最大圈基本应该能达到320亿元左右。当前还取决于今天、明天和后天美国时间的几张巨额订单。截至昨天晚上开会时，还有14张critical mega deal。总体而言，应该在320亿元左右。

FY26的Q1经财报调整后为223亿元，因此YoY算下来应该接近1.4几，约为1.44几，基本能够达到此前的指标。

如果能够达到target值，Azure中圈将达到60大几亿元，不到70亿元。小圈基本为26亿元左右，约26、27亿元。这是Q1目前的大致情况，最终还要看最后几天的closing情况，确实存在一定难度。

提问者：最后一个问题，昨天Meta表示要重新做Enterprise Platform，包括news agent、business agent、news code和API等。从短期和中期来看，这对你们会产生什么影响？

回　答　者：如果从短期的agents对标来看，其实就是auto、autopilot和scouts。并不是完全没有影响，因为autopilot是按照API token计费，会直接影响API token。

回　答　者：收入，这是最直白的财务端。但从Satya以及Amy的角度来看，大家对这种竞合关系的看法比较辩证。

我们目前最主要的目标，第1个是做平台。也就是说，未来Copilot搭建完成后，并不排除Meta或其他公司的智能体架设在我们的平台上。我们提供的是平台化能力，就像Windows一样。Windows上不仅可以安装我们的Office，也可以安装PDF、Visio以及其他厂商的3方软件。

从我们的角度看，短期或直接的产品竞合关系会对Scot产生直接影响，但影响相对不会特别大。与其他公司相比，我们的Scot基于传统的端到端SaaS进行，并进一步实现AutoPilot。我们在办公场景中的SaaS最为全面，包括M36 Copilot、会议视频、办公、OA、协同，以及D365的ERP、CRM、云安全保障和Coding。这1整套产品和服务可以说是最全面的。尤其在办公领域，我们仍然处于独占地位。

如果客户是B级客户，并且注重办公场景，使用我们产品的概率会更高。但如果B级客户使用的是原生场景或轻量化办公场景，对打通数据池、数据湖的要求不高，对权限管理和安全等级的要求也不高，那么使用Meta或其他公司的产品会更加轻量化，这也是它们的优势。

彼此的优势和定位比较分明。对于我们所谓的GA，即S500大客户，以及头部行业中的巨型客户，由于其与M365及其他SaaS服务的绑定周期长、绑定程度深，并且已经形成使用习惯和黏性，因此，如果这类大客户需要重量级办公AutoPilot，使用我们产品的概率仍然较高，其他公司对我们的影响不会非常明显。

这实际上是基于原有SaaS，再结合SaaS Copilot和平台能力构建的护城河。但从SMB，即中小微客户的角度来看，我们可能会流失1部分客户。这也回应了刚才提到的问题：目前OPG层面正在探讨，是否要针对SMB小微客户，使用new M中的home进行替代。因为它更加轻量化和直接，可以直接对标Meta或其他公司的Agent。

目前这一方案仍在探讨，尚未作出最终决定。我也不确定几天后或者11之后是否会有新的更新，届时再讨论。最后的1个方面，是从进一步的长期角度来看。

原文转译

呃，专家你好，呃，在我们开始今天的访谈前，请您就以下阐述表明我同意或我不同意。 您知道保密信息的定义，并同意不会在访谈中透露任何此类信息或任何其他的保密信息。 OK。 OK，好。 呃，专家，那我们开始吧。 呃，首先就是今天我们主要就聊一聊copilot的这个升级和 呃，这个季度可能一些运营的一些情况吧，就包括企业渗透率的情况，OK。 OK。 OK，呃，第一个就反正就是讲讲Copilot的，就是copilot的升级目前已经接到哪些产品里面了，然后能不能讲一讲这些产品里面分别增加了哪些能力，然后哪些是已经只是还只是个对话路口，哪些说已经能够读取一些业务数据，执行操作并写回去看完了。 嗯，首先我要先clarify一下您说的升级就是前几天0925的这个升级对吧？ OK。 对，对对对对，嗯。 首先第一个层面，您可以主这个详细的看一下，那天呢那个这个Vlog啊，包括官方发的这个文章啊，第一个，它的升级叫Microsoft Copilot升级。 OK。 好。 而Microsoft Copilot呢，其实现在的定位是什么呢？ 是统一的品牌， 应用入口和平台。 OK。 它 嗯。 同步， 它是什么呢？ 对标起来M365 Copilot其实是M365 Copilot还是面向企业级办公场景。 OK。 所以在这个里边，首先先说一个层面，为什么现在有这个，咱们简单来讲就叫M Copilot了啊，那个叫M365，咱们这个就叫M Copilot，好吧？ 那M Copilot的这个出来的这个原因是因为是这样。 因为最早的时候，在23年的时候，当然咱们今天为了方便讲，拿A公司来代替Microsoft，说这个更顺嘴一点啊，好吧，OK。 那A公司从23年开始正式步入了云三阶段，就是AI的这个阶段。 其实这个云三阶段是分了两步。 第一步，是23年开始一直到24年的中后期，就基本到25年前， 我们叫All in AI，什么叫All in AI？ 也就是把A公司所有的一级产品系列产品，比如说M365，Windows，D365，Security，GitHub等等，所有的一级产品系列当中，当然指的都是SaaS的层面， 都要加入AI。 OK。 好。 而在All in AI这个阶段之后变成了一个什么问题呢？ 就是 A公司内部有八九十个Copilot。 因为你所有的产品都有Copilot。 OK。 所以对于B端跟C端的无论是上级的客户还是C端的用户来讲很confused。 我你这么多口拍的究竟干嘛使？ 我也不知道使的好使不好，然后同时呢， 这些单点的Copilot它没有办法形成后台打穿， 没有聚合。 OK。 所以在这个层面上，第一个压力就是说我的单点口拍了很多，很杂。 大家没有办法搞清楚这个出处和所谓的接入的端口。 那应运而生的同步的还有一个是什么事情呢？ 就是说 它的copilot大家因为这个模型能力在后台有深有浅，OK，使用的场景不同，所以对于这个产出的结果内容其实也是不同的。 就是同样你问一个问题，您问M365 Copilot里面的chat，和您问这个M Copilot原来的就是Windows的Copilot里面的chat，其实在某些时刻，您得到的结果是不一样的。 OK，好。 那基于这些问题基础上，从25日年开始，总部就逐步的要步入了云三阶段的第二步。 叫AI enable all。 而在这个里边，最主要的一个问题是什么？ A公司自身首先我们 不是一个Frontier Lab,我们不是一个模型商。 早在15年16年开始,我们自搞模型的,就是当年向阳总Harry Shum, 在搞AI Research这个团队,就是自研模型的时候,其实 就我们本身的骨子学里面就,自己的模型就搞不了太好。 OK。 所以导致的是什么呢?又跟OAI的这个这个关系在越越行越远,来脱绑这个唯一的云厂商的这个所谓云供应商。 使得我们自身的定位就是什么呢? 我们不单一的是说对于AI能力去看模型。 而进一步演化成了一个什么? 我们要做的是一个平台能力。 所谓的平台能力,你可以理解为什么?就是AIOS。 什么叫AIOS? 我相信您或者在现在朋友可能大家有使这个Windows作为操作系统的这个笔记本。 或者或者PC或laptop。 对吧? 您的这个PC的,它的Windows其实是一个底座,是一个操作系统。 而您在这个Windows基础之上,您可以装Office, 装Dynamics,就是ERP CRM,可以装其他的软件和插件。 对不对?OK。 所以现在进一步演化的就是这个M Copilot,刚才咱们定义的是统一的平台, 应用入口和平台。 而在这个当中,它的三个功能,核心工作区域,home、code、autopilot。 是三个核心工作区域,但并不是三个分别单独的独立产品。 OK。 这个意味着什么? M Copilot首先来去讲, 它是一个产品UI或产品的统一入口。 但是无论产品许可, 后台的模型服务,包括数据隔离,仍旧是不同的独立体系,尤其是您如果拿M Copilot跟M360 Copilot去比较,因为咱们知道home里边其实是包括了一部分这个Word、Excel、PowerPoint的功能,对不对? 它并不会 简单的说是说我拿M Copilot就替代了M360 Copilot,至少在目前这个中短期内是不会的。 OK。 那打一个比方,一个形象的一个比喻是指啥呢? 就是M Copilot和 这个类似于什么?类似于咱们国内咱们大家使的比较多的微信了。 OK。 您微信有个人端口,也有企业端, 对不对? 都是通过一个界面可以login。 您里边有不同的authority, 对吧? 您B端C端您进入以后,其实您实现的 功能,当然括号,后台所接的比如说模型, 包括后台所用的卡,无论是老黄家的,NV家的N代,还是说C端, 用我们自研的Maia,无论是这个200还是280还是明年的300。 那模型的能力无论是老黄家,sorry,是OAI或者是Claudie,还是我们自研的模型,甚至是开源模型, 它在后台,你在B端C端在介入的时候,其实就已经帮你进行设定了。 OK。 所以在这个逻辑上的是什么呢? 它只是在目前这个阶段是把界面进行统一。 当然这个角度来去讲,从界面的层面上是统一了一个单一的一个产品名称,叫M Copilot,对吧?无论是网页,无论是Windows,无论是移动端,其实都可以合并为一个Copilot应用入口, 不再有单独的这种图标,来统一到这个入口当中。 而您在登录账号的时候,那您就是个人账号, 还是企业账号, 那如果您是企业账号的话,那您就有相对用的这种能力,对不对?如果您个人账号的话,您的从模型从卡的能力上就根本就不足够。 和起来去媲敌,对吧? 而在许可的角度来去讲呢,它是独立许可。 较比VS来讲,M3的copilot在目前不会取消,因为刚才咱们提到的一个关键的一个点啊, M36 copilot,其实是啥呢? 是面向B级的,企业级客户的办公场景呢,这种所谓的AI产品。 OK。 所以,那在这个里面你站在PC一个消费侧,一个C端的一个角度, 我有免费的M copilot, 无需要附加的许可。 而在这个里面您可以简单用Word,PowerPoint等等,但如果你要进一步的来去讲呢,其实是有这个M365的premium和个人账户, 您可以在这个里面去用,但是不能访问比如说企业级租户的graph和企业级的其他的一系列的功能, 对吧? 而您如果站在商业侧的角度, M copilot的chat是免费的, 您可以使。 但是像M365copilot里边的一些graph,一些深度集成能力, 等等,这些部分其实是没有办法直接免费用的。 您包括它的code, 包括它的autopilot, 其实是按照这个所谓的API token的方式去收, 对不对? 这个逻辑导致了一个最直白的一个结果就是什么呢? 我的后端的数据层面其实是完全隔离的两套,不会合并。 我的C端,我可以共享推理数据集, 数据也可以走这个互联网的公开消息,不接触这个企业级租户的这种graph的包括tenant的方式。 而企业版的角度来去讲,它呢是一个独立租户,企业数据呢,他他要在这个边界里面单独处理,不会流入到消费版的这个模型当中去。 OK。 这个是目前的这个角度, OK。 但如果in the future的角度来去看的是什么呢? 对外的产品, 如果演化的,因为现在毕竟还没有正式GA嘛, 对不对? 大多数还都是在内测。 这个待会我会给您单独去说一下, 针对于新的M copilot, 无论是我们内部的找的不同的团队人员去内测的结果, 正向反馈跟痛点。 同样,我们找了我们一些frontier的这个头部大客户的, 他们用新的M copilot来进行内测的一些量化值,以及一些正负向反馈,这个我待会儿说完这个部分会给到您, 好吧? 那在这个角度,目前呢它您可以理解为这是一个统一化平台端口的face1, 第一步。 OK。 face1的角度来去讲呢是什么呢? 好, 我这个所谓的M copilot跟M3 copilot还是完全分开的。 但将来 in the future,不排除的是说, 有可能如果这个端口做得很好, 就把M365 copilot, D36 copilot和security copilot, 类似于现在的code一样, 我把我的GitHub copilot,因为GitHub copilot就是code对应的就是GitHub copilot嘛, 对不对? 我类似于像GitHub copilot code一样先嵌入M365,M copilot一样。 我把其他的这些SAS copilot, 不叫M36,可能就叫这个work, 对吧? 或者就叫这个这个Dynamics这个ERP的层面,那就叫ERP CRM。 对不对? 我在这个统一的M copilot这个界面跟端口上实现模块化,其实就像现在的home,code跟autopilot是一个逻辑。 OK。 这个首先我跟您这边要澄清或者是说明白的是目前的... 这个定义, 这个角度来去讲,请一定不要和M365 Copilot这些去混淆,而且最近这两天有很多朋友啊,国内外的朋友都在,就是自己的朋友都在问,嘿, 你们这个出来的 M Copilot是不是就是说把原来的M366 Copilot就都替了,以后就是这一个。 对。 现在目前为止对于B级客户还是依旧有 M366 Copilot。 好吧, OK。 OK,好。 这个是第一个这个逻辑啊。 第二个,那就回到刚才咱们说的这个测试的这个层面啊。 好, 测试的角度来去讲, 首先分为内外部,内部就是我们的公司自身。 这个刀腹,就是狗粮的这个测试。 内部呢涉足的这个测试人员呢差不多有5000多人。 涉足的这个这个function啊,就是团队啊,有BG。 就是我们的这个几大BG嘛,九大BG。 然后有销售中的ATO和FDE。 因为我相信你也知道,我们今年7月份开始把FDE单独拎出来了,成立一个独立实体。 对吧? OK。 然后还有什么呢? 后台职能的部门,HR, Finance, Legal,这三个都在参与。 OK。 测试的这个周期 是持续了 50,50天左右。 OK。 而在这个里边, 那它是测试的是指什么呢? 是拿着老的M Copilot和新的 Copilot 来进行相对应的对比, OK。 首先是给到您老的M Copilot跟新的 Copilot它对比的一些观测的所谓的indicators,就指标值的前后的变化。 OK,好。 第一个, 对标老的 Copilot, 第一个啊,当然第一个指标叫这个周活跃会话,就是人均的 周活跃的会话的数量。 OK,好。 老的这个M Copilot之前平均人均的话, 是12次左右。 OK。 好,就一周啊,一个人平均。 而新的 改组以后的,新的这个M Copilot, 由原来的12次提升到18次, 到19次,就18点几次, 这么一个逻辑。 OK。 好。 第二个indicators是什么呢? 单会话的平均持续时长。 OK。 老的M Copilot, 内部的角度, 差不多是4分钟零10来秒钟。 OK。 新的M的 Copilot目前这个版本提升到了6分40多秒。 OK。 好。 第三个 是什么? 用户的正向反馈率。 这个基本上老的版本的M Copilot是51%, 其实比较低了, 因为毕竟说白了原来的M Copilot,就是Windows Copilot,我相信你也使, 那个东西其实没啥东西,坦白有什么说什么, 对不对? 而新的这个Copilot的M Copilot, 它在加入了hold的和autopilot和这个code以后, 用户的正向的反馈的比例,就是满意度其实您可以理解为, 提升到了67%到68%。 有一个比较明显的提升。 OK,好。 而第三个 sorry,第四个, 复杂多步骤任务完成成功率。 OK。 这个之前的老的M Copilot里面很低, 基本上可以忽略,就10%左右。 新的M Copilot, 它的复杂多步骤任务的完成率在内部的测试的层面上是68%到70%。 这个润。 OK。 哎,因为毕竟这个里边有了autopilot,也就是所谓的多说一嘴,其实就是对标的是什么呢? 对标的是我们之前说的scord。 OK,好吧,因为这个scord其实就是改名要整合到里面来嘛。 好。 然后再下一个指标值,这就是token。 人均的周消耗的token。 老的McoPilot是 89.7K的token。 OK, 而现在新的McoPilot,它的周的人均的token变成了146个K的token。 这个基本上还是一个比较明显的这个翻倍,因为说白了这个当然也能理解。 因为你的code和你的这个Autopilot都是按token方式走的,不是按照seats去走的,对不对? OK。 好。 而在这个里边, 还有一个是 主动开启Autopilot智能体的内的这个比例。 OK。 那在这个里边,老的McoPilot里面是没有的,是zero,因为他原来没有Autopilot。 OK。 新的McoPilot里边,主动去开启Autopilot智能体的能占到60%多,就是受测的这个人员。 OK。 好。 然后再往下, Autopilot它的任务执行的失败率。 OK。 老的McoPilot是zero,因为原来没有。 新的auto,新的McoPilot里边的autopilot的任务执行的失败率接近30%,29%。 OK,好。 嗯,而整体的层面上,对于 老的McoPilot的NPS。 OK,就是所谓的这种产品满意度嘛,或者说推广率,对不对? 推荐度。 这个之前老的McoPilot呢是基本上是复数。 因为大家觉得这个东西都使得很多也没有啥可推的了,对不对? 而新的McoPilot的NPS呢基本上是正的212。 OK。 好。 嗯,那在这个里边,那进一步的来去讲呢,如果按照刚才咱们说了,我们的内部的访问的这个就是测试的 这些人员,来自于我们的基本上端到端的几大function,对不对? BG, 包括销售, 当中的其他的几个部分,再包括后台的职能部门,对吧? 那基于这些职能,这这些function啊,首先, 第一, BG、产品经理对于code的模块的接受度是最高的。 内部的NPS这个部分已经达到了正的48、9。 OK,好。 而其中相对应的BG和PM的相对应的这些岗位的,当然PM其实说白了,您在销售在各个function,HR Legal Finance都有PM,这个PM不是产品经理,是项目经理啊,好吧,OK。 那在这个层面,测试的内部人员每周使用code的模块对应这些岗位, 至少是三到五次。 OK。 主要是用来快速生成一些copilot studio Agent,包括生成一些auto的这种所谓的流程,这种flow,然后编写数据处理的这种脚码。 OK,好。 而对于销售的这个团队,无论是AE、account base的,还是FDE的这种成功团队,客户成功, 他们重点使用的还是home这个里边的原生的office的嵌入, 使得跨Word的PPT Excel不用跳出口拍的界面。 这个在内部的测试之后,脚比之前你要单独的去 到Word Excel PowerPoint。 这个不用跳用这个原生的home的这种原生嵌入的时候， 这个报告生成的时间缩短了1/3,33%。 OK。 好。 而对于像legal, HR, 啊, sorry, legal和我们的内部信息IT部门， 对于autopilot他们的顾虑是最高的。 也就意味着什么？ 仅10%多的 legal的就是我们C-level的员工， 愿意主动开启autopilot常驻的执行。 OK。 而剩下的有70%左右的legal和在所谓的这个IT我指的是CSO啊， 就是这个内部的信息安全部门。 这些员工， 他们提交 相对应的风险工单， 他们担心担忧的是这种权限的越界， 包括带来的一系列的合规风险。 OK，这个是按照职能的角度去看。 好。 这个是所谓的内部的职能。 而如果in general来去看， 内部的反馈分为正向跟负向。 正向的角度核心呢有三条。 第一条， Home统一的这种接入的平台端口入口的价值是最高的。 因为原来需要切换M365 Copilot，Copilot Studio，GitHub Copilot等多个界面。 现在我单一入口就可以完成chat， 完成文档协同，构建agent，包括编码， 包括员工上下文切换时间在明显的下降。 内部的这个测试包括问卷， 有70%多的 内部的测试员工， 认为 这个对于消除多产品碎片化是一个最明显的提升，因为刚才咱们最刚开始提到了， 原来有八九十个Copilot， 其实不光是用户客户，我们自己有的时候也搞不明白。 坦白来去讲。 OK。 而第二个，针对于code的，它的正向反馈是什么呢？ code的这个模块 降低了agent它的构建的门槛。 也就是 非开发岗位，比如说我的一些业务的分析师SE，对吧？ 包括我做FDE当中的一些solution的， 这个industry solution, 再包括一些运营operation的人员等等。 可以相对直接简单的去用这个AGI来生成一些agent。 内测的角度来去讲，在这个50天的左右的这个时间内， 内部员工受访的这些人，一共建了1000多不到2000个小型的内部agent。 是用新的M Copilot这个coding来做的。 OK。 而在这个里边， 其中40%左右的创建这些agents的这个创建者，其实是没有任何的这个IT或者是 这个写代码的这个背景，或者是之前的这个专业并不是干这个的。 OK, 好。 这个是code的部分。 而对于autopilot的角度， autopilot 在限定权限的场景，它的产出相对比较明显。 也就是意味着什么呢？ 在配置相对应合适 和安全保障权限的前提之下， 执行比如说我的一些日常工作，比如说我的周报， 汇总， 邮件的批量分类， 会议纪要归档， 这些确定性的重复工作， 单用户每周可节省至少三到五个小时。 OK。 而工程化团队用来跑简单的单元测试日志的解析的效果更为突出。 错。 OK,好。 这个是内部针对于三个新模块转化之后的正向反馈。 而针对于内部的测试的角度,暴露出来的一些负向反馈和痛点, 在这个里边。 第一个, Autopilot,它常驻智能体的稳定性现在还是一个比较大的question mark。 因为刚才咱们讲了有接近30%的,它的任务是fail的。 OK。 这个里边最明显的是什么呢? 就是长链路的, 多步骤,设足到多方多团队多人员的这种所谓的任务,它中途会丢失上下文。 这是第一。 第二, 会尝试访问超出分配N权限的一些资源, 触发安全的自动的拦截。 OK,当然这个部分呢,其实也是要辩证的去看。 就是一旦你的autopilot的能力进一步的扩大, 那内部的CSO对应不同的这个所谓的归机的agent,或者归机的这种多步骤的这种所谓的归机员工,那他的权限要进一步的放开跟进一步的适配。 而测试的这个层面,目前虽然我相信你也知道我们内部其实有少量的这个digital employee嘛,就少量的归机员工嘛。 那但是这些少量的归机员工,在这个受访者的角度来去讲的并没有涵盖, 所以受访测试的人员都是探机员工,所以他的权限是严格的被切分的。 那在这个点确实也是容易触发安全的这个所谓的拦截。 而第三个,当后台的Office,如果它的服务站在峰值点、峰谷点有一些这个波动的话, Autopilot 它只能够从事直接进行任务的重新reset, 不会去这个等待或者是说我来进一步的就是这个,我在延迟区内我接着跑。 OK。 而在这个角度,我们的CSO包括MSD,就是IT的部门, 明确的是什么呢?对于Autopilot, 全默认的这种所谓的全局的打开,现在还是不允许的。 必须管理员逐个用户的要授权开启。 这个其实也是后续对于 对外私有预览的一个所谓的阴性的一个规则。 OK。 这个是针对于Autopilot的一些痛点和所谓的这个负向反馈。 而第二个,针对于code的这个部分, 它生成的代码跟Agent的质量的波动,也就是稳定性还是没有那么强。 比如说我简单的代码,简单的一些Agent,它生成的层面,我的成功率很高,有80%多,甚至接近80大几。 而如果涉及到多系统的一些 代码或API的串联复杂的这种大规模的Agent, 它的成功率是仅仅是百分之不到40左右。 而生成代码,如果按照现有CSO的标准来看, 用 这个里边的code, 因为它也关联了一部分这个autopilot嘛,自动化帮它生成嘛。 那在这个里边,生成的代码存在一定的安全漏洞风险。 而内部安全团队 也发现的是什么呢?内侧产出的由Autopilot跟code并行去产出的代码,有接近20%会存在潜在的注入风险, 必须要需要人工的,也就是归探机的二次审核, 并不能直接上线。 OK,好,这个是第二个。 第三个点, 内部测试完, 成本的这种,这个增加是明显的。 OK,因为刚才咱们提到了,无论是code还是Autopilot都是按照API token去走的,不是按照seat去走的。 所以,那token的角度, 较比老的,刚才咱们说的那个,这个token,咱们其实是有提升,就是升了60,60多嘛,对不对? 如果全公司完全铺开, 按照 Finance来进行, Central Finance去测算, 我们内部的这种所谓的预算预计要增加40%。 在目前这个阶段。 就是你的模型跟Agent的能力没有进一步的提升的话, 如果全面铺开,没有锁,所谓的API token,按照不同的国家、不同的部门、不同的人员岗位,你去锁上限的话, 因为我相信您也知道,其实这一段时间我们已经这个内部的员工按照不同的权限, 部门, job title,和你的岗位职责,其实对于API Token内部用量其实是各自有标准的。 你不能超。 你如果超的话,其实就是red flag,甚至要charge你各个部门自己的这个所谓的这个所谓的budget了。 就是你算你的cost了。 OK,好。 那促使的是什么呢?推动了一个结果是什么? 产品组, 他现在呢要加急上线一些所谓的配额,包括模型网关的限流,再按照场景,模型的自动升降级的功能。 这个也是现在finance这边连同于BG的角度在紧急在做的事情, 因为也要把控好所谓的内部成本,因为毕竟我们今年如果按目前的这个plan CA角度看,我们的Capex是2300亿左右到2400亿, 对不对? OK。 这个还不算Opex的层面。 好。 而在这个里边第四个痛点是什么呢? Office in Copilot, 它的一些重度操作其实是有卡顿的,有legacy的,有延迟的。 就是比如说在新的M Copilot里边,Home里边直接编辑大型的一个Excel,就是大于所谓的10万行的这种等量级的。 好。 它的延迟基本上就是在95分位的响应的延迟达到10秒到12秒左右。 明显会感觉到它还是有所卡顿的。 并不是很顺畅。 OK。 这个是内部的反馈的一些痛点和这个所谓的负向。 而在这个里边,紧跟着在内部测试之后,我们设定了一些规则, 就是什么呢?第一个, 站在CSO跟安全部门的角度,Autopilot 禁止全局默认开启。 必须在权限设定组织内部组织跟权限重新梳理完之前,必须由Entra的管理员给到不同用户租户组,包括小组,授予agent的身份跟最小权限。 同步, 禁止Autopilot做核心高风险、高敏感度的这种所谓的创作。 那比如说像我们这边,我们做corp strategy的人,我们有内部的所有的这种比如说这个revenue forecast budgeting这些东西,对不对,包括hicount,对吧,包括所有的组织架构的人员等等。 这个动作是禁止做的。 同步对于高风险的一些操作,比如说删除文档, 或者是对于外部客户,尤其是重大客户的这种主动推送现在是不允许的。 仅允许的是读跟副本的写和内部的分发。 当然对于一些非敏感或者是不在我们S500大客户的池子里,你可以申请去做这种自动。 推送。 OK。 而针对于code的角度， 它联动于autopilot去产生的agent， 要强制开启安全扫描， 未经人工审核在目前这个阶段是不能这个默认不能发布在租户内的。 第三， 增加分层、分区域、分部门、分岗位的token的配额。 高消耗的场景要自动切换到低成本模型， 抑制内部成本的失控。 OK。 好。 嗯。 这个是在内部员工使用之后做的一些调整。 而同步VS对比外部的B级客户。 首先， 这个B级的客户的角度我们是找了frontier计划的一些早期客户试点。 基本上 都是我们的头部的 付费的巨大型的这种头部大客户，就是以GA的客户为主。 OK。 而试点的角度呢是所谓的私有预览非正式GA。 OK。 好。 那一共给到这个frontier里边呢，差不多有个30多接近40家的这个企业。 OK。 在这个里边， 北美占到了20大几，欧洲占到了十多，剩下的是亚太。 OK。 每家frontier的这些企业开放的测试的这个席位， 差不多是从50到300不等。 按照客户需求，客户体量和它的这种职能的要求。 OK。 所以合计起来呢可能有这么个这个中位数几千个这个seats吧。 OK。 而选定客户的这个行业的分布是遵循我们什么呢？ Go back to essential plus one。 就是万物归宗加一的AI的行业的优先的这种战略。 主要的是什么呢？ tier one的行业。 是。 制造、金融， 包括咨询类公司， 包括这个刚才咱们讲的这个这个医疗， 以及互联网加high-tech这么几个大部分。 OK。 而auto pilot 在刚才咱们说的这个几十家当中， 只有20家去做私有预览，并不是完全做，就也就是50%左右吧， 是做了这种私有预览，并没有完全放开。 OK。 那剩下的没有给这个autopilot的呢，只是看home和code的这个模块。 OK。 好。 那在这个大的这个背景啊，跟这个所谓的testing的这个pool，咱们说完以后，咱们就说这个指标的角度。 相对来去讲， 外部的B级客户， 老的、新的M Copilot跟老的M Copilot， 人均的周会话数。 原来老的是10次左右。 现在呢增加到了16到17次。 OK，比较明显。 第二个， 正向反馈率， 由原来的40%出头，现在提升到56%到57%。 OK。 复杂任务的完成的成功率， 由之前的49%左右， 提升到了新的版本的M Copilot的60%出头。 OK。 然后，客户 它的IT管理员工单周的提交量， 原来的基线就是老的M Copilot是九九九个单子左右，作为benchmark。 新的呢平均每家呢是差不多16个左右。 OK。 而code的角度来去讲， 之前同期的这个旧版的studio，它同 呢可能是选了一个这个时间段。 它是同期有这个code差不多做了这个产出的这个agent,差不多是200个。 而在这个阶段内呢,code这个模块用新的M copilot,这个客户一共做了800来个。 OK,好。 然后, 那对于auto pilot的试点用户, 他的角度来去讲, 那他的业务失败的这个比例,这这个percentage这个ratio啊,老的是没有的,因为它没有auto pilot。 新的在客户环境下,这个auto pilot业务失误的这个这个ratio啊,差不多是35%,要略高于我们内部。 OK,好。 然后,再往下的就是什么呢?就是NPS。 老的M copilot对于客户来去讲呢,这些客户也比较给面子,基本上就是负一。 就差不多。 OK。 而对于新的目前的这个所谓的M copilot,客户给到的是正13。 OK。 好吧。 这个是基本上是对于外部的frontier的这些大客户的一些测试的一些指标值的前后对比。 而同步。 嗯嗯嗯嗯。 嗯。 专家我我我稍微点。 请说。 请说。 今天时间,嗯。 对,就是呃,就讲完这部分可能就是我们可能更关注就是后面什么时候全面推开,然后后面的一个收费的情况,到底是按,可能就是在席位以上就是哪些部分使用Co-pilot,然后你觉得对于这个今年的这个27年的这个Q1或者是以后,就是这个营收的这个影响是个什么样的,对对,就可能这方面可能就是就是就咱们对你可以可以稍微快点,然后就后面的这个变现快一点,对,谢谢。 那,好,没问题。 那外部客户的正向反馈我就快速跟您说一下啊,就是home的统一入口还是客户比较欢迎的。 OK,来回跳转,这个跟内不一样。 Code的, 呢降低了这个agent的门槛,比如说制造业的一个B级客户, 那他原来没有AI的专职开发,那现在就用code的这个模块,然后给他的供应链来建一个agent,其实没毛病。 而刚才咱说了800多个这个新建的agent当中有60%多,不是这个IT人员建的,OK。 而auto pilot呢, 对于咨询类的公司给Autopilot在设定之后,利用sharepoint,利用Teams聊天记录,他来自动的做每周的项目风险摘要。 客户整理的这个材料, 每周每人均的话节省两个多小时,接近三个小时,OK。 而外部客户的痛点的角度来去讲,就是auto pilot 在客户的异构的云跟IT的这个环境当中稳定性变差。 因为咱们也知道一个客户B级客户,他基本上都是混合多云。 包括它的这个所谓的软件,它不一定都用的是A公司的,对不对? 所以在这个层面上,那因为客户存在大量第三方的SAS,包括旧版的这种所谓的本地系统,权限又不分清,所以会经常出现这种问题,就是什么呢? 智能体想访问系统,但是 权限不通,系统不通,数据不通,任务跑一半就断了。 OK。 这个呢, 对于客户的他的CSO呢也比较大的担忧,就是agent ID一旦是权限匹配失错, 会横向访问海量的大量的B级客户自由的IP或者敏感数据。 这个里边10 20家左右拿到Autopilot预览的客户当中,其中有六到七家是主动临时关闭Autopilot,进时测试了,就是他觉得有风险。 OK。 第二个,成本不可控,这个角度来去讲呢,其实就是token猛增,这个主要是什什么呢? 客户的财务的层面,其实对于这个部分有很大的质疑。 但客戶的CTO的角度和財務這邊的這個兩者的battle更加明顯。 OK,而code生成的agent它的質量兩級分化比較明顯。 就是內部的知識庫的問答好,但涉及到客戶核心,或者是三方的API token,複雜的業務邏輯,這種生成的agent漏洞包括邏輯的比例還是比較高的。 OK。 而站在許可混合,它會confuse。 目前在初期的時候,還是有客戶分不清楚。 M copilot,M365 copilot,GitHub copilot之間的這種許可邊界, 它是分不了太清楚的。 OK。 但是這個點呢,隨著後續的推廣呢,可能就是進一步的能夠,所謂的這個完整性能夠進一步的讓它clarify清楚吧。 好吧。 那這個部分呢,就是剛才咱們提到的這個外外部客戶的一個濃縮啊,因為我就挑重點跟您說了,好吧,OK。 然後 首先來去講,基本上 從時間的角度來去講, 在今年的Q1基本上馬上就結束了嘛。 邏輯上應該是在Q2應該開始往起走。 但是 目前來去講,Q2像home和code的肯定能落。 OK。 Autopilot可能目前這兩天聽內部的會議啊,包括這個report的角度, Autopilot有可能會 在 Q2的底,甚至在Q3初才會出。 OK,因為內部的模型包括就剛才咱們講的這個調用agent啊,包括權限分佈管理啊,包括客戶的一些concern啊,這些問題都是要調的。 對吧? 所以最理想的是什麼呢?就是相對應對於auto的角度來講,因為我相信您知道每年我們11月的時候有這個所謂的 這個Ignite嘛,全球的產品技術大會,對吧? 這個可能它會做一個所謂的對外的一個正式一個大規模宣傳。 因為其實就是之前的scout嘛,對不對? 現在的這個叫autopilot嘛。 那在這個角度,邏輯上應該在二季度基本上新的M copilot就會往塊去推了。 OK,好,這個是大概的時間點。 而對於收入的一個角度的層面,當然這個裡邊咱們就要先看一個價格的層面啊。 首先來去講home的角度,它是包括chat,core,Office內置。 是按照用戶的訂閱的角度來去走。 對不對? 當然這個訂閱的角度呢,待會兒咱們去說,你有個人版,就是個人消費版,你有企業版本,對不對? 而第二個code的,它是基於GitHub copilot技術改用按照用量的token來去measure。 Autopilot的scout的角度是按照用量來計費。 目前呢也沒有一個最終的一個定價,這個大概率可能要到Q2的中後期才會明顯給出來。 OK。 嗯。 所以對於home的角度來去講呢,你首先M copilot的個人的角度啊,就是網頁, Windows內置的 copilot聊天,網頁搜索,基礎畫圖,這些層面是免費的,是不收費的。 OK,但是如果你涉足到了Office相關的,那它就會tag到什麼呢? M365的personal,比如說個人版是9塊9毛9一個月, 一年99塊錢, 對不對? 這個呢,但是不包括M365 copilot,它的那些所謂的企業級功能,也不包括code和autopilot。 OK,我我說的是後碼,就是Office這個部分。 而如果 是企業級的角度來去講, 好。 那M365 copilot的chat 说白了,他会是在这个M365里边。 而在这个里边,首先我要这么去讲啊, M365对于Copilot,对于企业级客户还是会独立存在的。 不会并到这个里面来。 OK。 好。 OK。 而企业级的客户, 他的这种 Essential的中小客户或者是这个小微客户, 现在有所谈论, 是否要用这个新M Copilot中的Home加上Code加Agents来进行这个Auto,来进行代入。 但现在目前并没有完全的这个decision making,并没有完全定。 OK。 所以大概率, 对于B级的企业级客户来讲,还是依旧是M365 Copilot。 这个30美金的这个版本。 当然在这个里面多说一嘴啊, M365 Copilot本身它就有三个,如果按照OPG, Office Product Group,它的产品路线图, 它本来就有三个版本。 第一个版本是什么呢? 就是现有的, 无论是一三一五还是一七里面内嵌的或者是外挂的这个30美金的这个版本, 我们叫它standard标准版。 在标准版基础之下, 还有一个 针对于中小客户的。 excuse me,我们叫它Essential。 中小客户版。 这个版本用的都是开源模型或自研模型,用的都是我们自研的卡,或者是老黄家的N减1甚至N减2代卡。 OK,作为支撑。 而这个部分刚才提到了,内部现在有争论,是否要把这个部分完全就用这个M Copilot的这个Home的这个Office的能力所替代。 OK,好。 而 站在这两个版本,就是Essential跟Standard版本基础之上,其实还有一个版本,叫什么呢?叫Premium,就是高阶版本。 这个Premium版本呢,其实是针对于FDE, 对标的这些我们的GAS500达客户, 在给到客户M365 Copilot标准版本基础之上要做所谓从模型的二开post-train, 到KB建立,再到标准的M365 Copilot它的定制开发, 去产生这种Auto和这种所谓的Flow。 这个其实是一个高阶版本。 OK。目前来看, 按照OPG的路径的角度来去走, 因为在这个里边, Copilot,新的M Copilot,它的BG的老大是Jacob。 OK。 而M365 Copilot的老大依旧是Rolanski, 这边。 OK,两个老大的BG是分开的,所以坦白来讲,站在BG的利益的角度, 对于企业级B级的层面, 这个标准版跟高级版在一段时间内应该是不​​会拿掉的,但对于中小​​的角度呢,其实是有探讨。 好吧,OK, 那对于企业级的来去讲呢,那你就按照比如说一期这个99一个月,那13、15现在的标价是多少,涨价以后的这个价格是多少,按照这个去算了。 OK,好。 而 站在Code的角度来去讲, 它呢是不包含在这个30美金的当中的, 它都是什么呢,按照API Token去走,目前对于API Token的这个价格跟Auto一样, 目前是没有官方定价的。 就现在还没有完全说,据我所知应该是没有的,OK。 而对于Auto的角度,里边会有一个什么呢,就是Everyday AI, 对吧,在Home里边。 这个呢其实是固定的是 30美金每月每用户。 对吧? 剩下的那几个都是按照计价的,就是计这个计量的方​​式去收, 那现在的API Token单价格, 说实话,现在内部也没有完全的定下来, 还在一个TBD的一个状态。 好。 嗯。 而 那接下来呢,一个角度就是说,您关心的一个点就是所谓的商业化进展。 OK。 这个层面咱们先说M365 Copilot。 这个是比较直接的。 OK。 M365 Copilot, 在上一个财年,FY26, 一个整财年, 全年全球一共是70多个亿的收入。 OK。 嗯。 今年,FY27, 一年的target,针对于M365 Copilot的target, 目前来去看是130个亿,USD。 OK。 而如果Q1拿FY27的Q1去看,当然这个Q1还没跑完啊。 我说的是一个非常roughly的数字,因为知道 各家公司咱们也都清楚这个seasonality,对不对? 你的季末的最后的这几天都是结mega deal的,结巨大单的,对不对? 嗯。 目前来去看, 站在这个Q1的角度,FY27的Q1差不多能有个30个亿左右。 OK。 而去年FY26的Q1呢是10来个亿,基本上就是翻倍了。 OK,这个是针对于M365 Copilot。 好。 而如果按照 财务部, 就是Amy Hood底下的Central Finance, 他们去推的, 当然这个您感兴趣也可以给您拆啊。 就是去推的, 我们在FY28,如果保持我们的CapEx理论上在继续增加的话, 因为刚才咱们提到了, FY25, 上上年我们的CapEx是800多亿。 FY26上一年1450, 今年是2300多,对不对?当然有可能在今年的1月底 和2月左右可能会加200亿,这个有TBD的一系列的要求,跟这个标准, OK。 如果要满足在明年的基础之上继续增长,比如说3000多亿的CapEx, 你的M365 Copilot的B端加C端, 要达到220、30个亿 的收入,单年。 只是本体。 而这220、30个亿包括了当年的new,就是新增订单, 包括了当年的add-on,补充订单, 也包括了28财年往回调一年和两年,就FY26,FY27,它的recurring的订单,因为我们跟企业级客户一般一签都是签三年。 对吧,也就是所谓的我们的ARPU就是这么来的,说白了。 OK。 嗯。 所以这三部分,如果达到220、30个亿, 基本上是CapEx还会继续涨。 如果 200亿,当然如果我自己判定啊,200亿左右应该问题不大。 如果是189呢,您如果站在投资的角度,您可能要多关注。 如果明年下个财年,M365 Copilot低于170亿, 单年, 这个被砍的风险就极其的风险之大了。 OK,好。 这个是M365 Copilot。 当然在这个里边呢,我简单呢也跟您说一下这个M365 Copilot这个怎么得到的这200多亿,有几个数,我给您念一下,您这个也好记。 第一个, 这200多个亿分为B端跟C端,咱们分开说。 B端, 首先是全球的云化的付费的B端的这个用户数量, 全球差不多有个4个亿,4亿多一点用户。 OK。 而咱们刚才也说了, 我们的这个Copilot其实,就是M365 Copilot是类似于乐高玩具的一加一插件,你得先买它的本体,标准版、高级版,E3,E5,包括现在E7, 您才能用这个所谓的M365 Copilot。 对不对? 那在这个角度,这几个eligible的版本占到这个4亿多一点用户中的67%到68%。 你就拿4亿多一点乘以0.67乘以0.68。 然后再乘以一个到FY28年底的所谓推出来的渗透率。 这个渗透率推出来是怎么推的? 是由当年的on-premise license,就是Office软件转到O365。 O365转到M365,M365由低版本向E5,E7的攀升率, 再加上2023年10月1号全球正式GA到 去年的,就是今年的6月底,7月初的时候, 它的复合增长的线性推出来的渗透率。 这个到28的日历财年末 基本上是要到17%到18%。 也就是你拿4亿多一点乘以0.6768乘以0.1718。 再乘30美金每月每用户, 乘12个月。 而对于B端客户来去讲,好。 我们没有所谓的平均客单价跟平均的折扣率。 都是不同客户不同项目,不同波次的opportunity单独去批。 但如果去看23年10月1号正式GA,到6月底的这个角度, 全球平均的大概的这个折扣是七几折。 那咱们就变成什么呢? 4亿多一点乘以0.6768乘以0.1718,乘30美金每月每用户乘12个月,乘一个0.75,咱们就算一个75折。 您算下来差不多是150来个亿。 OK。 嗯。 而C端同样 全球的Office的C端的用户数量差不多6亿1,6亿2。 OK。 而其中 C端的云化的用户, 它占到这个6亿1,6亿2中的57%到58%。 你就拿这个6亿1,6亿2这个数乘以0.5758。 然后按照刚才这个逻辑去推到FY28财年底它的渗透率会是到7%到8%。 OK,好。 那这个里边 也就是乘以一个0.070.08,再乘20美金每月每用户乘12个月,默认C端是没有折扣的,OK。 那在这个角度算出来差不多是70亿左右。 也就是150多亿加70亿就223,这么个数,是这么算出来的。 但是在这个里边,为什么要说这个数字? 其中 因为M,新的M copilot出来, home的这个功能, 它对于B端的影响其实目前看没有很大。 嗯。 但对于C端, 它的这个所谓的渗透率的增速 其实还是有促进的。 OK。 所以现在这一段时间,他们在算这个复合的增素这个渗透, 但是数据他们没有给,我个人估计, 如果这个C端的这个这个新的M copilot出来,正式GA,且功能不太差的话, 那我的这个渗透由现在的7%到8%,应该能到13%到14%, 就是基本上 翻一倍左右。 嗯。 OK。 这个当然是我的估算,这个所有的这个估算还要等Central Finance加上OPG他们统一给个数,那给的数一定是在正式GA之后的一到两个季度之后才会给出来, 因为毕竟你得看实际的这个增长情况,对不对? OK。 所以那如果按照这个逻辑的话, 你的渗透增速起来, 那按照刚才这个数量,您6亿多乘以一个0.67,呃,0.5758,您乘以一个... .1314。 而它的home的单价如果没记错应该是30美金,对不对? 嗯,OK。 那你就要乘30乘12个月默认没有折扣。 那这个里边它的增速就会起来, 说白了,当然在这个里面你不能完全按30美金走, 因为之前的还有这个C端的它是20美金左右的这个金额, 你要把它劈开算。 其实说白了。 OK。 嗯。 嗯,这个其实是一个基础的一个逻辑和这个量化值。 嗯,明白,明白。 对对,咱们是今天时间还比较有限,可能咱们再聊个10分钟,就是 我有两个,就是,那还有两个小,也不是小问题,就两个比较关键的问题。 就是,第一个就是27Q1的这个这个 Azure这个云的增速啊,就是是不是就目前因为季度还没结束啊,但是反正从您角度来看的话, 呃,之前的那个同等汇率百分之 好像是44到45的指引,就目前来看, 对对对,那目前看能 这么来说啊。 上次是什么样的,然后,嗯。 嗯,咱们咱们把这个单独来去讲。 您画三个圆圈。 这个三个圆圈的逻辑是大圈包含中圈包含小圈。 OK。 最大圈叫AzureO。 顾名思义就是Azure所有,包括三个部分。 传统的IaaS,网络计算存储,PaaS, 混合云,这个数据分析、数据池、高阶云安全,对不对? 和AI,就是跟相关的所有AI部分。 当然这个AI是刚才说的三个圆圈中的中圈也是,好吧? 目前来去看,首先来去讲,去年咱们知道, 在财报如果没改口径之前是104几。 改完以后应该是101几,不到1020的这么一个数, 对不对? 首先, 今年如果按着新财报口径, 今年全年的的 target有两个 target。 第一个 baseline,是基于1020左右这个数要乘以1.42左右。 OK,这是无论如何要做到大的,就是1.严格意义上是1.418几, 这么一个数。 OK,就是1.42左右嘛。 还有一个nice to have一定要做到的,就是,因为咱们也知道Jason作为这个全球销售老大, 他肯定要跟这个Satya要要要说嘛,老板我我这边要做更高。 他跟老板是说今年要做 所谓全年脚比1020这个数字的1.447几。 就是接近1.45 X。 OK。 好。 而在这个是最大圈啊,所以你能够推出来今年全年的大概的Azure的 target,对不对? 中圈, 就是Azure所有AI相关的括号, 不含OAI给我们的那部分分润,也不含它租我们的云计算。 他租我们的云计算是算在Azure大圈里的IaaS跟PaaS里的,不算在Azure AI。 所以Azure AI这个中圈, 其实是啥呢? 是我们基本上所有to B的企业级客户,当然也包括一些中小size的这种所谓的frontier lab,就是模型商。 OK。 那这个部分在去年的中圈是190大几,无限接近200个亿。 占到去年的102几的差不多20%。 对吧? OK。 而今年 要也是两个 target。 第一个 target, baseline的 target要占到21点多接近22, 这个占比。 第二个 target是要占到24。 OK,好。 就是按占到新的Azure大圈今年计划的212和24左右。 OK,好。 然后,那在这个里边,首先AI的角度来去。 讲分四个层面。 如果按照去年的这个190大几,无限接近200个亿的角度来看, OK。 那首先第一个层面, 它的mass API token,卖API token在190大几里边是70多个亿,占到38%左右。 OK。 嗯。 而第二个平行的就是machine learning and other services,就是工具链调用链,因为咱们知道, AI公司尤其对于这种美国或者是欧洲这种巨大性的S500大客户, 他们客户其实调API token不是直接用,他们都是要post-training二开二训的, 对不对?那要工具链调用跟其他的服务。 这个部分在去年的是30个亿出一点点头。 那占到的角度呢差不多就是10%多嘛,对不对? 然后第三个部分就是other AI,就是在23年原有AGI之前原有的AI,比如说big data,认知识别,blablablabla。 这个在上年当中呢是20个亿出头。 最后 是什么?60多个亿。 都是啥呢?GPU rental, 裸金属租令, 就是把我们手上的A啊、H啊,就是老黄家的N减2,N减3代卡往B级客户去租。 OK。 这个层面上差不多是60来个亿。 好。 那回到今年的第一季度的角度,当然第三个圆圈啊,就是所谓的这个刚才说的, Azure是中圈Azure AI的第一个部分就是API token,就是在去年是70多个亿嘛, 对不对? 这是去年的大中小圈。 好。 今年逻辑上应该是这样, 当然没有跑完所有的数请以 10月底的一季度财报披露数据为准,我现在只是roughly给你一个大概感觉。 第一个,嗯嗯。基本上 FY27的Q1, Azure的最大圈应该能做到320个亿左右, 目前看,当然,dependency在今天明天跟后天,这个美国时间有几张巨大的单,一共有昨天晚上夜里我们开会的时候的话还有14张, 这个critical mega deal。 OK。 逻辑上应该在320个亿左右,也就是什么呢? YoY 因为FY26的Q1在财报调完以后呢是223个亿。 您算起来应该差不多是1.4几。 1.44几。 嗯。 基本上能on之前的这个索引。 OK。好。 嗯。 而在这个里边,如果假设我on了这个所谓的这个 呃这个所谓的这个target的这个值, 那我Azure的中圈呢就是60大几个亿,不到70个亿, 左右。 OK。 OK。 而小圈的角度来去讲呢,基本上就是26左右吧,26,7左右这么个数字,目前来去看。 OK。 嗯,好吧。 好。 这个基本上就是Q1大概的roughly的一个情况啊,这个还要看最后这几天的closing情况,反正确实有一点难度,坦白来讲,嗯。 对对,我我觉得其实可以,咱们再过个半个月可以再再沟通一次,对,到时候可能会有一些更详实的数嘛。然后最后一个问题就是,昨天反正那个Meta也说要又要重新搞这个Enterprise Platform吧,那实际上就是,就包括一些news agent, business agent, 还有news code, API对吧。 这些,就从你们角度来看,就是实际上对你们会有什么影响吗?从短期和中期来看的话。 如果从短期的agents对标那其实就是auto, autopilot嘛,就是scouts嘛。 其实说白了。 但对于这个角度呢,首先第一个点啊, 并不说没有完全的影响,因为你的autopilot坦白来去讲是啥呢? 你是按API token的,也就直接影响你的这个API token。 收入,这是最直白的财务端。 但这种竞和关系呢,其实站在萨的ia的角度,包括站在Amy的层面上,大家看这个问题呢比较辩证。 因为我们现在这个最主要的是啥呢?第一个,我们要做的是平台。 OK, 也就是并不排除是说将来我的这个Copilot我搭建完成以后,我并不排除将来像Meta或他其他的这种所谓的智能体能架在我们上面。 OK。 嗯。 我们只不过是提供一个平台化,就像Windows一样,因为在Windows上面不光是我们的Office,其他的这些软件,你想PDF啊,你想其他的Visio或sorry,其他厂商的三方的这种软件其实都是能安上来的,对不对? 所以站在我们的角度,对于一个短期或直接的一个产品竞争的竞合关系,对于Scot会是直接影响。 OK, 而相对来讲, 影响不会特别大,为什么呢?因为 小比其他家来讲,我们的Scot是基于我们的传统的端到端的SAS来进行Scot的,进行autopilot的。 而我们的这种所谓的办公场景的SAS是最全的,你无论是M36Copilot,这个会议视频, 办公、OA、协同, 再到D365的ERPCRM,再到云安全的保障, 再到coding,这一整套的东西我们可以说是最全的,尤其是在办公这个领域,其实坦白讲还是这个独占的这个地位,对不对? 所以如果客户他是一个B级客户, 且他注重的是在办公场景的话, 用我们的概率会更强。 OK。 但如果他的这个B级客户,他用的是一些这个原生的一些场景, 或者是说一些轻量化办公的这些场景,对于这种数据打穿数据池数据湖,要求并不高,权限管理、安全等级也不高的话,那他们用Meta会用其他家,其实相应来讲会更加轻量化。 这个是优势。 OK, 就彼此之间的优势,就是大家的定位还是比较分明的,所以导致的一个层面就是说呢, 对于这种我们所谓的GA就是S500大客户, 这种头部行业中的巨大型客户, 因为它对于我们的M365和其他的这些SAS的服务绑定的周期长、绑定深,使用习惯跟粘性在这,所以如果是这种大客户的这种全部的 这个重量级的重量化的办公的这种autopilot, 坦白来讲,用我们的这种概率的影响,就是其他家对我们的影响不会非常之明显。 这个其实就是我们基于原来最早的SAS, 再基于SAS的这种copilot以及这种平台能力,我把它圈起来,所谓的一个护城河的一个构建。 但如果您对于SMB的角度, OK, 就是中小微客户的角度,可能会流失一部分客户,所以这个就echo回刚才那个点, 为什么现在站在OPG的层面也在探讨是否要把SMB的这种小微客户,我要用这个home,就是new的new的这个M里边的这个home来替代。 这个因为它是轻量化,对不对? 它是很直接, 那我直接就对标的是Meta或其他家的这种所谓的agent了,对不对? 嗯。 OK, 所以这个是目前在探讨,但没有最终的决定,目前此时此刻啊,但是我不知道过,比如说几天或者说11之后啊,会不会有一个新的update,那个到时候咱们再说,好吧? 嗯。 而最后的一个点是指什么呢? 就是对于进一步的一个这个长期的角度,