治理作为企业AI准入门槛
微软在Build 2026上悄然作出了一项值得更多关注的决策：与其发布更强大的模型或更有能力的智能体，不如将Agent 365 SDK推向正式发布，并在其周围配套了身份、策略和数据控制机制——这些机制在设计阶段就已激活，而不是等到智能体在生产环境中出了问题再启动。这一隐性赌注背后的逻辑是：模型能力已不再是大型组织的瓶颈。阻碍智能体项目落地的，不是系统性能不足，而是无法证明有人清楚该智能体在做什么、使用了哪些数据、在什么授权下运行、代表谁在行动。
这不是一个技术论点，而是一个关于组织内部权力架构的论点。
智能体项目之所以会卡在法务审查、风险委员会或CISO的案头，原因不在于模型本身有问题，而在于没有人能回答三个基本问题：谁批准了这个智能体的存在？它能接触哪些内容？如何在审计中证明这一点？微软识别出了这个瓶颈，并决定围绕它来构建自己的平台。
微软看清了竞争对手仍在用速度掩盖的问题
Agent 365 SDK附带了一个集中式注册表，微软将其描述为企业智能体清单的"唯一可信来源"。该注册表与Defender、Purview、Entra和Foundry相互连接，这意味着大型企业已部署的安全、身份和合规控制无需为智能体重新搭建，而是可以直接延伸覆盖。每个智能体可以拥有独立于任何人类用户的唯一身份。管理员可以定义哪些智能体可被发现、哪些被隔离、谁有权创建它们，以及它们在什么条件下运行。
该注册表还能检测出那些尚未经过任何人批准就已在运行的智能体。微软表示，该系统可识别超过20种本地智能体类型，包括Model Context Protocol服务器——这恰恰是工程团队快速部署、绕过采购流程的那类基础设施。将其称为"智能体蔓延"，是一种委婉的说法，意味着组织内已有智能体在任何管控框架之外运行，而这在成为安全问题之前，首先是一个治理问题。
与谷歌云相比，后者围绕每个智能体的唯一加密身份构建其智能体平台；与AWS相比，后者选择了通过Bedrock AgentCore走一条更快、更轻量的路径；而微软则选择了自己本就占优的领域：其最大型企业客户已安装并信赖的控制基础设施。这不是技术优势，而是二十年来与企业安全团队积累的社会资本优势。
浮现出的模式并非偶然。三大云服务商正在向同一概念架构收敛：一个用于智能体的控制平面，复刻Kubernetes之于容器的地位。区别在于，微软带着Entra、Intune、Defender和Purview登场，这些工具已存在于大多数大型企业之中。智能体治理不是需要在预算中另行论证的新平台，而是安全团队今日已在运营的体系的延伸。
谁在设计会议室里，这揭示了什么
从结构性设计视角来看，故事在这里变得更加耐人寻味。Agent 365 SDK是为解决企业采购方的问题而构建的，而非为那些想要快速推进的开发者服务。微软优先实现的功能——注册表、访问控制、运行时数据防泄漏、操作系统级别的Windows控制——都是为了说服CISO、法务团队或合规官员相信该智能体可以部署。这是一种设计选择，揭示出谁在采购周期中拥有否决权。
这绝非细枝末节。当一个平台的设计是先降低审计师的摩擦，而非开发者的摩擦，就意味着它明确承认：大型组织中的阻断权力不在技术团队手中，而在控制职能部门。微软押注于：说服风险团队比说服工程团队能赢得更多市场。这一押注对其他公司如何思考自身智能体工具的采用，具有深远的影响。
这由此引发了一个结构性问题：谁被排除在那个设计会议室之外？该SDK声称与任何智能体平台兼容，不局限于微软自家的，这是一种战术性开放的信号。但最强的控制架构在Windows、Entra和Microsoft Foundry的边界内运行。一家在AWS、谷歌云以及一套遗留SaaS工具上运行智能体的企业，在微软边界内获得了可见性，同时也继承了对该边界更深的依赖。多云治理在现实中，仍然是三大服务商都尚未解决的问题。Saviynt或TrueFoundry等独立厂商的存在，恰恰是因为这种需求真实存在，且未被超大规模云平台所满足。
还有一件事值得精确说明：微软于2026年4月Build大会之前，以MIT许可证将Agent Governance Toolkit作为开源项目发布。该公司将其定位为首个工具包，能够以不超过一毫秒的确定性策略执行，应对OWASP所识别的十项智能体AI风险。这是一个抢先定义标准的举动，在任何其他人之前率先出手。当一个主导性参与者以开源方式发布安全参考框架时，那并非慷慨之举，而是将自己的概念架构置于行业对话中心的战略行为。
没有任何销售演示会提及的治理成本
微软并未解决它自己制造的所有问题。任何准备采纳这一架构的组织，在作出承诺之前，都应正视三类摩擦。
第一类摩擦是：Build 2026上发布的相当一部分内容仍处于预览阶段，尚未正式发布。Defender与GitHub Code Security的集成已可用。面向智能体的Windows 365已可用。但MDASH系统——包含超过100个专业智能体的智能体式扫描系统——以及Purview的运行时控制和Defender的多项能力，仍处于预览阶段或待确认发布日期。建立在预览阶段能力之上的治理计划，是一个存在空白的计划。
第二类摩擦是操作层面的。每一层保护组织的控制，同时也在拖慢开发者的速度。过度调整控制的团队将会看到工程师绕道而行——因为审批流程需要三周，他们便将智能体部署于注册表之外。制造过度摩擦的治理，恰恰会产生注册表本该检测出的那种非受管智能体蔓延。这是一个组织设计问题，而非技术问题。
第三类摩擦是战略层面的。采用Agent 365作为控制层的组织，在微软边界内获得了真正的可见性。与此同时，它们继承的是对该边界更深的依赖。这不是反对该平台的论据，而是任何诚实的架构决策都应纳入考量的变量。通过Model Context Protocol等标准实现的治理可移植性——三大服务商都声称支持——在实际操作中，可能远不如新闻稿中描述的那样触手可及。
非人类身份：企业控制的新前沿
去掉产品术语，微软正在构建的，是一套针对非人类实体的身份与授权系统——这些实体并非人类，却可以像人类一样行动：读取敏感数据、调用工具、触发流程、代表组织作出决策。这个问题在两年前还不存在于这种规模之上。
预算含义是直接的。原本用于模型访问和实验的支出，现在需要为身份与治理层单独列一笔预算，正是这一层将实验转化为获批准的部署。一旦智能体能够自主读取数据并触发操作，这笔支出便不再是可选项。非人类身份成为头等问题，其紧迫性与组织自从企业边界不再是物理围墙以来对待人类身份的方式相当。
微软的这一举措，并未解答当组织在多云环境中运营，同时使用数十个SaaS工具和基于第三方平台构建的智能体时，治理能运作得多好这一问题。但它确实揭示了一种权力机制——这种机制将决定哪些组织能够扩展智能体部署，哪些将继续困于在法务审查中夭折的试点项目循环。在监管机构或董事会提出要求之前，就能证明每个智能体做了什么、使用了哪些数据、在什么授权下运行——这一能力，将是区分真正部署者与无尽实验者的标准。
微软在Build 2026上展示的架构，并非解决这一问题的唯一途径。但它确实是第一个将最大型组织已安装的控制基础设施打包在内、随之而来的方案。这种分发优势不是技术性的，而是结构性的，远比一个安全基准测试成绩难以复制。
