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

0 序

  • 不论是问各个AI、还是网络技术博客，都难有一篇把整个企业级应用的架构设计、及其开源组件的情况讲清楚的。
  • 本篇历时多日，大量调研、并结合个人实践，梳理、总结此篇，以作为企业级AI Agent系统设计的理想蓝图、参考图纸。

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

AI 应用的形态: ChatBot / WorkFlow / Agent 及混合

  • AI 应用的三种形式分别是 Chatbot、Workflow 和 Agent

  • Chatbot 的形态是指，每轮都由用户主动提问，AI 对用户提问进行回答，这种一问一答的形式是 Chatbot

最经典的特征。就像去服务台问路，你问一句前台答一句，你不开口，对方就不会有动作

  • Workflow 的形态比较灵活，可以理解为在传统工作流程序中加入 AI 能力。

AI 运行在既定代码逻辑中，按照写死的流程节点老老实实干活。
就像按步骤做菜的食谱，先洗菜、再切肉、最后下锅，大模型只负责其中切肉这一步

  • Agent 的形态是 ReAct(思考行动模式)及其衍生模式。

区别于前两者，它具备最基本的感知、思考、决策、行动能力。
更像把买菜做饭这整件事全包出去，中间遇到菜市场没开门，它会自己琢磨换个超市买。

  • 那么，上面三种形态各有什么优缺点？
  • Chatbot 是比较早期的 AI应用形态。

它的优点是系统简单，适合简单的日常问答和单点任务；缺点是交互主权完全在用户手里，每一步都需要用户推着走，无法自主完成多步骤的复杂任务

  • Workflow 是让 AI(LLM/VLM) 嵌入到传统代码流程中

优点是运行路径确定，编排灵活，速度快，适合规则明确的交付任务；
缺点是流程被硬编码卡死，遇到突发情况无法动态调整路径

  • Agent 采用了 ReAct 模式，具备自主决策和行动能力，灵活性最高

适合:目标明确、但决策路径不确定的任务。
当然，由于多个环节都依赖大模型自主推理，成本高、响应慢，还会带来模型幻觉和输出不可控等工程治理挑战。

  • Chatbot 看交互是否完全由用户单向驱动，Workflow 看流程是否走固定的预设链路，Agent 看内部是否有自主循环的 ReAct 机制
  • Chatbot 本质上是对话驱动。现在的 Chatbot 可能会加上工具调用、长期记忆等功能，但它的核心目标依然是伺候好眼前的这轮问答，不会主动发散出新的延伸目标
  • Workflow 的本质是自动化流水线，流程怎么走早就定好了，大模型只是流水线上某几个工位的高级打工人，不能擅自跳出既定环节
  • Agent 的本质是自驱运转，核心在于让大模型通过思考和行动的闭环，自主探索解题路径，直到目标完成

