Copilot Managed Runtime CLI 实战：从本地开发到托管部署

Copilot Managed Runtime CLI 背后的托管运行时是什么

Copilot Managed Runtime 是内部业务应用的托管平台。代码仍可编辑，源代码管理仍使用真正的 Git；Microsoft 则负责托管运行时、Microsoft Entra 登录、受治理的数据连接、预览与部署机制，以及面向管理员的应用清单。

可以把它理解成一座为代码提供服务的办公楼。每个房间里做什么，仍由你设计；大楼负责门禁、公共设施、安全规则、维护记录和物业团队。这和只生成“房间布局”的 AI 编程界面并不是一回事。

Microsoft 将这套 SDK 定位为内部业务线应用的开发层。它内置 Entra 身份验证，无需自行编写身份代码；JavaScript 和 TypeScript 可访问超过 1,500 个连接器，但应用究竟能使用哪些连接器和操作，仍由租户策略决定。公开预览阶段的边界，可以从 SDK 概览和发布公告中确认。

本文只讨论当前可用的 SDK 和 CLI，不会把 Copilot Code 或 Autopilot 当成这套工具链的别名。

应用在每个阶段究竟存放在哪里

应用所处的生命周期阶段不同，答案也不同：

这种分离非常关键：预览版可以持续前进，线上版仍保持稳定；新的预览构建即使失败，也不会替换上一个成功版本。

先检查准入条件，再写代码

最浪费时间的做法，是等应用完成后才发现租户或许可证不满足要求。动手前先核对以下 5 项。

计费方式和管理策略需要单独做预算决策。在向试点用户开放前，建议先阅读 Copilot Managed Runtime 价格拆解。本文只强调一个容易忽略的操作细节：本地运行并不是绕过费用的办法，它与最终用户运行需要相同的运行时许可。

本文实际验证了什么

软件包检查确实执行过，但租户端流程没有跑通。

因此，本文不会声称测出了首个本地页面或托管预览所需的时间，也没有实际观察构建失败、检查 Entra 身份、调用连接器、执行部署或产生运行时账单。下面给出的是 Microsoft 文档规定的流程，不是伪装成实测结果的实验报告。

用 CLI 跑通一个小型运营应用

这里使用一个名为 Ops Intake 的模拟应用。第一版只做一件事：从租户批准的数据源读取记录，并以只读队列展示。先从读取操作入手，可以让首次策略审查保持清晰；等身份、源权限、连接器策略和运行时许可全部验证通过，再加入写入能力。

为保证可复现，以下命令固定使用 2026 年 9 月 27 日验证过的 CLI 版本。你也应在仓库中记录自己选定的版本，避免预览版软件包更新后悄然改变试点行为。

npm install -g @microsoft/managed-apps-cli@0.25.1
ms --version

ms auth login
ms app create ops-intake --display-name "Ops Intake"
cd ops-intake

npm install
ms app dev

ms connector list --search SharePoint
ms connector list-actions --connector <allowed-connector-id> --search list
ms app add data-source --connector <allowed-connector-id>

git add .
git commit -m "first ops intake flow"
git push

ms app play --mode preview
ms app build-status
ms app deploy

下面逐步解释每一次状态转换。

1. 登录并创建受治理的应用外壳

ms auth login 会打开 Microsoft Entra 登录。在无界面的机器上，CLI 还支持 --device-code。ms app create 会创建应用记录和项目脚手架，默认使用平台管理的 Git 仓库。如果环境路由允许，首次执行 create 或 init 时，还会为制作者配置与其身份绑定的开发者环境。

不要随意选择仓库模式。平台管理的 Git 启动最快；外部仓库则可使用 GitHub.com 或 GitHub Enterprise Cloud。这条路径不支持 GitHub Enterprise Server、Azure DevOps 和其他提供商。仓库模式在应用的整个生命周期内都不能更改，之后想切换，只能重新创建应用。

2. 在本地运行，并记录首次可用耗时

先安装一次脚手架项目所需的依赖，再运行 ms app dev。该命令会读取 ms.config.json，启动项目的开发进程，并输出 Local Play URL。请在已登录该租户的同一个浏览器配置文件中打开它。

执行 ms app dev 前立即开始计时，首个可用页面渲染完成后停止，并单独记录浏览器权限造成的中断。Chrome 和 Microsoft Edge 可能会阻止公共来源访问 localhost，直到用户授予本地网络访问权限；这是浏览器关卡，不是应用构建失败。

3. 验证一次受治理的读取操作

