企业官网建设流程全解析

关键词：AI Agent、Dify、智能体平台、RAG、工作流编排、Tool、MCP、Skill、模型接入、私有化部署、开源组件、自主可控、企业级 AI 应用

一、为什么企业会想“自己做一个 Dify”

过去两年，很多企业在尝试大模型应用时，都会接触到 Dify 这类开源 LLM 应用开发平台。它把模型接入、Prompt 编排、知识库 RAG、Agent、工作流、工具调用、应用发布等能力放到一个可视化界面里，让团队可以较快做出一个 AI 应用原型。

但当原型进入企业生产环境后，问题会变得更复杂：模型服务可能要接入国产大模型和私有化模型；知识库要和组织权限、业务数据权限绑定；工作流要能调用内部系统；日志、审计、链路追踪要满足运维要求；代码和数据也要满足自主可控、私有化部署和二次开发要求。

这也是很多技术团队开始思考的原因：能不能基于成熟开源组件，开发一个类似 Dify 的智能体平台，但底层架构、源代码、部署环境和企业集成能力都掌握在自己手里？

这个问题不能简单理解为“把 Dify 再写一遍”。更合理的思路是：先分析 Dify 的产品能力和技术架构，再把它拆成若干独立模块，针对每个模块选择可替换、可扩展、可治理的开源方案，最后形成适合企业自身技术栈的智能体开发平台。

二、先看 Dify 的产品能力构成

Dify 官方 GitHub 将其定位为面向 agentic workflow development 的生产级平台。官方 README 中列出的核心能力包括：可视化 Workflow、多模型接入、Prompt IDE、RAG Pipeline、Agent 能力、LLMOps 以及 Backend-as-a-Service API 集成能力。也就是说，Dify 并不是单纯的聊天机器人搭建器，而是一个把大模型应用开发、知识增强、工具调用和应用发布组合起来的平台。

从产品功能视角看，一个类似 Dify 的智能体平台大致包括以下模块：

从这张表可以看出，Dify 的价值在于把“大模型能力”变成“可配置、可发布、可运营的应用能力”。但企业自研平台不能只学界面和概念，更要补上企业环境中的权限、安全、国产化、系统集成和运维治理。

图：Dify 功能构成与企业自研平台关注点对照图

三、再看 Dify 的技术架构启发

从公开资料看，Dify 采用的是比较典型的 Web 平台 + AI 引擎 + 中间件 + 插件/沙箱的组合架构。

Dify GitHub 页面显示其项目主题包含 Python、Next.js、agent、workflow、MCP、RAG、low-code、agentic-workflow 等关键词。Dify 官方本地源码启动文档提到，运行后端服务前，需要先启动 PostgreSQL、Redis、Weaviate，以及 sandbox、plugin-daemon 等中间件和扩展服务。Docker Compose 部署资料中也可以看到 API 服务、worker、web 前端、插件守护进程、向量库、缓存、数据库、沙箱、反向代理等组件共同组成运行环境。

可以抽象出一个类似 Dify 的平台技术架构：

这个架构说明了一个关键点：智能体平台不是一个“大模型调用页面”，而是一个 AI 应用工程化平台。它需要同时具备应用平台、数据平台、流程平台、工具平台和运维平台的能力。

四、为什么不能只“Fork Dify 改一改”

Dify 的优势很明显：产品体验完整、生态活跃、模型和工具支持丰富、上手快，适合快速验证 LLM 应用、RAG 应用和 Agent 工作流。但如果企业目标是“自主可控”，直接 Fork 并长期深度改造并不一定是最优路线。

原因主要有四个。

第一，技术栈匹配问题。Dify 主要面向 Python/Next.js 技术栈。如果企业内部主技术栈是 Java、Spring Boot、Vue、国产数据库、中间件和私有化模型服务，那么深度二次开发会遇到语言栈、人员能力、部署标准和运维体系不一致的问题。

