Dify 1.17把Agent从临时节点变成了正式资产：Agent平台化的关键一步

做Agent开发的人应该都有过这种体验：一个Agent在工作流里跑得好好的，想复用到另一个场景，结果发现Prompt、Tools、参数全要重新配一遍。配完之后两个副本各自漂移，改一个忘改另一个，半年后根本不知道谁在维护。

8月27日，Dify发布了1.17.0版本，其中最核心的更新是"New Agent"。一句话概括这次变化：Agent从工作流里的临时节点，变成了一个独立的、可复用的、有生命周期的应用。

这个变化为什么重要？因为它解决的是Agent从"Demo"到"生产"之间最容易被忽视的问题：治理。

从临时节点到独立资产

以前Dify里的Agent是跟着所在Workflow存在的。想在另一个应用复用，得重新复制Prompt、Tools和参数，然后每个副本开始各自演变。New Agent改成了单一配置源：名称、说明、模型、Prompt、Skills、Files、Tools和发布状态全部集中管理，并显示创建者、更新时间和调用入口。

一个Agent可以发布为独立Web应用，也能暴露为API，或者被多个Workflow引用。进入具体流程后，Workflow只需要用Agent Task声明这个节点要完成什么、读取哪些上游变量、向下游交付什么结果，不用重新搭建整套配置。

简单说，这就像把函数封装成了模块。以前每用一次都要重新写代码，现在只需import一下。

三层能力扩展：Tool、Skill与Plugin

Dify这次把能力扩展拆成了三个层级，每个层级对应不同的承诺和使用场景。

Tool是最底层的，用于长期受管的外部连接，包括插件、API、MCP和Workflow as Tool。这些是稳定的、经过验证的能力，改动需要走审批流程。

Skill是中间层，把操作说明、背景材料和执行脚本打包在一起，形成一个可交付的能力单元。它比Tool更完整，包含了"怎么用"的上下文信息。

Plugin是最上层的，支持可安装的模块，通过Dify Marketplace进行分发。这三层分工解决了企业Agent开发中"什么都往Prompt里塞"的问题。

Build Mode：让非技术人员也能参与

另一个值得关注的新功能是Build Mode。它让业务专家可以通过真实任务和Agent一起试做，模型提出的变更先进入Build Draft，用户可以保留或放弃。系统还用build_note.md文件记录配置变化和未完成事项。

这个设计的巧妙之处在于，它把"会不会写Prompt"这个技术门槛，转化成了一段可审查的配置迭代过程。业务人员不需要懂技术细节，只需要判断Agent的提案是否合理。这对企业落地Agent来说非常关键，因为最终使用Agent的人往往不是构建Agent的人。

Agent平台化的趋势信号

从1.15.0到1.17.0，Dify在几周内完成了从插件系统到Agent架构重构的迭代。E2B云沙箱、工作区级别的技能管理、统一追踪等功能的同步上线，说明Dify正在从"开发者的实验工具"向"企业级AI应用平台"演进。

这个方向不是Dify独有的。如果你观察整个Agent开发生态，从LangChain的LangGraph到扣子Coze的工作流，大家都在解决类似的问题：怎么让Agent不只是能跑，而是能管、能复用、能交接。Dify这次的New Agent是目前看到的最直接的一个答案。

对企业来说，Agent平台化意味着一个重要的转变：Agent不再是某个人的个人项目，而是团队可以正式管理的数字资产。当Agent有了生命周期、版本管理和访问控制，它才能真正进入生产环境。

写在最后

对还在用Dify搭Agent的团队来说，1.17.0值得认真升级。New Agent的价值不只是"复用更方便"，而是Agent第一次变成了一个可以正式交接的资产。以前团队里有人离职，他搭的Agent基本就成了黑箱；现在，配置集中管理、变更有记录、调用有追踪，交接终于有据可依了。

Agent平台化这件事，Dify走在了前面。