企业内部AI应用做到一定规模，最先失控的往往不是模型效果，而是接入方式。每个项目组各自去找模型服务商开账号，Key直接写在代码仓库里，谁也说不清一共开了多少Key、每月烧了多少Token、某个接口到底是哪个系统在调。我们当时为了避免这种混乱继续扩大，决定在业务系统和模型服务之间加一层统一的AI能力中台，最终选型用了Taotoken。这篇文章把从为什么搭、怎么设计、到落地运营的要点都梳理一遍，适合正在做AI平台化的团队，也适合那些已经有一堆散装AI接口、想统一治理的公司。

1. 为什么企业内部需要一个AI能力中台

1.1 没有中台时的混乱现状

先说一个最常见的画面。公司里只要有三五个系统接入过大模型，基本就会出现三种典型问题。

第一种是Key散落。业务开发图省事，把模型服务商的Key直接写在应用配置里或者环境变量里，员工离职之后也没人清理。更麻烦的是，团队之间为了省事会共用同一个平台账号，一旦有个内部爬虫任务把账号的日配额跑光，当天所有AI功能一起报错。我们内部就吃过一次亏：凌晨一个数据任务触发批量生成，直接把共享账号的额度打满，早上同事问为什么智能客服不能用，查了半天才发现是配额被半夜的批处理耗完了。

第二种是效果不统一。同样是“生成一段商品文案”，A系统接入的是擅长中文但成本高的模型，B系统为了省钱接入的是另一个模型，两个系统输出的风格、稳定性完全不一样。业务方感知不到底层模型差异，只会觉得“这个功能好用，那个功能不好用”，最后问题都会被踢回给技术团队。

第三种是无审计。所有请求都是业务系统直连模型服务商，没有统一的日志和监控。一旦出现Prompt注入、越权访问或者内部敏感数据被带出，想追溯是哪个用户、哪个应用、哪个时间段发起的请求都无从下手。出了问题只能靠猜，这种状态在业务量小的时候还能忍，一旦AI能力扩散到几十个系统，就是定时炸弹。

1.2 中台到底要解决哪几件事

我们讨论了很久，最终把AI能力中台的目标收敛为六件事。这也成了后续做技术选型和方案设计的基准线。

• 统一接入：把各家模型的接口标准化成一个内部API协议，业务侧不感知底层是哪家服务商，只关心模型别名和返回结果。
• 统一鉴权与审计：每个请求都能明确知道是谁、哪个应用、用了哪个模型、消耗了多少Token，做到全链路留痕。
• 统一配额与成本：按租户、应用维度做并发和Token用量限制，用量可以拆账到部门，财务不再是一笔糊涂账。
• 统一路由与容灾：优先模型不可用或限流时，自动把流量切换到备用模型，业务无感。
• 统一安全策略：对进出模型服务的文本做脱敏和合规检查，敏感请求只放行给经过授权的内部模型。
• 统一能力沉淀：把Prompt模板、工具调用、Agent编排这类公共能力做成中台组件，而不是让每个业务团队重复造轮子。

这六件事不是并列的优先级关系，前四件是基础，后两件是加分项。实际落地时，我建议先把前四件做实，再逐步叠加安全策略和能力沉淀。

1.3 选型时我为什么倾向Taotoken

聊方案的时候，团队里大致有三条路线。

一是自研网关。好处是完全可控，想怎么改都行。但坏处也明显：要有人持续维护认证、限流、配额、审计这一整套东西，而且很容易做成只转发不治理的半成品。很多自研网关最后就是一层反向代理，Token统计还是靠手工对账单。

二是直接用云厂商出的聚合网关。这类产品开箱即用，但私有数据要经过第三方链路，内部私有化模型也纳管不进去，对不少企业来说是过不去的红线。

三是选一个能私有化部署的中间件平台，在上面做定制。我们最终倾向的是Taotoken，核心原因是它把企业最在意的治理能力内置了，而不是让我从零开始造轮子。

选型还有一个隐性因素：团队能不能快速上手。Taotoken的控制台和配置模型比较直观，运维人员半天就能看懂，不用专门招一个网关专家。这个因素在后期推广时非常重要，因为中台日常运营大概率还是交由现有运维团队负责。

2. 用Taotoken搭建中台的架构思路

2.1 接入层、编排层、能力层怎么分工

