计划负责启动智能体
谁来对结果负责

微软在2026年9月24日的公告中介绍，Routines 将触发器、智能体操作、执行身份、连接和运行历史整合到 Foundry 项目中。调用和工具使用可以采用例程创建者的身份，也可以采用智能体的身份。随后发布的 Foundry 月度汇总，则展示了启动之后应用还需要做什么。它的标题写的是9月，但发布元数据标明的日期是2026年10月16日。两篇材料应结合起来看：公告解释执行服务，月度汇总追踪报告在应用中的流转。

Routines 已标注为正式可用（GA），而由智能体安排后续继续执行的提醒工具仍为预览版。这两个状态都不能证明端到端交付的可靠性。月度汇总明确指出，Routines 不替代多智能体编排或审批流程。托管触发服务可能省去维护独立调度器的工作，但应用仍须跟踪已接收的任务、保存结果，并处理发送状态不确定的情况。

月度汇总中的变更报告流程，将工作分给两个智能体：一个收集公开证据，另一个准备并交付报告。应用先保存任务，再确认接收，并分别提供状态查询和结果获取方式。即使调用方不再等待，已接收的任务仍能被识别。交接时，接收方负责自己的报告副本和交付记录，而不是假定自己可以访问生成方的私有存储。作者称，10月13日的演示交付了一份已保存的报告，并支持在同一张卡片内浏览不同内容。之后，生成方采用接收方的消息回执，没有再次发送。这是一个有用的应用示例，但它通过手动调度例程启动。尽管作者表示周一计划已启用，这次完成的演示仍不能证明周一的日历计划曾触发运行，也不能证明生产环境中无人值守工作的可靠性。

微软将创建者身份描述为在创建者权限范围内进行的委托访问，适用于采用用户身份验证的工具。智能体身份则使用在 Microsoft Entra ID 中单独配置的权限，工具通过密钥或托管身份完成身份验证。应逐一核对每个实际连接是否适合所选身份；设置了计划，并不等于获得访问授权。记录谁批准权限范围、谁能停用执行。采用创建者身份时，问清此人离职或权限变化后会怎样；采用智能体身份时，明确谁审查权限、谁维护连接。这些是建议开展的责任核查，并非两篇文章已经证实的身份生命周期行为。还应指定交付负责人，由其批准接收位置并处理发送状态不明的情况。否则，每个组件都可能报告成功，却没有人对缺失的报告负责。

先选一份范围明确的报告。查看触发与调用历史，核对发起事件、时间和已配置的执行身份，区分手动启动、日历触发与事件触发。接着，查找持久保存的任务接收记录、任务标识，以及事后仍能查询的状态。如果应用随后找不到任务，仅有 API 返回“已接收”并不够。然后取回完成的报告和支持它的来源，保留来源覆盖缺口。调用结束不一定意味着业务所需的成品已经完成，报告已保存也不能证明内容正确。最后，核对交付确认是否对应这份报告和已批准的接收位置。频道消息回执可以支持“已送达”的说法，却不能证明有人读过或认可了内容。应另行要求提供按计划执行的证据，并测试任务中断和回执丢失的情形。这些是建议进行的验收核查，不是本分析已经开展的测试。要把确认状态未知，与已确认失败、已确认送达分别记录：重试一次状态不明的发送，可能造成重复交付。