大模型网关与自动化编程工作流落地实践

1. 大模型网关到底解决什么问题

1.1 从一个真实痛点说起

去年下半年，我所在的团队同时接入了四家模型供应商的API——一家做通用对话，一家做代码补全，一家做文档理解，还有一家专门跑Embedding。刚开始大家各写各的调用代码，前端组用Node.js直接fetch，后端组用Java写了一套HTTP客户端，数据组在Python脚本里硬编码了API Key。三个月后问题集中爆发：某家供应商突然调整了计费接口的返回格式，三个团队各自排查了一整天；某次安全审计发现两个API Key被硬编码在测试脚本里提交到了代码仓库；更离谱的是，同一个业务场景在不同端的超时设置不一样，导致用户侧看到的结果时而完整时而截断。

这些问题的根源不在于模型本身，而在于调用模型的方式太分散了。每个团队、每个项目、每种语言都在用自己的方式直连模型API，没有统一的入口、统一的鉴权、统一的监控、统一的降级策略。大模型网关（LLM Gateway）就是在这个背景下进入我们视野的。

简单说，大模型网关是介于业务应用和模型服务之间的中间层。所有对模型的请求先打到网关，由网关完成鉴权、路由、限流、缓存、日志、计费统计等一揽子事情，业务侧只需要面对一个统一的接口。你可以把它理解成公司前台——不管来的是快递、访客还是面试者，都先到前台登记，前台根据类型分流到不同部门，同时记录谁来了、什么时候来的、待了多久。

1.2 网关的核心能力拆解

一个能落地的大模型网关，至少要具备以下几项能力，我按优先级从高到低排列：

统一接入层是最基础的。不管底层接了几家供应商、几种模型，对外暴露的接口格式必须一致。我们内部采用的是兼容OpenAI Chat Completions的格式，原因是生态最成熟，大部分客户端SDK不用改代码就能对接。请求进来后，网关根据模型名称路由到对应的供应商适配器，适配器负责把统一格式转换成各家自己的格式，再把响应转回来。

密钥管理与鉴权是安全底线。所有供应商的API Key只存在网关的配置中心里，业务侧拿到的是网关自己签发的Token。Token可以设置有效期、绑定业务线、限制可调用的模型范围。这样一来，某个业务的Token泄露了，影响面可控，直接吊销重新签发就行，不用去动供应商那边的Key。

限流与配额直接关系到成本控制。我们按业务线、按模型、按时间窗口三个维度做限流。比如A业务线每分钟最多调200次GPT-4级别的模型，B业务线每天最多消耗50万Token。超过阈值直接返回429，同时触发告警。这个策略帮我们避免过一次事故——某个定时任务写错了循环条件，十分钟内发起了上万次请求，限流直接把它挡住了。

可观测性是排查问题的眼睛。每次请求的耗时、Token消耗、状态码、命中的供应商、是否走了缓存，全部打成结构化日志。配合链路追踪，一个用户请求经过了哪些服务、在网关层花了多少时间、在模型侧花了多少时间，一目了然。我们用的是OpenTelemetry标准，日志进Elasticsearch，指标进Prometheus，看板用Grafana。

缓存与降级是提升体验和可用性的关键。对于相同或高度相似的请求，网关可以返回缓存结果，省Token也省时间。当某个供应商出现故障时，网关自动切换到备用供应商，业务侧无感知。这里有个细节：缓存Key的生成策略很讲究，不能简单用Prompt的MD5，因为同样的Prompt在不同温度参数下结果不同。我们的做法是把模型名、温度、Top_P、Prompt文本拼在一起做哈希。

1.3 为什么不是直接用一个开源方案

市面上确实有一些开源的大模型网关项目，我们评估过几个，最终选择自研。原因有三：第一，我们的业务场景比较特殊，需要在网关层做Prompt模板管理和敏感词过滤，开源方案要么不支持要么改起来很别扭；第二，我们的部署环境有信创要求，某些开源项目的依赖树太深，过不了安全扫描；第三，自研的代码量其实不大，核心逻辑大概两千行左右，维护成本可控。

