Dify 官方亲述：我们为什么要推倒重做 Agent 架构？

平衡大模型迭代与企业稳定性

从一开始，构建 Dify 就意味着在两个截然不同的世界之间寻求平衡：一边是飞速迭代的大语言模型，一边是企业软件应有的稳定性。

我们既想让用户享受到最新模型的能力，又要为企业提供在生产环境中真正用起来所需的一切：私有化部署、模型自由选择、访问控制、可解释性和可审计性。要同时兼顾两者，从来都不是一件容易的事。这种张力不仅塑造了我们的构建方式，也决定了我们选择不做什么。

今年早些时候，OpenClaw 爆火，我们本可以一拥而上火速做一个 Dify 版本。但我们选择更冷静地观察其走红背后正在形成的更大共识：CLI Agent 模式不再只是编程领域的专属，它开始在企业真实的业务流程中找到自己的位置。

这正是我们想要押注的转折点。我们重新设计了 Dify 的 Agent 系统，让基于 Dify 构建的应用和工作流，能够把复杂任务中的一部分交给 CLI Agent 去完成。

新 Agent 适用于哪些场景

你的团队可能已经有了一套标准操作流程（SOP）和相关技能的积累。其中一部分工作重复且耗时，你可以让新 Agent 接手这部分工作，而不必推倒重建整个流程。

又或者，你所需要的某项服务尚未被 Dify 的插件生态覆盖，新 Agent 可以帮你弥合这一集成空缺，因为它能够直接调用 CLI 工具。

还有一些情况：团队里的人清楚什么样的产出才算好，只是不想先去学一遍提示词、工具、文件和运行时配置。

Build Mode（构建模式）正是为此而生：你可以通过聊天来搭建 Agent。

你无需手动填写每一项配置，只需带着 Agent 走几遍真实任务，就像带一位新入职的同事：一起尝试完成任务、纠正它、再试一次。过程中沉淀下来的技能、工具和关键指令都会被保存下来，供后续运行使用。

Agent 循环只是起点

Build Mode 让 Agent 的搭建变得更容易，但当 Agent 真正跑进工作流里，"容易搭建"就远远不够了。

在核心层面，这套系统采用了你可能已经在 Codex 和 Claude Code 中见过的同款模式：由模型驱动的 ReAct 循环、Bash 工具，以及一个用来说干就干的隔离沙箱。

但循环只是起点。一个需要反复运行的 Agent，还要能在长任务中管理上下文、在不同模型之间切换、维持稳定的运行环境，并在故障发生时做出可预期的响应。

为了持续可靠地运行，Agent 还需要在模型间灵活切换、管理长任务上下文、维护自己的运行环境，并以可预期的方式处理失败。在这些基础能力上，我们做了大量投入。用当下 Agent 领域的话说，这就是"循环工程"（Loop Engineering），而 Dify 开箱即为你提供了坚实的地基。

在安全与合规方面，Dify 企业版会让每一次会话都运行在专属的沙箱容器中，实现进程、文件系统和网络的全面隔离。管理员可以自定义网络策略和安全上下文。每个沙箱都基于加固的基础镜像构建，并以非 root 权限运行。

Agent 都这么能干了，为什么工作流依然重要

过去半年我们无数次听到这个问题，答案是：

是的，工作流依然重要——因为 Agent 和工作流承担的是不同的职责。

Agent 决定如何完成一项任务；工作流则决定这项任务何时发生、前后如何衔接、什么时候需要人介入，以及出了问题该怎么办。

无论一个人多么能干，复杂的工作仍然需要日历、即时通讯、审批和可复用的流程，来让所有人保持协同。

我们把工作流视为 Agent 与人之间的协调层：它把灵活的 Agent 行为，转化为可调度、可监控、可长期稳定运行的流程。Agent 能承担的工作越多，这种协调就越重要。

从一次性的灵光乍现，到持续运转的系统

这正是工作流大显身手的地方。Agent 擅长即兴发挥：写个脚本、调几个工具、操作文件，解决一个没人提前规划过的任务。

这确实令人惊艳，但一次成功的运行并不等于一个系统。

工作流通过给 Agent 划定清晰的边界，让这种能力变得可复现：明确的输入输出、执行计划、权限、失败处理和监控。在这些边界之内，一次性的即兴发挥，就变成了可以长期可靠运行的流程。

最终产物不一定是一个完整的应用。更多时候，它只是填补你正在使用的产品中某个空缺的一小块软件。你可以把它理解成专属于你自己的"软件补丁"。

一个来自我会议预约的小例子

我用 Calendly 安排与客户和合作伙伴的会议，通常提前几周就订好了。可等到会议真正到来时，一些参会者早就忘了这回事：要么毫无准备地参会，要么在最后一刻改期，在我的日历上留下一个尴尬的空档。

Calendly 的免费版几乎满足了我所有的需求，唯一缺失的功能是当天的会前提醒。

我当然可以让一个编程 Agent 把 Calendly MCP 接到邮件客户端上，写一个提醒脚本，再部署成定时运行的 GitHub Action。这些都不算难，但对非开发者来说，听起来就像一个大工程。

在 Dify 里，这个过程简单得多：安装 Gmail 插件，通过 Build Mode 配置 Calendly MCP，做几次测试，然后把它加进一个定时工作流。大约十分钟后，它就开始自动检查我的会议并发送提醒了。这不是一个新应用，只是补上了我恰好缺失的那一块。

JOTO 企业落地观察

• 企业部署 CLI Agent 类系统时，必须明确其定位是‘补丁’而非‘平台’。这类系统的核心价值在于快速对接已有工具链（如 Calendly+Gmail），而非重构基础设施；因此部署重点应放在接口适配、权限收敛与失败回滚机制上，而非追求通用能力。
• 对于智能体工程团队，Dify 新架构中强调的‘循环工程’（Loop Engineering）意味着：长任务上下文管理、模型切换策略与沙箱稳定性，已成为比 Prompt 设计更关键的交付物。企业需将这些能力纳入 CI/CD 流水线进行版本化管控。
• RAG 知识工程在此类系统中角色发生转变——不再仅服务于问答，而是作为 Agent 决策链中可插拔的‘事实校验模块’。例如会议提醒 Agent 需实时核对日历状态，此时 RAG 应嵌入执行循环内，而非仅用于初始化阶段。
• AI 安全治理需覆盖 Agent 运行时态：Dify 企业版沙箱方案表明，进程、文件系统与网络三重隔离是生产环境底线。企业若自建类似能力，须验证非 root 权限下 CLI 工具链的完整性，避免因权限限制导致工具失效引发静默失败。