你可能以为，推断猜测概率需要用到与我们目前所用完全不同的技术。事实上，我们的做法将完全相同：我们把想要学习的概率值作为新的连续随机变量加入模型，并用概率推断来计算它们的后验分布。这展示了基于模型方法的威力——每当我们想知道某个东西时，我们就把它作为一个随机变量引入模型，然后用概率推断去求出它。

让我们看看如何修改模型，把猜测概率作为随机变量纳入进来。为了保持一致，我们也会为犯错概率（实际上是不犯错概率）添加一个变量，但我们会把它固定在 10% 的犯错几率上。首先，我们要改变书写 AddNoise 因子的方式。

(a) 内置概率的自定义因子

(b) 通用的 Table 因子

图 2.25：书写 AddNoise 因子的两种方式：(a) 作为一个把猜测和犯错概率“内置”其中的自定义因子。(b) 使用一个通用的 Table 因子，它带有两个参数：给定父节点为 false 时子节点为 true 的概率（左参数），以及给定父节点为 true 时子节点为 true 的概率（右参数）。这种书写因子的方式让我们可以把这些概率作为变量提供给因子。

图 2.25 展示了如何把现有的 AddNoise 因子（其中猜测和不犯错概率被硬编码为 0.2 和 0.9）替换为一个通用的 Table 因子，后者把这些概率作为额外的参数。然后我们可以用两个新的随机变量来设置这些参数，我们把它们命名为 probGuess 和 probNoMistake。推断这些变量的后验分布，就会给出我们所需的猜测和不犯错概率的学习值——但为此，我们首先需要一种能表示这类变量不确定性的分布。

只要跟正在把 Microsoft Foundry 往生产环境搬的企业团队聊过，我几乎都会听到同一条底线：智能体不能跑在公网上。它一旦碰到专有数据、内部 API 或者受监管的负载，安全团队就要求把它塞进公司自己的虚拟网络里，藏在专用终结点、中心防火墙和受控 DNS 后面。这种拓扑，也就是一个 Foundry Standard 智能体被注入到 自带（BYO）VNet 里，正是大多数大型组织真正推到生产的形态。也恰恰是在这里，很多团队的首次部署悄无声息地卡住了。

我最近一直在琢磨一件事：为什么 AI 智能体用起来总有种"似曾相识的挫败感"。

我们把越来越多的活儿交给它——写材料、排会议、报税，甚至直接上手构建和调试生产系统。它的能力肉眼可见地在变强，可有个毛病始终没治好：同样的坑，它会一次又一次地踩进去。

举个我自己踩过的例子。智能体执行 python main.py，结果项目是用 uv 管理依赖的，直接甩给我一个 ModuleNotFoundError。它试了好几轮，最后摸索出 uv run python main.py 才是对的。但下周再来一次呢？同样的报错，同样白烧掉的 token 和时间。如果它有"程序性记忆"（Procedural Memory），学一次就够了，然后记住这条：在用 uv 管理的项目里，一律走 uv run。

把 copilot 从简单问答升级成真能干活的助手，我很快撞上一堵墙：单个智能体应付不了那种要走好几步、还跨领域的任务。当你指望一个 copilot 同时做推理、读实时数据、又要遵守各领域自己的规则时，问题就冒出来了，比如排障流程、汇总多个系统的洞察，或者把好几条业务线的信息揉到一起。

多智能体编排的思路，是让 copilot 把活儿分给专门的智能体，同时留一个统一的决策层。下面这套编排器—专家（orchestrator–specialist）模式来自真实的客户实践，我照着在 Microsoft Copilot Studio 里从头走了一遍，顺带用 Activity Map 这类内置工具验证了智能体之间到底有没有好好协作。

当一个机器学习系统不工作时，通常有三个可能的原因：坏数据、坏模型或坏推断。以下是这三个类别下各自一些常见的问题成因：

• 坏数据（Bad data）：数据项被错误地录入、存储或加载；数据项不完整或标注错误；数据值噪声太大而无用；数据有偏或不能代表系统将被使用的方式；这是任务的错误数据；数据不足以做出准确预测。
• 坏模型（Bad model）：一个或多个建模假设是错的——即与实际生成数据的过程不一致；模型做了太多简化假设；给定可用数据量，模型包含的假设不足以做出准确预测。
• 坏推断（Bad inference）：推断代码含有 bug；消息传递调度不好；推断尚未收敛；存在数值问题（例如舍入、溢出）；近似推断算法不够准确。