当然，如果你的团队规模不大、需求比较标准，直接用开源方案是更明智的选择。自研的前提是你确实有定制化需求，并且有人力长期维护。

2. 自动化编程与Agent工作流的结合点

2.1 Agent不是万能药，先搞清楚它适合什么

Agent这个词今年被炒得很热，但我在实际项目中看到太多“为了Agent而Agent”的案例。一个简单的表单填写流程，非要用Agent来做，结果引入了不确定性，反而更难维护。我的判断标准很简单：如果这个任务的步骤是固定的、可枚举的，那就用传统工作流；如果步骤需要根据中间结果动态决定，才考虑Agent。

举个例子，简历筛选这个场景。如果筛选规则是“学历本科以上、工作年限三年以上、有Java经验”，那这就是一个确定性的过滤流程，用传统工作流引擎（比如Dify的工作流或者Coze的工作流）拖几个节点就搞定了，稳定可靠。但如果筛选规则是“判断这个候选人是否适合我们的技术团队文化”，这就需要Agent去理解简历中的项目描述、技术栈演进、团队协作经历，做出综合判断，这种场景才适合Agent。

Agent的核心能力是在不确定环境中做决策。它通过LLM的推理能力，结合可调用的工具（搜索、计算、数据库查询等），一步步逼近目标。但代价是每次决策都可能出错，而且出错后很难复现和调试。所以我的经验是：能用工作流解决的，不要用Agent；必须用Agent的，要把决策空间尽量收窄。

2.2 工作流编码：把Agent的行为约束在轨道上

“工作流编码”这个词听起来有点绕，其实意思就是用代码来定义和管理工作流，而不是在可视化界面里拖拽。可视化拖拽适合快速原型验证，但一旦流程复杂到几十个节点、需要版本控制、需要多人协作，拖拽界面就力不从心了。

我们现在的做法是：用YAML或JSON定义工作流的结构，包括节点类型、节点之间的依赖关系、每个节点的输入输出映射、异常处理策略。然后写一个执行引擎来解析这个定义并驱动流程。这样做的好处是工作流定义可以进Git仓库，可以Code Review，可以回滚到任意历史版本。

举个具体的例子。我们有一个“代码审查助手”的工作流，大致流程是：接收GitLab的Merge Request事件 → 拉取变更的代码文件 → 对每个文件调用LLM做审查 → 汇总审查意见 → 在MR下发表评论。用YAML定义大概长这样：

name: code-review-assistant trigger: type: gitlab_webhook event: merge_request steps: - id: fetch_diff type: gitlab_api action: get_merge_request_changes params: project_id: "{{ trigger.project_id }}" mr_iid: "{{ trigger.mr_iid }}" - id: review_files type: llm_batch foreach: "{{ fetch_diff.changes }}" prompt_template: prompts/code_review.md model: gpt-4 max_tokens: 2000 - id: post_comment type: gitlab_api action: create_merge_request_note params: body: "{{ review_files.summary }}"

这个YAML文件进仓库，谁改了哪一行、为什么改，都有记录。执行引擎负责解析foreach、处理{{ }}模板变量、管理重试和超时。相比在Coze或Dify里拖节点，这种方式对工程师更友好，也更容易做自动化测试。

2.3 CLI工具在自动化编程中的角色

CLI（命令行工具）在自动化编程里被低估了。很多人觉得CLI是“老古董”，但实际上，CLI是连接各种系统的万能胶水。GitLab有CLI，Docker有CLI，Kubernetes有CLI，几乎所有的开发工具都提供CLI。把这些CLI组合起来，就能快速搭建自动化流程，而且比调API更简单——不用处理OAuth回调、不用管理Token刷新，CLI工具通常已经帮你封装好了。

我们内部有一个“项目初始化”的自动化流程，用Shell脚本把几个CLI串起来：先用gitlab cli创建远程仓库，然后用cookiecutter生成项目骨架，接着用docker cli构建基础镜像，最后用kubectl部署到开发环境。整个流程跑下来不到两分钟，新人入职第一天就能自己搞定环境搭建。

