原文：Evaluating Agentic AI in Microsoft Foundry: Beyond Final-Answer Quality，作者 jothsnapraveena，发布于 2026-09-10

AI 系统正在从单轮对话助手演变成会调用工具的智能体，评估方式也必须跟着变。这是我最近研究 Microsoft Foundry 智能体评估功能时最直接的感受。

做传统 LLM 应用的团队，通常只关心最终回复是否相关、连贯、有依据。但智能体不一样，这只是问题的一部分。

一个智能体完全可能给出看起来很靠谱的答案，但背后选错了工具、传错了参数、没理会工具返回的结果、违反了用户设下的限制、多打了几次不必要的调用，或者压根没把任务做完。回答"看上去对"和"真的做对了"，是两回事。

这正是 Microsoft Foundry 把智能体评估拆成多个层次的原因，它同时支持系统级评估和过程级评估。微软把智能体评估器定义为一套系统性评估工具，用来衡量智能体工作流中的质量、安全性和性能，而不只是看最后一句回复。这个思路我很认同：只盯着结果，很容易把一堆过程性问题都漏掉。

详见：评估智能体文档

先确定评估目标

Foundry 支持针对不同目标做评估。可以选择直接评估一个智能体，用测试输入跑一遍，看它新生成的行为；也可以直接评估某个模型；还可以评估一个已经存在于数据库里的数据集，对已有的输出打分。

这个区别很重要，因为评估流程会随目标改变。目标是智能体时，Foundry 会针对每条输入生成一个全新的回复，再对这个回复评分；目标是数据集时，Foundry 评估的是数据集里已经写好的回复。

参考：评估生成式 AI 应用

对于智能体系统，我习惯从两个范围来看评估：一个是单轮，方便细致调试工具调用和回复行为；另一个是完整对话，用来看多轮任务是否完成、对话是否连贯、用户体验如何。微软目前的建议是先用完整对话加模拟数据做可控测试，等上线后再用真实对话数据。

系统评估：智能体到底有没有把任务做完

第一层看的是端到端的结果。

任务完成度（Task Completion）

智能体到底有没有完成用户交代的任务？

举个例子：“帮我在达拉斯找一双 120 美元以内、9 码的黑色跑鞋。”

智能体可能正确地搜索了商品，却在检查库存之前就停下了。回复读起来没毛病，但任务其实没做完。

任务遵从度（Task Adherence）

智能体有没有遵守指令、政策和用户明确提出的限制条件？

如果客户说预算是 120 美元，智能体却推荐了一件 129 美元的商品，还没说清楚这已经超预算，遵从度就该打折扣。

意图理解（Intent Resolution）

智能体有没有正确理解用户到底想要什么？

一次工具调用可能在技术上完全没问题，但语义上是错的。用户明确要跑鞋，智能体却搜了一堆普通运动鞋，就是个典型例子。

客户满意度（Customer Satisfaction）

这个指标看得更远一些，不只看技术是否正确，而是问：整个交互体验是不是能让用户满意。这一条最难量化，但也最贴近真实的产品体验。

这几个指标合在一起，回答的其实是一个很朴素的问题：系统到底有没有解决用户的问题？微软把这类衡量方式归到智能体工作流的系统评估里。

过程评估：智能体走的路对不对

真正有意思的部分从这里开始。

Foundry 为使用工具的智能体准备了专门的过程评估器。

工具选择（Tool Selection）

这个指标看智能体选没选对工具。

假设一个智能体手上有这几个工具：搜索商品、查库存、查促销、网页搜索。

用户问：“DailyRun X 这款鞋在达拉斯有没有 9 码现货？”

企业场景下正确的做法是调用查库存的工具。如果智能体转头去用了网页搜索，答案听起来可能照样像那么回事，但走的路子就是错的。

工具输入准确度（Tool Input Accuracy）

这个指标看工具调用时传的参数对不对。

比如这样一次调用：

check_inventory( product_id="DEMO-SHOE-002", size="9", location="Dallas-TX" )

智能体可能选对了工具，尺码或地点却传错了。也就是说，工具选择这一项可以通过，工具输入准确度却照样能挂掉。

工具调用成功率（Tool Call Success）

这个指标看的是调用本身有没有跑通：接口返回是否成功、有没有超时、有没有执行失败。

但调用成功不等于调用对了。接口完全可能针对错误的商品编号或错误的地点返回 200，照样是一个漂亮的 200。工具调用成功率衡量的是执行是否可靠，语义对不对是另一回事——这两件事我见过太多人搞混。

