无需写代码：用Microsoft Foundry门户搭建你的第一个AI智能体

构建一个生产就绪的AI智能体，涉及模型、智能体、工具、评估、可观测性、治理等诸多环节，这些部分必须协同工作。在真正动手写代码之前，先在一个可视化平台中把每个环节跑通、看清能力边界，往往能省下大量返工成本。Microsoft Foundry门户（ai.azure.com）正是为这个目的而生——它让你在编写生产代码之前，就能对整条链路建立信心。

从新建项目开始：Foundry门户的整体布局

登录ai.azure.com后，点击「New Foundry」即可进入新版门户体验。你可以选择已有项目，也可以创建全新项目。在高级选项中，除了给项目命名（演示中命名为「Sparkles Cupcake」），还能指定资源名称、订阅、区域以及Azure中的资源组。点击创建后，几分钟内项目便部署完成。

新版Foundry门户的导航结构清晰：右侧的Discover标签用于查找模型和智能体；Build标签用于端到端地创建智能体与评估；Operate标签管理生产环境中的智能体，包括查看成本、运行状态与权限管理；文档入口也直接内嵌在门户中，使用体验相当顺手。项目的endpoint和API密钥在首页即可直接获取。

值得一提的是，门户操作会同步在Azure门户中生成对应资源——创建的Sparkles资源组内会包含Foundry及Foundry项目实体，可视化操作与底层Azure资源是一一对应的。

部署模型：从Discover到Playground

搭建智能体的第一步是选定模型。在Discover标签下可以看到来自不同供应商、覆盖多模态能力的大量模型。演示中搜索了GPT系列并选择了mini版本，页面会展示该模型的版本信息、来自Azure的定价与可用性。

右上角的Deploy按钮支持两种模式：只是试用可直接采用默认配置，需要精细控制则可自定义部署参数。部署完成后会直接进入Playground，且模型已自动选中，可以立即做一次「hello world」式的简单测试。这种「部署即可试」的设计，把从选型到验证的路径压缩到了最短。

构建智能体并接入工具

有了模型，就可以基于它构建智能体。在Build标签或Agents标签中都能创建新智能体。Foundry支持两种类型：一种是在平台内构建的「prompt agent」（提示型智能体），另一种是自带代码托管在平台上的「hosted agent」（托管型智能体）。

演示创建了名为sparkles的智能体并在Playground中打开。Playground允许你快速搭建智能体原型：选择模型、开启语音模式、编写指令，还提供了「improve and optimize」按钮来优化提示词。

工具方面，当下最流行的是MCP（Model Context Protocol，模型上下文协议）服务器。演示为「sparkles cupcakes」添加了一个自定义MCP工具：填入名称、指定store MCP的端点，认证方式支持key、Entra、OAuth，演示中选择了unauthenticated。除了工具，还可以配置知识（knowledge）、记忆（memory）和护栏（guardrails）。

保存智能体后会开启版本管理，并自动启用traces（追踪），用于记录对话过程、展示智能体的实际行为。

MCP（Model Context Protocol，模型上下文协议）是由Anthropic于2024年底提出、随后被业界广泛采纳的开放标准，旨在解决AI模型与外部工具、数据源之间的集成碎片化问题。其核心思想是将「工具暴露给模型」这件事标准化：MCP服务器负责声明自己提供哪些工具及其参数格式，MCP客户端（即模型或智能体运行时）则按统一协议调用这些工具。这种设计类似于USB接口的理念——只要遵循协议，任何工具都可以即插即用，开发者不必为每个模型单独编写适配层。在Foundry中接入MCP工具，意味着你自己编写或部署的业务服务（如订单系统、库存查询）只需暴露MCP兼容端点，智能体便能自动发现并调用，极大降低了企业级工具集成的复杂度。

在真实业务中验证：工具调用全流程

保存后即可提交首个查询。演示走完了一整套真实业务流程：先创建新的客户ID（提供姓名与位置），此时可以看到一次工具调用（tool call），支持「批准一次/批准该工具/批准全部工具」三种粒度。选择「批准一次」能清楚地观察每一步过程。

