企业官网建设流程全解析

1. 底座不是又一个中台：企业在焦虑的其实是这两件事

过去一年，我所在的团队一直在帮不同行业的企业做大模型落地，从制造、零售到金融。每次和客户技术负责人开会，前二十分钟大家还在兴致勃勃地聊模型效果，聊到第三十分钟气氛就开始微妙了——C TO问的最多的，往往不是"哪个模型更强"，而是"模型接进来了，然后呢？"然后这个词背后，藏着一整片没人提前规划的工程荒地。

1.1 模型能力过剩，工程能力严重不足

现在市面上的大模型，单论文本生成、逻辑推理、多模态理解，能力已经远远超出了绝大多数业务场景的实际需求。大多数企业内部的应用，用到的模型能力可能连 GPT-4 或者国产旗舰模型的 20% 都不到。但恰恰是这个"用不满"的状态，暴露了一个尴尬的事实：模型很强，但企业的工程系统很弱。

我见过不少企业，第一阶段的落地方式非常原始——某个业务部门自己找研发，直接调大模型的 API，写一段 Prompt 塞进去，返回结果解析出来，就算完成了。这种做法打几个内部小工具完全没问题，但一旦要认真做生产级应用，立刻会撞上一堆墙：

• 同一个 Prompt 散落在十几个项目的代码库里，改一段提示词要全局搜索替换
• 模型从 A 切换到 B，返回的 JSON 格式略有变化，所有对接方一起跟着改
• 知识库内容更新了，应用侧完全没有感知，模型还在用旧数据回答
• 一条链路涉及模型调用、向量检索、工具调用、Agent 多轮规划，线上出问题根本不知道是哪个环节挂了

这些问题单看每一个都不复杂，但叠在一起，就是一个典型的"分布式复杂性"。QuickBlue 这类产品盯住的就是这片区域——不是去比谁的模型更强，而是解决"模型接入之后，企业怎么把 AI 真正当作基础设施来运营"的问题。

1.2 从"调 API"到"治理一套系统"的鸿沟

说到底，企业需要一个 AI 应用底座，本质上是因为"调 API"和"治理一套系统"之间有一道巨大的鸿沟。单个 API 调用，是一次请求-响应的简单交互；而一套 AI 应用系统，是一个长周期的、不断演化的工程实体。

这个区分非常关键。我习惯用一个类比来解释：直接调 API 就像你在路边打出租车，车到了、上车、付钱、下车，过程很直接；而一套 AI 应用底座更像是一个城市的交通系统，你要考虑的不仅是"车能不能跑"，还要考虑路网怎么规划、红绿灯怎么协调、违章怎么处理、拥堵怎么疏导。

落到具体技术上，企业接入了大模型之后，真正需要治理的包括：模型路由策略（不同任务走不同模型）、上下文的存取与生命周期、知识库的更新与权限、Agent 工具的注册与调用规范、生成内容的审计与追溯、成本与延迟的观测。这些东西每一件都不性感，但没有一件是可以跳过的。

QuickBlue 为什么会被越来越多的人拿出来讨论？因为它把这一堆"不性感但绕不过去"的事情，收拢成了一个统一的底座，让上层应用不必各自为政。对于企业来说，这比多接一个模型 API 的诱惑力大得多。

2. 底座到底在管哪些事：QuickBlue 的能力边界拆解

聊清楚了"为什么需要"，接着就要回答"底座到底是什么"。很多企业一听"底座"两个字，第一反应是"是不是又要搞中台"。这是很自然的警觉。和过去那种包罗万象、动辄几百人维护的中台不同，AI 应用底座的核心职责是收窄的，本质上就三件事：接入、编排、治理。

2.1 接入层：一套协议把模型、知识、工具统一起来

接入层解决的是"万物互联"的问题。企业内部有不止一个大模型，有开源的、有商业的，有通用大模型、也有垂直行业微调过的；企业内部也有不止一个知识源，有 Wiki、有工单系统、有数据库、有对象存储里的文档；企业内部还有大量既有系统， ERP、CRM、工单平台、监控告警，这些系统里能操作的动作就是工具的雏形。

QuickBlue 的接入层做的事情，是给所有这些"能力提供方"定义了一套标准协议。模型也好、知识库也好、工具也好，只要按协议接入，上层应用就可以用统一的方式去调用，而不必关心背后的实现对不齐。

