架构] 企业级AI应用的架构设计（参考蓝图）

0 序

梳理、总结此篇，以作为企业级AI Agent系统设计的理想蓝图、参考图纸。

理解了此篇，也就任意理解市面上的各类AI Agent项目的所处位置了。

AI Agent 的一般运行流程

交互接入层：接收用户 / 事件请求，鉴权、预处理
Agent 编排模块： Router 识别意图，加载【记忆层】会话上下文、召回相关长期记忆 & 业务知识库
Agent 规划模块：生成任务计划，ReAct 循环思考，选择 Skill 工具
下发到【工具执行层】做参数校验，调用【企业能力集成层】访问业务系统
获取执行结果，返回【编排层做反思校验，判断是否完成；失败触发重试 / 人工介入
状态 Checkpoint 保存记忆；【审计层】记录全链路日志
格式化输出，返回【交互层】给到用户

1 企业级AI应用的架构设计

架构设计

flowchart TD %% 全局样式设置 classDef layerFill fill:#F0F4FF,stroke:#4A72B8,stroke-width:2px,color:#1E293B,font-weight:bold; classDef coreFill fill:#EBF3FF,stroke:#2563EB,stroke-width:2px,color:#0F172A,font-weight:bold; classDef sideFill fill:#F8FAFC,stroke:#64748B,stroke-width:2px,color:#334155; classDef infraFill fill:#F1F5F9,stroke:#94A3B8,stroke-width:1.5px,color:#475569; %% 0. 治理与可观测平台（侧边纵向管理） subgraph GOV["AI Governance Platform"] direction TB G1["Observability & Evaluation"] G2["Guardrails & Security"] G3["Identity & Audit"] end %% 1. 访问接入层 subgraph L1["AI Interface Layer"] direction LR I1["Chat / Copilot"] --- I2["Web / Mobile App / API"] --- I3["Agent-to-Agent"] end %% 3. Agent 核心平台 subgraph L2["AI Agent Platform"] direction TB subgraph L2_1["Orchestrate & Manage"] direction LR M1["Workflow & Multi-Agent Orchestration"] M2["Agent Registry & Lifecycle"] end subgraph L2_2["Agent Runtime (运行时)"] direction LR R1["Reasoning Planning Reflection"] R2["Memory Engine Context Engine"] R3["State & Checkpoint"] R4["Skills Tool Use"] end end %% 4. 模型平台与工具/能力平台 subgraph L3_MODEL["Model Platform"] direction TB MP1["Model Gateway & Routing"] MP2["Inference Serving & Evaluation"] MP3["LLM / Multi-Modal / Fine-tuning"] end subgraph L3_TOOL["Tool/Capability Platform (工具与能力集成平台)"] direction TB TP1["Tool Gateway"] TP2["Tool Registry & Discovery (APIs / MCP)"] TP3["Tool Policy/Auth"] TP4["Tool Execution : Direct Exec Sandbox Runtime"] end %% 5. 存储、数据与业务层 subgraph L4_KNOW["Knowledge Platform"] KP1["ETL & Hybrid Search (RAG)"] KP2["Knowledge Graph & Vector Rules"] end subgraph L4_DATA["Data Platform"] DP1["Data Warehouse & Lakehouse"] end subgraph L4_BUSINESS["Business Systems"] BS1["ERP / CRM / MES / HR / OA / ..."] end %% 6. 基础设施底座 subgraph L5_INFRA["Infrastructure (基础设施)"] direction LR INF1["存储: Vector DB (Milvus/pgvector) & Graph & Relational DB & Object Storage & Kafka & NoSQL"] INF2["计算: GPU & CPU"] INF3["虚拟化/调度: K8s / ..."] end %% 数据流与控制流连接关系 L1 -->|"请求接入"| L2 L2 -->|"模型推理"| L3_MODEL L2 -->|"能力调用"| L3_TOOL L3_TOOL -->|"向量/知识检索"| L4_KNOW L3_TOOL -->|"数据读写"| L4_DATA L3_TOOL -->|"业务读写"| L4_BUSINESS L3_MODEL -->|"推理计算"| L5_INFRA L4_KNOW --> L5_INFRA L4_DATA --> L5_INFRA L4_BUSINESS --> L5_INFRA %% 治理贯穿连接 %% GOV -.->|"全链路监控与安全防护"| L2 %% GOV -.->|"审计与安全策略"| L3_TOOL %% 应用样式 class L1 layerFill; class L2 coreFill; class L3_MODEL,L3_TOOL sideFill; class L4_KNOW,L4_DATA,L4_BUSINESS sideFill; class L5_INFRA infraFill; class GOV layerFill;

