多智能体系统跨区域上线：先证明“上线的就是测过的”

发布证据比部署成功更重要

托管智能体跨区域上线时的七项实践

这是 Microsoft Foundry 博客“全球企业多智能体系统”系列的第二篇。上一篇偏重起步、设计与安全，这一篇转向发布与运维。作者的核心观点是：智能体能够启动，不等于它就是被测试过的那个版本，也不等于配置正确、业务结果可靠。

文章给出第 8 到第 14 条实践，依次涉及：区分部署与晋升、明确配置归属、分层评估、保护诊断数据、衡量有效进展、衡量单次有效产出的成本、演练恢复与交接。最后还有一个发布后的持续改进闭环。

据文章介绍，托管智能体具备独立身份与端点、不可变版本，并默认把 OpenTelemetry 追踪发送到 Application Insights。这让“测试并晋升同一个候选版本”成为可能，也为发布留下证据。编排逻辑、应用权限、依赖和业务结果仍由团队自己负责。

文章还强调，每个区域都应视为一次独立发布。服务版本、模型与工具可用性、生效配置、访问控制和诊断数据边界，都要逐区域核对。

这是文章最具操作性的一条。文章指出，默认路由会跟随最新版本，所以要先固定当前服务版本，再创建候选版本，并且只记录一次候选版本号，测试之后不再重新解析“最新”。

文中的一个团队用配置服务保存当前生效的版本号：流水线先创建并验证新版本，最后才改这个值，失败时流量留在旧版本。文章还提醒，端点选择器同一时刻只服务一个版本，渐进放量需要网关或独立端点；已有会话也不会随选择器迁移。

我的看法是，这套顺序的价值在于把“已合并”“已部署”“已生效”“已复测”拆成不同里程碑，团队可以据此设置明确的晋升门槛。

文章认为，门户用户、流水线和安全自动化都可能写入设置，所以每个设置都需要负责人，并要验证从后端行为到最终生效状态的整条链路。基础设施即代码有帮助，但不会自动覆盖所有字段。

评估部分建议分别看智能体、工具和系统结果三个层面，并按用户群体或任务类型拆分结果，避免平均分掩盖小群体的严重问题。文章特别提到，被跳过或不适用的检查不能算通过；智能体说“任务已完成”也不能代替业务系统的回执。

追踪会复制提示词、检索内容、工具参数和输出。文章建议盘点所有落点，包括遥测、治理与安全副本、运维副本，并为每处明确用途、归属、访问、保留与删除规则。

文章还介绍了把敏感内容路由到专用表、再用受保护表控制访问的做法，同时强调路由不等于保护。上线前应先用唯一标记做测试，确认数据能写入，再验证各类访问路径；无法证明保护到位时，应抑制内容采集。

文章明确说明，文中多项能力在撰写时处于预览阶段，并且预览功能不提供服务等级协议，不建议用于生产。因此，团队落地时需要逐项确认当前状态。

待观察的问题：预览功能何时正式可用；原生的渐进放量能否取代自建网关（这只是推测）；多区域成本与恢复演练在实际团队中会占多大工作量。

Microsoft Foundry Blog：Global enterprise multi-agent systems in production: Release and operations (Part 2)，https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/global-enterprise-multi-agent-systems-in-production-release-and-operations-part-/4564916