1Panel AI网关Jev模式：无缝对接Bedrock，智能路由再进化

1. 项目概述

1.1 核心需求解析

先说结论：这次1Panel AI网关智能路由新增的Jev模式，解决的是AI网关接入面不够广、路由策略不够聪明这两个老问题。

AI网关智能路由这个应用，核心干的事就两件：一是把多种模型服务统一收口到一个入口，让应用不用关心底层接的是哪家API；二是根据预设的分流策略，把请求派发给不同的模型后端，实现负载分摊、成本控制或者快速容灾切换。

原先的AI网关智能路由主要接的是OpenAI兼容接口和Anthropic接口，覆盖面够用但不够广。特别是国内用户常用的AWS Bedrock生态（Claude模型托管在Bedrock上）、以及一些走自定义协议的小众模型服务，接入成本偏高——要么自己写适配层，要么用官方SDK硬编码，绕来绕去很麻烦。

Jev模式的引入，正好把这块短板补上了。Jev这个名字本身是Jevan的缩写，Jevan是一个开源的、把OpenAI/Anthropic类API请求转换成Amazon Bedrock协议格式的代理组件。它的核心特点就是“协议翻译”——本来只认Bedrock协议的客户端或模型，经过Jevan一转，就能直接使用OpenAI/Anthropic格式的请求。这次AI网关把它做成一个可选模式内置进来，等于把这层协议翻译能力直接内嵌到了网关里，用户在网页上点两下就能启用，不用再自己单独部署和运维一套Jevan服务。

那这个功能适合谁来用？如果你手里有一个或多个基于Bedrock的模型接入需求，同时又希望保留AI网关的统一鉴权、智能路由、日志审计能力，这个模式就是为你准备的。如果你是一个只管调用OpenAI接口的开发者，暂时用不到Bedrock，那这个模式跟你关系不大，但了解一下路由策略的维度设计也是有价值的。

后面我会把Jev模式的实现原理、路由配置过程、在我自己服务器上的完整实操记录，以及几个坑的排查思路，一步步拆开来讲。

1.2 场景延伸与技术背景

这次功能更新落地的场景，其实比表面上看起来要大。

1Panel这个运维面板本身，用户基数不小，很多人已经不是在跑一台裸机，而是开了一台云服务器之后，先用1Panel把网站部署、反向代理、数据库、对象存储这些基础设施张罗齐了。最近看到的热搜词里有“1panel配置反向代理 多个网站”“1panel 实现虚拟主机功能”“绑定多个域名”，基本反映出一个趋势：越来越多的人正在把1Panel当作服务器管理的默认入口，而不是仅仅当一个测试玩具。

在这个基础上再叠一层AI能力，路径就非常顺滑了。你已经有多个域名，可能其中一个就预留给了AI服务入口，比如ai.example.com。你用1Panel的OpenResty（它的Web服务器组件）建一个反向代理站点，把ai.example.com指到内部AI网关的端口。客户端往ai.example.com/v1发请求，实际打到的是1Panel管理的AI网关容器。这样域名绑定、SSL证书、反向代理、网关路由全部由一套工具链管理，运维心智负担小很多。

Jev模式在这个链路里扮演的角色，是让“网关后端”这一层不再局限于OpenAI/Anthropic系，而是能向下兼容Bedrock系的模型服务。换句话说，你前端请求格式不用变，后端从openai/gpt-4o切换到bedrock/claude-sonnet，网关内部自动做协议转换，客户端无感知。

这正是智能路由真正值钱的地方。很多自建AI网关的方案，本质上只是个“转发器”，没有真正的路由智能。而1Panel这个AI网关智能路由，路由判断不只看模型名，还能结合上游状态、请求上下文、模型能力标签、成本权重等多维信息来决策。Jev模式的加入，等于又多了一个模型后端维度，路由时可选择的“出口”变多了，容灾和成本优化空间也更大。

2. AI网关智能路由架构与Jev模式定位

2.1 路由框架的工作机制

讲Jev模式之前，先把AI网关智能路由整体框架捋清楚。这套系统的架构可以拆成三层：

第一层是接入层，统一暴露一个兼容OpenAI格式的API端点（通常就是/v1/chat/completions）。应用只认识这个端点，不需要关心后端到底是哪个模型服务。这一层负责鉴权，每个调用方分配一个API Key，按Key控制配额和速率。

