企业里做 AI 落地最怕的不是模型不够强而是每个业务线各自为战算法团队在 Notebook 里跑通了一个 Demo工程团队把它包成一个接口业务方用两周后发现效果不稳定回头一查——训练数据、提示词、知识库版本、调用链路全是散的没人说得清线上到底跑的是哪一版。这种局面下AI 中台这四个字才会被反复提起。它不是一个具体的开源项目也不是买一套软件就能解决的问题而是一套把模型、知识库、Agent、业务系统四层能力沉淀下来、复用出去的组织方式和技术架构。这篇内容面向的是正在或即将负责企业 AI 能力建设的工程师、架构师和技术管理者。我会把 AI 中台拆成四层来讲清楚模型层怎么管、知识库层怎么建、Agent 层怎么编排、业务系统怎么接。中间会穿插大量实际落地时的取舍逻辑和踩坑经验尤其是那些文档里不会写、只有真正跑过生产环境才知道的细节。如果你手上正有一个公司要做 AI 中台的任务或者你正在评估 Dify、RAGFlow 这类平台能不能直接拿来用这篇应该能帮你少走几个月的弯路。1. 先想清楚 AI 中台到底解决什么问题1.1 中台不是技术栈是能力复用机制很多人一上来就问AI 中台用什么框架搭这个问题本身就问偏了。中台的本质是能力复用技术栈只是实现手段。判断一个团队需不需要 AI 中台看一个指标就够了同一个能力比如根据文档回答问题是不是被三个以上业务线重复实现了。如果是那就有中台的价值如果只有一个业务在用硬搭中台纯属给自己找麻烦。我见过一个典型反面案例某公司业务线 A 用 LangChain 搭了套问答业务线 B 用 Dify 又搭了一套业务线 C 直接调大模型 API 硬写提示词。三套系统各自维护自己的知识库、各自的提示词、各自的评测集。结果大模型一升级三套系统全要改改完效果还不一致。这就是典型的没有中台的代价——不是不能做而是重复成本随业务线数量线性增长。AI 中台要解决的核心问题可以归纳成三条统一模型接入不管底层是 GPT、Claude、通义还是本地部署的开源模型上层业务只面对一套统一接口换模型不改业务代码。统一知识资产文档、FAQ、结构化数据统一入库、统一切分、统一检索避免每个业务各建一套知识库。统一编排与治理Agent 的流程、工具调用、权限、审计、限流都在中台层管控业务方只关心自己的业务逻辑。1.2 四层架构的分工边界把 AI 中台拆成四层是我实践下来最清晰的分法层级核心职责典型组件面向对象模型层模型接入、路由、推理、微调模型网关、推理服务、微调平台算法/平台团队知识库层文档解析、切分、向量化、检索向量库、Embedding、Rerank知识运营/业务Agent 层流程编排、工具调用、记忆管理编排引擎、工具注册中心应用开发团队业务系统层具体场景落地、权限、UI各业务应用、API 网关业务方这四层的边界不是绝对的但职责必须清晰。最常见的错误是把知识库逻辑写进 Agent 里或者把业务权限判断塞进模型网关。一旦边界模糊后面任何一层要升级都会牵一发动全身。提示分层的目的不是画架构图好看而是让每一层可以独立演进。模型层换供应商时知识库和 Agent 层不应该感知到变化知识库换向量库时业务系统不应该改代码。做不到这一点说明分层没做到位。1.3 什么阶段该上中台什么阶段不该我的经验判断标准是这样的1-2 个 AI 场景别搞中台直接快速迭代把场景跑通最重要。3-5 个场景且开始重复造轮子开始抽象公共能力但保持轻量别过度设计。5 个以上场景或跨部门协作正式建中台投入专职团队。过早建中台是创业公司最常见的死法之一。中台本身不产生业务价值它只是降低边际成本。如果业务量还没起来中台的固定成本反而会拖垮团队。我见过一个二十人的团队花三个月搭了套企业级 AI 中台结果上面只跑了一个客服问答场景投入产出比惨不忍睹。2. 模型层统一接入比选哪个模型更重要2.1 模型网关是整个中台的咽喉模型层最核心的组件是模型网关。它的作用类似微服务架构里的 API Gateway但专门针对大模型调用场景做了优化。一个合格的模型网关至少要解决这几件事协议统一把 OpenAI 格式、各家私有格式、本地推理服务的格式统一成一套内部协议。路由与降级根据请求特征长度、任务类型、成本预算路由到不同模型主模型挂了自动切备用。限流与配额按业务线、按用户维度限流防止某个业务把额度跑爆。可观测记录每次调用的 token 数、延迟、成本、成功率这是后面做成本优化的基础。为什么强调协议统一因为大模型生态变化太快了。今天用 GPT-4明天可能因为成本换成国产模型后天某个场景又要用本地部署的开源模型。如果业务代码直接写死了某家的 SDK每次换模型都是一次重构。有了网关业务方只调内部统一接口换模型只是网关配置的改动。2.2 模型选型的实际决策逻辑选模型不是选最强的而是选最合适的。我一般按这个顺序决策任务类型需要复杂推理的如多步 Agent用强模型简单分类、抽取用轻量模型。数据合规涉及敏感数据的场景优先本地部署开源模型。成本预算算清楚每千次调用的成本高频场景必须用便宜模型。延迟要求实时交互场景对首 token 延迟敏感批处理场景无所谓。稳定性商用 API 有 SLA本地部署要自己保证可用性。这里有个反直觉的结论大部分企业场景不需要最强的模型。我做过统计一个典型的企业知识问答场景用中等能力的模型 好的 RAG 检索效果往往比用最强模型 差检索要好。因为答案质量的天花板往往在检索环节而不是生成环节。2.3 本地部署与云 API 的混合策略成熟的中台通常是混合的核心敏感场景本地部署通用场景用云 API。本地部署这块GPU 资源调度是难点。我推荐用 GPUStack 这类工具做本地模型的统一管理它能帮你把多张卡的资源池化按需分配模型实例。本地部署最容易踩的坑是显存估算。很多人按模型参数量简单估算结果一跑就 OOM。实际显存占用大致是显存 ≈ 参数量 × 精度字节数 × 1.2KV Cache 和中间激活的开销比如 7B 模型用 FP16大约需要 7 × 2 × 1.2 ≈ 17GB。如果用 INT8 量化能降到 9GB 左右。但注意上下文长度会显著影响 KV Cache长上下文场景显存需求会翻倍。这个细节在选卡时经常被忽略。注意本地部署模型时一定要预留至少 20% 的显存余量。生产环境不是实验室并发请求上来后显存峰值会远超单请求测试值。2.4 模型版本管理与灰度模型升级是件危险的事。同一个提示词模型从 A 版本换到 B 版本输出风格可能完全变了下游解析逻辑直接崩。所以中台必须支持模型版本管理和灰度发布。我的做法是每个模型实例有唯一版本号业务方调用时指定版本或走最新稳定版别名。新模型上线先跑影子流量对比新旧模型的输出差异确认无问题再逐步切量。这套机制听起来重但比起线上事故的代价非常值得。3. 知识库层RAG 效果的天花板在这里3.1 三种知识库的区分与应用场景热词里提到的KG 知识库、RAG 知识库和结构化知识库的区分这是很多人搞混的地方。我按实际用途分一下类型存储形式擅长场景典型工具RAG 知识库向量 原文非结构化文档问答向量数据库结构化知识库表/图数据库精确查询、统计SQL/图库KG 知识库实体-关系图多跳推理、关系查询Neo4j 等实际项目里纯 RAG 往往不够。比如问我们公司去年营收最高的三个部门分别是谁负责这需要结构化查询 关系推理纯向量检索搞不定。成熟的中台会做混合检索向量检索召回语义相关内容结构化查询处理精确条件最后融合排序。3.2 文档解析与切分最容易被低估的环节RAG 效果差八成问题出在文档解析和切分上而不是模型。我见过太多团队直接拿 PDF 丢进工具就完事结果表格错乱、标题丢失、页眉页脚混进正文检索出来的内容驴唇不对马嘴。文档解析要处理的难点PDF 双栏排版解析顺序错乱需要版面分析。表格普通文本切分会把表格拆散需要专门的表格提取。图片图片里的文字需要 OCR图片本身要考虑是否入库RAG 知识库能不能存图片能但通常存的是图片的描述或 OCR 结果而不是图片本身参与向量检索。扫描件需要 OCR且 OCR 质量直接决定后续效果。切分策略上我推荐语义切分 结构切分结合。按标题层级切大块块内再按语义切分块之间保留重叠overlap。重叠比例一般 10%-20%太小会丢上下文太大浪费存储和检索成本。3.3 向量化与检索的工程细节Embedding 模型的选择直接影响检索质量。中文场景下我一般优先测几个主流中文 Embedding 模型用自己业务的评测集跑一遍而不是盲目信榜单。因为通用榜单和你的业务数据分布可能差很远。检索环节纯向量检索的问题是对精确匹配不敏感。比如用户问产品型号 X200 的保修政策向量检索可能召回一堆保修政策相关但型号不对的内容。解决办法是混合检索向量检索 BM25 关键词检索两路结果用 RRF倒数排名融合合并再用 Rerank 模型精排。Rerank 这一步很多人省掉觉得多花钱。但实测下来加了 Rerank 后 Top-3 命中率能提升 15-30 个百分点这个投入非常值。Rerank 模型比生成模型便宜得多性价比极高。3.4 知识库的更新与版本治理知识库不是建完就完事的它是活的。文档会更新、会过期、会新增。中台必须支持增量更新新文档入库旧文档更新删除的文档要能同步删除向量。版本追溯能查到某个答案是基于哪个版本的文档生成的。权限隔离不同部门的知识库要隔离检索时按用户权限过滤。权限隔离这块特别容易出事故。我见过一个案例HR 的薪酬文档被误入库到公共知识库结果全员都能问出别人的薪资。所以知识库的权限模型必须在入库时就设计好而不是事后补。提示知识库入库时给每个 chunk 打上权限标签部门、密级检索时在向量库层面做过滤而不是检索完再过滤。后者既浪费算力又有泄露风险。4. Agent 层编排能力决定中台的上限4.1 Agent 与普通工作流的本质区别热词里harness 和 agent 区别这个问题问得很好。简单说工作流是预定义路径Agent 是动态决策。工作流适合流程固定的场景如审批、表单填写Agent 适合需要根据中间结果动态决定下一步的场景如复杂问题排查、多工具协作。但实际落地时我建议能用工作流就别用 Agent。原因很简单工作流的可控性、可测试性、可调试性都远好于 Agent。Agent 的自由度带来的是不确定性和调试噩梦。很多号称需要 Agent 的场景拆解下来其实是几个固定工作流的组合。判断标准如果任务的步骤数量固定、顺序固定用工作流如果步骤数量或顺序依赖运行时信息才用 Agent。4.2 工具注册与调用规范Agent 的核心能力是调用工具。中台层要提供统一的工具注册中心业务方把自己的能力注册成工具Agent 通过标准协议调用。工具定义要包含名称和描述描述质量直接影响 Agent 选对工具的概率参数 schema类型、是否必填、取值范围权限要求超时和重试策略工具描述是门学问。描述写得太简单Agent 不知道什么时候该用写得太复杂又浪费 token。我的经验是描述里要包含什么时候用和什么时候不用后者经常被忽略但很重要。4.3 记忆管理与上下文工程Agent 要有记忆才能处理多轮任务。记忆分几种短期记忆当前会话的上下文直接放 prompt 里。长期记忆跨会话的信息需要存储和检索。工作记忆任务执行过程中的中间状态。上下文工程是 Agent 效果的关键。上下文太长会稀释注意力、增加成本太短会丢信息。我的做法是分层压缩原始对话保留最近几轮更早的对话做摘要关键信息抽取成结构化字段。4.4 Agent 的安全与权限治理热词里agent 安全是个大话题。Agent 能调工具、能访问数据一旦被恶意利用后果严重。中台层必须做工具调用白名单Agent 只能调授权范围内的工具。参数校验防止注入攻击尤其是拼接 SQL、命令的场景。操作审计每次工具调用都记录可追溯。敏感操作二次确认删除、转账这类操作要人工确认。我特别想强调提示词注入的防范。用户输入里如果包含忽略之前的指令这类内容可能诱导 Agent 执行非预期操作。中台层要做输入清洗和指令隔离把用户输入和系统指令严格分开。5. 业务系统层中台价值的最终检验5.1 业务接入的标准姿势业务系统接入中台理想状态是只写业务逻辑不碰 AI 细节。业务方通过中台提供的 SDK 或 API声明式地描述需求我要一个基于 XX 知识库的问答能力用 XX 模型带 XX 工具。中台负责组装。但现实往往没那么理想。业务方总有些特殊需求中台不可能全满足。这时候要留扩展点允许业务方自定义提示词模板、自定义后处理逻辑但核心的模型调用、检索、编排还是走中台。5.2 效果评测与持续迭代中台建完不是终点效果评测才是。我建议每个接入的场景都要有评测集包含典型问题、边界问题、对抗问题。每次模型升级、知识库更新、提示词调整都跑一遍评测集看指标变化。评测指标不能只看准确率。实际业务里拒答率和幻觉率同样重要。一个总是自信地给出错误答案的系统比一个会说我不知道的系统危害大得多。5.3 成本控制与性能优化AI 中台的运营成本主要是 token 成本和 GPU 成本。控制手段缓存相同或相似问题缓存答案命中率高的场景能省 30% 以上。模型分级简单问题用便宜模型复杂问题才用贵模型。检索优化减少无效上下文prompt 越短越省钱。批处理非实时场景合并请求提高 GPU 利用率。5.4 从项目制到产品化的组织演进最后说个组织层面的事。AI 中台要真正发挥价值必须从项目制转向产品化。项目制是业务方提需求、中台团队接需求、做完交付产品化是中台团队主动规划能力、业务方自助使用。这个转变很难因为它要求中台团队既懂技术又懂业务还要有产品思维。但只有完成这个转变中台才能摆脱外包团队的命运真正成为企业的 AI 能力底座。我在实际推进中最大的体会是中台的成功不取决于技术多先进而取决于业务方愿不愿意用。技术团队容易陷入自嗨把架构做得无比优雅结果业务方觉得接入太麻烦宁愿自己另起炉灶。所以从第一天起就要把降低业务接入成本当成核心指标而不是把架构多完美当成目标。这个顺序搞反了中台基本就废了。