Dify

Dify、WorkBuddy 和 AI Stack 怎么分层：平台、入口与算力的关系

2026 年 7 月 16 日

把 Dify、WorkBuddy 和 AI Stack 放进同一张架构图时，最容易出现的误解是把三者画成可以互换的方框。更清楚的分层是：AI Stack 提供受控环境中的模型与相关基础能力，Dify 承担应用、知识和工作流编排，WorkBuddy 面向办公用户提供任务入口与交互。实际支持范围仍以各自官方资料和项目验证为...

Dify、WorkBuddy 和 AI Stack 怎么分层：平台、入口与算力的关系

是否需要三层架构

先判断是否真的需要三层。只有办公入口和少量固定接口时，可以减少中间组件；只有后台智能流程而没有统一桌面入口时，也不必强行引入前端代理。三层组合更适合多个办公场景共享私有模型、知识和业务工具，同时要求集中身份、权限和审计的情况。选型应从业务链路出发，而不是凑齐产品清单。

再看每层是否有独立责任人。AI Stack 侧负责模型版本、资源、网络和服务可用性；Dify 侧负责应用定义、提示、知识、工具和发布；WorkBuddy 侧负责用户入口、任务上下文和确认体验。企业身份目录与业务系统则是外部事实源。若同一问题没有明确归属，故障时会在三层之间反复转移。

还要确认接口边界。模型接口处理推理请求，不应直接获得全部业务权限；工作流接口只开放必要能力；办公入口不能携带共享管理员密钥。涉及发信、审批或修改记录的动作，要让业务系统再次校验身份和权限，并给用户人工确认机会。无法说明调用者、目标和失败行为的接口不适合进入组合架构。

实施四步拆解法

首先画出数据与控制流。用户在 WorkBuddy 发起任务，入口携带可信身份和请求标识调用 Dify 应用；Dify 按流程检索获准资料、调用 AI Stack 模型并在需要时访问业务工具；结果返回入口展示。每条连线注明协议、认证、输入输出、超时、重试、日志和负责人，禁止用一条笼统的“系统集成”线掩盖边界。

第二步统一身份映射但不混同权限。目录账号映射到 WorkBuddy 用户、Dify 应用角色和模型调用主体，各层保留本层最小权限。服务账号与人员账号分离，测试和生产分离，离职或角色变化能在约定时间内传递。审计记录通过请求标识关联，但日志只保存定位所需字段，不复制所有正文。

第三步按层建立失败策略。AI Stack 超时，Dify 返回明确错误或进入已评测降级；Dify 工作流节点失败，任务停在可重放状态；WorkBuddy 无法展示确认页，不得继续执行外部写入。重试必须有限次且使用幂等标识。高风险节点展示证据、参数和影响，由授权人员人工确认，拒绝后记录原因而不继续。

第四步做端到端验收。用例覆盖首次登录、无权限用户、知识检索、长任务、模型不可用、工具超时、重复提交、取消任务和审计查询。分别记录每层的日志与业务结果，确认告警能找到负责人。发布采用小范围入口，保留上一版连接配置、应用导出和模型路由，观察稳定后再扩大。

不可忽略的架构限制

三层架构增加了版本组合、网络跳数和排障成本。某层控制台显示正常，不代表完整路径可用；模型返回成功也不代表业务动作完成。官方能力和接口可能变化，升级时一次只改一层，并用固定案例回归。用户体验中的等待、取消和重复点击也要纳入设计。

回滚应区分模型路由、应用版本和入口配置。若外部系统已经写入，回退组件不能自动撤销业务结果，必须对账并按业务规则处理。发现越权或身份错配时立即关闭相关连接，保存必要审计证据，修复映射后由安全与业务人员复验。只要任一层的恢复、人工接管或责任边界未被验证，就不能把组合视为完整上线。

参考资料

JOTO 企业落地观察

对企业部署意味着需明确划分模型运行环境（AI Stack）、智能体工程中枢（Dify）与终端交互界面（WorkBuddy）的职责边界。若将三者混为单一部署单元，将导致故障归因困难、权限扩散与升级耦合，尤其在私有化交付中易引发运维责任真空。
这类系统的取舍在于：是否接受跨层调试复杂度以换取统一治理能力。当企业已有成熟身份目录与审计体系时，强制引入三层可能增加适配成本；但若需支撑多业务线复用同一套知识库与模型能力，则分层可降低长期维护熵值。
在 RAG 知识工程实践中，Dify 作为编排层承担了知识切片、检索策略与上下文注入逻辑，而 AI Stack 仅提供原始推理能力。这意味着知识质量、时效性与权限隔离必须在 Dify 层显式建模，不能依赖底层模型服务自动保障。
AI 安全治理的关键控制点正从单点防护转向跨层协同。例如模型调用需经 Dify 做 prompt 安全过滤与上下文脱敏，WorkBuddy 入口则需确保操作意图可追溯、高危动作需二次确认——任何一层缺失该能力，都会使整体架构产生治理盲区。