AI Interface Layer/AI交互层 : 负责与终端用户或外部系统交互，处理协议转换、会话管理、流式响应（SSE/WebSocket）及多模态输入输出。

职责

多通道接入：Web、IM、API、Webhook、业务系统事件流、语音、文件上传

请求预处理、鉴权、参数标准化、输入过滤、会话会话 ID 管理；把外部输入转为 Agent 内部统一事件格式

输出结果格式化、多模态返回；支持人工介入节点（Human‑in‑the‑loop）

Chat
Copilot
Web / Mobile App / Embeding AI
Business Applications
API / SDK
Agent-to-Agent
xxx
开源组件
- 前端控制台/对话 UI：NextChat、Open WebUI、Lobe Chat、...
- API 网关：FastAPI、Golang 网关、LangGraph‑API Gateway；Dify 网关、Spring Cloud Gateway、APISIX（支持插件化扩展 AI Gateway 功能）、...
- 消息通道（商业+开源）：Slack / 企业微信 / 钉钉适配器、Kafka 消费事件驱动 Agent 触发、...

AI Agent Platform/AI智能体平台

Agent Ochestration/Agent 编排与工作流: 整个Agent执行流程的核心调度器,接受 AI Interface Layer 的调用;管理复杂业务逻辑、多Agent协作模式（如Supervisor/Swarm模式）及确定性的DAG流程控制，确保Agent在可控轨道内运行
- Agent Ochestration/Agent编排
  - 开源组件:
    - 图逻辑与状态机驱动型（企业级确定性编排首选）
      - LangGraph (LangChain 开源: 状态图、checkpoint、循环、分支)
        
        当前企业级 Agent Runtime 的绝对事实标准、企业级首选。
        
        通过 DAG/有向图显式定义状态转移（State）、断点（Checkpoint）和人工干预，极度适合复杂商业逻辑。
      - AgentScope (阿里巴巴开源)
        
        高并发、分布式、基于 Actor 模型的 Agent Runtime，专为大规模多 Agent 协作和高吞吐场景设计
    - 自动化/代码执行与多 Agent 协作型
      - AutoGen (微软开源)：多 Agent 对话协同框架的先驱，擅长解决复杂的代码编写与多角色会话决策。（AG2）
      - CrewAI：以“角色（Role）- 任务（Task）- 团队（Crew）”为抽象的 Agent 编排框架，极易上手。
    - 低代码、快速POC、可视化工作流与应用引擎型（快速业务落地）
      - Dify：全球最火爆的 Agent 编排与应用开发平台之一，可视化 DAG 工作流与 RAG 引擎的集大成者，企业 MVP 选型首选
      - Flowise：基于 Node.js/LangChain 的可视化 Agent 流程编排工具
- Multi-Agent Orchestrator：管理多 Agent 间的通信、任务分发与状态同步；角色分发、消息通信、结果聚合（复杂场景）
- Workflow/工作流
  - 工作流与可视化：Dify（可视化编排与快速 MVP）、Flowise
Agent Management/Agent管理
- Agent Registry: Agent 注册、发现、生命周期
- Agent Definition: Agent 身份、角色、目标/职责、配置
- Agent Version&Release: Agent 的版本管理与发布
Agent Runtime/Agent运行时: Agent 核心决策层，Agent 的“大脑”与“手脚”，实现基于 ReAct、Plan-and-Solve 等范式的思考、记忆与工具调用
- Reasoning/推理: 推理、判断、决策（包括但不限于：识别业务目标，选择 Agent/Skill，避免大模型无边界自由发挥）
- Planning/规划: 任务拆解、执行计划；此外还可：ReAct 循环推理；Plan‑Execute 生成执行计划
  - 规划器的实现：LLM 原生 Prompt 规划；HTN 分层任务规划；少量硬编码规则兜底
- Reflection/反思机制: 校验工具返回结果、判断是否达成目标、错误重试、自我修正
- CoT/思维树、图推理
- State&Checkpoint/任务状态: Checkpoint 断点，任务中断后可恢复，不用从头跑
- Memory Engine: 短期记忆 + 情景记忆 + 长期记忆
- Context Engine/上下文引擎: 构造当前 LLM Context
- Tool Use/工具调用 (Function Calling)？如何定义边界
- Skills/技能: Agent 可复用的能力抽象（对完成某个任务所需的流程、工具、经验/认知的能力抽象）
  - Skill Registry
  - Skill Execution
