技术知识库 · 架构设计 · · 国科智飞 Gavin

AI 项目架构模式库：常见架构与其适用场景

从实际项目里抽出的五套 AI 架构模式：前后端分离、知识图谱流水线、多模型路由、Agent 平台，以及企业引入 AI 的成熟度路径。

做 AI 项目久了会发现一个规律：大多数需求最后都会收敛到少数几种架构上。下面这些模式来自我们做过的多个项目，每个都标注了特征、关键分层、适用场景，以及实际使用时要小心的坑。

先说一个前提判断：架构选型的第一原则不是"哪个先进"，而是"当前阶段匹配哪个"。同一个团队在单点尝试期用体系化架构，和在体系化阶段用脚本凑合，都会出问题——前者被复杂度拖死，后者被债务压垮。下面这些模式大致对应了从简单到复杂的几个阶段。

一、FastAPI + React 前后端分离

这是最"无聊"也最稳的一种。后端 FastAPI + SQLAlchemy + Celery，前端 React 18 + TypeScript + Vite + TailwindCSS，数据层 PostgreSQL + Redis，部署用 Docker Compose。

关键分层：

适合 B 端管理后台、数据平台，以及带复杂业务逻辑的 AI 应用。实际使用要注意两点：模型调用这类长耗时任务不要塞进同步请求，交给 Celery 队列；Redis 同时承担缓存和任务状态。另外，types/ 和 schemas/ 是这个架构的隐形成本——前后端两侧都偷懒不做类型约束，最后一定会疼。

不适合什么：如果只是内部工具、一天几十次调用，全套前后端分离就是过度设计，一个带界面的单体脚本可能就够了。另外，Celery 引入的是"至少一个 worker 进程"的运维成本；团队没人愿意管队列时，长任务可以先用同步接口撑着，等真的超时了再拆。

部署上有一条经验：Docker Compose 适合单机起步，但数据库和队列的持久化要提前配好卷，否则容器重建时任务状态会丢。迁移到多机之前，先把日志和健康检查做出来——没有可观测性的分布式系统，只会更难查问题。

二、知识图谱流水线

典型流程：

文本 → Chunk 分块 → LLM 提取 SPO 三元组 → 实体标准化 → 关系推理 → 可视化

几个关键技术点：

适合非结构化文档的知识提取、领域知识图谱构建，以及 RAG 之前的文档结构化预处理。经验是：图谱质量的分水岭在标准化这一步。抽取模型可以换，但同义词不归一，后面的推理和检索都会脏。

关系推理则要防止过度推理：传递性可以推出"A 的供应商的母公司也相关"，但推得越远，错误的放大效应越明显。生产环境里建议给推理深度设上限，并把推理出来的边和抽取出来的边区分标记——查错时能分清哪条来自原文，哪条是推断。

这个模式也不是所有场景都需要。如果需求只是"文档问答"，向量检索加好的切片通常就够了；图谱的构建和维护成本，只有在实体关系本身是业务价值时（比如合规审查、供应链分析）才划得来。强行上图谱，最后往往变成一份没人维护的静态图。

三、多模型路由

核心结构是：多云模型账号池（OpenAI / Claude / 火山等），分组管理加负载均衡，对外提供统一的 OpenAI 兼容协议，Prompt 版本化并支持灰度发布。

这个模式的价值有三点。成本上，不同场景可以用不同性价比的模型；可靠性上，单模型故障不影响整体服务；灵活性上，切换或新增模型不需要改业务代码。

统一协议层是这个模式的全部意义。如果业务代码直接写某个厂商的 SDK，路由层就白建了。另外，账号池必须处理配额和健康检查，否则负载均衡会把请求打到已经限流的账号上。

再往下还有两件事决定它能不能长期用：一是可观测性，按厂商、按场景记录延迟、失败率与用量，否则"哪个模型更划算"永远说不清；二是 Prompt 版本化，路由层要能回答"这个请求用的是哪版提示词、哪版模型"，灰度发布才有依据。这两件事不做，路由层就只是个会转发请求的中间件。

边界：单模型、低并发的内部应用没必要上路由——多一层抽象就多一层故障点。判断信号是"换模型时要不要改业务代码"和"单点故障能否接受"，两个都答"否"，才值得建。

四、Agent 开发平台

以 Coze 的开源版 Coze Studio 为代表：后端 Golang + 微服务架构 + DDD，前端 React + TypeScript，Docker Compose 部署。核心模块包括模型服务管理、智能体编排（Agent + Workflow + Plugin）、知识库管理，以及对外 API 和 SDK。

它适合想自建 Agent 平台、需要二次开发和私有化部署的团队。但如果需求只是一两个固定场景的智能体，引入这套平台属于杀鸡用牛刀——平台型架构的复杂度，会变成后续每一次迭代都要付的税。

判断标准可以具体一些：需要给多个业务方自助搭建 Agent、需要私有化与二次开发、团队里有长期维护平台的人力——三条同时成立，才考虑平台。否则，直接用现成的 Agent 框架把两三个场景做扎实，性价比高得多。平台的价值在复用；复用还没发生时，平台就是纯成本。

五、企业引入 AI 的成熟度路径

从多个企业项目里，我们观察到一条相似的路径：

  1. 单点尝试：某个业务环节先试 AI；
  2. 流程嵌入：AI 进入核心流程，和既有系统打通；
  3. 体系化：AI 能力平台化，对内对外双轨输出。

很少有企业能跳过第二步直接做体系化。单点尝试证明价值，流程嵌入证明可靠性，到了体系化才谈得上复用。跳过第二步的典型症状是：平台建得很完整，却没有一个真实业务真的依赖它——因为没有经历过流程嵌入，就不知道稳定性和集成成本在哪里。

反过来，卡在第二步的企业通常不是技术问题，而是组织问题：AI 的产出要进入既有流程，就要有人对结果负责、有指标衡量效果。这一步走通，体系化才有根基。

六、信息架构：收件箱加三区工作流

知识库类产品还有一个可复用的信息架构：00 收件箱作为唯一入口、每日清空；01–04 工作区（项目 / 技术 / 产品 / 行业）是日常产出燃料；05–07 沉淀区（知识体系 / 成长 / 资源库）是复利资产；09 归档做减法，保持主目录干净。

它和 PARA 的对应关系是：01 项目管理对应 Projects，02–04 对应 Areas，07 资源库对应 Resources，00 对应 Inbox。差别在于这套结构对技术追踪和知识体系有更重的设计。

核心矛盾是信息输入永远大于处理能力。解法不是更多分类，而是"收件箱作为强制入口 + 每日清空"的纪律。这个模式有一个前提：使用者是一个人。多人协作的知识库，收件箱如果不区分来源和责任人，会从入口变成垃圾场——团队场景要在入口就加归属，而不是靠"大家自觉"。

可复用的组件清单

组件 适用场景
玻璃拟态 UI 组件 B 端 AI 产品界面
规则可视化构建器 强规则配置场景
多模型路由 AI 能力聚合与成本控制
知识图谱生成器 文档结构化与领域图谱
Agent 开发平台 AI 平台型产品

选架构的原则从来不是"哪个先进"，而是"哪个匹配当前阶段"。上面这些模式没有高下之分，只有阶段之分。

如果一定要给一个选择顺序，我们的做法是问三个问题：这个需求会不会长期存在（决定要不要建流程）；产出是否要进入别人的工作流（决定要不要建接口）；同类需求会不会出现第三次（决定要不要建平台）。三个都答"是"，再上最重的那套架构；有一个答"否"，就先用最轻的方案把价值跑出来。