当然，CLI方案也有局限。它的错误处理比较粗糙，输出格式不一定是结构化的，跨平台兼容性也需要考虑。所以我的建议是：原型阶段和内部工具用CLI快速搞定，生产环境的核心链路还是走API。

3. 从零搭建一个轻量级大模型网关

3.1 技术选型与架构设计

我们最终选用的技术栈是：Go语言做网关核心，Redis做缓存和限流计数器，PostgreSQL存配置和日志，Nginx做最前面的反向代理和TLS终止。选Go的原因很简单——高并发场景下性能好，部署简单（一个二进制文件扔上去就能跑），而且团队里有人熟悉。

架构上分四层：

接入层由Nginx负责，处理TLS、静态资源、基本的IP限流。这一层不涉及业务逻辑，配置简单，出问题也容易排查。

网关核心层是Go写的服务，负责鉴权、路由、请求转换、响应转换、缓存读写、限流判断。这一层是无状态的，可以水平扩展。我们目前跑了三个实例，前面用Nginx做负载均衡。

适配器层是网关核心的一部分，但逻辑上独立。每个供应商一个适配器，实现统一的接口。适配器的职责是把内部统一格式转换成供应商格式，以及把供应商响应转回统一格式。新增一个供应商只需要写一个适配器，不影响其他部分。

存储层包括Redis和PostgreSQL。Redis存缓存结果和限流计数器，PostgreSQL存配置数据（供应商信息、模型映射、业务线配额）和请求日志。日志量大的话，PostgreSQL只存最近七天的热数据，更早的归档到对象存储。

3.2 核心代码实现要点

先看鉴权部分。业务侧请求网关时，在Header里带一个Authorization: Bearer <token>。网关收到后，先查Redis看这个Token是否有效。Token的格式是JWT，里面包含了业务线ID和可调用的模型列表。验证签名通过后，解析出业务线ID，用于后续的限流和计费。

func AuthMiddleware(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { token := extractToken(r) claims, err := verifyJWT(token) if err != nil { http.Error(w, "unauthorized", http.StatusUnauthorized) return } ctx := context.WithValue(r.Context(), "business_id", claims.BusinessID) ctx = context.WithValue(ctx, "allowed_models", claims.AllowedModels) next.ServeHTTP(w, r.WithContext(ctx)) }) }

路由部分的核心是一个映射表，把模型名称映射到适配器。比如gpt-4映射到OpenAI适配器，claude-3-opus映射到Anthropic适配器，qwen-max映射到通义千问适配器。这个映射表存在PostgreSQL里，网关启动时加载到内存，配置变更时通过Redis的Pub/Sub通知所有实例刷新。

type ModelRouter struct { mu sync.RWMutex mappings map[string]Adapter } func (r *ModelRouter) Route(modelName string) (Adapter, error) { r.mu.RLock() defer r.mu.RUnlock() adapter, ok := r.mappings[modelName] if !ok { return nil, fmt.Errorf("model %s not found", modelName) } return adapter, nil }

限流部分用的是滑动窗口算法，基于Redis的Sorted Set实现。每个业务线每个模型一个Key，请求进来时先把当前时间戳作为Score插入Sorted Set，然后移除窗口外的旧记录，最后统计Set的大小。如果超过阈值就拒绝。

func RateLimit(businessID, model string, limit int, window time.Duration) bool { key := fmt.Sprintf("ratelimit:%s:%s", businessID, model) now := time.Now().UnixNano() windowStart := now - int64(window) pipe := redisClient.Pipeline() pipe.ZRemRangeByScore(ctx, key, "0", fmt.Sprintf("%d", windowStart)) pipe.ZAdd(ctx, key, &redis.Z{Score: float64(now), Member: now}) pipe.ZCard(ctx, key) pipe.Expire(ctx, key, window) cmds, _ := pipe.Exec(ctx) count := cmds[2].(*redis.IntCmd).Val() return count <= int64(limit) }

