从空文件夹到云端智能体：Microsoft Foundry Canvas 实战解析

什么是 Microsoft Foundry Canvas

从一个空文件夹起步，到把一个托管智能体（hosted agent）部署上云——这个过程往往让开发者望而生畏，因为脚手架搭建、运行时配置、编排逻辑等基础设施工作会消耗大量精力。Microsoft Foundry Canvas 的目标正是把这些环节收敛到一个对话式面板中。

Foundry Canvas 是嵌入在 GitHub Copilot 应用中的一个扩展，以侧边面板的形式引导开发者完成智能体的构建与部署。它的核心机制是：当你在 Canvas 中做出选择时，每一步操作都会带着 Foundry 项目的上下文传递给 Copilot，由 Copilot 完成实际的代码生成和配置工作。开发者无需自己动手写脚手架代码。

所谓「托管智能体」，指的是由平台（这里是 Microsoft Foundry）在运行时、编排、执行层面全权管理的智能体。它被打包在一个自定义容器中，既可以本地运行，也可以原封不动地部署到云端。这种模式让开发者能把注意力集中在智能体的「行为」上，而不是基础设施。

Microsoft Agent Framework 是微软推出的一套用于构建、编排和部署 AI 智能体的 SDK 框架。它抽象了智能体与大语言模型交互的底层细节，提供工具调用（tool calling）、多步推理、状态管理等能力，开发者可以通过声明式配置或代码方式定义智能体的行为规则与可用工具集。Responses 协议是该框架支持的一种通信协议，与 Chat Completions 协议相比，它更适合有状态的多轮对话和流式输出场景，能够更细粒度地追踪每一步推理与工具调用的执行过程。Microsoft Foundry 则是微软 Azure AI 平台的托管服务层，提供模型部署、智能体运行时、可观测性和评估能力，Foundry Canvas 即构建在这一基础之上。

环境准备与启动流程

使用 Foundry Canvas 需要两个前置条件：安装 GitHub Copilot 应用，以及在其中安装 Microsoft Foundry Canvas 扩展。安装方式是在 GitHub Copilot 应用的 Customize（自定义）区域进入 Featured（精选）标签页，即可在顶部找到 Microsoft Foundry 扩展。

启动方式相当直接：在目标本地文件夹中打开一个新对话，输入类似「Create a Foundry hosted agent using Microsoft Foundry Canvas」的提示词，就会触发 Foundry 扩展，Canvas 随即在右侧面板打开。

Canvas 把整个流程拆成三个阶段：第一步创建托管智能体，第二步构建与自定义当前智能体，第三步部署与测试。在创建环节，Copilot 提供了一些预置提示词供开发者获取灵感，你也可以直接让 Copilot 协助你完成创建。此外，这一步还需要配置目标 Foundry 项目——智能体将被预置到该项目中，项目里也需要包含一个模型实例（示例中使用的是 GPT 5.4 mini）。

一个真实案例：Sparkles 纸杯蛋糕助手

视频演示以一个名为「Sparkles」的纸杯蛋糕店助手为例。这个智能体扮演一位友好的门店助理，帮助顾客下单预订纸杯蛋糕以便到店自取。它的业务逻辑包括：询问顾客 ID、为新顾客创建 ID、收集注册新顾客所需的信息，并且所有操作都通过一个专门配置的 Sparkles MCP 服务器来完成。

在实现层面，Copilot 被要求使用 Python、Microsoft Agent Framework 和 Responses 协议；在预置层面，则复用已存在的 Foundry 项目。提交提示词后，Copilot 开始基于这些选择在工作区中生成智能体代码。

通过点击 Visual Studio Code 图标打开工作区，可以看到核心逻辑位于 source 文件夹下的 main.py 文件中——它使用 Microsoft Agent Framework 构建智能体，接入 Foundry 托管模型，并写入了针对 Sparkles 店铺的指令（比如围绕顾客 ID 的检索与创建逻辑）。值得关注的一个细节是，Copilot 检测到项目中已存在一个包含 MCP 服务器的工具箱（toolbox），于是自动将其加入了智能体的工具集。

