Copilot Studio 工作流：无人值守自动确认 D365 采购订单

人工在聊天窗口里敲一句话，让 AI 代理去调用工具——这已经是上一代做法了。本文要拆解的方案，来自一位 YouTube 技术博主的实操演示：把同一个 X++ 工具改造成 Dataverse 自定义 API，再在 Copilot Studio 里编排成工作流，实现「订单全部成功则静默结束，一旦失败才唤醒代理排查并推送 Teams」的无人值守闭环。

据该视频演示，整个链路的关键不在代理本身，而在于把工具的触发权从「人」手里交给「工作流」。下面按搭建顺序还原这条链路，并补充其中容易被忽略的设计取舍。

从聊天触发到事件触发：思路的转变

上一期视频里，博主构建了一个 X++ 类 Purchase Order Confirm Custom，为它加上自定义 API 属性，代理通过 MCP 发现了这个工具并能自主调用。但流程上仍有一处断点：每次确认订单，都得有人进聊天窗口发消息。

新方案的核心思路是把代理从「主流程」降级为「异常处理者」。工作流负责常规动作——调用工具确认订单；代理只在失败分支被唤醒，负责诊断原因、给出修复建议。这样既压低了 token 消耗与响应延迟，也让 AI 的介入点落在真正需要判断力的地方。博主在视频中反复强调这一设计：代理只在「东西真的出问题」时才被调用。

MCP（Model Context Protocol） 是 Anthropic 提出的一种开放协议，用于让 AI 代理以标准化方式发现和调用外部工具。在本文场景中，X++ 类通过自定义 API 属性暴露后，代理借助 MCP 自动识别到该工具及其参数定义，从而在聊天中自主调用。MCP 的价值在于解耦：工具提供方只需按协议描述能力，代理无需硬编码每个工具的调用细节。不过，MCP 目前主要面向交互式代理场景，本文主流程改用工作流直接调用 Dataverse 动作，正是为了绕开「必须有人发起对话」的限制，把触发权交给事件或定时器。

前置准备：让 Dataverse 能触达 Finance and Operations

工作流在 Dataverse 中查找可调用的动作，所以第一步是把 X++ 工具暴露为 Dataverse 可识别的自定义 API。Finance and Operations 保留自己的数据库，但环境与 Dataverse 相连，配置到位后 Dataverse 就能反向调用 F&O 中的类。

需要在 Power Platform 管理中心为环境安装两个应用：

• Finance and Operations Virtual Entities：把 F&O 数据实体以虚拟表形式带入 Dataverse，读写直接作用于 F&O 而非复制数据。自定义 API 依赖它——微软插件会把每次调用转交给一张特殊的虚拟表，再由该表把请求递到 F&O 里的类。安装约需 15 分钟。
• Copilot for Finance and Operations apps：提供让 Dataverse 执行 X++ 代码的 Copilot 插件，创建自定义 API 时会用到其中之一。耗时更长，约 1 小时。

博主特别提示了一个新手容易踩的坑：在全新沙箱环境中创建解决方案可能报错，原因是 F&O 正在重试同步供应商互动应用的虚拟表，同步期间解决方案创建会失败。规避办法是把 CDS 虚拟实体自动创建批处理作业的下一次运行时间往后调。

虚拟表（Virtual Entities） 是 Dataverse 的一种机制，它不在 Dataverse 中存储数据副本，而是把外部系统（如 F&O）的数据实体映射为看起来像本地表的结构，读写操作实时转发到外部系统。本文中，微软插件将自定义 API 的每次调用转交给一张特殊的虚拟表，再由该表把请求递到 F&O 里的 X++ 类。这样做的好处是数据始终以 F&O 为唯一事实来源，避免同步延迟和一致性问题；代价是每次调用都依赖网络往返和 F&O 侧的可用性，且虚拟表的元数据同步可能引发本文提到的沙箱解决方案创建失败。

手工搭建自定义 API：八个组件对齐一个类

在 Power Apps 中创建解决方案作为容器，先新建发布者（演示中命名为 erp digest，前缀 int），再创建自定义 API。关键字段设置：

• 绑定类型为 global，对应工作流中调用的「非绑定动作」；
• 插件类型选择微软的 InvokeNoCustomAPI 插件，它是 Dataverse 调用 F&O 类的桥梁。

接下来的工作是把类上的 3 个输入、4 个输出逐一映射为请求参数与响应属性。博主强调命名必须严格对齐：参数的 Name 必须与类上的数据成员名完全一致（如 purchase_order_numbers），因为 F&O 靠这个名字找到对应输入；Display Name 只是给人看的标签，可以自由填写。

类型	名称	数据类型	是否可选
请求参数	purchase_order_numbers	string	否
请求参数	stop_on_first_failure	boolean	是
请求参数	company_id	string	是
响应属性	confirm_count	integer	—
响应属性	failed_count	integer	—
响应属性	results_json	string	—
响应属性	company	string	—

八个组件加一个自定义 API，全部手工录入。博主对此直言不讳：理想情况下这些应该能从类自动生成，但目前没有这个能力，只能手搭，希望微软后续补上。这是当前方案最明显的效率短板，也是读者评估落地成本时应当计入的部分。

