接上回。Part 2里,我花了3小时、踩了8个坑,终于用Power Automate把REST API跑通了。但流程刚通,我就忍不住想:有没有更短的路?

有。答案叫MCP。

打开网易新闻 查看精彩图片

这次我没建任何自动化流,没配轮询循环,没调HTTP连接器——直接把LDX hub的MCP服务器接进Copilot Studio agent。全程2小时,大半时间耗在两个藏得很深的设置上。

以下是完整记录。

环境配置

• Microsoft Copilot Studio(Kawamura International租户)
• LDX hub MCP服务器(https://gw.ldxhub.io/mcp)
• 现有agent:Minutes Assistant(議事録アシスタント)
• 耗时:约2小时

为什么弃Power Automate选MCP?

Part 2的REST API路线能跑通,但代价不小:

• 要搭Do Until轮询循环
• HTTP连接器颜色陷阱(白标vs绿标)
• triggerBody()引用报错
• 异步结果的变量类型管理

MCP把这些全砍了。agent直接调工具——没有中间层,没有要维护的流。如果你的场景能接受这个tradeoff,上线速度快得多。

当然,tradeoff真实存在:MCP更适合交互式、单条记录场景。批量处理20个文件?Power Automate仍是正解。这部分留到Part 4展开。

背景与目标

Kawamura International正在全公司推进生成式AI驱动的业务流程。这次验证的核心,是把LDX hub的StructFlow(结构化数据提取)集成进"Minutes Assistant"——自动从会议记录中提取:

• 任务与行动项(含负责人、截止日期)
• 已做出的决策
• 按发言人整理的摘要
• 下次会议议程候选

架构链路

用户(粘贴会议记录)

Copilot Studio "Minutes Assistant"
↓ MCP tools/call(Streamable HTTP)
LDX hub MCP服务器
↓ createStructFlowJob
StructFlow引擎(异步任务)
↓ getStructFlowJob(轮询)
结构化JSON结果

Copilot Studio格式化输出

第一步:连接前验证端点

碰Copilot Studio之前,先确认LDX hub MCP端点符合要求。

⚠️ 关键提醒:SSE传输协议已于2025年8月废弃

Copilot Studio已移除SSE支持,现仅接受Streamable HTTP。连接前务必核实协议版本。

PowerShell验证命令:

$headers = @{
"Content-Type" = "application/json"
"Accept" = "application/json, text/event-stream"
"Authorization" = "Bearer YOUR_API_KEY"
}
$body = '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'
$r = Invoke-WebRequest -UseBasicParsing -Uri https://gw.ldxhub.io/mcp -Method POST -Headers $headers -Body $body

返回状态200且包含serverInfo,说明端点就绪。

第二步:Copilot Studio端配置

进入agent设置 → 知识 → 操作 → 新增操作 → 选择"MCP服务器"。

这里藏着第一个坑:Transport类型必须选"Streamable HTTP",默认的SSE选项会直接导致连接失败——但界面不会提醒你SSE已废弃,只会报模糊的连接错误。

第二个坑在认证头。LDX hub要求Bearer token格式,但Copilot Studio的"API密钥"字段会自动添加"Bearer "前缀。如果你在密钥框里手动写了"Bearer ",实际发出的是"Bearer Bearer xxxx",必然401。

正确做法:密钥框只填纯token,前缀交给系统自动处理。

第三步:工具暴露与测试

连接成功后,LDX hub暴露两个核心工具:

1. createStructFlowJob - 提交异步提取任务
2. getStructFlowJob - 轮询查询任务状态

在Copilot Studio的"操作"面板中,这两个工具会自动生成对应的动作卡片。但别急着发布——先点"测试"跑通端到端。

测试时的典型失败:agent调用createStructFlowJob后,不会自动轮询getStructFlowJob。需要显式在对话流中加入"调用操作"节点,把jobId传给getStructFlowJob,并设置重试逻辑直到status为completed。

这里省下的时间,正是Power Automate里Do Until循环的等价替代——但MCP版本更透明,调试时能看到每次轮询的原始响应。

耗时对比

路线 | 总耗时 | 核心障碍
REST API + Power Automate | 3小时 | 连接器配置、轮询循环、变量类型
MCP直连 | 2小时 | 两个隐藏设置(传输协议、认证头格式)

1小时的差距,本质是"可视化编排的复杂度"vs"协议层配置的隐蔽性"。

当前局限

MCP路线并非万能。实测发现:

• 单条会议记录处理流畅
• 批量提交场景下,agent对话上下文会膨胀,需手动清理
• 超时控制不如Power Automate精细(无图形化重试策略配置)

这些边界条件,正是Part 4要对比的决策框架:什么场景该用MCP,什么场景必须回Power Automate。

下一步

Minutes Assistant现已上线内部测试。Part 4将整理完整决策矩阵——包括成本、维护负担、扩展性三个维度的对比。