第二层是路由决策层，它是整个网关最核心的部分。请求进来后，网关先在内部做一次“语义解析”，识别模型名、上下文长度、是否带工具调用等参数，再结合规则引擎匹配路由目标。规则可以是固定模型映射，也可以是动态挑选策略，比如“同一模型ID背后有多个provider时，按权重拆分流量”或者“主provider超时后自动降级到备provider”。

第三层是后端适配层，也就是这次Jev模式所在的层级。适配层把网关内部的统一请求格式翻译成每个provider的协议格式。OpenAI格式的翻译器已经成熟，Anthropic格式的也能用，Bedrock协议这一块原来一直是短板——直到Jev模式补位。

从代码视角看，适配层通常是一个多态接口，每种模式实现同一个抽象类，核心方法就是call_model(messages, parameters)。新增一种模式，主要是实现请求头和请求体重组、响应流式解析这两个环节。

我用一个生活类比来解释：网关相当于公司的总机接线员。客户打电话进来，说“我要找技术部的张三”（请求里带模型名），接线员根据通讯录（路由表）把人接到对应分机（后端provider）。Jev模式相当于总机专门配了一个“懂外语的翻译员”，客户说的是普通话，但后端分机只听英语，翻译员在中间把普通话转成英语再接过去，客户和分机都不用改变自己的习惯。

2.2 Jev模式的技术角色拆解

Jev模式在网关里的具体实现，本质上是注入了一个“协议转换通道”。通道入口是AI网关处理完路由决策后的统一调用请求，出口是Bedrock的API接口。

Jevan的转换逻辑有一个很关键的设计——它不是简单地把JSON字段改个名就完事，而是做了语义层面的对齐。举个例子，OpenAI的max_tokens参数和Bedrock的max_tokens都叫max_tokens，参数名可以直接映射，但系统提示词的处理不一样。OpenAI系统提示词是独立的system角色消息，Bedrock在Claude模型上推荐使用system字段携带；Jevan在做转换时会把消息列表里的system内容提取出来，放到Bedrock请求的system位置，避免因为消息结构不对导致模型拒答。

另一个容易踩坑的是流式响应格式。OpenAI的流式返回是data: {"choices":[{"delta":{"content":"..."}}]}，每个chunk里的内容是增量；Bedrock的流式返回是chunk事件里带bytes字段，内容是base64编码的文本块。Jevan在返回路径上要做逆转换——把Bedrock的chunk解析成明文token，再封装成OpenAI格式的增量delta包。这个过程涉及base64解码、文本增量计算、状态保持，处理不好就是乱码或者重复字符。

AI网关这次引入Jev模式，做得比较务实的一点是没让用户自己去配Jevan实例，而是把协议转换器以插件形式内置，用户在UI上勾选启用即可，底层的Jevan容器自动拉起、自动组网。

2.3 三种模式选型对比

为了让你清楚什么时候用哪种模式，我把AI网关智能路由常见的三种模式拉出来对比一下：

从这张表能看出来，Jev模式并不是替换前两种，而是补齐Bedrock这条线。它的存在意义是“被选为Fallback”或者“在Bedrock为主用场景下做统一转发”。正常生产环境三种模式可以并存，按模型ID区分路由目标即可。

3. Jev模式的安装与配置

3.1 环境准备

先说明一下我这次实操的前提条件，方便你对号入座。

服务器是一台2C4G的云主机，操作系统是Debian 12，已经安装好了1Panel（我用的是1.10.x版本），Docker运行正常，磁盘剩余空间至少要有10GB——因为除了AI网关本身，还有模型镜像、Jevan组件，如果后面想本地跑一个小模型做测试，空间越大越从容。

如果你的1Panel还在老版本，建议先升级到最新版，因为AI网关智能路由这个应用是随1Panel应用商店更新的，旧版的面板不一定能拉到最新版本的应用模板。升级1Panel不会动到已部署的应用数据，但从经验上看，升级前手动备份一下数据库总归稳妥。

准备工作清单：

• 1Panel面板正常运行，能够正常访问应用商店
• Docker和Docker Compose正常（1Panel安装时会一并装好）
• 准备一个或多个上游模型服务的API Key，比如Bedrock的凭证，这个后边要在配置里用到
• 预留一个域名用于AI网关的对外访问，比如ai.example.com（可选，但推荐，因为走域名比裸IP管理起来正规）
• 确认服务器的时间同步正常——这个细节很多人忽略，Bedrock调用基于AWS签名机制，时间偏移超过5分钟会导致签名校验失败

