企业官网建设流程全解析

企业里做 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 中台拆成四层，是我实践下来最清晰的分法：

这四层的边界不是绝对的，但职责必须清晰。最常见的错误是把知识库逻辑写进 Agent 里，或者把业务权限判断塞进模型网关。一旦边界模糊，后面任何一层要升级都会牵一发动全身。

提示：分层的目的不是画架构图好看，而是让每一层可以独立演进。模型层换供应商时，知识库和 Agent 层不应该感知到变化；知识库换向量库时，业务系统不应该改代码。做不到这一点，说明分层没做到位。

1.3 什么阶段该上中台，什么阶段不该

我的经验判断标准是这样的：

• 1-2 个 AI 场景：别搞中台，直接快速迭代，把场景跑通最重要。
• 3-5 个场景且开始重复造轮子：开始抽象公共能力，但保持轻量，别过度设计。
• 5 个以上场景或跨部门协作：正式建中台，投入专职团队。

过早建中台是创业公司最常见的死法之一。中台本身不产生业务价值，它只是降低边际成本。如果业务量还没起来，中台的固定成本反而会拖垮团队。我见过一个二十人的团队，花三个月搭了套"企业级 AI 中台"，结果上面只跑了一个客服问答场景，投入产出比惨不忍睹。

2. 模型层：统一接入比选哪个模型更重要

2.1 模型网关是整个中台的咽喉

模型层最核心的组件是模型网关。它的作用类似微服务架构里的 API Gateway，但专门针对大模型调用场景做了优化。一个合格的模型网关至少要解决这几件事：

• 协议统一：把 OpenAI 格式、各家私有格式、本地推理服务的格式统一成一套内部协议。
• 路由与降级：根据请求特征（长度、任务类型、成本预算）路由到不同模型，主模型挂了自动切备用。
• 限流与配额：按业务线、按用户维度限流，防止某个业务把额度跑爆。
• 可观测：记录每次调用的 token 数、延迟、成本、成功率，这是后面做成本优化的基础。

为什么强调"协议统一"？因为大模型生态变化太快了。今天用 GPT-4，明天可能因为成本换成国产模型，后天某个场景又要用本地部署的开源模型。如果业务代码直接写死了某家的 SDK，每次换模型都是一次重构。有了网关，业务方只调内部统一接口，换模型只是网关配置的改动。

2.2 模型选型的实际决策逻辑

选模型不是选"最强"的，而是选"最合适"的。我一般按这个顺序决策：

1. 任务类型：需要复杂推理的（如多步 Agent）用强模型；简单分类、抽取用轻量模型。
2. 数据合规：涉及敏感数据的场景，优先本地部署开源模型。
3. 成本预算：算清楚每千次调用的成本，高频场景必须用便宜模型。
4. 延迟要求：实时交互场景对首 token 延迟敏感，批处理场景无所谓。
5. 稳定性：商用 API 有 SLA，本地部署要自己保证可用性。

这里有个反直觉的结论：大部分企业场景不需要最强的模型。我做过统计，一个典型的企业知识问答场景，用中等能力的模型 + 好的 RAG 检索，效果往往比用最强模型 + 差检索要好。因为答案质量的天花板往往在检索环节，而不是生成环节。

2.3 本地部署与云 API 的混合策略

成熟的中台通常是混合的：核心敏感场景本地部署，通用场景用云 API。本地部署这块，GPU 资源调度是难点。我推荐用 GPUStack 这类工具做本地模型的统一管理，它能帮你把多张卡的资源池化，按需分配模型实例。

本地部署最容易踩的坑是显存估算。很多人按模型参数量简单估算，结果一跑就 OOM。实际显存占用大致是：

显存 ≈ 参数量 × 精度字节数 × 1.2（KV Cache 和中间激活的开销）

比如 7B 模型用 FP16，大约需要 7 × 2 × 1.2 ≈ 17GB。如果用 INT8 量化，能降到 9GB 左右。但注意，上下文长度会显著影响 KV Cache，长上下文场景显存需求会翻倍。这个细节在选卡时经常被忽略。

注意：本地部署模型时，一定要预留至少 20% 的显存余量。生产环境不是实验室，并发请求上来后显存峰值会远超单请求测试值。

2.4 模型版本管理与灰度

模型升级是件危险的事。同一个提示词，模型从 A 版本换到 B 版本，输出风格可能完全变了，下游解析逻辑直接崩。所以中台必须支持模型版本管理和灰度发布。

我的做法是：每个模型实例有唯一版本号，业务方调用时指定版本或走"最新稳定版"别名。新模型上线先跑影子流量，对比新旧模型的输出差异，确认无问题再逐步切量。这套机制听起来重，但比起线上事故的代价，非常值得。

3. 知识库层：RAG 效果的天花板在这里

3.1 三种知识库的区分与应用场景

热词里提到的"KG 知识库、RAG 知识库和结构化知识库的区分"，这是很多人搞混的地方。我按实际用途分一下：

实际项目里，纯 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 能力底座。

我在实际推进中最大的体会是：中台的成功不取决于技术多先进，而取决于业务方愿不愿意用。技术团队容易陷入自嗨，把架构做得无比优雅，结果业务方觉得接入太麻烦，宁愿自己另起炉灶。所以从第一天起，就要把"降低业务接入成本"当成核心指标，而不是把"架构多完美"当成目标。这个顺序搞反了，中台基本就废了。