缓存部分要注意Key的设计。我们用的是cache:{model}:{temperature}:{top_p}:{sha256(prompt)}作为Key，Value是完整的响应JSON。TTL默认设一小时，但可以通过请求参数覆盖。对于流式响应，缓存的是完整的拼接结果，下次命中缓存时一次性返回，不再走流式。

3.3 部署与运维实操

部署用的是Docker Compose，三个服务：gateway、redis、postgres。Nginx跑在宿主机上，反代到gateway的端口。配置文件通过环境变量注入，敏感信息（数据库密码、JWT密钥）存在Docker Secret里。

version: '3.8' services: gateway: image: registry.internal/llm-gateway:v1.2.3 ports: - "8080:8080" environment: - REDIS_ADDR=redis:6379 - POSTGRES_DSN=postgres://user:${DB_PASSWORD}@postgres:5432/gateway - JWT_SECRET_FILE=/run/secrets/jwt_secret secrets: - jwt_secret depends_on: - redis - postgres redis: image: redis:7-alpine volumes: - redis_data:/data postgres: image: postgres:16-alpine environment: - POSTGRES_PASSWORD=${DB_PASSWORD} volumes: - pg_data:/var/lib/postgresql/data volumes: redis_data: pg_data: secrets: jwt_secret: file: ./secrets/jwt_secret.txt

监控方面，网关暴露一个/metrics端点，Prometheus定时抓取。关键的指标包括：请求总数（按业务线、模型、状态码分组）、请求延迟的P50/P95/P99、缓存命中率、限流触发次数、各供应商的错误率。Grafana看板上把这些指标可视化，值班同学一眼就能看出有没有异常。

注意：JWT密钥一定要定期轮换，但轮换时不能直接替换，否则已签发的Token全部失效。我们的做法是同时保留新旧两个密钥，验证时先试新的再试旧的，等旧Token全部过期后再移除旧密钥。

4. 自动化编程工作流的落地实践

4.1 简历筛选工作流的完整实现

简历筛选是我们最早落地的工作流之一，需求很明确：HR每天收到大量简历，人工初筛耗时耗力，希望用AI做第一轮过滤。但这里有个坑——不能让AI直接决定“通过”或“淘汰”，因为AI的判断可能有偏差，而且涉及就业公平问题。我们的方案是让AI做“分类”和“摘要”，把简历分成“明显匹配”、“可能匹配”、“明显不匹配”三类，并给出理由，最终决定权还是在HR手里。

工作流的节点设计如下：

节点一：简历解析。输入是PDF或Word格式的简历文件，用Apache Tika提取文本，然后用LLM做结构化解析，输出JSON格式的候选人信息（姓名、学历、工作经历、技能栈、项目经验）。这一步的Prompt要写得非常明确，要求LLM严格按照给定的JSON Schema输出，不能自由发挥。

节点二：硬性条件过滤。根据职位要求，检查候选人是否满足硬性条件（比如学历、工作年限、特定技能）。这一步用规则引擎做，不用LLM，因为规则是确定的，用LLM反而增加不确定性。

节点三：软性匹配评估。对于通过硬性过滤的候选人，用LLM评估其项目经验与职位要求的匹配度。Prompt里会给出职位描述和候选人的项目经历，要求LLM从技术栈匹配度、项目复杂度、业务领域相关性三个维度打分，并给出简短理由。

节点四：结果汇总与通知。把评估结果写入数据库，同时通过企业微信机器人通知HR。通知消息里包含候选人姓名、分类结果、匹配度分数、AI给出的理由摘要，以及简历原文的链接。

整个工作流用我们前面提到的YAML定义，执行引擎负责调度。实测下来，一份简历从上传到出结果平均耗时8秒，HR的初筛效率提升了大概四倍。

4.2 代码审查助手的工作流设计