我见过不少朋友把时间同步问题当成API Key不对来排查，白折腾一个小时。

3.2 在1Panel中安装AI网关

打开1Panel面板，进入应用商店，搜索“AI网关”或者“AI网关智能路由”，你应该能看到这个应用。点安装，注意安装界面有几个选项：

• 端口设置：默认会分配一个端口，我这次用的是19999
• 用户密码：设置一个管理后台的登录密码
• 内存限制：默认256MB，如果并发请求量大建议调到512MB，但如果是4G内存的机器，256MB起步也不算错

安装过程本质上是拉取几个镜像并编排起容器。等待时间取决于服务器网络，国内服务器如果拉镜像慢，建议先在1Panel的镜像加速配置里把加速地址填好，可以省下不少时间。

装完之后，浏览器访问http://服务器IP:19999，用刚才设置的管理密码登录，进入AI网关的管理后台。第一次登录会要求创建一个访问用的API Key，这个Key是给业务系统调用的，跟后台登录密码不是一回事，注意区分。

管理后台界面分几个功能区：左侧是资源统计、日志、设置这些，中间区域是模型管理、路由管理、API Key管理。新装完是空状态，所有模型列表、路由规则都要自己配置。

3.3 配置Jev模式

这是这次功能更新的核心环节。我按照实际操作顺序，列出完整配置流程。

第一步：打开“模型管理”（不同版本可能叫“模型市场”或“Provider”），点击“新增模型”。这里要注意，不是直接填模型名，而是先选择“模型服务商”类型。

第二步：在服务商类型里选“Bedrock”，这种方式下会自动激活Jev模式的协议转换通道。如果你选的还是OpenAI或Anthropic，那走的是原逻辑，只有选Bedrock/Jev才会启用转换器。

第三步：填写AWS凭证信息。需要在AWS控制台创建一组ACCESS KEY，权限方面至少要允许Bedrock的InvokeModel和InvokeModelWithResponseStream操作。把以下信息填进去：

访问密钥ID（Access Key ID） 访问密钥（Secret Access Key） 区域（Region）：如 ap-northeast-1（东京）或 us-east-1（弗吉尼亚北部）

如果是在国内服务器上访问AWS端点，区域选东京通常延迟会低一些。

第四步：填写模型映射。Jev模式的优势在于你可以用OpenAI风格的模型ID去映射Bedrock上的模型。比如：

模型ID（对外暴露）：claude-sonnet 实际调用的Bedrock模型ID：anthropic.claude-3-5-sonnet-20241022-v2:0

这是一对一的显式映射，对外统一暴露claude-sonnet。也可以建立多个映射，比如：

gpt-4o（对外别名） → anthropic.claude-3-5-sonnet-20241022-v2:0（Bedrock实际模型） claude-3-haiku → anthropic.claude-3-haiku-20240307-v1:0

这么做的用意很明显：应用代码里的模型名完全不用变，只要在网关里把新模型的映射关系配上，后端切换对业务方透明。这是一个非常实用的升级路径。

第五步：测试连通性。配置页面一般会有一个“测试连接”按钮，保存前先跑一次。这一步会实际调用一次Bedrock的接口，如果凭证错了、区域错了、或者权限不够，都会在这一步暴露出来。

测试通过后，保存配置。Jev模式就生效了。此时发请求到AI网关的/v1/chat/completions端点，网关会把OpenAI格式的请求体转换成Bedrock协议，转发给Bedrock；拿到响应后再转换回OpenAI格式，返回给调用方。

配置过程中有一个容易忽略的点：Bedrock上的模型分“按需”和“预置吞吐”，前者不需要提前购买容量，按token计费；后者需要预先购买专用容量。如果你在测试时发现HTTP 400错误消息里带no capacity之类的字眼，多半是模型ID填错或者进了预置容量的坑。家庭或中小团队使用，按需模式就够了，不用碰预置吞吐。

3.4 智能路由规则设置

模型接好之后，真正体现“智能路由”的部分来了。

进入“路由规则”或“策略管理”页面，把刚才配置好的Jev模型加入路由池。这里的核心玩法是“一个别名，对应多个真实provider，按条件分流”。

举例说明。我在网关里建立了一个路由别名claude-main，它同时指向两个后端：