部署由两个 YAML 文件驱动：azure.yaml 负责预置 Foundry 项目和模型部署，toolbox.yaml 则作为连接工具箱的占位配置。

MCP（Model Context Protocol）是由 Anthropic 提出、目前已被多家厂商采纳的开放协议，用于规范大语言模型与外部工具、数据源之间的交互方式。MCP 服务器以标准化接口暴露工具（如数据库查询、API 调用），智能体运行时通过协议发现并调用这些工具，无需为每个工具单独编写适配代码。在 Sparkles 案例中，Sparkles MCP 服务器封装了「创建顾客」「创建订单」「列出纸杯蛋糕」等业务操作，智能体只需通过协议调用对应工具，而不必感知后端具体实现。Copilot 能够自动检测项目中已存在的 MCP 服务器并将其纳入工具集，正是得益于 MCP 协议的标准化描述能力——工具的名称、参数、用途均通过协议元数据自动可读，无需人工配置。

自定义、本地调试与部署

进入第二步自定义阶段，可调整的维度包括模型、工具箱、技能（skills）和护栏（guardrails）。以模型为例，如果项目中部署了多个模型实例，就可以在它们之间轻松切换，做对比分析。工具箱方面，演示中预配置了包含 Sparkles MCP 的工具箱（含创建顾客、创建订单的工具），以及一个 Web 搜索工具。

本地调试是这套流程中比较实用的环节。智能体在本地 8088 端口运行，通过 Agent Inspector 界面可以与本地智能体交互并查看执行链路（traces）。开发者能看到工具调用、逐段拼接生成的响应文本、MCP 服务器返回的工具调用结果，还能进一步检查工具调用细节、定位错误。界面同时展示 token 消耗，从而估算成本。

演示中完整走了一遍下单流程：请求一份 red velvet 口味 → 智能体询问顾客 ID → 作为新顾客提供姓名、姓氏、城市 → 智能体调用 register customer 工具注册 → 确认下单。整个交互过程中，多个工具（如 list cupcakes、register customer、order cupcake）被依次调用，订单最终在店铺仪表盘中生成。

测试满意后，点击部署即可在几分钟内把托管智能体推送到 Microsoft Foundry 云端。Copilot 还会建议开发者配置一套评估套件（evaluation suite）。部署完成后，在 Foundry 中就能看到已在云端运行的 Sparkles Concierge Agent。

Agent Inspector 是一类用于智能体本地调试的可视化界面，核心功能是以「执行链路（trace）」的形式展示智能体每一步推理与工具调用的完整过程。与传统应用调试不同，智能体的执行路径是动态的——模型会根据上下文决定是否调用工具、调用哪个工具、如何解读返回结果，因此可观测性尤为重要。通过 Inspector，开发者可以看到：模型的原始输入与输出、每次工具调用的请求参数与返回值、流式响应的逐段生成过程，以及每步消耗的 token 数量。这种可观测性使得调试不再依赖猜测，开发者能够精确定位智能体在哪一步产生了错误或偏差，对于涉及多工具串联的复杂业务流程尤为关键。

这套工作流的价值与意义

从空文件夹、一段提示词、一个应用，到运行在 Foundry 上的托管智能体，模型、工具箱和指令全部串联到位——整个闭环的核心价值在于「降低智能体开发的门槛」。

对开发者而言，最大的减负来自三方面：脚手架自动生成免去了重复的基础设施工作；本地 Inspector 提供了可观测性，让调试不再是黑盒；本地容器与云端部署的一致性避免了「本地能跑、上云出错」的常见问题。MCP 服务器的自动检测与接入，也体现了工具生态与智能体框架之间日益紧密的整合趋势。

需要留意的是，本文所述内容基于单一视频演示，实际生产环境中的稳定性、复杂业务场景下的表现，以及评估套件的具体能力，仍有待更多实践验证。但从演示呈现的完整度看，对话式构建智能体这一范式确实正在从概念走向可用。