编排画布的适用边界
拖拽式编排画布是 AI 应用里最容易高估的东西。演示效果非常好——拖几个节点连起来，一条 RAG 流水线跑通了，看起来整个 AI 工程都被"可视化"了。
问题是：画布能表达数据流向，表达不了状态。当一个流程开始需要重试、回滚、并发、长事务、可恢复执行时，画布就不是变难了，而是它根本不提供这套语义。
1. 先分清你要做的是哪一类
这是最常见的误选，而这几类之间几乎不能互换：
| 你的需求 | 该看什么 | 为什么 |
|---|---|---|
| 做 LLM 应用本身（RAG、对话 Agent，发布成 API 或 web app） | 画布类 LLM 平台 | 节点就是模型/检索/工具，语义匹配 |
| 把已有系统串起来，其中一步调模型 | 通用工作流自动化 | 它有几千个现成集成，画布平台没有 |
| 需要状态机、断点续行、长事务 | 代码框架（LangGraph 这类） | 画布没有"可恢复执行"这个语义 |
| 要白牌转售或多租户 SaaS | 先看许可，再谈功能 | 见第 5 节 |
用通用自动化工具去搭 RAG 平台，等于拿扳手拧螺丝；反过来，用 LLM 画布平台去串公司内部的十几个 SaaS，你会发现它根本没有那些连接器。
2. 画布真正解决的三件事
说它有用，是因为这三件事确实做得比代码好。
2.1 让非工程角色看得见流程
一个产品经理能在画布上看出"这个问答先检索再生成、检索失败就转人工"。看代码他看不出来。
这不是"降低技术门槛"这种空话，是评审成本的真实下降：流程是否漏了一步、是否该加个分支，在图上比在代码里容易发现得多。
2.2 缩短实验回路
搭一条完整的 RAG 链路（解析、切分、embedding、入库、检索、生成），手写代码要一两小时；在画布上十几分钟。
这个差距在需要反复试检索策略时最有价值——比较递归切分和语义切分、换向量库、调 top-k，都是改一个节点的配置然后立刻跑。见《切片决定检索上限》里那些需要实测的参数，画布让这种实测变得便宜。
2.3 中间态可视化调试
画布会在节点连接处渲染中间输出：提示词模板拼出来是什么、检索器召回了什么、Agent 某一步产出了什么。
这个能力在纯代码里要靠逐步加日志来近似，成本高得多。它是画布最不可替代的一点——所以即使你最终用代码跑生产，用画布做原型调试也是划算的。
3. 画布解决不了的三件事
3.1 重试与回滚
真实流程里"这一步失败了怎么办"不是一条分支线能表达的：重试几次、退避多久、哪些错误可重试、失败后前面的副作用要不要撤销。
《限流的三个维度》里那些细节——抖动、幂等区分、预扣与冲正——在画布上要么没有位置放，要么变成一个"配置面板"，而那个面板本质上是在写一个小语言。
3.2 并发与长事务
画布表达的是顺序流。分支合并、并行执行、等待多个结果、超时取消其中一路——这些在可视化上会迅速变得比代码更难读。
一个判断标准：如果你的流程需要"等待"而不只是"执行"，画布就不合适了。
3.3 版本与评审
画布配置通常是 JSON。它的 diff 读不懂，code review 无从下手，合并冲突几乎无法手工解决。
这一点在团队变大之后会变成硬伤：五个工程师同时改一张画布，比同时改五个文件痛苦得多。
所以一个务实的做法是画布产出配置、配置转成代码进仓库（第 6 节）。
4. 自研画布的技术底座
如果决定自己做，底层库基本没有第二个选择：React Flow（现在叫 XYFlow），MIT 许可，是目前这一类画布的事实标准。几个主流平台都构建在它上面。
架构上的四个要点：
4.1 节点即组件，边即数据契约
每个节点是一个组件，声明自己的输入 schema、输出 schema、配置项。边不是"画一条线"，而是类型化的连接——输出 A 能不能接到输入 B，要在连接时校验。
不做这层校验，画布会在运行期才报错，而用户看到的是"某个节点红了一下"。
4.2 执行引擎与画布分离
这是最重要的一条。画布是编辑器，执行引擎是另一套东西。
原因是执行引擎要能被独立调用（定时任务、API 触发、CLI 跑批），不能被"是否打开了画布"绑定。同时它也意味着画布配置是一种数据格式，可以被序列化、版本化、转成别的东西。
4.3 运行态要能回显到节点
执行时每个节点要显示自己的状态：等待、运行中、耗时、输出、错误。
没有这个，画布就只是一个静态图，用户看不到"现在跑到哪了、卡在哪一步"。这一层也是调试价值的主要来源——见《给大模型链路装仪表》，trace 的 span 要能映射回节点。
4.4 布局要持久化且可版本化
节点坐标要存，但坐标不该是配置的语义部分。把坐标和逻辑混在一个 JSON 里，会让 diff 完全不可用。
flow.graph.json // 逻辑：节点、边、配置（可 diff、可 review）
flow.layout.json // 坐标：只影响渲染
5. 选型时先看许可
这一条经常被跳过，然后上线前法务过不去。
| 项目 | 许可 | 能不能做商业产品 |
|---|---|---|
| Langflow | MIT | 可以，白牌、转售、多租户都没问题 |
| Dify | Apache-2.0 加两条附加条件 | 不行：禁止未授权的多租户；前端版权信息不得移除 |
| n8n | Sustainable Use License（官方自陈非开源） | 不行：白牌转售、架站收费都明确不允许，需谈 OEM |
| Flowise | Apache-2.0，但2026 年 8 月已归档只读（7 月底冻结进最后一个 release） | 不适合任何新项目；它 2025 年 8 月已被 Workday 收购，归档是收购后的产品收编 |
几条补充：
Dify 的两条附加条件要注意，它是 Apache-2.0 但不是纯 Apache-2.0。想拿它当产品基底卖人，会卡在"禁止未授权多租户"这一条上。
n8n 的 fair-code 不是开源。它自托管做内部自动化没问题，但任何形式的对外转售都要另外谈。
Flowise 已经归档了。代码冻结只读，意味着没有安全补丁、没有依赖更新、没有社区支持。2026 年中之后选它就是给自己埋雷，存量部署应尽快规划迁移。这也提醒了一件事：星数不代表活跃度，选型时看最后一次提交和 issue 响应速度。
Langflow 的 MIT 是它最硬的卖点，但要注意它的归属几经变更（Logspace → DataStax 2024-04，IBM 2025-02 宣布收购 DataStax），路线图决策权不在原团队手里。另外 DataStax 的托管服务于 2026-03-09 弃用、2026-04-09 关停，自托管现在是默认路径——意味着 DevOps 成本要算进总账。
6. 一个折中方案：画布配置 + 代码执行
如果要兼顾"让非工程角色看见"和"让工程侧可控"，比较稳的结构是：
- 画布作为编辑与沟通界面，产出配置
- 配置转成代码（或声明式定义）进仓库，走正常 review 与 CI
- 生产执行用代码路径，画布只用于查看和调试
这样评审、版本、测试都在代码侧解决，画布保留它的核心价值（可见性、实验速度、中间态调试），而不用承担它承担不了的东西（状态机、重试、并发）。
6.1 评测同样要走代码路径
画布上"跑一遍看着对"不能替代评测。流程改动仍然要过 golden set——见《评测集怎么变成门禁》。如果画布配置无法被 CI 加载，那这条流程就没有回归保护。
7. 决定前的三问
- 这个流程需要状态吗？（重试、回滚、等待、长事务）——需要，就用代码框架
- 谁会改它？——只有工程师，画布的收益要打折；有非工程角色参与，收益明显
- 它会被当成产品对外交付吗？——会，先查许可，这一步能直接筛掉一半选项
三个问题问完还觉得要上画布，那就上。画布不是坏东西，它只是常被用在它不擅长的那半边。
最后一句关于《Agent 和写死流程的差别》：Agent 的价值在于它自己决定下一步做什么。画布的价值在于人已经决定好了下一步是什么。这两者是有张力的——画布越详细，留给 Agent 的自主空间越小。所以高度自主的 Agent 流程，用画布表达往往是错配：你画不出一条自己会改自己的线。