AI Agent 的一般运行流程

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

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 <br> Planning <br> Reflection"] R2["Memory Engine <br> Context Engine"] R3["State & Checkpoint"] R4["Skills <br> 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 :<br>Direct Exec<br>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 UI、IM（Slack / Teams / 钉钉 / 企微 / 飞书等）、API 接入、Webhook、业务系统事件流、语音、文件上传
  • Generative UI（Agent 动态生成界面组件）
  • 请求预处理、鉴权、参数标准化、输入过滤、会话会话 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、...
      • Nanobot：把 MCP servers 转成自主 Agent + Web UI
    • API 网关：FastAPI、Golang 网关、LangGraph‑API Gateway；Dify 网关、Spring Cloud Gateway、Apache APISIX:The Cloud-Native API Gateway and AI Gateway，支持插件化扩展 AI Gateway 功能、...
    • 消息通道（商业+开源）：Slack / 企业微信 / 钉钉适配器、Kafka 消费事件驱动 Agent 触发、...
    • 可视化工作流编辑器（ByteDance）: FlowGram: 8.4k(2026.08.31)
    • 前端技术栈： Next.js / React / Vue + WebSocket / ...
    • 其他-补充: CopilotKit：全栈框架，React/Angular SDK，支持 generative UI + HITL
      • HITL，即Human-in-the-Loop（人机回圈/人机协同），是一种将人工智能的自动化能力与人类专业判断、伦理考量和创造性思维结合的系统设计模式。在HITL模式下，AI系统并非完全自主运行，而是在关键步骤或决策节点上暂停等待人类审批、修改或确认，以保证输出的可靠性和安全性

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 / AgentScope-Java (阿里巴巴 开源)
            • 高并发、分布式、基于 Actor 模型的 Agent Runtime，专为大规模多 Agent 协作和高吞吐场景设计
        • 自动化/代码执行与多 Agent 协作型
          • AutoGen(微软开源)：多 Agent 对话协同框架的先驱，擅长解决复杂的代码编写与多角色会话决策。（AG2）
          • CrewAI：以“角色（Role）- 任务（Task）- 团队（Crew）”为抽象的 Agent 编排框架，极易上手。
          • Spring-AI Alibaba
        • 低代码、快速POC、可视化工作流与应用引擎型（快速业务落地）
    • Multi-Agent Orchestrator：管理多 Agent 间的通信、任务分发与状态同步；角色分发、消息通信、结果聚合（复杂场景）
    • Workflow/工作流与可视化：低代码、快速POC、可视化工作流与应用引擎型（快速业务落地）
      • Dify：154k star(2026.09.02),全球最火爆的低代码 AI Agent 编排与应用开发平台之一，可视化 DAG 工作流与 RAG 引擎的集大成者，企业 MVP 选型首选。相比n8n，其作为面向生成式 AI 的应用开发平台，专注 LLM 应用与 AI 工作流
      • n8n：203k star(2026.09.02),低代码工作流自动化平台，具备原生 AI 功能。支持可视化构建与自定义代码相结合，可自托管或云端部署，集成 400 多个平台。相比dify，其作为通用工作流自动化平台，擅长系统集成与流程串联
      • Flowise：55.4k star(2026.08.31)，于2026.08.13停止运营，项目进入只读模式。基于 Node.js/LangChain 的可视化 Agent 流程编排工具

  • 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
        • DeepSeek-Hardness: 205k star(2026.08.31)，产品设计理念=一切即插件
        • codex: 120k star(2026.08.31)，运行在终端的Agents
        • Pi-Agent : 99.5k star(2026.08.31)，一种非常优秀的、聚焦于轻量级与编码领域（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）
        • DeepAgents: langchain-ai 出品，28.7k star(2026.08.31)
        • claude-agent-sdk(python): Claude 出品，8k star
      • 工具协议扩展：Model Context Protocol (MCP)（标准化的上下文与工具对接协议）
      • 观测调试：（参见：AI治理层）
  • 为什么会叫 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/上下文引擎

  • 推荐文献
  • 本质对比：

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

  • 推荐组件

LangGraph：工业Agent首选；Checkpoint会话状态、消息中间件、Store存储，可自定义每一步送入LLM的消息，高度可控；compaction、消息过滤需要自己编排逻辑。

