Microsoft Foundry上手：Agent发布前的测试场

微软的 Microsoft Foundry 提供了一个集中的 Agent 开发环境。在正式发布之前，开发者最该花时间的地方不是写代码，而是那个看起来不起眼的 playground——它是验证模型行为、指令遵循和工具调用的第一道防线。

三种起点，殊途同归

进入 Foundry 后，平台给出三个入口：从头构建 Agent、直接部署模型，或者用代码起步。对于想快速看到效果的人来说，从「构建 Agent」开始阻力最小。给 Agent 起个名字、点下创建，平台会在后台完成初始化，然后直接把人送进 playground。

这个设计意图很明确：缩短从「想做」到「能试」的距离。不需要先搞定环境配置或脚手架，创建动作本身就完成了资源准备。

模型部署与 Agent 构建的区别

「部署模型」入口面向的是只需要模型推理能力的场景，部署完成后得到一个可直接调用的端点，不包含指令编排和工具调度逻辑。「构建 Agent」则在此基础上叠加了系统指令、工具集和对话状态管理，本质上是在模型之上封装了一层行为控制。两者并不互斥：同一个已部署的模型可以被多个 Agent 引用。对于需要多轮对话、外部工具调用或特定角色设定的场景，走 Agent 构建路径更合适；如果只是做单次文本生成或分类，直接部署模型反而更轻量。选择哪个入口，取决于你是否需要「行为」而不只是「能力」。

Playground：发布前的唯一真相

落地 playground 后，界面围绕四件事展开：选模型、写指令、配工具、直接对话。这四项恰好对应 Agent 上线后最常出问题的环节——模型选错、指令模糊、工具没接对、实际对话跑偏。

演示里用了一个最简单的 hello world 提示词去确认链路通畅。这个动作看似平淡，但它是必要的基线检查：先确认能拿到响应，再去调优复杂逻辑。如果连基础问答都不稳定，后面叠加的指令和工具只会放大问题。

真正值得关注的是这四项配置的组合效应。模型能力决定上限，指令决定行为边界，工具决定可执行范围，而对话界面把这些一次性暴露出来。

Playground 与真实 API 的关系

Playground 并非独立的模拟环境，它背后调用的是与生产部署相同的模型端点与工具连接器。也就是说，在 playground 中观察到的响应延迟、工具调用成功率、指令遵循程度，基本可以外推到正式发布后的表现。差异主要出现在配额、并发和鉴权上——playground 通常使用开发级配额，而生产环境有独立的吞吐限制。因此，playground 适合验证行为正确性，但不适合做压力测试或成本核算。理解这一点能避免两种误判：一是把 playground 的稳定表现当成生产保证，二是因为 playground 偶发超时就否定整体方案。

为什么「先测再发」值得单独强调

Agent 和传统应用的区别在于，它的行为是概率性的。同一个提示词，换一个模型、改一句指令、多接一个工具，输出就可能完全不同。playground 的价值就在于让这些变量在可控环境里被反复试错，而不是等用户在生产环境里替你发现。

从产品流程看，Foundry 把测试放在了创作和发布之间，而不是事后补救。这个顺序上的讲究，比任何单个功能都更能说明平台对 Agent 生命周期的理解：发布不是一个点击动作，而是测试通过后的自然结果。

一句话建议

如果你正在 Foundry 里搭 Agent，别急着找发布按钮。先在 playground 里把 hello world 跑通，再逐项加上指令和工具，每加一项就回头测一次。这个笨办法能省下大量线上返工。