「把7个算术工作流塞进一个Docker镜像，然后让另一个AI代理来决定先算加法还是幂运算。」——这不是什么实验室demo，而是Azure官方刚放出的方案。

他们解决了一个很具体的问题：企业里那些现成的自动化流程，怎么才能让AI代理直接调用，而不需要重写代码或搭新服务。

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

核心图：一个容器，两层角色

整个架构可以用一张图概括。底层是7个独立的HTTP触发工作流——加减乘除、取模、幂运算、开平方。它们被打包进同一个Docker镜像，跑在Azure容器应用（ACA）上。

关键配置只有一段host.json：

"workflow": { "McpServerEndpoints": { "enable": true, "authentication": { "type": "anonymous" } } }

这段配置让容器自己变成了MCP服务器。不需要额外进程，不需要sidecar，运行时直接把每个工作流暴露为MCP工具。

容器启动后，访问这个地址就能拿到全部工具清单：https://la-arithmeticmcp..westeurope.azurecontainerapps.io/api/mcp

上层是消费端。另一个叫BODMASAgent的Logic App收到数学表达式，比如(2 + 3) * 4^2 / 2，交给Azure OpenAI代理处理。

代理在循环里只有一个工具可用：指向上述MCP服务器的内置连接器。设计师界面会自动发现全部7个工具，让你勾选代理能调用哪些。

AI怎么"学会"算数学题

输入(2 + 3) * 4^2 / 2，代理自己拆解执行顺序：

第1步调用wf_arithmetic_add算2+3=5；第2步调用wf_arithmetic_pow算4²=16；第3步调用wf_arithmetic_mul算5×16=80；第4步调用wf_arithmetic_div算80÷2=40。

整个过程没有预编排代码。代理自己决定调用顺序和参数，每次工具调用都会触发容器里真实的工作流运行，返回结果后继续下一步。

内置MCP客户端连接器自动处理了会话初始化、工具发现、JSON-RPC封装这些底层细节。如果你想手动实现客户端，需要理解initialize如何建立会话、tools/list如何返回目录、tools/call如何触发工具。

为什么选容器应用（ACA）做宿主

这套方案本身支持多种宿主方式，但MCP服务器场景下容器有独特优势。

首先是隔离性。7个算术工作流跑在同一个容器里，但对外是一个统一的MCP端点。消费端不需要知道背后有多少个工作流，只需要关心工具清单。

其次是弹性。ACA支持基于HTTP流量的自动扩缩容。如果多个代理同时调用数学工具，容器实例可以横向扩展，而MCP端点地址保持不变。

最后是现有资产的复用。很多企业已经有大量工作流，原本通过HTTP触发器暴露。现在只需要加一段host.json配置，重新打包镜像，就能变成AI可调用的工具，不需要重写业务逻辑。

匿名认证背后的权衡

示例配置里用了"authentication": { "type": "anonymous" }，这在生产环境显然不够。

但微软选择先展示这个版本，可能是有意降低上手门槛。MCP协议本身支持多种认证方式，包括API密钥和OAuth。运行时在后续版本中加入更严格的认证配置是大概率事件。

当前方案的真正价值在于证明可行性：容器化的工作流可以无缝接入MCP生态，成为AI代理的"工具箱"之一。

从计算器到企业工具链

7个算术工作流只是个演示。实际场景中，这套模式可以承载更复杂的业务逻辑。

比如财务审批流程、库存查询接口、客户数据更新操作——任何已有HTTP触发的工作流，都可以按同样方式容器化、MCP化，然后被AI代理调用。

代理不需要理解业务细节，只需要知道工具名称、输入参数、返回格式。复杂的编排逻辑仍然留在原有的工作流里，由成熟的可视化设计器维护。