Agent可观测性完整方案：追踪、评估与Red Teaming实战指南

在AI Agent从原型走向生产的过程中，一个核心挑战始终困扰着开发者：如何弥合Agent预期行为与实际表现之间的差距？ 在AI Engineer大会上，Microsoft Foundry团队的Amy和Nitya深入展示了Agent可观测性（Observability）的完整解决方案，涵盖追踪、评估、安全防护和AI辅助优化的全生命周期管理。

非确定性：AI Agent面临的核心挑战

无论你使用哪种技术栈构建Agent，一个不可回避的现实是：Agent本质上是非确定性的。这不仅仅是Demo阶段的问题，更是生产环境中的核心挑战。当你把Agent交付给真实用户时，必须管理这种非确定性带来的风险。

要理解这一点，需要回到大语言模型的底层机制。传统软件工程中，函数通常是确定性的——相同的参数总是返回相同的结果。但LLM基于概率分布的token采样机制（如temperature参数控制的随机性）、上下文窗口的动态变化，以及模型版本的静默更新，天然具有非确定性。在Agent场景中，这种非确定性被进一步放大：Agent不仅要生成文本，还要做出工具调用决策、规划多步骤任务，每一步的微小偏差都可能导致最终结果的显著差异。这就是为什么传统的单元测试和集成测试方法在Agent系统中严重不足，必须引入统计性的评估框架。

演讲者将应对策略归纳为三个维度：

1. 评估（Evaluation）：检查性能、质量和安全性，确保Agent按预期工作
2. 监控（Monitoring）：持续追踪Agent在生产环境中的表现，应对模型变更、用户行为变化和环境变化
3. 优化（Optimization）：基于收集到的数据，系统性地改进Agent表现

一个精妙的类比是：评估就像建筑检查员检查你的房子是否符合规范；而安全防护（Red Teaming）则是请人尝试闯入你的房子，以证明防护确实有效。

从零构建Agent原型：Microsoft Foundry快速起步

面对超过200万个可用模型和Azure目录中11000+个模型的选择困境，开发者往往不知从何开始。Microsoft Foundry提供了一条快速路径。

Portal快速原型搭建

在ai.azure.com上，开发者可以在几分钟内完成：

• 创建项目并自动配置资源
• 系统自动推荐GPT-4.1作为起始模型
• 添加系统提示词、工具（如Bing搜索）和知识库
• 内置App Insights实现即时追踪

关键的是，Portal不仅仅是一个玩具环境。每次与Agent的交互都会自动生成追踪记录，包括token消耗、响应时间，以及AI质量和安全指标。开发者可以直接在Playground中选择评估指标，无需记住各种指标名称。

SDK深度开发路径

从Portal验证概念后，开发者可以无缝切换到SDK进行更复杂的开发。Workshop提供了完整的Notebook路径：

1. Lab 1：环境连接验证，确保Codespaces与Azure后端正确对接
2. Lab 2：用代码创建基础Agent（模型+提示词）
3. Lab 3：添加函数工具（航班查询、酒店预订、租车服务）
4. Lab 4：构建多Agent协作系统（Orchestrator Agent）
5. Lab 5：配置追踪（本地+Azure Monitor）
6. Lab 6：运行评估和Red Teaming

多Agent协作追踪与成本优化实践

Foundry引入了Team Agent的概念，允许开发者将单一的单体Agent拆分为多个专业化子Agent，并通过编排器（Orchestrator）协调它们的工作。

多Agent协作系统（Multi-Agent System）是当前AI Agent架构的重要演进方向。与单体Agent将所有能力集中在一个提示词和工具集中不同，多Agent架构将复杂任务分解为多个专业化子Agent，每个子Agent拥有独立的系统提示词、工具集，甚至可以使用不同的底层模型。编排器负责任务分发、结果聚合和错误处理。这种架构的优势包括：关注点分离使每个子Agent更容易调试和优化；不同子Agent可以使用不同成本级别的模型（如简单查询用小模型，复杂推理用大模型）；子Agent可以独立迭代而不影响整体系统。但这也带来了新的挑战：Agent间通信的延迟累积、编排逻辑的复杂性，以及跨Agent的追踪和归因问题——这正是Foundry Team Agent和追踪系统要解决的核心问题。