第二，企业权限和业务系统集成问题。很多企业并不是缺一个 AI 应用 Demo，而是需要把 AI 应用接入组织架构、角色权限、业务系统 API、统一认证、审计日志和运维规范。这里大量工作不在 AI 模型本身，而在企业软件工程体系。

第三，治理和合规问题。Gartner 在 2026 年关于 AI Agent 治理的观点中提醒，企业如果不区分 Agent 的自治级别和访问边界，容易在生产环境中出现治理失败。对企业来说，Agent 能不能调用工具、能不能访问知识库、能不能触发业务动作，都必须有分级授权和审计机制。

第四，许可证和产品边界问题。Dify GitHub 页面说明其开源许可证基于 Apache 2.0 但带有额外条件。企业如果计划商业化分发、深度改造或内置到自有产品中，应该认真审查许可证、商标、分发和二次开发边界。

因此，更稳妥的方式是学习 Dify 的产品结构和工程思想，但在关键技术栈、数据存储、权限体系、部署架构和二次开发能力上，采用企业自己可掌控的实现路线。

五、各功能模块可以选择哪些开源组件

如果要从零搭建一个类似 Dify 的智能体平台，可以把工程拆成 10 个核心模块，再分别选择开源组件。

1. 模型接入层

模型接入层的目标是屏蔽不同模型供应商的接口差异，为 Agent、工作流和应用提供统一模型调用能力。Java 技术栈可以优先考虑 Spring AI、Spring AI Alibaba、LangChain4j；Python 技术栈可以考虑 LangChain、LlamaIndex 或 LiteLLM。

Spring AI 的 ChatClient 和 Advisors API 提供了模型调用、上下文增强、RAG Advisor 等能力，适合 Spring Boot 项目接入模型服务。LangChain4j 则更偏 Java 应用中构建 LLM、Embedding、工具调用和 RAG 能力。

企业实现时应把模型类型拆开管理：LLM、Embedding、Rerank、Vision、OCR、语音转文本等分别配置，并支持 OpenAI compatible 模型、公有云模型、私有化模型和国产模型。

2. 知识库 RAG 层

知识库是企业 AI 应用的核心。Dify 官方知识库文档支持创建知识库、管理文档和分段、检索测试、元数据增强、检索策略调整等能力。Dify 的 Knowledge Pipeline 进一步把 RAG ETL 路径做成可视化节点，从数据源、文档解析、切片策略到插件化处理都能编排。

自研平台可以组合以下组件：

RAGFlow 官方文档强调其基于 deep document understanding，适合处理复杂格式数据并提供带引用的问答能力。Docling 也强调对 PDF、DOCX、PPTX、XLSX、图片、HTML 等多格式文档的解析，以及版面、阅读顺序、表格结构和 OCR 能力。企业如果文档形态复杂，不应只做简单文本切片，而要把解析质量、切片策略、权限元数据和检索评测作为知识库工程的关键。

3. Agent 编排层

Agent 的核心不是“会聊天”，而是能在模型、Prompt、知识、工具、上下文和权限边界内完成任务。LangGraph 官方文档把 Workflow 和 Agent 做了区分：Workflow 是预定义路径，Agent 则可以动态决定过程和工具使用。这个区分很重要，因为企业平台通常两者都需要。

自研 Agent 层可以包括：

• 模型和参数配置。
• Prompt、角色、人设和任务约束。
• 知识库选择和检索策略。
• Tool、MCP、Skill 能力调用。
• 会话上下文和记忆。
• ReAct、Plan-and-Execute、Function Calling 等执行策略。
• 调试、流式输出、结构化输出和调用日志。

如果偏 Python 生态，可以参考 LangChain、LangGraph、AutoGen 等；如果偏 Java 生态，可以基于 Spring AI、LangChain4j 和自研执行器组合实现。

4. 工作流画布与运行引擎

Dify 的 Workflow 是它最有代表性的能力之一。企业自研平台可以参考这种“可视化节点 + 后端运行引擎”的架构，但前后端要分开设计。

前端画布可以选：

