去年年底我们团队做了一次内部盘点发现自己手里有大大小小十几个AI应用有接大模型API的有做知识库问答的有跑Agent流程的。结果每个应用都有自己的模型配置、各自的prompt管理方式、单独调的上下文缓存出了线上问题还要分别去查。那段时间我最大的感受就是AI应用的开发方式完全倒退回十年前——没有统一的数据访问层每个模块各写各的数据库连接。这时候我们决定把一层公共能力抽出来给它起了个项目代号叫QuickBlue后来发现这个东西在外面有一个更正式的名字AI应用底座。这篇内容我打算把QuickBlue从定位、核心能力到落地实操和踩坑过程完整拆开讲。它不是某个炫酷的模型也不是一套业务系统而是架在大模型和业务应用之间的一层“基础设施”解决的是模型怎么统一接入、Agent流程怎么编排、上下文和成本怎么治理、权限和审计怎么落地这一系列工程问题。适合正在做AI应用但觉得处处重复造轮子的技术负责人、架构师、AI工程团队也适合那些准备把AI从demo推进到生产环境的团队参考。1. AI应用底座的定位先搞清楚它到底解决什么问题1.1 企业AI落地的“三层困境”模型、应用与数据之间缺了一层先看大多数企业做AI时实际面对的处境。模型层面开源的有Llama、Qwen、DeepSeek闭源的有各家商业API能力参差不齐价格天差地别接口协议也都不一样。应用层面业务方要的是“帮我总结这份合同”“自动回复这个客户”“把这段语音转成工单”每个需求背后都连着一套prompt、一轮tool调用、一份知识库检索。数据层面真正的业务数据停在CRM、ERP、工单系统里模型根本够不着需要一套完整的RAG管道去清洗、切片、向量化、检索。这三个层面之间天然缺了一个中间层。如果每个AI应用都自己去做模型接入、自己管上下文、自己写权限控制就会出现一个很经典的结果项目越多重复代码越多模型一换全线返工成本一涨根本说不清是谁花的钱。QuickBlue这个底座的出发点就一句话把模型、数据、应用三者之间大量重复的横向能力收拢到一层让应用团队专注于自己的业务场景而不是从零开始搭一套“模型SDK私有工具”的组合。1.2 QuickBlue在技术栈中的位置它不是模型也不是业务系统我第一次给团队解释QuickBlue时用了数据库来类比。早年写应用每个模块都自己拼SQL连数据库后来出现ORM和数据访问层大家才把连接、缓存、事务这些事收拢到一起。AI应用底座做的事情逻辑上是一样的——它不是一个模型不负责“思考”也不是某个业务系统不管“合同审核”或“客服应答”。它处于模型和业务应用之间核心职责是把模型能力变成标准接口把复杂编排变成可配置流程把模型调用过程变成可观测、可治理的工程行为。具体展开后QuickBlue在技术栈里的位置由四块组成模型网关负责统一接入各家模型并做路由编排引擎负责定义Agent的步骤和工具调用上下文与记忆服务负责管理会话、摘要和长期记忆治理控制台负责权限、审计、成本和监控。业务应用只需要对接QuickBlue这一层就能获得“模型无关”的开发体验——今天用的是模型A明天因为成本或效果换成了模型B业务代码一行都不用动改的是底座上的配置。1.3 为什么叫“底座”而不是“中台”或“平台”起名这件事我当时没有随便来。QuickBlue拆开看就是quick加bluequick对应“快速交付”希望业务团队接入AI能力时不用等太久blue对应“稳定和可信”底座这种东西一旦出问题挂的是所有上层应用稳定是第一位的。没有叫“AI中台”是因为“中台”这个词在很多公司已经被搞成了流程僵化、响应变慢的代名词业务团队一听中台就担心又要提需求排队。而“平台”一词又过于宽泛听起来像个什么都装的筐。叫“底座”传达的是一种克制这一层提供能力但不定义业务规则它靠近基础设施不靠近业务创新。我们内部明确了一条边界底座团队不替业务决定“这个场景要不要用某个模型”也不替业务写prompt里的领域知识他们负责的是让这些能力“好用、可控、可运维”。把姿态放低反而是它能够长期存活的原因——一旦一个底座团队开始对业务指手画脚业务部门就会想办法绕过它。2. QuickBlue的核心能力拆解一个底座该有的四件事2.1 模型接入与统一网关把各家模型变成标准接口QuickBlue的第一层能力是模型网关。无论底层接的是国内的开源模型、国际商业API还是自建的微调模型对外都暴露一套统一的接口协议我们内部采用OpenAI兼容的/v1/chat/completions格式这套协议已经成为事实上的行业标准工具链最全迁移成本最小。业务方不用关心某个模型是走HTTP还是走内部SDK也不用关心它底层是哪个供应商。网关内部还要做路由。我们实际配置时把模型分成几种角色主模型处理常规请求备用模型承担降级流量局部小模型承担高并发低成本的简单任务。路由的依据主要有三类按能力这个请求是否需要工具调用、按成本相同效果下优先选便宜的、按延迟对响应时间敏感的场景优先选快的。配置大概是下面这样models: - name: pro provider: openai-compatible base_url: https://internal-model-gateway.example.com/v1 api_key_env: LLM_PRO_KEY capabilities: [chat, tool_use] price_per_1k_input: 0.012 price_per_1k_output: 0.036 router: strategy: cost_first fallback: [backup, local-fast] timeout_seconds: 30 max_retries: 2这里有一个很容易忽略的点call超时和重试必须收敛在网关层而不是留给业务应用自己处理。很多模型服务商不会在文档里明确写“我们也会抖动”但实际生产环境里上游超时、限流、5xx几乎是常态。网关层统一做了超时熔断和重试之后业务侧的代码可以保持简单也不会因为某个供应商的一次抖动让全线应用一起报错。2.2 Agent编排与工作流定义让AI参与业务而不是跑demo第二层能力是编排引擎。很多团队做Agent时喜欢把步骤写在业务代码里顺序调用LLM、调用工具、判断结果、再调用LLM。这种方式的致命问题在于AI应用的行为经常需要调整而每次调整哪怕只是改一个分支都要走代码发布流程产品同事等得失去耐心。QuickBlue的编排引擎把工作流改成了声明式配置用节点和边的形式定义任务流程。拿一个典型的“工单自动分诊”来说流程是先对工单内容做意图识别再判断紧急程度和业务线接着决定直接生成回复还是转人工。这个流程用配置描述为workflows: ticket_triage: input_schema: ticket_text: string customer_level: string steps: - id: intent type: llm prompt_ref: prompts/triage/intent.md output_field: intent - id: priority type: llm prompt_ref: prompts/triage/priority.md output_field: priority - id: should_auto_reply type: condition field: intent in: [refund, return, shipping_query] - id: draft_reply type: llm prompt_ref: prompts/triage/draft.md depends_on: should_auto_reply - id: send_to_human type: webhook url: http://crm.internal/v1/tickets/escalate depends_on: should_auto_reply声明式配置最大的好处是业务运营或AI产品经理经过简单培训后就能自己调整分支逻辑不用等研发排期。这对AI类项目的意义很大——因为它本质上是探索性的没有人能一次就把流程定义对快速试错本身就是核心竞争力。2.3 上下文与记忆管理解决“多轮会话断片”的工程方案第三层能力是上下文与记忆管理这是做对话类AI应用最容易翻车的地方。直接把所有历史消息一股脑塞给模型效果其实不差但成本会失控。一次对话超过十轮之后历史消息占用的tokens可能比实际要完成的任务还多。QuickBlue把记忆拆成三级来管理。第一级是短期上下文用滑动窗口保留最近几轮消息这个窗口的默认大小按业务场景调整客服场景通常是八到十二轮太多会超过模型的有效注意力范围。第二级是会话摘要当窗口快要被挤掉时先把旧消息用模型压缩成一段摘要放在窗口最前面。第三级是长期记忆包括用户的偏好、历史订单、常问问题等这部分内容不能靠硬拼进上下文而是按需从向量库里检索出来再注入。这里补充一个实际参数经验摘要触发时机不是“对话超过N轮”而是估算当前上下文tokens接近窗口上限的七成时触发。每次摘要成本不高但能把后续请求的token消耗降到一个相对平稳的水平。如果不做这层管理一次客服会话到最后一条消息时可能已经把一两万tokens烧进去了而且大部分是重复历史。2.4 可观测性、权限与审计底座能不能上生产看的就是这一层第四层能力是治理能力这是一个AI底座能不能从demo走向生产的分水岭。可观测性方面每次模型调用都要留trace包括输入内容、输出结果、模型名、耗时、token数、费用估算。没有trace的情况下线上出了错只能靠用户截图排查效率极低。权限方面要区分用户级、角色级和数据级权限。用户级决定谁能调用某个模型角色级决定谁能在编排里改配置数据级决定模型能检索到哪部分业务数据。审计能力在不同行业要求不一样但我们统一建议做到“每次调用可追溯每笔成本可归属”。具体做法是每个请求从网关进来时就带上tenant_id和biz_trace_id一路透传到日志、监控和账单系统。后面不管财务要求解释成本还是合规部门要求说明某次输出是怎么来的都能在几秒内定位到当时的完整调用链。3. 从0到1搭建QuickBlue的实操过程3.1 搭建前的三个决策租户、模型与数据隔离如果你准备在自己团队里搭一套类似的底座动手前先定三个事。第一是单租户还是多租户。产品线少、业务单一就做单租户省掉大量租户隔离的成本如果公司里有多个业务线都要接入建议一开始就考虑多租户哪怕先只做“逻辑隔离”而不是“物理隔离”也要把tenant_id的字段在数据模型里留出来否则后面硬拆会非常痛苦。第二是模型选型。我们的建议是“一主一备一便宜”一个效果好的主力模型一个能力稍弱但稳定的备用模型一个超便宜的小模型负责路由判断、摘要、关键词抽取这类简单任务。这样能保证效果、稳定性和成本三者相对平衡。第三是数据隔离。向量数据库、缓存、调用日志这三类数据要提前明确按什么维度隔离是按业务线、按团队还是按客户。这里没有标准答案但一定要在第一天就做出选择因为涉及数据归属和数据安全的东西后面迁移成本极高。3.2 快速搭建一个最小可用底座下面是我们当时搭建最小可用底座的实际步骤不依赖任何特殊环境你可以在自己的开发机上复现。第一步准备基础环境一台8核16G的虚拟机或者开发容器就够了。我们需要Docker和一个Kubernetes集群单机模式用kind或者k3s都行。第二步部署网关服务。我们内部网关基于FastAPI自研核心就一个转发模块接收标准/v1/chat/completions请求查路由配置转发给指定模型供应商再把响应原样返回。这里有个细节网关和模型供应商之间要加一层api_key管理供应商的key不能出现在业务配置里统一放在环境变量或密钥服务中。第三步配置第一个模型供应商。在配置中心里填入模型名称、base_url和api_key_env然后跑一个冒烟测试脚本用客户端请求一次from quickblue import Client client Client(base_urlhttp://localhost:8080, api_keydev-key) resp client.chat.completions.create( modelpro, messages[{role: user, content: 用一句话介绍你自己}], ) print(resp.choices[0].message.content)第四步把可观测性接进来。我们直接用OpenTelemetry协议上报到本地的Jaeger网关每个请求自动生成一个trace_id记录模型名、耗时和token数。这一步不要省哪怕一开始只接个最简版也要让“每一次调用都可见”成为一个默认行为。做完这四步你就有了一个能转发请求、能看到trace的最小底座耗时大概半天。3.3 接入第一个业务场景以客服工单自动分诊为例底座跑起来之后找一个具体场景来验证它是最好的方式。我们当时的第一个场景是客服工单自动分诊原因很简单高频、重复、价值明确而且不影响收入失败了也容易兜底。第一次接入我们只做了一件事把原来写在客服应用里的“判断工单意图→分配技能组”的逻辑搬到QuickBlue的编排引擎里。业务代码里保留原来的接口但内部改为调用底座的编排能力。同时把prompt抽出来放到提示词仓库里与应用代码解耦。调整后的prompt模板大概是你是一个客服工单分诊助手。请根据工单内容判断意图和紧急程度。 意图范围退换货、物流查询、账户问题、产品咨询、投诉建议。 紧急程度高涉及资金安全、服务不可用、中客户有明显不满、低普通咨询。 只输出JSON格式{intent: ..., priority: ..., reason: ...} 工单内容{ticket_text}上线后我们盯三个指标分诊准确率人工复核抽样、转人工率、平均处理时长。分诊准确率稳定在85%以上就可以进入正反馈循环低于这个值说明prompt或流程设计有问题优先检查的是意图范围是否覆盖了真实数据分布而不是急着换模型。顺便说一句AI应用上线后效果不好第一个怀疑对象通常是“任务定义”不是“模型能力”。很多分诊不准是因为“投诉建议”和“产品咨询”在真实工单里边界模糊换再强的模型也区分不了这时候要改的是任务拆法。4. 落地过程中最常见的5个坑4.1 模型不稳定导致的上游故障扩散第一个坑是我们真实踩过、也是所有AI应用团队几乎都会遇到的模型供应商接口抖动结果所有上层应用跟着一起报错。表面上看是供应商不稳定根子却在自己的底座上没有做隔离。我们当时的网关只有转发功能没有超时、没有重试、没有降级模型慢三秒所有依赖它的接口就全部堆积。解法是给网关统一加上三件套。第一超时设置默认30秒超过就中断并记录trace。第二重试策略对5xx、429限流、超时这几种情况最多重试两次但重试必须带Exponential Backoff否则上游抖动时你的重试只会让情况更糟。第三降级链路启用fallback配置主模型失败时自动切到备用模型fallback: - triggers: [timeout, 5xx, rate_limit] fallback_to: backup message: 主力模型暂不可用已切换备用这套机制上线之后我们再也没有因为模型供应商的状态波动而需要加急发版。很多团队觉得这是“以后再说”的事但我的经验是它在第一周内就会找上门来。4.2 Token成本失控第二个坑是Token成本失控。有一次月度账单出来我们发现成本翻了三倍一查才知道是某个业务线的应用在用户输入为空时也会带上整个会话历史去请求模型大量无效请求在烧钱。问题的根源不是模型贵而是应用层完全没有成本意识。我们后来做了三层控制。第一层预算池。按业务线设置月度预算上限超过阈值自动告警并降级到备用小模型。第二层单请求限额。网关在转发前检查请求的token估算值超过配置限额直接拒绝。第三层成本归属。之前提到的tenant_id和biz_trace_id在这里发挥作用每笔成本都要能归到具体业务和应用上。一个必须掌握的计算公式单次请求成本 (输入tokens / 1000) × 输入单价 (输出tokens / 1000) × 输出单价重点在于输出tokens往往更贵所以需要在prompt里限定输出格式和长度。给模型规定“只输出JSON”不仅提升了解析稳定性还能避免它生成一大堆无关的解释性文字成本降得很明显。4.3 提示词散落在业务代码里第三个坑属于工程规范问题提示词散落在各处业务代码里。一开始大家觉得prompt不就是一段字符串嘛放代码里也没问题。直到某天产品要求把客服助手的语气从“正式”改成“亲切”我们需要在四五个仓库里找到七八段prompt逐个改完再发布这个过程非常容易漏。解法是把prompt抽成一个独立的提示词仓库带版本管理。业务代码通过prompt_ref引用某个版本的提示词而不是直接把内容粘在代码里。QuickBlue的编排配置里我们统一用prompt_ref字段提示词仓库里每个prompt文件都有版本号、变更记录和生效时间。这样产品想调整语气或措辞只需要在提示词管理界面上改一版、做一次AB测试不需要经过代码发布流程。这件事对后续迭代效率影响极大早做早省心。4.4 权限模型设计得过早或过晚第四个坑是权限模型的设计时机。我们见过两个极端一个团队在只有两个应用的时候就上了企业级的RBAC、数据隔离、审批流结果业务方要接一个场景要提一堆申请开发也被流程拖得没脾气另一个团队则完全裸奔应用上线三个月后才发现任何登录用户都能让模型检索到整个知识库的文档紧急返工。我们的做法是分阶段。起步阶段用最小权限模型所有内部开发人员默认可以调模型按“谁创建谁管理”划分编排配置的编辑权限数据级权限只做了基础的知识库范围隔离保证不同业务线不能互相看到对方的私有文档。等应用数量到了十个以上再补上完整的审批流、细粒度角色和审计报表。不要试图一步到位但一定要在这条路上留好扩展点比如用户体系里一开始就用tenant_id user_id而不是只存一个用户名。4.5 把底座做成“大而全”的黑洞第五个坑最隐蔽底座团队的无边界扩张。我们当时差点犯这个错误团队里有人提议把文档解析、数据清洗、标注平台都收进QuickBlue理由是“这些以后都能用上”。讨论到最后我们刹住了车因为底座一旦什么都做就会变成一个巨大的黑洞——每个需求都要排期每个业务方都在催团队日夜加班却产出稀碎。我后来定了一条很简单的规则底座只做“模型和应用之间必须被统一治理的横向能力”涉及具体业务语义的东西一概不做。文档解析可以接外部成熟组件但只有当解析结果要被多个应用复用且都要经过权限校验时才考虑收编进来。判断标准就是这件事是“平台必须承担的共性逻辑”还是“个别业务的个性化需求”。守住这条线底座才能保持轻和快。5. 什么样的企业现在就该考虑AI应用底座5.1 判断标准先问自己三个问题很多团队问我“我们到底要不要现在做底座”我的回答是先问三个问题。第一你现在同时用着或者计划用两个以上的模型吗如果只需要固定用一个供应商的API重复建设还不多可以先不做。第二你的AI应用准备接入核心业务流程吗比如直接处理工单、辅助客服回复、参与审批流而不只是做几个内部demo。如果答案是“是”那你很快会遇到统一接入、权限审计、稳定性这些问题底座就是答案。第三你有没有想过如果明天模型供应商涨价或者接口变了你的应用怎么办如果这个问题让你后背发凉那你就需要一个模型无关的底座。这三个问题里只要有一个“是”就值得开始做轻量底座有两个以上就不要再等了。但请注意这里的“做底座”不是指组建一个几十人的平台事业部而是先在现有团队里抽出两三个人把网关、编排、可观测性这层薄薄的能力搭起来。5.2 团队怎么养底座团队不需要很大但边界要清晰底座团队的组织方式我建议是“小而精”三到五个人起步就够了。一个负责模型网关和基础设施一个负责编排引擎和提示词仓库一个负责可观测性、权限与成本治理如果预算允许再加一个偏产品思维的成员对接业务方帮他们把场景翻译成工作流配置。不需要按传统的“中间件团队”“AI平台组”那样狂铺人力因为底座这一层一旦稳定下来运维压力其实不大。真正难的不是招人而是边界管理。底座团队的KPI应该绑定“接入场景数量、稳定性指标、成本治理效果”而不是“我们建了几个平台能力”。我们内部有一条硬规矩底座成员必须每隔一段时间全程参与一个业务场景的落地亲手写一次工作流配置而不是只在会议室里评审需求。否则一个底座团队很容易脱离实际业务做出很多“看似先进但没人用”的功能。5.3 与现有系统的协同不是替代而是渐进叠加最后多说一句与存量系统的关系。很多团队以为上了AI应用底座就要把现有系统推倒重来其实不是。底座是一个叠加层你完全可以让老系统继续运行新AI应用接到底座上存量应用按接口协议逐步适配一次迁移一两个场景而不是搞什么“Big Bang”切换。我们当时的经验是选一个最痛、最高频、价值最清晰的场景先跑通把这个场景做成样板再逐周扩展到其他业务线。整个落地过程我个人体会最深的一点是先有应用还是先有底座其实是个伪问题。正确路线是先有应用“逼”出底座——当你同时维护多个AI应用发现大量重复的横向逻辑时底座的需求会自动浮现。但底座一旦立起来它反过来又会加速新场景的接入速度这个正反馈会让你越做越顺手。跑了一年后回头看QuickBlue帮我们省下的最大成本不是代码量而是让每个业务团队都不需要自己在“模型接入、权限治理、成本管控、稳定降级”这些事上重新交一遍学费。