从去年开始我明显感觉大家聊 AI 的方式变了。前年还在问怎么调大模型的 API去年开始问怎么让 AI Agent 别乱跑今年问得最多的变成了我们到底要不要搞一套 AI 应用底座还是继续让每个项目组各搞各的。这个问题正好就落在 QuickBlue 这类方案要回答的核心上。QuickBlue 不是一个你下载完就能用的软件而是一种把模型、Agent、知识库、权限、可观测性统一沉淀成企业基础设施的工程化思路。这篇文章我想用我自己在几个项目里实际搭建、改造这套底座的经验把AI 应用底座到底是什么、企业为什么需要它、以及踩过哪些坑一次讲透。1. 先搞清楚一件事AI 应用底座到底解决什么问题1.1 没有底座的时候AI 项目为什么越做越痛苦我带过一个典型的 AI 客服项目当时为了赶进度每个研发小组各自对接大模型服务。A 组用了厂商 A 的接口B 组用了厂商 B 的接口C 组图省事直接在业务代码里拼 prompt。三个月后项目进入联调期问题开始集中爆发。首先是接口协议不统一。厂商 A 的消息格式是messages数组厂商 B 是input加parametersC 组自己封装了一层又把数据结构改了。每次排查问题光是把请求从业务层追踪到模型层就要花半天。其次是权限和成本没法管控任何一个人拿到 API Key 就能调模型月底账单出来根本不知道哪个业务线烧的钱。更麻烦的是AI 的行为完全不可观测用户问了一句莫名其妙的话客服 AI 绕了八个来回你连它中间做过哪些工具调用都看不到只能靠用户截图反馈。这种状态的本质是没有把 AI 能力当成一种基础设施来管理。就像你公司不会让每个部门自己拉一条宽带、自己买服务器而是统一走 IT 的网络和机房。AI 应用底座做的就是这件事的智能化版本只不过这一次要统一的不只是网络还有模型路由、上下文管理、Agent 编排、安全护栏和费用计量。1.2 底座在技术栈里处于哪一层很多人会把 AI 应用底座和低代码平台AI 开发框架混为一谈实际上它们的位置完全不同。我习惯把 AI 技术栈分成四层。最底下是算力层包括 GPU 集群、推理服务这些往上一层是模型层包括开源模型、商业模型 API再往上是底座层也就是 QuickBlue 这类东西主要落位的区域最上面才是业务应用层比如客服机器人、AI 编程助手、营销内容生成工具。底座层的关键作用是屏蔽掉下面两层的复杂性。业务研发在面对大模型时不需要关心底层用的 Llama 还是 GPT或者某个国产模型也不需要通过写一堆胶水代码去拼接模型接口。他就只需要声明一句我要调用摘要能力底座会自动路由到当前最便宜、最快、效果达标的模型并处理好重试、降级、流式返回和审计日志。这里也顺便解释一个很多初学者困惑的问题为什么豆包的 API 请求格式是input而不是 OpenAl 风格的message其实没有谁对谁错模型厂商各自定义协议是很正常的事OpenAl 本身也不是行业标准。一个成熟的 AI 应用底座在架构设计时就要把协议差异吃掉让上层永远面对统一的内部规范。你可以把底座理解为电源插座转换头不管电从哪来、电压是多少业务侧插上去就能用。1.3 QuickBlue 和常规低代码平台的关键差异低代码平台解决的是让业务人员也能做表单和流程AI 应用底座的关注点完全不在界面交互而在智能化链路的稳定性。QuickBlue 这类底座一般会包含几个能力模型网关、Agent 运行时、知识库接入、评测与可观测性、安全与权限控制、费用治理。这些能力有一个共同特点都对业务不具备直接价值但没有它们AI 业务就撑不住规模。这跟水电煤很像你不会因为水龙头好看而选择自来水厂你只关心它能不能持续供水、水价稳不稳定、爆管时能不能快速修复。AI 底座就是这个水厂它越透明上层的业务跑得就越稳。2. 为什么企业需要它从能跑 Demo到扛得住生产2.1 AI 应用真实落地中的连环问题我见过太多团队陷在同一个循环里Demo 阶段感觉大模型无所不能一上生产就处处受挫。第一个瓶颈是并发。业务量上来以后模型供应商的限流策略立刻生效如果没有统一的路由层做请求分发和排队应用就直接返回限流报错。第二个瓶颈是 Agent 失控多步骤任务里模型偶尔会陷入死循环或者调用了一个本来不该调用的工具这时候没有一个底座层的熔断机制事故几乎是必然。还有一块是被很多人低估的上下文与幻觉治理。AI 应用不是一个独立程序它要读知识库、要看历史对话、要参考业务数据。没有统一的知识接入和上下文截断策略每个研发都在自己拼 prompt结果同一批数据在 A 模块能回答正确在 B 模块就张冠李戴。这些问题不来源于某一个模型的好坏而是来源于工程化能力的缺失。2.2 底座带来的不是技术便利而是组织效率如果你只是三五个人做个演示项目确实不需要底座直接调 API 就行。一旦企业有多个业务线同时使用 AI问题就变成了组织级的谁有权限调用哪个模型预算如何分摊提示词和数据集如何沉淀为公司的资产Agent 的行为如何审计我举个实测的例子。我们曾在一个相对较大的团队里做 AI 编程辅助最开始每个工程师自己配模型、自己写提示词模板、自己决定是否把代码片段发给模型。结果一个月后代码仓库里出现大量风格不一致的 AI 生成代码而且有人误把内部接口文档贴给在线模型。后来我们把所有 AI 能力收敛到底座上由底座统一决定哪些数据可以出域、哪些 prompt 模板经过审核、哪些模型只能在特定环境使用。这一层收敛之后研发效率反而提升了因为团队成员不再需要纠结底层怎么跑。底座还能明显降低新人的上手成本。一个新同学加入团队不需要读一遍所有模型 API 文档只需要看底座的使用规范。这就很像你自己家里装修好了水电新住户只用拧开龙头就能用水而不用去研究自来水厂怎么净化。2.3 决策参考什么样的企业该上底座结合我自己的经验给一个非常主观但真实的判断标准。如果你公司同时满足这三条就要认真考虑引入底座了第一至少三个业务线或三个产品在用大模型能力第二每个月有大模型 API 消费但说不清楚钱花在哪个功能上第三出现过因模型限流或行为失控导致线上故障。如果只满足一条比如只是做了一个内部知识问答工具那先不要搞底座继续用轻量方案就好。底座本身是要投入的它省的是规模上去之后的钱和管理成本而不是省小团队的一次性开发成本。很多企业犯的错是业务才跑通一个 Demo 就急着组织团队自研底座结果底座做得比业务还重最后拖垮了整个节奏。3. 底座的核心构成像水电煤一样的能力分层3.1 模型网关统一入口与自动容灾模型网关是整个底座的第一个模块它要解决的问题通俗讲就是上游断了我得换条路。在底座架构里网关负责接收所有模型调用请求然后按照策略把请求转发到不同供应商。策略可能包含优先级规则、成本阈值、延迟要求、地域合规要求。我在实现网关时最看重的是优雅降级能力。比如你的业务默认使用模型 A但 A 的某个区域节点超时了网关应该自动把流量切换到模型 B并且只增加一百毫秒左右的延迟用户几乎无感知。切换不是简单换一个 API还要处理上下文格式转换、部分能力差异比如 A 支持 JSON 结构化输出而 B 不支持。所以网关内部的所有请求都会被转换成一套统一的内部数据结构再针对不同供应商做适配。再强调一次协议统一是非常重要的设计决策。如果你们选择自研底座第一件事就要定义好内部请求规范不要直接把 OpenAI 的messages格式当作标准因为那个格式只适合 OpenAI。我做项目时的做法是定义一个通用的LLMRequest它包含messages、tools、parameters和context字段再由适配层转换为不同厂商的格式这样后续接入任何新模型都是插件式扩展。3.2 Agent 运行时并发控制与行为约束Agent 是当前底座中最活跃的部分也是最容易出问题的地方。Agent 运行时负责的事情有点像一个监工它要给每个 Agent 限定最大执行步数、工具调用次数、单次运行的最长耗时还要处理多 Agent 之间的协作与消息传递。我踩过一次很典型的坑当时做了一个多 Agent 协作的调研机器人让信息搜索 Agent把结果传给报告写作 Agent。因为没给运行时限结果搜索 Agent 在某个数据源里陷入了循环连续调用了上百次搜索工具既产生了巨额费用又迟迟没有返回。后来我在运行时里加了max_iterations和单步超时时间并且设置了一个运行沙盒让每个 Agent 执行完必须汇报当前状态由父 Agent 决定是继续还是结束。Agent 并发的处理同样不能靠简单的线程池。因为 Agent 会调用外部工具比如查询数据库、调用 HTTP 接口如果并发数设置过高下游系统可能被打爆。我在底座里通常会实现一个信号量机制对不同优先级的任务做限流白屏用户直接交互的请求优先级最高后台批处理任务限制并发数到个位数。这个策略跟数据库连接池很像核心思想是底层资源永远不能被上层把配额占满。3.3 知识接入与上下文管理策略一个企业级 AI 应用没有知识库的底座是空心底座。但知识接入不只是一个向量数据库那么简单它涉及数据接入、切分、权限过滤和召回策略等很多细节。我建议把知识层拆成三个子模块离线索引、在线召回、权限过滤。离线索引负责把企业内部的文档清洗、切片、向量化。这一环的高频问题是切片大小怎么定太小了语义不完整太大了检索召回不准。我的经验是先按标题和段落结构预切再根据 token 数做二次合并通常控制在 300 到 800 个 token 之间比较稳妥。在线召回要考虑查询改写也就是用户问上个月退货率系统先改写成退货率 上个月 统计报告再去向量库检索召回效果会好很多。权限过滤是很多团队容易忘的知识库里同时存了不同部门的数据如果权限不过滤AI 会把不该说的也说了这是合规层面的隐患。上下文管理则是另一个看不见的角落。对话型 AI 应用需要把历史记录送进模型但历史太长了既浪费 token又拖慢响应。我的习惯是在底座里做滑动窗口 关键信息提取。滑动窗口保留最近几轮对话同时从历史中提取用户偏好、业务参数等结构化信息穿插到系统提示词里。这样做能让模型既记住重点又不会因为信息过载而答非所问。3.4 可观测性、评估与成本治理最后这项我把它看作是底座里最不性感但最值钱的部分。AI 应用的可观测性绝对不能只停留在记录一条日志的层面。你需要记录每次请求的输入输出、模型名称、token 消耗、延迟、工具调用链、评分结果还要能把一次完整的 Agent 运行过程像调用链一样还原出来。我们在底座里给每一次请求分配了一个trace_id从用户进入应用开始到底座转发模型、调用工具、再到返回所有环节都打上这个 ID。排查为什么这个回答这么奇怪的时候只要搜 trace_id就能看到模型当时得到了什么上下文、做过哪些工具调用不需要靠猜。评估模块是基于底座的 AI 应用特有的需求。传统软件测试只验证逻辑分支AI 应用的输出没法用对错衡量。我的方案是引入多层评估第一层用规则检查是否包含敏感词或关键事实第二层用一个小模型给大模型的输出打分比如相关性、忠实度第三层在线上抽流量做人工盲评。每一轮模型升级都要先跑一遍评估集分数不达标就直接自动回退。成本治理就更直接了底座统一记录每个调用方消耗的 token 与费用分摊到业务线月底财务不再需要对着供应商账单发呆系统里导出来就是一张成本报表。4. 亲自动手搭一套轻量底座关键路径与避坑指南4.1 最小可用模型网关的代码骨架很多团队问我的第一个问题是底座要自己写还是买我的回答是建议先自己写一个 300 行的最小模型网关把核心机制跑通再看要不要引入商业方案。因为只有自己写过一遍你才知道重点在哪里后面评审采购方案时也更有判断力。一个最小可用的网关至少包含三件事多供应商注册、统一请求格式、自动重试与降级。下面这个 Python 代码是我做过的一个简化版本核心思路很直接。import time import random from dataclasses import dataclass, field dataclass class LLMRequest: messages: list tools: list field(default_factorylist) temperature: float 0.3 max_tokens: int 1024 dataclass class LLMResponse: content: str model: str usage: dict class ModelProvider: def __init__(self, name, client, priority, is_fallbackFalse): self.name name self.client client self.priority priority self.is_fallback is_fallback def call(self, req: LLMRequest): # 适配层把 LLMRequest 转成厂商格式 return self.client.chat(req) class ModelGateway: def __init__(self, providers): self.providers sorted(providers, keylambda p: p.priority) def complete(self, req: LLMRequest, max_retries2): last_error None for attempt in range(max_retries 1): for provider in self.providers: if provider.is_fallback: req.temperature min(req.temperature, 0.0) try: return provider.call(req) except RateLimitError: wait min(2 ** attempt random.uniform(0, 1), 8) time.sleep(wait) last_error RateLimitError(provider.name) continue except TimeoutError: last_error TimeoutError(provider.name) continue raise last_error这段代码的核心不是功能完整而是让你理解底层机制每次请求都先尝试主模型主模型限流或超时就自动切换备用模型同时按指数退避策略做重试。当然生产级网关要复杂得多要加熔断、健康检查、token 计费、审计日志但骨架逻辑是一致的。4.2 一次 Agent 工作流的声明式配置实践用代码写 Agent 逻辑最大的问题是每新增一个场景都要改代码。我更喜欢把 Agent 的编排规则做成声明式配置底座只负责解析业务团队只要写 YAML 就能上线一个新助手。下面是我在生产环境用过的配置简化版agent: name: customer_triage_assistant description: 客服分流助手识别用户意图并生成处理建议 model: primary: gpt-4o-like fallback_chain: [fast_local_model, cheap_online_model] temperature: 0.2 max_tokens: 2048 tools: - name: query_order_status max_calls_per_run: 3 - name: search_knowledge_base max_calls_per_run: 5 - name: escalate_to_human max_calls_per_run: 1 control: max_iterations: 8 timeout_seconds: 30 concurrent_limit: 20 guardrails: - refuse_prompt_injection - sensitive_data_detection - domain_chat_off_topic_check这种配置文件的价值在于你在底座层统一了解了所有 Agent 的脾气。比如concurrent_limit: 20就是告诉底座这个 Agent 同一时间最多允许 20 个实例运行超过的部分就排队等待。max_iterations: 8是防止 Agent 陷入死循环的最后一根保险丝无论模型怎么绕最多执行 8 步工具调用就会强制终止避免了我在前面说过的搜索 Agent 循环上百次那类事故。另外一个值得关注的字段是fallback_chain。它表示主模型挂了以后依次切换的模型顺序。我一般会配置一个延迟敏感的本体模型作为第一备选再加一个更廉价的在线模型作为兜底这样能保证即使在高负载下用户体验也不会退化为服务不可用。4.3 设置一个基础的评估回环评估是底座质保能力里的关键模块没有它你的底座没法判断一个模型升级到底是变好还是变坏了。一个基础的评估回环至少要覆盖三个环节离线回归、线上采样、人工盲评。离线回归的做法是维护一个几百条的评测集里面包含典型的用户问题、期望的回答要点、涉及知识库的事实。每次你要切换主模型或调整提示词时先用这个评测集跑一遍给每一条输出基于规则的打分比如是否包含关键实体是否拒绝了不该答的内容。分数低于设定阈值的直接终止上线流程。线上采样在这个基础上更进一步。模型在真实流量里跑出的输出用一个小模型自动打分并对得分低的结果打标签如果你有精力每天抽 20 条明显异常的结果做人工复核。这个机制投入不大但会给你极其宝贵的算法迭代依据。人工盲评则是把不同模型对同一批问题的回答随机打乱让人去看哪个更好。听起来很原始却是在大模型评测中最可靠的方法。最后把这些评分数据全部回流到底座的元数据库就形成了一条评测-迭代-回归的闭环。我见过很多团队省掉这一步直接上了新模型上线后用户反馈变差再回滚时间和口碑都损失了。4.4 为什么请求格式各不相同适配层到底在解决什么前面提到豆包这类服务使用input而不是messages这里展开说说。不同厂商的 API 设计在思路上分成两类一类是兼容 OpenAI 风格用messages数组承载对话历史另一类是自定义参数风格用input字段加parameters结构传参。豆包属于后者的代表它更强调把整个输入聚合起来再调用。如果没有适配层你在代码里每接一个新厂商都要改默认业务代码非常痛苦。适配层要做的事有两层一是请求适配把内部标准转换成该厂商所需的格式二是响应适配把厂商返回的结果统一处理成内部标准。这样做会让研发面对一个稳定的接口底层模型即使换了业务侧也不会感知。这里有一个容易被忽略的细节不同模型的参数命名差异很大。比如有的叫temperature有的叫top_p还有的叫randomness有的支持response_format指定 JSON有的只支持在提示词里强调。适配层建议把这些差异全部收敛针对每一种模型都写一份能力配置标明它支持哪些能力、不支持哪些能力。入口统一收敛的好处在迁移模型时体会特别深你只需要在配置中心改一行model: xxx后面所有兼容性和降级策略都自动生效。5. 常见问题与排查技巧实录5.1 模型供应商频繁限流怎么办这个问题几乎每个团队都会遇到。症状表现得很简单应用某个时段突然大量报 429 错误用户操作失败。排查时我们首先通过底座的可观测性看板确认是不是所有流量都到同一家供应商了然后看是不是某个 Agent 在短时间内引发了大量并发。解决策略有两条腿。一条是入口分流在网关层根据请求类型把流量分散到多个供应商比如摘要任务走模型 A对话任务走模型 B另一条是出口限速给每个业务方设置调用配额超过配额自动排队。最忌讳的方案是无脑重试因为重试会加剧上游压力反而让限流更严重。我们的做法是将重试改为指数退避配合随机抖动并且在连续失败时触发熔断直接降级到备用模型。5.2 Agent 在长时间运行后突然答非所问这个问题的根源九成在一层层堆叠的上下文里。一次性 Agent 运行的早期变量、中间工具返回的长文本都会占用上下文窗口到后面模型真正该关注的信息被挤出去了。你会看到 Agent 前几步还很清醒越往后越像是失忆了。我排查这类问题时的套路如下先用 trace 还原整个 Agent 运行的上下文快照计算每个步骤消耗的 token 数再定位是哪一步注入了一个超长文本。解决时我给工具返回值加了摘要策略超过 500 个 token 的返回结果先调用一次压缩模型做结构化提取只把关键信息传回给主 Agent。另外我会在系统提示词中动态注入一个当前任务的重点清单确保模型在上下文末段还能看到最该关注的目标这比依赖模型自己去理解一堆历史消息可靠得多。5.3 多个 Agent 协作时互相等待甚至死锁多 Agent 协作的坑不是每个团队一开始就会踩到但只要一踩往往特别隐蔽。症状是业务任务卡在某一步长时间不返回但 CPU 占用不高日志里也没有报错。死锁的本质是 A Agent 在等待 B Agent 的结果而 B Agent 又在等待 A Agent 释放某个信号量。拿我前面的多 Agent 调研机器人为例信息搜索 Agent 写结果的时候报告 Agent 正在等它的输出而搜索 Agent 调用的查询接口又被报告 Agent 占用了连接池的资源两个 Agent 就僵住了。解决这个问题我只用了两个手段。第一全局规定 Agent 之间的调用只能通过消息队列传递不允许共享线程或连接资源。第二给每一次协作调用都设置强制超时超时后父任务直接走分支逻辑要么使用已有结果要么标记失败给用户一个明确回应。死锁不会因为代码写得小心而消失它需要靠架构约束去消灭。5.4 多个模型混用时费用不可控混合使用多个模型之后费用问题会变得比之前更复杂。之前只用一家账单是单一来源最多看个总量。用了底座以后流量在多个模型之间自动路由费用分散如果不在底座层做预算控制月底一看可能远超预期。我们的做法是建立双层预算机制。第一层是全局预算在公司层面给底座设定月度 token 上限第二层是业务线预算每个调用方有一个独立配额不同业务线的配额可以不同。底座在路由选模型时会额外纳入一个成本权重也就是说只要效果达标优先选更便宜的模型。我们当时靠这个机制在业务量增长 30% 的情况下模型成本基本没变核心就是靠把高成本模型的使用率从 70% 压到了 20%。注意很多人以为模型路由越智能越好实际上成本最低和效果最好通常冲突。一个成熟的策略是给每个请求标记任务等级。高等级任务客户投诉、法务咨询优先保证效果低等级任务文案润色、摘要优先控制成本。不要试图对全量请求用一套策略那才是真正的土办法。6. 最后聊点个人体会做了这么多底座相关的项目我最大的一个感受是底座不是一上来就要做的东西但也不是等出了事才要做的东西。它应该在你第一次感到多个 AI 项目在重复造轮子的那一刻启动。启动的姿势也不要太贪心先做模型网关和可观测性这两块能立刻解决系统不可用、问题不可查两个最痛的痛点Agent 运行时和评估回环可以等应用形态再稳定一些再上。另外想分享一个有些反直觉的技巧自研底座时一定要抵抗封装一切的诱惑。底座层不要试图把所有 AI 能力都抽象掉尤其是涉及业务逻辑的提示词千万不要全部下沉到底座。否则每次业务调整提示词都要底座团队排期发布流程会变得很长。我们后来的做法是底座只提供能力原子和调用规范具体的业务提示词还是留在业务层由业务方自己维护。这个边界一旦划清两个团队的协作效率会高很多。最后别迷信任何现成的底座产品。QuickBlue 这类方案本质上提供的是一个脚手架的框架真正决定价值的是你愿不愿意在企业内部把模型、数据、权限和流程真正统一起来。单纯把底座装上去而不动组织上的协作方式它大概率会变成另一个吃灰的基础组件。先想清楚要解决谁的问题、管住哪些资源再选择合适的底座方案这才是企业落地 AI 应用底座的正确顺序。