这套设计的好处是实实在在的。我见过一个客户，他们原本的 AI 应用里，大模型调用用了三家不同的 SDK，知识库检索自己写了两套逻辑，工具调用则是每个应用各自对接。到了要做统一权限管控的时候，差点把自己搞崩溃。后来迁移到底座模式，把模型统一走网关接入、知识统一挂到底座的知识服务上、工具统一注册成标准动作，才终于能做到一处配置、全局生效。

接入层的设计有一个关键细节必须提醒：协议定义得越薄越好。不要一上来就搞一个包罗万象的大协议，把模型输出格式、知识分块策略、工具参数 schema 全部焊死。一旦焊死，后面每个新接入方都会来找你诉苦。薄协议的意思是，你只定义最核心的交互契约（怎么鉴权、怎么传上下文、怎么返回结果、怎么报错），至于每个能力内部的实现细节，全部留给适配层去消化。

2.2 运行时：一个编排引擎承接 Agent 和业务流的"脏活"

接入层解决的是"能连上"的问题，运行时解决的是"怎么跑"的问题。今天企业里的 AI 应用，早就不再是简单的"输入 Prompt、输出文本"了。稍微复杂一点的业务场景，都会涉及到多轮对话、工具调用、知识检索、上下文管理等环节的组合。这就是 AI Agent 概念火起来的直接原因——当模型需要连续做决策、调用多个工具、携带长上下文的时候，纯粹的"一次调用"已经不够用了。

QuickBlue 的运行时，本质上就是一个为 AI 工作负载设计的编排引擎。它要处理的任务包括：

• 多轮会话的上下文管理：怎么把历史消息、检索到的知识片段、工具返回结果，组织成模型能理解的上下文窗口
• Agent 的规划与工具调度：模型决定下一步要调用哪个工具，底座负责把参数校验好、把调用发出去、把结果接回来重新喂给模型
• 条件分支与人工介入：某些高风险操作（比如对外发消息、改订单状态）需要设置审批节点，底座要能支持在 Agent 执行的路径上插入"人工确认"这一步
• 超时与重试策略：模型调用会有波动，工具调用可能失败，编排引擎需要定义好这些异常场景的兜底逻辑

我对运行时设计的建议是：宁可做得笨一点，也不要做得太灵活。编排引擎如果给了业务方过度自由的编排能力，最后一定会在线上环境里长出一大片不可维护的流程。底座的价值在于提供几个规范、稳定、可观测的编排范式，而不是让每个应用都 DIY 一套流程。

2.3 治理面：让 AI 应用可观测、可评测、可干预

接入和编排是底座"干活"的部分，治理是底座"负责"的部分。一个没有治理能力的底座，用不了多久就会失控。企业 AI 应用的治理，至少要看四个维度：

成本治理。大模型调用不是免费的，有的模型按 token 计费，有的按调用次数计费。如果不对模型路由做策略管控，一个内部小工具的日均调用成本可能高到让你怀疑人生。底座需要在接入层就做好"模型路由+配额管理"，给每个应用、每个部门设预算上限，超额自动告警甚至熔断。

可观测性。一次 AI 应用请求，从用户输入到最终返回，中间可能经过了模型调用、知识检索、工具调用、多轮 Agent 决策。任何一环出问题，最终表现都是"回答不对"或者"回答不了"。底座必须做全链路的 Trace，把一次请求的每一步都记录下来，包括模型输入输出了什么、检索到了哪些知识、工具调用耗时多少、哪一步触发了重试。

评测体系。这可能是最容易被忽略、但后劲最大的一块。模型是在持续升级的，底座接入的模型一变，上层应用的效果就可能波动。没有一套评测集，你就无法回答"换了模型之后，业务效果到底是变好了还是变差了"这个问题。建底座的时候，评测必须前置考虑进去，沉淀一套带标注的业务评测集，每次模型升级、Prompt 调整、知识库变更，都跑一遍回归。

安全与合规。内容安全审核、敏感信息过滤、权限隔离，这些在底座层面就应该是一次性做好的能力，而不是让每个上层应用各搞一套。特别是权限隔离，企业知识库里的内容是分密级的，底座的向量检索必须做到"什么人检索什么范围"，否则一个跨部门的知识问答应用上线，就是一场安全事故。

3. QuickBlue 在技术栈里的位置：和 LangChain、RAG、API 网关的分工

