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

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

手动进行推断

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

这篇是我照着 Microsoft 社区里一篇实战文章跑通之后整理的笔记，原文作者是 MuraliKumanduri，2026 年 6 月发布，原文在这里。我把它跑通并按自己的理解重讲一遍，方便以后复用。

先说结论：这是一套能上生产的模式，给跑在 Microsoft Foundry 里的 Claude 模型前面套一层用 Entra 保护的 LLM 网关，做到按开发者认证、限流、配额和成本追踪，而且任何一台笔记本上都不落模型密钥。全套实现大概两小时，只想搭个最小试点的话半小时够了。

如果你已经把 gpt-realtime 跑上了生产环境，大概率撞到过同一个问题：多轮对话之间，上下文到底该怎么管？

听上去像个实现细节，其实不是。这个决定直接关系到：你每通电话的成本是三毛还是九毛，你呼叫中心的延迟能不能压在两秒以内，以及你的客户会不会在同一通电话里被迫把账号报上五遍。

企业客户把语音和对话式 AI 从 demo 推向规模化时，追问的其实是同一件事：怎么优化 prompt 缓存策略，让调用量从每天一百通涨到十万通时，token 账单和延迟预算不会跟着爆炸。缓存是 realtime API 上撬动成本最狠的那根杠杆：缓存过的音频输入比未缓存便宜 99%，而解锁它靠的是一个稳定的前缀（prefix）。但到底哪种缓存策略真的赢，取决于你的应用是一次性查询、一段简短对话，还是呼叫中心那种动辄三十轮的升级工单。

本文编译自 Microsoft Tech Community 上 varghesejoji 的博客文章 AI Observability Starter Kit for Microsoft Foundry agents，我按自己上手时的理解重新整理，并补充了一些实际跑下来的体会。

先把结论放前面：一条 PowerShell 命令，就能拉起一个包含四个智能体的 Microsoft Foundry 环境，带遥测、8 个内置评估器、1 个自定义合规评估器、一次自动化红队扫描，还有两条 scheduled-query 告警。整套东西端到端验证过，再敲一条命令就能全部拆掉。Fork 下来直接跑。我觉得它最对胃口的人群是那些在 Azure 上跑 AI 智能体、又不想自己手写一堆管道代码的应用开发者、ML 工程师和 SRE。

我第一次把生产环境里的 gpt-4o 换成 gpt-5.1，服务发出的第一个请求就吃了个 HTTP 400。不是上线两周后才暴露，而是第一次调用就报错。更糟的是，报错指向的那个参数，我在自己代码里根本没写过——它是被一个我用了两年的 LangChain 辅助函数悄悄绑上去的。

所以这篇我想认真拆一下：从 GPT-4 家族迁移到 GPT-5 家族，在 Azure OpenAI（Microsoft Foundry）上到底有哪些破坏性变更，那些没人提前警告你的集成陷阱，以及要让同一处调用代码同时兼容两个模型家族、不做分支，我到底需要哪几个文件。

在为某些数据设计模型时，我们必须对产生这些数据的过程做出假设。事实上，我们可以说，模型就是这组假设，而这组假设就是模型。模型与它所表示的假设之间的关系如此重要，值得强调：

模型 = 关于数据的一组假设

选择在模型中包含哪些假设，是模型设计的关键环节。错误的假设会导致模型给出不准确的预测，正是这些有缺陷的假设造成了这种结果。然而，不做任何假设是不可能建立模型的——至少必须做出一些假设。

正如你在第 1 章中所见，本书将使用因子图来表示我们的模型。随着阅读的深入，你将学会如何构建对一组选定假设进行编码的因子图。同样，你也将学会观察一张因子图并推断出它所表示的假设。你可以把因子图看作一组假设的精确数学表示。例如，在第 1 章中，我们构建了一张因子图来表示关于一起谋杀之谜的一组精确假设。对于当前这个应用，我们需要对“一个具备特定技能集的候选人如何回答一组测试问题”这一过程做出假设。这将定义候选人的潜在技能与其测试答案之间的关系，随后我们可以将其反转，从测试答案中推断出他们的技能。

在设计因子图时，我们首先要选择希望图中包含哪些变量。图中至少必须包含表示我们实际拥有的数据的变量（候选人是否答对了每道题），以及我们想要了解的变量（技能）。正如我们将看到的，引入其它中间变量往往也很有用。选定变量之后，我们就可以开始向图中添加因子，以编码这些变量在答题过程中如何相互影响。通常从我们想要了解的变量（技能）开始，沿着这个过程一路推进，直到我们真正能够测量的变量（候选人是否答对了题目），这样做往往会很有帮助。

那么，从技能变量开始，这是我们的第一个假设：

1 每位候选人要么已掌握某项技能，要么没有掌握。

假设 2.1 意味着我们可以把候选人的技能表示为一个二值（true/false）变量：如果候选人掌握了该技能，则为 true；否则为 false。像我们目前见过的所有变量那样，只能取一组固定值之一的变量，称为离散变量。在本章后面，我们会遇到连续变量，它可以在一段连续取值范围内取任意值，例如 0 到 1 之间的任意实数。正如我们将看到的，连续变量在学习事件概率等许多用途上都非常有用。

前段时间在整理自家 GenAI 平台的模型调度方案，我又把 Microsoft Foundry 的 Model Router 翻出来仔细看了一遍。以前"这个请求该走哪个模型"是塞在应用代码里的一堆 if-else，现在它能被挪到平台层统一管起来。这篇就把我看下来的心得和踩过的点记一记，原文在这儿：Architecting Cost-Aware LLM Workloads with Model Router in Microsoft Foundry。

我最在意的其实就一件事：把多模型路由收进一个能被治理的部署里。故障转移它自己扛，数据驻留边界它帮你守住，18 个底层 LLM 之间该怎么在成本和质量之间权衡，也是按每一条 prompt 现算的。

在过去一年里，我一直在研究生产级 AI 智能体的构建。多智能体系统、RAG 流水线、一个全天候运行在 Mac mini 上的自主编程智能体……这些项目里最难搞的从来不是 AI 本身，而是基础设施。

沙箱隔离、状态管理、工具执行、容器编排、凭据轮换、错误恢复——在智能体真正能做什么有用的事之前，往往需要好几个月的水管工程。

用 Azure AI Search 加 Azure OpenAI 搭 RAG 系统时，我碰到过一个很典型的现象：上线初期检索质量挺好，跑了一阵子却慢慢变差。代码没动，基础设施没改，服务也没出故障，可检索的相关性就是在往下掉。折腾了一番我才搞清楚，背后常见的元凶叫向量漂移（vector drift）。这篇就说说向量漂移到底是什么、它为什么会在生产环境的 RAG 系统里冒出来，以及怎么用 Azure 原生的模式设计一套抗漂移的架构。

Azure AI Foundry（前身为 Azure AI Studio）是微软提供的端到端平台，用于构建、测试、部署和监控 AI 代理及应用程序。它将模型、工具、框架和治理能力整合到一个统一的系统中。

现代企业自动化往往需要多个 AI 系统协同完成任务。与其让单一的大型语言模型承担所有工作，Azure AI Foundry 引入了多代理编排机制——让专业化的 AI 代理在工作流中相互协作。