核心要点
- API7 企业版 3.10.0 移除了服务模板和 API 发布机制，让服务可以直接在网关组下管理，服务管理因此更加简单。
- 新版本通过更安全的身份认证默认配置、敏感字段存储时加密、身份请求头加固和更清晰的缓存行为，进一步提升了安全性。
- AI Proxy 和 AI Proxy Multi 的改进通过稳定的请求编码与能够感知 DNS 的上游选择，让 AI 流量更加可靠。
- 开发者门户的行为更加明确：只有已发布的 API 产品才会启用开发者身份认证，从而减少对草稿产品行为的隐性假设。
- 升级规划应重点检查服务归属、认证客户端、缓存行为、开发者门户发布流程以及自定义运行时配置。
当服务归属、发布流程、运行时策略和流量运维分散在不同层级时，企业 API 平台很容易变得复杂。一支团队可能负责服务模板，另一支团队负责发布 API 产品，而平台运维人员仍然需要弄清楚：究竟是哪个网关组、服务、路由、插件或策略影响了某个生产请求。随着同一网关层开始同时承载产品 API、合作伙伴 API、大语言模型（LLM）流量和 MCP 工具访问，这种复杂性会愈发明显。
API7 企业版 3.10.0 从三个实际方向解决这一问题：简化服务管理、强化安全默认配置，以及提升 AI 流量可靠性。其中最重要的变化并非界面调整，而是移除了服务模板和 API 发布机制，并将服务直接放到网关组下管理。围绕这一核心模型变化，新版本还加强了身份认证、缓存行为、开发者门户发布规则和 AI 流量处理。
因此，API7 企业版 3.10.0 是一个以运维为核心的版本。它减少了平台团队需要理解的概念层级，同时改善了现有生产流量路径的默认行为。
1flowchart LR
2 group[网关组] --> services[直接管理的服务]
3 services --> routes[路由与插件]
4 routes --> apis[API 流量]
5 routes --> ai[AI 流量]
6 portal[开发者门户] --> products[已发布的 API 产品]
7 products --> services
8 console[控制台策略编辑器] --> group
9 services --> security[安全与缓存默认配置]
10 services --> ops[升级检查]更简单的服务管理
API7 企业版 3.10.0 最大的变化，是移除了服务模板与服务中心模型，以及 API 发布机制。服务现在直接归属于网关组，并通过 APISIX Admin API 管理。在控制台中，原有的服务中心区域也由各网关组下的服务列表取代。
这项变化很重要，因为服务管理正是日常 API 运维与组织归属交汇的地方。平台团队需要知道服务位于哪里、哪些路由和插件属于它，以及哪个网关组负责承载它。过去的模板与发布层可以帮助标准化流程，但也拉开了“人们编辑的配置”与“排障时需要理解的运行时服务行为”之间的距离。
升级期间，现有服务模板和已发布服务会自动迁移到新的直接服务模型。原始数据会保留下来，以便回滚；引用服务模板或已发布服务 ARN 的 IAM 策略也会先备份，再重写。这个迁移路径十分关键：它改变了服务管理的思维模型，却不要求运维人员手动重建每一项服务关系。
控制台也围绕这一更简单的运维模型进行了改进。兼容性警告现在会按照业务层级路径展示受影响的资源，例如网关组、服务和路由，而不是只显示原始资源 ID。管理员还可以使用可视化的权限策略语句编辑器，通过选择资源类型、操作和条件来构建 IAM 策略，无需手写 JSON。
1flowchart LR
2 before[3.10.0 之前：服务模板与 API 发布层] --> migrate[升级迁移]
3 migrate --> after[3.10.0 之后：网关组下直接管理服务]
4 after --> routes[路由、插件与运行时流量]
5 after --> iam[IAM 策略检查]
6 after --> console[控制台兼容性路径]更强的安全默认配置
API7 企业版 3.10.0 还收紧了多项安全敏感行为。它们未必都是醒目的新功能，却能减少在生产环境中代价高昂的模糊行为。
首先，hmac-auth 的 signed_headers 现在默认设置为 ["date"]。升级后，任何没有显式配置 signed_headers 的 hmac-auth 都会要求客户端对 Date 请求头签名。这是更强的请求验证默认配置，但也是一项必须检查的升级事项：此前未对 Date 签名的客户端可能开始收到 HTTP 401，除非相应调整插件配置。
其次，启用数据加密后，API7 企业版会继续减少敏感字段暴露。3.10.0 会对 Feishu Auth 和 DingTalk Auth 的 secret_fallbacks 进行存储时加密。它的实际价值很直接：开启加密后，类似凭证的字段不应继续以明文形式出现在 etcd、备份或导出文件中。运维人员应协调控制面与数据面的升级，或者在依赖新加密字段前先升级数据面，避免旧数据面把密文当作真实密钥处理。
身份请求头也更加安全。Feishu Auth 现在会在认证前清除客户端提供的 X-Userinfo，从而确保上游服务收到的是由插件控制的身份信息，而不是调用方自行填写的内容。对于构建零信任 API 架构的团队而言，这个细节十分关键：传递给上游的身份应来自经过验证的认证结果，而不是客户端可以伪造的请求头。
缓存行为同样属于安全问题。API7 企业版 3.10.0 为内存型 Proxy Cache 策略增加了对 Vary 响应头的支持。系统会按照 Vary 中列出的请求头分别缓存响应，而带有 Vary: * 的响应不会被缓存。对于响应内容取决于请求头的 API，这能让缓存行为更加正确。如果你使用 GraphQL Proxy Cache 或对已认证 API 进行缓存，升级时正好可以重新检查缓存键假设。
更可靠的 AI 流量
当每个应用都直接连接模型提供商时，大语言模型流量会更难运维。请求格式的一点变化可能影响提供商侧的提示词缓存，DNS 行为可能影响端点选择，流式响应处理会改变用户感知到的延迟，而大型请求体也会给网关和应用性能带来压力。
API7 企业版 3.10.0 通过 AI Proxy 插件改进了这条链路。插件现在会按照键名排序后，对发送到上游的大语言模型请求体进行 JSON 编码。对于内容相同、仅 JSON 键顺序不同的等价请求，这会生成字节完全一致的请求体。部分大语言模型提供商会根据请求体的精确字节内容决定提示词缓存行为，因此，当提供商支持此类缓存时，稳定的请求编码有助于提高重复提示词的缓存命中率，减少不必要的模型计算。
AI Proxy Multi 也改进了端点处理。当一个大语言模型端点域名解析出多个 A 记录时，插件会解析全部地址并构建多节点上游，再为每个请求选择一个节点。Host 请求头和 TLS SNI 仍然使用原始域名。对于平台团队而言，当模型端点依赖 DNS 分发时，这能提供更好的负载分布与故障切换能力。
真正的价值并不只是 AI Proxy 改变了请求格式，而是整体可靠性得到了提升。应用团队可以调用受治理的内部端点，平台团队则能够在同一个位置管理提供商路由、身份认证、请求规范化、DNS 行为和可观测性。随着企业开始跨团队统一使用 API7 AI 网关，而不是让每个应用各自直接集成模型提供商，这一点尤其重要。
1sequenceDiagram
2 participant App as 应用
3 participant GW as API7 AI 网关
4 participant DNS as DNS 解析器
5 participant LLM as 大语言模型端点
6
7 App->>GW: OpenAI 兼容或提供商特定请求
8 GW->>GW: 规范化 JSON 请求体，稳定缓存行为
9 GW->>DNS: 解析提供商域名
10 DNS-->>GW: 返回可用的多个 A 记录
11 GW->>LLM: 将请求路由到选定的上游节点
12 LLM-->>GW: 返回模型响应
13 GW-->>App: 返回带有网关上下文的受治理响应AI 可靠性也包括工具开放。OpenAPI to MCP 插件可以通过 MCP 接口开放基于 OpenAPI 的服务，同时让请求继续经过网关策略。相关版本还为动态解析的 base_url 增加了 allowed_hosts，用于限制动态基础 URL 可以指向哪些主机，并拒绝格式错误或非 HTTP(S) URL。随着 AI 智能体工作流不断增加，这类边界可以让工具访问始终处于治理之下，而不是变成临时拼接的通道。
更明确的开发者门户与运维行为
服务治理只有融入日常平台运维，才能真正发挥作用。服务直接归入网关组之后，周边流程也必须足够明确：哪些 API 产品需要开发者认证、哪些策略作用于哪些资源，以及出现兼容性问题时运维人员应该去哪里排查。
开发者门户的行为变得更加明确。在开发者门户中，开发者身份认证现在只对已发布的 API 产品生效。此前，草稿状态的 API 产品也可能把开发者认证规则同步到网关，因此属于草稿产品的路由同样需要开发者认证。升级后，草稿 API 产品中的路由在产品发布前不再要求开发者认证。依赖草稿产品提供保护的团队，应先发布这些产品，或在升级前通过其他控制手段限制访问。
控制台还新增了权限策略语句的可视化编辑器。管理员可以通过选择资源类型、操作和条件构建 IAM 策略，无需手写 JSON。兼容性警告也会按照网关组、服务、路由等业务层级路径显示受影响资源，帮助运维人员更快定位配置问题。
除配置检查外，平台团队还可以在日常网关运维中使用调试会话进行运行时排障。
升级前需要检查什么
更适合的做法，是把 API7 企业版 3.10.0 同时视为一次产品升级和一次治理检查。升级前，请仔细阅读发布说明，并重点验证最可能影响生产行为的部分：
- 服务模板和 API 发布机制已被移除，并迁移到直接服务模型。
- 开发者身份认证现在只对已发布的 API 产品生效。
- 数据面运行时已升级至 OpenResty 1.29.2.4，应检查自定义 NGINX 代码片段的兼容性。
- 除非显式配置
signed_headers，否则hmac-auth现在默认要求客户端对Date请求头签名。 - 如果启用了数据加密，需要谨慎安排控制面和数据面的升级顺序，确保新加密的插件字段由兼容的数据面处理。
- 如果使用 Proxy Cache 或 GraphQL Proxy Cache，应在为已认证 API 启用或调整缓存前重新检查缓存键假设。
1flowchart TD
2 start[规划 3.10 升级] --> services[检查服务模型迁移]
3 services --> portal[检查开发者门户草稿产品行为]
4 portal --> nginx[验证自定义 NGINX 代码片段与 OpenResty 1.29.2.4 的兼容性]
5 nginx --> encryption[规划加密字段兼容性]
6 encryption --> hmac[确认 HMAC 客户端会对 Date 请求头签名]
7 hmac --> ai[验证 AI Proxy 路由与模型端点]
8 ai --> cache[检查 Proxy Cache 与 GraphQL 缓存设置]
9 cache --> staging[在预发布环境测试网关组与数据面]
10 staging --> release[进入生产发布]升级检查应覆盖网关配置、插件使用情况、客户端认证行为、开发者门户工作流以及自动化脚本。对于混合、多集群或 Kubernetes 环境，团队还应先在预发布环境中验证数据面兼容性与 Helm Chart，再进入生产升级。
总结
API7 企业版 3.10.0 的重要性在于：当服务归属、发布流程、流量策略和运行时行为分散在过多层级时，API 管理会越来越困难。这个版本让核心服务模型向更简单的方向演进，同时收紧了多项重要的网关默认配置。
新版本进一步强化了 API7 企业版作为网关级治理层的能力。服务管理更加直接，安全默认配置更强，开发者门户的发布规则更加明确，大语言模型流量更加可预测，MCP 接口开放获得了更清晰的边界，缓存行为更加正确，运维人员也能在控制台中更清楚地管理配置和策略。
阅读完整的 API7 企业版发布说明，结合自身环境检查升级要求，并进一步了解 API7 AI 网关和开发者门户文档，为下一次发布做好准备。