在追踪层面，这种架构的价值尤为突出。当用户提出一个旅行规划请求时，追踪系统能够清晰展示：

• 编排器如何将任务分发给航班Agent、酒店Agent和租车Agent
• 每个子Agent的调用链路、耗时和token消耗
• 哪个环节成功、哪个环节出现问题

关于成本优化，演讲者指出了两个关键策略：一是模型替换（如从GPT-4.1切换到GPT-4 Mini以降低token成本），但每次替换后必须运行回归评估确认质量未下降；二是追踪分析，通过观察各环节耗时来识别瓶颈（如知识检索耗时过长可考虑缓存或数据预处理）。

说个细节，Foundry的追踪基于OpenTelemetry标准构建。OpenTelemetry（简称OTel）是由Cloud Native Computing Foundation（CNCF）托管的开源可观测性框架，它统一了分布式追踪（Traces）、指标（Metrics）和日志（Logs）三大信号的采集标准。在AI Agent领域采用OpenTelemetry意义重大：它意味着Agent的调用链路可以与传统微服务的追踪数据无缝关联。例如，一个用户请求从前端到API网关，再到Agent编排器，最后到LLM推理端点的完整链路，都可以通过统一的trace ID串联起来。这避免了AI系统成为可观测性的"黑盒"，也使得现有的监控基础设施（如Jaeger、Grafana、Azure Monitor）可以直接消费AI相关的遥测数据，而无需构建全新的监控体系。同时，追踪数据可以同时推送到Foundry Portal和Azure Monitor，让IT团队也能在熟悉的监控平台上看到AI相关的遥测数据。

Agent评估体系：从质量指标到安全测试

质量评估指标详解

Foundry提供了丰富的内置评估器，涵盖：

• 相关性（Relevance）：回答是否切题
• 流畅性（Fluency）：语言是否自然
• 基础性（Groundedness）：回答是否有事实依据
• Agent行为评估：工具调用是否正确、任务完成度等

评估结果会清晰标注失败原因。例如，在一个测试案例中，Agent返回了"2024年8月24日"而非"2025年"，被标记为基础性失败——它并非真正基于事实回答。

Red Teaming安全测试实战

Red Teaming是安全防护中最具挑战性的环节。其核心思路是用一个攻击Agent来主动探测目标Agent的漏洞。

开发者可以定义风险分类（如数据泄露、未授权操作等），选择攻击策略（从简单的直接攻击到复杂的Crescendo攻击），然后让系统自动生成攻击用例并评估防护效果。

Crescendo攻击特别值得关注。这是Microsoft研究团队在2024年发表的一种多轮对话越狱（jailbreak）技术。与传统的单轮提示注入不同，Crescendo利用LLM的上下文学习能力，通过一系列看似无害的对话逐步建立语境，最终引导模型突破安全边界。例如，攻击者可能先询问"历史上有哪些著名的化学发现？"，然后逐步将话题引向危险化学品的合成方法。由于每一轮对话单独来看都不违反安全策略，传统的输入过滤器很难检测到这种攻击。在Agent场景中，Crescendo攻击更加危险，因为Agent拥有工具调用能力——攻击者可能通过渐进式对话最终诱导Agent执行未授权的API调用或数据访问操作。防御Crescendo攻击需要在对话级别而非单轮级别进行安全评估。

对于Agent场景，还有一类特殊的功能滥用攻击——试图让Agent执行其不应执行的操作（如窃取密码、泄露数据），这在多工具Agent中尤为危险。

Observe技能：用AI自动评估和优化AI Agent

演讲中最令人兴奋的部分是Foundry Skills的展示，特别是Observe技能。这是一个全新的范式：让AI Agent来帮你评估和优化你的AI Agent。

自动化评估优化工作流程

1. 开发者只需提供一个基础Agent（模型+提示词+端点）
2. Observe技能自动分析代码，发现缺少评估数据集
3. 自动生成测试数据集
4. 选择合适的评估器并运行基线评估
5. 返回结果报告，标注问题所在
6. 自动运行Prompt Optimizer，改进提示词并重新评估
7. 迭代多轮，记录每轮的改进和回退
8. 最终由人类决定采用哪个版本

