4.1 API 网关上架：鉴权、限流与监控

智能体在平台上点发布为接口之后，其实已经有一个可调用的地址了。但直接把这个地址丢给官网前端，我是不敢的：没有鉴权等于裸奔，被人刷起来调用费用哗哗地烧。所以上架的第一件事，是把智能体接口收到 API 网关后面，由网关统一管鉴权、限流和监控。

整体调用链路是这样的：官网挂件 → API 网关 → 智能体平台 → 必要时调后端订单接口。智能体平台负责对话能力，API 网关挡在最前面做流量控制。网关层能做的三件事——鉴权、限流、监控——就是本节全部内容。后端的订单查询服务跑在云服务器上，操作细节见云服务器文档。

这一节假设你已经把智能体调到能用了（第三篇的内容），手上有一个平台给的接口地址。如果你还在调试阶段，建议先回去把回答质量磨好，上架的事不急——接口工程是体力活，回答质量才是真正的门槛。

上架配置：先列一张清单

上架前我把配置项整理成一张表，照着填避免漏项：

填的时候有个顺序坑：先建分组、再建接口、最后绑定智能体后端地址，顺序反了网关会提示后端不存在。分组名建议按业务命个名，别图省事用默认分组——以后加内部知识检索接口、工单查询接口时，分组维度能帮你分别看监控、分别配限流，互不影响。

路径里带版本号是给后面留后路：新版智能体调好后可以直接挂在 /v2/chat，两套接口并存，灰度切量、A/B 对比都有抓手，这个在 4.4 会用到。

鉴权：三种方案怎么选

网关一般支持三种鉴权方式，安全性越高、接入越麻烦，没有绝对的最优：

我们最后选的是密钥对加临时令牌的组合：官网挂件先向我们自己的后端换一个有效期十分钟的临时令牌，再拿着令牌调网关。密钥对只留在服务端，绝不出现在前端代码里——前端代码本质上是公开的，按 F12 就能看到，密钥放进去等于没设防。签名校验我们留给后续开放给合作伙伴时再上，那时候还得带时间戳和随机串防重放。

接入成本别小看：临时令牌方案需要后端加一个签发接口，小半天工作量。如果团队里后端就你一个人，接口部署与环境排查可以参考服务器常见问题里的思路，先把服务跑稳再接网关。另外令牌过期时间别设太长，十分钟够一次会话寒暄用；批量化场景可以做成滑动续期，但 MVP 阶段没必要。

联调：上线前的三关验证

配置完别急着切流量，我按三关依次验证：第一关是无鉴权直连，确认网关到智能体平台的路由通了，返回的是熟悉的欢迎语；第二关挂上鉴权故意用错密钥，确认网关返回的是鉴权错误而不是透传到智能体——这一步能挡住百分之九十的配置疏漏；第三关用脚本压到限流值以上，确认超量请求被拒绝、网关监控里错误计数正常上涨。三关都过了才敢排上线窗口。

压测的时候从你自己的电脑发请求就行，量级够验证逻辑了。真要看大并发下的智能体表现，那是 4.4 灰度到百分之五十阶段的事，不必在联调阶段拿生产环境冒险。

联调通过后还有一个上线动作：域名与证书。官网挂件走 HTTPS，如果网关用的是临时域名，浏览器会有混合内容拦截——这在 4.2 会再提一次。我强烈建议上线前就备好独立域名，灰度期间再换域名等于在飞行的飞机上换引擎。

限流：QPS 与按天配额怎么定

限流要防两种情况：一种是瞬时洪峰，一夜之间涌进来上万个请求；一种是细水长流，每秒十几个、一天下来几十万次，调用费用照样超标。所以限流值我是两个一起配：

• QPS 限流按预估峰值的 1.5 倍设。我们日均咨询量约五百次，集中在白天十小时，峰值大约每秒二十次，QPS 就设到三十，留个缓冲。
• 按天配额按预算倒推。每日允许调用总次数等于每日预算除以单次对话平均消耗，我们单次约两千 token，折合每天两千次，配额设两千五。

