知识库不止能问答，还能按流程自动跑
新文档进库自动归类、定时汇总、Webhook 触发通知——有谷工作流用 FlowExecutor 编排 action 与 tool，支持延迟、审批和断点续跑。
销售把合同 PDF 丢进「待整理」文件夹，希望系统自动：识别类型 → 分到「合同」目录 → 通知法务群 → 三天后提醒归档。
这件事用 Agent 问答也能「聊出来」，但步骤固定、要可审计、要失败重试、要人工在某一环点批准——更适合工作流，而不是每次靠 prompt 碰运气。
有谷大脑内置工作流引擎：可视化（或 JSON）编排 Flow map，由 FlowExecutor 驱动；触发器（Webhook、Cron、内部事件）启动一次 run，节点分 Action（对外部系统做事）和 Tool（流程控制），运行历史持久化，支持挂起后续跑。
工作流和 Agent 怎么分工
| Agent | 工作流 | |
|---|---|---|
| 决策 | 非确定性，模型规划 | 确定性，人画好图 |
| 适合 | 开放问答、起草、多工具探索 | 固定 SOP、合规、集成 |
| 失败 | 重试整轮对话 | 节点级日志、从断点续跑 |
| 人工 | 对话中确认 | 审批节点显式挂起 |
两者共用知识库：工作流里的「查询知识库」「文档自动归类」调同一套 RAG 和文档 API；Agent 里的 query_knowledge_base 和 workflow action 不重复造轮子。
FlowExecutor 核心语义
一次 flow run 大致是：
- 加载 FlowBlueprint 的
map_json（节点树 + 连线） - 创建或恢复
flow_history（运行实例） - 从触发节点或挂起恢复点
_run_nodes - 每个节点：Action（HTTP、邮件、有谷内置）或 Tool（条件、延迟、循环、JSON 解析…）
- 写节点级 log；失败按策略 abort / continue
- 遇到 delay / 审批 → 持久化 pending，Celery 延迟任务或人工操作后
execute(..., history_uuid, next_node_id)续跑
与「单次 HTTP 请求里跑完」不同，跨时间的暂停是 first-class：delay 节点 schedule 未来唤醒；approval 节点等人点通过再继续——语义对齐常见 iPaaS，但跑在有谷自己的 Celery + Postgres 栈上。
内置 Action 示例：文档自动归类
yoguBrain action 的 assignDocumentFolder：对新入库文档，用文件夹匹配服务（embedding + 规则）建议目标目录，置信度超过阈值则移动，否则留待人工或走审批分支。
这依赖前面 入库 已完成、文档有 Markdown 摘要和 metadata——工作流是入库链的下游消费者，不是替代解析。
其它常见 Action：
- HTTP — 调外部 CRM、工单系统
- Mail — 发通知邮件
- Webhook 响应 — 对外部触发器返回结构化结果
Tool 节点：流程里的控制流
- condition — 按表达式走不同分支（类似 n8n 的 IF）
- delay — 挂起 N 分钟/小时/天
- approval — 人工闸门
- iterator / repeater — 对列表逐条处理（批量文档、批量通知）
- json_parser / markdown — 把上一步输出结构化，供下游用
容器节点（iterator 子树）递归执行：对每个元素重放子 map，RunContext 里隔离变量，避免并行污染。
触发器从哪来
- Webhook — 外部系统 POST，payload 进 trigger_data
- Cron — 定时（日报、过期提醒）
- 内部 bus — 如「文档入库完成」事件，和 SSE 进度 同源不同消费者：进度给 UI，事件给 workflow
文档入库完成 → 触发「自动打标签 + 通知 owner」；比轮询 API 更省、也更实时。
可观测与失败
每个节点一条 log：开始时间、结束时间、输入输出摘要、status（success / error / pending）。运维可以定位「卡在 approval 还是 HTTP 超时」，业务可以审计「谁在何时把合同移到了哪个文件夹」。
失败策略 OnNodeFail：整条 run abort，或记录错误走错误分支（发告警、建工单）。不会像 Agent 那样 silently 换说法——流程要么走到成功终点，要么显式失败。
和开放能力的边界
- Open API / MCP — 给外部系统「查库、写入」的能力
- 工作流 — 在有谷内部或 Webhook 边界上「编排多步」
- Agent — 给人用的对话面
企业版常见组合：Webhook 收 OA 审批结果 → 工作流更新文档状态 → Agent 答「这份合同现在什么状态」——三者各管一层，数据都在同一知识库。
什么时候该上工作流而不是 Agent
- 步骤和 IF 分支在上线前就能画完
- 需要法定保留执行日志
- 某步必须人工签字（approval）
- 要等现实世界的时间（delay 三天再提醒）
- 同一逻辑要对 100 个文档重复（iterator）
什么时候仍用 Agent：问题开放、需要综合多源、引用和解释比固定步骤更重要。
有谷大脑的定位是「知识工作与学习」——问答让人即时弄懂，工作流让组织规则 7×24 执行。FlowExecutor 把后者做成和 RAG、Agent 同级的 first-class 能力，而不是 Zapier 外挂：文档、权限、审计、触发器都在一个 tenant 里闭环。