企业做Agent最容易的部分，是让一个演示跑起来；最难的部分，是半年后还能知道谁在维护、哪些流程正在调用、一次修改会影响谁。Dify在8月27日发布New Agent，把Agent从工作流里的临时节点拆成独立应用和可复用资源：模型、Prompt、Skills、文件与工具在一处维护，再进入Web应用、API或多个业务流程。

从一次性节点，变成可以交接的能力资产

过去的Agent节点跟着所在Workflow存在。团队想在另一个应用复用它，往往要重新复制Prompt、Tools和参数，随后每个副本各自漂移。New Agent改成单一配置源：名称、说明、模型、Prompt、Skills、Files、Tools和发布状态集中在Agent页面管理，并显示创建者、更新时间与Access Points。

它可以发布为独立Web应用，也能暴露为API，或被多个Workflow引用。进入具体流程后，Workflow只需要用Agent Task声明这一节点要完成什么、可读取哪些上游变量、向下游交付什么结果，而不必重新搭建整套能力。共享配置被更新前，维护者也能先看到哪些入口和流程会受影响。

构建方式同时分成手工配置与Build Mode。后者让业务专家通过真实任务和Agent一起试做，模型提出的变更先进入Build Draft，用户可以保留或放弃；系统还用build_note.md记录配置变化和未完成事项。它把“会不会写Prompt”改造成一段可审查的配置迭代过程。

Tool、Skill与临时CLI，分别承担不同承诺

Dify把能力扩展拆成三层。Tool用于长期受管的外部连接，包括插件、API、MCP和Workflow as Tool；Skill把操作说明、背景材料和执行脚本打包，保存团队反复使用的方法；CLI工具则只在当前隔离沙箱处理临时任务，适合解析日志、转换文件或快速试验。

这种分层解决的是交付承诺：一次性的探索不必立刻进入共享工具目录，重复出现的方法可以沉淀为Skill，需要跨团队稳定调用时再升级为受管API、插件或工作流。Prompt因此不再同时承担业务规则、资料、脚本和连接配置，维护人员也更容易判断某个修复应该落在哪一层。

不过，Dify明确把工作区级Skill Management列为后续方向，不能把它当成已经完成的统一版本库。当前团队仍要自行规定Skill评审、兼容性和回滚流程。

复用扩大影响面，Workflow仍负责兜底

Agent擅长根据现场情况决定“怎么做”，Workflow负责“何时做、前后接什么、哪里要人批准、失败后走哪条路”。Dify没有用更自由的Agent替代确定性编排，而是把两者组合：Agent处理判断和工具调用，Workflow继续承接数据加工、规则分支、人工输入和异常路径。

观测也分三层。单次运行可查看日志和Tracing；Workflow中的Last Run与Variable Inspect帮助定位节点输入输出；长期面板跟踪用量、质量、性能和成本。历史日志还能按月归档下载，但这一能力不属于Community Edition。对自托管和企业环境，版本与授权差异需要在上线前逐项确认。

安全边界同样不能只靠产品口号。Dify称企业版每个会话运行在独立沙箱容器中，并支持进程、文件系统、网络策略和非root运行；1.16系列代码还加强了代理后端认证和网络代理。但公开材料没有任务完成率、故障率、延迟或成本基线，尚不能据此判断真实生产可靠性。

编辑判断：关键变化是维护边界，不是又多一个Agent

New Agent最有价值的地方，不是聊天式构建有多炫，而是把Agent重新定义为有所有者、有版本、有调用关系的交付单元。FDE可以先围绕一个真实任务共创能力，再把成熟部分复用到更多入口；当模型或工具变化时，团队更新中心资产，而不是追着一堆副本修补。

代价也随之上升：一次错误配置可能同时影响多个Workflow，集中复用会把变更管理、访问控制、回归评测和回滚从“最好有”变成必需。下一步值得观察的，不是创建了多少Agent，而是Dify能否给出共享变更的灰度、兼容性与生产指标，以及企业能否把每次修复沉淀为可审计、可复用的方法。