- 开源选型
  - 核心框架：
    - LangChain / LlamaIndex（Java 生态推荐 Spring AI 或 LangChain4j）
    - Pi-Agent : 一种非常优秀的、聚焦于轻量级与编码领域（Coding Agent）的轻量级 Agent Runtime 框架。
      - 备注：相比 LangGraph / Dify, Pi-Agent (pi-agent-core) 侧重于极简、轻量级、面向终端/编码/高响应要求的本地 Agent 运行时。
      - pi-ai：统一 LLM 接入层（屏蔽 20+ 模型供应商接口差异）
      - pi-agent-core：纯粹的 Agent Runtime（引擎），只负责管理“思考 -> 调工具 -> 看结果 -> 再思考”的事件循环（Agent Loop），不绑定任何特定场景
      - pi-coding-agent：应用与产品层，基于 pi-agent-core 实现的具体编程 Agent（命令行 TUI/Web UI）
  - 工具协议扩展：Model Context Protocol (MCP)（标准化的上下文与工具对接协议）
  - 观测调试：LangSmith(追踪每一步思考、工具调用、token 消耗，排错审计必备)

为什么会叫 Agent Runtime？

如果把 LLM 比作 CPU，那么 Agent Runtime 就是操作系统（OS）的进程调度器与内核。它负责管理一个 Agent 从“接收输入”到“完成任务”的整个生命周期状态。
下述这些要素，确实恰好构成了 Agent Runtime 的标准架构拓扑：

Memory & Context：运行时的内存管理（短存、长存、滑动窗口截断）。

Planning & Reasoning：运行时的CPU 执行逻辑/调度器（ReAct 循环、Plan-and-Solve 循环）。

Checkpoint & State：运行时的持久化与快照（如 LangGraph 的状态持久化，允许 Agent 在任意步骤挂起、人工介入 Human-in-the-loop 后恢复）。

Skills & Tool Use：运行时的 I/O 设备驱动与指令集扩展。
架构层面的语义对齐：在写架构设计文档时，使用 Agent Runtime 往往比叫“核心决策层”显得更专业、更具工程感。

Context Engine/上下文引擎

推荐文献

Context Engineering/上下文工程 - 博客园/数据知音

Prompt Engineering/提示词工程 - 博客园/数据知音

本质对比：

提示词工程：定义任务目标、角色、规则、输出范式；解决模型意图对齐、行为约束、输出范式。
上下文工程：筛选、裁剪、排序、压缩、组装送入窗口的全部信息；解决有限窗口内信息质量与利用率问题——即：解决稀缺 token 预算、丢失‑in‑middle、上下文溢出问题
记忆组件: 突破LLM上下文窗口限制，跨轮次、跨会话保存Agent状态、历史事实、用户偏好；实现长期知识沉淀；解决跨窗口状态留存、历史信息复用问题。

Memory/记忆模块

推荐文献

[AI/Agent/记忆] AI Agent之记忆组件 - 博客园/数据知音

[AI/Agent/Memory/RAG] 辨析：AI Agent 的记忆组件(Memory) vs 知识库系统(Knowledge) - 博客园/数据知音

Model Platform/模型平台

模块职责

统一接入云端 API 与自托管开源模型

按任务复杂度/成本/延迟做模型路由（Model Router）

支持热切换，防止厂商锁定

Model Gateway/模型网关
Model Registry/模型注册与接入
- LLM(大语言模型) Model / VL Model(视频语言模型) / TTS Model(文本语言模型)
- Embeding Model(嵌入模型) / Reranker(重排序模型)
Model Routing/模型路由
Model Access / API
Inference Serving/推理服务
Model Evaluation/模型评估
Fine-tuning / Adaptation: 微调、适配
Model Cost / Performance: 模型成本、模型性能
...
组件选型:
- 模型网关：
  - LiteLLM：57.5k star，统一代理 + SDK，一套 OpenAI-compatible 接口路由到 100+ 模型，内置重试/降级/成本控制/OTEL 回调，是企业模型网关的首选（轻量级、高性能的 LLM 推理框架，专注于优化 GPU 利用率和推理效率）
  - OneAPI 36.6kstar
  - RouteLLM 5.4k star
- 推理加速引擎：
  - vLLM（高吞吐量 PagedAttention 引擎）、SGLang
  - Ollama（轻量级、侧重于【本地】测试） 180k star
  - TGI
- 模型策略：云端 API（GPT-5.5 / Claude Sonnet 4.6）起步 → 业务量增长后引入 Llama 3 / Qwen / DeepSeek 等开源模型处理特定任务，形成混合模型策略
推荐文献

[AI/Model/Gateway] LLM Gateway 组件选型：LiteLLM / One API / RouteLLM / Ollama - 博客园/数据知音

