企业大模型网关与Agent工作流落地实践：架构设计与成本优化

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

1.1 从一个真实痛点说起

去年帮一家做企业服务的团队做技术咨询，他们内部有七八个业务线都在调大模型接口，财务系统用一套 Key，客服系统用另一套，市场部的自动化文案工具又是单独申请的。结果月底对账的时候，谁也说不清钱花在哪了，哪个业务线调用量暴涨也查不出来。更麻烦的是，某天某个业务线的 Key 泄露了，被人拿去刷量，一晚上烧掉了几千块，事后追责连日志都对不上。

这不是个例。只要公司里超过三个人在用大模型，就一定会遇到这几个问题：密钥散落各处、调用量无法归集、成本无法分摊、模型切换要改代码、敏感数据裸奔。企业大模型网关就是为了解决这一堆问题而存在的中间层。

你可以把它理解成公司内部的“模型调用总机”。所有业务系统不再直接对接 OpenAI 或者别的模型服务，而是统一打到网关上，由网关负责鉴权、限流、路由、计费、审计、脱敏。业务方拿到的只是一个内部地址和一把内部 Key，背后用哪个模型、走哪条链路，业务方不用关心。

1.2 网关的核心能力拆解

一个能上生产的大模型网关，至少要具备下面这几块能力，缺一块都会在某个阶段卡住你。

这里面最容易被低估的是成本计量。很多团队一开始觉得“先跑起来再说”，结果跑了两个月发现账单对不上，回头补计量逻辑，历史数据全丢了。我的建议是网关第一天上线就要带计量，哪怕先记到文件里，也比事后补强。

1.3 为什么是“网关”而不是“SDK”

有人会问，我封装一个内部 SDK 让业务方引入不就行了？早期确实可以，但 SDK 方案有三个绕不过去的坎。

第一，升级困难。SDK 发版后，十几个业务线要各自升级、各自测试、各自发版，协调成本极高。网关是服务端升级，业务方无感。

第二，语言异构。公司里 Java、Go、Python、Node 都有，你得维护多套 SDK，逻辑还容易不一致。网关是 HTTP 接口，任何语言都能调。

第三，管控能力弱。SDK 跑在业务进程里，限流、熔断、脱敏这些逻辑业务方可以绕过。网关是强制入口，绕不过去。

所以只要团队规模超过一定阈值，网关就是必然选择。这不是技术偏好问题，是管理半径问题。

2. 网关的技术选型与架构设计

2.1 自研还是用开源

这是第一个要拍板的问题。我的经验是：如果团队有 3 个以上后端且有人懂网关类中间件，优先自研轻量版；如果团队小、时间紧，先用开源扛着，但要留好扩展点。

自研的好处是贴合业务，计量口径、脱敏规则这些都能按自己需求来。坏处是要自己处理高并发、流式转发、连接池这些脏活。开源方案像 One-API、New-API 这类，开箱即用，但深度定制时会发现它的数据模型不一定适配你的组织架构。

我一般推荐一个折中路线：核心转发链路自研，管理后台先用现成的。转发链路是整个网关的命脉，必须自己掌控；管理后台是给人看的，用开源省时间。

2.2 转发链路的关键设计

转发链路看起来简单——收到请求、转发出去、把结果流回来——但大模型场景有几个特殊点。

第一是流式响应。大模型返回是 SSE 流，网关必须支持边收边转，不能等全部收完再返回，否则首字延迟会爆炸。实现上要注意关闭缓冲，很多框架默认会缓冲响应体，导致流式变成“假流式”。

第二是超时策略。普通接口超时设 3 秒，大模型动辄几十秒。网关的超时要比模型侧超时略长，同时要有心跳机制，避免中间层把长连接掐断。

第三是重试的坑。大模型请求重试要非常谨慎，因为它是非幂等的——重试一次就多花一次钱，还可能产生重复内容。我的做法是：只对连接失败重试，不对超时重试，且重试次数不超过 1 次。

下面是一个简化的转发核心逻辑，用 Python 示意：

async def forward(request, route): upstream = route.upstream headers = build_headers(request, upstream.api_key) body = rewrite_model(request.body, route.target_model) async with httpx.AsyncClient(timeout=Timeout(connect=5, read=120)) as client: async with client.stream("POST", upstream.url, headers=headers, json=body) as resp: async for chunk in resp.aiter_bytes(): yield chunk # 边收边转，不缓冲

这段代码里aiter_bytes是关键，它保证流式透传。如果你用resp.read()就会把整个响应读进内存，流式就废了。

2.3 路由策略怎么定

路由不是简单的“A 业务走 A 模型”，要考虑几个维度。

