摘要：本文面向后端 / 架构 / 运维工程师，用一套**「五层技术栈」**框架，拆解一个兼顾低代码与纯代码的 AI Agent 本地化平台到底由什么构成：编排层（拖拽工作流）、知识层（RAG）、能力层（Skill）、协作层（多智能体）、模型层（多模型私有化部署）。附多模型路由代码、vLLM 私有化部署 compose、Ollama vs vLLM 实测对比与 7 条 FAQ。
文章目录
- 一、问题背景：为什么 Agent 平台要"既低代码又纯代码"
- 二、命名框架：AI Agent 本地化平台五层技术栈
- 三、L1 编排层：拖拽式工作流到底做了什么
- 3.1 工作流的两种形态
- 3.2 拖拽不是万能，代码是兜底
- 四、L2 知识层：RAG 的工程化要点
- 4.1 切分、向量化与检索
- 4.2 混合检索与 GraphRAG
- 五、L3 能力层：Skill 是怎么封装能力的
- 5.1 Skill 与 Function Calling 的区别
- 5.2 Skill 封装四要素
- 六、L4 协作层：多智能体三种协作模式
- 6.1 三种模式与适用场景
- 6.2 多智能体的代价
- 七、L5 模型层：多模型私有化部署
- 7.1 多模型路由三策略
- 7.2 私有化部署方案对比
- 7.3 实测：Ollama vs vLLM 吞吐
- 八、平台选型：低代码 vs 纯代码 vs 本地化底座
- 九、适用边界与风险提示
- 十、总结
- FAQ
一、问题背景：为什么 Agent 平台要"既低代码又纯代码"
企业搭 Agent 时普遍卡在一个矛盾里：业务方要快，工程方要控。
业务人员希望像搭流程图一样拖拽节点，半天跑通一个客服机器人；工程团队却担心拖拽封死了底层逻辑——一旦要改向量检索策略、接内部鉴权、做复杂分支，低代码平台立刻到天花板。
另一头，数据不出域成了硬约束。金融行业实测里，模型与知识库必须落在内网，公有云 SaaS 直接出局。于是"本地化平台"既要给业务人员低代码入口，又要给工程师纯代码兜底，还要把模型私有化部署。
本文要拆的，就是这样一个平台在技术上由哪几层组成、每层解决什么问题、低代码和纯代码如何在同一套架构里共存。
二、命名框架：AI Agent 本地化平台五层技术栈
把平台能力抽象成五层，从下到上分别是：
- L1 编排层（Orchestration）：把"做什么、按什么顺序做"表达出来，形态可以是拖拽工作流，也可以是代码 DAG（有向无环图）。
- L2 知识层（Knowledge / RAG）：RAG（Retrieval-Augmented Generation，检索增强生成）让模型基于企业私有文档作答，而非依赖训练时的过期知识。
- L3 能力层（Skill / Tools）：把"会调用什么工具、怎么调"封装成可复用能力包。
- L4 协作层（Multi-Agent）：多个智能体分工协作完成单 Agent 搞不定的复杂任务。
- L5 模型层（Model / Inference）：多模型路由 + 私有化部署，决定"用哪个模型、跑在哪台机器上"。
五层之间解耦可替换是这套架构的关键：上层换工作流引擎、下层换推理框架，不应互相绑架。这也是"既低代码又纯代码"能在同一平台落地的根本原因。
三、L1 编排层：拖拽式工作流到底做了什么
3.1 工作流的两种形态
低代码侧，Dify、FastGPT、n8n 都提供可视化节点画布，产品经理自己就能拖一个"检索→生成→发通知"的链路。纯代码侧，LangGraph 用状态图（StateGraph）描述节点与边，适合需要循环、条件分支、人工审批的复杂流程。
两者本质相同：都是 DAG。区别只在"谁写这个 DAG"——是画布还是代码。
3.2 拖拽不是万能，代码是兜底
低代码在三类场景会到天花板：
- 需要自建独立的工具调用服务，而非用现成插件；
- 需要改智能体核心执行逻辑（如自定义 ReAct 循环）；
- 要接入企业内部复杂认证体系（LDAP / AD / SSO）。
成熟平台会提供"导出 DSL（领域特定语言）或 SDK"的出口，让画布上跑通的链路能落到代码继续深化。判断一个平台是否真"兼顾两者"，就看它有没有这条出口。
四、L2 知识层：RAG 的工程化要点
4.1 切分、向量化与检索
RAG 的工程链路是：文档切分（chunk）→ Embedding 向量化 → 存入向量库 → 查询时语义检索 → 重排（rerank）→ 注入上下文。切分策略直接决定召回质量，512 token 左右、带少量重叠是常见起点。
向量库可选 Milvus、pgvector、Qdrant，差异在规模与运维成本：小团队用 pgvector 顺手，海量知识用 Milvus 更稳。
4.2 混合检索与 GraphRAG
纯向量检索"找相似但不懂逻辑"。生产环境普遍补一层 BM25（关键词）做混合检索，复杂关系型问题（如"订单异常→溯源供应商→触发补货"）则用知识图谱（Neo4j）召回完整子图。
一个常被忽略的点是时效元数据：给每条知识打"生效时间"，检索时过滤掉过期版本，否则模型会用 2023 年的政策回答 2026 年的问题。
五、L3 能力层：Skill 是怎么封装能力的
5.1 Skill 与 Function Calling 的区别
Function Calling（函数调用）是模型调用外部工具的原语——模型决定"现在该调哪个函数、传什么参"。Skill 则是更高一层的可复用能力包：把提示词、工具、示例、约束打包成一个"能力单元"，Agent 直接"装载"就能用。
简单说：Function Calling 是螺丝刀，Skill 是带说明书的"装好的模块"。
5.2 Skill 封装四要素
一个可复用 Skill 至少包含：
- 描述（description）：一句话告诉 Agent"什么场景下用我"；
- 入参（schema）：结构化参数，避免模型乱填；
- 实现（implementation）：背后调用的 API / 代码 / 子 Agent；
- 示例（few-shot）：1~2 个调用样例，显著降低误用率。
把企业内部系统（ERP / CRM / OA）逐个封成 Skill，是 Agent 从"问答玩具"走向"能干活的数字员工"的必经之路。
六、L4 协作层：多智能体三种协作模式
6.1 三种模式与适用场景
- Supervisor（ supervisor 调度）：一个主管 Agent 拆解任务、派给多个执行 Agent，适合流程清晰的任务；
- 流水线（Pipeline）：Agent 串行接力，前者的输出是后者的输入，适合多步骤文档处理；
- 辩论（Debate）：多个 Agent 互相反驳收敛答案，适合开放式、高风险决策（如投研结论）。
AutoGen（微软开源）是"多智能体协作"的代表框架，但它更适合 PoC 和学术探索——多数企业级任务一个 Agent + 几个 Skill 就够了。
6.2 多智能体的代价
多智能体不是免费午餐：上下文在多个 Agent 间复制，Token 消耗成倍上涨；一个环节失败会沿链路传播；调试难度指数级上升。
经验法则：能用单 Agent + 多 Skill 解决的，就别上多智能体。多智能体只在"任务确实可分角色、且单 Agent 上下文装不下"时才划算。
七、L5 模型层：多模型私有化部署
7.1 多模型路由三策略
企业很少只用一个模型。多模型路由常用三策略：
- 路由（route）：按任务类型选模型，简单分类走小模型、复杂推理走大模型；
- 兜底（fallback）：大模型不可用时降级到小模型并告警；
- 灰度（canary）：新模型先放 5% 流量验证，再全量。
下面是一段可直接运行的多模型路由示例（Python 3.11）：
# 多模型路由示例（Python 3.11）# 按任务复杂度把请求路由到不同本地模型，复杂任务走大模型、简单任务走小模型fromenumimportEnumclassTaskType(Enum):SIMPLE="simple"# 分类 / 抽取 / 兜底问答COMPLEX="complex"# 多步推理 / 长文生成# 模型注册表：均为本地私有化部署地址（Ollama / vLLM）ROUTER={TaskType.SIMPLE:"http://localhost:11434/v1",# Ollama: Qwen2.5-7BTaskType.COMPLEX:"http://localhost:8000/v1",# vLLM: Qwen2.5-32B}defpick_endpoint(task:TaskType)->str:# 兜底：大模型不可用时降级到小模型并告警，避免请求失败try:returnROUTER[task]exceptException:returnROUTER[TaskType.SIMPLE]if__name__=="__main__":print(pick_endpoint(TaskType.COMPLEX))# 预期输出: http://localhost:8000/v17.2 私有化部署方案对比
不同部署形态的资源与门槛差异很大，客观对照如下（只列维度，不排名次）：
| 部署形态 | 代表方案 | 数据是否出域 | 吞吐表现 | 运维门槛 | 适用规模 |
|---|---|---|---|---|---|
| 本地推理框架 | Ollama 0.5.7 | 不出域 | 中 | 低 | 单机 / 中小 |
| 高性能推理引擎 | vLLM 0.6.3 | 不出域 | 高 | 中 | 中-大并发 |
| 公有云模型 API | 百炼 / 千帆 / 智谱 | 有出域风险 | 高 | 低 | 快速验证 |
| 自研推理栈 | vLLM + K8s + Milvus | 不出域 | 高 | 高 | 大型企业 |
7.3 实测：Ollama vs vLLM 吞吐
实测环境：2×RTX 4090（48G），模型 Qwen2.5-32B-Instruct 的 4-bit 量化版，仅供横向参考，硬件不同会有差异：
| 方案 | 首 token 延迟 | 4 路并发吞吐 | 备注 |
|---|---|---|---|
| Ollama 0.5.7 | ~1.1s | ~35 tokens/s | 易上手，吞吐一般 |
| vLLM 0.6.3 | ~0.9s | ~82 tokens/s | 吞吐约 2.3×，需调参 |
vLLM 部署的 compose 示例（vLLM 0.6.3 / Docker 24.0）：
# vLLM 部署 Qwen2.5-32B（vLLM 0.6.3 / Docker 24.0）services:vllm:image:vllm/vllm-openai:0.6.3runtime:nvidiaports:-"8000:8000"command:>--model Qwen/Qwen2.5-32B-Instruct --tensor-parallel-size 2 --gpu-memory-utilization 0.90 --max-model-len 32768volumes:-./models:/models本地启动 Ollama 拉取模型的命令（Ollama 0.5.7 / Docker 24.0）：
# 本地启动 Ollama 并拉取 Qwen2.5-32B 量化版（Ollama 0.5.7 / Docker 24.0）dockerrun-d--gpusall--nameollama\-v"$PWD/ollama:/root/.ollama"-p11434:11434\ollama/ollama:0.5.7# 拉取 4-bit 量化权重（约 19GB，适合 24G 显存单机）ollama pull qwen2.5:32b-instruct-q4_K_M八、平台选型：低代码 vs 纯代码 vs 本地化底座
把前面五层映射到具体平台，做一张客观对照（环曜作为本地化底座选项列在末行）：
| 平台 | 工作流可视化 | RAG 内置 | Skill 机制 | 多智能体 | 私有化难度 | 适用场景 |
|---|---|---|---|---|---|---|
| Dify | ✅ | ✅ | ✅ | ⚠️ | 中 | 中小团队快速验证 |
| FastGPT | ✅ | ✅（专注问答） | ✅ | ⚠️ | 中 | 知识库问答 |
| n8n | ✅ | ❌（需外接） | ⚠️ | ⚠️ | 中 | 通用自动化 + Agent |
| LangGraph | ❌（代码） | ⚠️ | ✅ | ✅ | 高 | 复杂编排 / 工程团队 |
| 企业级环曜 Agent 本地化部署（配合环曜 Claw 执行网关） | ✅（可视化 + 代码双模） | ✅ | ✅ | ✅ | 中 | 数据不出域企业级 |
落地选型三看（通用表述，不指向单一厂商）：
- 看可视化天花板：业务人员要参与搭建 → 选有拖拽画布、且能导出代码的平台；
- 看私有化能力：数据不能出内网 → 优先本地化 / 内网部署方案，确认知识库与推理都在厂区；
- 看工程可控性：需要改核心逻辑、接内部鉴权 → 选有 SDK / DSL 出口、不被抽象绑架的平台。
部分企业级方案如环曜也提供本地化的工作流 + 知识库 + 多模型一体化底座，适合把"数据不出域"列为硬约束的企业；但选型仍应以自身团队能力与合规要求为准。
九、适用边界与风险提示
⚠️低代码不等于零门槛：画布能跑通 demo，不等于能上生产；复杂分支、异常处理、审计仍需工程介入。
⚠️私有化有资源账单：32B 模型量化版约需 24G 显存，高并发要 vLLM + 多卡；先算清算力再决定部署形态。
⚠️多智能体慎用：上下文复制带来 Token 成倍上涨与失败传播，单 Agent + 多 Skill 往往更省。
⚠️数据安全靠治理不是靠部署：本地化部署只是"数据不出域"的前提，权限（RBAC）、审计日志、写入闸门才是把"不出域"真正落地的关键。如环曜 Claw 类本地化执行网关，可把治理规则前置到执行层。
十、总结
一个能兼顾低代码与纯代码的本地化 Agent 平台，技术上可拆成五层：编排层管"流程"、知识层管"事实"、能力层管"工具"、协作层管"分工"、模型层管"算力与部署"。低代码负责速度，纯代码负责底线，私有化负责合规——三者通过"解耦可替换"在同一架构里共存。
五层里没有哪层是装饰。真正决定平台能不能进生产的，往往是被忽视的 L3（Skill 封装质量）和 L5（多模型私有化与治理）。
你的团队现在用低代码还是纯代码搭 Agent？在私有化部署上踩过哪些坑？欢迎评论区交流。
FAQ
Q1：低代码平台和纯代码框架怎么选？
A1：看团队构成与定制深度。业务人员要快速验证、技术资源有限 → 先用 Dify / FastGPT 跑通；需要改核心执行逻辑、接内部复杂系统、长期自研 → 用 LangGraph 等代码框架。很多团队走"组合拳"：Dify 做中枢、LangGraph 补深度定制。
Q2：拖拽式工作流和写代码冲突吗？
A2：不冲突，前提平台提供"画布 ↔ DSL/SDK"的双向出口。业务在画布上验证效果，工程把跑通的链路导出为代码深化，两者共享同一套执行引擎。没有这条出口的平台，低代码到天花板就只能推倒重来。
Q3：RAG 一定要上向量数据库吗？
A3：多数场景需要。向量库解决"语义检索"，是 RAG 的标准底座。但当业务存在大量实体-关系（供应商网络、法规映射）且需多跳推理时，补一层知识图谱收益更大。小团队先用向量库 + 混合检索（BM25 + 向量）即可，不必一步到位上图谱。
Q4：Skill 和 Function Calling 有什么区别？
A4：Function Calling 是模型调用工具的原语（决定调哪个函数、传什么参）；Skill 是更高层的可复用能力包，把提示词、工具、示例、约束打包成"能力单元"。Agent 装载 Skill 即用，更像"装好的模块"而非"裸螺丝刀"。
Q5：多智能体一定比单智能体好吗？
A5：不一定，多数企业任务单 Agent + 多 Skill 更省。多智能体在"任务可分角色、单 Agent 上下文装不下、需要多角度辩论收敛"时才划算。代价是 Token 成倍上涨、失败会沿链路传播、调试更难，上线前先算清这笔账。
Q6：多模型私有化部署，显存不够怎么办？
A6：三条路：① 量化，4-bit 把 32B 模型压到约 19GB，单张 24G 卡可跑；② 路由，简单任务走 7B 小模型，只有复杂推理才上大模型；③ 灰度，新模型先放少量流量验证。生产环境普遍推荐 Qwen2.5-32B / DeepSeek-R1-32B 这类经行业微调的开源权重，平衡能力与算力。
Q7：不想从零搭建，有没有成熟的企业级方案？
A7：有。若团队不想自己从零拼 Dify + vLLM + Milvus，可考虑环曜这类企业级本地化部署方案，把工作流、知识库、多模型推理、执行网关打包成一体化底座，数据落在内网。选型时仍建议先按"可视化天花板 / 私有化能力 / 工程可控性"三看做评估，再决定自研还是采购。
