本文整理自 Microsoft Foundry 博客的 Evaluating Voice Agents: How Reliable Are Foundry’s Multi-turn Evaluators?，作者是 Sheng Liu、Shivank Goel 和 Morteza Ziyadi。

做语音 Agent 的团队迟早会撞上一个现实：每天几千通电话，Agent 还隔三差五更新，光靠人工听录音根本跟不上，只能上自动评估。Microsoft Foundry 给的办法是多轮评估器，它会看完整段对话，评估 Agent 的行为和结果。

本文整理自 Microsoft Foundry 博客的 Closing the AI Agent Governance Gap with Microsoft Foundry，作者是 Alexandra Miller-Browne。

开发者上线 Agent 的速度，已经快过安全团队给它们登记造册的速度。组织从试点走向同时运行几十个甚至上百个 Agent 之后，总会反复冒出同一个问题：我到底怎么才能看清整个环境里有哪些 AI Agent？

这篇文章讲的是如何借助 Azure 的现有服务，为 AI 资产建立可见性、护栏和成本归属。读完我最大的感受是，它并没有让你另起炉灶，而是把大多数组织手上已经有的身份、网络和合规控制，接到 Agent 这套新东西上。

题图来自 Microsoft Foundry 博客的 How to make AI responses faster on Microsoft Foundry: lessons from 2,040 measurements，作者是 Yassine El Ghali。

模型换得更快，应用不一定就更快。这篇文章的作者在 Microsoft Foundry 上把文本、图片、文件、工具和 MCP 几类工作负载都测了一遍，想知道哪些改动真能降低延迟，又不牺牲正确性。我读下来最大的感受是，延迟的来源比我平时想的杂得多：输出长度、重复的 prompt 内容、图片和文档处理、工具选择、连接建立、串行等待，还有多出来的模型请求，都会占时间。

题图来自 Microsoft Foundry 博客的 Evaluate More, Spend Less: Batching Microsoft Foundry Evaluators for Efficient Evaluation，作者是 Salma Elshafey、Ali Mahmoudzadeh、Kayla Ames、Ahmad Qardahji、Vivek Bhadauria、Morteza Ziyadi 和 April Kwong。

给 Agent 做评估时，同一段对话往往要分别发给好几个评估器。这篇文章讲的是微软 Foundry 团队的一项实验：用一次 Judge 调用同时跑五六个 Microsoft Foundry 评估器，总输入 token 少了 61.25% 到 71.07%，实测运行耗时少了 35.74% 到 46.10%，而且在几个价值较高的评估维度上，前沿 Judge 模型的质量没有明显波动。我把它读完后觉得，数字好看是一回事，更有用的是它顺带给出了哪些评估器适合合并、哪些得留着单独跑。

题图来自 GitHub Blog 的 Project HydraFusion。

9 月初 GitHub 放出了 HydraFusion，一个在 Copilot 模型选择器里排着的"模型"，但它其实不是模型。我把官方博客、Changelog、社区讨论帖、HyDRA 论文和 Rubber Duck 的两篇文章放在一起读了一遍，想弄清楚三件事：它到底在每一轮里做了什么，那组"成本降 67%、质量还更高"的数字能信到什么程度，以及现在值不值得切过去用。

在全球范围内，每年约有 450,000 人死于哮喘。如果我们能够更好地理解是什么导致人们患上哮喘，这将对哮喘的检测、诊断和治疗产生巨大的积极影响。基于模型的机器学习能否帮助我们获得这种更深入的理解呢？

哮喘是一种非常常见的疾病，在英国约有 5% 的人受其影响 [Anderson et al., 2007]，在美国这一比例约为 7% [Fanta, 2009]。对于患者而言，哮喘可能造成极其严重的后果。发展成哮喘的一个已知风险因子是这个人是否患有过敏，但过敏与哮喘之间的关系尚未被充分理解。若能加深对这一关系的理解，就有可能实现对那类可能导致住院乃至更糟后果的严重哮喘的早期检测。