• React Flow：适合 React/Next.js 技术栈，官方 Workflow Editor 模板支持节点、边、自动布局、拖拽侧栏和 Runner 逻辑。
• LogicFlow：适合 Vue 技术栈，常用于流程图、审批流和自定义节点画布。
• X6、Drawflow、BPMN.js：适合不同复杂度的流程编辑需求。

后端运行引擎可以选：

• 自研轻量状态机：适合 AI 工作流，节点种类可控，易于记录上下文和执行日志。
• Flowable/Camunda：适合 BPMN、审批、人工任务和长事务流程。
• Temporal：适合高可靠、可恢复、分布式任务编排。
• LangGraph：适合 Agentic workflow、状态图和动态路径。

AI 工作流不是传统审批流的简单替代。它要处理 LLM 输出不确定性、工具调用异常、上下文传递、人工确认、重试、流式输出和节点级日志。因此，自研时建议把“画布模型”和“运行模型”解耦，前端负责节点设计，后端负责执行、上下文、日志和权限。

5. Tool、MCP、Skill 能力市场

Dify 有插件和工具生态。对于企业自研平台，更建议把能力分为 Tool、MCP、Skill 三类管理。

• Tool：面向 HTTP API、OpenAPI、数据库查询、脚本函数等调用单元。
• MCP：按照 Model Context Protocol 接入标准化外部工具、资源和提示词。
• Skill：面向一个完整任务的能力包，可以组合 Prompt、Tool、MCP、脚本、模板和业务规则。

MCP 官方组织说明，MCP 是连接 LLM 应用与外部数据源和工具的开放协议。其 Python SDK 文档也强调，MCP Server 可以向 LLM 应用暴露 tools、resources 和 prompts，并支持 stdio、Streamable HTTP、SSE 等传输方式。企业平台接入 MCP 后，可以把地图、搜索、数据库、代码仓库、业务系统等能力标准化暴露给 Agent 和工作流。

Skill 更偏企业能力沉淀。比如合同审查 Skill、会议纪要 Skill、发票报销 Skill、数据分析 Skill。它不是一个函数，而是一个可版本化、可授权、可调试、可复用的任务能力资产。

6. 应用发布与集成层

智能体平台最终要把能力发布给用户和业务系统。常见发布形态包括：

• WebApp 页面。
• Embed 嵌入窗口。
• API 接口调用。
• 企业门户入口。
• 业务系统插件或菜单入口。

这一层需要解决版本管理、角色授权、应用上下架、API Token、会话记忆、运行日志、调用限流、外部系统回调等问题。企业使用 AI 应用时，最关心的往往不是“能不能回答”，而是“谁能用、用的是什么版本、调用了哪些资源、出了问题能不能追溯”。

7. 观测、调试与治理层

McKinsey 在 2026 年关于 agentic AI scale 的文章中强调，Agentic AI 要规模化，需要强数据基础、高影响工作流、数据质量和组织运营模式共同支撑。Gartner 也强调，Agent 治理不能简单一刀切，而要根据自治程度和访问边界做分级控制。

因此，自研平台必须从第一天就设计可观测能力：

• 应用资源依赖：应用引用了哪些模型、知识库、Tool、MCP、Skill、工作流。
• 应用链路日志：一次对话或 API 调用经过了哪些节点和资源。
• Agent 调试诊断：Prompt、上下文、模型响应、工具入参出参。
• 工作流运行日志：节点状态、变量传递、失败原因、耗时。
• 知识检索日志：检索策略、命中文档、权限过滤、引用来源。
• 成本与性能统计：Token、模型调用耗时、工具调用耗时、错误率。

没有这些能力，AI 应用就仍然是黑盒，无法真正进入生产环境。

图：基于开源组件搭建自主可控智能体平台方案图

六、推荐的技术选型组合

如果企业以 Java 和 Spring 技术栈为主，可以采用如下组合：