"底座到底包含哪些组件"这个问题，很多人在技术选型时都会纠结。原因在于，市面上能和"AI 应用底座"这个概念沾边的开源项目、商业产品实在太多了。LangChain 说自己是编排框架，向量数据库说自己是知识底座，API 网关说自己是模型接入层，每个都有点像，但又不完全是。

QuickBlue 的定位逻辑，我觉得可以这么理解：它更像是一个面向企业的 AI 应用运行时平台，把"模型接入、知识挂载、工具编排、可观测性、权限治理"这些能力内聚成一个整体，而不是某一个单一组件。

3.1 和 LangChain 这类编排框架的边界

LangChain 这类的开源框架，解决的是"开发者写 AI 逻辑"的便利性问题，它给你提供了一些链式调用、记忆封装、工具调用的代码模板。它的使用场景是开发者在代码里直接调用，粒度很细，灵活度很高。

但企业级底座需要考虑的很多事，LangChain 这类框架是不管的：比如多租户隔离、模型成本配额、链路追踪与审计、灰度发布与回滚、知识库的集中治理。你可以用 LangChain 写一个漂亮的应用，但你很难仅凭 LangChain 就把它变成一个多人协作、长期运营的平台。

QuickBlue 的编排引擎和 LangChain 并不矛盾。更常见的关系是：底座平台提供运行环境和治理能力，应用层开发者仍然可以用自己熟悉的开源框架去写应用逻辑，只是把模型的接入、知识的检索这些底层能力，替换成底座的统一标准接口。换句话说，框架解决的是"单次开发"的体验问题，底座解决的是"持续运营"的治理问题。

3.2 和 RAG 组件、向量数据库的边界

RAG（检索增强生成）是企业落地 AI 应用最常用的技术路线之一。一个典型的 RAG 流程包括：文档解析、分块、向量化入库、检索召回、重排、拼接 Prompt。向量数据库在其中的角色，是负责向量的存储和近似最近邻检索。

QuickBlue 这类底座不会去替代向量数据库，它做的是把 RAG 的全流程"平台化"。底座里的知识库服务，会统一管理文档的接入、解析、分块策略、向量化模型、检索参数和权限过滤规则。业务方不用关心背后的知识库是如何构建的、向量是在哪个库里存的、检索用的什么模型，只需要面对一个简单的接口：给我一段问题，我还你一批相关片段。

这个"平台化"的价值在于，当企业内部有几十个应用都要挂知识库能力的时候，你不会看到几十套不同的 RAG 实现在并行运行、各自维护。底座把"知识接入-检索-权限"这条链路统一起来，知识运营团队只需要在一个地方维护知识资产，所有应用自动生效。

3.3 和 API 网关的区别：底座不是挡在模型前面的一个 Proxy

有人会觉得，底座不就是一个模型网关吗，把大模型的 API 统一代理一下，做做鉴权和限流。这个理解偏了。API 网关解决的是南北向流量的管控问题，模型 API 网关本质上还是一个 Proxy，只是把请求转发到上游模型服务。

底座做的是更多的事。举个例子：同样是"让 AI 调用一个工具"，API 网关模式下，你要自己写工具调用的逻辑，自己管理工具返回结果的上下文拼接；在底座模式下，工具是注册在底座上的，Agent 规划引擎会自动决定调用哪个工具，底座负责参数校验、调用执行、结果回填、全程留痕。这已经是"应用运行平台"的范畴，不是一个网关能覆盖的。

所以，如果企业已经有了成熟的 API 网关，底座是可以和它共存协作的。API 网关负责南北向的流量治理，底座负责 AI 应用内部的编排与治理。两者管的东西不一样，放在一起用并不冲突。

4. 在企业里落地底座，最容易翻车的四个地方

我认为所有的架构问题，最后都要落到"落地"上来检验。底座这个概念听起来很合理，但真正在企业里推的时候，会遇到非常具体的阻碍。我把见过的高频翻车点整理成四个，每一个都是真实踩过的。

4.1 接口规范一开始不定，后面全是接口对齐的噩梦

底座要接入模型、知识、工具，就得定义接口规范。最大的坑是：底座团队为了"快速响应业务需求"，一开始没有把接口规范定清楚，而是给每个业务方单独拉了一条自定义通道。结果半年之后，底座同时维护着五六种风格迥异的接入方式，每个新来的工程师都要看一遍不同的代码才能接进去。

