1. 企业大模型网关到底解决什么问题1.1 从一个真实困境说起去年下半年我帮一家两百多人规模的软件公司做内部 AI 工具链改造。当时他们的状态很典型前端组用某海外模型的网页版后端组自己申请了另一家的 API Key测试组在用某个国产模型运维组甚至有人偷偷在服务器上跑本地模型。月底财务拿着账单来找我说这个月 AI 相关支出比上个月翻了三倍但没人说得清钱花在哪、谁在用、用来干什么。这不是个例。只要公司里超过二十个人开始用大模型就一定会遇到三个问题密钥满天飞、成本不可控、数据无审计。每个团队各自申请 Key离职了 Key 还在用有人拿公司 Key 跑个人项目敏感代码被贴进外部对话框出了事查不到源头。企业大模型网关LLM Gateway就是冲着这三个问题来的。你可以把它理解成公司内部的AI 前台所有对模型的请求都不再直连厂商而是先经过这个网关由它统一做鉴权、路由、限流、计费和日志。对开发者来说接口还是那个 OpenAI 兼容格式几乎无感对管理者来说终于有了一个能看清全局的仪表盘。1.2 网关的核心能力拆解很多人第一次听到网关会以为是反向代理换个名字其实差得远。一个能落地的企业级大模型网关至少要具备下面这几层能力缺一层都会在真实场景里翻车。统一协议层是最基础的一层。市面上的模型厂商接口格式五花八门有的兼容 OpenAI 的/v1/chat/completions有的自成一派。网关要做的是把所有上游统一成一套对外协议通常是 OpenAI 格式因为生态最成熟客户端 SDK 最多。这样业务侧换模型只需要改一个模型名参数不用动代码。路由与调度层决定了网关的智能程度。最简单的路由是按模型名转发复杂一点的会做负载均衡、故障转移、成本优先路由。比如你配置了三个同能力的模型网关可以按当前配额余量、响应延迟、单价自动选一个最划算的。我见过做得好的网关能在某个厂商接口抖动时 200 毫秒内切到备用通道业务侧完全无感知。计量与配额层是给管理者看的。每个部门、每个项目、每个 Key 都要有独立的额度按 Token 数或按调用次数计费。这里有个坑不同模型的 Token 计价方式不一样输入输出价格也不一样网关必须能按模型分别配置单价表否则算出来的账是错的。审计与安全层是最容易被忽视但最要命的一层。所有请求和响应要留痕敏感词要过滤Prompt 里如果出现身份证号、手机号、内部项目代号要能拦截或脱敏。我建议日志至少保留 90 天因为很多数据泄露事件是事后一两个月才被发现的。1.3 为什么自建而不是买现成的市面上确实有商业网关产品但企业真正落地时自建的比例远高于预期。原因不复杂网关处在数据流的咽喉位置很多公司不愿意把内部 Prompt 和响应交给第三方。哪怕对方承诺不存储合规部门那一关也过不去。自建的技术门槛其实没有想象中高。一个最小可用的网关核心就是一个 FastAPI 或 Express 服务加上 Redis 做配额计数、PostgreSQL 做日志存储。真正花时间的是周边管理后台、Key 的轮换机制、和现有 SSO 的对接、监控告警。我当时的做法是先上一个能跑的最小版本两周内让内部用起来然后根据反馈迭代比憋三个月做个完美方案务实得多。提示网关本身不产生智能它只是流量的调度者。不要指望上了网关就能提升模型效果它的价值在于治理和成本。2. 自动化编程 Agent 与 CLI 工具的落地路径2.1 Agent 和普通脚本的本质区别热词里agent和harness 和 agent 区别出现频率很高说明很多人对这两个概念还是模糊的。我用一句话区分脚本是你告诉它每一步怎么做Agent 是你告诉它目标它自己决定怎么做。举个具体例子。你要批量给一百个文件加版权头。写脚本的话你得自己遍历目录、判断文件类型、处理编码、写回文件每一步都是你写死的。而 Agent 的做法是你给它一个目标给 src 目录下所有 .ts 文件加上版权头跳过已经有的它会自己规划——先列目录、再读文件、判断是否已有、决定用什么方式写入、遇到二进制文件跳过。中间某一步失败了它还会自己重试或换方案。Harness 则是另一回事。它更像是 Agent 的测试台或运行框架负责给 Agent 提供工具、管理上下文、控制执行循环。你可以把 Agent 理解成司机Harness 理解成车——司机决定去哪车提供油门刹车方向盘。很多 Agent 框架比如一些开源项目其实主要工作是在做 Harness真正的智能来自背后的大模型。2.2 CLI 工具为什么重新火起来这两年 CLI 类 AI 编程工具扎堆出现从早期的各种 code 助手到现在的 codex cli、zcode cli、trae cli本质上是大家在重新发现命令行的价值。图形界面看着友好但在真实开发流里开发者 80% 的时间在终端里切来切去反而低效。CLI 工具的核心优势有三个。第一是可组合它能和 git、grep、make 这些老牌工具串起来用一条管道解决复杂任务。第二是可脚本化你可以把常用操作写成 shell 函数一键触发。第三是上下文天然丰富CLI 工具能直接读到当前目录、git 状态、环境变量不需要你手动粘贴一堆信息。我自己的日常是这样的在项目根目录敲一个命令让 Agent 读一遍最近的 git diff然后自动生成 commit message 并提交。整个过程三秒比手动写快十倍而且格式统一。这种小到不值得写脚本、但又天天要做的任务正是 CLI Agent 的最佳战场。2.3 从单点工具到工作流编排单个 CLI 工具能解决的问题有限真正的效率提升来自把多个 Agent 串成工作流。比如一个典型的代码审查流程第一个 Agent 读 PR diff 找出潜在 bug第二个 Agent 检查是否符合团队规范第三个 Agent 生成审查意见草稿。三个 Agent 各司其职通过网关统一调用模型日志统一记录。这里就体现出网关和 Agent 的协同价值了。Agent 是干活的手网关是管账的管家。没有网关Agent 调用模型就是一笔糊涂账没有 Agent网关只是个被动的转发器。两者结合才能既提效又可控。3. 大模型网关的实操搭建过程3.1 环境准备与依赖选型先说技术栈。我推荐Python FastAPI作为网关主体理由是异步性能好、生态成熟、团队上手快。如果你团队是 Node 背景Express 或 Fastify 也完全够用。数据库用 PostgreSQL 存日志和配置Redis 做配额计数和缓存。部署用 Docker Compose 起步规模上来再上 K8s。依赖清单大致如下# 核心依赖 fastapi0.110.0 uvicorn[standard]0.27.0 httpx0.27.0 # 异步 HTTP 客户端用于转发请求 redis5.0.1 sqlalchemy2.0.25 psycopg2-binary2.9.9 pydantic2.6.0选 httpx 而不是 requests是因为网关要处理高并发转发异步客户端能显著降低资源占用。实测下来同样的机器配置httpx 异步方案能扛的并发是 requests 同步方案的三到四倍。3.2 核心转发逻辑的实现网关最核心的一段代码就是接收请求、鉴权、选上游、转发、记录。下面是我实际用的简化版逻辑去掉了业务定制部分from fastapi import FastAPI, Request, HTTPException import httpx, time, json app FastAPI() client httpx.AsyncClient(timeout60.0) UPSTREAMS { gpt-4: {url: https://api.example-a.com/v1/chat/completions, key: sk-a-xxx, price_in: 0.03, price_out: 0.06}, claude-3: {url: https://api.example-b.com/v1/messages, key: sk-b-xxx, price_in: 0.015, price_out: 0.075}, } app.post(/v1/chat/completions) async def proxy(req: Request): body await req.json() model body.get(model) upstream UPSTREAMS.get(model) if not upstream: raise HTTPException(400, funknown model: {model}) # 鉴权校验内部 Key internal_key req.headers.get(authorization, ).replace(Bearer , ) if not await check_key(internal_key): raise HTTPException(401, invalid key) # 配额检查 if not await check_quota(internal_key, model): raise HTTPException(429, quota exceeded) start time.time() resp await client.post( upstream[url], headers{Authorization: fBearer {upstream[key]}}, jsonbody, ) latency time.time() - start result resp.json() usage result.get(usage, {}) cost usage.get(prompt_tokens, 0) * upstream[price_in] / 1000 \ usage.get(completion_tokens, 0) * upstream[price_out] / 1000 await log_request(internal_key, model, usage, cost, latency) return result这段代码看着简单但有几个细节值得说。超时设置我给了 60 秒因为大模型生成长文本确实慢设太短会误杀正常请求。价格计算按千 Token 计价注意输入输出分开算很多新手会漏掉这一点导致账单对不上。日志写入建议异步不要阻塞主请求链路否则高并发时日志会成为瓶颈。3.3 配额与限流的实现细节配额这块我踩过坑。最初用 Redis 的INCR做简单计数结果发现两个问题一是跨天重置需要额外的定时任务二是并发场景下计数会有微小误差。后来改成用 Redis 的滑动窗口方案配合 Lua 脚本保证原子性。-- 滑动窗口限流 Lua 脚本 local key KEYS[1] local limit tonumber(ARGV[1]) local window tonumber(ARGV[2]) local now tonumber(ARGV[3]) redis.call(ZREMRANGEBYSCORE, key, 0, now - window) local count redis.call(ZCARD, key) if count limit then redis.call(ZADD, key, now, now .. - .. math.random()) redis.call(EXPIRE, key, window) return 1 else return 0 end这个脚本的好处是精确到毫秒级窗口不会出现整点重置时瞬间涌入大量请求的问题。配额维度我建议至少分三层全局总额度、部门额度、个人 Key 额度。任何一层超了都拒绝这样既能防单点滥用也能防整体超支。注意限流阈值不要设得太死。我见过有团队把个人额度设成每天 100 次结果开发同学调试一个功能就用完了反而逼着他们去申请更多 Key适得其反。建议初期宽松观察一周真实用量后再收紧。3.4 日志与审计的落地日志表结构我建议至少包含这些字段请求 ID、内部 Key、模型名、输入 Token、输出 Token、费用、延迟、状态码、时间戳、Prompt 摘要。Prompt 全文要不要存我的建议是存摘要不存全文摘要用前 200 字符加哈希值既能追溯又不至于把敏感内容全落库。如果合规要求必须存全文那一定要加密存储并且访问日志本身也要审计——谁在什么时候查了哪条记录。我见过一个案例内部员工利用日志查询权限把别人的 Prompt 内容导出来这属于典型的审计系统本身没被审计。4. 自动化编程 Agent 的实操与避坑4.1 CLI 工具的安装与常见报错热词里出现了不少安装报错比如missing optional dependency openai/codex-win32-x64、npm:无法加载文件、internetopenurl() failed。这些我基本都遇到过逐个说下排查思路。missing optional dependency这类错误九成是 npm 的可选依赖机制在特定平台没装全。解决办法是先卸载再重装并且指定平台npm uninstall -g openai/codex npm install -g openai/codexlatest --includeoptional如果还不行检查 npm 版本老版本 npm 对 optional dependencies 的处理有 bug升级到 10.x 以上基本能解决。npm:无法加载文件这种通常是 PowerShell 的执行策略问题。Windows 上默认不允许运行脚本需要改策略Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned改完重开终端即可。这个坑我踩过两次第一次折腾了半小时才反应过来是策略问题。internetopenurl() failed一般是网络层的问题可能是代理配置、DNS 解析或证书问题。先确认基础网络通不通再检查环境变量里有没有残留的代理设置。4.2 Agent 怎么扛并发ai agent 怎么扛并发是个好问题因为 Agent 和普通 API 不一样它一次任务可能调用模型十几次每次都有延迟。如果一百个用户同时触发 Agent后端瞬间就是上千个模型调用。我的经验是三层削峰。第一层是任务队列用户请求先进队列Agent 从队列里取任务执行避免瞬时打满。第二层是并发上限每个 Agent 实例限制同时处理的任务数超出的排队。第三层是模型调用池对同一个上游模型的并发调用做统一限流防止把厂商接口打挂。具体参数上我一般这样配单 Agent 实例并发 5 到 10 个任务模型调用池按上游配额设上限队列长度设成并发数的 10 倍。这样即使突发流量也能平滑处理不会雪崩。4.3 Agent 安全不能只靠提示词agent安全这个词最近被讨论得很多。很多人以为在 System Prompt 里写一句不要执行危险操作就够了这是自欺欺人。Agent 能调用工具就意味着它能真实地改文件、发请求、执行命令提示词层面的约束很容易被绕过。我的做法是在工具层做硬约束。比如文件写入工具限制只能写项目目录内的文件路径里出现..直接拒绝。命令执行工具维护一个白名单只允许跑git、npm、pytest这类安全命令rm、curl这种一律禁止。网络请求工具限制只能访问白名单域名。这些约束写在代码里不写在提示词里。提示词是建议代码是法律。Agent 再聪明也绕不过代码层的检查。4.4 常见问题速查表问题现象可能原因排查方向Agent 执行中途终止上下文超限或工具报错看日志最后一步检查 Token 用量CLI 命令无响应网络阻塞或进程卡死加超时参数检查网络连通性模型返回乱码编码不一致统一 UTF-8检查响应头配额突然耗尽有循环调用或重试风暴查日志调用频次加退避策略网关转发 502上游不可达或超时检查上游健康加故障转移Agent 重复执行同一操作状态未持久化引入任务状态存储做幂等这张表是我从实际故障里总结的每一条都对应过至少一次真实事故。建议打印出来贴在工位上出问题时先对照排查能省不少时间。5. 网关与 Agent 的协同架构5.1 整体架构设计把网关和 Agent 放在一起看一个完整的企业 AI 基础设施应该是这样的分层最上层是业务应用IDE 插件、聊天工具、自动化脚本中间是 Agent 编排层负责任务规划、工具调用、状态管理下面是网关层负责鉴权、路由、计量最底层是模型厂商。这个分层的好处是职责清晰。业务侧只管提需求Agent 侧只管干活网关侧只管治理模型侧只管推理。任何一层要换实现其他层不受影响。比如你想从 A 厂商换到 B 厂商只改网关配置想换个 Agent 框架只改编排层。5.2 数据流与可观测性数据流是这样的业务请求带着内部 Key 到网关网关鉴权后转发给 Agent 服务Agent 调用模型时再经过网关用服务账号的 Key网关记录每一次模型调用。这样一条完整的链路从用户点击到模型响应每一跳都有日志。可观测性上我建议至少监控四个指标请求量、延迟 P95、错误率、Token 消耗。前三个是健康度指标第四个是成本指标。任何一个异常波动都要能告警。我当时的做法是用 Prometheus 采集Grafana 展示阈值告警推到企业 IM。5.3 成本优化的几个实操技巧成本这块能省的地方比想象中多。第一缓存高频请求。很多 Agent 任务里系统提示词是固定的这部分可以缓存不用每次都传。第二用小模型做预处理。比如判断一个任务该走哪个流程用便宜的小模型就够了没必要上最贵的。第三压缩上下文。Agent 的历史对话不要全量传做摘要或截断能省大量输入 Token。我实测过一个案例一个代码审查 Agent优化前每次调用平均消耗 8000 输入 Token优化后压到 3000成本直接降了六成效果几乎没差别。关键就是把重复的系统提示词缓存了历史对话做了摘要。6. 落地过程中的经验与教训6.1 先跑通再优化我见过太多团队在设计完美架构上耗掉几个月结果一行生产代码没上线。正确的做法是先用最土的办法跑通闭环一个简单的转发服务、一个硬编码的 Key 列表、一个 CSV 记日志。跑起来之后真实问题会自己冒出来你才知道该优化什么。我自己的第一个网关版本只有 200 行代码没有数据库配额存在内存里重启就丢。但它让我在一周内摸清了团队的真实使用模式后面所有的优化都是有的放矢。6.2 文档和培训比技术更重要网关上线后最大的阻力不是技术是人的习惯。开发者习惯了直接拿 Key 调厂商你让他改成走网关他会觉得麻烦。这时候光有技术方案没用得配上清晰的文档和一次简短的培训。我的做法是写一份三分钟接入指南只讲怎么改 base_url 和 Key其他一概不提。再录一个两分钟的视频演示从申请 Key 到跑通第一个请求的全过程。文档越短看的人越多。6.3 安全是持续过程不是一次性任务最后说个容易被忽视的点安全不是上线时检查一遍就完事。新的攻击手法、新的模型能力、新的业务场景都会带来新的风险。我建议每季度做一次安全复盘检查 Key 轮换、权限收敛、日志审计这些机制是否还在正常运转。我踩过的一个坑是上线时配了 Key 自动轮换但半年后有人改了配置把轮换关了没人发现。直到一次安全扫描才暴露出来。所以关键机制要有监控不能只靠配置。这套东西我从零搭到稳定运行前后花了大概四个月中间返工过两次。如果让我重来一遍我会把网关和 Agent 分开推进先让网关稳定跑一个月再上 Agent避免两个新系统同时出问题、互相甩锅。这个顺序上的经验比任何技术细节都值钱。
企业大模型网关与自动化编程Agent落地实践指南
1. 企业大模型网关到底解决什么问题1.1 从一个真实困境说起去年下半年我帮一家两百多人规模的软件公司做内部 AI 工具链改造。当时他们的状态很典型前端组用某海外模型的网页版后端组自己申请了另一家的 API Key测试组在用某个国产模型运维组甚至有人偷偷在服务器上跑本地模型。月底财务拿着账单来找我说这个月 AI 相关支出比上个月翻了三倍但没人说得清钱花在哪、谁在用、用来干什么。这不是个例。只要公司里超过二十个人开始用大模型就一定会遇到三个问题密钥满天飞、成本不可控、数据无审计。每个团队各自申请 Key离职了 Key 还在用有人拿公司 Key 跑个人项目敏感代码被贴进外部对话框出了事查不到源头。企业大模型网关LLM Gateway就是冲着这三个问题来的。你可以把它理解成公司内部的AI 前台所有对模型的请求都不再直连厂商而是先经过这个网关由它统一做鉴权、路由、限流、计费和日志。对开发者来说接口还是那个 OpenAI 兼容格式几乎无感对管理者来说终于有了一个能看清全局的仪表盘。1.2 网关的核心能力拆解很多人第一次听到网关会以为是反向代理换个名字其实差得远。一个能落地的企业级大模型网关至少要具备下面这几层能力缺一层都会在真实场景里翻车。统一协议层是最基础的一层。市面上的模型厂商接口格式五花八门有的兼容 OpenAI 的/v1/chat/completions有的自成一派。网关要做的是把所有上游统一成一套对外协议通常是 OpenAI 格式因为生态最成熟客户端 SDK 最多。这样业务侧换模型只需要改一个模型名参数不用动代码。路由与调度层决定了网关的智能程度。最简单的路由是按模型名转发复杂一点的会做负载均衡、故障转移、成本优先路由。比如你配置了三个同能力的模型网关可以按当前配额余量、响应延迟、单价自动选一个最划算的。我见过做得好的网关能在某个厂商接口抖动时 200 毫秒内切到备用通道业务侧完全无感知。计量与配额层是给管理者看的。每个部门、每个项目、每个 Key 都要有独立的额度按 Token 数或按调用次数计费。这里有个坑不同模型的 Token 计价方式不一样输入输出价格也不一样网关必须能按模型分别配置单价表否则算出来的账是错的。审计与安全层是最容易被忽视但最要命的一层。所有请求和响应要留痕敏感词要过滤Prompt 里如果出现身份证号、手机号、内部项目代号要能拦截或脱敏。我建议日志至少保留 90 天因为很多数据泄露事件是事后一两个月才被发现的。1.3 为什么自建而不是买现成的市面上确实有商业网关产品但企业真正落地时自建的比例远高于预期。原因不复杂网关处在数据流的咽喉位置很多公司不愿意把内部 Prompt 和响应交给第三方。哪怕对方承诺不存储合规部门那一关也过不去。自建的技术门槛其实没有想象中高。一个最小可用的网关核心就是一个 FastAPI 或 Express 服务加上 Redis 做配额计数、PostgreSQL 做日志存储。真正花时间的是周边管理后台、Key 的轮换机制、和现有 SSO 的对接、监控告警。我当时的做法是先上一个能跑的最小版本两周内让内部用起来然后根据反馈迭代比憋三个月做个完美方案务实得多。提示网关本身不产生智能它只是流量的调度者。不要指望上了网关就能提升模型效果它的价值在于治理和成本。2. 自动化编程 Agent 与 CLI 工具的落地路径2.1 Agent 和普通脚本的本质区别热词里agent和harness 和 agent 区别出现频率很高说明很多人对这两个概念还是模糊的。我用一句话区分脚本是你告诉它每一步怎么做Agent 是你告诉它目标它自己决定怎么做。举个具体例子。你要批量给一百个文件加版权头。写脚本的话你得自己遍历目录、判断文件类型、处理编码、写回文件每一步都是你写死的。而 Agent 的做法是你给它一个目标给 src 目录下所有 .ts 文件加上版权头跳过已经有的它会自己规划——先列目录、再读文件、判断是否已有、决定用什么方式写入、遇到二进制文件跳过。中间某一步失败了它还会自己重试或换方案。Harness 则是另一回事。它更像是 Agent 的测试台或运行框架负责给 Agent 提供工具、管理上下文、控制执行循环。你可以把 Agent 理解成司机Harness 理解成车——司机决定去哪车提供油门刹车方向盘。很多 Agent 框架比如一些开源项目其实主要工作是在做 Harness真正的智能来自背后的大模型。2.2 CLI 工具为什么重新火起来这两年 CLI 类 AI 编程工具扎堆出现从早期的各种 code 助手到现在的 codex cli、zcode cli、trae cli本质上是大家在重新发现命令行的价值。图形界面看着友好但在真实开发流里开发者 80% 的时间在终端里切来切去反而低效。CLI 工具的核心优势有三个。第一是可组合它能和 git、grep、make 这些老牌工具串起来用一条管道解决复杂任务。第二是可脚本化你可以把常用操作写成 shell 函数一键触发。第三是上下文天然丰富CLI 工具能直接读到当前目录、git 状态、环境变量不需要你手动粘贴一堆信息。我自己的日常是这样的在项目根目录敲一个命令让 Agent 读一遍最近的 git diff然后自动生成 commit message 并提交。整个过程三秒比手动写快十倍而且格式统一。这种小到不值得写脚本、但又天天要做的任务正是 CLI Agent 的最佳战场。2.3 从单点工具到工作流编排单个 CLI 工具能解决的问题有限真正的效率提升来自把多个 Agent 串成工作流。比如一个典型的代码审查流程第一个 Agent 读 PR diff 找出潜在 bug第二个 Agent 检查是否符合团队规范第三个 Agent 生成审查意见草稿。三个 Agent 各司其职通过网关统一调用模型日志统一记录。这里就体现出网关和 Agent 的协同价值了。Agent 是干活的手网关是管账的管家。没有网关Agent 调用模型就是一笔糊涂账没有 Agent网关只是个被动的转发器。两者结合才能既提效又可控。3. 大模型网关的实操搭建过程3.1 环境准备与依赖选型先说技术栈。我推荐Python FastAPI作为网关主体理由是异步性能好、生态成熟、团队上手快。如果你团队是 Node 背景Express 或 Fastify 也完全够用。数据库用 PostgreSQL 存日志和配置Redis 做配额计数和缓存。部署用 Docker Compose 起步规模上来再上 K8s。依赖清单大致如下# 核心依赖 fastapi0.110.0 uvicorn[standard]0.27.0 httpx0.27.0 # 异步 HTTP 客户端用于转发请求 redis5.0.1 sqlalchemy2.0.25 psycopg2-binary2.9.9 pydantic2.6.0选 httpx 而不是 requests是因为网关要处理高并发转发异步客户端能显著降低资源占用。实测下来同样的机器配置httpx 异步方案能扛的并发是 requests 同步方案的三到四倍。3.2 核心转发逻辑的实现网关最核心的一段代码就是接收请求、鉴权、选上游、转发、记录。下面是我实际用的简化版逻辑去掉了业务定制部分from fastapi import FastAPI, Request, HTTPException import httpx, time, json app FastAPI() client httpx.AsyncClient(timeout60.0) UPSTREAMS { gpt-4: {url: https://api.example-a.com/v1/chat/completions, key: sk-a-xxx, price_in: 0.03, price_out: 0.06}, claude-3: {url: https://api.example-b.com/v1/messages, key: sk-b-xxx, price_in: 0.015, price_out: 0.075}, } app.post(/v1/chat/completions) async def proxy(req: Request): body await req.json() model body.get(model) upstream UPSTREAMS.get(model) if not upstream: raise HTTPException(400, funknown model: {model}) # 鉴权校验内部 Key internal_key req.headers.get(authorization, ).replace(Bearer , ) if not await check_key(internal_key): raise HTTPException(401, invalid key) # 配额检查 if not await check_quota(internal_key, model): raise HTTPException(429, quota exceeded) start time.time() resp await client.post( upstream[url], headers{Authorization: fBearer {upstream[key]}}, jsonbody, ) latency time.time() - start result resp.json() usage result.get(usage, {}) cost usage.get(prompt_tokens, 0) * upstream[price_in] / 1000 \ usage.get(completion_tokens, 0) * upstream[price_out] / 1000 await log_request(internal_key, model, usage, cost, latency) return result这段代码看着简单但有几个细节值得说。超时设置我给了 60 秒因为大模型生成长文本确实慢设太短会误杀正常请求。价格计算按千 Token 计价注意输入输出分开算很多新手会漏掉这一点导致账单对不上。日志写入建议异步不要阻塞主请求链路否则高并发时日志会成为瓶颈。3.3 配额与限流的实现细节配额这块我踩过坑。最初用 Redis 的INCR做简单计数结果发现两个问题一是跨天重置需要额外的定时任务二是并发场景下计数会有微小误差。后来改成用 Redis 的滑动窗口方案配合 Lua 脚本保证原子性。-- 滑动窗口限流 Lua 脚本 local key KEYS[1] local limit tonumber(ARGV[1]) local window tonumber(ARGV[2]) local now tonumber(ARGV[3]) redis.call(ZREMRANGEBYSCORE, key, 0, now - window) local count redis.call(ZCARD, key) if count limit then redis.call(ZADD, key, now, now .. - .. math.random()) redis.call(EXPIRE, key, window) return 1 else return 0 end这个脚本的好处是精确到毫秒级窗口不会出现整点重置时瞬间涌入大量请求的问题。配额维度我建议至少分三层全局总额度、部门额度、个人 Key 额度。任何一层超了都拒绝这样既能防单点滥用也能防整体超支。注意限流阈值不要设得太死。我见过有团队把个人额度设成每天 100 次结果开发同学调试一个功能就用完了反而逼着他们去申请更多 Key适得其反。建议初期宽松观察一周真实用量后再收紧。3.4 日志与审计的落地日志表结构我建议至少包含这些字段请求 ID、内部 Key、模型名、输入 Token、输出 Token、费用、延迟、状态码、时间戳、Prompt 摘要。Prompt 全文要不要存我的建议是存摘要不存全文摘要用前 200 字符加哈希值既能追溯又不至于把敏感内容全落库。如果合规要求必须存全文那一定要加密存储并且访问日志本身也要审计——谁在什么时候查了哪条记录。我见过一个案例内部员工利用日志查询权限把别人的 Prompt 内容导出来这属于典型的审计系统本身没被审计。4. 自动化编程 Agent 的实操与避坑4.1 CLI 工具的安装与常见报错热词里出现了不少安装报错比如missing optional dependency openai/codex-win32-x64、npm:无法加载文件、internetopenurl() failed。这些我基本都遇到过逐个说下排查思路。missing optional dependency这类错误九成是 npm 的可选依赖机制在特定平台没装全。解决办法是先卸载再重装并且指定平台npm uninstall -g openai/codex npm install -g openai/codexlatest --includeoptional如果还不行检查 npm 版本老版本 npm 对 optional dependencies 的处理有 bug升级到 10.x 以上基本能解决。npm:无法加载文件这种通常是 PowerShell 的执行策略问题。Windows 上默认不允许运行脚本需要改策略Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned改完重开终端即可。这个坑我踩过两次第一次折腾了半小时才反应过来是策略问题。internetopenurl() failed一般是网络层的问题可能是代理配置、DNS 解析或证书问题。先确认基础网络通不通再检查环境变量里有没有残留的代理设置。4.2 Agent 怎么扛并发ai agent 怎么扛并发是个好问题因为 Agent 和普通 API 不一样它一次任务可能调用模型十几次每次都有延迟。如果一百个用户同时触发 Agent后端瞬间就是上千个模型调用。我的经验是三层削峰。第一层是任务队列用户请求先进队列Agent 从队列里取任务执行避免瞬时打满。第二层是并发上限每个 Agent 实例限制同时处理的任务数超出的排队。第三层是模型调用池对同一个上游模型的并发调用做统一限流防止把厂商接口打挂。具体参数上我一般这样配单 Agent 实例并发 5 到 10 个任务模型调用池按上游配额设上限队列长度设成并发数的 10 倍。这样即使突发流量也能平滑处理不会雪崩。4.3 Agent 安全不能只靠提示词agent安全这个词最近被讨论得很多。很多人以为在 System Prompt 里写一句不要执行危险操作就够了这是自欺欺人。Agent 能调用工具就意味着它能真实地改文件、发请求、执行命令提示词层面的约束很容易被绕过。我的做法是在工具层做硬约束。比如文件写入工具限制只能写项目目录内的文件路径里出现..直接拒绝。命令执行工具维护一个白名单只允许跑git、npm、pytest这类安全命令rm、curl这种一律禁止。网络请求工具限制只能访问白名单域名。这些约束写在代码里不写在提示词里。提示词是建议代码是法律。Agent 再聪明也绕不过代码层的检查。4.4 常见问题速查表问题现象可能原因排查方向Agent 执行中途终止上下文超限或工具报错看日志最后一步检查 Token 用量CLI 命令无响应网络阻塞或进程卡死加超时参数检查网络连通性模型返回乱码编码不一致统一 UTF-8检查响应头配额突然耗尽有循环调用或重试风暴查日志调用频次加退避策略网关转发 502上游不可达或超时检查上游健康加故障转移Agent 重复执行同一操作状态未持久化引入任务状态存储做幂等这张表是我从实际故障里总结的每一条都对应过至少一次真实事故。建议打印出来贴在工位上出问题时先对照排查能省不少时间。5. 网关与 Agent 的协同架构5.1 整体架构设计把网关和 Agent 放在一起看一个完整的企业 AI 基础设施应该是这样的分层最上层是业务应用IDE 插件、聊天工具、自动化脚本中间是 Agent 编排层负责任务规划、工具调用、状态管理下面是网关层负责鉴权、路由、计量最底层是模型厂商。这个分层的好处是职责清晰。业务侧只管提需求Agent 侧只管干活网关侧只管治理模型侧只管推理。任何一层要换实现其他层不受影响。比如你想从 A 厂商换到 B 厂商只改网关配置想换个 Agent 框架只改编排层。5.2 数据流与可观测性数据流是这样的业务请求带着内部 Key 到网关网关鉴权后转发给 Agent 服务Agent 调用模型时再经过网关用服务账号的 Key网关记录每一次模型调用。这样一条完整的链路从用户点击到模型响应每一跳都有日志。可观测性上我建议至少监控四个指标请求量、延迟 P95、错误率、Token 消耗。前三个是健康度指标第四个是成本指标。任何一个异常波动都要能告警。我当时的做法是用 Prometheus 采集Grafana 展示阈值告警推到企业 IM。5.3 成本优化的几个实操技巧成本这块能省的地方比想象中多。第一缓存高频请求。很多 Agent 任务里系统提示词是固定的这部分可以缓存不用每次都传。第二用小模型做预处理。比如判断一个任务该走哪个流程用便宜的小模型就够了没必要上最贵的。第三压缩上下文。Agent 的历史对话不要全量传做摘要或截断能省大量输入 Token。我实测过一个案例一个代码审查 Agent优化前每次调用平均消耗 8000 输入 Token优化后压到 3000成本直接降了六成效果几乎没差别。关键就是把重复的系统提示词缓存了历史对话做了摘要。6. 落地过程中的经验与教训6.1 先跑通再优化我见过太多团队在设计完美架构上耗掉几个月结果一行生产代码没上线。正确的做法是先用最土的办法跑通闭环一个简单的转发服务、一个硬编码的 Key 列表、一个 CSV 记日志。跑起来之后真实问题会自己冒出来你才知道该优化什么。我自己的第一个网关版本只有 200 行代码没有数据库配额存在内存里重启就丢。但它让我在一周内摸清了团队的真实使用模式后面所有的优化都是有的放矢。6.2 文档和培训比技术更重要网关上线后最大的阻力不是技术是人的习惯。开发者习惯了直接拿 Key 调厂商你让他改成走网关他会觉得麻烦。这时候光有技术方案没用得配上清晰的文档和一次简短的培训。我的做法是写一份三分钟接入指南只讲怎么改 base_url 和 Key其他一概不提。再录一个两分钟的视频演示从申请 Key 到跑通第一个请求的全过程。文档越短看的人越多。6.3 安全是持续过程不是一次性任务最后说个容易被忽视的点安全不是上线时检查一遍就完事。新的攻击手法、新的模型能力、新的业务场景都会带来新的风险。我建议每季度做一次安全复盘检查 Key 轮换、权限收敛、日志审计这些机制是否还在正常运转。我踩过的一个坑是上线时配了 Key 自动轮换但半年后有人改了配置把轮换关了没人发现。直到一次安全扫描才暴露出来。所以关键机制要有监控不能只靠配置。这套东西我从零搭到稳定运行前后花了大概四个月中间返工过两次。如果让我重来一遍我会把网关和 Agent 分开推进先让网关稳定跑一个月再上 Agent避免两个新系统同时出问题、互相甩锅。这个顺序上的经验比任何技术细节都值钱。
解法与面试要点)