其中，Prompt Optimizer（提示词优化器）是一种利用自动化方法系统性改进LLM提示词的技术。其核心思路借鉴了机器学习中的超参数调优：将提示词视为可调参数，将评估指标视为目标函数，通过迭代搜索找到最优提示词。常见的优化策略包括：基于评估反馈的自动重写（让另一个LLM根据失败案例改进提示词）、基于梯度近似的离散优化（如APE、OPRO等方法），以及基于进化算法的提示词变异与选择。在Foundry的实现中，优化器会分析评估失败的具体原因（如基础性不足、工具调用错误），然后针对性地调整系统提示词中的指令、约束条件和示例，再通过重新评估验证改进效果。

在演示中，Observe技能经过多轮迭代，将Agent的评估得分从初始水平逐步提升。关键的是，它不仅优化提示词，还会建议模型替换、追踪配置等更深层的改进方向。

Human-in-the-Loop的关键角色

这个过程中，人机协作至关重要。AI可能会在优化过程中出现"翘翘板效应"——改善了一个指标却恶化了另一个。此时需要人类判断何时停止迭代，选择最佳平衡点。演示中，系统在多轮尝试后发现得分在5-8之间波动，最终由开发者决定采用得分为5的版本作为最优解。

开发者工具链：构建可观测性完整闭环

除了SDK和Portal，Foundry还提供了多层次的开发者支持：

• AI Toolkit扩展：在VS Code中直接访问Foundry功能
• Ask AI：Portal内置的AI助手，了解你的项目上下文
• Azure Monitor自然语言查询：用自然语言替代复杂的KQL查询来分析追踪日志
• MCP Server：通过GitHub Copilot直接调用Foundry技能

值得展开说明的是MCP Server的意义。MCP（Model Context Protocol）是Anthropic于2024年底发布的开放协议，旨在标准化LLM与外部工具和数据源之间的交互方式。MCP采用客户端-服务器架构：MCP Server暴露工具和资源，MCP Client（如GitHub Copilot、Claude Desktop等AI助手）通过标准协议调用这些能力。Foundry提供MCP Server意味着开发者可以在自己熟悉的AI编码助手中直接调用Foundry的评估、追踪和优化功能，而无需切换到Portal或手动编写SDK代码。这体现了AI工具链正在从"平台锁定"走向"协议互通"的行业趋势，开发者可以在统一的对话界面中编排来自不同平台的AI能力。

整个工具链的设计理念是：无论你处于开发的哪个阶段，都有对应的工具帮助你弥合可观测性的缺口。从Portal的快速验证，到SDK的精细控制，再到AI Skills的自动化优化，形成了一个完整的闭环。

总结：弥合Agent可观测性三大缺口

Agent可观测性的缺口体现在三个层面：

1. 行为差距：Agent的预期行为与实际表现之间的偏差，需要通过追踪和评估来发现
2. 响应速度：从检测问题到诊断修复的时间，需要通过关联追踪和评估来缩短
3. 安全防线：不仅要防范正常使用中的问题，还要主动测试恶意攻击场景

弥合这些缺口的关键在于：将可观测性从事后补救转变为开发流程的内建能力，并借助AI编码助手加速整个评估-优化循环。Foundry Skills目前仍处于非常早期的阶段（发布仅两周），但其展示的方向——用AI来管理AI的质量——无疑是Agent工程化的重要趋势。

核心要点

• Agent的非确定性是生产环境的核心挑战，需要通过评估、监控和优化三个维度来管理
• Microsoft Foundry提供从Portal快速原型到SDK深度开发的完整路径，内置基于OpenTelemetry的追踪系统
• 多Agent协作架构（Team Agent）配合追踪系统，可以精确定位每个子Agent的性能瓶颈和成本消耗
• Red Teaming通过攻击Agent主动探测安全漏洞，Crescendo攻击和功能滥用攻击是Agent场景的特有威胁
• Foundry Observe技能实现了AI驱动的自动化评估与优化闭环，包括自动生成测试数据、运行评估、优化提示词并迭代改进