Windows Agent Launchers：统一注册、发现和调用桌面 AI 智能体

1. 一句话结论

Windows Agent Launchers 是 Windows 上统一注册、发现和调用交互式 AI 智能体的框架，使应用无需为每个入口重复编写专用集成。[S1] 它建立在 App Actions 与本机注册机制上，适合桌面 Agent 生态互操作，但仍需开发者自行实现权限、身份、界面和具体任务能力。[S1][S2]

2. 框架定位

Agent Launcher 是一个已注册的智能体入口，支持系统或应用发现并打开相应交互界面。[S1] 该框架面向持续对话、保持上下文并能执行任务的可见 Agent，而不是静默后台服务。它解决的是发现与调用标准化，不规定模型、推理框架或业务工具必须采用哪家实现。

3. 核心组件

官方概览列出 Agent 定义 JSON、应用包中的扩展声明，以及带必要输入实体的 App Action。[S1] 定义文件保存名称、描述、唯一标识和调用动作；应用声明负责注册；动作接收 agentName、prompt 及可选附件等输入。[S1][S2] 三者必须保持一致，否则 Agent 可能可见却无法正确启动。

4. 注册与发现

开发者可在安装时静态注册，也可根据登录、订阅或运行状态动态注册。[S1][S2] 注册信息进入 On-Device Registry，并可由支持体验查询。动态方式更灵活，但需要处理注销、过期身份和多账号切换；静态方式更简单，却可能展示当前用户无法使用的入口。

5. 调用流程

支持端先查询本机注册表，选择目标 Agent，再通过关联 App Action 传递提示和上下文并打开应用界面。[S1] 这让开始菜单、搜索或其他应用可用一致方式触达不同提供方的 Agent。调用成功不等于任务成功，提供方仍需展示进度、错误、确认步骤和最终结果。

6. 适用场景

适合已有 Windows 应用和可见交互 Agent，希望被系统入口或合作应用发现的团队。纯云端 API、无需用户界面的批处理或只在单一应用内部使用的助手，未必需要该框架。若 Agent 会执行文件、邮件或业务系统动作，应在应用内部继续实施最小权限和明确确认。

7. 开发路径

官方入门流程从实现 Action Provider 开始，随后加入所需输入实体、测试 App Action、创建 Agent 定义、选择静态或动态注册，并验证列举和调用。[S2] 最稳妥的试点是只接收文本提示并返回只读结果，确认发现、启动、上下文传递和错误处理后，再逐步增加附件与写动作。

8. 主要风险

风险包括恶意应用仿冒 Agent、注册信息陈旧、输入附件越权、调用者和提供者对权限理解不一致，以及系统预览行为变化。统一发现也可能让用户误以为所有 Agent 都经过同等审核。界面应明确提供方、当前账号、将使用的数据和即将发生的动作，并允许用户取消。

9. 验收建议

分别测试安装注册、动态注册、注销、升级和卸载，确认本机注册表没有残留。调用测试要覆盖空提示、超长输入、无效附件、未登录状态和应用崩溃，并确认错误可见且不会静默执行。再从两个不同支持入口调用同一 Agent，核对身份、上下文和结果一致，才算互操作闭环完成。

10. 来源与更新时间

• 信息截至(as_of)：2026-08-12
• [S1] Tier1｜Microsoft Learn：Agent Launchers on Windows overview｜链接｜访问日期：2026-08-12
• [S2] Tier1｜Microsoft Learn：Get started with Agent Launchers on Windows｜链接｜访问日期：2026-08-12