
一个Agent不仅回答问题,还能决定工作流下一步走哪条路;应用迁到另一个工作区,相关技能和文件也能打包带走。10月23日,Dify发布1.18.0版本,把这些交付环节与嵌套流程追踪一起纳入更新。但对已经运行生产任务的团队,最先需要确认的并非新按钮在哪里,而是API、后台任务和Agent运行组件能否按同一套协议交接。
快速看点:Agent节点新增可选的Output Routes,能从预设出口中选择分支;应用支持以.ifpkg格式携带受支持资源迁移;运行记录可展开子工作流。与此同时,Agent Knowledge Base仍为需要主动启用的Beta集成,不能把版本发布理解为所有功能已经在云端全面开放。
过去,一个普通Agent成功结束后通常只有一个常规出口,若要决定后续动作,还要在流程中另加判断。新路由把选择条件放进Agent节点:启用后至少配置两条路线,为每条写明适用情况,再连接直接处理、转交专员等后续步骤。模型需要从这些已定义的路线中选择,而不是临时创造任意出口。
选中的路线通过只读switch系统输出暴露给工作流。这里的只读是变量属性,不是说整个Agent只能读取业务数据,也不代表下游工具自动获得权限。具体工具能执行什么,仍取决于原有账号与应用配置。把路由结果留在流程里,价值在于能检查“为何走到这里”,而非取消边界。
错误处理也有组合限制。路由打开时可以停止或走失败分支,但不能同时采用节点级默认值错误处理,因为默认值路径不会选择一个出口。普通Agent v2节点开始支持逐步流出文本,结构化结果、路由结果及使用默认值错误处理的节点仍保持缓冲返回;不能笼统写成所有Agent输出都已实时流式化。
新的.ifpkg包支持把Workflow或Chatflow与其受支持的内联Agent、Skills和文件一并导出。导入目标工作区时,系统重建相应资源并调整引用关系;文件或URL导入也继续支持YAML,明确的YAML导出没有取消。这解决的是应用结构及部分资源随包迁移的问题,不是整套生产环境的无条件克隆。
例如,团队把经过验证的客服流程迁到另一工作区后,仍应确认目标环境的模型服务、外部连接和访问条件。包能导入,与任务能在真实业务边界内完成,是两项不同的验收。上述是实施场景说明,不是Dify已经公布的某家客户迁移完成率或节约成本数字。
排查流程时,新版允许从运行历史打开Workflow Tool调用,查看子流程的各个步骤。嵌套工具以子图运行,暂停、恢复、停止和文件输出协调处理,源应用的详情仍受访问检查保护。企业不必只盯父节点的成功或失败,可以进一步寻找实际失败的子步骤。
但可见性并不等于计量已完全精确。发布说明明确保留了嵌套用量和步骤总数可能近似的限制,尤其是在暂停或停止后;控制台下钻与外部追踪导出的覆盖范围也不同。因此,不宜仅凭某个总计数字建立精确账单或断言所有外部监控都已获得同等细节。
此次Agent Backend切换到新的运行协议,旧运行请求不再被接受;会话快照在读取时转换,再按新版格式保存,旧运行时无法读取新保存的快照。API、workers、Agent Backend和运行时镜像需要配套升级。已有任务应先完成交接,不能让缺少新取消保护的旧消费者继续处理同一个共享队列。
人工介入也要区分类型:旧的Agent专用AskHuman工具和延后恢复路径被移除,历史Agent表单不能据此继续执行;共享Workflow Human Input节点仍受支持。企业若依赖暂停后由员工批准再恢复的流程,应先检查自己使用的是哪条路径,不能把“仍有人审节点”当成历史会话都能原样恢复的保证。
可选KnowledgeFS需要独立数据库、迁移和验证配置,默认Compose保持关闭。启动容器不等于开放产品流量,健康检查返回正常也不等于就绪检查通过;缺少验证器或持久依赖时,服务应保持拒绝接流量。Agent Knowledge Base仍标为Beta,经典Knowledge继续可用,云端接入另有发布进度。
升级还要求本地Agent沙箱设置非空认证令牌,并保留既有密码哈希pepper配置。已有部署不能随意换一个新pepper,宣称这只是透明升级。备份数据库、向量数据、上传文件、会话存储和部署配置,再确认组件版本与恢复路径,是交付工作的一部分,而不是上线后的补课。
Dify 1.18.0的价值,不仅是让Agent多一个选择分支的能力,而是把应用搬迁、子流程观察和运行控制连起来。对企业实施团队,可先挑一条包含转交、暂停与失败出口的低风险流程,分别验证路线是否选对、资源引用是否完整、停止后是否仍会被旧任务唤醒,再决定扩大范围。
目前没有可据此引用的统一生产收益基线,也不能把Beta知识库或发布说明中的部署步骤等同于已经验过的所有镜像环境。路线可选、应用可搬、记录可展开,都是能力的起点;迁移后保持权限、状态和恢复语义一致,才是这次升级真正需要交付的结果。