我的建议是，底座的第一条纪律就是"规范面前人人平等"。模型接入有统一的模型服务接口，工具注册有统一的工具协议，知识挂载有统一的知识服务接口。业务方的个性化需求，可以在规范允许的范围内做扩展，但不能绕过规范另起炉灶。哪怕前期慢一点，这个底线不能松。

顺带说一下接口设计里一个容易忽略的点：错误码体系一定要从第一天开始定义清楚。AI 应用里最磨人的问题不是"系统挂了"，而是"系统没挂，但返回了一堆语义不明的错误"。模型超时、上下文超长、知识库无权限、工具参数校验失败、内容安全拦截，这些都应该是清晰的错误码，而不是一个笼统的 500。错误码不清晰的底座，后面做排查的时候会消耗掉整个团队的耐心。

4.2 知识库权限跟着业务权限走，否则隔离就是摆设

知识库是底座能力里最敏感的部分。很多企业落底座，前期业务线跑得好好的，一到跨部门共享知识库的时候，权限问题就爆发了。销售部的应用，回答中带出了研发部的内部技术细节；客服部的知识问答，引用了财务部未公开的流程文档。这些问题一旦出现，不只是技术事故，还是管理事故。

解决方案说起来简单：知识库的权限体系必须和企业的组织架构、业务系统权限打通，而不是在底座里独立维护一套。也就是说，用户通过底座访问知识库内容时，答案里能引用哪些知识片段，取决于这个用户在业务系统里的角色和权限，而不是取决于知识库本身的可见范围。这个打通的工作量比想象中大，因为它意味着底座的向量检索必须在上游做权限过滤，而且过滤逻辑要能跟着用户身份动态变化。

我在实践中的做法是，知识库接入时，每一个知识源都必须声明它的可见范围（哪些组织、哪些角色可见），检索结果的召回阶段就完成权限裁剪，而不是放在最后生成答案之后再过滤。后者一是浪费算力，二是存在信息泄露的风险。凡是经历过一次线上权限事故的团队，都会明白这一条的价值。

4.3 评测体系不前置，后面要付出十倍代价去补

很多团队做 AI 应用的时候，节奏是这样的：功能开发的很快，Prompt 调一调、示例跑一跑，感觉效果不错，就上线了。上线的第一个月都挺好，第二个月模型升级，或者知识库内容大改，效果立刻波动。这个时候你才发现，没有任何一套评测集能回答"现在的效果比上个月差多少"。

评测体系前置建设，是底座落地里性价比最高的一件事。不需要一开始就做得很重，只需要沉淀两个东西：一个带标注的评测问题集，一份覆盖核心场景的评测跑批脚本。每个业务方在底座的评测模块里提交自己场景的评测用例，模型路由变更、知识库更新、Prompt 调整都要触发一次回归评测。这样做的直接效果是，你永远知道线上效果变化的"原因"在哪里。

这里我要提一个常被忽略的细节：评测集不是一次建好就一劳永逸的，它要跟着业务演化持续扩充。尤其是 Agent 类应用，评测的不光是"最终回答对不对"，还有"中间的工具调用决策对不对"、"无效调用多不多"、"拒绝不该执行的操作时是否得体"。这类交互过程的评测，比单轮的问答评测复杂得多，但价值也大得多。

4.4 底座上线后，先要搞清楚的不是"谁最强"，而是"谁来兜底"

底座这个东西有一个很特殊的地方：它一旦运行起来，几乎所有 AI 应用都跑在它上面，那它就是整个 AI 体系的"关键路径"。关键路径意味着，任何一个环节的抖动，都会被放大到全平台。这在落地推行的初期，会带来非常现实的阻力。

我记得在一个项目里，底座刚上线那阵子，模型路由偶尔超时，导致某个业务方的应用响应变慢。业务方第一反应不是排查底座，而是直接质疑"为什么要多穿一层"。这个问题非常典型——当底座不能带来立竿见影的业务增量时，它带来的"额外延迟"就是原罪。

应对这个问题的思路，是要在底座设计阶段就给性能留好裕量。比如模型调用的超时设置、重试机制、缓存策略，这些底座自身的能力要非常扎实。同时要在组织上明确"底座团队"的职责边界和响应机制。底座团队不是做了平台就撒手不管，而是要成为所有 AI 应用出问题时的兜底方。第一次线上事故发生的时候，底座团队能不能在最短时间内定位到是模型问题、知识问题还是工具问题，这个体验决定了业务方对底座的信任度。

