本文编译自 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）上到底有哪些破坏性变更，那些没人提前警告你的集成陷阱，以及要让同一处调用代码同时兼容两个模型家族、不做分支，我到底需要哪几个文件。

阅读全文

前段时间在整理自家 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 代理在工作流中相互协作。

阅读全文

这篇文章记录的是如何观察和了解 Agent 在现实中的实际运行状态。

Agent 与普通 API 有根本的不同。它不是简单的请求/响应就结束，而是一套多阶段流程：LLM 推理 → 工具调用 → 结果处理 → 再推理。出错时，很难立即看出是哪个阶段因为什么原因失败了。速度慢时，也搞不清楚时间消耗在哪里。在成本方面，更难分析是哪个查询消耗了大量 Token。

阅读全文

Microsoft Agent Framework 现已集成 Claude Agent SDK，让我们能够构建由 Claude 完整代理能力驱动的 AI 代理。这个集成将 Agent Framework 的一致代理抽象与 Claude 的强大功能结合在一起，包括文件编辑、代码执行、函数调用、流式响应、多轮对话以及模型上下文协议（MCP）服务器集成——目前在 Python 中可用。

为什么将 Agent Framework 与 Claude Agent SDK 结合使用？

我们可以单独使用 Claude Agent SDK 来构建代理。那么为什么要通过 Agent Framework 来使用它呢？以下是主要原因：

阅读全文

在过去的几周里,我一直在探索小语言模型(SLM)的部署之旅。从最初了解 Phi-4 和小语言模型的强大之处,到实践使用 Foundry Local 在本地运行模型,再到学习函数调用,最近还构建了一个完整的多智能体测验应用,其中包含一个协调专家智能体的编排器。

这个测验应用在本地运行得很好,但它依赖于 Foundry Local 目录中的模型——这些模型经过预优化且随时可用。但如果想部署一个不在目录中的模型该怎么办?也许你已经在特定领域的测验数据上微调了一个模型,或者 Hugging Face 上刚发布了一个你想使用的新模型。今天我将展示如何从 Hugging Face 获取一个模型,使用 Microsoft Olive 优化它,在 Foundry Local 中注册它,并在测验应用中运行它。同样的工作流程适用于你可能为特定用例微调的任何模型。

阅读全文

我发现 Microsoft Agent Framework 现在与 GitHub Copilot SDK 集成,让我们能够构建由 GitHub Copilot 驱动的 AI 代理。这个集成将 Agent Framework 一致的代理抽象与 GitHub Copilot 的强大功能结合在一起,包括函数调用、流式响应、多轮对话、Shell 命令执行、文件操作、URL 获取以及 Model Context Protocol (MCP) 服务器集成 —— 所有这些功能在 .NET 和 Python 中都可用。

为什么将 Agent Framework 与 GitHub Copilot SDK 结合使用?

你可以单独使用 GitHub Copilot SDK 来构建代理。那么为什么要通过 Agent Framework 来使用它呢?以下是几个关键原因:

阅读全文