原型设计、路径追踪、评估与红队测试：Microsoft Foundry中的AI智能体工作流程。
在Microsoft Foundry中实现AI智能体的模型选择、指令处理、基础设定、路径追踪、批量评估及自动化红队测试，随后过渡到SDK使用。
来源: Build, Evaluate, and Red-Team an AI Agent Before You Write Code
让人工智能代理给出几个不错的回复只需几分钟，但要决定是否可以将其发布则需要更长的时间，因为团队首先必须弄清楚所选模型是否物有所值、该代理是否使用了正确的数据、它调用了哪些工具、其回复的质量如何，以及它在面对刻意试图破坏它的攻击时的表现如何。
Microsoft Foundry将这一流程中的大部分功能整合到一个浏览器工作空间中，涵盖模型比较、指令处理、工具与知识管理、追踪分析、性能评估、生成的测试数据以及自动化红队测试。它的真正价值并不在于能够无限期推迟代码编写，而在于能够在项目改动成本还较低时就确定那些昂贵的设计决策，避免在生产代码定型后难以更改。
接下来的内容将追踪一个智能体从初始空白项目发展到基于数据的原型，经历测试、评分与攻击分析，最终标志着工作从门户系统转入SDK的节点。该环境位于瑞典中部区域的Microsoft Build零售智能体环境中，属于新的Foundry体验的一部分。门户系统用于快速迭代，而走向生产环境的路径仍在同一个Foundry项目中，因此无需从头开始重建任何内容。
从可运行的基础开始
一个新的Foundry项目是一个包含智能体、模型、工具、知识库、评估机制及监控功能的工作空间。具体的配置步骤、默认设置以及可用功能会因地区而异，并且会随时间变化，因此应以门户系统提供的信息作为判断项目功能的最终依据。
创建智能体之后，工作便在“实验场”中展开。模型与指令在此设置，工具或知识也会被附加，最终结果则在聊天窗口中进行测试。也正是这里，原型会首次暴露出其不足之处。将一个复杂的产品问题交给配置极简的智能体，得到的回复通常会很平淡无奇。尽管对产品目录、规则或业务环境一无所知，它仍可能表现得很有把握。请将这样的回复作为基准，因为后续的所有改进都应以此为参照标准。
基于证据选择模型
性能出色的默认模型未必适合实际应用。某些任务需要深度推理，而另一些则更看重速度或低成本，因此模型的选择应基于评估而非直觉。Foundry提供了多种工具来筛选合适的模型：
- 一个排行榜，根据模型在质量、安全、性能以及成本相关指标上的表现对其进行排序。
- 折衷图表，将两个维度展示在同一个图上，例如质量与价格的关系。
- 并排视图，将候选模型列表缩小为适合当前工作负载的模型。
- 模型路由器，根据成本与质量的平衡策略为每个请求分配合适的模型，这样无需一个模型就能回答所有问题。
仅凭基准测试分数作为依据并不充分，让所有候选模型处理相同的工作负载才是更可靠的方法。当请求的难度差异较大时，路由器才能发挥其作用。它目前提供平衡模式、成本模式和质量模式，若被分配的模型出现故障，当前版本会自动切换到另一个合适的模型。
接下来的步骤是向每个候选配置发送相同的提示语，然后比较回答质量、响应延迟及成本。基准测试可缩小候选范围，而您的工作量则用于选出最优方案。Microsoft Learn在其Foundry文档中介绍了基准测试工作流程以及相关工具。
指令是最经济有效的手段
更换模型并不总是正确的第一步。模糊的指令可能会让昂贵的模型沦为普通的聊天机器人。Foundry中的Prompt Optimizer功能能够重写和重构指令，解释对特定部分进行修改的原因，并允许在应用任何更改之前进行多次调整。这样一来，指令就能以版本化的形式提交给工程团队，而非仅仅通过反复修改段落来让回复看起来更理想。
仅仅进行漂亮的文本重写并无太大意义。更有效的检验方法是使用同一组评估数据来对比旧版本和新版本的表现。智能体应当遵循的任何角色设定、响应格式、备用行为规则，以及对偏离主题请求的限制，都应同时体现在其指令中以及用于评估其输出的结果标准里。
将答案与已批准的数据关联
指令决定了智能体的行为方式，而知识则决定了它能够回答什么问题。在规模较小的场景中，通过上传文件并利用检索工具将其呈现出来，可以让回复引用相应的来源材料。
规模较大的企业环境可以使用Foundry IQ，这是一种整合了多种数据源的共享知识层。知识库可以连接Azure Blob Storage、SharePoint、OneLake、现有的搜索索引以及公共网络内容，智能体检索系统则会负责规划查询、选择数据源、进行搜索，并返回带有引用依据的准确结果。
关于访问控制有一个重要提示：文档级别的权限仅对支持该功能的源代码和配置有效，因此在真正配置好源代码权限和身份验证流程之前，不应将知识库描述为具备权限感知功能的。
要了解其效果，可以在对模型进行 grounding 操作前后各提问一次。第一次回复会显示模型的一般知识，而第二次回复则应体现出你的数据所带来的差异。
尽早开启追踪功能
在智能体仍会出现故障时，可观测性功能能提供很大帮助。Foundry 的追踪功能遵循 OpenTelemetry 标准，并可与 Azure Monitor Application Insights 相集成，从而记录智能体或应用程序的执行路径，便于之后查看模型调用、工具使用情况、输入数据、输出结果以及执行时间等信息。
三个层级基于这一共享的运行视图，各自解答不同的问题：
- 追踪功能可显示某次具体运行中发生了什么。
- 评估功能可判断该行为是否达到标准。
- 监控功能可显示运行情况随时间的变化趋势。
请记住，Application Insights 的遥测服务费用与数据量及存储时长相关。应将可观测性视为生产架构的一部分来规划预算，而非免费的调试福利。
衡量实际行为，而非主观猜测
动手测试有助于探索问题，但无法确定某项更改是否提升了代理程序的性能。Foundry 提供了针对多个行为维度的现成评估工具：质量、风险与安全，以及针对代理程序的特定指标，比如任务是否被执行、是否完成、意图是否被理解，以及工具调用的效果如何。
自定义评估器通常有两种形式。基于评分标准或提示的评估器会使用模型来判定那些主观性较强或取决于上下文的标准；而确定性评估器则是针对可直接计算的标准设计的简单函数。判断回复的友好程度可能需要评分标准，但长度限制则无需如此。评估本身会带来成本和干扰，因此当函数能够可靠地做出判断时，再调用另一个模型就是浪费金钱。
数据集让迭代更加严谨
单个提示只能证明某个功能有效，但数据集才能揭示其中的规律。Foundry可以对你准备的JSONL或CSV文件、已有的追踪数据或合成测试数据进行评分。在产品发布前，或是实际流量过少无法覆盖所需的所有边界情况时，合成数据非常有用。
这样就能形成一个可以重复的循环：
- 确定一个代表性的测试集，使其保持不变。
- 用当前版本的智能体在该测试集上运行。
- 仅修改一个变量，无论是模型、指令、工具设置还是其他相关参数。
- 在同一测试集上再次进行评估。
- 比较各项指标，如得分、响应时间和资源消耗情况。
- 决定接受该更改或予以舍弃。
至此，这项工作就不再属于简单的提示词调整，而更接近于软件的回归测试。
红队测试能发现常规评分方法遗漏的问题
常规的质量检查仅关注智能体是否出色地完成了分配给它的任务。而红队测试则着眼于当有人故意向系统输入恶意数据时系统会如何反应。Foundry内置的AI红队测试智能体将开源的PyRIT项目与Foundry的风险和安全评估功能相结合，利用专门用于绕过标准防护措施的攻击方法来测试所支持的模型和智能体，并输出攻击成功率（ASR）。
所支持的方法包括Flip和Tense之类的转换操作，以及越狱攻击和其他对抗性技巧；当前的风险场景涵盖有害内容、敏感数据泄露、禁止行为以及间接提示注入等。这项测试的价值在于其评估结果能推动进一步的工程优化，而非仅仅作为满足合规要求的截图存在。应将其视为一个循环过程：
- 在非生产环境中进行扫描。
- 分析哪些风险类别和攻击方式成功穿透了防御。
- 修复导致问题的根源，无论是指令问题、工具边界问题、内容控制问题还是权限问题。
- 再次进行扫描。
- 观察攻击成功率是否呈下降趋势。
监控全部设备
当代理程序开始运行后，关注点就从某个指令是否有效转变为系统在数周内的整体表现。监控视图和操作视图会显示整个工作负载的各类指标，如通话次数、令牌使用情况、故障频率以及成本相关数据；在支持的情况下还可以进一步查看单个代理程序和模型的详细信息。
在有限范围内，以微服务思维来处理问题是有用的。每个智能体都可以被视为一个具有独立版本的行为单元，它由指令、工具、知识、模型策略以及可观察的输出组成。并非每个智能体都必须成为独立部署的服务，关键在于划定边界，这样就可以在不重写相关所有内容的情况下对某个智能体进行编辑、评估和升级。
门户背后的循环
在实际操作中，这个循环包括构建、测量、优化、管理，一旦有迹象表明该智能体尚未准备好，则重新回到起点。进展的依据是追踪数据与评估分数达到了预先设定的标准，而非仅仅因为演示效果良好。产品界面可能会变化，但这一流程始终如一：原型设计、追踪分析、评估优化、加固完善、监控跟踪，然后重复上述步骤。
目前有一个需要注意的问题：微软计划于2026年12月1日停止支持Foundry Workflows，并将新的工作流开发方向转向Microsoft Agent Framework。不应在即将被废弃的架构基础上构建新设计。
从浏览器原型到生产代码
该门户应缩短通往代码的路径，而非替代代码本身。对于自定义编排、CI/CD、更深层次的集成或托管代理代码等需求，则需要使用Foundry SDK及其工具，这些工具目前支持Python、C#、JavaScript和Java语言。从架构上看，该项目的资产和端点依然处于核心位置。门户、SDK和工具只是通往同一个Foundry项目及其资源的不同入口，因此可以将其视为一个拥有统一端点、没有独立原型平台与生产平台的项目。在Microsoft Learn上提供的SDK快速入门指南便是这一过渡的起点。
后续实验
接下来介绍两个主题。其一为多智能体协调，即通过现代协调框架将具有独立测试性、且各自拥有明确契约与评估基线的智能体组合起来，而非将它们整合为一个庞大的提示语。其二为模型定制，只有当提示设计、基础设定、路径规划及工具设计均无法满足需求时，才值得对其进行评估。这两者都属于此处所述的评估范畴之后所探讨的内容。
总结
代理的首个可用响应仅能启动流程，而无法完成整个流程。候选版本需要在多个方面提供证明：在负载对比中表现稳定的模型选择、能明显改变响应结果的基础机制、可查看的工具调用记录、可重复的评估过程，以及会随时间下降的红队风险值。该平台提供了快速迭代机制，而项目与SDK则将工作推进到实际的生产环境中。要快速构建系统，尽早加入监控功能，在相同的负载条件下测试每一项变更，在外部人员介入之前先自行排查系统问题，一旦浏览器能稳定输出预期结果，即可切换到代码实现方式。