曼彻斯特哮喘与过敏研究（Manchester Asthma and Allergy Study，MAAS）是一项旨在帮助理解儿童哮喘和过敏成因的研究 [Custovic et al., 2002]。具体而言，该研究的目标是理解为什么有些患有过敏的儿童会发展成哮喘，而另一些却不会。MAAS 是一项出生队列研究——换句话说，参与者是在出生时被招募进入研究的——共包含约 1,000 人。该研究始于 1995 年，并持续至今，不断收集有关研究参与者的最新数据，如今这些参与者已是青年人。可以想见，这些参与者及其家庭为此付出了巨大的奉献与投入——我们和研究团队都对他们心怀由衷的感激！

本文参考了 Microsoft Community Hub 上 Robin Lester 的文章 Using Jev with Agents in Microsoft Foundry for Model Evaluation，下面是我整理的理解和步骤。

Jev 是什么

Jev 是 TypeSafe AI 推出的新模型，2026 年 9 月 15 日开放了抢先体验。TypeSafe 把它称为自家第一个“System One”模型，它不写长篇文字，只负责又快又结构化地做判断。

用法很直接：把一段状态或上下文交给它，再说明你想让它做什么判断，它会返回一个带类型的概率化结果。结果有三种形式：

当我们绘制电影在特质空间中的位置时（之前的图 5.14），我们只展示了那些位置能被合理准确地知道的电影（也就是后验方差较低的那些）。由此可知，有许多电影的后验方差较大，甚至可能大得多。这意味着我们基本上不知道某些电影在特质空间中的位置。我们可能会预期这些是那些没有很多评分的电影。如果我们不知道某些电影在特质空间中的位置，那么我们可能会预期与这些电影相关的推荐准确性会很低。我们该如何诊断是否属于这种情况呢？

首先，了解每部电影通常有多少评分会很有用。图 5.25 展示了整个数据集中每部电影的评分数量，电影从左边评分最多到右边评分最少排序。

图 5.25：整个数据集中为每部电影给出的评分数量。电影从左边评分最多到右边评分最少排序。

我们的模型把完整的星级评分范围变成了简单的喜欢或不喜欢，这意味着它丢弃了大量有用的信息。给一部电影打 3 星和打 5 星之间有天壤之别，然而我们却把这两种情况同等对待。为了利用不同的星级评分，我们需要改变模型，使其能够处理完整的评分范围，而不是二值的喜欢/不喜欢。这不仅让我们能够在星级评分上训练，还让我们能够预测星级评分——一举两得！

我们可以在已经设计好的二值喜欢/不喜欢模型的基础上做出这一改变。在这个模型中，我们有一个 affinity（好感度）变量，它是一个连续的数字，表示一个人对一部电影的喜欢程度。目前我们在零处对这个好感度取阈值，说大于零的值意味着这个人喜欢这部电影，小于零的值意味着他们不喜欢这部电影。为了建模不同的星级评分，我们可以假设更高的好感度意味着一个人会给出更高的星级评分。更确切地说，我们现在不再只在零处取阈值，而是为每一个星级评分引入一个阈值。如果一个人对一部电影的好感度高于某个特定星数的阈值，那么我们就预期他们会给这部电影至少那么多星。

最近我在研究 Microsoft Foundry 的多智能体能力时，注意到一个变化：智能体之间的协作终于不用再靠一堆自定义 API 拼凑了。A2A 工具和新的入站 A2A 端点现在支持 A2A 协议 1.0 版本，这个版本已经正式发布（GA）。之前预览阶段用的 a2a_preview 工具类型和 0.3 版协议依然保留，给已有的集成留了一条兼容路径。托管智能体（Hosted Agents）也可以通过暴露在 MCP 上的 Foundry 工具箱来使用 A2A 工具。