Memory/记忆模块

  • 推荐文献
  • 推荐组件:

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 等开源模型处理特定任务，形成混合模型策略

  • 推荐文献

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

  • 模块职责： (单独拆分出的 Tool / Capability 层（工具能力层） 需承担的职责)
  • 工具注册与发现（Registry & Discovery）：以标准规范（如 OpenAPI / MCP）暴露出工具的元数据（Schema、参数说明）。
  • 访问控制与鉴权（Auth & RBAC）：统一对接企业 IAM，确保 Agent 代表用户（On-behalf-of-user）执行 API 时具备正确权限。
  • 执行与安全隔离（Execution & Isolation）：提供轻量级容器/沙箱环境（Docker、Wasm、E2B）隔离高危代码执行，防止工具调用越权。
  • 统一接入企业内外系统（OA / CRM / ERP / 数据库 / 通信工具 / ...）

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

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

  • MCP Server

    • MCP Servers: 90k(2026.08.31)，社区官方项目，支持多种语言(Java/Python/Go/...)
    • FastMCP : 27.4k(2026.08.31)，Python生态中实现 Anthropic 主导的 MCP 协议的高级 SDK。它大大降低了将企业现有 Python 函数、数据库查询或微服务包装为 MCP Server 的门槛；协议与实现：MCP 定义了通信规范，FastMCP 是该规范的 Python 实现载体。 功能覆盖：FastMCP 完整支持 MCP 的三大核心能力——工具（Tools）、资源（Resources）、提示（Prompts），并在此基础上扩展了企业级特性。 生态融合：FastMCP 1.x 已并入官方 MCP Python SDK，成为其高级抽象层；FastMCP 2.x 独立演进，兼容 MCP 1.6 协议，并通过官方 SDK 底层接口通信。
    • 开发 SDK (Python): 用于将内部 Python 代码、本地函数包装为标准的 MCP 工具服务。
      • MCP Python SDK （来自: MCP Servers项目的SDK）
    • 开发 SDK (Java/TS): 如果企业主栈是 Java（Spring 生态）或 Node.js，用对应的语言 SDK 开发 Tool Server。
      • MCP Java SDK / MCP TypeScript SDK

  • Tool Gateway: 当内部有几十上百个 MCP Server 时，提供统一的 API 路由、限流、Token 转发和熔断。

    • Apache APISIX MCP Plugin : The Cloud-Native API Gateway and AI Gateway
    • MCP Gateway: MCP Gateway 是一个面向 MCP 服务器的反向代理和管理层，可在 Kubernetes 环境中实现可扩展、会话感知的状态化路由以及 MCP 服务器的生命周期管理。

  • 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

  • 补充组件

    • LangChain Tools / 自定义 Function Calling：作为补充
  • 为什么必须将 Tool Execution 单独拆分出来作为独立的 工具与集成层(工具能力层)？

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

  • 安全隐患：代码执行（如 Python Sandbox）或高危操作（数据库删改）在 Agent 宿主进程中运行，极易引发越权或崩溃。
  • 连接膨胀与维护灾难：100 个 Agent 都需要接入企业 CRM 或内部 API 时，每个 Agent 都要实现一遍鉴权、RPC 调用与错误重试。
  • 能力无法复用：Agent A 开发的数据库查询工具，Agent B 无法无缝调用。

sandbox/沙箱

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) / weaviate / chroma / PGVector（若已有 PostgreSQL 基础设施） / ElasticSearch 等。
    • 重排模型/框架：BGE-Reranker、FlashRank、Qwen-Rerancker系列模型。

Data Platform/数据平台

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

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

这是企业级与玩具项目的根本差异。必须从第一天就规划，不能事后补。

  • 模块职责
  • 分布式追踪：记录每一次 LLM 调用、工具调用、决策路径
  • 安全护栏：输入过滤、输出审计、沙箱隔离
  • 策略引擎：RBAC、最小权限、人工审批阈值
  • 评估体系：离线 + 在线评测
  • Kill Switch：异常时秒级熔断
  • Observablity/可观测性: 捕获 Agent 内部思考链（Chain of Thought）、Prompt 消耗、工具调用耗时及 Token 成本
  • Evaluation/评测与迭代: 自动化的 RAG 评估与 Agent 任务成功率评估（LLM-as-a-Judge）
  • Guardrails/安全与护栏: Input/Output 审核、防止 Prompt 注入攻击、敏感数据脱敏（PII Masking）
  • 行为异常监测
    • 基于 ClickHouse + Z-score 滑动窗口的轻量方案、...
  • 注册中心: 自建 Agent Registry，记录每个 Agent 的所有者/模型/工具/权限
  • 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 推荐文献

基于当下AI发展态势，如何实现：满足湖仓一体、存算分离、容器化、Data+AI的深度融合的企业数据架构？分层设计、及其技术组件的选型？

X 参考文献

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