Tool Platform (Capability Platform)/工具与能力集成层: 面向AI Agent提供【能力实体】

Tool发现 → 鉴权 → 路由 → 执行

执行：本地执行(文件/浏览器/...)、调用知识平台/数据平台/业务系统

Tool Gateway
Tool Registry/工具注册 (例如:)
├── search_customer
├── create_order
├── query_sales
├── python_execute
└── browser
└── ...
Tool Policy/工具权限
Tool Execution/工具执行
- Direct Execution/直接执行
- Sandbox Runtime/沙箱运行时: 把工具执行放进一个资源、网络、文件和身份都受控的隔离环境（让Agent能干活儿，但不能串门）
 - 4层一起工作:
 - Control面(目标 --> TaskSpec --> 调度与生命周期)
 - Execution面(Agent + 代码 + 私有工作区)
 - Policy面(每次行动前：允许/拒绝/需要审批; 风险越高，边界越硬；隔离粒度，按风险划分：普通查询-进程级隔离、代码执行-容器、高风险与多租户-微虚拟机或虚拟机)
 - Evidence面(Artifact/产物、重验、审批与真实世界发布)
 - 4大关键问题: 任意Linux二进制？代码与租户的可信度？冷启动与密度？状态与恢复方式？
 - 网络出口：默认拒绝所有，再按Task Spec开放
 - 方案1: Container （共享内核）: 适合侧重【兼容性】、【工具生态】的场景
 - Agent Process -> Host Linux Kernel （优点:快、兼容性好、共享内核；缺点: 攻击面仍在宿主机的内核）
 - 具体组件: Docker / Kubernetes Pod
 - 方案2: gVisor （用户内核）
 - Agent Process --> Sentry + Gofer --> Host Kernel (兼容性稍差、syscall中介)
 - 具体组件: gVisor (Google 开源，在用户空间实现 Linux 系统调用的拦截和处理，不需要 KVM；适合场景：不支持 KVM，需要在现有 Docker 设施上快速叠加安全层)
 - 方案3： MicroVM （硬件级VM）
 - Agent Process --> Guest Kernel --> KVM / Host （强租户边界、成本更高）
 - 具体组件： Firecracker VM（由 AWS 开发，专为 Serverless 场景设计，是 Lambda 和 Fargate 的底层技术。）
 - 方案4： Wasm （Capability ABI）
 - Wasm Module(无模棱两可的访问) <--> Explicit Imports/显式导入（轻量、细粒度、兼容受限）
 - ... （上述方案，自上而下：兼容性/工具生态：好-->差；隔离边界：差-->好）
 - 补充方案: 沙箱云服务
 - 把 sandbox 能力产品化、云服务化，专门服务 AI Agent 代码执行场景。
 - 具体组件:E2B
 - 其他组件: Daytona / Modal
开源组件
- 开发 SDK (Python): 用于将内部 Python 代码、本地函数包装为标准的 MCP 工具服务。
  - MCP Python SDK
  - FastMCP(Python生态中实现 Anthropic 主导的 MCP 协议的高级 SDK。它大大降低了将企业现有 Python 函数、数据库查询或微服务包装为 MCP Server 的门槛)
- 开发 SDK (Java/TS): 如果企业主栈是 Java（Spring 生态）或 Node.js，用对应的语言 SDK 开发 Tool Server。
  - MCP Java SDK / MCP TypeScript SDK
- 工具路由与网关：当内部有几十上百个 MCP Server 时，提供统一的 API 路由、限流、Token 转发和熔断。
  - MCP Gateway / APISIX MCP Plugin
- 代码执行沙箱

为什么必须将 Tool Execution 单独拆分出来作为独立的工具与集成层(工具能力层)？

这正是企业级架构向大规模演进时的“必经之路”
在单体或简单 Agent 架构中，Tool 通常作为 API 直接硬编码在 Agent 代码中。但在企业级复杂场景中，如果不拆分：

安全隐患：代码执行（如 Python Sandbox）或高危操作（数据库删改）在 Agent 宿主进程中运行，极易引发越权或崩溃。

连接膨胀与维护灾难：100 个 Agent 都需要接入企业 CRM 或内部 API 时，每个 Agent 都要实现一遍鉴权、RPC 调用与错误重试。

能力无法复用：Agent A 开发的数据库查询工具，Agent B 无法无缝调用。

工具与集成层(工具能力层)，在被拆分后的职责划分与演进形态？

单独拆分出的 Tool / Capability 层（工具能力层）承担三大职责：