Taotoken在逻辑上并不复杂，核心是三层加一个横向治理平面。

接入层面向业务系统，提供统一的API入口和标准的请求头约定。业务侧只需要知道网关的域名，不需要关心背后有几个模型服务商、用的是什么网络链路。

编排层是中台的头脑，负责四件事：第一，解析请求里的身份凭证，确认租户和应用是否合法；第二，做流控判断，看当前配额够不够、并发有没有超限；第三，做路由选择，根据策略决定把请求转到哪个模型；第四，做动作审计，把调用信息写入日志和计量系统。

能力层放各类模型供应商的适配器，以及企业内部私有化部署的模型服务。Taotoken通过插件机制屏蔽各个供应商的差异。以后要新增一个模型服务商，只需要写一个适配器并注册进去，不需要改动上层逻辑。

横向治理平面则包括控制台、监控指标、日志检索和预算告警。这一层不直接参与请求处理，但它决定了中台能不能长期运营下去。

这套分层设计的核心价值是解耦。业务侧和模型服务商完全隔离，前端的路由策略调整不会影响业务代码，后端的模型换新也不会让业务侧感知到变更。

2.2 统一模型接入与路由策略

统一模型接入的第一步是在Taotoken中定义模型供应商。以接入一个内部模型服务为例，配置大致长这样：

providers: - name: llm-platform-internal type: openai-compatible base_url: http://model-internal.example:8000/v1 auth: api_key_env: TAOTOKEN_MODEL_INTERNAL_KEY timeout_ms: 15000 models: - name: chat-smart upstream_model: llm-chat-smart-v2 context_window: 32768 max_output_tokens: 4096

这里的name是Taotoken内部的模型别名，upstream_model才是模型服务商认识的真实模型名。auth字段不直接存Key，而是指向环境变量，避免敏感信息落到配置文件里。

配置完供应商后，再定义路由策略。路由是Taotoken比较有价值的设计，业务调用时只使用模型别名，由路由层决定实际落到哪个模型上。

routes: - alias: llm-default strategy: priority candidates: - provider: llm-platform-internal model: chat-smart weight: 80 - provider: llm-platform-backup model: chat-backup weight: 20

为什么一定强调“业务只调用别名”？因为模型迭代太频繁了。今天内部把v2版本升级到v3，业务代码一行都不用改，中台里把upstream_model替换一下，再灰度一段流量就行。反过来，如果业务代码里写死了模型名，每次升级都要协调所有应用方发版本，推广阻力会大得多。

2.3 多租户、API Key与权限模型怎么设计

中台能不能在企业里真正管住，权限模型是关键。我们最终使用的是三层结构：租户对应业务域，应用对应具体系统，调用身份由统一登录平台提供。

租户是最粗粒度的隔离单位，比如销售域、客服域、供应链域各自一个租户。应用则挂在租户下面，是一个具体的系统。API Key绑定在应用上，不绑定个人。这样做的好处是，员工离职不会影响系统间的调用，只需要回收个人身份凭证；而某个应用出了问题，吊销应用Key即可，不用牵连其他系统。

对应的配置结构大致如下：

tenants: - code: ecommerce display_name: 电商业务域 apps: - code: sales-assistant models: [llm-default] quota: daily_tokens: 5000000 max_concurrency: 20

业务侧调用时，请求头需要携带应用标识和身份凭证：

Authorization: Bearer tk_live_xxxxxx X-Taotoken-Tenant: ecommerce X-Taotoken-App: sales-assistant

Taotoken网关会先校验API Key，再调用统一登录服务校验用户身份，最后按租户配额做流控。这套模型的要点是最小权限：应用只能用分配给它的模型别名，不能用通配符访问所有模型，更不能透传原始模型服务商的账号。

3. 实操：从零跑通一套最小可用中台

3.1 落地前的容量估算和资源准备

动手部署之前建议先做一道粗算题，否则后面很容易被流量打懵。

假设第一阶段要接入30个内部应用，日均调用总量是10万次，高峰集中在上午4小时，且有80%的调用发生在这个时段。那么峰值调用次数是8万次，平均QPS算下来是80000除以14400秒，大约是5.6。为了应付突发流量，再留3倍冗余，目标入口QPS大概是17。

这个数字不算大，网关服务分配8到10个Pod，每个Pod配置500m核和512MiB内存就足够了。