代码审查是另一个高频场景。我们的目标是：在MR创建时自动触发审查，对变更的代码文件给出审查意见，包括潜在的Bug、代码风格问题、安全漏洞、性能隐患。

这个工作流比简历筛选复杂，因为代码审查需要理解上下文。一个函数改了，可能影响到调用它的其他地方。我们的做法是：不仅把变更的代码发给LLM，还把变更文件的完整内容、相关的测试文件、以及最近三次的提交记录一起发给LLM，让它有足够的上下文做判断。

Prompt的设计是关键。我们用的是“角色扮演+检查清单”的方式：让LLM扮演一个资深工程师，按照给定的检查清单逐项审查。检查清单包括：变量命名是否清晰、是否有未处理的错误、是否有硬编码的敏感信息、是否有性能问题（比如循环内查数据库）、是否有并发安全问题。每一项要求LLM给出“通过”或“有问题”的判断，有问题的话要指出具体行号和修改建议。

REVIEW_PROMPT = """ 你是一个资深的后端工程师，正在审查一个Merge Request的代码变更。 ## 变更文件 {changed_files} ## 相关上下文 {context_files} ## 检查清单 1. 变量和函数命名是否清晰、符合规范？ 2. 是否有未处理的异常或错误？ 3. 是否有硬编码的密钥、密码、Token？ 4. 是否有性能问题（如循环内IO、N+1查询）？ 5. 是否有并发安全问题？ 6. 是否有明显的逻辑错误？ 请逐项检查，对每一项给出结论。如果有问题，指出文件名、行号和修改建议。 输出格式为JSON，包含一个issues数组，每个issue有file、line、severity、description、suggestion字段。 """

实测下来，这个工作流能发现大约60%的明显问题，剩下的40%需要人工审查。但它的价值在于把人工审查的注意力集中在真正复杂的问题上，而不是浪费在拼写错误和格式问题上。

4.3 工作流编码的版本管理与协作

工作流定义进Git仓库后，就可以像管理代码一样管理工作流。我们用的是GitLab，每个工作流一个目录，目录下有workflow.yaml（流程定义）、prompts/（Prompt模板）、tests/（测试用例）、README.md（说明文档）。

版本管理的关键是向后兼容。工作流定义变更后，正在执行中的实例不能受影响。我们的做法是：每次变更生成一个新的版本号，执行引擎根据启动时的版本号加载对应的定义。新请求用新版本，老请求继续用老版本直到执行完毕。

协作方面，我们要求每个工作流必须有Owner，Owner负责Review变更、处理告警、定期检查执行日志。变更必须经过Code Review才能合并，Review的重点是：Prompt变更是否会影响输出格式、新增节点是否有异常处理、超时设置是否合理。

提示：Prompt模板的变更要特别小心。我们遇到过一次事故，有人把Prompt里的“输出JSON格式”改成了“输出JSON”，结果LLM有时输出纯JSON，有时输出带Markdown代码块的JSON，导致下游解析失败。所以Prompt变更后一定要跑一遍测试用例。

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

5.1 网关层的典型问题

问题一：流式响应中断。用户反馈在使用流式输出时，偶尔会中途断掉。排查发现是Nginx的proxy_read_timeout默认60秒，而有些长回答超过60秒。改成300秒后问题消失。但要注意，超时时间不能设太大，否则连接池会被占满。我们的做法是：网关层设置300秒超时，同时在网关内部对单个请求设置240秒的处理上限，留60秒缓冲。

问题二：Token计数不准。计费统计发现网关记录的Token数和供应商账单对不上。原因是不同供应商的Token计算方式不同，OpenAI按BPE分词，Anthropic有自己的分词器。我们的解决方案是：网关只记录请求和响应的字符数，Token数由各适配器根据自己的分词器计算，并在响应中返回。这样虽然不能做到100%准确，但误差在可接受范围内。

问题三：缓存穿透。某些请求的Prompt非常长，做哈希计算耗时明显。优化方案是用Prompt的前256个字符加上长度作为缓存Key，牺牲一点准确性换取性能。实测下来，碰撞率极低，因为前256个字符通常已经包含了足够的区分信息。

