制造业 AI Agent 平台 — 分阶段架构设计
编制日期：2026-06-03 | agent平台架构方案
总体路线（先看全景，再看分步）
阶段 1
0-3个月
单场景验证
1个Agent
单体应用
SaaS云
→
阶段 2
3-9个月
部门级平台
5-15个Agent
模块化服务
私有化起步
→
阶段 3
9-18个月
企业级Agent OS
30-100个Agent
微服务+消息队列
混合云
→
阶段 4
18个月+
生态化全球复制
100+Agent
多云+边缘
开放市场
核心理念：不学上古中天一上来就做"大而全"的 OS，也不学灵核只做纯 SaaS 应用层。我们走中间路线——先轻量验证场景，再逐步建设平台能力，最终形成自己的 Agent OS。每一步都有明确的架构决策和升级触发条件。
第一步：阶段 1 — 单场景快速验证（0-3 个月）（现有demo里已经实现了）
1.1 阶段目标
用最小成本、最快速度跑通一个具体业务场景的 AI Agent，验证"这条路走得通"。
1.2 架构全景图
┌──────────────────────────────────────────────────────────────────────────────┐
│ 阶段 1 架构：单场景单Agent单体（最小可用） │
│ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ 用户接入 │ │
│ │ Web 控制台 + 企微/钉钉 bot │ │
│ └──────────────────────────────┬───────────────────────────────────────┘ │
│ │ HTTPS │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────────────────┐ │
│ │ 单体应用服务 (FastAPI) │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │
│ │ │ 用户/登录 │ │ 知识库 │ │ Agent │ │ 场景业务逻辑 │ │ │
│ │ │ (简单JWT) │ │ (RAG) │ │ 执行器 │ │ (如：合同审查) │ │ │
│ │ └──────────┘ └──────────┘ └────┬─────┘ └──────────────────┘ │ │
│ │ │ │ │
│ │ ┌─────────▼──────────┐ │ │
│ │ │ LLM 调用层（单路） │ │ │
│ │ │ DeepSeek API │ │ │
│ │ └────────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────┼────────────┐ │
│ ▼ ▼ ▼ │
│ ┌──────────────────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ SQLite / PostgreSQL │ │ 文件存储 │ │ LLM API (外网) │ │
│ │ (业务数据 + 向量) │ │ (本地) │ │ DeepSeek / Qwen │ │
│ └──────────────────────┘ └──────────┘ └──────────────────┘ │
└──────────────────────────────────────────────────────────────────────────────┘
1.3 组件清单与选型理由
| 组件 | 阶段 1 选型 | 为什么这么选 |
|---|
| 后端框架 | FastAPI（单体） | 开发快，现有 demo 直接复用 |
| 数据库 | PostgreSQL + pgvector | 业务数据 + 向量检索一套搞定 |
| 缓存 | 不需要 | 用户量少，不构成瓶颈 |
| LLM | DeepSeek API（云） | 按量付费，零硬件投入 |
| Embedding | BGE-M3（本地 CPU） | 免费，1024 维，中文效果好 |
| 文档解析 | MinerU / Unstructured | 开箱即用 |
| 前端 | React + Vite（现有 demo） | 直接复用 |
| 部署 | 单台云服务器 / 内网服务器 | Docker Compose 一键起 |
1.4 数据流（以"合同审查 Agent"为例）
用户上传
合同文件
→
文档解析
MinerU
→
文本切片
BGE-M3 Embedding
→
pgvector
向量存入
→
用户发起
审查请求
→
RAG 检索
+ Prompt 拼接
→
调用
DeepSeek API
→
解析结果
返回前端
1.5 阶段 1（防止过度设计）
1.6 第 3 个月结束 — 关键决策点
| 评估项 | 通过标准 | 不通过则 |
|---|
| Agent 解决真实业务问题 | 业务方验收通过，愿意日常使用 | 换场景重新验证 |
| LLM 响应可接受 | 首 token < 5 秒，完整响应 < 30 秒 | 换模型 / 加缓存 |
| 数据安全无风险 | 无敏感数据泄露，合规检查通过 | 提前引入私有化 |
| ROI 初步回正 | 省了人力或提了效率，有数字支撑 | 重新评估是否继续 |
→ 全部通过后，进入 阶段 2。
第二步：阶段 2 — 部门级平台（3-9 个月）（现有demo实现了部分，还待完善）
2.1 阶段目标
从一个 Agent 扩展到 5-15 个 Agent，覆盖 1-2 个部门的核心业务。平台基础能力（多租户、权限、Agent 市场、计费计量）开始搭建。
2.2 架构全景图
┌───────────────────────────────────────────────────────────────────────────────────────┐
│ 阶段 2 架构：模块化多Agent平台 │
│ │
│ ┌──────────────────────────────────────────────────────────────────────────────────┐ │
│ │ 接入层 │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ Web控制台 │ │ 企微/钉钉 │ │ iframe │ │ JS SDK │ │ OpenAPI │ │ │
│ │ │ │ │ 机器人 │ │ 嵌入 │ │ 悬浮窗 │ │ (API Key)│ │ │
│ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │
│ └───────┼──────────────┼──────────────┼──────────────┼──────────────┼───────────────┘ │
│ └──────────────┼──────────────┼──────────────┼──────────────┘ │
│ ▼ ▼ ▼ │
│ ┌──────────────────────────────────────────────────────────────────────────────────┐ │
│ │ API 网关 (Nginx/APISIX) │ │
│ │ JWT 鉴权 / API Key 鉴权 / 限流 / 路由 │ │
│ └────────────────────────────────────┬─────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────┼─────────────────────────────────────────────┐ │
│ │ 业务中台 (FastAPI 模块化，仍为单体) │ │
│ │ │ │ │
│ │ ┌───────────┐ ┌───────────┐ ┌──┴────────┐ ┌───────────┐ ┌───────────┐ │ │
│ │ │ 租户管理 │ │ 用户与权限 │ │ Agent市场 │ │ 计量计费 │ │ 集成管理 │ │ │
│ │ │(多租户隔离)│ │(RBAC+ABAC)│ │(模板+实例) │ │(Token计数) │ │(iframe/SDK)│ │ │
│ │ └─────┬─────┘ └─────┬─────┘ └─────┬──────┘ └─────┬─────┘ └─────┬─────┘ │ │
│ │ └──────────────┼──────────────┼───────────────┼──────────────┘ │ │
│ │ ▼ ▼ ▼ │ │
│ │ ┌────────────────────────────────────────────────────────────┐ │ │
│ │ │ Agent 执行内核（核心） │ │ │
│ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │
│ │ │ │ Prompt管理器 │ │ 工具调用层 │ │ 知识检索层 │ │ │ │
│ │ │ │ (模板渲染) │ │ (MCP协议) │ │ (RAG混合检索) │ │ │ │
│ │ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │ │
│ │ │ └────────────────┼──────────────────┘ │ │ │
│ │ │ ▼ │ │ │
│ │ │ ┌──────────────────────────────────────────────────┐ │ │ │
│ │ │ │ LLM 路由层 │ │ │ │
│ │ │ │ DeepSeek V3 (主力) / Qwen3 (兜底) / 本地(离线) │ │ │ │
│ │ │ └──────────────────────────────────────────────────┘ │ │ │
│ │ └────────────────────────────────────────────────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────┼─────────────────────────────────────────────┐ │
│ │ 数据层 │ │
│ │ ┌───────────┐ ┌───────────┐ ┌─────────────┐ ┌───────────┐ │ │
│ │ │ PostgreSQL│ │ Redis │ │ MinIO(S3) │ │ 企业系统 │ │ │
│ │ │ +pgvector │ │ 会话/限流 │ │ 文件存储 │ │ ERP/MES │ │ │
│ │ └───────────┘ └───────────┘ └─────────────┘ └───────────┘ │ │
│ └──────────────────────────────────────────────────────────────────────────────────┘ │
│ │
│ 部署方式：Docker Compose 一键部署，运行在 1-2 台服务器（或私有云） │
└────────────────────────────────────────────────────────────────────────────────────────┘
2.3 阶段 2 新增组件（相比 阶段 1）
| 新增组件 | 选型 | 解决什么问题 |
|---|
| 多租户体系 | tenant_id 全表隔离 + JWT 租户上下文 | 多个部门/客户数据完全隔离 |
| RBAC 权限 | Casbin / 自研 | 平台管理员、租户管理员、普通员工不同权限 |
| Agent 市场 | ai_agent_template（demo 已有） | AI 员工模板上架，租户按需招募 |
| 计量计费 | 自研 Token 计数器 + 套餐额度表 | 按 Token 数 / 调用次数 / 存储容量计费 |
| Redis 缓存 | Redis | 会话缓存、限流计数器、分布式锁 |
| 对象存储 | MinIO | 文档文件统一存储，不再存本地磁盘 |
| API 网关 | Nginx / APISIX | 统一鉴权、限流、路由 |
| LLM 路由 | 多模型切换层 | DeepSeek 主路 + Qwen3 兜底 + 本地离线备胎 |
| MCP 协议 | 自研 MCP Client | Agent 以标准协议调用外部工具 |
2.4 Agent 执行流程（阶段 2 完整版）
① 鉴权
JWT→租户ID
→权限点
→
② 限流检查
Redis QPS
Token配额
→
③ 加载Agent
模板+租户
配置
→
④ 构建上下文
会话历史+
RAG检索+文件
→
⑤ Prompt
渲染
→
⑥ 工具调用
MCP Client
(如需)
→
⑦ LLM 路由
主→备→兜底
→
⑧ 后处理
扣Token+审计
+Webhook
→
返回
结果
2.5 第 9 个月结束 — 关键决策点
| 评估项 | 通过标准 |
|---|
| 5+ Agent 稳定运行 | 日均调用 > 100 次，成功率 > 95% |
| 多部门实际使用 | 2+ 部门日常使用，非 IT 部门 |
| 知识库形成规模 | 至少 1 个知识库 > 1000 文档 |
| 计费体系跑通 | 能准确计量、出账单 |
| 单体性能未到瓶颈 | API P99 < 2 秒（不含 LLM） |
→ 全部通过后，进入 阶段 3。
第三步：阶段 3 — 企业级 Agent OS（9-18 个月）
3.1 阶段目标
从部门级平台升级为企业级 Agent 操作系统（对标上古中天 AgentOS）。30-100 个 Agent 覆盖全公司主要岗位。引入多 Agent 协同、自我进化闭环。架构从单体拆分为微服务。
3.2 架构全景图（五层完整版）
全貌
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ 第五层 · 应用层（Agent 应用市场） │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │
│ │ 内部提效智能体 │ │ 工业智能智能体 │ │ 全球增长智能体 │ │ 通用工具市场 │ │
│ └────────┬─────────┘ └────────┬─────────┘ └────────┬─────────┘ └────────┬─────────┘ │
│ └────────────────────┼─────────────────────┴────────────────────┘ │
│ │ │
│ 多端入口：Web控制台 │ 钉钉/企微/飞书 │ iframe内嵌 │ JS SDK │ OpenAPI │ 移动H5 │
└────────────────────────────────┬─────────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ 第四层 · 调度层（Agent OS 核心引擎） │
│ │
│ ┌──────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐ │
│ │ Agent 编排引擎 │ │ 任务调度引擎 │ │ 群控系统 │ │
│ │ LangGraph 状态图 │ │ Celery + RabbitMQ │ │ 多Agent并发管理 │ │
│ │ 顺序/并行/条件/循环 │ │ 优先级/重试/定时 │ │ Agent间通信总线 │ │
│ └──────────┬───────────┘ └──────────┬───────────┘ └──────────┬───────────┘ │
│ └─────────────────────────┼──────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────┼─────────────────────────────────────────────────┐ │
│ │ Skills / Tools / MCP 工具层（连接ERP/MES/CRM/PLC...） │ │
│ └────────────────────────────────────┼─────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────┼─────────────────────────────────────────────────┐ │
│ │ Human-in-the-Loop 人机协同层 —— 审核节点 / 干预修正 / 反馈评分 / 审批流集成 │ │
│ └────────────────────────────────────┼─────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────┼─────────────────────────────────────────────────┐ │
│ │ 自我进化闭环：执行→监控→评估→优化→沉淀 → (循环) ← 阶段 3 核心差异化能力 │ │
│ └────────────────────────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────┬───────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ 第三层 · 认知层（AI 大脑） │
│ │
│ LLM 推理集群(DeepSeek V3 / Qwen3-72B / Kimi K2) │ 多模态(Qwen2.5-VL / PaddleOCR / 语音) │
│ 行业微调模型(LoRA) │ 规划反思引擎(ReAct / Plan+Execute / Reflexion) │ 短期+长期记忆系统 │
└─────────────────────────────────────┬───────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ 第二层 · 数据层（企业记忆沉淀） │
│ │
│ PostgreSQL+pgvector │ Milvus(向量) │ Neo4j(知识图谱) │ TimescaleDB(时序) │ MinIO(对象存储) │
│ 消息中间件：RabbitMQ(任务队列) + Kafka(事件流) + Redis(缓存/锁) │
│ 数据治理：Flink CDC → ETL Pipeline → 数据血缘(Atlas) → 生命周期管理 │
└─────────────────────────────────────┬───────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ 第一层 · 算力层（基础设施） │
│ │
│ ┌──────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐ │
│ │ GPU服务器 ×2 │ │ CPU服务器 ×2 │ │ 存储服务器 ×1 │ │
│ │ 8×H20/H100 │ │ 鲲鹏/Xeon 64核 │ │ 100TB SSD+500T HDD │ │
│ │ LLM推理 + 模型微调 │ │ 知识图谱+数据治理 │ │ MinIO + 热数据 │ │
│ └──────────────────────┘ └──────────────────────┘ └──────────────────────┘ │
│ │
│ K8s + Istio(服务网格) │ ArgoCD(GitOps) │ Harbor(镜像) │ Vault(密钥) │ Prometheus+Grafana │
│ 阿里云/华为云GPU(弹性补充) │ 边缘推理节点(工厂现场) │ 灾备机房(异地容灾) │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
横向贯穿全栈：安全与治理
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ 国密SM2/SM4 │ RBAC+ABAC细粒度权限 │ 全链路审计日志 │ OT/IT隔离(工业网闸) │ 沙箱执行(gVisor) │ 等保合规 │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
3.3 阶段 3 新增组件（相比 阶段 2）
| 新增组件 | 选型 | 解决什么问题 |
|---|
| 消息队列 | RabbitMQ（任务）+ Kafka（事件） | 异步任务解耦、事件驱动 |
| 独立向量数据库 | Milvus | pgvector 不够用（百万级向量需专用库） |
| 图数据库 | Neo4j | 知识图谱关系推理，企业知识资产化 |
| 时序数据库 | TimescaleDB | 设备 IoT 数据、生产数据 |
| K8s 集群 | K8s + Istio | 微服务编排、灰度发布、自动扩缩 |
| 微服务拆分 | 从单体拆出 6-8 个服务 | 独立部署、独立扩缩、故障隔离 |
| LLM 本地推理 | vLLM 部署 Qwen3-72B | 断网可用、敏感数据不出厂 |
| 自我进化闭环 | 自研（5 步循环） | 越用越好，持续积累 |
| 知识图谱 | Neo4j + 自研抽取Pipeline | 从非结构化文档自动构建知识图谱 |
| API 网关升级 | Kong / APISIX | 微服务路由、多租户限流、插件化 |
| 全链路监控 | Prometheus + Grafana + SkyWalking + ELK | 全链路可观测 |
3.4 微服务拆分方案
阶段 2 单体 阶段 3 拆分
───────────── ────────────
┌─────────────────────┐ ┌─────────────┐ API网关
│ │ │ auth-svc │ 用户/权限/租户
│ FastAPI 单体应用 │ → │ agent-svc │ Agent执行/Prompt
│ (所有模块一起) │ │ kb-svc │ 知识库/RAG
│ │ │ billing-svc│ 计费/账单
│ │ │ market-svc │ 市场/模板
└─────────────────────┘ │ workflow-svc│ 编排/调度
│ integrate-svc│ 集成/iframe/SDK
│ audit-svc │ 审计/日志
└─────────────┘
服务间通信：HTTP REST（同步） + RabbitMQ（异步事件）
服务发现：K8s Service + Consul/Nacos
配置管理：Nacos 集中配置
链路追踪：SkyWalking
3.5 多 Agent 协同工作模式（阶段 3 引入）
阶段 2（单Agent） 阶段 3（多Agent协同）
───────────────── ─────────────────────
用户 → Agent → 结果 用户 → 总协调Agent
│
┌────────────┼────────────┐
▼ ▼ ▼
Agent A Agent B Agent C
(数据查询) (分析推理) (报告生成)
│ │ │
└────────────┼────────────┘
▼
结果汇总 → 用户
四种协同模式：
1. 顺序链式：A → B → C → 结果
2. 并行分派：一个问题同时问 A、B、C，汇总最优答案
3. 条件路由：根据用户意图，路由到不同的专家 Agent
4. 人机协同：Agent 遇到高置信度决策时，暂停等待人工审核
3.6 自我进化闭环（阶段 3 核心差异化）
① 执行
Agent 执行
任务
→
② 监控
全链路追踪
耗时/质量
→
③ 评估
结果打分
用户反馈
→
④ 优化
Prompt调整
Tool更新
→
⑤ 沉淀
知识写入
知识图谱
→
回到①
下次更好
这是对标上古中天"五步循环"但同时对标灵核"记记空间"知识沉淀的设计——既有自动化闭环，也有人工反馈入口。
3.7 第 18 个月结束 — 关键决策点
| 评估项 | 通过标准 |
|---|
| 30+ Agent 覆盖 | 至少覆盖 3 个部门的 30 个岗位场景 |
| 知识图谱 > 10 万实体 | 实体关系和业务规则可被 Agent 调用推理 |
| 自我进化闭环跑通 | 至少 1 个 Agent 经反馈迭代后准确率提升 10%+ |
| 系统可用性 > 99.9% | 无单点故障，单服务故障不影响整体 |
| 运维成熟度 | 自动化部署、监控告警、日志排查达标 |
→ 全部通过后，进入 阶段 4。
第四步：阶段 4 — 生态化与全球复制（18 个月+）
4.1 阶段目标
从企业级平台升级为开放生态平台。支持多语言、多时区、跨工厂/跨国部署。开放 Agent 市场生态供外部开发者贡献。
4.2 架构全景图
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ 阶段 4 架构：开放生态 + 多云 + 全球化 │
│ │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐ │
│ │ 接入层（全球化） │ │
│ │ │ │
│ │ 中国大陆 ────────┐ ┌────────── 东南亚 │ │
│ │ 欧洲 ────────────┼────────────────────────┼─────────── 北美 │ │
│ │ 中东 ────────────┘ ┌─────────┴─────────────┐ │ │
│ │ │ 全局 DNS 智能解析 │ │ │
│ │ │ (就近接入、合规路由) │ │ │
│ │ └───────────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────────────────┼──────────────────────────────────────────┐ │
│ │ 开放生态层 │ │
│ │ ┌──────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐ │ │
│ │ │ Agent 应用市场 │ │ Skills 插件市场 │ │ 行业解决方案市场 │ │ │
│ │ │ · 平台官方Agent │ │ · MCP Server 上传 │ │ · 汽车/电子/医药 │ │ │
│ │ │ · 第三方开发者Agent │ │ · 社区贡献工具 │ │ · 模板化部署 │ │ │
│ │ │ · 企业内部贡献Agent │ │ · 付费/免费工具 │ │ │ │ │
│ │ │ · 评分/评论/计费 │ │ │ │ │ │ │
│ │ └──────────────────────┘ └──────────────────────┘ └──────────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────────────────┼──────────────────────────────────────────┐ │
│ │ 多云调度层 │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 私有云（总部）│ │ 阿里云 │ │ 华为云 │ │ AWS/Azure │ │ │
│ │ │ 核心Agent OS │ │ 弹性推理 │ │ 国产化区域 │ │ 海外区域 │ │ │
│ │ │ 敏感数据 │ │ 非敏感Agent │ │ 信创合规 │ │ 全球加速 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ │ 跨云编排：K8s Federation / Terraform / Crossplane │ │
│ └──────────────────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────────────────┼──────────────────────────────────────────┐ │
│ │ 边缘计算层 │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 工厂A │ │ 工厂B │ │ 工厂C │ │ 海外工厂D │ │ 海外工厂E │ │ │
│ │ │ 轻量推理 │ │ 轻量推理 │ │ 轻量推理 │ │ 轻量推理 │ │ 轻量推理 │ │ │
│ │ │ Qwen-7B │ │ Qwen-7B │ │ Qwen-7B │ │ Qwen-7B │ │ Qwen-7B │ │ │
│ │ │ +本地PLC │ │ +本地PLC │ │ +本地MES │ │ +本地PLC │ │ +本地MES │ │ │
│ │ │ 断网可用 │ │ 断网可用 │ │ 断网可用 │ │ 断网可用 │ │ 断网可用 │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │
│ │ 边缘与中心同步：KubeEdge / OpenYurt + 知识库增量同步 │ │
│ └──────────────────────────────────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
4.3 阶段 4 新增能力
| 新增能力 | 说明 |
|---|
| 开放 Agent 市场 | 第三方开发者可上传 Agent/Skills，类似 App Store，平台抽成 |
| 多语言支持 | i18n 国际化，支持中/英/日/韩/德等制造业主要语言 |
| 多地部署 | 中国/东南亚/欧洲/北美各自部署就近节点 |
| 边缘推理节点 | 每个工厂部署轻量推理节点（Qwen3-7B），断网可用 |
| 跨云编排 | 私有云 + 阿里云 + 华为云 + AWS，Terraform 统一管理 |
| 联邦学习（可选） | 跨工厂共享模型能力但不共享原始数据 |
| 信创适配 | 适配国产 CPU（鲲鹏/飞腾）+ GPU（昇腾）+ OS（麒麟/欧拉） |
| 灾备升级 | 两地三中心 → 异地多活 |
未来可能的升级方向（阶段 5+）
| 方向 | 说明 | 触发条件 |
|---|
| 自研行业大模型 | 从 LoRA 微调 → 从头训练制造业垂直大模型 | 行业数据积累 > 10TB 高质量文本 |
| AI 一体机产品化 | 把你的平台打包成一体机售卖（对标上古中天） | 私有化需求 > 20 家客户 |
| 具身智能 Agent | Agent 直接控制工业机器人/AGV/机械臂 | 产线自动化程度足够 |
| 数字孪生融合 | Agent 平台与工厂数字孪生系统融合 | 已有数字孪生基础设施 |
| 行业标准制定 | 主导制定制造业 Agent 行业标准 | 市场占有率行业前三 |
各阶段技术栈总览
| 层次 | 阶段 1 | 阶段 2 | 阶段 3 | 阶段 4 |
|---|
| 接入层 | Web + Bot | + iframe/SDK/API | + 移动H5/飞书 | + 全球多端 |
| API网关 | 无 | Nginx/APISIX | Kong | Kong(多区域) |
| 业务层 | 单体 FastAPI | 模块化 FastAPI | 微服务(8+服务) | 微服务+Serverless |
| 编排引擎 | 硬编码 | LangChain | LangGraph | LangGraph+自研 |
| 消息队列 | 无 | 无 | RabbitMQ+Kafka | Kafka集群 |
| 数据库 | PG+pgvector | PG+pgvector+Redis | +Milvus+Neo4j+时序 | +ClickHouse |
| 文件存储 | 本地磁盘 | MinIO | MinIO集群 | 多云对象存储 |
| LLM推理 | 云API | 云API+本地兜底 | vLLM+私有化 | 云+本地+边缘 |
| 容器 | Docker Compose | Docker Compose | K8s+Istio | K8s Federation |
| 监控 | 无 | Prometheus基础 | 全链路观测 | AIOps |
| 部署 | 单台服务器 | 1-2台私有服务器 | 3-5台一体机 | 多云+边缘 |
| Agent数 | 1个 | 5-15个 | 30-100个 | 100+（含社区） |
升级触发条件速查
| 当出现以下情况时 | 执行对应的升级动作 |
|---|
| 单个 Agent 被业务方验收通过 | 阶段 1 → 阶段 2 |
| Agent 日均调用量 > 100 | 引入 Redis 缓存 |
| 租户数 > 5 | 强化多租户隔离方案 |
| 文档数 > 10000 | 引入独立向量数据库 Milvus |
| API 响应 P99 > 2秒（不含LLM） | 单体拆分，引入消息队列 |
| Agent 数 > 15 | 引入 Agent 编排框架 LangGraph |
| 跨部门协作需求出现 | 引入多 Agent 协同 |
| 知识库准确率不再提升 | 引入知识图谱 + 自我进化闭环 |
| 数据安全合规要求 | 引入私有化一体机 |
| 跨工厂/跨国需求出现 | 边缘节点 + 多云部署 |
| 第三方想贡献 Agent | 开放 Agent 市场 |
| 工厂断网场景 | 边缘推理节点（轻量模型本地跑） |
与竞品的架构差异（我们的差异化设计）
| 维度 | 灵核 LinkCrux | 上古中天 AgentOS | 我们的方案 |
|---|
| 架构抽象 | 扁平（岗位→技能→连接） | 五层OS（固定） | 五层OS + 分阶段演进 |
| 起步方式 | SaaS 纯云 | 一体机重型起步 | 轻量云验证 → 逐步私有化 |
| 生态策略 | "派派市场"（封闭） | 无独立市场 | 开放市场 + MCP 标准 |
| 知识管理 | "记记空间"（沉淀） | "知识库治理"（主动管理） | 被动沉淀 + 主动治理 + 图谱化 |
| 自我进化 | 未明确 | 五步闭环 | 量化闭环：准确率追踪 + 自动优化 |
| 多Agent | 蜂群协同 | 协同矩阵 | LangGraph 编排 + 人机协同审核点 |
| MCP支持 | 未提及 | 未提及 | 一等公民，所有工具走 MCP 标准 |
核心差异化：我们不学上古中天一上来就做重型 OS，也不学灵核只做应用层。我们的方案是"渐进式 OS"——先用轻量 SaaS 验证场景，验证通过后逐步把 Agent 编排、知识图谱、自我进化闭环自建起来。每一步都有明确的架构决策和升级触发条件，知道什么时候该加什么、什么时候不该加。
专题：桌面客户端架构方案
结论先行：加桌面客户端对现有架构影响很小——接入层多一个端，后端加一个设备认证流和推送通道。90% 的前端代码可从 Web 端复用。
1. 桌面端在整体架构中的位置
┌───────────────────────────────────────────────────────────────────────────────────────┐
│ 接入层（阶段 2+ 新增桌面端入口） │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Web控制台 │ │ 企微/钉钉 │ │ iframe │ │ JS SDK │ │ OpenAPI │ │ 桌面客户端│ ← 新增 │
│ │ │ │ 机器人 │ │ 嵌入 │ │ 悬浮窗 │ │ (API Key)│ │(Electron)│ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ └─────────────┴─────────────┴─────────────┴─────────────┴────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────┐ │
│ │ API 网关 (APISIX) │ ← 不新增任何接口 │
│ │ JWT / API Key / 限流 │ 仅新增 Device Auth 认证流 │
│ └─────────────────────────┘ │
└───────────────────────────────────────────────────────────────────────────────────────┘
2. 桌面客户端内部架构
┌──────────────────────────────────────────────────────────────────────────────┐
│ Electron 桌面客户端（内部架构） │
│ │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ Renderer (React) │ │
│ │ ┌────────────────────────────────────────────────────────────────────┐ │ │
│ │ │ 复用现有 frontend-portal 90% 的 UI 代码 │ │ │
│ │ │ │ │ │
│ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │
│ │ │ │ Agent市场 │ │ 对话中心 │ │ 知识库 │ │ 合同审查 │ │ 管理后台 │ │ │ │
│ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │ │
│ │ └────────────────────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
│ │ IPC │
│ ┌─────────────────────────────────▼───────────────────────────────────────┐ │
│ │ Main Process (Node.js) │ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 窗口管理 │ │ 自动更新 │ │ 本地存储 │ │ 系统托盘 │ │ │
│ │ │ BrowserWindow │ │ electron- │ │ better- │ │ Tray + │ │ │
│ │ │ 多窗口/分屏 │ │ updater │ │ sqlite3 │ │ 通知+菜单 │ │ │
│ │ └──────────────┘ └──────────────┘ └──────┬───────┘ └──────────────┘ │ │
│ │ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────┴───────┐ ┌──────────────┐ │ │
│ │ │ 文件系统集成 │ │ 截图/录屏 │ │ 离线消息队列 │ │ 本地推理 │ │ │
│ │ │ 拖拽上传 │ │ desktop- │ │ msg-queue │ │ llama.cpp │ │ │
│ │ │ 文件夹监听 │ │ capturer │ │ (断网缓存) │ │ (阶段3+) │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
│ │ HTTPS + WSS │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ 后端 API 服务 │ ← 与 Web 端完全共用 │
│ │ (不需新增接口) │ │
│ └─────────────────────┘ │
└──────────────────────────────────────────────────────────────────────────────┘
3. 桌面端独有的能力（Web 端做不到的）
| 能力 | 实现方式 | 制造场景价值 | 引入阶段 |
|---|
| 本地文件拖拽上传 |
Electron 原生文件对话框 + 拖拽区域，支持批量文件/文件夹，自动解析 PDF/DWG/DXF/STEP |
工程师直接拖图纸文件夹进 Agent，不用一个个上传 |
阶段 1→2 |
| 系统级通知推送 |
Electron Notification API + WebSocket 长连接，Agent 任务完成、审查结果出来时弹窗提醒 |
不用盯着浏览器，后台跑着任务，完成自动弹窗 |
阶段 2 |
| 截图/录屏输入 |
desktopCapturer + 剪贴板监听，截图直接粘贴到对话里让 Agent 分析 |
产线异常拍照 → Agent 识别 → 给出处理建议，一气呵成 |
阶段 2 |
| 离线消息缓存 |
better-sqlite3 本地存储，断网时消息暂存本地队列，网络恢复后自动重发 |
车间网络不稳定时，消息不丢 |
阶段 2 |
| 本地小模型推理 |
llama.cpp / Ollama 嵌入 Electron，跑 Qwen3-1.8B/4B 量化版（仅需 2-4GB 内存） |
完全断网时也能用基础 Agent：文档摘要、OCR、简单问答 |
阶段 3 |
| 开机自启动 + 系统托盘 |
Electron auto-launch + Tray，最小化到托盘，后台常驻 |
Agent 像"数字员工"一样始终在线，随时呼出 |
阶段 2 |
4. 各 阶段 桌面端的能力演进
| 阶段 | 桌面端形态 | 说明 |
|---|
| 阶段 1 |
不单独做桌面端 |
用 Web 端 + 企业微信 bot 就够了，验证场景优先 |
| 阶段 2 |
Electron 壳 + Web 套壳 |
复用全部 Web UI，加文件拖拽、系统通知、托盘常驻、离线缓存。投入：1 个前端工程师 2-4 周 |
| 阶段 3 |
+ 本地小模型推理 |
嵌入 llama.cpp + Qwen3-4B 量化模型，断网也能用基础能力。投入：额外 1-2 周适配 |
| 阶段 4 |
+ 工厂专用客户端 |
对接 PLC/DCS 数据采集、串口扫码枪、工业平板适配（Win 触屏 + 防爆安卓） |
5. 后端需要新增的能力
| 新增能力 | 说明 | 复杂度 |
|---|
| Device Auth 认证流 |
OAuth 2.0 Device Authorization Grant。桌面端显示一个短码，用户在手机/Web 上确认登录，不用在客户端输密码 |
低，1-2 天开发 |
| 长 Refresh Token |
桌面端 Token 有效期 30 天（Web 端 24 小时），支持"记住我"，JWT 里加 device_id 字段用于远程踢下线 |
低，改 JWT 配置 |
| WebSocket 推送通道 |
长连接推送通知（Agent 任务完成、审查结果等），替代轮询。复用已有 Webhook 事件体系 |
中，FastAPI WebSocket 或独立 Socket.IO 服务 |
| 设备管理 API |
租户管理员可查看/管理已登录设备列表，远程踢下线。审计日志记录设备信息 |
低，CRUD |
6. 桌面端的多租户与安全
- 登录态隔离：每个桌面端拥有独立的 device_id + refresh_token，不与其他端共享登录态
- 数据不落地（默认）：敏感文档不上传到本地缓存，仅在内存中处理；可配置"允许离线缓存"开关
- 远程擦除：租户管理员可以在后台对某个设备执行"远程退出 + 清除本地数据"（通过 WebSocket 指令）
- 本地推理数据隔离：本地小模型推理完全在本地完成，数据不经过服务器，满足极端安全需求
- 代码完整性校验：Electron 打包时启用 ASAR 加密 + 代码签名，防止篡改
7. 技术选型
| 组件 | 推荐 | 备注 |
|---|
| 框架 | Electron 33+ | 直接复用 React 前端，90% UI 共享 |
| 自动更新 | electron-updater (electron-builder) | 增量更新、静默安装、强制更新策略 |
| 本地数据库 | better-sqlite3 | 轻量、与 PostgreSQL 的 SQL 兼容 |
| 本地向量检索 | sqlite-vec | 与 better-sqlite3 同一进程，零额外依赖 |
| 本地推理引擎 | llama.cpp (node-llama-cpp) | CPU 即可跑 4B 量化模型，2-4GB 内存 |
| 打包 | electron-builder | Win/Mac/Linux 三端，NSIS/DMG/AppImage |
| 代码保护 | bytenode + ASAR 加密 | 防止 Electron 主进程源码泄露 |
关键判断：桌面客户端对后端架构几乎零影响。API 完全复用，仅新增 Device Auth + WebSocket 推送。它本质上是把你的 Web 前端用 Electron 包了一层，外加本地文件系统、通知、离线缓存和本地推理能力。如果你 阶段 2 的 OpenAPI 和 JS SDK 都做好了，加桌面端只是个纯前端工程工作。
附录：现有 Demo 与目标架构的差距分析
基于 E:\demo\agentjuhe 已有能力（FastAPI 后端 + React 前端 + JS SDK）：
✅ 已有能力（可直接复用）
| 能力 | 对应阶段 |
|---|
| 多租户 JWT + API Key | 阶段 2 |
| RBAC 权限模型 | 阶段 2 |
| Agent 市场（模板+实例） | 阶段 2 |
| 计量计费（Token/套餐） | 阶段 2 |
| 知识库 RAG (pgvector) | 阶段 2 |
| iframe / JS SDK / OpenAPI | 阶段 2 |
| Webhook 事件 | 阶段 2 |
| 审计日志 | 阶段 2 |
| 合同审查 Agent | 阶段 1 |
🔜 待建设能力
| 能力 | 阶段 |
|---|
| 真实 LLM 接入 | 阶段 1→2 |
| Agent 编排 (LangGraph) | 阶段 3 |
| 多 Agent 协同 | 阶段 3 |
| MCP 协议支持 | 阶段 2→3 |
| 知识图谱 (Neo4j) | 阶段 3 |
| 自我进化闭环 | 阶段 3 |
| 消息队列异步化 | 阶段 3 |
| K8s 微服务化 | 阶段 3→4 |
| 私有化一体机 | 阶段 3 |
| 边缘推理节点 | 阶段 4 |
| 开放 Agent 市场 | 阶段 4 |
版本 V1.0 | 编制日期：2026-06-03 | agent平台架构方案