在 UI 里创建 Agent，配置 base prompt、Skills、文件、工具和知识。 用一个 Agent 去帮助你构建另一个 Agent，它可以配置 Linux 沙箱、安装依赖、生成 Skills 和文件。 把 Agent 发布成新的 Web App 使用。
Agent 如何拥有运行环境。 Agent 如何持有 Skills 和文件。 Agent 如何在沙箱里执行命令和代码。 Agent 如何被复用到工作流和应用里。
Agent 能不能执行不该执行的命令。 Agent 能不能读到不该读到的文件。 Agent 会不会被诱导访问不该访问的地址。 Shell 输出里会不会泄露密钥、路径或内部信息。
docker-compose 新增了 agent_backend 和 local_sandbox 两个服务。 新增了一组 DIFY_AGENT_* 环境变量，覆盖 Redis、内部 API、plugin daemon、shellctl、运行超时和输出脱敏。 官方明确要求生产环境替换 DIFY_AGENT_SERVER_SECRET_KEY。 新增 SHELLCTL_ENABLE_PATH_ISOLATION，并补了 DIFY_AGENT_SHELL_REDACT_PATTERNS。 安全增强里专门提到 Agent HOME 目录的 Landlock 保护，以及 sandbox enforcement 修复。
输入什么。 调哪些节点。 每一步产出什么结构化变量。 下一步怎么继续处理。
把一个目标交给它。 让它自己决定调用哪些 Skills、工具、文件和知识。 等它完成后再把结果传回流程。
确定性更强的节点编排。 自主性更强的 Agent 执行。
多步资料整理。 临时文件处理。 带上下文的工具链调用。 半结构化任务执行。
这个任务到底该用普通节点还是 Agent 节点。 Agent 节点的成本、耗时和结果可预测性是否可接受。 出错后是重试 Agent，还是回退到确定性节点。 Agent 生成的中间文件、Skills 和依赖如何治理。
版本不一致时怎么协商。 工具输出是随便返回文本，还是有结构化约束。 上游请求身份信息怎么安全地下传给 MCPClient。
MCP 接入可以更自然地对接企业已有网关、代理和按请求鉴权体系。 工具调用终于不一定只能依赖一个平台级静态密钥。
去掉了价值不高的 Ideal output 字段。 以前静态示例提示，改成了基于工作区上下文生成的建议。 节点配置生成开始并行化。 新增 WORKFLOW_GENERATION_TIMEOUT_MS，默认 180 秒。
生成结果是不是足够贴合现有工作区。 节点配置是不是能一次生成到可改、可跑的程度。 超时以后是卡死，还是能明确结束。 大一点的工作流生成时，速度还能不能接受。
服务拓扑。 env 文件拆分。 端口与内部服务访问关系。 运行超时和关闭策略。
新增 28 个环境变量。 删除 1 个环境变量。 修改 1 个环境变量。
Agent backend 和 sandbox。 Redis keepalive 与重连。 Workflow generation 超时和并行度。 新用户默认模型和默认插件。
先 diff 新旧 docker-compose 和 env 文件，不要直接覆盖升级。 检查 OpenAI provider 里历史配置的 API type，确认是否还停留在 Chat Completions。 把 Agent 能力的可用范围限制在可信用户和有限 workspace 内，不要一上来就全员开放。 审核 DIFY_AGENT_SERVER_SECRET_KEY、DIFY_AGENT_SHELL_REDACT_PATTERNS、路径隔离和内部服务访问边界。 为 Agent 节点设定明确使用场景，不要把所有任务都丢给 Agent 执行。 如果要透传动态请求头到 MCPClient，先做白名单和日志审计设计。 在测试环境完整跑一遍数据库迁移和回归验证，尤其核对你当前版本基线对应的实际迁移范围。
不要把内置 Linux 沙箱理解成“天然安全”，沙箱只是起点，不是生产安全结论。 不要把 Agent 节点理解成“比普通节点更高级”，很多确定性流程仍然更适合传统工作流。 不要把动态请求头注入理解成“所有身份信息都可以透传”，要做白名单和最小暴露。 不要把升级说明里的迁移数字当成唯一事实，必须结合自己的版本基线核对。 不要忽略历史 OpenAI 配置的 API type，尤其是准备接 GPT-5.6 及后续模型时。
Data for AI：数据如何支撑 AI。 AI for Data：AI 如何反过来改造数据治理。