如果完全调用外部模型服务，中台部署本身不太吃资源。但要接入私有化模型，就得单独给推理服务预留GPU资源，那才是大头。仓库里还需要准备PostgreSQL存元数据，Redis做令牌桶和热点缓存。内存规格建议至少4GB以上，后面启用审计检索时会轻松一些。

3.2 部署Taotoken并接入第一个模型

部署过程并不复杂，我习惯按四步走。

第一步，准备数据库实例，执行Taotoken初始化脚本，把元数据表、审计表、配额表建好。第二步，部署控制台和网关模块，环境变量里配好数据库连接、Redis地址、密钥服务地址。第三步，在控制台添加模型供应商，填好base_url和模型名，Key通过环境变量注入。第四步，熬过这一步，点击测试连接，确认鉴权通过，记下当前模型的平均时延。

启动命令大概长这样：

export TAOTOKEN_DB_DSN="postgres://taotoken:change-me@db-host:5432/taotoken" export TAOTOKEN_REDIS_ADDR="redis-host:6379" export TAOTOKEN_MODEL_INTERNAL_KEY="$(cat ${MODEL_KEY_FILE})" ./taotoken-server start --config ./config.yaml

这里有一个非常重要的实操心得：Key不要直接明文写在config.yaml里，也不要让运维手工复制到环境变量。可以用密钥管理服务统一托管，启动时读取一次，进程内部保持引用就行。我们踩过配置库被同步到团队仓库的坑，从那之后一律走密钥托管，配置文件里只放环境变量名。

3.3 配置统一网关并开放标准接口

模型接入完成，接下来就是建租户、建应用、放接口。

在控制台里依次完成四步操作：创建租户ecommerce，创建应用sales-assistant，绑定模型别名llm-default，生成该应用的API Key。然后，业务方就可以用标准接口开始调试了。

curl -X POST 'http://aigateway.internal.company/v1/chat/completions' \ -H 'Authorization: Bearer tk_live_xxxxxxxx' \ -H 'Content-Type: application/json' \ -H 'X-Taotoken-Tenant: ecommerce' \ -H 'X-Taotoken-App: sales-assistant' \ -d '{ "model": "llm-default", "messages": [{"role":"user","content":"给这款新品写三段卖点"}], "temperature": 0.7 }'

Java、Python、Go这些语言接入方式都类似，无非是发一个HTTP请求。比如Python侧：

import requests resp = requests.post( "http://aigateway.internal.company/v1/chat/completions", headers={ "Authorization": "Bearer tk_live_xxxxxxxx", "X-Taotoken-Tenant": "ecommerce", "X-Taotoken-App": "sales-assistant", }, json={ "model": "llm-default", "messages": [{"role": "user", "content": "给这款新品写三段卖点"}], }, ) data = resp.json() print(data["choices"][0]["message"]["content"])

业务侧在这个阶段是无感的，它只知道中台提供了一个和主流模型服务商几乎一致的接口协议。但注意，协议一致不代表可以混用，有些字段必须中台自己控制，例如原始服务商的API Key对业务侧完全不可见。

3.4 灰度切换：先影子模式，再切真实流量

第一次接入新系统时，不要直接改代码把流量切到中台，建议先走影子模式。

所谓影子模式，就是把请求同时发给原链路和中台，但中台只记录日志、不把结果返回给业务。这样能评估路由配置是否正确、时延比原链路高多少、有没有鉴权失败的请求，而业务完全不受影响。

跑两天影子模式后，选择一个低风险应用切真实流量。切的时候重点观察三个指标：成功率、P95时延、Token计费是否正常。观察一两天都没有异常后，再把其他应用逐步切换。全部切换完成别忘了一件事：在模型服务商侧吊销所有业务系统直接持有的旧Key，彻底断掉直连链路。

这一步很多人会忘，结果是中台上线了，旧Key还挂在业务代码里，等于治理白做。

4. 运营治理：成本、审计与模型迭代

4.1 预算分摊与Token配额控制

中台如果只统一入口，不管成本，最后只会从“乱接”变成“统一地乱用”。所以我们把预算控制做进了日常运营里。

给每个租户设置每日Token上限和月度预算，超限时可以配置成直接拒绝或者降级到低成本模型。举例来说，假设模型服务商结算价是30元/百万Token，销售域月均消耗2000万Token，那么月度预算就是30乘以20，等于600元。配额策略可以写成：

