Agent 应用转私网，先重构网络与身份

Agent 应用在公网跑通聊天、流式响应和上传，不代表它能顺利进入企业内网。原文讨论的是 Azure App Service 上的这一步迁移：从验证产品流程的公开 POC，走向受网络和身份约束的私有 MVP。

作者的结论很明确：多复制几份 .env，换掉几个 URL，完成不了架构升级。真正需要验证的是谁能访问应用、应用能访问哪些依赖、域名解析到哪里，以及每个用户能操作什么。对准备把 Agent 接入企业环境的前端和全栈团队，这比继续调提示词更值得提前想清楚。

为什么配了 private endpoint，应用仍可能没准备好

作者把环境成熟度拆成四个平面：入口、出口、私有 DNS 和身份。这里的「平面」，可以理解成四组需要分别验收的访问关系。

POC 可以开放公网入口，也可以设置严格的 IP 白名单，目的是尽快跑通 Agent 交互。私有 MVP 则要让应用入口、关键 API 和必须隔离的数据依赖，满足明确的网络约束。

最容易混淆的是 App Service 的两个能力。

private endpoint 解决入站访问：让网络中的调用方通过私有 IP 访问应用。regional VNet integration 解决出站访问：让 App Service 工作实例进入虚拟网络，访问私有 Key Vault、存储或平台端点。

入口私有和出口私有，必须分别设计、分别验证。

只做 VNet integration，不能据此认定公网入口已经关闭；只配 private endpoint，也不能保证应用能够访问内网依赖。原文还特别指出，private endpoint 与 VNet integration 不能使用同一个子网，后者需要委派子网。

如果企业要求检查所有出站流量，还需要考虑 route-all。这是原文给出的条件性要求，不能把它理解成所有 MVP 都必须打开的固定开关。

对开发者来说，直接影响是：本地能调用的 API，部署后可能超时；应用入口已经能从内网访问，读取配置却仍然失败。排查时需要先确定失败发生在哪条访问链路上。

为什么网络收紧后，还要一起处理 DNS 和权限

作者把 private DNS 当成产品依赖，而不是部署结束后的补充配置。

域名必须在应用实际使用的网络中解析到正确的私有 IP。因此，需要列出 Azure Private DNS zones，并记录它们分别链接了哪些 VNet，尤其是应用执行 VNet integration 所使用的网络。如果采用自定义 DNS，还要检查转发链路。

典型故障是：同一个域名，在某处解析正确，在应用所在网络却仍然指向公网。此时看到的可能是 403，也可能是超时。作者用「别把它当应用 Bug 调试三天」提醒团队，但没有给出故障统计；「问题几乎总是 DNS」应理解为经验判断。

身份也需要同步收紧。原文区分了三件事：

• 应用使用 managed identity，获得访问依赖资源的身份。
• 用户通过 Entra 登录，由 API 上的 app roles 决定可用功能和路由。
• Agent 平台端点的网络可达性需要单独说明，不能因为应用入口私有就默认成立。

必要时再加入 Conditional Access。网络隔离缩小能够接触服务的人群，功能授权继续决定进入服务后可以做什么。一个已登录用户，不应因此自动获得全部 Agent 操作权限。

密钥迁移也在这条链路上。POC 可以使用短期密钥、受限的 App Settings 或本地 .env；进入私有 MVP 后，作者建议使用 Key Vault references 或等价方案，并在平台规范要求时通过私有网络访问。

重点不只是把字符串换成引用，还包括 managed identity 的角色分配、密钥存储位置和轮换安排。原文没有提供具体权限配置，不能把这篇文章当成完整的部署手册。

环境升级之前，先写一张能验收的架构表

作者建议在复制目录之前，先写清 POC 与私有 MVP 的差异。

POC 验证 shell 行为、流式聊天和上传流程，可以接受公网可达的平台端点。私有 MVP 则要列出入口控制、出站路径、DNS 链接、身份授权和密钥来源，并明确网络、DNS、监控分别由谁负责。

可以沿用的是 SPA、API、Agent 接口等产品结构，以及授权模型和角色测试矩阵。不能顺手带过去的是旧连接字符串、镜像仓库凭据和临时公网放行规则。

作者还提醒，container registry、App Service plan SKU 和 managed identity role assignments 都需要盘点。私有部署可能要求更高的计划层级，但原文没有列出具体 SKU、价格或能力对照，预算仍需按实际方案核算。

最有价值的是升级顺序：先通过网络和身份验收，再让密钥通过正确路径接入，最后赋予环境相应的阶段标签。保留公网例外时，要有负责人和复审日期。

这套流程有明确代价。私有 MVP 搭建更慢，需要网络、DNS 和身份负责人共同参与。过去在公网执行 curl 或临时演示的便利也会减少，需要提前安排 VPN 或堡垒机访问路径。

出站受限后，on-behalf-of 流程也更难排查。作者建议把身份测试与网络测试分开，先确认哪一层出了问题，避免每次都从聊天页面开始猜。

我的判断

我认同作者把入口、出口、DNS 和身份拆开验收。这能把一句模糊的「已经私有化」，变成几组可验证的访问关系。比只维护多套配置文件更有用，因为 URL 写对了，并不代表路由、解析和权限都成立。

不过，作者讨论的是有私有网络要求的企业 Agent MVP。MVP 通常描述最小可行产品，并不天然要求私有入口。公开服务也可以是合格的 MVP，所以文末「公网可达就是更响亮的演示」表达得过于绝对。

同样，公网域名的存在本身不足以证明服务暴露。原文自己的 DNS 讨论已经说明，关键是域名在目标网络中如何解析，以及公网请求是否真的能到达服务，不能只看主机名判断。

文章没有迁移耗时、故障率或成本的对照数据，也没有展示一次完整部署实验。它更适合作为 Azure 架构检查框架。对仍在验证需求的团队，公网入口配合 IP 限制、短期凭据和必要授权，依然是合理的 POC 选择；什么时候承担私有网络的协作成本，应由实际约束决定。

能拿来做什么

• 给现有 Agent 应用补一张访问关系表，分别写清浏览器到 SPA、浏览器到 API、API 到 Key Vault 或存储的入口、出口、DNS 和身份要求，再确定哪些链路必须私有。
• 把部署验收拆成可达性、域名解析和角色权限三组检查。遇到 403 或超时时，先定位失败链路，再检查前端请求或服务端代码。
• 升级环境时逐项清理旧连接字符串、镜像仓库凭据和临时放行规则，并核对 managed identity 的权限、Key Vault references 和密钥轮换安排。
• 在关闭公网访问之前，准备好 VPN 或堡垒机路径，并分别验证网络连通性与 on-behalf-of 身份流程，让开发和演示有明确入口。