我们团队最近把整个企业内部的 AI 应用都迁到了一个内部代号 QuickBlue 的底座上起因很简单市面上模型越来越多业务部门提的需求也从做个聊天机器人变成了让 AI 去处理工单、写报告、审合同单靠调 API 根本顶不住。折腾了几个月踩了不少坑也趟出了一些可复用的打法。这篇文章就把 QuickBlue 到底是什么、为什么企业需要它、以及我们落地时的具体做法和血泪教训一次说清楚。不管你是技术负责人、架构师还是刚接触 AI 应用的产品经理看完应该能少走几周弯路。1. 从AI 项目到AI 应用中间隔着一道真实的门槛刚开始做 AI 落地时团队里最容易出现的错觉是既然大模型这么强写个 Prompt 调 API 不就行了做过 Demo 的人都知道单个功能跑通确实不难难的是把它放进真实的企业业务流程里让它稳定、安全、费用可控地长期运行。1.1 做 Demo 和做产品完全是两码事我见过太多团队花两周时间做了个惊艳的 AI 客服 Demo效果演示时全场鼓掌然后一上线就翻车。原因往往不是模型不够聪明而是没人处理这些问题上下文管理用户多轮对话超过窗口长度后模型开始失忆工具调用AI 需要查订单系统、回写 CRM但接口认证方式五花八门成本失控同一个 Prompt 被高频调用月底账单吓死人不可观测模型返回了错误结果你连日志都查不清楚是哪一层出的问题。这些坑单靠业务团队自己填每个项目都要重填一遍规模一大必然失控。所以AI 应用底座这个词本质上是在解决一个工程化问题把让 AI 干活这件事从手工作坊变成流水线。1.2 底座要接住的三大类共性能力我梳理了我们内部所有 AI 应用后发现不管业务场景是什么需求都可以收敛成三类模型接入与路由屏蔽不同模型厂商的 API 差异支持按场景选择不同模型智能体编排让多个 AI 角色Agent协同工作分工处理复杂任务企业级支撑知识库、记忆、权限、审计、可观测性一应俱全。QuickBlue 这个名字在内部是随口起的但后来用下来发现A 应用底座这个定位非常准确。它不是一个具体的业务系统而是所有 AI 应用的基础设施层像水电煤一样让业务团队不需要关心模型从哪来、怎么接、出问题了找谁。2. 为什么不能直接采购大模型而是需要一个底座层可能有人会问我直接用 OpenAI、通义千问、文心一言的 API 不就得了为什么非要中间加一层这个问题我们的回答是企业级场景里你敢不敢让业务系统直接依赖某个具体模型供应商的接口决定了你有多少自主权。2.1 模型供应商锁定是最大的隐性风险把大模型 API 直接写死在业务代码里短期看省事长期看是给自己埋雷。你想想这几个场景供应商调整价格策略你毫无议价能力某家模型在某些垂直领域表现差你想换一家发现代码耦合太重换不动私有化部署成为硬性合规要求时技术栈完全推倒重来。QuickBlue 的做法是把模型接入统一收敛到网关层。业务代码只面向网关的标准协议底层模型可以按需切换。我们实际做过一次大规模迁移从模型 A 切到模型 B业务侧零改动只改网关配置十分钟完成。2.2 多模型协同比单模型调用更符合真实业务在真实业务里一个大模型包打天下的情况非常少。我们内部总结出一个经验按任务难度和成本给不同模型分配角色。简单意图识别用轻量模型复杂推理任务才用旗舰模型重大合规判断再加一道专家模型复核。底座的价值就是把这种多 AI 协作变成常态能力。热搜词里频繁出现的多 AI 协作AI Agent 搭建本质上都是在讲同一件事任务经过拆解后分发给不同的 AI 角色由编排引擎统一协调最后聚合结果返回给用户。2.3 底座天然承担治理与合规责任企业级应用绕不开安全与合规。谁负责确保 AI 生成内容不违规谁负责敏感数据不泄露谁负责留痕可审计如果每个项目组各搞一套标准必然混乱。底座层把这些收编为统一服务业务团队在配置界面就能设置内容安全策略、敏感词过滤、数据脱敏规则而不需要自己研究安全算法。3. QuickBlue 的核心模块与设计思路讲了这么多理念下面落到具体设计。QuickBlue 在架构上分了五个核心模块每个模块我都结合我们实际踩坑的过程说说为什么这么设计。3.1 模型接入网关一切请求的总入口网关是底座的门面所有业务请求先到这里由它决定把请求转给哪个模型。设计上需要解决三件事协议标准化不同厂商的 API 格式差异很大网关统一转换成内部标准格式路由规则支持按业务线、按 Prompt 类型、按模型负载动态分发降级容错主模型超时或报错时自动切换到备用模型业务无感知。我们早期网关做得太薄只是做了个反向代理结果流量一大就暴露问题某业务线调用某个模型超时整个调用链都卡住。后来我们在网关层加了熔断和半开状态机制——连续失败超过阈值就熔断隔一段时间放少量流量探测恢复业务侧稳定性明显提升。3.2 数据与记忆服务给 AI 配上企业记忆大模型的参数知识是通用的但企业内部的制度、产品文档、历史工单模型一概不知。要让 AI 真正干好活必须给它提供企业内部知识。我们的做法是用 RAG检索增强生成架构配合向量数据库做知识库。这块设计时最容易忽略的是权限隔离。不同部门的知识库不能互相串不同职级的员工能问的内容范围也不一样。我们最初的版本没有做知识库级权限导致一个低权限账号能检索到核心业务文档的切片被安全团队打回来重做。后来在知识库服务里集成了文档级、切片级、用户级的三层权限控制才算过关。记忆服务则是另一种维度让 AI 记住用户偏好和历史操作。比如集团法务部门的同事每次审合同都要求标注风险等级和修改建议模板第二次来问时系统直接沿用上次的风格。这种用户画像级的长期记忆需要独立于模型的存储服务来维护否则换个模型记忆全没了。3.3 智能体编排引擎把大任务拆给多个 AI 协作这是 QuickBlue 里最复杂也最核心的模块。所谓AI Agent就是一个能自主规划步骤、调用工具、根据反馈调整方案的智能体。但单 Agent 能力再强面对大型任务也容易迷失。我们更推荐多 Agent 协作模式。以合同审查为例我们在底座上编排了三个 Agent条款审查 Agent负责识别合同里的风险条款合规比对 Agent负责把条款与企业合规清单比对建议生成 Agent负责汇总前两者的结果生成修改建议。编排引擎负责管理它们的执行顺序、传递中间结果、处理失败重试。这里的关键设计是任务分解与状态管理。我们踩过一个坑Agent 之间传递的上下文太大导致接口超时和费用飙升。后来规定每个 Agent 的输入输出必须经过摘要器压缩一轮上下文控制在 2000 token 以内问题才解决。3.4 安全与审计底线能力不能再靠运气企业里的 AI 应用生成内容必须过得了一双合规的眼睛。我们在底座里内置了内容安全巡检所有模型输出在返回给用户前都会经过一层规则加模型的联合审核。审计日志也是刚需。我们要求每一次 AI 调用都记录完整的调用链包括输入、输出、用的哪个模型、调用了哪些工具、命中了哪些知识库。有一次业务方反馈 AI 给客户承诺了不存在的优惠正是靠审计日志还原了全过程确认是 Prompt 设计缺陷导致的快速修正了模板。3.5 测试与可观测性让 AI 应用的迭代不再是玄学传统软件的测试是断言明确的AI 应用的测试天然带有不确定性。同一个 Prompt模型上一秒和下一秒的输出可能不同。我们在底座里建立了两套机制评测集回归沉淀一批高质量测试用例每次更换模型或调整 Prompt 后自动跑一遍输出质量、响应时间、成本消耗全部量化对比调用链追踪从用户请求入口到模型响应出口全链路 Trace哪个环节慢、哪个 Agent 出错、哪次调用幻觉了一目了然。这两块建设投入不小但长远看是让 AI 应用从能跑走向能迭代的核心保障。4. 实操视角在 QuickBlue 上搭建一个合同审查 Agent理论说了不少直接上一段实操。我们以搭建一个合同审查 Agent 为例把从注册到上线的完整路径走一遍。这套流程是我们在多个项目上反复打磨出来的照着做基本能避掉大部分初级坑。4.1 第一步接入模型与配置路由在 QuickBlue 控制台创建项目后第一件事是配置模型接入。我们通常会注册两个模型一个主力模型负责复杂推理一个轻量模型负责前置分类。关键参数是路由优先级和超时时间。我们实际配置如下参数推荐值说明主力模型超时30 秒复杂推理任务需要更多时间但超过 30 秒大概率是死循环直接熔断轻量模型超时8 秒分类任务响应必须快否则用户体感很差路由优先级主用 - 降级主模型失败后自动降级到备用模型温度temperature0.2合同审查场景要求确定性温度太高会乱编这里特别强调一下合同审查这类任务温度一定要调低。我们最初按通用对话场景设了 0.7结果 AI 反复把补偿条款脑补成惩罚性条款差点让商务团队在谈判中出岔子。温度控制在 0.2 以下后幻觉概率明显下降。4.2 第二步搭建知识库与权限体系在知识库模块中上传企业的历史合同样本、合同模板库、合规审查清单。注意上传的文档最好是结构化程度较高的版本纯扫描件或排版混乱的 PDF召回效果会差一大截。我们走过弯路上传了大量未清洗的原始扫描件向量化之后召回准确率惨不忍睹。后来花钱做了一道 OCR 和格式清洗流程把文档统一转成 Markdown再加Metadata 标签合同类型、适用业务线、生效状态检索精度直接翻倍。知识库建好后立刻配置权限。法务组的 Agent 服务账号挂全部可见角色业务部门的 Agent 服务账号挂仅本业务线可见角色。这一步千万不要图省事权限出问题是安全事故级别的。4.3 第三步编排多 Agent 协作流程在编排引擎里画一条流水线配置化实现不写代码识别合同类型轻量模型判断是采购合同、销售合同还是劳务合同抽取关键条款主力模型从合同文本中提取付款、交付、违约、保密等核心条款合规比对主力模型 知识库检索将条款与知识库中的审查规则逐个比对标记风险等级生成审查报告主力模型汇总风险点输出结构化的修改建议文档。这四条任务之间需要传递上下文。我们用底座的变量通道功能定义了两个共享变量关键条款列表和风险清单。前一个 Agent 的输出自动写入变量后一个 Agent 从变量读取这样既解耦又便于追溯。4.4 第四步上线前的评测与灰度上线前必须跑一遍评测集。我们准备了 50 份历史合同其中 30 份是有明确结论的历史案例20 份是新增测试样本。底座会自动跑批量评测输出风险条款召回率我们要求大于 90%误报率我们要求低于 10%平均响应时长我们要求在 15 秒以内单次调用成本我们要求控制在 0.5 元以内。评测通过后先灰度到法务部 5 个人试点一周。灰度期间重点盯两个东西AI 输出的报告被人工修改的比率以及用户主动反馈的异常。这周积累了 200 多条真实反馈筛选出三个 Prompt 模板的重灾区全部优化后再全量上线。5. 常见问题与排查技巧实录最后分享我们运维快半年来最常遇到的问题和排查思路很多是文档里不会写的实战经验。5.1 模型幻觉怎么防最头疼的问题。我们的排查顺序是这样的先确认温度参数是否为默认的偏高状态再查 Prompt 是否给了模型足够明确的约束最后看知识库召回是否引入了噪音内容。实操中让模型在拿不准时说不知道这条指令写进 Prompt 的 System 层比什么都管用。5.2 知识库召回率低怎么优化先查文档清洗质量再看 Embedding 模型是否和文档语言匹配最后看查询语句是否过于口语化。我们内部的收益排行是文档清洗收益最大贡献了 70% 的提升更换更高维度的 Embedding 模型贡献 20%改写查询语句贡献 10%。5.3 多 Agent 协作时任务总是超时大部分情况是某一个 Agent 上游输入太大导致下游处理变慢。我们的解决方法是在每个 Agent 之间加摘要器压缩上下文同时把超时时间按 Agent 类型分别设置不要让一个全局超时值拖垮所有环节。还有一招比较土但很有用给每个 Agent 加一个最大重试次数超过就跳过并标记异常不要让错误无限传播。5.4 并发上来之后延迟飙升担心底座扛不住其实大部分瓶颈出现在知识库检索。我们后来给向量检索加了两级缓存——热数据走 Redis 缓存温数据走向量库冷数据直接下推到对象存储。效果是高峰期 P95 延迟从 8 秒降到 2 秒以内。5.5 成本怎么控制底座提供的成本看板是我们最常用的功能。按业务线、按模型、按 Agent 类型三个维度看消耗。发现某条业务线的调用量异常高点进去一看原来是巡检脚本在非高峰期跑批量测试关掉定时任务就省了 30% 的费用。我个人在做这个底座时最深的体会是底座的本质不是炫技而是把 AI 应用开发中最脏最累的共性活接走。考验的不是某一个单点的技术深度而是把所有环节串起来的能力。如果你所在的企业也在认真考虑规模化落地 AI 应用不妨从梳理自己的共性负担开始——哪些事情每个 AI 项目都要做一遍把这些抽出来你就找到了自己的底座边界。先用起来再逐步完善这条路我用半年时间验证过值得走。