按成本路由：简单任务走便宜模型，复杂任务走贵模型。比如意图识别、分类这种，用小模型完全够用，没必要上旗舰模型。

按可用性路由：主模型挂了自动切备用。这里要注意，切换要基于健康检查，不能等业务报错才切。

按合规路由：涉及敏感数据的请求，路由到私有化部署的模型，不出公网。

按灰度路由：新模型上线先放 5% 流量，观察效果再逐步放量。

我见过一个团队把路由规则写死在代码里，结果每次调整都要发版。正确做法是把路由规则做成配置，支持热更新，最好有个简单的规则引擎。

2.4 计量与限流的实现细节

计量要记什么？至少要有：请求时间、业务线标识、用户标识、模型名、输入 token 数、输出 token 数、耗时、是否成功。这些字段缺一个，后面做分析就会卡壳。

token 数怎么算？两种方式：一是调用模型返回的 usage 字段，最准；二是本地用 tokenizer 估算，快但有误差。我的做法是以返回的 usage 为准，本地估算作为兜底，因为流式响应里 usage 可能拿不到。

限流用令牌桶还是滑动窗口？大模型场景我推荐滑动窗口，因为请求耗时差异大，令牌桶的平滑特性反而不符合实际。限流维度要支持多级：全局、业务线、用户三级，任何一级超限都拒绝。

注意：限流拒绝要返回明确的错误码和提示，不要直接 500，否则业务方排查半天以为是模型挂了。

3. 自动化编程与 Agent 工作流落地

3.1 Agent 和普通工作流的区别

很多人把 Agent 和工作流混为一谈，其实两者定位不同。工作流是确定性的编排，Agent 是带决策的自主执行。

工作流适合流程固定的场景，比如“收到简历→解析→打分→入库”，每一步都是确定的，用 Dify、Coze 这类工具拖拽就能搭。Agent 适合需要动态决策的场景，比如“帮我调研一下竞品”，它要自己决定搜什么、看哪些页面、怎么总结。

实际项目里，两者往往是混合的：外层用工作流保证流程可控，内层用 Agent 处理不确定的子任务。这样既有工作流的稳定性，又有 Agent 的灵活性。

3.2 简历筛选工作流的完整拆解

拿简历筛选这个典型场景来说，一个能上生产的流程大概是这样：

1. 简历接入：从邮箱、招聘系统、上传入口收集简历，统一转成文本。PDF 解析是第一个坑，扫描件要过 OCR，排版复杂的要处理分栏。
2. 结构化抽取：用大模型把简历抽成结构化字段——姓名、学历、工作年限、技能栈、项目经历。这里要用 JSON Schema 约束输出，否则模型会自由发挥。
3. 硬性条件过滤：学历、年限这类硬指标用规则过滤，不要交给模型，规则更准更便宜。
4. 软性匹配打分：把 JD 和简历一起给模型，让它按维度打分并给理由。打分要给出评分标准，否则模型每次尺度不一样。
5. 结果汇总：按分数排序，生成候选人列表，附上打分理由供 HR 参考。

这个流程里，第 2 步和第 4 步是模型调用，其他都是确定性逻辑。把模型用在刀刃上，成本和效果都最优。

3.3 工作流编码的几个关键决策

上下文超长怎么办。Dify 这类工具处理长上下文时容易爆，因为工作流会把所有中间结果都塞进上下文。解决办法是分段处理+摘要压缩：长文档先切块，每块单独处理，再把结果摘要后汇总。不要指望模型一次吞下几万字还能保持质量。

失败重试怎么做。工作流里每个节点都可能失败，要有重试和降级。模型调用失败重试 1 次，还失败就走兜底逻辑（比如标记为待人工处理），不要让整个流程卡死。

结果怎么校验。模型输出不可信，尤其是结构化抽取。要用 JSON Schema 校验，校验不过就重试或降级。我见过太多因为模型偶尔输出格式错误导致整个流程崩掉的案例。

3.4 从工作流到代码的转换

有些团队用 Dify 搭好工作流后，想转成 Java 代码集成到自己的系统里。这个转换不是自动的，需要手工重写，但思路可以照搬。

转换时要注意：Dify 里的变量传递、条件分支、循环，在代码里要用对应的数据结构实现。模型调用部分抽成独立的 service，方便替换。整个流程做成状态机，每个节点是一个状态，便于观测和重试。

我一般建议：原型阶段用 Dify 快速验证，生产阶段用代码重写。Dify 适合验证流程可行性，但生产环境的可观测性、错误处理、性能要求，还是代码更靠谱。

4. 实操中的常见问题与排查

4.1 网关层的典型故障