如果企业以 Python 技术栈为主，可以把 FastAPI、LangChain、LangGraph、LlamaIndex、RAGFlow、Celery、PostgreSQL、Redis、Milvus/Qdrant 作为主要组合。

关键不是哪套技术绝对更好，而是看企业已有团队能力、部署规范、国产化要求、系统集成深度和长期维护成本。

七、开发路线建议：不要一口吃成平台

很多团队做智能体平台容易失败，是因为一开始就想做完整平台。更合理的路线是分阶段演进。

第一阶段，先做模型统一接入和应用配置。解决模型供应商、参数、密钥、调用日志和基础应用发布问题。

第二阶段，做知识库 RAG。先支持 Word、PDF、Excel、Markdown 等常见文档解析、切片、向量化、检索测试，再逐步加入混合检索、Rerank、权限过滤和检索日志。

第三阶段，做 Agent 能力。把模型、Prompt、知识库、Tool、MCP、Skill、上下文和调试日志纳入统一配置。

第四阶段，做工作流编排。先支持输入、输出、LLM、Agent、知识库、工具、HTTP、条件、变量、人工确认等基础节点，再扩展循环、子流程、异常处理和节点级审计。

第五阶段，做能力市场和治理。把应用、Tool、MCP、Skill、Prompt、Workflow 等沉淀为可复用资产，支持版本、授权、导入导出、依赖追踪和日志审计。

第六阶段，做企业级部署和运维。补齐私有化部署、国产化适配、统一认证、监控告警、备份恢复、成本统计和性能优化。

图：从开源组件到企业级智能体平台的演进路线图

八、哪些地方必须自研

基于开源组件开发平台，并不意味着所有东西都拼装。企业级智能体平台有几类能力最好自研或深度掌控。

第一，资源对象模型。应用、Agent、工作流、知识库、工具、MCP、Skill、Prompt、模型、版本、权限、日志之间的关系，决定了平台能不能长期演进。

第二，权限与审计。知识库检索权限、工具调用授权、应用访问授权、日志审计、敏感操作确认，这些能力和企业组织、业务系统强相关，不能只依赖通用开源组件。

第三，工作流运行上下文。AI 工作流里的变量、节点输入输出、模型响应、工具调用结果、人工确认结果，都需要可追踪、可恢复、可诊断。

第四，企业系统集成。CRM、ERP、OA、合同系统、工单系统、数据库、搜索服务、地图服务、消息服务等，往往需要按企业规范封装为 Tool、MCP 或 Skill。

第五，国产化和私有化适配。操作系统、数据库、中间件、模型服务、对象存储、日志系统和部署规范，通常需要根据企业环境做专项适配。

开源组件适合解决通用能力，但企业级平台的长期价值，来自对业务场景、资源模型、治理边界和工程运维的持续沉淀。

九、最后：自主可控不是闭门造车，而是可替换、可治理、可演进

开发一个类似 Dify 的智能体平台，不应理解为复制一个开源产品，而应理解为建设企业自己的 AI 应用工程化底座。

Dify 给出了很好的产品参考：可视化编排、多模型接入、RAG Pipeline、Agent、工具生态和应用发布。LangGraph、Spring AI、RAGFlow、Docling、Milvus、Qdrant、React Flow、LogicFlow、MCP SDK 等开源组件，则分别提供了 Agent 编排、模型接入、知识处理、向量检索、画布编辑和工具协议等底层能力。

真正的自主可控，体现在几个方面：代码可掌控，数据可掌控，模型可替换，组件可替换，部署可私有化，权限可治理，运行可追踪，业务系统可集成。

从这个角度看，本文所述的智能体开发平台路线，核心不是“做一个聊天页面”，而是把模型、知识、工具、流程、发布、权限和日志纳入统一生命周期。云程智能体开发平台的工程化设计，也正是沿着这条路线展开：在学习主流开源平台设计思想的基础上，面向企业级私有化部署、国产化适配、源代码交付和业务系统集成，构建可二次开发、可治理、可持续演进的 AI 应用开发底座。