1. QuickBlue 在我这儿的定位不是模型也不是中台是底座有一次团队例会上产品同学拿着刚跑通的演示问我我们这是不是已经有 AI 能力了我下意识回了一句你有的只是模型能力还没有 AI 应用能力。这句话后来成了我们内部统一口径的依据也顺带说清楚了 QuickBlue 到底在做什么。QuickBlue 不是某一个开箱即玩的聊天机器人也不是一个卖提示词的平台。在我参与过的几次 AI 项目里它承担的是更靠底层、也更无趣的角色——把模型、数据、工具调用、权限、日志这些东西串起来让业务应用不需要每次从零造轮子。你可以把它理解成 AI 应用底座上面跑的是客服、知识助手、数据分析助手、审核助手底下是统一模型接入、上下文管理、智能体编排、成本观测和治理栏杆。第一次听到AI 应用底座这个词的人很容易把两个极端搞混。一头是大模型 API 平台好像申请一个 Key 就完事另一头是业务中台恨不得把全公司能力都装进去。底座恰好位于两者中间。模型平台管的是模型怎么被调用底座管的是调用之后应用怎么活下来。业务中台承载的是公司稳态的业务规则底座承载的是 AI 应用里不断调整的推理逻辑。1.1 我理解里的 QuickBlue是给AI 应用接上的水电煤做业务的同事往往看到的是效果做工程的同事看到的是依赖。一个 AI 应用要能稳定跑在生产环境至少要回答这些问题模型从哪接入提示词和知识库放在哪调用出错时怎么重试每一次请求花了多少 Token用户可以访问到哪一层数据审计日志怎么留敏感信息怎么过滤在没有统一底座的时候我把这些问题原样抛给每个业务开发得到的是十个团队十种解法有人把 Key 写死在代码里有人用 Excel 管理提示词有人把向量数据库直接架在生产库旁边。短期看都能跑起来一旦有第二个应用所有设施就得再搭一遍。更麻烦的是第三个应用搭的时候又换了另一套最后没人说得清线上到底在跑什么。QuickBlue 在我这里最朴素的定位就是把这部分公共能力收口。它不决定业务长什么样但决定业务能不能被稳定支撑起来。说它是水电煤一点不夸张——你看不见它的时候说明基础设施是健康的你开始频繁操作它的时候往往就是业务卡住了。1.2 底座和模型平台、低代码平台、业务中台边界到底在哪把四个经常被混淆的概念放一起差异会更清楚。概念主要管什么典型使用者为什么不是底座模型 API 平台模型本身、计费、并发算法工程师、后端开发只解决调通不解决用好低代码/Agent 建站平台表单、流程、效果演示业务人员、产品经理重交互、轻治理适合原型而非规模化业务中台订单、用户、支付等确定性能力整个业务体系承载的是确定性流程不是不确定性的推理AI 应用底座模型路由、上下文、编排、观测、治理应用 owner、算法工程师、运维它就是公共底座本身这个边界只要稍微错位一点后续的坑就会非常明显。把底座做成模型平台的人最后团队天天在研究哪个模型更强却没人回答我们自己的数据在哪把底座做成中台的人则会陷入无尽的抽象设计第一个真实业务还没进来项目先被评审流程拖没了。QuickBlue 这个关键词放在标题里本质上是在提醒一件事企业真正缺的不是多一个模型而是缺一个能把模型变成产品级能力的地基。2. AI 应用底座到底由什么构成四件套拆开讲说清楚 QuickBlue 的价值之后接着要回答的问题是底座里到底装了什么。我见过的底座方案五花八门剥掉广告词稳定发挥作用的通常是四件套模型接入与路由、数据与上下文、智能体与工作流编排、可观测性与治理。缺了其中任何一件短期内不一定出事一旦应用多起来或流量涨起来会以非常难看的姿势补课。2.1 模型接入与路由让大模型变成可插拔资源第一层做的事很朴素把市面上各种模型统一成一套 API。业务开发不用关心你接的是哪个厂商的模型、参数怎么填、鉴权怎么做只需要按统一协议发请求。这一层还要有能力做路由。同一家公司内部有的场景需要长上下文有的场景更看重响应速度有的场景对成本极度敏感。底层的路由规则可以按场景标签 模型能力 预算来决定用哪个模型并且要支持降级。比如主模型超时自动切到备用的小模型用户界面上的感知只是慢了一点而不是直接报错。我习惯用一个比方大模型像一位外聘的顶级专家底座则是专家的助理和流程。助理负责对接排期、准备材料、控制预算、处理突发情况专家只需要专注给出判断。没有助理专家再厉害也会陷入约不到、等不到、付不起、说不清的混乱。2.2 数据与上下文RAG、记忆、知识库的根本作用是减少幻觉模型本身只会接着话往下说企业应用要的是基于我们的真实数据来回答。所以底座必须替应用管理上下文。这里说的上下文不是简单把对话历史拼起来而是包括知识库检索、动态记忆、用户画像、结构化数据查询。一个客服助手要回答我上个月的订单为什么还没有发货光靠模型聪明是不够的它得能拉取订单系统的数据、读取最新的售后政策、还要记得这个用户刚刚说过的诉求。这些能力应该由底座在接口层面直接提供而不是每个业务团队各自对接三五套系统。我对团队提的要求是凡是涉及外部数据的回复必须能指出数据来源和更新时间。否则你根本分不清某个错误回答到底是模型幻觉还是知识库里的旧数据在误导。这也是为什么 RAG 链路不能只是 demo 里的一句口号它需要做数据清洗、分块、索引更新、检索结果校验一整套工程。2.3 智能体和工具编排结果要可以被追溯当 AI 应用不满足于答一句话而要替用户完成多步任务时就会用到智能体和工具编排。比如帮我写一份竞品分析报告并且发给相关的三个人这不是一次模型调用就能完成的需要拆解成多个动作还需要调用搜索工具、文档审批工具、消息发送工具。底座的职责不是提供一个炫酷的 Agent 界面而是提供一套确定性的工作流运行时。每个任务从哪里触发、每一步调用了什么工具、消耗了什么权限、结果是否被人工确认都要有记录。Agent 越自主这块就越不能放松。你可以想象成公司里的督办系统事情可以自动流转但每一步谁批的、谁改的、谁最终签字事后随时可查。在没有这套能力时我见过团队用无数个如果条件 A调用工具 B的代码硬拼 Agent看起来跑了实际上每次请求的路是全乱。生产环境一出问题根本无法定位是模型判断错了还是工具参数传错了还是外部系统响应不稳定。2.4 可观测性、成本控制和安全护栏底座的隐形骨架这些能力不怎么出现在演示里却是底座能不能长期活下去的关键。模型调用不像传统接口它天生带有概率性和不确定性所以必须把输入、输出、延迟、Token 消耗、审核结果完整记录下来。成本控制要细化到应用、团队、场景三个维度。我见过一家公司月底收到大模型账单时才发现某个内部工具一个月烧掉的钱比整个平台的预算还高因为当初只是试试没人设过配额。底座如果从一开始就记录用量并做配额预警这种事根本不会发生。安全护栏则是把不合规的内容挡在边界之外。包括敏感词和隐私信息过滤、数据权限校验、外发内容审核、以及针对特定业务的高风险操作复核。护栏不应该由各个业务应用自己拼凑而应该在底座里统一配置、统一升级。能力层一句话职责缺失时最典型的后果模型接入与路由统一 API、场景选型、降级业务代码绑死单一模型升级一次改全家数据与上下文知识库、记忆、数据来源追踪输出看着像样细问全是幻觉和旧数据智能体与工作流任务拆解、工具调用、轨迹留存Agent 像黑盒出了问题无从排查观测、成本、护栏用量记录、配额、安全过滤账单爆炸、合规风险、事故难复现这里我还要多说一句护栏不一定等于管的越多越好。做得太死业务同学会绕开底座另起炉灶反而更危险。护栏要解决的关键问题不是禁止一切而是让每个越界操作留下痕迹、可解释、可撤销。3. 没有底座的企业 AI 项目问题往往长这样这一节不说概念说现象。我自己总结下来没有底座的企业 AI 项目问题往往逃不开三种形态而且每一种我都亲手处理过。3.1 三条典型的翻车路径第一重复建设。每个业务团队都觉得 AI 很简单各自接入模型、各自建知识库、各自写提示词。表面热闹实际是同一套底层能力被反复实现十遍而且每一遍的实现质量都不一样。今天 A 团队修好的鉴权漏洞B 团队那边的代码里还留着。第二模型依赖过重。很多团队在开发时喜欢选最强的模型把指令、格式、行为都压在某一个模型的脾气上。一旦模型厂商发新版或者价格调整整个应用的行为就变了要么输出格式乱掉要么成本和延迟暴涨项目组只能放下手头所有事去救火。第三成本与责任失控。业务同学在界面上随便问几句背后其实在调用昂贵的模型一次深度推理会话可能消耗上千 Token。没有统一计量时这些成本是分散的、隐蔽的最终变成财务月度惊讶和团队互相甩锅。3.2 一个让我印象很深的案例客服助手从 POC 到生产那三个月去年有个做企业服务的团队找我复盘一个客服助手项目最开始做 POC 时效果惊艳领导很满意直接排期上线。上线后出现三个问题一是不同渠道来的用户问题格式差异大知识库里的文档跟不上回答经常给出过时的促销政策二是某次底层模型发版之后原本稳定输出的退款单号突然变成了 Markdown 表格下游系统解析失败三是没有成本配额某个外部渠道的一次异常流量把当月模型预算打掉了一半。听起来是三个不同的问题根子上都是同一个应用和模型之间缺一层缓冲区。如果当时有 QuickBlue 这样的底座第一类问题会落在知识库更新和数据来源校验的职责里第二类问题可以通过统一输出校验和模型版本灰度拦截第三类问题在第一天就会有配额预警。这个项目后来花了两个月补基础设施比重新开发一个功能还痛苦。复盘时我们还有个很扎心的发现团队并不是不知道这些问题而是觉得先演示、先上线后面再补。但模型应用的容量、成本、行为漂移问题不是上线后才有而是上线后被放大。等到老板开始过问账单和故障率再回去补底座每次变更都要背上正在跑的业务这个包袱成本和风险完全不是一回事。3.3 症状和底座能力的对照比任何理论都直观你观察到的症状底座里负责解决它的部分每个团队都在封装各自的大模型客户端统一模型接入与路由层提示词散落在代码、说明文档和聊天记录里提示资产与评估版本库模型换版本后输出格式漂移模型灰度、输出校验与回滚回答涉及企业内部数据时经常一本正经胡说知识库索引、来源追踪、RAG 流程月底才知道 AI 花了多少钱用量计量、预算配额、实时预警Agent 出错但不知道执行到哪一步工作流轨迹、日志与回放数据权限在 AI 应用里形同虚设统一鉴权、数据过滤、审计这张表不是要从理论上说服谁而是排查问题时的索引。线上出了问题拿症状对照底座能力基本能找到缺的那块。我甚至建议团队把这张表贴在项目作战室里遇到事故先把症状归类再看是底座的问题还是应用的问题别每次都靠拍脑袋。4. 落地底座时的负责人排序先做哪一步后做哪一步很多团队知道要补底座但一动手就想一步到位结果做了三个月全部在讨论架构图。我个人的做法是严控节奏按四步收口每一步都能在两周内看到效果。4.1 阶段一统一模型网关把选模型这件事收口先不要碰复杂的编排也不要去建统一知识库第一步就是把所有模型调用收敛到一个网关。所有应用不再直接配置模型厂商的 Key而是向网关申请访问凭证。网关里保留统一协议、超时策略、重试、模型路由和请求日志。这一步的收益是立竿见影的起码你终于知道线上每天有多少次模型调用、哪个应用在调、平均延迟多少。后续换模型供应商也只需要在网关层改配置。一个接近实用的网关配置长这样model-gateway: providers: - name: primary-llm type: openai-compatible base_url: http://llm.internal.example/v1 router: default_model: primary-llm fallback_models: [backup-llm] max_retries: 2 timeout_sec: 30 quota_enabled: true cost_trace_enabled: true我只把这个当作模板企业根据自己的部署形态改即可。核心思想是应用只依赖网关地址不依赖具体模型名模型是网关背后的资源不是应用代码里的常量。这一步做得越早后续换模型的代价就越低。4.2 阶段二补齐知识接入与提示资产版本化网关稳定以后再开始收拾内容这一摊。把公司现有的制度文档、产品手册、FAQ、历史工单抽出来做清洗、分块、建立索引并按业务域打标签。同时要求所有 AI 应用的提示词从版本库读取不能直接写死在业务代码里。很多人不理解提示词为什么要版本化。我的回答是提示词本质上是一段会直接影响线上行为的代码它当然应该被版本管理、可回滚、可评审。提示词里的一个措辞调整可能让某个分类任务的准确率变化几个百分点这比很多普通代码变更的影响都大。阶段二还要顺手做一件事为每个知识域绑定权限。低权限用户提问时检索结果只能来自其可见范围内的知识避免员工通过聊天机器人变相翻出自己不该看的内容。这一步不复杂但一定得放进底座而不是放给应用层自觉。知识检索的权限控制做不好大模型就会成为公司里最勤快的泄密助手而且很多时候是无意的。4.3 阶段三把智能体链路放进可观测体系如果你的应用开始引入 Agent可以在阶段一日志的基础上叠加任务级追踪。每次任务生成一个 trace_id记录模型输入、模型输出、工具名、工具参数、执行结果、耗时、费用。伪代码大概是这样result workflow.run( triggerticket.created, steps[ fetch_knowledge(ticket.category), call_llm(summarize, max_tokens500), call_tool(create_draft, require_confirmTrue), ], trace_iduuid4(), )有了这个链路Agent 就不再是黑盒。线上报一个机器人答错了你可以把整个过程翻出来看是检索到的知识不对还是工具调用参数写错还是模型做了一个错误判断。定位时间会从几天缩短到几分钟。这里有一个容易被忽视的设计点不要在业务代码里写死工具调用把工具注册表放到底座里。注册表管每个工具的参数 schema、权限要求、是否需要人工确认。这样既方便审计也方便未来接入更多工具。更实际的好处是当某个第三方工具涨价或掉线时你能在底座层面直接切换而不是去改几十个业务调用点。4.4 阶段四完成权限、审计与护栏闭环最后一步做治理。这一步包括给每个应用设置独立的密钥和配额、按月生成成本报表、按团队设置预算线、把不合规请求的拦截策略做成全局规则。还要确定哪些高风险动作要人工确认例如发送对外消息、修改正式数据、导出批量客户信息。治理做完之后底座才真正称得上底座。在这之前它只是工具集合。有了权限和审计企业才敢让 AI 应用进入主流程而不是永远停留在演示给领导看的层面。我见过太多团队在第四步上拖延理由是现在人少先跑通业务要紧。结果业务跑得越顺权限和成本问题越积越多最后补的时候已经要动所有应用的代码。治理这种事越早做、越便宜它不是在限制业务而是在给业务上保险。5. 上底座前企业最该想的三个问题到了这里肯定会有读者想行底座有价值但也听说过太多平台化项目变成烂尾工程。所以我再放慢一点说说企业动手前最该想的三个问题。5.1 底座会不会变成又一次造中台式的折腾过去几年中台这个词被打上了阴影很多企业一听到公共底座就皱眉担心又搞出一套宏大叙事。我的判断是底座和中台的区别不在于抽象层级而在于第一版到底服务谁。真正能落地的底座从来不是从一张全景架构图开始而是从最痛的两三个 AI 应用中反推出来的。你先有客服助手、知识助手、数据分析助手它们遇到重复的问题再把共性抽出来这才是底座。反过来先画好十层架构再找业务来凑大概率会重演中台烂尾。所以选 QuickBlue 或自建底座第一步动作应该是一样的挑一个已经在线上跑、真实有多方参与、大家都在受基础设施之苦的 AI 应用拿它当底座的第一批试点。管理层的预期也要同步对齐底座第一版不追求覆盖全公司只追求让第一批试点的满意度明显提升。满意度上来了后面要推广就顺理成章满意度不行再大的规划书也救不了。5.2 模型能力变化太快底座会不会锁死技术选型AI 领域每个月都有新模型出现企业担心底座做了就锁死这很正常。但底座的设计目标恰恰就是为了避免锁死。底座把模型放在适配层后面应用不感知模型品牌只感知能力标签比如长文本低成本高准确率。技术选型的自由不是谁都能直接调而是换模型的时候不用改业务代码。我建议底座默认策略是保守模式在没把握之前核心场景尽量用默认模型新模型先在非核心场景灰度跑够评估指标再决定要不要放量。这比公司上下全员追新模型安全得多。模型换代的概率在你做好底座之后反而更高因为底座让试错成本变低了。没有底座的公司换一次模型等于重构一次应用有底座的团队换模型就是改一条路由配置。两者对模型变化快的恐惧程度完全不同。5.3 团队只有几个人、只有一个 AI 应用要不要上底座如果你们全公司只有一个 AI 应用、用户量不大、也没有合规审计压力我的建议很直接先别搭底座直接用模型平台加一个简单的封装层就够了。底座是公共品公共品在没有多个消费者之前建设成本就是纯损失。需要开始认真考虑底座一般是出现这几个信号第二个 AI 应用开始立项不同团队出现了重复的模型接入代码某个月模型账单超出了所有人的预估线上问题无法复现因为上下文的日志根本不够或者老板开始问我们这么多 AI 项目到底哪几个在真正创造价值。我的体会是QuickBlue 这类底座真正解决的不是从 0 到 1的问题而是从 1 到 10、从 10 到 100的问题。早期没有平台是正常的有了规模化诉求再回头做也不丢人。怕的是规模已经上来了还在假装每个应用的模型接入都是各自的事。关于怎么选底座这件事我最后再给一条很个人、也很实用的建议不管用 QuickBlue 还是自研第一版底座一定要让最痛的应用的负责人成为核心用户。底座不是给架构师看的是给每一个跑线上业务的工程师和产品用的。谁天天在线上挨用户骂谁最清楚底座该先解决哪一块。把他们的痛解决掉底座自然会被留下来解决不掉你的平台再漂亮也只会成为下一次技术盘点时的反面案例。