副标题：Agent从工作流节点升级为可独立维护的“AI同事”：一次构建，连接Skills、Tools与Sandbox，在Web、API和多个流程中持续复用
Dify 正式推出全新的 Agent 体验。最大的变化不是界面翻新，而是产品结构发生了根本转向：Agent 不再只是某个 Workflow 里的执行节点，而是拥有独立配置、完整生命周期和多种访问入口的一等资源。
团队可以为一个 Agent 集中配置模型、指令、Skills、Tools、文件和运行环境，通过真实业务任务不断调试，再将同一份能力发布为 Web App、API，或者嵌入多个 Workflow。这样既减少重复搭建，也让版本、质量、成本和影响范围变得可追踪。
产品入口：查看站内 Dify 官方入口、功能介绍与部署方式。
一、从 Agent 节点到独立 Agent
过去的 Agent 节点让模型能够在 Workflow 和 Chatflow 中自主决策并调用工具，但它依附于具体流程。不同团队想在客服、销售分析和内部运营中复用同一种能力，往往要复制 Prompt、工具和参数，更新时再逐个修改。
新版把 Agent 从流程节点中抽离。每个 Agent 都拥有独立名称、描述、模型、Prompt、Skills、Tools、文件和发布状态，并可在 Agents 页面集中管理。它负责“会什么”，Workflow 则通过 Agent Task 决定“这一次具体做什么”。
二、Build、Manage、Track构成完整生命周期
Dify 把 Agent 生命周期归纳为三部分：
- Build：围绕真实任务构建和迭代能力，通过对话、结构化配置与预览验证逐步完善。
- Manage：集中维护模型、提示词、技能和工具，查看状态、创建者、版本与引用关系。
- Track：追踪单次执行过程、Workflow节点流转和长期质量、速度、成本指标。
这套结构针对的是企业 Agent 上线后的长期问题：谁负责维护、改动会影响哪些业务、故障发生在哪一层、不同版本是否真的更好。
三、Build Mode：像带新人一样通过真实任务构建Agent
Build Mode 允许用户直接描述目标、给出任务并与 Agent 多轮协作。对话过程中生成的配置修改不会立即覆盖线上版本，而是先进入 Build Draft。维护者可以检查差异，再选择 Apply 或 Discard。
在发布前，还可以切换 Preview 验证回答、工具调用与整体交互。这让业务专家不必一开始就理解所有 Prompt、变量和运行参数，也保留了可审查、可回退的配置过程。
四、Agent不再等于一条越来越长的Prompt
把业务规则、参考资料、工具说明和操作步骤全部塞进 Prompt，会导致上下文冗长、职责混杂且难以协作。新版 Dify 把能力拆成可独立维护的模块：
- Prompt：定义角色、目标、行为原则和边界。
- Skill：封装业务方法、操作指南、参考资料与执行脚本。
- Tool：连接稳定运行的API、插件、MCP服务器和工作流。
- Sandbox：提供CLI、文件和代码执行环境，处理当前任务中的动态需求。
这种拆分的好处是：替换工具不必重写角色设定，优化业务规则不必重新开发插件，多个团队也能分别负责不同能力。
五、Tool：连接需要长期稳定运行的正式能力
Tool 适合已经明确接口、需要反复使用和集中治理的生产能力。团队可以从 Dify Marketplace 安装工具，接入自定义 API 或 MCP 服务器，也能把已有 Workflow 封装为 Tool。
工具在工作空间层级管理，可以被多个 Agent 共用。高级设置还可集中保存环境变量和运行参数，默认值变化时无需逐个进入 Agent 修改。对于图表生成、企业搜索、CRM查询和工单操作等能力，这种集中维护尤为重要。
六、Skill：把团队经验变成可版本化资产
Skill 用于保存“应该怎样做”的专业方法。例如增长分析 Skill 可以同时包含指标定义、计算规则、参考资料和脚本，要求 Agent 按同一套方法计算 CTR、CPA 与 ROAS。
与普通 Tool 不同，Skill 中的脚本可随能力包一起维护，不必单独开发成插件。Dify 还推出 Skill Management，让 Skill 成为工作空间共享资源：团队可以统一创建、发布版本、查看引用关系，并让修改同步服务多个 Agent。
自托管用户应注意版本要求和升级说明。Skill Management 已进入 Dify 1.17.0 相关版本，但正式环境升级前仍需备份数据库、核对插件兼容性并进行灰度验证。
七、Sandbox CLI：处理一次性、动态出现的任务
并非每项能力都值得提前开发成插件。对于临时生成演示文稿、日志解析、文件格式转换或数据清理，Agent 可以在当前 Sandbox 中安装并运行 CLI 工具。
如果某套 CLI 安装与调用方式反复出现，可以先沉淀成 Skill；当它需要被多个 Agent 长期稳定调用时，再升级为 API、MCP、插件或共享 Workflow。这个路径让团队可以先低成本验证，再逐步产品化。
安全上应区分不同版本：官方说明企业环境可为会话配置专用沙箱容器、文件系统和网络隔离，而社区版与云端能力范围可能不同。CLI 能执行真实操作，仍需最小权限、出口限制、凭据隔离和人工审批。
八、一次修正，成为下一次运行的起点
Agent 的构建不会在首次发布时结束。真实任务会暴露规则冲突、知识缺口和流程断点，团队需要判断问题究竟应该通过 Prompt、Tool、知识记录还是 Skill 修正。
例如商品比较 Agent 混淆营养字段时，与其继续在 Prompt 尾部增加补丁，不如把商品数据拆为独立知识记录，再把“逐项检索、交叉核验、缺失信息不推断”保存为 Skill。通过回归测试验证后，这项修正便能在后续运行和其他场景中复用。
九、一份配置，可以进入Web、API与多个Workflow
Agent 构建完成后不会固定在单一产品形态。Access Point 会展示它的使用入口，以及有哪些 Workflow 正在调用、对应版本和更新时间，维护者修改配置前可以先评估影响范围。
同一个增长分析 Agent 可以独立接收问题，也可以进入活动分析 Workflow。Workflow 通过 Agent Task 提供当前任务、上游变量和预期结果；声明式输出则让结果按预设结构交给质量检查、条件分支、人工审核或后续系统。
对于某个流程的临时智能能力，仍可从空白 Agent 节点开始。如果后续发现可跨场景复用，再保存到 Agent 库集中管理。
十、从单次追溯到长期运营监测
当一个 Agent 被多个入口复用，仅看最终回答已经无法定位问题。Dify 提供三层观测：
- 单次追溯：还原输入、规划、工具调用与回复，并标明请求来源。
- 节点检查：查看 Workflow 单节点运行信息和变量传递，区分 Agent、条件分支、质量检查或人工审核的问题。
- 长期指标：按时间和来源统计使用量、响应速度、满意度、Token与预估成本，比较不同版本和场景。
Workflow 日志还可按月归档下载，用于运营分析、内部审计和长期问题追溯；该归档能力的可用范围需以当前云服务或企业版本说明为准。
结语：Agent负责判断，Workflow负责边界
全新的 Dify Agent 不是为了取代 Workflow，而是重新划分两者职责。Agent 适合在不确定环境中判断步骤、选择工具和完成动态任务；Workflow 负责触发条件、前后顺序、数据传递、人工介入、质量检查和失败处理。
真正适合企业的 Agent 平台，不仅要“做得出来”，还要能复用、维护、追踪、审计和持续改进。Dify 这次把模型、Agent、Workflow、Skills、Tools、Sandbox、API 与运行观测放进同一套生命周期，向生产级智能体平台迈出了关键一步。