• 后端A：Anthropic直连（走Anthropic模式），对应claude-sonnet-4-20250514
• 后端B：Bedrock上的anthropic.claude-3-5-sonnet-20241022-v2:0（走Jev模式）

路由策略我做了如下设置：

• 默认请求走后端A（主用）
• 当检测到请求上下文长度超过10万token时，自动切到后端B
• 当后端A连续返回5xx错误时，自动切到后端B，并标记后端A为“不健康”，冷却5分钟后自动恢复

这套策略的含义是：Jev模式不仅是“能接Bedrock”，更是“在关键时刻兜底”。因为Bedrock托管的Claude实例在长上下文场景下表现稳定，同时它也归属于你已开通的AWS资源，不会绕道增加一层外部依赖。

配置路由时，记得打开“健康检查”开关。网关会每隔一段时间（默认30秒）向后端发一个轻量级探测请求，连续失败N次后自动摘除该后端。这个开关是保障高可用的基础，强烈建议开启。

3.5 域名绑定与TLS配置

上面讲的是基础安装与配置，如果你的AI网关只在内网使用，到上一步就算完成了。但如果你想把网关暴露到公网，后面还要接域名和HTTPS。

基于前面提到的“1panel配置反向代理 多个网站”这个热搜词，这里有必要展开讲一下怎么在1Panel里给AI网关配反向代理，把裸IP访问升级成域名访问，还顺便把TLS证书挂上。

操作步骤：

1. 进入1Panel面板的“网站”页面，点击“创建网站”
2. 类型选择“反向代理”，填入域名ai.example.com
3. 目标地址填http://127.0.0.1:19999（注意这里填的是AI网关的监听地址；如果AI网关和1Panel在同一台机器，用127.0.0.1是对的；如果跨机器，填内网IP）
4. 保存后，申请Let’s Encrypt证书。1Panel自带证书申请流程，选HTTP验证或者DNS验证都行。有几台1Panel机器可以跑通HTTP验证的话，几分钟就下证书了
5. 开启HTTPS强制跳转

这样一个带HTTPS的AI网关公网入口就做好了。客户端访问https://ai.example.com/v1/chat/completions，请求先到1Panel的OpenResty，反向代理转发到AI网关容器，AI网关内部按Jev模式转换请求后转发到Bedrock。

整个过程相比裸奔IP，安全性和可维护性都好太多。另外如果你有多个域名，也可以按域名建多条反向代理规则，比如ai.example.com指向AI网关，blog.example.com指向Hexo博客，shop.example.com指向电商后端——1Panel的虚拟主机功能本质上就是同一套Web服务器按域名分发流量。你只需要把域名解析统统指向这台服务器，一条条站点配置加进去就行。

多域名绑定这个场景，我有一个实操建议：不要直接修改OpenResty的全局配置，所有网站入口都在1Panel里管理，每新增一个站点就建一条独立规则。这样升级面板、迁移服务器时，配置结构清晰，不会出现“某个站点突然打不开，配置找不着在哪儿改”的窘境。

4. 实操过程与核心环节实现

4.1 请求链路全程追踪

配置完成后，我从客户端发起一次真实请求，把链路完整跑一遍。先用curl做一个最基本的不带流式的测试：

curl --location 'https://ai.example.com/v1/chat/completions' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer sk-你的网关APIKey' \ --data '{ "model": "claude-main", "messages": [ { "role": "system", "content": "你是一名职场写作助手" }, { "role": "user", "content": "帮我写一封工作周报，150字以内" } ], "max_tokens": 300 }'

正常情况下，网关返回的响应结构是标准OpenAI格式：

{ "id": "chatcmpl-xxx", "object": "chat.completion", "created": 1735712345, "model": "claude-main", "choices": [ { "index": 0, "message": { "role": "assistant", "content": "本周主要完成了AI网关Jev模式的接入验证，推进了Bedrock后端联调..." }, "finish_reason": "stop" } ], "usage": { "prompt_tokens": 28, "completion_tokens": 78, "total_tokens": 106 } }

看到200响应并不代表链路全通，还需要验证一个容易出问题的地方——流式输出。因为流式走的就是之前提到的增量数据转换，这里单独跑一下：

curl --location 'https://ai.example.com/v1/chat/completions' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer sk-你的网关APIKey' \ --data '{ "model": "claude-main", "messages": [{"role": "user", "content": "用一句话介绍什么是AI网关"}], "stream": true }'

观察返回的SSE流：

