在 Agent 与 Power Automate 之间搭建最佳桥梁

📢 本文同步发布於公众号：Power Platform · 最佳实践
🔗 原文链接：https://johnliu.net/blog/building-the-best-bridge-between-your-agent-and-power-automate/

哈，Agent，有时候你真是让人哭笑不得。

不过说句公道话，有时候平台才是先犯傻的那个。

当 Agent 在 Power Automate 上工作时，一些微小的不匹配就可能演变成无限循环：

最好的 Agent 桥梁，不是说得最多的那个，而是说得刚刚好——让 Agent 持续推进，又不会用模型早已理解的重复信息塞满上下文。

这正是我们在 Flow Studio MCP 中一直在收紧的那类故障模式。

目标不仅仅是将 Power Automate 暴露为一堆端点。真正的目标是让这座桥梁足够好用，好到 Agent 能自己完成工作，而不需要我们时刻盯着。

1. 更好的提示，但只在有帮助时

我们最先改进的事情之一，是 Power Automate API 返回的 REST 错误。

有时候，原始错误在技术上是对的，但在操作层面毫无用处。

对于阅读日志的人类来说，这条消息可能足以推断出哪里出了问题。但对于 Agent 来说，同样的消息可能模糊到让它走上错误的道路。

所以我们会记录 PA API 的 REST 错误，当我们判断 Agent 即将陷入困惑时，就给它一个更好的提示。

这听起来是小事，但影响很大。

Agent 不需要听一堂课。它只需要足够的信号来停止原地转圈。

我们有时也会克制自己，因为有些 API 错误本身已经非常清晰，Agent 可以直接恢复。在这些情况下，更多的提示只是重复，而重复只会白白堵塞你的上下文，没有任何实际收益。

所以多不一定好，少也可以是更多。

好的工具通常就是这么回事——更少的困惑，更少的折腾，更多实际完成的工作。

我们也在持续对工具本身做小而重要的更新。

比如，update_live_flow_state 在纸面上听起来很简单：启动流程、停止流程、报告结果。

update_live_flow_state

我们还确保 Agent 可以从非标准状态（比如 suspended）启动或停止流程，这样连最后 0.1% 的奇葩情况也覆盖到了。

这就是那种只看“快乐路径”的人会跳过的东西。

但快乐路径不是全部路径，远远不是。

这类修复在更新日志里看起来平平无奇，但在真实世界中，它们让工具用起来少了很多烦恼。

我们还注意到，有些 Agent——尤其是通过 Bot Framework 托管的时候——在正确序列化 JSON 方面会遇到困难。

当你的工具契约期望一个干净的 JSON 定义时，这就很不理想了。

所以我们增加了对字符串化流程定义的支持，而不再只要求结构化的 JSON 规范。

这是一个务实的修复，不是哲学层面的选择。

我们身处的世界充满了中间件、包装器、传输层和宿主环境，它们各自对载荷有自己的假设。如果对某个宿主来说最实际的路径是发送字符串化的……