一个技术老兵工作的点滴记录，专注、沟通、乐在分享!
原文：Evaluating Agentic AI in Microsoft Foundry: Beyond Final-Answer Quality，作者 jothsnapraveena，发布于 2026-09-10
AI 系统正在从单轮对话助手演变成会调用工具的智能体，评估方式也必须跟着变。这是我最近研究 Microsoft Foundry 智能体评估功能时最直接的感受。
做传统 LLM 应用的团队，通常只关心最终回复是否相关、连贯、有依据。但智能体不一样，这只是问题的一部分。
……
本文整理自 Microsoft Community Hub 的文章 Model Migration Process on Microsoft Foundry and Azure OpenAI，原作者 Meera Kurup（Microsoft）。我把里面这套模型迁移流程读了几遍，觉得挺实用，就整理成中文分享给大家，案例和数据都保留了原文的说法。
只要你的应用是跑在某个大模型上的，迟早会碰到换模型这件事。可能是你在用的模型被官方标了退役日期，也可能单纯是有更好、更快或更便宜的新模型出来了。把代码里的模型名从 gpt-4o 换成 gpt-5.1，理论上一行代码就能搞定。但这一行代码背后藏着的工作量，经常被严重低估。
……最近在给 Foundry 上的托管代理配置对外能力时，碰到了一个绕不开的问题：怎么让别的 agent 框架也能发现我这个代理、跟它对话。翻了一圈 Microsoft Foundry 的文档，发现官方已经把 Agent-to-Agent（A2A）协议接进了托管代理里，跨框架、跨技术栈的代理之间能直接打通。原文在这儿：Enabling A2A endpoint and Agent Card for a Hosted Agent（原文作者 srisatyakrishna5，发布于 2026 年 8 月 24 日）。我把自己跑通的过程和踩的坑整理了一下。
……
企业里用 Azure OpenAI 的场景越来越多——内部知识库、自动化流程、客服助手、安全运营，几乎每个团队都想接进去用。但真正让AmalUBasnayake 停下来想一想的是这个问题：怎么让应用安全地访问 AI 服务，同时把不必要的网络暴露降到最低，还能保护好身份、凭据和敏感数据？
如果 AI 处理的是公司内部数据、敏感系统或者受保护的资源，这个问题就不只是"锦上添花"了。
……有一次收到 Azure 的通知邮件，大体内容如下：
Important update: Eligibility for Quota Tier upgrade
We are pleased to inform you that, based on your recent usage and account standing, your subscription is now eligible for an upgrade from your current Tier (Free Tier) to the next Tier (Tier 1) within our AI Services platform.
我就去翻了翻 Microsoft Foundry 关于配额等级（Quota tiers）的文档，把这次邮件里真正发生的变化记下来，也顺便把几组常用模型的数字放在一起。
本文整理自 Microsoft Learn 的 Quotas and limits 文档。该页面显示的更新时间是 2026 年 7 月 29 日；配额表还会调整，部署前最好再看一眼 Foundry 门户里的实时值。
……只要跟正在把 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 核算不再靠猜。
……