ms connector list 会显示连接器 ID、身份验证类型、表格数据支持情况，以及 Data Loss Prevention 和 Advanced Connector Policy 的状态。应以该输出作为当前环境的判断依据。某个连接器出现在 Microsoft 目录中，并不代表你的租户一定允许使用。

在 Ops Intake 中，选择一个获准的 SharePoint 连接、数据集和列表，再选取读取或列表操作。交互式 ms app add data-source 流程会在 generated/ 目录下生成带类型的 TypeScript 模型和服务。应用应调用生成的读取方法，而不是自行拼装原始 Graph 令牌流程。

请在浏览器中确认 3 件事：

1. 当前登录用户就是预期的 Entra 身份。
2. 该用户只能看到源系统原本允许其访问的记录。
3. 当同一用户失去数据源访问权限时，应用能够安全失败。

以后共享应用，并不会同时授予底层数据的访问权限。每个接收者仍需具备正确的数据源权限和连接。这是治理能力，不是部署障碍。

4. 提交并推送真实源代码

继续使用常规 Git 命令即可；运行时 CLI 不会取代源代码管理。提交内容应包括已可工作的应用改动，以及项目所需的连接器绑定生成文件。

最需要记住的陷阱很简单：git push 不会构建应用，它只会更新远程仓库中的唯一可信源代码。

5. 打开托管预览并检查构建结果

ms app play --mode preview 会打开固定的预览端点。如果最新推送的提交尚未构建，打开预览就会将其加入构建队列。请记录从打开预览到新版本就绪所需的时间。

如果构建失败，运行 ms app build-status；也可以加上 --commit <sha>。将完整失败原因与对应提交一起保存。新版本仍在构建或已经失败时，预览会继续提供上一次成功构建。预览 URL 只面向对仓库拥有写权限的开发者，并不能随意发给评审人员使用。

如果希望在打开预览前启动构建，可以运行 ms app build。不过，多数团队应先掌握默认行为：推送源代码，然后打开预览。

6. 只部署已经检查过的版本

ms app deploy 会把一次成功构建发布到线上应用。线上版是固定快照，不会跟随每次推送或预览构建自动变化。

要进行可控发布，请记录提交 SHA、查看构建状态并打开该提交的预览，确认无误后再运行 ms app deploy --commit <sha> 部署。使用同一参数还可以干净地回滚到较早的成功构建，无需重写 Git 历史。

平台层改变了成本结构

这套运行时不会让应用开发变成零成本。它改变的是：哪些能力需要团队另行采购或自行搭建。

可对比的软件预算并不低。Retool 官方价格页显示，Team 套餐每位构建者每月 $10、每位内部用户每月 $5；Business 套餐则分别为每月 $50 和 $15。Copilot Managed Runtime 不会天然比这些价格更低。对于 Microsoft 365 组织，它可能省去单独的平台工程，但运行时许可证或 credits、连接器工作和管理时间仍是真实成本。

在认定它更便宜之前，先用下面的公式核算试点：

试点成本 = 开发时间 + 管理设置 + 运行时许可 + 连接器与数据工作。

最有可能下降的是平台搭建成本，最容易带来意外的则是每一位应用用户所需的运行时许可。

适合这套运行时的 7 类内部应用

最合适的候选项目，是那些更看重身份、受治理的 Microsoft 365 数据和可控发布，而不是公共店面的内部工作流。

每个用例都应从只读开始。加入写入操作、外部端点、第三方连接器或广泛共享应用，都会改变审查范围。默认策略只包含 18 个 Microsoft 第一方连接器，而不是整个目录；即使连接器已经获准，其中一些开放式 HTTP、任意代码、任意查询和任意平台操作仍会被阻止。

值得围绕这套运行时打造的 3 类产品

最有潜力的产品，是 Microsoft 365 新员工入职指挥中心。它既对应实测需求最高的方向，工作流又天然横跨身份、文档、任务、邮件和团队交接。

1. Microsoft 365 新员工入职指挥中心

打造一个内部应用，让 HR 和 IT 在同一处查看获准的新员工记录、待办任务、文档链接和负责人。HR 运营与 IT 服务团队愿意为更少的交接遗漏和更简单的审计链路付费。

需求已有数据支撑：“employee onboarding software”在美国每月约有 590 次搜索，具备商业意图，每次点击成本为 $156.35。更具体的 “best employee onboarding software”每月有 90 次搜索，建议数据中的年度趋势增长为 180%。

最小可售版本只服务一个部门：读取一份获准的员工列表，展示任务清单，并把每项任务链接到负责人。只有只读路径通过策略和权限测试后，再加入连接器操作。

