Dify 的官方博客 recently 发了一篇文章，标题很直白："Why We Redesigned Dify's Agent?"
读完之后我觉得值得聊聊。不只是因为这次改了什么，更因为 Dify 在这篇文章里说清楚了一件事——Agent 和 Workflow 不是替代关系，而是协作关系。
这个判断，对做 Agent 框架的人来说，比任何功能更新都重要。
起因：OpenClaw 火了，但 Dify 没有急着抄
文章里提到一个细节挺有意思的。
今年早些时候 OpenClaw 爆火，Dify 团队说他们"本可以赶紧做一个 Dify 版"，但选择先观察。他们注意到的不是 OpenClaw 本身，而是它背后的趋势——CLI Agent 模式不再只属于编程领域了，它开始在真实业务场景里找到位置。
所以 Dify 的重设计目标很明确：让 Dify 上构建的应用和工作流，能把复杂任务的一部分交给 CLI Agent 来处理。
不是造一个聊天机器人，而是造一个能跑代码、操作文件、调用工具的"数字同事"——然后让这个同事融入你现有的工作流程。
Build Mode：像带新人一样构建 Agent
这是新设计里我觉得最有意思的部分。
以前构建一个 Agent，你需要手动填每一个配置项——Prompt、工具、模型、环境变量。现在 Dify 推出了 Build Mode，你可以直接通过对话来构建 Agent。
操作方式很像"带新人入职"：
-
你描述一个任务 -
Agent 试着完成它 -
你纠正它 -
再试一次 -
过程中学到的技能、工具调用方式、关键指令，都会被保存下来
技术上说，Build Mode 会把对话中产生的配置变更先保存为 Build Draft（草稿），你可以选择 Apply（应用）或 Discard（放弃）。这就避免了"Agent 在处理用户请求时偷偷改写了自己的持久化配置"这种尴尬。
这里有个关键区分：
这个设计很聪明。聊天式配置很方便，但你不希望一个 Agent 在干活的时候把自己"改造"了。
Agent 不只是一段 Prompt
这是文章里另一个核心观点。
Dify 把 Agent 的能力拆成了四个独立模块：
-
Prompt：定义角色和行为边界 -
Skills：可复用的业务方法论，包含操作指南、参考资料和执行脚本 -
Tools：外部集成能力，从 Marketplace 安装或连接自定义 API / MCP -
Sandbox CLI：处理临时需求，Agent 可以在当前沙箱里直接安装和运行命令行工具
为什么要拆开？
因为如果你把所有东西都塞进 Prompt，配置会越来越长，越来越难维护。拆开之后，你可以分别维护不同能力——换一个工具不用改 Prompt，优化一项技能不用动工具配置。
Skills 的概念特别值得关注。它不是简单的 Prompt 片段，而是把"怎么干这件事"封装成一个可版本化、可复用的能力包。团队里有人摸索出一套好用的方法，打包成 Skill，其他 Agent 直接调用。
Agent 负责"怎么干"，Workflow 负责"什么时候干"
这是整篇文章里我最认同的判断。
Dify 团队被问了半年这个问题："Agent 这么强了，Workflow 还有意义吗？"
他们的回答很干脆：有，因为 Agent 和 Workflow 干的是不同的事。
-
Agent决定如何完成一个任务 -
Workflow决定这个任务什么时候发生、之前做什么、之后做什么、什么时候需要人介入、出了问题怎么办
不管一个人多能干，复杂工作还是需要日历、消息、审批和可重复的流程来保持协调。
这个分工很清晰：
一次成功的即兴发挥不是一个系统。Workflow 把 Agent 的即兴能力变成可以重复运行、可以调度、可以监控的流程。Agent 能接手的活越多，Workflow 的协调作用就越重要。
一个真实的例子：Calendly 会议提醒
文章里举了个很小的例子，但很说明问题。
作者用 Calendly 管理客户会议，经常提前几周就约好了。但到开会的时候，有些参会人已经忘了，要么没准备就来，要么临时改期。
Calendly 免费版什么都能做，唯独缺一个当天提醒。
找编程 Agent 来做也不难——接 Calendly MCP，写个提醒脚本，部署成 GitHub Action。但对非开发者来说，这听起来像个大工程。
在 Dify 里：装 Gmail 插件 → Build Mode 配置 Calendly MCP → 测几轮 → 加进定时工作流。十分钟搞定。
不是新应用，就是缺的那块拼图。
背后的架构变化
从技术角度看，这次重设计的变化其实非常大：
之前：Agent 是 Workflow 里的一个执行节点，本质上是一个"代理策略" 现在：Agent 是拥有独立身份、配置和生命周期的 Dify 资源
每个 Agent 都有自己的：
-
模型配置 -
指令（Prompt / Build Note） -
技能（Skills） -
工具（Tools / MCP） -
沙箱环境（本地 / E2B 云沙箱） -
环境变量 -
版本、日志、追踪 -
发布入口（Web App / API / Workflow 调用）
关键特性：
-
E2B 云沙箱：Agent 可以在云端隔离环境里跑代码和 Shell，不依赖本地执行 -
Home Snapshots：发布的 Agent 可以恢复构建时的文件系统状态，包括安装的包和准备好的文件 -
Skills 管理：工作区级别的 Skills 可以被多个 Agent 发现和调用 -
声明式输出：Workflow 可以定义 Agent 节点的输出字段（如 vendor_name、price、recommendation），下游节点直接引用，不需要解析自由文本 -
上下文压缩：长对话自动压缩历史，保持在模型有效窗口内
对 Agent 框架方向的启示
读完这篇文章，我觉得有三个判断值得关注：
1. Agent 和 Workflow 不是竞品，是搭档
很多框架在"Agent 还是 Workflow"这个问题上站队。Dify 的选择是：两个都要，但各司其职。Agent 做决策和执行，Workflow 做编排和控制。
这个分工在生产环境里非常重要。一个能自主行动的 Agent 如果没有流程约束，就是定时炸弹。
2. "怎么构建 Agent"比"Agent 能干什么"更重要
Build Mode 解决的不是 Agent 的能力问题，而是构建门槛问题。当 Agent 的能力越来越强，"怎么用"比"能做什么"更关键。像带新人一样通过对话构建 Agent，这个体验比填表单好太多了。
3. Skills 会成为 Agent 生态的关键抽象层
把业务方法论封装成可复用、可版本化的 Skill，让 Agent 不是每次都从零开始，而是能调用团队沉淀的最佳实践。这个方向如果走通了，Dify 的 Marketplace 就不只是工具市场，而是"工作方法"市场。
写在最后
Dify 这次 Agent 重设计的核心不是加了什么新能力——Linux 沙箱、ReAct 循环、E2B 云沙箱这些技术本身都不新鲜。
真正的变化在于定位：Agent 不再是一个执行节点，而是一个可独立构建、可复用、可观测、有完整生命周期的"数字同事"。Workflow 不再是 Agent 的容器，而是 Agent 和人协作的协调层。
用他们的话说：
The goal isn't another standalone agent. It's a workflow that brings agents, existing systems, and people together.
这才是 2026 年 Agent 框架该有的样子。不是比谁的 Agent 更聪明，而是比谁能让 Agent 真正融入生产流程。
Dify社区群：嗨聊吧
欢迎扫码加入嗨聊吧！