data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"role":"assistant","content":""},"finish_reason":null}]} data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"content":"AI"},"finish_reason":null}]} data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"content":"网关是"},"finish_reason":null}]} data: [DONE]

如果Jev模式的流式转换有问题，你会在这里看到两种典型异常：一种是content字段整个返回空字符串，另一种是每个chunk返回的是一大段完整文本而不是增量。这两种情况分别对应转换层的状态丢失和增量计算逻辑错误，下文排查部分会细说。

流式验证通过，再升级到代码层面。我用Python的OpenAI SDK做了一个快速验证，确认SDK不用做任何改动就能正常调用：

from openai import OpenAI client = OpenAI( api_key="sk-你的网关APIKey", base_url="https://ai.example.com/v1" ) resp = client.chat.completions.create( model="claude-main", messages=[{"role": "user", "content": "你好，请简单介绍一下你自己"}] ) print(resp.choices[0].message.content)

这段代码里的model参数填的是claude-main，但实际背后走的是Jev模式转发。SDK什么都没感知，它只认为自己连了一个OpenAI兼容的服务。这就是网关做协议统一的意义所在。

4.2 挂载到实际业务场景：多域名网站接入

网关配置完毕，就该把它用起来了。我用“1Panel多站点反向代理”这个底座做了个业务场景串联。

我当前1Panel里有三个网站站点：

在站点B（AI网关）的反向代理配置里，我额外加了这么一段转发逻辑：