工具注册与发现（Registry & Discovery）：以标准规范（如 OpenAPI / MCP）暴露出工具的元数据（Schema、参数说明）。

执行与安全隔离（Execution & Isolation）：提供轻量级容器/沙箱环境（Docker、Wasm、E2B）隔离高危代码执行。

访问控制与鉴权（Auth & RBAC）：统一对接企业 IAM，确保 Agent 代表用户（On-behalf-of-user）执行 API 时具备正确权限。

Knowledge Platform/知识库平台: 为 AI Agent 提供高质量的上下文知识补充，解决幻觉、并支持海量长文本与结构化/非结构化数据的检索

模块划分:
- 文档解析、切片与向量化 (ETL/Embedding)：文档解析、Chunk 策略、向量化 Pipeline。
- 构建【知识图谱】
- 混合检索与重排 (RAG & Rerank)：密集向量检索 + 稀疏文本检索（BM25）+ GraphRAG + Re-ranking。
- 知识库存储：向量数据库、关系型数据库、图数据库。
数据来源:
- QA/问答
- Rules/规则
- Documents/文档手册
- ...
开源选型：
- RAG 引擎/框架： RAGFlow（内容检索增强引擎: 精准文档解析与模块化 RAG）、GraphRAG（知识图谱结合）等
- 向量数据库： Milvus(千万级或以上的中大型VDB) / Qdrant(百万条级内的小型VDB) / PGVector（若已有 PostgreSQL 基础设施） / ElasticSearch 等。
- 重排模型/框架：BGE-Reranker、FlashRank、Qwen-Rerancker系列模型。

Data Platform/数据平台

Data Application Products/数据应用产品
- BI
  开源组件: Superset / ...
- Data Assets System
- ...
Data Warehouse/数据仓库
- 开源组件: Hadoop+Hive / Doris / Clickhouse / ...
Lakehouse/数据湖
- 开源组件: Iceberge / Hudi / Paimon / ...

Business Platform/业务平台

ERP
CRM
MES
HR
OA
Core Business System
...

AI Governance Platform (AI治理平台): 横切 AI Interface Layer、AI Agent Platform、Model Platform、Tool Platform、Knowledge Platform、Data Platform、Business Platform

Observablity/可观测性: 捕获 Agent 内部思考链（Chain of Thought）、Prompt 消耗、工具调用耗时及 Token 成本
- 开源组件：Langfuse（极佳的开源 Tracing 方案）、Arize Phoenix、OpenTelemetry 集成。
Evaluation/评测与迭代: 自动化的 RAG 评估与 Agent 任务成功率评估（LLM-as-a-Judge）
- 组件选型：Ragas、DeepEval
Guardrails/安全与护栏: Input/Output 审核、防止 Prompt 注入攻击、敏感数据脱敏（PII Masking）
- 开源组件：NeMo Guardrails、Llama Guard
Audit/审计
Identity/身份鉴权
Security/安全策略
...

Infrastructure/基础设施层: 上层可以同时使用它、让 Agent 跑得稳

模块职责

计算与部署：Agent 服务标准化打包、扩缩容、GPU 调度

任务队列：长任务（多工具调用、长文档处理）走异步队列，避免 HTTP 长连接阻塞

隔离运行时：Agent 执行代码或操作文件系统时提供内核级隔离

短任务用同步 API（FastAPI），长任务务必上异步队列，否则生产环境连接会被拖垮

组件选型
- 容器/编排(Container): K8s(Pod) / Docker / ... (生产级微服务集群事实标准)
- 异步任务: Celery / NATS / SQS (超过数秒的 Agent 任务走异步队列)
- 模型推理服务: vLLM / SGLang (高吞吐自托管推理；Ollama 适合本地轻量部署)
- 沙箱隔离: Docker / gVisor / E2B(云服务) / Firecracker Micro-VM / ... / NVIDIA OpenShell (代码执行类 Agent 必备，毫秒级启动 + syscall 拦截)
- 计算资源: GPU / CPU / ...
- 存储:
  - 关系型数据库: PostgreSQL
  - 缓存数据库/KV-DB: Redis
  - Object Storage: MinIO
  - 消息队列: Kafka
  - 搜索引擎: Elasticsearch
  - VectorDB
    - Milvus
    - Qdrant
    - Weaviate
    - pgvector
    - (ElasticSearch)
  - Graph DB: NebulaGraph（原生分布式，推荐） / Neo4J（单机免费，但分布式集群需付费） / ...
- ...

Y 推荐文献

X 参考文献

posted @ 2026-08-28 23:24 数据知音阅读(3) 评论(0) 收藏举报

刷新页面返回顶部