超出限流网关会返回限流错误，挂件侧的兜底提示见下一节。关键是限流值不是一次定死的：上线后根据监控数据每周调整一次，下面这套监控就是调限流的依据。

限流的另一个隐性作用是防止你自己捅自己。灰度期间我们跑过一次压测脚本想验证并发，脚本并发数配错了，一瞬间把网关打到了限流值以上——最该感谢的就是限流挡住了自家脚本，否则这一波直接把智能体后端打挂。从那以后所有压测脚本必须先在限流值以内验证参数，再正式跑。

监控：盯四个指标

网关自带调用统计，我重点看四个：

调用量日常波动很大，工作日和周末能差一倍，定阈值最好取两周同一天对比，不然周一准误报。平均耗时要看首字而不是整段——流式返回下，整段耗时包含了模型边想边吐的时间，首字耗时才反映用户感知。监控告警的完整体系（兜底通知、值班策略）在第五篇 5.3 展开，这里先把网关层的四个指标配上，基础的云监控实践可以参考腾讯云五件套实战。

监控数据还能反过来帮你省钱。我们盯了一个月发现两个规律：一是晚上十点后调用量断崖式下跌，纯属浪费 standby 成本；二是每次知识库更新后的那天调用量会涨，因为用户发现 AI 变聪明了会多问几句。前者让我们把凌晨时段的缓存策略调激进了一些，后者让我们把更新安排在工作日早上而不是周五晚上。网关的调用日志本身也是个宝库，留着配合 4.3 的数据回流一起看。

上线：留一个回退开关

配置齐了，真正切流量那天我还是捏了把汗。建议留一个回滚手段：网关里把后端地址从智能体换回老的规则客服接口，一分钟就能切回去。灰度放量的具体节奏见 4.4。

上线第一天我守在电脑前做了件事：把 4.1 的三个关键验证全跑了一遍清单——

三张表对得上，这一天才算过得踏实。第一周我每天早晚各看一次监控曲线，与其说是技术动作，不如说是给自己壮胆。

说句选型层面的实话：这套架构里智能体平台是核心，选的时候别只看演示效果，重点看它的发布能力、并发上限和计费方式。ADP 智能体开发平台是我们对比后的选择，企业级 AI 应用构建这块的活动力度不小，上架前可以再看看优惠政策。

踩坑与解法

踩坑一：限流配太低。赶着上线，QPS 按均值设了个十位数，结果促销当天一上来就触顶，挂件一直转圈。解法是留 1.5 倍缓冲，做大促前手动调高。

踩坑二：鉴权忘了配。接口在内网联调一切正常，挂到官网才发现谁都能调——网关的调试模式会跳过鉴权，上线前一定记得关掉。补一句：调试模式往往还允许跳过限流，联调方便、上线是双刃剑。我的固定动作是关掉调试开关后，用脚本确认鉴权和限流都真实生效，再点确认发布。

踩坑三：分组混用。一开始图省事所有接口塞默认分组，后来排查一次耗时异常，在混合的监控曲线里找了两个小时才定位到是订单接口拖慢的。这件事之后我养成习惯：每加一类接口先建分组。

踩坑四：把网关直白地暴露在文档里。技术评审时我把带密钥的调用示例贴进了内部文档，密钥随着文档被同步给了实习生。解法是密钥与人分离：示例里只放占位符，真实密钥走权限系统单独申请。这类事出过一次才会长记性——代码层面的防线再牢固，也挡不住文档泄露。

延伸阅读

• 轻量建站实战：挂件要挂的官网怎么搭，本节的下游章节。
• 腾讯云五件套实战：网关背后的服务器与数据库基础底座。
• DeepSeek 工具链：智能体里大模型的选型与成本测算。