绑定类型（Binding Type） 决定了自定义 API 在 Dataverse 中的调用方式。global 对应非绑定动作（Unbound Action），调用时不需要指定实体记录作为上下文，适合本文这种「传入订单号列表、返回批量结果」的批量操作。相对地，绑定类型若设为 entity，则动作必须关联到某条具体记录，调用时需提供记录 ID。在 Copilot Studio 工作流中，Perform an unbound action 步骤正是用来调用 global 绑定的自定义 API，因此绑定类型选错会导致工作流中找不到该动作。

在 Copilot Studio 中编排工作流

进入 Copilot Studio，切到同一环境，新建工作流并命名为 confirm purchase orders agent flow，画布切换为纵向布局便于阅读。触发器暂时保持 manual 以便测试，后续可改为定时计划（例如每晚执行）。

输入与工具调用

添加两个文本输入：purchase order numbers（逗号分隔，需已审批）与 company ID（如 USMF）。随后在开始卡片下添加 Perform an unbound action（Microsoft Dataverse），粘贴自定义 API 的唯一名称选中它，填入三个参数。其中 stop on first failure 保持 no，确保每张订单都被尝试、每张都有结果。

失败分支：条件判断与代理唤醒

在动作之后加一个 If/Else 条件：取 failed_count，判断是否大于 0。全部成功时走 else 分支，工作流直接结束；至少一单失败时走 if 分支，这里挂上代理步骤——从代理列表中选择已有的 ERP 代理，并粘贴一段提示词，把失败订单交给代理排查原因、建议修复方式，同时明确约束：只做调查和建议，不得自行确认或修改任何订单。

提示词中的两个占位符分别用动作输出的 company 和 results 填充。最后的输出保留为文本响应，供 Teams 消息引用。

提示词中的占位符在 Copilot Studio 代理步骤中通过动态内容插入，运行时由上游动作的输出填充。本文用 company 和 results 两个占位符把失败订单的上下文传给代理，代理据此调查根因。需要留意的是，占位符的内容会直接进入代理的上下文窗口，若 results_json 体积较大，可能挤占代理的推理空间或增加 token 消耗。对于批量失败场景，建议在传入前先做截断或摘要，只保留失败订单的关键字段，而不是把完整 JSON 原样灌入。

把诊断结果推到 Teams

代理步骤之后添加 Post message in a chat or channel（Microsoft Teams），Post as 设为 Flowbot，发布位置选 chat with Flowbot——消息以机器人私聊形式送达，而不是来自任何人的个人账号。收件人填入邮箱即可解析到对应账号。

消息模板包含标题、摘要行、代理调查结论和原始结果四个占位符，分别映射到动作输出的公司、确认数、失败数，代理步骤返回的 investigation，以及动作输出的 results_json。

实测：一单失败，两分钟闭环

保存并发布后，博主用订单 42、公司 USMF 做测试——特意选这张单，因为预算控制会拒绝它，正好验证失败分支。

运行过程：非绑定动作约 8 秒完成，工作流进入 if 分支，代理开始调查，整个运行约 2 分钟后成功结束。查看运行详情，输入为订单 42 与 USMF，输出中 confirmed count 为 0、failed count 为 1，results_json 里带有该订单的结果。代理步骤返回三个值：会话 ID、状态 completed、以及以「订单 42 的根本原因」开头的结果文本。

Teams 中 Flowbot 的消息显示：公司 USMF，0 单确认、1 单失败。代理的调查报告指出，订单 42 是一张已审批的、金额 3000 美元的开放广告订单，其唯一行项目过账到单一分类账账户，而预算检查显示该账户资金不足，3000 美元全额超出预算及阈值。修复建议有两条：向该账户过账一笔不低于 3000 美元的已审批预算转移；或者如果账户本身有误，更正行项目的会计分配后重新运行预算检查，再行确认。

消息底部的原始结果显示 F&O 返回的信息：订单 42 的过账超出该账户可用预算资金 3000 美元——与代理结论完全吻合。这一步交叉验证是整段演示最有说服力的地方：AI 的诊断不是凭空生成，而是可以从原始报错中逐条对照。

这套方案的价值与边界

值得肯定的是架构层面的取舍：用条件分支把 AI 调用限制在异常路径上，常规流程零人工、零对话；代理被约束为只读调查角色，避免自动改单带来的业务风险；诊断结果直接落到 Teams，责任人无需登录额外系统。

需要清醒看待的是成本与维护负担。两个前置应用安装合计约 1 小时 15 分钟，自定义 API 的八个组件全部手工创建且命名必须与 X++ 类逐一对应，类一旦变更就要同步改 Dataverse 侧——这正是博主呼吁微软提供自动生成能力的原因。此外演示中的触发方式仍为手动，真正落地为定时或事件驱动后，还需处理并发运行、失败重试和消息去重等工程问题，视频未涉及这些部分。

对于已经运行 F&O 与 Power Platform 的团队，这条路径提供了一种低侵入的 AI 增强方式：不改动核心业务逻辑，只在 Dataverse 层加一层可编排的壳。