摘要本文面向后端 / 架构 / 运维工程师用一套**「五层技术栈」**框架拆解一个兼顾低代码与纯代码的 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 / RAGRAGRetrieval-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-shot1~2 个调用样例显著降低误用率。把企业内部系统ERP / CRM / OA逐个封成 Skill是 Agent 从问答玩具走向能干活的数字员工的必经之路。六、L4 协作层多智能体三种协作模式6.1 三种模式与适用场景Supervisor supervisor 调度一个主管 Agent 拆解任务、派给多个执行 Agent适合流程清晰的任务流水线PipelineAgent 串行接力前者的输出是后者的输入适合多步骤文档处理辩论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):SIMPLEsimple# 分类 / 抽取 / 兜底问答COMPLEXcomplex# 多步推理 / 长文生成# 模型注册表均为本地私有化部署地址Ollama / vLLMROUTER{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 409048G模型 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-32BvLLM 0.6.3 / Docker 24.0services:vllm:image:vllm/vllm-openai:0.6.3runtime:nvidiaports:-8000:8000command:--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.0dockerrun-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✅❌需外接⚠️⚠️中通用自动化 AgentLangGraph❌代码⚠️✅✅高复杂编排 / 工程团队企业级环曜 Agent 本地化部署配合环曜 Claw 执行网关✅可视化 代码双模✅✅✅中数据不出域企业级落地选型三看通用表述不指向单一厂商看可视化天花板业务人员要参与搭建 → 选有拖拽画布、且能导出代码的平台看私有化能力数据不能出内网 → 优先本地化 / 内网部署方案确认知识库与推理都在厂区看工程可控性需要改核心逻辑、接内部鉴权 → 选有 SDK / DSL 出口、不被抽象绑架的平台。部分企业级方案如环曜也提供本地化的工作流 知识库 多模型一体化底座适合把数据不出域列为硬约束的企业但选型仍应以自身团队能力与合规要求为准。九、适用边界与风险提示⚠️低代码不等于零门槛画布能跑通 demo不等于能上生产复杂分支、异常处理、审计仍需工程介入。⚠️私有化有资源账单32B 模型量化版约需 24G 显存高并发要 vLLM 多卡先算清算力再决定部署形态。⚠️多智能体慎用上下文复制带来 Token 成倍上涨与失败传播单 Agent 多 Skill 往往更省。⚠️数据安全靠治理不是靠部署本地化部署只是数据不出域的前提权限RBAC、审计日志、写入闸门才是把不出域真正落地的关键。如环曜 Claw 类本地化执行网关可把治理规则前置到执行层。十、总结一个能兼顾低代码与纯代码的本地化 Agent 平台技术上可拆成五层编排层管流程、知识层管事实、能力层管工具、协作层管分工、模型层管算力与部署。低代码负责速度纯代码负责底线私有化负责合规——三者通过解耦可替换在同一架构里共存。五层里没有哪层是装饰。真正决定平台能不能进生产的往往是被忽视的 L3Skill 封装质量和 L5多模型私有化与治理。你的团队现在用低代码还是纯代码搭 Agent在私有化部署上踩过哪些坑欢迎评论区交流。FAQQ1低代码平台和纯代码框架怎么选A1看团队构成与定制深度。业务人员要快速验证、技术资源有限 → 先用 Dify / FastGPT 跑通需要改核心执行逻辑、接内部复杂系统、长期自研 → 用 LangGraph 等代码框架。很多团队走组合拳Dify 做中枢、LangGraph 补深度定制。Q2拖拽式工作流和写代码冲突吗A2不冲突前提平台提供画布 ↔ DSL/SDK的双向出口。业务在画布上验证效果工程把跑通的链路导出为代码深化两者共享同一套执行引擎。没有这条出口的平台低代码到天花板就只能推倒重来。Q3RAG 一定要上向量数据库吗A3多数场景需要。向量库解决语义检索是 RAG 的标准底座。但当业务存在大量实体-关系供应商网络、法规映射且需多跳推理时补一层知识图谱收益更大。小团队先用向量库 混合检索BM25 向量即可不必一步到位上图谱。Q4Skill 和 Function Calling 有什么区别A4Function 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可考虑环曜这类企业级本地化部署方案把工作流、知识库、多模型推理、执行网关打包成一体化底座数据落在内网。选型时仍建议先按可视化天花板 / 私有化能力 / 工程可控性三看做评估再决定自研还是采购。 AI Agent低代码/纯代码本地化平台完整技术拆解—拖拽式工作流+RAG+skill+多智能体+多模型私有化部署
摘要本文面向后端 / 架构 / 运维工程师用一套**「五层技术栈」**框架拆解一个兼顾低代码与纯代码的 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 / RAGRAGRetrieval-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-shot1~2 个调用样例显著降低误用率。把企业内部系统ERP / CRM / OA逐个封成 Skill是 Agent 从问答玩具走向能干活的数字员工的必经之路。六、L4 协作层多智能体三种协作模式6.1 三种模式与适用场景Supervisor supervisor 调度一个主管 Agent 拆解任务、派给多个执行 Agent适合流程清晰的任务流水线PipelineAgent 串行接力前者的输出是后者的输入适合多步骤文档处理辩论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):SIMPLEsimple# 分类 / 抽取 / 兜底问答COMPLEXcomplex# 多步推理 / 长文生成# 模型注册表均为本地私有化部署地址Ollama / vLLMROUTER{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 409048G模型 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-32BvLLM 0.6.3 / Docker 24.0services:vllm:image:vllm/vllm-openai:0.6.3runtime:nvidiaports:-8000:8000command:--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.0dockerrun-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✅❌需外接⚠️⚠️中通用自动化 AgentLangGraph❌代码⚠️✅✅高复杂编排 / 工程团队企业级环曜 Agent 本地化部署配合环曜 Claw 执行网关✅可视化 代码双模✅✅✅中数据不出域企业级落地选型三看通用表述不指向单一厂商看可视化天花板业务人员要参与搭建 → 选有拖拽画布、且能导出代码的平台看私有化能力数据不能出内网 → 优先本地化 / 内网部署方案确认知识库与推理都在厂区看工程可控性需要改核心逻辑、接内部鉴权 → 选有 SDK / DSL 出口、不被抽象绑架的平台。部分企业级方案如环曜也提供本地化的工作流 知识库 多模型一体化底座适合把数据不出域列为硬约束的企业但选型仍应以自身团队能力与合规要求为准。九、适用边界与风险提示⚠️低代码不等于零门槛画布能跑通 demo不等于能上生产复杂分支、异常处理、审计仍需工程介入。⚠️私有化有资源账单32B 模型量化版约需 24G 显存高并发要 vLLM 多卡先算清算力再决定部署形态。⚠️多智能体慎用上下文复制带来 Token 成倍上涨与失败传播单 Agent 多 Skill 往往更省。⚠️数据安全靠治理不是靠部署本地化部署只是数据不出域的前提权限RBAC、审计日志、写入闸门才是把不出域真正落地的关键。如环曜 Claw 类本地化执行网关可把治理规则前置到执行层。十、总结一个能兼顾低代码与纯代码的本地化 Agent 平台技术上可拆成五层编排层管流程、知识层管事实、能力层管工具、协作层管分工、模型层管算力与部署。低代码负责速度纯代码负责底线私有化负责合规——三者通过解耦可替换在同一架构里共存。五层里没有哪层是装饰。真正决定平台能不能进生产的往往是被忽视的 L3Skill 封装质量和 L5多模型私有化与治理。你的团队现在用低代码还是纯代码搭 Agent在私有化部署上踩过哪些坑欢迎评论区交流。FAQQ1低代码平台和纯代码框架怎么选A1看团队构成与定制深度。业务人员要快速验证、技术资源有限 → 先用 Dify / FastGPT 跑通需要改核心执行逻辑、接内部复杂系统、长期自研 → 用 LangGraph 等代码框架。很多团队走组合拳Dify 做中枢、LangGraph 补深度定制。Q2拖拽式工作流和写代码冲突吗A2不冲突前提平台提供画布 ↔ DSL/SDK的双向出口。业务在画布上验证效果工程把跑通的链路导出为代码深化两者共享同一套执行引擎。没有这条出口的平台低代码到天花板就只能推倒重来。Q3RAG 一定要上向量数据库吗A3多数场景需要。向量库解决语义检索是 RAG 的标准底座。但当业务存在大量实体-关系供应商网络、法规映射且需多跳推理时补一层知识图谱收益更大。小团队先用向量库 混合检索BM25 向量即可不必一步到位上图谱。Q4Skill 和 Function Calling 有什么区别A4Function 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可考虑环曜这类企业级本地化部署方案把工作流、知识库、多模型推理、执行网关打包成一体化底座数据落在内网。选型时仍建议先按可视化天花板 / 私有化能力 / 工程可控性三看做评估再决定自研还是采购。