5. 一个底座在三个月内的落地节奏参考

我没有办法给出一个适用于所有企业的通用实施方案，但可以分享一个我认为行之有效的落地节奏。这个节奏的核心思想是：底座不是一步到位的，而是在与业务应用共同演进中逐步成型。

5.1 第一个月：跑通三条影子链路，先不接真实流量

第一个月不建议一上来就搞大的平台建设，而是选三个最有代表性的业务场景，做三条"影子链路"。影子链路的意思是，业务的真实逻辑不变、真实数据不迁移，只在旁边并行跑一套基于底座的实现，用来验证底座的能力边界。

三条影子链路怎么选，要有讲究：

• 一条选典型的 RAG 问答场景，验证知识库接入、检索、权限隔离的链路是否顺畅
• 一条选轻量 Agent 场景（比如调用内部系统的数据查询工具），验证工具注册、规划调度、上下文管理的效果
• 一条选高并发场景的分析类应用，验证底座的性能储备和稳定性

这个月最重要的产出不是"功能上线"，而是把底座的接入规范、错误码体系、评测跑批脚本这三大件沉淀出来。这三件东西，往后所有的业务方接入都要基于它们。

5.2 第二个月：让业务方"无感"迁入，底座开始处理真实请求

影子链路验证没问题之后，第二个阶段就是让真实的业务应用迁到底座上。迁入的原则是"无感"，即对业务最终用户来说，应用的交互方式不变，但底层链路已经切换到底座在跑。

这个月要做的事集中在"规范化"上。所有迁入的应用，必须在底座上完成标准的接入注册：应用画像、模型路由策略、知识挂载范围、工具权限清单、日志与 Trace 等级。每一项都有对应的配置记录。这里我要强调一点，不要在这个阶段放任业务方保留"自己直连模型"的旧逻辑。旧的直连通道一天不关，底座就永远只是"一个可选的通道"，而不是"底下的地基"。

处理真实流量之后，前面提过的四个翻车点就会陆续暴露：接口规范、权限隔离、评测回归、性能兜底。这个阶段团队要做的就是快速接招、快速修坑。每一次线上问题，都是底座治理能力补全的机会。

5.3 第三个月：从"接入平台"走向"开发平台"

第二个月结束的时候，底座已经稳定承载了几个核心应用的流量。第三个月，底座的形态要开始发生变化——从"接入平台"走向"开发平台"。换句话说，不再只是业务方把现有应用迁进来，而是新应用可以基于底座的能力直接生长出来。

这个阶段需要补充的关键能力包括：面向开发者的自助接入文档与示例代码库、更细粒度的模型调用成本账单、评测集的自动化流水线。当业务方可以自助完成接入、自助跑评测、自助看成本的时候，底座就真正从一个项目变成了一个"产品"。

到了这一步，底座才算基本立住了。它不再是技术团队向外"推销"的一个平台，而是整个企业 AI 应用开发的事实标准——新应用先接底座，已经成了一个默认选项。

6. 最后一层体会：底座做的是"管道"和"容器"的活

我把 QuickBlue 这类 AI 应用底座想明白了之后，一个最大的感觉是：底座在技术体系里的角色，很像城市里的管道和容器——它不产生水，也不决定水要去哪里，但如果没有它，整个城市的水系统就是一团乱麻。

做底座的团队，心态上一定要甘于做"幕后工作"。底座做得好，业务方感知不到它的存在；底座做得不好，所有人都会第一时间感受到。这种"做得好是应该的，做得不好是要挨骂的"角色定位，确实劝退了一些团队。但我个人的体会是，恰恰是这种位置，决定了你在企业 AI 落地这件事上的不可替代性。模型会持续迭代，业务场景会持续变化，但底座的治理能力和工程规范，是随着时间在不断增值的。

最后再分享一个小经验：底座项目立项时，千万别急着和业务方谈"我能帮你做什么"，先和研发团队把"我们能沉淀什么公共能力"这件事聊透。底座的客户其实有两个，一个是业务方，另一个是研发团队自己。前者要的是业务增量，后者要的是可持续的工程效率。能把这两拨人的诉求同时照顾好，底座才真正立得住。