322 lines
26 KiB
Markdown
322 lines
26 KiB
Markdown
|
||
---
|
||
#领域/未知
|
||
|
||
#复盘/0 #临时/备忘 #状态/待处理
|
||
|
||
20260509-备忘-主题名-文件内容
|
||
|
||
## 一句话描述
|
||
|
||
[________]
|
||
|
||
---
|
||
## 一句话描述
|
||
|
||
面向个人极客/开发者，打造一套**分层解耦、职责单一、自托管优先、资产可复用**的全链路AI服务架构，完美覆盖日常深度对话与个人知识库RAG高质量问答两大核心场景，严格保障3-4年不重构、易维护、可平滑迭代，拒绝无效折腾。
|
||
|
||
## 详细解释
|
||
|
||
### 一、最高优先级核心思想（所有设计必须严格遵守）
|
||
✅ 黄金核心原则（来源：软件工程分层架构理论《软件工程：实践者的研究方法》、微服务设计规范《微服务设计》）
|
||
1. **职责单一、分层解耦**：每层只做一件事，绝不功能重叠，层间仅通过标准OpenAI格式API通信，层内迭代不影响上下游
|
||
2. **自托管优先、兼容开放**：核心链路全自托管保障数据隐私，同时通过标准化网关兼容第三方API兜底，绝不重复造轮子
|
||
3. **资产可复用、长期主义**：所有配置、知识库、模型资产标准化沉淀，架构符合行业通用标准，保障3-4年不重构，仅做层内升级
|
||
4. **折腾有价值、拒绝无效内耗**：所有选型均为GitHub星标≥10k、近3个月活跃更新、有社区长期维护的开源项目，避免小众项目停更吃灰，每一步部署都服务于核心场景
|
||
|
||
---
|
||
|
||
### 二、架构分层设计（原理→选型→用法→案例，新手友好）
|
||
基于**关注点分离的分层架构模式**，将整个系统拆分为5个完全解耦的层级，从用户入口到算力底座逐层向下调用，绝不跨层通信，完美适配戴福斯技能习得模型，新手可分阶段落地。
|
||
|
||
#### 1. 前端入口层：LibreChat
|
||
- **核心原理**：用户交互的唯一聚合入口，统一对话体验，完全屏蔽下层服务的接口差异，符合B/S架构前端聚合层设计规范
|
||
- **知识点&同类工具对比**：
|
||
| 工具 | 核心差异 | 适配性 |
|
||
|------|----------|--------|
|
||
| LibreChat（最终选型） | 支持多会话归档、多模型一键切换、插件系统、完美兼容OpenAI格式，社区活跃（16k+星标），长期维护有保障 | 完美匹配个人全场景对话需求，一个入口聚合日常对话+RAG问答，无需切换多个工具 |
|
||
| ChatGPT-Next-Web | 轻量但功能单薄，RAG和插件支持弱 | 仅适合极简对话，无法满足长期复杂场景 |
|
||
| Chatbox | 桌面端为主，自托管Web端能力弱 | 不适合统一入口的架构设计 |
|
||
- **核心用法**：仅对接下层NewAPI的OpenAI兼容端点，所有模型、RAG应用全部通过NewAPI同步，前端无需重复配置
|
||
- **落地案例（Docker一键部署）
|
||
- **知识联动**：作为架构最顶层，仅依赖紧邻的网关层，后续更换前端仅需修改本层，完全不影响下层所有服务，符合层内迭代原则。
|
||
|
||
#### 2. 模型网关层：NewAPI
|
||
|
||
- **核心原理**：整个架构的 “交通枢纽”，实现 AI 流量调度、模型分发、故障转移、权限管控，是实现 “新增模型仅在网关添加，上层自动可用” 的核心，来源：API 网关设计模式
|
||
- **知识点 & 同类工具对比**：
|
||
|
||
表格
|
||
|
||
|工具|核心差异|适配性|
|
||
|---|---|---|
|
||
|NewAPI（最终选型）|完美兼容 OpenAI 格式，支持全主流模型接入、故障自动转移、用量统计、密钥管理，社区活跃（10k + 星标），持续更新|完全匹配分层解耦需求，实现模型能力的统一管理和分发|
|
||
|OneAPI|原作者停更，分支混乱，长期维护性极差|不符合 3-4 年不重构的核心要求|
|
||
|OpenLLM|侧重模型部署，网关调度能力极弱|职责不匹配，无法承担枢纽角色|
|
||
|
||
- **核心用法**：
|
||
|
||
1. 所有下层服务（Ollama、vLLM、Dify/MaxKB、第三方 API）全部接入 NewAPI，向上提供唯一的 OpenAI 兼容端点
|
||
2. 配置模型分流规则：日常对话调度 Ollama，RAG 相关推理调度 vLLM，自托管服务故障时自动切第三方 API 兜底
|
||
3. 为上层不同应用分配独立密钥，实现权限隔离和用量管控
|
||
|
||
- **落地案例**：新增自托管模型仅需 3 步，上层零修改
|
||
|
||
1. 在 NewAPI 后台新增渠道，选择对应模型类型，填写 Ollama/vLLM 的接口地址和密钥
|
||
2. 配置模型名称，设置分流规则和兜底策略
|
||
3. 保存后，LibreChat、Dify、MaxKB 等所有上层应用自动获得该模型的调用能力
|
||
|
||
- **知识联动**：是整个架构的核心中间层，承接所有上层入口，调度所有下层服务，完全解耦上层应用和底层推理，层内新增 / 修改模型，完全不影响上下游。
|
||
|
||
#### 3. 应用 / 智能体编排层：Dify + MaxKB 共存（职责完全分离，无功能重叠）
|
||
|
||
- **核心原理**：RAG 流程、Agent 工作流、知识库应用的可视化编排层，将底层模型、向量库能力封装成可直接调用的对话应用，来源：低代码应用编排设计规范
|
||
- **知识点 & 同类工具对比**：
|
||
|
||
1. **为什么共存而非二选一？** 严格拆分职责，完全避免功能重叠：
|
||
|
||
- Dify：负责**复杂 Agent、多轮工作流、高级 RAG 流程定制、多文档交叉推理**，适合需要复杂逻辑的深度知识串联场景
|
||
- MaxKB：负责**轻量化、开箱即用的个人知识库问答、文档快速入库、极简 RAG 应用**，适合日常快速查知识库、单文档问答，资源占用低，维护成本极低
|
||
|
||
2. 同类工具对比：Flowise、LangFlow 更偏向开发者低代码拖拽，上手门槛高，个人日常维护成本高，不符合 “拒绝无效折腾” 的原则；Dify 和 MaxKB 中文支持完美，社区活跃，长期维护有保障。
|
||
|
||
- **核心用法**：
|
||
|
||
1. 所有模型能力**仅对接 NewAPI**，不直接调用底层模型，保障模型统一管理
|
||
2. 所有知识库能力**仅调用下层 AnythingLLM 的 API**，不自身维护向量库，避免知识库重复存储、资产分散
|
||
|
||
- **落地案例（Dify 对接 AnythingLLM 转接服务核心代码）**：
|
||
- **知识联动**：承接前端的 RAG 请求，调用下层知识库底座和推理能力，完全符合分层原则，层内升级应用、新增工作流，完全不影响上下游，后续更换编排应用，知识库资产完全无需迁移。
|
||
|
||
#### 4. 推理引擎层：Ollama + vLLM 共存（职责完全分离，无功能重叠）
|
||
|
||
- **核心原理**：大语言模型、Embedding 模型、Rerank 模型的本地推理运行环境，是整个架构的 “算力核心”，来源：LLM 推理引擎架构设计规范
|
||
- **知识点 & 同类工具对比**：
|
||
|
||
1. **为什么共存而非二选一？** 严格拆分职责，完全避免功能重叠：
|
||
|
||
- Ollama：负责**日常对话、轻量模型推理、快速模型部署 / 切换**，开箱即用，一键 pull 就能运行主流开源模型，适合日常深度哲学探讨的对话场景，维护成本极低，社区极其活跃（90k + 星标）
|
||
- vLLM：负责**高吞吐、低延迟的批量推理、Embedding 生成、Rerank 精排、大负载 RAG 场景**，基于 PagedAttention 技术实现 10 倍以上的推理效率提升，适合 RAG 场景下的批量向量生成、重排序
|
||
|
||
2. 同类工具对比：TGI 上手门槛高，配置复杂，个人维护成本高；LocalAI 兼容性差，性能弱，更新慢，均不符合长期使用需求。
|
||
|
||
- **核心用法**：
|
||
|
||
1. Ollama 和 vLLM 全部接入 NewAPI，向上提供标准 OpenAI 格式接口
|
||
2. NewAPI 配置分流规则：日常对话优先调度 Ollama，RAG 相关的向量生成、Rerank、批量生成优先调度 vLLM
|
||
|
||
- **落地案例（一键部署命令）**：
|
||
- **知识联动**：为上层所有应用提供统一的推理能力，层内升级模型、优化推理参数，完全不影响上层应用，符合层内迭代优先的原则。
|
||
|
||
#### 5. 知识库底座层：AnythingLLM
|
||
|
||
- **核心原理**：个人知识资产的唯一沉淀底座，负责统一的文档管理、解析、向量存储、粗排召回，是实现 “资产可复用、不重复造轮子” 的核心，来源：《RAG 实战》中向量数据库与文档管理层设计规范
|
||
- **知识点 & 同类工具对比**：
|
||
|
||
1. **为什么选 AnythingLLM 作为唯一底座，而不是让 Dify/MaxKB 自带向量库？**
|
||
|
||
核心原因：如果 Dify 和 MaxKB 各自维护向量库，同一份文档需要重复上传，知识库无法跨应用复用，后续更换应用还要迁移数据，完全违背 3-4 年不重构、资产可复用的原则。AnythingLLM 自带完整的文档解析、分块、向量管理、版本控制能力，同时提供标准 API，完美对接上层所有编排应用，实现 “一次上传，全架构复用”。
|
||
2. 同类工具对比：Milvus、Qdrant 是纯向量数据库，没有文档管理能力，个人使用需要自行开发文档处理流程，折腾成本极高，不符合 “拒绝无效折腾” 的原则。
|
||
|
||
- **核心用法**：
|
||
|
||
1. 所有个人文档、知识资料**统一上传到 AnythingLLM**，进行标准化的文档解析、分块、向量生成、版本管理
|
||
2. 向量粗排召回全部在本层完成，精排重排序交给上层 vLLM，严格职责分离
|
||
3. 向上提供标准 API，供上层编排应用调用，不直接对接前端
|
||
|
||
- **落地案例（Docker 一键部署）**：
|
||
- **知识联动**：是个人知识资产的唯一沉淀层，上层所有 RAG 应用都调用本层的能力，后续哪怕更换整个编排层，知识库完全无需迁移，完美符合长期可发展、资产可复用的核心需求。
|
||
|
||
---
|
||
|
||
### 三、两条核心业务链路（全闭环，无跨层调用）
|
||
|
||
1. **日常对话链路（极简高可用）**
|
||
|
||
用户 → LibreChat（前端入口） → NewAPI（模型网关） → Ollama/vLLM（自托管推理）/ 第三方 API（兜底） → 结果原路返回
|
||
2. **RAG 知识库问答链路（高精准资产复用）**
|
||
|
||
用户 → LibreChat（统一入口） → NewAPI（网关路由到对应 RAG 应用） → Dify/MaxKB（编排层处理对话逻辑） → 转接服务 → AnythingLLM（知识库粗排召回） → vLLM（Rerank 精排） → NewAPI（调度大模型） → Ollama/vLLM（推理生成回答） → 结果原路返回
|
||
|
||
## 延伸补充
|
||
|
||
### 常见避坑点
|
||
|
||
⚠️ 每个坑点均配套精准解决方案，严格规避无效折腾和架构失效
|
||
|
||
1. **坑点**：功能重叠，重复造轮子，比如 Dify 和 MaxKB 各自维护知识库，同一份文档多次上传，数据分散
|
||
|
||
**解决方案**：严格遵守「知识库唯一底座」黄金规则，所有文档统一存入 AnythingLLM，上层编排层只做流程编排，绝不存储任何知识库数据
|
||
2. **坑点**：选型小众开源项目，后续作者停更，项目吃灰，不符合 3-4 年不重构的需求
|
||
|
||
**解决方案**：✅ 强制选型规则：只选 GitHub 星标≥10k、近 3 个月有活跃更新、社区 issue 响应及时的开源项目，本次架构所有选型均符合该规则
|
||
3. **坑点**：层间强耦合，比如前端直接调用底层模型，后续换模型要修改前端配置，维护成本极高
|
||
|
||
**解决方案**：严格遵守分层架构，所有层间通信仅通过标准 OpenAI API，上层只对接紧邻的下层，**绝对禁止跨层调用**
|
||
4. **坑点**：一次性部署所有服务，复杂度太高，新手无法驾驭，最终全部吃灰
|
||
|
||
**解决方案**：按照戴福斯模型分阶段落地，先搭建最小可用链路（LibreChat→NewAPI→Ollama），跑通日常对话后，再逐步扩展知识库和 RAG 能力
|
||
5. **坑点**：自托管模型性能不足，日常对话卡顿，体验差
|
||
|
||
**解决方案**：在 NewAPI 中配置超时自动兜底策略，自托管模型响应超时时，自动切换到第三方 API，保障体验的同时，符合自托管优先的原则
|
||
6. **坑点**：数据无备份，服务器故障导致知识库、配置全部丢失
|
||
|
||
**解决方案**：所有服务的配置、数据全部通过 Docker Volume 挂载到宿主机，设置定时任务每日备份核心数据（AnythingLLM 知识库、NewAPI 配置、LibreChat 会话数据）
|
||
7. **坑点**：频繁更换 Embedding/Rerank 模型，导致知识库反复重建，资产无法复用
|
||
|
||
**解决方案**：固定使用社区公认效果稳定的开源模型（bge-large-zh-v1.5 做 Embedding，bge-reranker-large 做 Rerank），非必要不更换，保障知识库资产长期可用
|
||
|
||
### 知识点浓缩（背诵级，解决反复查资料的核心需求）
|
||
|
||
1. **核心架构**：5 层分层架构，**入口层→网关层→编排层→推理层→底座层**，严格职责单一，绝不跨层调用
|
||
2. **核心原则**：分层解耦、自托管优先、资产可复用、长期主义、拒绝无效折腾
|
||
3. **选型速记**：
|
||
|
||
- 统一入口：LibreChat
|
||
- 唯一网关：NewAPI
|
||
- 编排分工：Dify 做复杂 Agent / 工作流，MaxKB 做轻量知识库问答
|
||
- 推理分工：Ollama 做日常对话，vLLM 做 RAG 高吞吐推理 / Rerank
|
||
- 唯一知识库底座：AnythingLLM
|
||
|
||
4. **两条核心链路**：
|
||
|
||
- 日常对话：LibreChat → NewAPI → Ollama/vLLM/ 第三方 API
|
||
- RAG 问答：LibreChat → NewAPI → Dify/MaxKB → AnythingLLM → vLLM Rerank → 大模型生成
|
||
|
||
5. **黄金选型规则**：只选星标≥10k、近 3 个月活跃更新的开源项目，保障长期维护
|
||
6. **资产复用核心**：所有知识文档统一存入 AnythingLLM，上层应用只调用，不存储
|
||
|
||
### 进阶优化方向（3-4 年平滑迭代，无需重构架构）
|
||
|
||
1. **高可用升级**：层内服务集群部署，比如 NewAPI 多实例、vLLM 多节点推理，实现负载均衡和故障自愈，层内升级不影响整体架构
|
||
2. **数据安全升级**：新增私有 CA 证书，全链路 HTTPS 加密，对接内网 VPN，实现外网安全访问，保障私有数据不泄露
|
||
3. **知识资产自动化**：对接 Obsidian、Notion 等个人笔记工具，实现文档自动同步到 AnythingLLM，知识库自动更新，无需手动上传
|
||
4. **自动化运维升级**：新增 Prometheus+Grafana 监控系统，监控所有服务的运行状态、模型推理性能、磁盘使用率，异常自动告警，降低维护成本
|
||
5. **Agent 能力扩展**：在 Dify 中对接自定义工具、代码执行环境、第三方 API，实现个人自动化任务（比如自动文献整理、数据分析），完全在现有架构内扩展
|
||
6. **多模态能力升级**：在推理层新增多模态模型部署，通过 NewAPI 同步到上层所有应用，实现图片、文档的多模态问答，层内扩展，不影响整体架构
|
||
|
||
## 提问建议
|
||
|
||
为了帮助你真正吃透这套架构，从「有意识无能」进阶到「有意识有能」，你可以围绕以下方向提问，也可以提出你自己的困惑：
|
||
|
||
1. 基础落地类：针对某一层的具体部署步骤、配置细节、开箱即用的完整脚本，我可以给你一步到位的执行方案
|
||
2. 架构理解类：比如 “为什么必须把知识库底座和编排层分开，而不是直接用 Dify 自带的知识库？”，帮你理清底层逻辑，避免知其然不知其所以然
|
||
3. 避坑实操类：针对 RAG 召回效果差、模型部署失败、服务间对接不通等具体问题，我可以给你精准的排查步骤和解决方案
|
||
4. 分阶段落地类：如果你是新手，我可以给你制定从最小可用版本（MVP）到完整架构的分阶段落地计划，避免一次性折腾太多导致吃灰
|
||
5. 选型对比类：如果你想替换某一层的工具，我可以给你详细的优劣势对比、适配方案，以及是否符合长期主义原则的专业判断
|
||
6. 原理深度类：比如 “为什么分层架构能实现 3-4 年不重构？”，帮你理解底层的软件工程原理，建立自己的架构设计能力
|
||
|
||
|
||
# 个人自托管AI架构 绝对优先级行动纲领
|
||
## 纲领总纲·不可动摇的顶层铁律（最高优先级，所有行动不得违反）
|
||
本纲领所有行动均围绕**两大核心场景**（日常深度哲学对话、个人知识库RAG高质量知识串联）展开，严格遵守5条终身铁律，任何违反以下规则的行动均判定为「无效折腾」，绝对禁止：
|
||
1. **分层解耦、职责唯一铁律**：一层仅承担一项核心职责，绝不出现功能重叠；层间仅通过标准OpenAI格式API通信，绝对禁止跨层调用
|
||
2. **资产可复用铁律**：所有个人知识资产、模型配置、应用资产必须标准化统一沉淀，可跨服务全架构复用，绝不重复建设、重复存储
|
||
3. **自托管优先、兼容兜底铁律**：核心链路100%自托管保障数据隐私，仅将第三方API作为故障兜底方案，绝不形成第三方服务依赖
|
||
4. **长期主义铁律**：所有服务选型必须符合3-4年可维护标准，仅选择GitHub星标≥10k、近3个月活跃更新、社区长期维护的主流开源项目，绝对禁止小众无保障项目
|
||
5. **核心价值导向铁律**：所有行动必须直接服务于两大核心场景，非核心需求一律延后，禁止为了尝鲜、跟风开展无明确价值的折腾
|
||
|
||
---
|
||
|
||
## 绝对优先级梯队计划（严格按顺序执行，上一梯队未100%完成验收，绝对禁止进入下一梯队）
|
||
### P0级：生死线·架构骨架搭建（绝对第一优先级）
|
||
#### 核心目标
|
||
搭建符合分层解耦铁律的**最小可行架构骨架**，固化全生命周期不变的架构边界、通信规范，为3-4年不重构打下不可动摇的根基，跑通最基础的自托管对话闭环。
|
||
#### 核心行动项（严格按先后顺序执行）
|
||
1. 书面固化5层架构的唯一职责、边界、层间通信规范，形成《架构边界说明书》，明确禁止跨层调用、功能重叠的红线
|
||
2. 落地**模型网关层（NewAPI）**，建立全架构唯一的模型调度、权限管控、API分发标准，作为整个架构的唯一交通枢纽
|
||
3. 落地**前端入口层（LibreChat）**，仅对接网关层，建立全架构唯一的用户交互入口，实现入口与底层能力的完全解耦
|
||
4. 落地**推理引擎层核心节点（Ollama）**，对接网关层，完成自托管日常对话链路的全闭环
|
||
#### 验收标准（必须100%全部满足，方可进入下一梯队）
|
||
1. 有明确可落地的《架构边界说明书》，每层职责唯一、无功能重叠、无跨层调用设计
|
||
2. 仅通过网关层新增/修改模型，前端入口无需任何配置修改即可自动适配
|
||
3. 日常对话链路100%自托管闭环，可连续稳定运行72小时无故障
|
||
4. 所有层间通信均采用标准OpenAI格式API，无定制化强耦合对接
|
||
#### 本阶段绝对禁止项（触碰即判定为无效折腾）
|
||
1. 禁止提前部署RAG、知识库、Agent、工作流等非核心功能
|
||
2. 禁止修改层间通信规范、禁止任何形式的跨层调用
|
||
3. 禁止部署小众、无长期维护保障的开源项目
|
||
4. 禁止一次性部署多个推理引擎，仅保留Ollama一个核心推理节点
|
||
|
||
---
|
||
|
||
### P1级：核心能力线·两大核心场景全落地（P0验收通过后方可进入）
|
||
#### 核心目标
|
||
完成全架构5层能力的完整落地，实现两大核心场景的全闭环，满足用户全部核心诉求，同时固化资产复用、层内迭代的标准规范，保障架构长期可维护。
|
||
#### 核心行动项（严格按先后顺序执行）
|
||
1. 落地**知识库底座层（AnythingLLM）**，建立全架构唯一的知识资产沉淀标准，固化文档入库、解析、向量存储、召回的统一规范，作为个人知识资产的唯一载体
|
||
2. 落地**推理引擎层补充节点（vLLM）**，对接网关层，明确与Ollama的职责边界：仅负责RAG场景的高吞吐推理、Rerank精排，不承接日常对话流量
|
||
3. 落地**应用编排层轻量化节点（MaxKB）**，仅对接网关层+知识库底座，跑通极简RAG知识库问答链路，满足日常快速知识串联的核心需求
|
||
4. 落地**应用编排层复杂能力节点（Dify）**，仅对接网关层+知识库底座，实现复杂Agent、多轮工作流、深度知识交叉推理能力，满足深度哲学探讨、复杂知识串联需求
|
||
5. 固化两大核心链路的全流程规则，包括模型分流策略、故障兜底规则、权限管控规范、资产复用标准
|
||
#### 验收标准（必须100%全部满足，方可进入下一梯队）
|
||
1. 知识资产实现「一次入库、全架构复用」，一份文档仅需一次上传，所有上层应用均可调用，无重复存储、重复建设
|
||
2. 两大核心链路100%闭环，无跨层调用、无功能重叠，可连续稳定运行7天无故障
|
||
3. RAG问答链路实现「粗排-精排-生成」全流程标准化，可稳定输出贴合个人知识库的高质量知识串联内容
|
||
4. 所有新增模型、新增知识库、新增应用，均仅需在对应层内操作，不影响其他层的稳定运行
|
||
#### 本阶段绝对禁止项（触碰即判定为无效折腾）
|
||
1. 禁止在编排层内自建向量库、存储知识库资产，必须统一调用知识库底座层能力
|
||
2. 禁止模糊Ollama与vLLM的职责边界，禁止重复部署同类型推理能力
|
||
3. 禁止新增非核心场景的功能与独立服务
|
||
4. 禁止修改P0阶段固化的架构骨架、层间通信规范与边界规则
|
||
|
||
---
|
||
|
||
### P2级：体验优化线·可维护性与体验升级（P1验收通过后方可进入）
|
||
#### 核心目标
|
||
在不改动核心架构骨架的前提下，仅做层内优化，提升架构的可维护性、稳定性、使用体验，降低长期运维成本，不新增核心能力边界。
|
||
#### 核心行动项（无严格先后顺序，按需选择，不影响核心架构）
|
||
1. 层内高可用优化：核心服务多实例部署、故障自动转移、负载均衡配置
|
||
2. 自动化运维体系搭建：服务状态监控、异常告警、核心数据自动备份机制落地
|
||
3. 知识资产自动化同步：对接个人笔记工具、文档库，实现知识库自动更新、增量同步
|
||
4. 全链路安全加固：内网访问控制、全链路HTTPS加密、权限精细化管控
|
||
5. 核心场景体验优化：对话分流规则优化、RAG召回效果调优、模型推理性能优化
|
||
#### 验收标准
|
||
1. 所有优化均在层内完成，未改动P0阶段固化的架构骨架、层间规范与边界
|
||
2. 架构可维护性显著提升，日常运维耗时降低80%以上
|
||
3. 两大核心场景的响应速度、稳定性、输出质量有可量化的提升
|
||
#### 本阶段绝对禁止项
|
||
1. 禁止改动核心架构分层、职责边界、通信规范
|
||
2. 禁止新增与核心场景无关的独立服务
|
||
3. 禁止部署小众无保障的开源项目，破坏长期可维护性
|
||
|
||
---
|
||
|
||
### P3级：长期扩展线·未来能力进阶（P2验收通过且稳定运行6个月以上方可进入，绝对禁止提前触碰）
|
||
#### 核心目标
|
||
基于现有固化的架构骨架，仅做层内扩展，补充非核心的进阶能力，完全不改动核心架构，保障3-4年不重构的前提下，拓展架构的能力边界。
|
||
#### 核心行动项（按需选择，无严格先后顺序）
|
||
1. 多模态能力扩展：在推理层新增多模态模型，通过网关层同步到全架构所有应用
|
||
2. 自动化Agent能力扩展：在编排层新增自定义工具、代码执行环境，实现个人自动化任务
|
||
3. 分布式算力扩展：推理层新增分布式推理节点，提升大模型推理性能
|
||
4. 知识资产体系扩展：知识库底座新增多源数据接入、知识图谱、版本管理进阶能力
|
||
5. 多端入口扩展：入口层新增移动端、桌面端入口，统一对接网关层，不改动下层任何架构
|
||
#### 验收标准
|
||
1. 所有扩展均在层内完成，未改动核心架构骨架、层间规范与边界
|
||
2. 扩展能力可完全复用现有资产，无需重复建设
|
||
3. 两大核心场景运行稳定，不受扩展能力的任何影响
|
||
#### 本阶段绝对禁止项
|
||
1. 禁止为了扩展能力改动核心架构分层、职责边界、通信规范
|
||
2. 禁止新增与核心场景无关的独立服务，导致架构臃肿
|
||
3. 禁止部署小众、无长期维护的项目，破坏架构长期可维护性
|
||
|
||
---
|
||
|
||
## 3-4年不重构的核心保障机制（终身执行）
|
||
1. **架构骨架终身不变原则**：P0阶段固化的5层分层架构、层间职责边界、标准OpenAPI通信规范，3-4年内绝对不改动，所有变更、优化、扩展均在层内完成
|
||
2. **资产标准化沉淀原则**：所有知识资产、模型资产、配置资产，均按架构标准统一沉淀，不与单一服务绑定，更换同类型服务无需迁移任何核心资产
|
||
3. **选型终身可替代原则**：所有层的服务选型，均基于标准OpenAI API设计，可随时替换同类型服务，不影响其他层的稳定运行，彻底避免厂商/项目锁定
|
||
4. **月度架构巡检机制**：每月执行一次架构巡检，检查是否出现功能重叠、跨层调用、无效折腾的情况，及时修正，避免架构腐化
|
||
5. **最小变更原则**：所有变更均采用最小影响原则，仅改动需要优化的部分，不做全架构重构，保障架构长期稳定
|
||
|
||
---
|
||
|
||
## 无效折腾判定红线（终身执行，符合任意一条即为无效折腾，绝对禁止）
|
||
1. 未完成上一优先级梯队的验收标准，提前进入下一梯队的行动
|
||
2. 改动P0阶段固化的核心架构骨架、层间职责边界、通信规范
|
||
3. 部署与两大核心场景无关的服务、功能
|
||
4. 重复建设已有能力，出现功能重叠、资产重复存储的情况
|
||
5. 选型小众、无长期社区维护的开源项目，存在1年内停更风险
|
||
6. 出现跨层调用，破坏分层解耦架构
|
||
7. 为了跟风、尝鲜更换已有稳定运行的服务，无明确的核心场景价值提升
|