企业AI应用的分层架构设计

以“LLM+聊天UI”的方式引入企业人工智能的时代已经结束。为了平衡生产环境中的可靠性、可扩展性和治理，基于清晰层分离的架构设计至关重要。本文提出了一个四层模型：基础设施层、平台层、应用层和表示层，并解释了 Dify 定位在哪一层以及如何设计各层之间的集成模式。

整体架构概览

graph TB
    subgraph PL["プレゼンテーション層（ユーザー層）"]
        WEB["Web UI / チャット"]
        MOBILE["モバイルアプリ"]
        INTERNAL["社内ポータル連携"]
        API_GW["API Gateway"]
    end

    subgraph AL["アプリケーション層"]
        APP1["契約レビュー Assistant"]
        APP2["社内 FAQ Bot"]
        APP3["稟議ドラフト生成"]
        APP4["製造品質分析"]
        APP5["文書処理パイプライン"]
    end

    subgraph PLAT["プラットフォーム層 ← Dify"]
        MODEL["モデル管理・ルーティング"]
        KB["Knowledge Base"]
        WF["Workflow エンジン"]
        AGT["Agent フレームワーク"]
        GOV["権限・ログ・監査"]
        TOOL["Tool / Plugin 管理"]
    end

    subgraph INFRA["インフラストラクチャ層"]
        K8S["Kubernetes / コンテナ基盤"]
        DB["PostgreSQL / RDS"]
        REDIS["Redis / ElastiCache"]
        S3["S3 / オブジェクトストレージ"]
        VDB["ベクトルDB（Weaviate / Qdrant）"]
        NET["ネットワーク / Ingress / WAF"]
    end

    PL --> AL
    AL --> PLAT
    PLAT --> INFRA

为什么我们需要分层架构

职责分离原则

企业人工智能基础设施涉及各种各样的利益相关者。

利益相关者	兴趣	对应层
基础设施团队 (SRE)	可用性、扩展性和成本	基础设施层
人工智能平台团队	模型管理、RAG 质量、治理	平台层
业务拓展团队	业务逻辑、用户体验	应用层
最终用户/外部系统	使用方便，响应速度快	表示层

如果不分层，模型变更将波及到基础设施配置，业务应用修改将与整个平台的发布周期捆绑在一起。有一个金融行业大公司的案例，LLM版本更新触发了全公司系统测试，因为这种分离不充分。

日本企业特定的考虑因素

数据主权：遵守个人信息保护法和金融服务机构指南。通过分离模型推理层和数据存储层，可以定位数据跨界问题。
多供应商策略：与日本公司常见的SI划分系统兼容。可以将A公司的基础设施、B公司的平台运营以及内部应用程序开发分开。
逐步实施：从PoC到生产逐层提高成熟度。

基础设施层设计指南

组件和推荐配置

组件	开发/验证环境	生产环境（中型）	生产环境（大规模）
库伯内特	单节点/Docker 撰写	3+ 个工作节点	5 个以上工作节点，多可用区
PostgreSQL	单实例	RDS 多可用区	极光 PostgreSQL
Redis	单实例	ElastiCache（副本）	Redis哨兵/集群
对象存储	本地卷	S3	S3 + CloudFront
矢量数据库	Weaviate单	韦维特集群	Qdrant 分布式 / pgvector
网络	节点端口	ALB + 入口	ALB + WAF + 私有链接

###基础设施层设计原则

无状态/有状态分离：Dify 的 API Server 和 Workers 被设计为无状态，使得水平扩展变得容易。最好将有状态数据存储（PostgreSQL、Redis、向量数据库）委托给托管服务。
资源预留：使用 NodePool 分离 GPU 节点（如果您内部托管模型推理）和 CPU 节点
秘密管理：使用 Kubernetes Secrets 或 HashiCorp Vault 集中管理 API 密钥和数据库凭证

平台层设计指南–Dify定位

Dify 覆盖的领域

Dify 位于企业人工智能应用基础的平台层。具体来说，它提供了以下功能。

graph LR
    subgraph DifyPlatform["Dify プラットフォーム層"]
        direction TB
        MP["Model Provider 管理<br/>OpenAI / Azure / Anthropic / 国産LLM"]
        KB2["Knowledge Base<br/>ベクトル検索 / 全文検索 / Hybrid"]
        WF2["Workflow Designer<br/>条件分岐 / ループ / 外部API呼出"]
        AG2["Agent<br/>Tool 呼び出し / ReAct / Function Calling"]
        PERM["Workspace 権限管理<br/>メンバー / ロール / API キー"]
        LOG["ログ・可観測性<br/>実行履歴 / トークン使用量"]
    end

###平台层向应用层提供的接口

Dify 通过以下方式向上层应用程序层公开功能。

接口	应用	典型使用场景
休息 API	来自应用程序的调用	来自内部系统的聊天机器人/完成调用
网络钩子	事件驱动的协作	向 Slack / Teams 发送工作流程完成通知
嵌入小部件	网页嵌入	嵌入内部门户的聊天 UI
工作流程作为 API	将复杂的处理管道转换为API	系列文件导入→分类→汇总→通知

