我们为什么重新设计了 Agent？
Dify 重新设计 Agent 系统，旨在平衡 SOTA 模型能力与企业级需求（私有化部署、模型中立、权限管理、可解释性、可审计性）。新 Agent 基于 ReAct Loop 与沙箱执行，聚焦 CLI 工具集成、上下文与失败策略管理，并强调与工作流协同——Agent 解决个体能力，工作流解决组织调度。目标是将即兴智能固化为可长期运行的‘软件补丁’。
在模型浪潮与企业需求间做取舍
自诞生起，Dify 一直在做一件有些拧巴的事：试图在快速发展的模型浪潮中，提供一套成熟的企业脚手架。但这意味着，必须时常在释放 SOTA（state-of-the-art，最先进水平）模型实力以及企业要求的：私有化部署、模型中立、权限管理、可解释和可审计之间做出取舍。
因此，年初龙虾热的时候，没有立即跟进做一款 DifyClaw 那样的时尚热门单品类产品。但很让人兴奋的是，这几波热潮推动了社会共识的形成：CLI Agents 的范式借此契机正在走出 Coding 场景，进入越来越多的企业，解锁越来越多业务场景。
基于这个变化，重新设计了 Dify 中的 Agent 系统，让 Dify 应用和工作流可以将一部分复杂任务交给 CLI Agents 来完成。
哪些任务适合交给新的 Agent？
如果你的团队已经沉淀了一套成熟的业务 Skills，希望快速转化为 Agent 的能力，让 Agent 接手业务中重复、耗时的工作；如果你遇到了 Dify 插件生态尚未覆盖到的集成问题；又或者，业务人员希望通过对话指导和打磨一个 Agent，并绕过晦涩难懂的技术学习，那么，新的 Agent 值得一试。
熟悉的内核，完备的基础工程
从原理上看，新的 Agent 系统和 Codex、Claude Code 等 Coding Agents 采用了相近的核心结构：由模型驱动的 ReAct Loop，通过 Bash 等工具在独立沙箱环境中完成任务。
但 Agent 能真正进入生产环境，仅靠能够循环调用工具是不够的。
幕后，把大量精力投入到了模型切换、上下文管理、运行环境管理、失败策略等基础能力中。用当下时兴的说法，Dify 提供了一套相对完备的 Loop Engineering。这样，不必再为每个 Agent 重复解决这些常见问题，而可以把精力投入到如何将这些 Agents 编排到业务流程中来。
在安全与合规方面，Dify 企业版为每个会话启动一个独立的 Sandbox 容器，实现 PID、FS 和网络隔离，并支持配置自定义的网络策略和 Security Context。Sandbox 基于安全加固的基础镜像构建，并以非 Root 用户运行。
Agent 与工作流：能力与调度的分工
近半年，经常被问到一个问题：当 Agent 经历了三年的探索，如今终于形成被广泛承认的范式之后，Dify 是否还会继续做工作流？
我们的答案是：当然会，因为 Agent 与工作流解决的是不同维度的问题。
Agent 解决的是个体能力问题，而工作流解决的是能力如何能被组织和调度的问题。
即使个体能力强如人类，依然发展出了如线上会议软件、企业 IM、OA 工具、OKR 等一系列的“协作基础设施”。其中，有一些服务于临时协作，另一些负责承载稳定、反复发生的流程。
我们认为工作流解决的问题，是企业如何把现有的固化流程，以一种合理的方式，转化为 Agent 与人的协作产物，并让该产物能便捷地发布并在一套企业级基建上以及长期运行。在 Agent 能力得到跃升的今天，这个需求不但没有消失，反而显得愈发紧迫。
从即兴发挥到可长期运行的软件补丁
传统的软件，本质上由数据库、数据之上的函数、以及人与这些函数交互界面组成。今时今日，Agent 已经可以在大量的一次性场景中临时客串这套系统：即兴生成的脚本，开始替代一部分过去必须由严谨代码实现的功能。
但即兴发挥本身不是生产系统。
当把 Agent 放进前文所述的编排里，再用确定性的输出输入、调度机制、失败策略、权限和可观测性为它划定边界，就能把这些即兴能力固化下来。由此获得的未必是一套完整软件，更现实的形态是，为现有软件快速补上缺失的能力 —— 一块属于自己的软件补丁。
PM 实例：Calendly 会议强提醒补丁
和许多需要承担对外沟通工作的人一样，惯用 Calendly 约会议。但预约跨度较长时，参会者经常忘记会议。
只需要一个非常小众的需求：在会议当天再次自动发邮件提醒对方（这通常需要昂贵的付费订阅）。
理论上，这个需求从技术上看并不复杂。开发者可以让 Coding Agent 接入 Calendly MCP 和邮件客户端，编写一套自动提醒程序，再发布为一个 Github Action 实现云端定时执行。而对于非开发者来说，这依然是一个不大不小的工程。
在 Dify 里，这件事变得异常简单：安装 Gmail 插件，通过 Build Chat 教 Agent 配置 Calendly MCP。在完成测试后，将这个 Agent 作为 Agent 节点放入一个定时工作流中。这样，任何人都能在 10 分钟内，完成一个生产级的 SaaS 软件补丁。
接下来：Agent 与 SOP
新 Agent 解决了"有没有"的问题。接下来，会把重点转向两个方向：
横跨多种 Agent 技术栈的集成，包括不同的 CLI Agent 和各类 Agent SDK；
Agent 与人的企业级协同，尤其是 Agent + Human 的 SOP 编排。
我们的目标不再是增加一个单独的 Agent，而是让不同的 Agent、与现有软件系统和真实的人，可以在同一套流程中协作
JOTO 企业落地观察
- 企业部署 CLI Agent 时，需权衡沙箱隔离强度与运维成本：PID/FS/网络全隔离虽提升安全性，但对容器编排与资源监控提出更高要求，中小团队宜从轻量级隔离起步，逐步演进。
- 将 Agent 编排进工作流，本质是将“非确定性能力”纳入“确定性流程”，这对 RAG 知识工程提出新挑战——需确保 Agent 所调用的外部工具描述、参数约束、错误码映射等元信息本身具备版本化、可审计的知识治理能力。
- “软件补丁”模式降低了 AI 落地门槛，但也模糊了责任边界：当 Agent 补丁出现误操作，企业需在工作流层预设人工审核节点或回滚机制，而非依赖 Agent 自身的“反思”能力，这对 FDE 驻场共创中的 SOP 设计提出前置要求。
- Agent + Human 的 SOP 编排，要求工作流引擎支持细粒度的人机交接点定义（如审批触发、异常接管、结果确认），而非仅提供“等待人工输入”这类通用节点——这对智能体工程中的状态机建模与可观测性埋点构成刚性需求。
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
想把这些做法用到你的业务里?
留下你的场景和痛点,我们帮你判断从哪一步开始。
联系我们
