只要跟正在把 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 这类内置工具验证了智能体之间到底有没有好好协作。

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

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

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

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

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

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

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