quota_policies: - tenant: ecommerce daily_tokens: 10000000 daily_budget_cny: 300 actions: on_limit: block on_budget_warning: notify

到了下旬如果预算快用完了，系统会给租户管理员发告警，由业务负责人决定是追加预算还是收紧用量。这里有个经验：Token配额一开始不要卡得太死，先按历史消耗量的1.5倍给，运行一两个月有了真实基线再收紧。否则业务方一旦被限流就反馈“中台不好用”，后面推广阻力会变大。

4.2 全链路审计与数据安全

审计是中台和普通网关最大的区别。Taotoken默认记录每一次调用的租户、应用、用户身份、模型别名、Token用量、时延和状态码。这些日志要至少保留90天，方便追溯历史问题。

数据安全方面有三条硬规矩。

第一条，日志不做全量Prompt留存。完整Prompt可能包含业务敏感信息，存到日志系统等于二次扩散。默认只保存文本摘要和向量特征，需要追溯时再用特征去匹配。第二条，应用Key定期轮换。手动换容易被遗忘，建议配置自动过期和轮换策略，应急状态下一键吊销。第三条，对外部模型服务的请求默认开启脱敏和内容安全过滤。内部私有化模型和外部服务商的策略可以不同，但原先的“一路裸奔直连”必须禁止。

4.3 模型版本迭代与多环境管理

中台稳定之后，模型升级会变成一个高频动作。建议用环境隔离来管理：开发环境随意换模型，测试环境做对比评测，生产环境通过路由权重做灰度。

例如要把销售域的核心模型从V2升级到V3，先在开发环境把upstream_model改成V3，跑回归测试；再到测试环境用一组固定业务样例对比两个版本的输出质量；确认没问题后，在生产环境的routes配置里把V3的权重从0逐步调到100。如果过程中发现V3在某些场景下效果回退，只需要把权重调回0，一秒完成回滚。

这件事的价值在于，模型升级不再需要协调所有业务方排期，中台自己就能完成。

5. 高频故障排查与避坑实录

5.1 问题速查表

以下是我们运行大半年后整理出来的高频问题，基本覆盖了常见故障。

排查超时问题时有一点容易忽视：中台和后端模型服务之间可能还隔着一个负载均衡层，超时时间要逐层确认。我们之前把中台超时设为10秒，但后端模型服务本身单次生成就要8秒，加上排队压力，10秒经常不够用。建议先通过测试连接摸清正常耗时的P95值，再在这个基础上加一点缓冲。

5.2 反复踩坑后我总结的四个原则

第一个原则，中台不能做成慢路径。早期我们为了统一日志格式，把请求体完整解析了一遍再原样转发，时延比直连高出80毫秒。后来改成只解析必要字段，请求体直接透传，时延才降下来。中台的任务是治理，不是加工，能少碰数据就少碰。

第二个原则，模型Key绝不进业务代码。不管业务方怎么要求，都只能通过中台分配的应用Key调用。谁把原始Key漏到前端，谁就要为数据事故负责。这句话说得重，但真的管用。

第三个原则，先做计量再谈优化。没有Token用量和成本统计，配额就是拍脑袋，优化也没有依据。必须先跑出一个月基线，让每个租户看到自己的消耗曲线，他们才会主动去优化Prompt和缓存策略。

第四个原则，别追求一步到位。中台上线第一版只做转发、鉴权、配额、审计四件事就够了。Prompt模板、Agent编排、知识库检索，这些第三阶段再说。一上来就想把所有AI能力都塞进中台，只会把项目周期拖垮，最后连基础功能都交付不了。

结尾

我个人在推动这套中台落地时最深的体会是：中台能不能建起来，一半靠技术方案，一半靠上下游的信任。业务方愿意接入的前提是接入成本足够低，管理层愿意继续投入的前提是成本和风险真正可见。Taotoken在这个过程里帮我们把“看得见”这件事先解决了，后面的事情才有继续展开的可能。

最后分享一个实用的小技巧：接入第一个业务时，别挑最核心的生产系统，找一个内部效率工具先跑两星期，把Key轮换、配额告警、审计查询这些流程全部用真实流量磨一遍，再横向铺开。中台这种基础组件，稳比快重要。很多问题在第一个接入方身上暴露得越早，后面几十个系统接入的时候就越顺利。