在我们的情形中，我们可以相当有信心地认为数据是好的，因为我们已经仔细地检查和可视化过它。所以看起来问题很可能出在模型或推断上。我们将从检查推断算法——即循环置信传播——是否正确工作开始。

既然我们已经在示例数据上充分试验过模型，现在就可以用一些真实数据来工作了。我们请了 22 位志愿者完成一份由 48 道题组成的测评测试，用以评估七种不同的开发技能。许多题目需要两项技能，因为它们既需要某个软件开发概念的知识（例如面向对象编程），又需要该题所用编程语言的知识（例如 C#）。

除了完成测试之外，我们还请每位志愿者说明他们认为自己具备哪些开发技能。这些自评技能将作为技能变量的真实标注（ground truth）——也就是说，我们把它们当作变量的真实取值。这类真实标注数据将用于评估我们的系统从志愿者答案中自动推断技能的准确性。真实标注数据应当相当可靠，因为志愿者没有夸大自己技能的动机：结果是匿名的，所报告的技能和答案无法与任何特定志愿者关联。然而，某些志愿者也有可能高估或低估自己的技能，我们在用这些数据评估准确性时需要牢记这一点。

本文编译自 Microsoft Community Hub 的文章 Auto-Generated Rubric Evaluators: Building Context-Aware Evaluators for AI Agents，原作者 Shuo Qiu 等人。我读完之后觉得这套验证方法挺扎实，就顺手整理成中文，把里面的数据和结论都留了下来。

预置评估器有个老毛病：它们太通用了，一旦碰到真实业务里的智能体，往往不够贴身。Microsoft Foundry 里的自动生成 Rubric 评估器就是冲着这个问题去的——你手头已经有的上下文，它拿来生成一个针对具体任务的 Rubric 评估器。团队从四个方面做了验证，结论是：在测试条件下，用推荐配置跑出来的评估器，有效性和可靠性都站得住。

现在让我们把模型稍微扩展一下，添加第四道需要两项技能的题目。这张新的因子图如图 2.14 所示，我们为这道新题添加了新的 isCorrect4 和 hasSkills4 变量。在这张仅仅略微变大的图上，我们当然也可以用置信传播来做推断吧？其实，我们不能。

环可能很棘手。

问题在于，置信传播只有在某个（未观测）节点的所有其它边上都收到了消息之后，才能从该节点发出一条消息（算法 2.1）。在这个约束下，只有当图中没有环时，我们才能把图中的所有消息都发送出去；这里的环是指一条穿过图、从同一个节点出发又回到该节点的路径（且不重复经过同一条边）。如果图中有一个环，那么我们无法沿着环上的任何一条边发送消息，因为这总是要求先计算出环上的另一条消息。

我第一次盯着一个启用了 MCP 的智能体的 token 账单时，脑子是懵的。API 告诉我这次跑了 773 个 token。可门户里的 trace 显示的是 581/141。切到 trajectory 视图，数字又变成了另一个样子。三个地方，三套数据，哪个才是对的？

在你急着去提 bug 之前，我想先说清楚这背后到底发生了什么，以及怎么建立一套站得住脚的证据方法，让企业级的 token 核算不再靠猜。

构建好一个模型之后，首先要做的就是用一些简单的示例数据来试验它，检查它的行为是否合理。假设有一位候选人懂 C# 但不懂 SQL——我们会预期他答对第一题，而答错另外两题。那么让我们针对这种情况试验一下模型，看看对于这样的答题模式它会推断出哪些技能。为方便起见，我们用 isCorrect 来指代数组 [isCorrect1, isCorrect2, isCorrect3]，因此我们要考虑的是 isCorrect 为 [true, false, false] 的情形。

我们想在给定这一组特定的 isCorrect 取值的条件下，推断候选人具备 csharp 和 sql 技能的概率。这是一个推断查询的例子，它由我们想要推断的变量（csharp、sql）以及我们所条件化的变量（isCorrect）连同它们的观测值共同定义。由于这个例子相当小，我们可以用手工方式求出这个推断查询的答案。

手动进行推断

作为开始，我们先来看看在只给定第一题答案的情况下，如何推断 csharp 技能的概率。舍去其它变量后，就得到图 2.6 所示的简化因子图。