创建客户后，演示继续下单购买cupcake，智能体会从MCP服务器获取商品列表并处理订单。最终，订单成功出现在员工制作蛋糕时使用的「staff dashboard」前端界面上——这直观证明了智能体已真正连接到业务系统，而不只是停留在对话层面。

Traces：看清智能体每一步在做什么

Traces是理解智能体、工具与提示如何在对话中协同的重要工具。在智能体页面点击Traces标签，可以在trace视图、conversation视图和response视图之间切换。

conversation视图能回放此前的完整对话，user视图则展示用户实际的交互内容——如何提供姓名、位置和订单，以及不同工具调用发生的位置。更实用的是，Traces还能显示每一步的执行耗时，点击后可查看消耗的token数量，为优化速度和效率提供了直接依据。

Traces（链路追踪）的概念来自分布式系统可观测性领域，最早由Google Dapper论文奠定基础，后经OpenTelemetry标准普及。其核心思想是为一次请求的完整处理过程生成结构化日志，记录每个子步骤的开始时间、耗时、输入输出及状态。在AI智能体语境下，一次用户对话可能触发多轮LLM调用、多次工具调用和多层嵌套推理，仅凭最终输出极难判断问题出在哪一环。Traces将这条调用链完整展开：哪次工具调用最耗时、哪个步骤消耗了最多token、模型在哪里做出了分支决策——这些信息直接对应性能优化和成本控制的具体方向。Foundry将Traces与智能体创建流程打通，保存智能体即自动开启追踪，省去了手动接入可观测性基础设施的步骤。

Evaluations：从单次对话到系统化测试

Traces适合分析单次对话，但要判断智能体是否真正可靠，需要系统化的评估（Evaluations）。Foundry提供三类评估：自动评估最简单，提供数据集、选择衡量指标，由LLM充当裁判自动运行；人工评估由你自己打分；**红队测试（red teaming）**则专门用于挑战智能体的安全性。

创建评估时，可针对智能体、模型或数据集。评估范围上，「query response pairs」（查询-响应对）适合首次评估，「full conversations」则可评估真实发生过的完整对话。评估可运行一次，也可长期运行以捕捉回归问题。若没有数据，Foundry能自动生成，演示则上传了已有数据集并核对了字段映射与裁判模型。

评估标准方面，系统建议了20个评估器，演示精简为5个：工具调用准确性（tool call accuracy）、任务遵从度（task adherence）、意图解析（intent resolution）、相关性（relevance，质量类）以及间接攻击（indirect attack，安全类）。命名为Sparkles V2提交后，几分钟便完成，给出整体得分和每个评估器的百分比。

结果可以下载完整数据集，也可在门户内逐条深入：查看每条通过或失败的原因——比如用户只是打了招呼、响应仅与问题松散相关、或助手未能满足查询cupcake的请求等。这种细粒度的归因分析，让评估不只是一个分数，而是可行动的改进依据。

红队测试（Red Teaming）源自网络安全领域，指组建一支扮演「攻击者」角色的团队，主动尝试突破系统防线，以此发现防御盲点。在AI智能体场景中，红队测试的目标是通过构造对抗性输入——如提示词注入、越狱指令、间接攻击（将恶意指令隐藏在工具返回的内容中）——来测试智能体是否会产生有害输出、泄露系统提示或被操纵执行超出授权的操作。Foundry将红队测试内置为评估选项之一，说明安全性验证已从事后审计前移到开发阶段。演示中出现的「间接攻击（indirect attack）」评估器，专门检测智能体在处理来自外部工具或文档的内容时，是否能抵御嵌入其中的恶意指令——这在接入MCP等外部数据源时尤为关键。

总结：写生产代码前先建立信心

整个流程串联起来，Foundry门户完成了部署模型、构建智能体、连接工具、检查traces、运行评估这一完整闭环。它的核心价值在于——在你动手编写生产代码之前，就能在可视化环境中把每一环验证清楚，逐步建立对整套系统的信心。对于希望快速理解AI智能体全貌、又不想一开始就陷入代码细节的团队来说，这种低代码的探索路径确实降低了入门门槛。