所有/v1/*路径的请求，都被反向代理到AI网关的19999端口。而工具箱站点C里有一个智能写作助手功能，它需要调用Claude模型。传统做法是工具箱直接去连AWS Bedrock SDK，代码里硬编码AWS凭证，密钥管理就成了大麻烦——前端页面引用了后端服务，后端服务拿着AWS密钥到处飞。

改造之后，工具箱后端只依赖一个环境变量：OPENAI_BASE_URL=https://ai.example.com/v1和OPENAI_API_KEY=sk-xxx。它不再需要直接接触任何AWS密钥，所有凭证只掌握在AI网关这一层。工具箱后端代码从“要去适配Claude API格式”简化为“假装自己在调用OpenAI”，开发成本和维护成本同时下降。

这一步做完，多域名站点、反向代理、AI网关、Jev协议转换连成了一条完整链路。对外看，每个站点各自独立、职责清晰；对内看，AI能力统一收口、权限统一管理，运维监控也只需要盯一个入口而不是盯着每家API。

4.3 模型切换与自动化策略配置

Jev模式的实际价值，在“多模型动态切换”场景下最能体现。

我在网关里配置了一条核心路由策略，逻辑如下：

路由别名：claude-main 默认策略：权重分配 目标A（Anthropic直连）——权重70% 目标B（Bedrock/Jev模式）——权重30% 降级策略： 当目标A连续错误次数≥3，权重降为0%，流量全部切到目标B 目标A冷却5分钟后自动恢复，权重逐步回升 成本策略： 当单日调用量超过500次后，默认走目标B（Bedrock按需计费单价略低）

这套配置落地后，遇到过一次真实的故障演练。我把目标A的API Key故意改错，模拟直连通道故障。观察管理后台的实时日志，网关在连续收到3次401错误后触发降级规则，后续请求自动转到Jev通道（Bedrock），客户端无感知，全程没有出现一例因为上游故障直接导致调用的报错。

值得注意的是，这里Jev通道本身的健康状态也会被实时监控。如果Bedrock侧也不稳定，网关会在两条通道之间来回切换，并根据配置的冷却时间做抖动抑制，避免频繁切换带来的颠簸。

这个场景想强调的核心经验是：Jev模式不是孤立的“接一个新型模型源”，它更大的价值在于成为多活/容灾/成本优化策略里的一个编队成员。你配置通道的时候，必须同时考虑路由策略的联动，而不是把每个通道当成独立烟囱。

5. 常见问题与排查技巧实录

5.1 连通性类问题

Jev模式上线之后，我在测试和实际使用中遇到了一批问题，把其中典型的几个整理在下面，应该覆盖大多数使用者会遇到的坑。

先快速给一张速查表：

5.2 流式转换异常专项

其实流式转换是因Jev模式而出问题概率最高的点，单独拿出来讲一下它的现象。

一个真实的case：某次测试时，我请求一个比较长的回答（生成400多个token），通过网关拿到完整响应没有任何问题，但从流式响应中只流出了前几十个token，后面内容直接丢失。这个问题的排查方向起初以为是网络中断，但直接用Bedrock SDK测没有出现同样问题，才想到是网关的转换层。

我最终定位到，这是流式响应的尾部处理逻辑存在缺陷：当Bedrock的流式事件在最后一个chunk没有包含显式的消息结束标记时，Jev的转换层没有正确生成finish_reason并终止SSE流，导致客户端等不到后续数据就主动断开了连接。

解决方式是升级AI网关到包含修复的版本。这里想提醒大家的是，Jev模式这类“多协议转换型网关”，流式兼容性必须当作第一优先级来测试。非流式模式下出现问题好排查，流式模式由于状态分散在多个chunk中，问题往往隐蔽得多。上线前做流式压测很有必要，我在实践中会写一个简单的脚本循环发送流式请求，每次请求完校验收到的响应文本与原始文本是否一致。

5.3 路由切换与监控排障

还有一个容易被忽视的问题：路由策略配置好后，网关不会像预期那样立刻切换到新后端。如果你把目标A的权重从100%改成0%，发现流量依然在目标A上，不要急着怀疑配置没生效，而是检查一下缓存。

AI网关智能路由的实现里，路由决策结果会做一定程度的本地缓存，以减少每次请求都去重新匹配规则的开销。这个缓存的默认TTL通常是60秒。所以你改了权重，至少要等一个TTL周期才能看到新策略生效。这不是bug，是设计取舍。

同理，如果在管理后台修改了模型映射表，比如把claude-main的实际目标从Anthropic直连改成Bedrock，同样存在延迟，改完立刻重启网关容器可以强制刷新，但这在生产环境不太推荐，等缓存自然过期更安全。

监控方面，我建议大家重点看这几个指标：

• 各路由目标的成功率（按5分钟粒度看趋势）
• Jev模式下的平均首字延迟（TTFT），这个指标直接反映协议转换层是否成为瓶颈
• 每分钟调用量中，Bedrock通道vs直连通道的分布
• Jev模式转换层的错误计数，这类错误一般不是上游问题，而是转换层本身的异常

我在实际使用中，把上述指标接到了Prometheus里，配合Grafana做了简单看板。同时配置了一个告警规则：如果Jev模式5分钟内成功率低于99%，立即触发通知。这个阈值在生产环境需要根据你的实际情况调整，但如果是面向外部客户的服务，99%是个合理的起步值。

6. 小结与我的实操心得

这次1Panel AI网关智能路由新增Jev模式，从功能完整度和实用价值来看，是值得肯定的更新。它把Bedrock接入的门槛降到了“网页上点几下”的级别，加上智能路由的多目标切换能力，让网关真正成为AI服务的统一入口。如果你的业务已经在用AWS Bedrock上的Claude，或者未来有跨模型容灾的规划，这个模式值得在你的服务器上实际部署试一把。

我在整个过程中有几个具体的体会，最后简单分享几点：

第一，Jev模式的核心是协议转换，转换层不是零开销的。实测下来，非流式请求增加的时间在10~30毫秒左右，绝大部分用户无感知。但流式请求的转化开销会体现在首字延迟上，如果你的场景是实时聊天，务必实测一下TTFT，不要想当然认为网关加个适配层不影响延迟。

第二，IAM权限要配细。给AI网关用的一组AWS凭证，权限范围限制在只允许Bedrock调用，不要给太多其他服务的权限。密钥万一泄露，攻击者至少没法直接访问你的S3或EC2资源。

第三，路由策略的容灾配置，生产环境必须启用“健康检查+冷却恢复”的组合。我自己踩过不配置冷却时间的坑——一条通道故障后流量切到备通道，备通道还没稳定时主通道恢复，结果网关在两条通道间来回横跳，错误率反而上去了。冷却时间设置5分钟起步，等稳定性确认了再逐步缩短。

第四，如果你决定把AI网关暴露到公网，域名配HTTPS是底线，但别忘了在入口处做一层IP白名单或者速率限制。1Panel的OpenResty层可以轻松加限制规则，结合网关自己的API Key认证，双重防护更稳妥。

这个项目后续我打算做的事情是在网关里继续接入一个本地小模型（通过Ollama跑一个7B级别的开源模型），和Bedrock上的模型一起加入路由池，做一套“低成本优先+高质量兜底”的成本优化策略。到时候有结果了再回来分享。