5.2 Agent工作流的典型问题

问题一：Agent陷入循环。这是最常见的问题。Agent在某个步骤反复调用同一个工具，或者在不同步骤之间来回跳转。我们的解决方案是设置最大步数限制（默认10步），超过就强制终止并返回当前结果。同时，在Prompt里明确告诉Agent“如果连续两次得到相同的结果，请尝试不同的方法”。

问题二：工具调用参数错误。Agent调用工具时传入了错误的参数格式。比如要求传JSON但传了字符串，或者必填参数缺失。解决方案是在工具定义里写清楚参数的类型和约束，同时在Agent的Prompt里给出正确的调用示例。另外，工具本身要做好参数校验，返回明确的错误信息，帮助Agent自我纠正。

问题三：上下文超长。这是Dify工作流用户经常遇到的问题。当对话历史很长时，上下文会超出模型的Token限制。解决方案有几种：一是做上下文压缩，用LLM把历史对话总结成简短摘要；二是做滑动窗口，只保留最近N轮对话；三是做相关性过滤，只保留与当前问题相关的历史片段。我们用的是滑动窗口加摘要的组合方案。

问题四：Agent执行终止报错。错误信息是“agent execution terminated due to error”。这种报错通常比较模糊，需要看详细日志。常见原因包括：工具调用超时、LLM返回了无法解析的格式、网络抖动导致请求失败。我们的做法是在每个节点加详细的日志，记录输入、输出、耗时、错误信息。排查时先看是哪个节点失败，再看该节点的输入输出是什么。

5.3 排查技巧速查表

5.4 几个踩过的坑

坑一：不要用LLM做确定性判断。我们曾经让LLM判断“这个请求是否应该被限流”，结果LLM有时会“通融”一下，导致限流策略形同虚设。后来改成纯规则引擎，LLM只负责生成限流提示文案。

坑二：Prompt里的示例要定期更新。我们有一个Prompt里包含了“输出格式示例”，后来输出格式改了，但示例没更新，导致LLM按旧格式输出。现在我们把示例也纳入版本管理，改格式必须同时改示例。

坑三：不要忽视冷启动。网关刚启动时，缓存是空的，所有请求都会打到模型侧，可能导致瞬间流量过大。我们的做法是：网关启动后先预热，把高频请求的缓存加载进来，再开始接收流量。

坑四：日志要脱敏。请求日志里可能包含用户的敏感信息，比如简历里的手机号、代码里的密钥。我们在日志写入前做脱敏处理，手机号中间四位打码，密钥类字段直接替换成***。

6. 一些个人体会

这套网关加工作流的组合，我们跑了大概半年，中间经历过几次大促级别的流量高峰，整体稳定性还可以。如果让我重新做一遍，有几个地方我会调整。

第一，网关的配置管理应该更早引入配置中心。我们一开始用环境变量，后来配置项多了，改一个参数要重启服务，很麻烦。后来迁移到Apollo，支持热更新，体验好很多。

第二，工作流的测试要更早做。我们一开始靠人工测试，后来发现有些边界情况根本测不到。现在每个工作流都有单元测试和集成测试，用Mock的LLM响应来验证流程逻辑。

第三，不要追求大而全的Agent框架。我们试过几个开源的Agent框架，功能很全但太重了，学习成本高，定制也麻烦。最后自己写了一个轻量级的执行引擎，核心代码不到一千行，反而更可控。

第四，CLI工具在内部工具链里的价值被低估了。我们后来用CLI串了一个“一键部署”的脚本，把构建、测试、部署、通知全部串起来，开发同学的自助率明显提升。

最后分享一个小技巧：网关的限流阈值不要设得太紧。我们一开始设得很紧，结果正常业务偶尔也会被限流，用户体验很差。后来改成“软限流”——超过阈值先告警但不拒绝，观察一段时间后再决定是否硬限流。这样既能发现异常，又不会误伤正常业务。