但这里的风险不容忽视。HR 数据十分敏感，数据源权限也很容易被误解，而且成熟的入职软件厂商已经覆盖更广泛的 HR 工作流。只有当 Microsoft 365 治理和租户原生运行比通用而冗长的功能清单更重要时，这款产品才有胜算。

2. 受治理的审批工作台

为财务、采购或运营团队打造可复用的审批界面：它们有明确的决策状态，却常常缺少集中呈现的佐证上下文。客户购买的是更快的审核和可控的发布流程，而不是又一个表单生成器。

“Approval workflow software”在美国每月约有 320 次搜索，具备商业意图，每次点击成本为 $114.86；建议数据中的年度趋势增长为 53%。这些信号说明，市场正在主动寻找解决方案，也给专注 Microsoft 365 的实现留下了空间。

MVP 只包含一种请求类型、一个获准的数据源、只读审核界面、决策历史，以及一个经过策略批准的操作。决策模型必须保持确定性，不要把审批规则藏进生成式文本中。

主要障碍仍是连接器策略。即使某个连接器获准，具体操作也可能被阻止；经典数据策略还可能与 Advanced Connector Policies 叠加，并以限制最严格的结果为准。

3. 托管应用迁移评估

把评估做成标准化服务：接手一个 AI 生成或定制开发的内部 Web 应用，判断它能否迁移到 Copilot Managed Runtime。目标客户是已有可用原型，却不想再维护一套独立托管和治理栈的 Microsoft 365 组织。

“Custom business app development”在美国每月约有 90 次搜索，具备商业意图，每次点击成本为 $84.03。搜索量较小，但这个查询已经非常接近服务采购阶段。

MVP 需要盘点应用的仓库、运行时假设、外部端点、身份代码、数据源和必要操作，然后给出“可迁移、需改造或停止”的判断，并把一个只读功能切片移植到测试环境。

风险在于平台集中化。该服务只适用于符合条件的 Microsoft 365 租户；公开预览行为可能变化，不受支持的源代码提供商或被阻止的外部资源，也可能让看似简单的迁移演变成重建。

Copilot Managed Runtime 解决不了哪些问题

它是受治理内部应用的一条可期待路径，却不是通用应用平台。

• 该功能仍处于公开预览阶段，文档也属于预发布版本，因此命令行为和策略界面都可能变化。
• 即使租户符合运行时条件，通过 CLI 创建应用的路径也不会自动开放；该路径默认关闭。
• 它不会让超过 1,500 个连接器全部成为可用数据源。租户策略、连接器操作策略、经典数据策略和源权限仍共同决定访问结果。
• 它不会把内部业务线应用变成面向公众的客户产品。预览仅限拥有仓库写权限的开发者；线上访问则需要在治理模型内主动共享。
• 它不支持所有仓库提供商。外部源代码仅限 GitHub.com 和 GitHub Enterprise Cloud，且仓库模式不能原地更改。
• 它不会取消运行时许可要求。本地运行和用户运行都需要 Power Apps Premium，或有资金支持的 Managed Application Copilot Credits。
• 它不会给管理员一份完美的取证记录。管理视图涵盖应用清单、用量、运行状况、连接器、数据源和依赖关系，但 Microsoft 明确表示，它无法完整展示精确目标、动态端点、实际执行的操作或每位用户在数据源中的有效权限。
• 它也不能证明本文作者完成过部署。由于缺少 Git Credential Manager、Linux 密钥存储库以及符合条件的租户，本次流程在登录前就已停止。

决策边界其实很清楚：如果应用只供内部使用、组织本就深度使用 Microsoft 365，而且省下来的身份与治理工作足以抵消采用预览平台及租户控制的代价，就值得尝试。如果需要公共 SaaS 产品、其他源代码提供商、基础设施控制权，或管理员无法批准的发布模型，则应选择其他托管方式。

常见问题

下周一就做这一步

请一位 Power Platform 管理员为一个测试组启用 CLI 创建权限，确认该组对应的环境路由规则，并为两名测试用户准备运行时许可。选择一个不含敏感数据的 SharePoint 列表和一个只读操作，然后让开发者在试点日志中记录 4 项信息：CLI 版本、首个本地页面耗时、托管预览耗时，以及实际部署的提交 SHA。如果 Entra 身份、数据源权限或连接器策略与书面预期不一致，就停止试点。

如果希望为你的企业规划并落地这条受治理的应用路径，可以先从 AI 生产系统评估开始。