Microsoft Copilot Studio 获得代理，失去旧应用模型

Microsoft Copilot Studio 现在强调代理 (agents) 而非其先前的应用模型。这一变化表明向更大自动化主张的推动。与此同时，底层企业软件仍控制着实际工作流程和数据路由。

此举正值 Microsoft 将代理推广为业务任务的下一层级之际。团队可以在 studio 内部构建代理，以处理曾经需要独立应用才能完成的步骤。这些代理依赖于从 SharePoint、Dynamics 和旧版业务线工具等现有系统中提取数据的连接器。

这种设置产生了一种张力。代理被呈现为能够规划和执行的灵活助手。但在实践中，代理继承了宿主系统已经设定的权限、数据模型和集成限制。当旧的技术栈限制某项操作时，代理就会停止或返回不完整的结果。

Microsoft Copilot Studio 代理通过预定义的连接器和 Power Automate 流运行。该 studio 为创建这些代理提供模板和拖放界面。每个代理都可以调用跨 Microsoft 365 服务和经批准的第三方端点的操作。

代理层并不会取代源应用程序。它位于顶层并遵循这些应用程序强制执行的规则。被要求更新客户记录的代理仍必须遵守客户关系数据库中定义的安全角色。如果这些角色封锁了某个字段，代理就无法完成请求。

企业客户已经在 Dynamics 和 SharePoint 中运行着数以千计的自定义工作流。这些工作流历经多年构建，并带有审计轨迹、审批和合规性设置。访问相同数据的代理会继承相同的约束，而不是绕过它们。

因此，代理将处理端到端工作的承诺与现有的权限结构发生了冲突。Microsoft 将代理描述为能够跨工具进行推理。文档指出，代理可以将任务分解为步骤并按顺序调用多个服务。然而，每次调用都要经过与人类用户相同的身份验证和授权层。

安全团队审查代理权限的方式与审查服务帐户的方式相同。如果请求跨越部门边界或涉及受监管的数据，代理仍需要明确的授权。这些授权仍由原始系统管理员管理，而不是由代理构建者管理。

分析人士指出，这种架构减少了意外故障。它也限制了智能体在无需人工干预的情况下能够真正完成的任务范围。当审批步骤处于遗留流程中时，智能体必须暂停并等待该步骤通过既定渠道完成。

ServiceNow 和 Salesforce 等竞争平台也面临类似的限制。它们也提供了基于其核心数据模型和审批引擎的智能体风格接口。区别在于营销重点。Microsoft 将其 studio 定位为任何用户都可以扩展的通用智能体构建器。技术现实表明，它与每个供应商所维持的底层平台具有相同的依赖性。

独立观察家指出，真正的智能体自主权需要直接访问原始数据存储以及覆盖业务规则的能力。很少有组织会授予这种级别的访问权限。相反，他们将智能体保持在已为其当前软件资产协商好的护栏之内。

因此，从旧应用模式的转变更多地改变了界面和语言，而不是改变了控制权。构建者现在在单个 studio 中工作，而不是在不同的应用程序之间跳转。他们创建的智能体仍然读取并回写到相同的表和记录中。任何需要多次审批或跨系统交接的流程都会保持这些要求不变。

测试早期智能体模板的团队报告称，单一系统内的简单任务运行迅速。跨越电子邮件、文档库和外部 ERP 系统的任务通常需要智能体至少向人工交接一次。studio 提供了日志记录，以便管理员可以追踪每次交接。

剩下的一个问题是 Microsoft 在未来几个季度将如何演进连接器的覆盖范围。如果新的智能体需要来自非 Microsoft 源的数据，公司必须在相同的安全模型下扩展批准的端点或允许自定义 API 调用。如果没有这些扩展，即使最初的承诺暗示了更广泛的覆盖范围，智能体仍将留在 Microsoft 生态系统内。

IT 领导者关注两个信号。首先，Microsoft 是否会大规模增加延伸到 Dynamics 和 SharePoint 之外的连接器。其次，来自智能体的审计日志是否能在无需额外映射工作的情况下满足当前的合规框架。这两个信号将表明智能体层是否能从演示阶段走向日常生产使用。