Flowise

Flowise 是一个用可视化画布搭建 AI 应用和 Agent 工作流的平台。它既能连接模型、知识库与工具，也能把判断、循环和人工确认放进同一条执行链。对于已经能做出聊天演示、却还不知道怎样约束工具调用和审核结果的团队，Flowise 更值得关注的是执行过程的控制能力，而不只是拖拽节点。

它提供云端服务，也可以自行部署。自建并不等于模型调用免费，模型、向量数据库、运行环境和维护工作仍需分别准备。下面围绕 Agentflow V2 的状态传递展开，帮助判断它是否适合你的业务流程。

Assistant、Chatflow 和 Agentflow，先选哪一种？

Flowise 的三个构建入口不是三个价格档，也不必按顺序全部使用。差别主要在于你需要控制多少执行细节。

例如，只回答产品手册问题，不一定需要多 Agent。反过来，如果“生成答案”只是审批流程的一环，单纯让模型在提示词里遵守步骤，通常不如把这些步骤画成可检查的节点。Flowise 的集成涵盖模型、工具、数据源、向量存储和记忆组件，不能把官网的集成数量直接理解成可用模型数量。

把一段公告草稿交给人工确认，状态怎样传递？

下面是按官方节点机制设计的示例，并非一次已经执行的部署：输入活动信息，让模型生成公告，审核人选择通过或退回，通过后只在对话中返回草稿，不连接外部发布服务。这个小流程已经包含了 Agentflow V2 最重要的几个概念。

Start 先声明状态，LLM 再写入草稿

Start 可以接收聊天输入，也可以使用表单输入。选择聊天输入时，可把活动时间、地点和报名要求作为一次请求；选择表单时，则可以把这些信息拆成明确字段。在 Start 的 Flow State 中预先声明一个 draft 键，初始值留空，用于保存后续生成的公告。

LLM 节点负责读取请求，按“不能补造未提供的地点、价格或报名链接”等要求生成文本，再通过 Update Flow State 把结果写入已有的 draft。这里的先后顺序有实际意义：运行途中更新状态，并不是随意新增一个没有在 Start 声明的键。后面的节点可以通过变量选择器引用 {{ $flow.state.draft }}，不必重新生成一次公告。

共享状态也不等于长期记忆。$flow.state 服务于这一次流程执行；独立的新请求不能被默认视为继承上次状态。若业务需要跨会话保存用户资料或历史记录，应另外设计持久化存储与记忆，而不是把它们塞进临时状态后期待一直存在。

Human Input 决定分支，Direct Reply 决定回复什么

在 Human Input 的说明中引用草稿，就能让审核人看到要确认的内容。这个节点会暂停流程，并提供继续或拒绝的分支；如果需要，也可以接收反馈。审核通过分支连接 Direct Reply，把 draft 返回给用户；拒绝分支则返回“请修改活动信息后重新提交”等说明。Direct Reply 会结束所在分支，不是一个还能继续接其他节点的中转站。

如果想实现“退回后自动改稿”，还需要把反馈接入新的改写步骤，并明确循环上限。仅仅放一个 Human Input，不会自动形成修订闭环。人工暂停后的恢复属于原流程的继续执行，也不代表任意新会话都能读取那份草稿。

检查的重点不是画布是否连通

• 信息齐全：草稿应保留输入的时间、地点，不擅自增加报名条件。
• 缺少活动时间：应提示补充或保留缺项，而不是编造日期。
• 选择拒绝：只进入退回分支，不应继续输出“已通过”的公告。
• 选择通过：最终回复应引用已审核的 draft，而不是再调用模型生成另一版。

把“生成”“确认”“交付”拆开，目的正是让错误停在对应步骤，而不是看到一段通顺文字就认为流程已正确完成。

哪些步骤交给 Agent，哪些应写成固定规则？

Agent 节点适合让模型根据上下文决定调用哪些工具；Tool 节点则适合已经知道要调用哪个工具、只需明确传入参数的任务。比如“根据问题选择查哪份资料”可以交给 Agent，而“审核通过后写入指定系统”更适合一个输入明确的固定工具步骤。两者都能调用能力，但执行责任不同。

条件判断也有相似区别。金额是否超过阈值、字段是否为空，适合使用确定性的 Condition；需要按自然语言含义归类，才考虑 Condition Agent。若已有业务规则能精确表达，改成模型判断往往只会增加不确定性。

知识检索可以使用 Retriever，从已经准备好的 Document Store 中取得文本或带元数据的结果，再交给后续节点。需要保留来源时，应让元数据沿着流程继续传递，不能只保留模型润色后的回答。多 Agent 协作、数组迭代和回路则适合更复杂任务，但每增加一层，都要解释清楚谁负责输入、谁验证输出，以及何时终止。

从画布走向应用，还要补齐哪些交付条件？

API、嵌入组件与运行观察

Flowise 提供 Prediction API、JavaScript/Python SDK 和聊天嵌入组件。常见调用入口是 POST /api/v1/prediction/:id，可以按流程类型传入问题、表单数据或其他受支持输入；人工确认的恢复也有相应输入机制。对外接入前，要确定客户端能调用哪条流程、允许提交哪些字段，而不是把编辑器的全部控制能力暴露出去。

运行观察需要区分层次：节点执行及模型调用的分析用于定位具体问题；Prometheus、Grafana 或 OpenTelemetry 等监控集成，则可用于观察服务层面的指标。高层监控有数据，并不自动证明每一次工具调用都已经具备完整业务追踪。团队还应按部署方案确认队列、工作进程、权限与审计能力的实际配置。

许可、部署和企业能力应分别核对

Flowise 仓库并非统一采用 MIT 许可：一般代码适用 Apache 2.0，企业目录及明确标识的文件有单独商业许可，第三方组件也可能有各自条款。需要改造或交付给客户时，应按实际使用的目录和功能检查许可，不能仅凭“开源”二字判断可任意商用全部模块。

Workday 于 2025 年 8 月宣布收购 Flowise，但收购背景不等于每个部署版本都自动获得企业级权限、合规认证或运维保障。云端和自建的账号管理、模型密钥、数据留存与升级责任，仍要按所选方案落实。如果还在比较不同平台的任务边界，可结合AI Agent 平台选型指南，先决定需要的是知识问答、组件编排还是可审核的多步骤执行。