平台层设计注意事项

模型路由策略：不是对所有应用程序使用相同的模型，而是根据任务特征在 GPT-4o / Claude / 轻量级模型之间切换。 Dify 模型提供程序设置允许基于每个工作空间进行控制
知识库分而治之：按部门/业务领域划分知识库，并限制每个应用程序的引用（详细信息请参阅“知识库可扩展设计”）
治理政策：设置令牌使用限制、模型访问审批流程以及管理提示模板

应用层设计指南

###应用模式分类

图案	特点	Dify中的实现方法	行业实例
互动助手	与用户自然语言对话	聊天机器人应用程序 + 知识库	财务：内部查询机器人
文档处理管道	大文档量的批处理	工作流程（HTTP + LLM 节点链接）	制造：质量报告自动摘要
决策支持	多方信息分析与建议	代理+工具（数据库搜索/API调用）	零售：需求预测报告生成
代码生成/审查	软件开发支持	完成应用+自定义提示	IT：代码审查支持
多式联运处理	图像/PDF/音频理解	工作流程+视觉模型	保险：定损单据图像分析

应用层与其他层的边界

应用层应该具备什么：

业务逻辑（审批流程、通知规则、输出格式）
用户认证/授权（SSO联动、API密钥管理）
特定业务的前处理和后处理

应用层不应该有的东西：

直接模型调用（通过平台层）
直接访问Vector DB（使用知识库API）
基础设施配置管理

表示层设计指南

连接模式

graph LR
    U1["エンドユーザー"] --> WEB2["Dify Web UI"]
    U2["社内ユーザー"] --> PORTAL["社内ポータル<br/>（iframe / API）"]
    U3["モバイルユーザー"] --> MAPP["モバイルアプリ<br/>（REST API）"]
    U4["外部システム"] --> APIGW["API Gateway<br/>（認証 + レート制限）"]
    
    WEB2 --> DIFY["Dify Platform"]
    PORTAL --> DIFY
    MAPP --> DIFY
    APIGW --> DIFY

日本企业的典型整合目的地

整合目的地	连接方式	笔记
微软团队	Bot 框架 + Dify API	需要与 Azure AD 进行 SSO 集成
松弛	Slack 应用程序 + Webhook	企业网格需要安全审查
立即服务	REST API 集成	工单创建/更新流程设计
SAP	RFC/BAPI → 中间 API → Dify	需要数据转换层
通通	Webhook + REST API	定制JS API调用

层间集成模式

模式 1：同步 API 调用

最简单的模式。如果响应时间落在 SLA 范围内，则适用。

ユーザー → API Gateway → Dify REST API → LLM → 応答返却

预计延迟：1-10秒（取决于型号提示长度）

模式 2：异步工作流程

适用于长期加工和批量加工。使用 Dify Workflow 进行排队。

外部トリガー → Dify Workflow API → 処理実行 → Webhook 通知 → 結果格納

模式 3：事件驱动的协作

使用文档注册/更新作为触发器自动更新知识库。

文書管理システム → Webhook → Dify Knowledge Base API → 自動インデックス更新

相	持续时间	行动	蛋鸡成熟度
第一阶段：PoC	1-2个月	使用 Docker Compose 进行 Dify 验证，1-2 个应用程序原型设计	基础设施：最低/平台：正在验证
第 2 阶段：试点	2-3个月	Kubernetes迁移、生产级基础设施建设、3-5个应用部署	基础设施：生产级/平台：稳定
第 3 阶段：全公司部署	3-6个月	多工作空间、已建立的治理、10 多个应用程序	各层生产运作
第四阶段：优化	连续	成本优化、模型策略审查、新用例	各层成熟

反模式

以下架构决策很可能会导致企业运营出现问题。

反模式	问题	推荐方法
单一人工智能应用程序	模型变化波及各处	层层分离+API抽象
每个部门都建立自己的LLM基础设施	成本增加和治理的不可能性	建立通用平台层
跳过平台层直接调用LLM	没有审核日志，提示难以管理	通过 Dify 标准化模型访问
基础设施层与应用层紧耦合	扩展困难和迁移成本增加	利用托管服务 + IaC

总结

企业人工智能应用的分层架构不仅仅是一个概念组织；这是一项实用的设计政策，可以明确团队之间的职责划分并将变更的影响本地化。通过将 Dify 定位在平台层，基础设施团队可以专注于基础设施，业务团队可以专注于业务逻辑，实现整个 AI 平台的治理和可扩展性。

特别是对于日本大型企业来说，它与SI合作伙伴的共享结构和分阶段引入流程高度兼容，是在利用现有IT治理体系的同时加速人工智能应用的现实方法。

参考资料

Dify官方文档：Overview
Dify企业部署指南：Kubernetes
Dify Helm 图表：Advanced Configuration
Dify API开发指南：API ベースの開発

MKC — Dify Japan 内容体系