智能体编排框架横评（6）：低代码与可视化平台
本文总结Dify、Coze Studio、n8n 入门：怎么部署、怎么在画布上搭出第一个应用，节点各是什么；再用节点链搭出建单前要员工确认的报销流程，最后说明它们和代码框架的分界。
这一站讲什么
前五站都是代码框架，写在 Python 或 TypeScript 里，跟着 Git 走。这一站看三个以画布为主的平台：
| 平台 | 出品方 | 特点 |
|---|---|---|
| Dify | LangGenius | LLM 应用平台，画布、知识库、插件市场、发布成 Web 应用或 API |
| Coze（扣子）/ Coze Studio | 字节跳动 | 商业版在线使用，Coze Studio 是开源的自部署版本 |
| n8n | n8n GmbH | 通用工作流自动化平台，AI 是其中一类节点 |
它们的共同做法是：把固定的流程画成节点图，节点之间用连线传数据；需要模型自己决定调哪些工具的部分，收进一个 Agent 节点。
报销场景沿用 主线：一个报销请求走完整个 Agent 系统：员工问"上周打车超标还能报吗，能就帮我提单"。三个工具是 search_policy 查制度，get_invoice 查发票（INV-102 金额 118.5，标准 80），create_ticket 建单（有副作用）。建单前必须员工确认。低代码平台不写代码，例子用文字描述节点怎么连。
Dify
Dify 是什么
Dify 是一个自带运行时的 LLM 应用平台。画布编排、知识库、插件、日志、发布都在一套服务里，执行、存储、权限也由平台负责。
它假定大部分业务流程的形状能事先写出来，用确定的节点链表达，模型只在少数节点里做判断或生成。固定编排与目标闸门：Workflow 运行时和 Goal Loop 用的是同一个标准：流程形状能事先写出来，就用固定编排。
部署
Dify 有在线版（cloud.dify.ai），也可以用 Docker 自己部署：
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d
启动后浏览器打开 http://localhost/install，创建管理员账号。然后在"设置 → 模型供应商"里安装一个模型插件并填入 API Key。
第一个应用
- 在"工作室"里点"创建空白应用"，类型选 Chatflow；
- 画布上默认有"开始""LLM""直接回复"三个节点，点 LLM 节点，选好模型，在系统提示里写"你是公司的报销助手，回答要简短"；
- 点右上角"预览"，输入"报销一般需要哪些材料？"，就能看到回答，以及每个节点的输入、输出和耗时；
- 点"发布"，应用就可以作为 Web 页面或 API 使用。
基本概念
应用类型。 两种最常用的应用共用同一块画布：
| 类型 | 怎么运行 | 结尾 |
|---|---|---|
| Workflow | 从头跑到尾一次，起点是 User Input 或触发器 | 输出结果 |
| Chatflow | 多轮对话，每轮跑一次流程 | 必须有 Answer（直接回复）节点 |
节点。 常用的有这些：
| 节点 | 作用 |
|---|---|
| LLM | 调用模型生成文本 |
| Knowledge Retrieval | 在知识库里检索 |
| If-Else | 按条件分支 |
| Code | 运行一段 Python 或 JavaScript |
| HTTP Request | 调用外部接口 |
| Tool | 调用插件提供的工具 |
| Agent | 让模型自己决定调哪些工具，可设最大轮数 |
| Human Input | 暂停流程，向人发一个表单，按人点的按钮决定走哪条分支 |
| Parameter Extractor | 从文本里抽取结构化参数 |
| Iteration、Loop | 遍历列表、循环 |
变量。 每个节点的输出都是变量，后面的节点可以引用，比如在 LLM 的提示词里插入"查发票"节点返回的金额。
插件。 模型、工具、数据源、触发器都以插件形式安装，来源是插件市场、GitHub 或本地文件。
DSL。 应用可以导出成 YAML 格式的 DSL 文件，在另一个 Dify 里导入。
报销例子：一条固定的节点链
用 Chatflow 搭一条固定链，模型只负责解释，金额比较和建单都不交给模型：
- User Input：接收员工的问题和发票号。
- Knowledge Retrieval：在《差旅费管理办法》知识库里检索打车标准，相当于
search_policy。 - Tool 或 HTTP Request：调用
get_invoice，取回 INV-102 的金额 118.5。 - Code 或 If-Else：用确定的逻辑比较 118.5 和标准 80，算出超出 38.5，决定走可报、需特批、不可报中的哪条分支。
- LLM：把条款和比较结果组织成给员工看的说明。
- Human Input：投递方式选 Web app，表单里放金额、条款、超标原因；配置"确认提单"和"取消"两个按钮；超时分支接一条回复，提醒员工稍后再办。
- HTTP Request：只在确认分支上调用
create_ticket，请求里带一个用本次运行 ID 拼出的幂等键；错误处理设为失败分支，失败时走单独的说明。 - Answer：返回单号（例如 R-55821，示意）。
下面这张图就是这条链，点开节点可以看每一步做什么：
- 员工的问题进来，先检索制度，再用 HTTP 节点查发票
- 金额比较交给 If-Else，不交给模型
- LLM 节点只负责把条款和比较结果写成说明
- Human Input 暂停工作流，给员工发表单
- 只有确认分支会调用建单接口
- Answer 节点返回单号
If-Else的细节：
- 拿到发票金额和制度标准，用确定逻辑比较
- 118.5 超过 80，走需特批这条分支
- 另外两条分支各自接自己的回复
Human Input的细节：
- 投递方式选 Web app，表单里放金额、条款和超标原因
- 工作流停在这个节点，等员工点按钮
- 点确认提单，走建单分支
- 点取消就不建单；超时走另一条分支，提醒稍后再办
HTTP 建单的细节：
- 请求里带上由本次运行 ID 拼出的幂等键
- 只有确认分支会走到这里调用建单接口
- 成功就拿到单号，交给 Answer
- 错误处理设成 Fail Branch，失败时走单独的说明分支
为什么不把三个工具都挂到 Agent 节点上，让模型自己调？因为 Dify 的 Agent 节点不能在循环中途停下来问人。文档写明，包含 Human Input 节点的工作流被当成工具时，只能作为独立的 Tool 节点用，Agent 节点调用不了它。所以建单前的确认只能放在固定链上。Agent 节点可以负责前面的解释。
常见问题
能不能用 Dify 源码做一个对外的多租户服务？ 不能直接做。Dify 用的是"修改版 Apache 2.0"许可证：未经书面授权，不得用源码运营多租户环境；使用其前端时，不得移除或修改 LOGO 和版权信息。选型前对照自己的部署形态读 LICENSE 原文。
导出的 DSL 在另一台机器上导入后跑不起来。 导出物不带凭据、插件依赖、关联的知识库、MCP 工具和触发器订阅，要在目标环境重新配齐。
导出时勾选了 Secret 变量。 那 Secret 会以明文写进导出包，分享前检查。
Email 投递的确认链接被转发了。 拿到链接的人都能回应，请求在第一个回应后关闭。必须本人确认时，用 Web app 投递，或者另外验证身份。
升级后服务起不来。 新版本的执行引擎依赖 Celery 和 Redis，部署组件变多了，升级时 API、worker 等镜像要一起换。每次升级前备份 docker/volumes 和 .env，对比 .env.example，逐版读升级指南。
能不能把新版 Agent 应用的沙箱当成用户之间的隔离？ 不能，文档写明它不打算在互不信任的用户之间提供加固的隔离。
Coze 与 Coze Studio
Coze 是什么
Coze（扣子）是字节跳动的智能体开发平台。商业版在线使用（coze.cn），不用部署。2025 年 7 月，字节把核心引擎开源为两个项目，都是 Apache 2.0 许可证：
- Coze Studio：开发平台，搭智能体、应用和工作流；
- Coze Loop：提示词开发、评测和调用链观测。
Coze Studio 的思路和 Dify 接近，后端用 Go 写，运行时基于字节开源的 Eino 框架。部分能力只在商业版有。
部署
git clone https://github.com/coze-dev/coze-studio.git
cd coze-studio/docker
cp .env.example .env
然后按 README 用 docker compose 启动。启动后先按 README 配置模型，再登录开发界面。用商业版的话，直接在 coze.cn 注册即可。
第一个智能体
- 在工作空间里创建一个智能体，写好人设与回复逻辑（相当于系统提示），选择模型；
- 在右侧调试区输入问题，查看回答；
- 需要固定流程时，创建一个工作流，在画布上从"开始"连到"大模型"再连到"结束"，试运行，然后把工作流添加到智能体里。
基本概念
智能体。 配置模型、提示词、插件、知识库、工作流，可以发布到不同渠道。
工作流和对话流。 画布编排的业务逻辑，对话流多一层多轮对话。常用节点有大模型、插件、代码、知识库检索与写入、数据库、选择器（分支）、循环、批处理、子工作流、意图识别。
问答节点。 在流程中途向用户提问。有两种方式：给出预置选项让用户选，或者让用户自由回答，再由模型从回答里抽取字段。
输入节点。 在流程中途接收用户输入。
插件。 每个插件包含多个工具，每个工具对应一个 API。
报销例子：对话流加问答节点
- 开始：接收员工问题。
- 知识库检索：查打车标准（
search_policy）。 - 插件：调用
get_invoice取 INV-102。 - 代码：比较 118.5 和 80，输出是否超标和超出金额。
- 大模型：生成说明。
- 问答节点：用选项回答，选项是"确认提单"和"取消"，没匹配任何选项时走单独的分支。
- 选择器：按问答结果分支，只有确认分支调用
create_ticket插件。 - 结束：返回单号。
问答节点提问时，整条工作流会挂起，状态存进检查点；用户下一轮回复时，回复交回这个节点，流程从中断处继续。
常见问题
带问答节点的工作流不能发布为 MCP 工具。 扣子商业版文档写明，含问答节点、输入节点的工作流和对话流暂不支持发布为 MCP 工具。一定要通过 MCP 给别的智能体调用时，拆成两个工作流：A 只查询和计算，返回一段待确认摘要和它的编号；B 只建单，入参必须带这个编号，B 校验编号存在且没用过才建单。这时员工确认由调用方负责，调用方不可信，确认就没有意义。
问答节点等太久失败了。 商业版的问答节点等待 24 小时，超时节点运行失败。
某些渠道里问答节点不显示选项。 豆包渠道暂不支持问答节点；Chat SDK 不支持问答卡片，用户要手动复制选项。
开源版里 MCP 不能用。 开源版源码里 MCP 调用是占位实现，商业版文档里的功能不能默认在 Studio 里可用。
部署到公网要注意什么？ README 提醒公网部署前评估风险：账号注册、代码节点的 Python 执行环境、服务监听地址、SSRF 和部分接口的越权。
开源版很久没发版。 v0.5.1（2026-02）之后没有新 release，选开源版要准备自己维护补丁。
n8n
n8n 是什么
n8n 首先是一个通用的工作流自动化平台：触发器加上千个集成节点（Slack、邮件、数据库、各种 SaaS），AI 是后来加进来的一类节点。
它和 Dify、Coze 的出发点不同：Dify 和 Coze 先有智能体，再补流程；n8n 先有流程和集成，再在流程里放智能体。所以 n8n 的审批、Webhook、表单、定时这些流程能力很成熟。它的 AI 节点基于 LangChain 的 JavaScript 版。
部署
用 Docker 启动：
docker volume create n8n_data
docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n
浏览器打开 http://localhost:5678，创建账号。也可以用 n8n 的在线版。
第一个 AI 工作流
- 新建工作流，添加触发器 Chat Trigger（聊天消息触发）；
- 后面接一个 AI Agent 节点；
- 在 AI Agent 节点下方的 Chat Model 插槽里接一个模型节点（比如 OpenAI Chat Model），新建凭据填入 API Key；
- 工具插槽里至少接一个工具，比如 Calculator；
- 点画布下方的 Open chat，输入"118.5 减 80 是多少"，可以看到 Agent 调用了计算器并给出回答。
基本概念
触发器。 工作流从哪里开始：Webhook、定时（Schedule）、聊天（Chat Trigger）、表单（Form Trigger），以及各应用的事件。
根节点和子节点。 AI 相关的节点分两层。Agent、Chain、Vector Store 是根节点；模型、记忆、工具、输出解析器是挂在根节点下方的子节点。
AI Agent 节点。 让模型在挂上的工具之间自己选择调用，至少要连一个工具。
Wait 节点。 暂停执行，把执行数据存进数据库，按时间、Webhook 调用或表单提交恢复。
Human review。 给 AI Agent 的某个工具加人工审批，模型调用这个工具前先等人批准。
凭据。 API Key 等加密存储，工作流引用凭据，不写明文。
报销例子：两种写法
固定链写法（推荐，确认点在流程上）：
- Chat Trigger 接收问题；
- 两个 HTTP Request 依次调
search_policy和get_invoice； - If 节点比较 118.5 和 80；
- 一个 Chain 节点生成说明；
- 用 Slack 的 Send and Wait for Response（审批人限定为员工本人），或者 Wait 节点的表单提交，等员工确认；
- If 节点按是否批准分支，HTTP Request 调
create_ticket（带幂等键），最后回复单号。
Agent 写法（确认点挂在工具上）：
- Chat Trigger 后面接一个 AI Agent，挂上模型和记忆；
search_policy、get_invoice作为普通工具挂上；create_ticket挂在 Human review 下面，审批渠道选 Chat，审批消息里用$tool.name和$tool.parameters展示模型打算传的参数；- 员工点批准，工具按模型给的参数执行；点拒绝，工具不执行，模型收到拒绝信息。
官方文档建议在系统提示里写明哪些工具需要审批、被拒后怎么回应。
两种写法的差别：固定链里，员工确认前看到的数字来自确定的节点；Agent 写法里，员工看到的是模型准备传给 create_ticket 的参数，金额算得对不对要靠人看出来。
常见问题
能不能拿 n8n 做对外收费的托管服务？ 许可证是 Sustainable Use License，只允许用于自身内部业务、非商业或个人用途。商业托管前读 LICENSE 原文。
审批链接谁都能点。 默认的链接按钮模式下，n8n 分辨不出是谁点的。要限定审批人，用 Slack 内审批并在凭据里填 signing secret，实例还要能被 Slack 通过公网 HTTPS 回调。
大版本升级后有的工作流不运行了。 大版本会移除旧节点，用到已移除节点的工作流会失败。升级前用 Settings 里的 Migration Report 检查，先在测试环境试。
导出的工作流包没有凭据。 导出从不包含凭据数据，目标实例要自己补齐。
多副本部署时 MCP 连接频繁断开。 多个 webhook 副本时，/mcp* 请求必须路由到同一个副本。
版本控制和多环境在哪里？ Git 同步、多环境、external secrets 都是付费功能；社区版的工作流历史只保留 24 小时内的版本。
Flowise 与 Langflow
这两个也是画布式的 Agent 搭建工具，这里只讲定位。
- Flowise：Node.js 实现，有 Chatflow 和 Agentflow 两种画布。主体是 Apache 2.0 许可证，企业功能目录用商业许可证。2025 年被 Workday 收购。
- Langflow：Python 实现，MIT 许可证，每个组件都能直接改 Python 源码，流程可以作为 API 部署、导出为 JSON，也能作为 MCP 服务器暴露。维护方 DataStax 已被 IBM 收购。
相比之下，Dify、Coze 是带运行时的应用平台，Flowise 和 Langflow 更偏可视化的 Agent 和 RAG 搭建器，常用来做原型或嵌进别的应用。
低代码平台和代码框架的分界
三家共同的骨架是：画布上的节点图，加上可导出的定义文件（Dify 的 YAML、n8n 的工作流 JSON、Coze 的工作流定义），平台负责执行、凭据、日志和发布。
适合的场景：流程形状稳定；参与者里有业务人员；需要快速接入大量现成系统；需要把一个 Agent 快速发布成 Web 应用或 API。
按工程实践逐项对比：
| 方面 | 低代码平台 | 代码框架 |
|---|---|---|
| 版本控制 | 平台内的版本历史；Git 同步多为付费功能；导出文件的 diff 不好读 | Git 原生，分支、合并、回滚都是常规操作 |
| 测试 | 多为手动试运行；n8n 有 Evaluations，Coze 有 Loop 评测；接进 CI 要自己搭，见 Agent 评测：从测试集到发布门槛 | 单元测试、录制回放、评测脚本直接进 CI |
| 代码审查 | 主要靠人看画布 | Pull Request 审查，改动范围清楚 |
| 复杂状态与错误处理 | 节点级的失败分支和默认值；事务、补偿、精细重试要拼节点或写 Code 节点，见 可靠执行：状态、幂等与恢复 | 可以写任意的状态机、补偿逻辑和检查点，如 智能体编排框架横评（2）：LangGraph |
| 迁移 | 定义文件只能在同一平台导入，跨版本也有限制 | 依赖库可以替换，但同样有接口迁移成本 |
一个实用的判断：流程里要写的 Code 节点越来越多，或者需要对画布做代码审查和回归测试时，就该考虑把这部分迁到代码框架，平台只保留触发、审批和集成。
版本说明
本文按 2026-11 初的文档写，查阅时的版本：Dify 1.19，Coze Studio v0.5.1，n8n 稳定版 2.46（3.0 在早期访问）。对照旧资料时注意：
- Dify 的 Human Input 节点从 1.13.0（2026-02）开始有；1.18.0 移除了旧的 Agent 专用提问工具，默认导出格式改成
.ifpkg应用包；1.19.0 导出的包只能导入 1.19.0 及以上版本。 - n8n 的 AI Agent 节点在 1.82.0 后只保留工具调用模式，3.0 移除了旧版节点和 ReAct 等旧模式，并且只支持 Docker 部署。
- Coze Studio 和 Coze Loop 于 2025-07 开源。
和手写循环的对照
跟读 learn-claude-code：17 个 harness 机制怎么挂到一个循环上 里手写的 harness 有几块：循环本身、工具调用与结果配对、权限、上下文压缩、检查点。固定编排与目标闸门：Workflow 运行时和 Goal Loop 又加了一层固定编排：模型只选工作流名和参数，运行时记日志、按内容哈希回放、节点输出过 schema 校验。
低代码平台把这两层都做成了产品：画布对应固定编排，Agent 节点对应循环。
| 手写 harness 的部件 | 平台替你做了什么 | 要你自己做的 |
|---|---|---|
| 循环（见 跟读 learn-claude-code（1）：循环内核） | Agent 节点内部跑工具调用循环，设最大轮数 | 循环中途停下来问人：Dify 的 Agent 节点不支持，n8n 只能在工具上审批 |
| 调用与结果配对 | 平台内部完成，用户看不到消息结构 | 想检查或改写中间消息时没有入口 |
| 权限 | 凭据托管、插件安装权限、n8n 的工具级审批 | 按用户身份限制工具调用，平台的角色模型不一定覆盖 |
| 上下文压缩（见 计划、子代理与上下文预算） | 记忆子节点或窗口记忆 | 精细的预算和摘要策略基本不可控 |
| 检查点与恢复（见 任务图、后台与定时：让工作撑过一轮对话） | Dify 经 Celery 恢复，n8n 把等待中的执行存进数据库，Coze 用 Eino 检查点 | 外部副作用的幂等，建单要自己带幂等键 |
| 日志与回放 | 执行记录、节点输入输出、外部追踪集成（见 可观测性：追踪一条任务的代价） | 按内容哈希跳过已完成节点的回放，三家都没有公开的对应机制 |
| 节点输出校验 | Dify 的 Parameter Extractor、n8n 的输出解析器 | 校验失败后的重试要自己连线 |
省下的主要是基础设施：队列、存储、凭据、表单与审批页面、集成适配、发布。省不下的是工程判断：哪一步必须确定、哪一步交给模型、副作用怎么幂等、确认点放在哪、怎么做回归。这些在画布上同样要想清楚，只是换成了连线。
自测
Dify 的 Workflow 和 Chatflow 有什么区别？
参考：Workflow 从头跑到尾一次，起点是用户输入或触发器；Chatflow 是多轮对话，每轮跑一次流程，必须有 Answer 节点回复用户。
n8n 的 AI Agent 节点下面挂的模型、记忆、工具叫什么？
参考：子节点。Agent、Chain 这类是根节点，模型、记忆、工具、输出解析器挂在根节点下方的插槽里。
在 Dify 里，为什么报销例子的建单前确认要放在固定节点链上，而不是让 Agent 节点在工具循环里自己询问员工？
参考：Dify 的 Agent 节点不能在循环中途停下来问人，含 Human Input 节点的工作流作为工具时，Agent 节点调用不了。所以确认只能放在固定链上。好处是确认点在画布上位置固定、可审计，金额比较由确定的节点完成，员工看到的数字不依赖模型。
n8n 的两种建单确认方式，工具级 Human review 和固定链上的 Wait 节点，分别适合什么情况？
参考：Human review 适合由 Agent 编排、工具多、只想拦截有副作用工具的情况，审批人看到的是模型准备传的参数。固定链适合流程形状稳定、确认前的数字必须来自确定计算的情况。报销金额敏感，固定链更稳；用 Agent 写法时，审批消息要展示完整参数，系统提示要写明被拒后怎么处理。
扣子不允许把含问答节点的工作流发布为 MCP 工具。如果一定要让外部 Agent 通过 MCP 调用报销流程，怎么保证员工确认后才建单？
参考：拆成两个工作流。A 只查询和计算，返回待确认摘要及其编号；B 只建单，入参必须带摘要编号，校验编号存在且没用过后再建单，并带幂等键。确认这一步移到了调用方，所以调用方要可信。
团队打算用平台导出的文件来做版本管理和环境迁移，要提前知道哪些限制？
参考：Dify 的导出不带凭据、插件依赖、知识库、MCP 工具和触发器订阅，Secret 选择导出时是明文，新版本导出的包不能导入旧版本；n8n 的导出不带凭据，社区版工作流历史只保留 24 小时，Git 同步是付费功能。导出文件可以作为备份，但代替不了代码仓库里的版本控制。
参考资料
以下链接均查阅于 2026-11。
- Dify LICENSE
- Dify Releases
- Dify 文档：Workflow 与 Chatflow
- Dify 文档：Human Input 节点
- Dify 文档：Agent 节点
- Dify 文档：工具与 MCP
- Dify 文档：应用导出与导入
- Dify 文档：升级与常见迁移问题
- Coze Studio 仓库与 README
- Coze Loop 仓库
- 扣子文档：问答节点
- 扣子文档：发布为 MCP 工具
- n8n LICENSE
- n8n 文档：LangChain in n8n
- n8n 文档：Human-in-the-loop for tools
- n8n 文档：Wait 节点
- n8n 文档：Slack approvals
- n8n 文档：Update n8n
- n8n 文档：MCP Server Trigger
- n8n 文档：v3.0 Breaking changes
- Flowise 仓库
- Langflow 仓库
连接
- 智能体编排框架横评：同一个报销 Agent 换六种写法：系列总览，本站是最后一站。
- 智能体编排框架横评（5）：轻量与类型化框架：上一站，代码优先的轻量框架，和本站的画布优先形成对照。
- 智能体编排框架横评（2）：LangGraph：用代码表达的图和检查点，对照画布和平台托管的恢复。
- 固定编排与目标闸门：Workflow 运行时和 Goal Loop：固定编排的判断标准，画布就是它的产品化形态。
- 跟读 learn-claude-code（1）：循环内核：Agent 节点内部跑的就是这个循环。
- 人在回路：三家建单前确认的实现方式各不相同。
- 可靠执行：状态、幂等与恢复：暂停恢复和幂等，平台只做了前一半。
- 工具调用：n8n 的工具级审批对应工具权限的划分。
- 可观测性：追踪一条任务的代价：平台内执行记录和外部追踪集成。
- 技能、MCP 与集成：MCP 客户端与服务端在三家的支持情况，Dify 作为客户端只支持 HTTP 传输的 MCP 服务器，n8n 有 MCP 客户端节点和 MCP Server Trigger。
- 主线：一个报销请求走完整个 Agent 系统：报销场景的来源。