微软的新Copilot智能体拥有自己的电子邮件、日历——并在组织架构图中占有一席之地
内容提要
微软发布迄今最大Copilot更新，CEO纳德拉称其为“工作新操作系统”。核心包括：Autopilot可在后台持续执行任务，拥有独立Entra身份与账号；Code用自然语言生成应用，运行于受IT治理的托管运行时。微软将智能体运行时、身份、状态与权限纳入Microsoft 365基础设施，降低开发门槛，但也加深对微软生态的依赖。
延伸解读
智能体身份独立带来的权限管理变化
Autopilot智能体拥有独立的Entra身份和用户账号，包括自己的邮箱、日历、OneDrive和Teams访问权限，并在组织架构图中占有一席之地。这意味着智能体以自身身份行事，而非借用用户凭证或共享服务账号。对开发者而言，无需再为智能体搭建共享账号体系；对管理员而言，可以将用于员工的访问策略直接扩展到智能体，实现更细粒度的权限控制。
托管运行时如何降低部署门槛
Code生成的应用运行在Microsoft Copilot Managed Runtime上，该平台在客户的Microsoft 365租户边界内托管代码，由IT治理。开发者无需自行搭建运行时环境，即可在现有身份和治理框架内部署应用，并能在不影响当前版本的情况下测试和部署新版本。运行时还接受Copilot Studio和Cowork构建的应用，并通过SDK和命令行工具向外部工具和专业开发者开放，Git负责跟踪源代码和版本。
长时运行智能体的成本治理挑战
Autopilot等智能体功能按使用量通过Copilot Credits计费，而非包含在标准订阅中。当智能体可以连续工作数小时甚至数天而无需人工干预时，成本就成为治理问题的一部分。微软将Agent 365的成本管理扩展到Code和Copilot Managed Runtime，并计划在10月支持Copilot Studio构建的智能体。工程团队需要同时控制智能体的计算资源消耗和可访问的数据范围。
便利性与平台锁定的权衡
微软将智能体运行时、身份、状态和权限纳入Microsoft 365基础设施，团队无需自行组装这些组件，但交出的基础设施越多，智能体迁移到其他平台的难度就越大。虽然微软目前同时运行OpenAI和Anthropic的模型，并计划引入更多模型和开放权重模型，Agent 365 SDK也提供受治理的MCP访问，但这些开放接口只覆盖智能体架构的一部分。智能体越依赖Microsoft 365的身份、权限和上下文，迁移成本就越高。
Q&A
微软最新的Copilot更新中，Autopilot智能体是什么？
Autopilot是微软称为“主动且长期运行的企业级智能体”，它从设置者那里获取角色和目标，然后在后台持续工作，无需每一步都重新提示。每个Autopilot拥有独立的Entra身份和智能体用户账户，其权限和活动与创建者分离。
Autopilot智能体如何拥有自己的电子邮件和日历？
在Microsoft Foundry中，Autopilot智能体获得完整的Entra Agent ID用户账户，并附带生产力许可证，从而拥有自己的电子邮件、日历、OneDrive存储、Teams访问权限以及在组织架构图中的位置。
微软Copilot更新中的Code功能是什么？
Code是微软Copilot更新的一部分，它基于与GitHub Copilot相同的底层技术，能够从自然语言生成应用、仪表板和工作流。生成的应用程序运行在Microsoft Copilot Managed Runtime上，该平台在客户的Microsoft 365租户边界内托管代码，受IT治理。
Autopilot智能体如何计费？
标准订阅涵盖助手功能，但Cowork、Code、Autopilot和其他智能体功能通过Copilot Credits按使用量计费。前沿模型如Fable和Astra也适用此计费方式，但用户仍需Copilot许可证才能访问它们。
使用微软Copilot智能体有哪些潜在风险或限制？
主要风险是加深对微软生态的依赖。因为微软控制底层企业环境，处理智能体状态、凭据和访问控制，团队移交的基础设施越多，智能体就越难迁移到其他平台。虽然模型不锁定，但智能体对Microsoft 365身份、权限和上下文的依赖会增加迁移工作量。
开发者如何创建和部署Autopilot智能体？
开发者从Foundry托管的智能体创建Autopilot蓝图，管理员批准后出现在Agent 365注册表中。员工随后可以在Teams中“雇佣”该智能体的实例。蓝图定义智能体的设计目的，但管理员仍控制每个实例可访问的资源和数据，将员工访问策略扩展到智能体。