流式响应中断。表现是前端收到一半内容就断了。排查顺序：先看网关日志有没有异常，再看上游连接是否超时，最后看中间有没有代理层缓冲。常见原因是 Nginx 的proxy_buffering没关，或者网关框架默认缓冲了响应。

token 计量对不上。表现是网关统计的 token 和模型账单差很多。原因通常是流式响应拿不到 usage，或者重试请求被重复计量。解决办法是流式场景用本地 tokenizer 估算，重试请求要标记去重。

限流误伤。表现是正常业务被限流。检查限流维度是不是太粗，比如按 IP 限流会把同一出口的多个业务一起限掉。改成按业务线+用户维度。

4.2 Agent 工作流的典型故障

上下文超长导致截断。表现是模型回答不完整或答非所问。排查方法是打印每次调用的实际 token 数，看是不是超了模型上限。解决靠分段和摘要。

工具调用死循环。Agent 反复调用同一个工具出不来。要在 Agent 循环里加最大步数限制，超过就强制结束并返回当前结果。

输出格式不稳定。同样的输入，有时返回 JSON 有时返回自然语言。要用结构化输出约束，或者在 prompt 里给明确的格式示例，再配合校验重试。

4.3 常见问题速查表

4.4 几个踩过的坑

坑一：以为网关只是转发。早期我把网关做得很薄，只做转发，结果计量、限流、脱敏全散在业务侧，最后又花大力气收回来。网关该厚的地方一定要厚。

坑二：忽略流式的特殊性。用普通 HTTP 客户端的思维写流式转发，缓冲、超时、重试全踩一遍。流式要单独设计。

坑三：Agent 没有兜底。Agent 自主决策很美好，但一旦卡住整个流程就挂了。任何 Agent 环节都要有超时和兜底。

坑四：密钥管理随意。上游 Key 直接写在配置文件里，没有轮换机制。正确做法是密钥加密存储，支持热轮换，泄露了能快速失效。

5. 上线后的运维与成本优化

5.1 可观测性怎么建

网关上线后，没有可观测性就是睁眼瞎。至少要建三块：指标、日志、追踪。

指标看调用量、成功率、延迟分布、token 消耗。日志记全量请求的关键字段，用于事后追溯。追踪把一次请求在网关、模型、业务侧的链路串起来，方便定位慢在哪。

我一般用 Prometheus 收指标，用结构化日志落盘，追踪用 OpenTelemetry。这套组合成熟稳定，接入成本也不高。

5.2 成本优化的几个抓手

模型分级。不是所有任务都要用旗舰模型。分类、抽取、改写这类任务，小模型效果差不了多少，成本能降一个数量级。

缓存。相同或相似的请求可以缓存结果。比如 FAQ 类问答，命中缓存直接返回，不调模型。缓存要注意失效策略，模型更新后缓存要清。

Prompt 精简。很多 prompt 写得又臭又长，token 哗哗地烧。定期 review prompt，删掉冗余描述，能省不少。

批处理。能批量调的任务不要一条条调，批处理能显著降低单位成本。

5.3 安全与合规的底线

数据脱敏。请求出网前，把手机号、身份证、银行卡这类敏感信息替换掉，返回后再还原。脱敏规则要可配置，不同业务线规则不同。

审计留痕。谁在什么时候调了什么模型、传了什么内容，都要有记录。这既是合规要求，也是出问题时的自证材料。

权限隔离。不同业务线只能访问自己授权的模型，不能越权。网关要做细粒度的权限控制。

内容安全。输入输出都要过一遍内容安全检测，防止违规内容进出。这块不能省，出事就是大事。

6. 我个人的一些实践体会

做企业大模型网关这两年，最大的体会是：技术难度不在转发，而在治理。转发逻辑一天就能写完，但计量口径、限流维度、脱敏规则、权限模型这些治理层面的东西，才是真正花时间的地方，也是决定网关能不能长期用下去的关键。

另一个体会是不要过度设计。一开始就想着支持十家模型、支持复杂路由、支持各种高级特性，结果半年没上线。正确做法是先支持一家模型、一条链路跑通，把计量和日志做扎实，再逐步扩展。网关是基础设施，稳定比功能多重要得多。

自动化编程这块，我的建议是从确定性高的场景切入。简历筛选、数据录入、报表生成这类流程固定的场景，用工作流能快速见效。Agent 适合探索性任务，但一定要有兜底，不能让它自由发挥到失控。

最后分享一个小技巧：网关的配置一定要支持热更新，且要有版本管理和回滚。我见过因为改错一个路由规则导致全公司模型调用挂掉的案例，有回滚机制的话，30 秒就能恢复。基础设施的每一次变更，都要假设它会出错，提前准备好退路。