工具输出利用率（Tool Output Utilization）

这个指标看智能体有没有正确使用工具返回的结果。

设想库存工具返回 { "available": false }，智能体却回复"是的，9 码有货"。工具没问题，输入也可能是对的。问题就出在智能体读了结果却没照着说——这个坑我见过不止一次。

工具调用准确度（Tool Call Accuracy）

这是一个更综合的信号，衡量整体的工具调用行为是否正确。

说白了，这几项合在一起就是想确认一件事：智能体走的是不是正确的工作流，而不是编出一个听起来令人信服的答案。

回复质量依然重要

就算过程全对，最终的回复也可能写得很差。

Foundry 提供了一组质量评估器：相关性、有依据性、完整性、连贯性、流畅性。

有依据性（Groundedness）

这个指标问的是：回复里的说法有没有上下文或证据支撑。对企业应用来说这一点特别重要，答案应该建立在权威信息源上，而不是模型自己"记得"的东西。

完整性（Completeness）

智能体有没有把请求里所有重要的部分都答到？

如果用户问：“这个有货吗，会员还有折扣吗？“只查了库存却没理会折扣问题，这个回答就不算完整。

连贯性与流畅性（Coherence and Fluency）

这两个指标看的是表达质量。微软把连贯性定义为观点呈现是否有逻辑、有条理，流畅性则看可读性、语法、用词和清晰度。

更多细节可以看：通用评估器文档

内置评估器不够用怎么办

零售智能体、金融智能体、理赔智能体、运营智能体，每一种都带着自己的业务规则，通用评估器很难面面俱到地覆盖。

微软目前的建议是：当团队需要表达政策执行、工具使用准确性、沟通规范这类应用特定标准时，把评分标准评估器（rubric evaluator）当作主要衡量手段，再叠加内置评估器做更广泛的覆盖。老实说，这也是我读完整篇文章后觉得最实用的一部分。

一个零售智能体的评分标准可能会写着：没查库存不能说有货，不能编造折扣，不能悄悄违反用户说的预算，能用企业内部目录工具就别用公开搜索，别重复打没必要的工具调用，找不到完全匹配的商品时要说清楚做了哪些妥协。

评估到这一步，看起来已经很像业务验收测试了。

详见：评分标准评估器文档

数据集其实是一套回归测试

Foundry 的评估数据集是可以反复使用的测试集合，拿来对比 Prompt V1 和 V2、对比不同模型、对比工具定义的改动、对比编排逻辑的改动，或者对比候选版本和线上版本。

Foundry 用数据集评估智能体时，会针对每条输入重新生成一次回复再打分；如果评估目标是线上正在跑的智能体，Foundry 会直接忽略数据集里已有的回复。

这一点把提示词工程从"这版 prompt 看起来更好"变成了"这版在同一套回归测试上跑分更高”。后一种说法明显更站得住脚，前一种说法说到底只是个人感觉。

黄金数据集、合成数据和生产环境轨迹，各有各的用处

成熟的评估策略不会只靠一种数据来源。

黄金数据集适合覆盖那些已知的关键场景，做确定性的回归测试；合成数据能在生产流量还不够多的时候，帮你补齐覆盖面、造出边界情况；完整对话模拟适合测试多轮任务和端到端的用户旅程；生产环境轨迹则直接告诉你真实用户实际经历了什么。

Foundry 支持直接从 Application Insights 的轨迹数据发起评估，不用重放原始请求就能评估已经上线的交互。

更多细节可以看：从已部署交互评估文档

生产环境的评估应该建立在轨迹数据上

生产环境的故障往往和开发阶段遇到的不太一样。真实用户会带来意想不到的措辞、缺失的信息、互相矛盾的约束条件、少见的工具调用顺序，还有合成测试数据根本覆盖不到的边界情况。

Foundry 可以直接评估 Application Insights 里已经采集到的轨迹，评估流程支持按轨迹 ID 或按智能体筛选，也支持智能抽样，挑出有代表性的一部分来评估，而不必把每一次交互都跑一遍。

这样就形成了一个扎实的运营闭环：运行 → 采集轨迹 → 评估 → 找出问题 → 加入回归测试集 → 修复 → 再评估。

我在看 Microsoft Foundry 这套评估体系时最大的感触是：它评的不只是智能体说了什么，还包括它实际是怎么运作的、用了哪些工具、任务有没有做完，以及这些行为随时间会怎么变化。这种颗粒度，才是真正让人放心把智能体放到生产环境里的原因。