应用系统的工作流 vs AI 工作流 — 对比分析

CCFlow 工作流 vs AI 工作流 — 对比分析

基于 BP.WF 引擎能力与典型 AI Workflow / Agent 编排场景整理，面向产品设计、架构选型与融合演进参考。

1. 一句话结论

CCFlow 的一等公民是待办（人）；AI 工作流的一等公民是推理与工具调用（模型）。

2. 场景定位对比

CCFlow 擅长：组织内「谁在什么条件下做什么、谁签字负责」。
AI 工作流擅长：非结构化任务的「理解—规划—调用工具—产出结果」。

3. 过程表示与推进方式

3.1 CCFlow：图 + 状态机

发起人填表 → GenerWorkFlow 实例
     ↓
当前节点待办 (GenerWorkerList)
     ↓  人打开 / 填表 / 点「发送」
方向线 Direction + 条件 Cond → 下一节点
     ↓
FindWorker / DeliveryWay → 下一处理人
     ↓
写 Track 轨迹 → 循环直至结束节点

关键载体（BP.WF）：

推进力几乎总是：人点发送（或超时策略、事件钩子自动下传）。

3.2 AI 工作流：目标 + 计划 + 工具环

用户目标 / Prompt
     ↓
LLM 理解与规划（Plan）
     ↓
选择 Tool / Agent / Sub-agent
     ↓
执行 → 观察结果 → 再推理（ReAct / Plan-Execute）
     ↓
可选 Human Gate → 最终产出

过程往往不是事先画死的固定图，而是运行时由模型生成下一步；图若存在，也多为「粗粒度阶段」而非细粒度岗位审批链。

3.3 对照小结

4. 「执行者」模型对比

4.1 CCFlow：组织与接受人规则

找人是引擎核心能力之一，典型机制：

• DeliveryWay：按岗位、部门、SQL、上一步选择、表单字段等数十种规则
• TodolistModel：抢办、会签协作、队列、共享等多人模式
• RunModel：普通 / 分流(FL) / 合流(HL) / 分合流 / 子线程
• 组织模型：Port_Emp / Dept / Station 与节点绑定

节点上虽有 WhoDoIt（Operator / MachineOnly / Mux）等人机混合钩子，但产品主路径仍是 Operator 人工审批。

4.2 AI 工作流：Agent 与工具

• 执行者多为 Agent / Worker / Tool
• 「找人」变成「选哪个模型、哪个工具、是否需要人工审核」
• 并行常表现为多 Agent 协作或异步任务扇出，而非组织分流合流

5. 数据、表单与状态持久化

5.1 CCFlow：数据库中心

典型表模型：

特点：

• 强结构化表单驱动条件与找人
• 待办、在途、已办、抄送列表全部围着库转
• 报表、监管、督办天然可做

5.2 AI 工作流：会话与 Run 日志

• 状态多为 Run / Session / Thread + 消息历史
• 记忆可能含向量库、外部知识库
• 业务结构化数据常通过 Tool 写入外部系统，而非引擎内置表单体系

6. 控制流能力对照

结论：组织协同类控制流（退回、会签、移交、抄送、督办）是 CCFlow 的「主场」；动态规划与工具编排是 AI 工作流的「主场」。

7. 人在回路（Human-in-the-loop）

对 CCFlow 而言，「无人自动跑完」是例外（超时、事件、机器节点）；对 AI 工作流而言，「人全程审批每一步」是例外。

8. 设计期 vs 运行期

说明：BP.WF 中已有 AI 相关能力，但定位多为设计期助手（如 AI 生成流程/表单、Copilot），运行时发送主链路仍走传统 NodeSend / NodeSendOrchestrator，并非独立 Agent 执行器。

9. 非功能与工程差异

10. 适用场景建议

更适合 CCFlow

• 强组织审批链：多级领导签批、会签、抄送
• 强合规审计：公文、财务、人事、采购
• 路径相对稳定、规则可配置固化
• 需要待办中心、在途监管、超时督办、岗位交接

更适合 AI 工作流

• 高非结构化：文档理解、方案生成、代码修改
• 步骤依赖模型判断，难以事先画全部分支
• 希望少人值守、自动调用多个系统/工具
• 探索性任务、内容生产、智能客服编排

不适合简单二选一的场景

• 「先 AI 起草，再走组织审批」
• 「审批中嵌入智能建议 / 智能找人 / 风险识别」
• 「AI 自动跑子任务，关键节点仍必须人签」

这类场景更适合 融合架构（见下一节）。

11. 融合演进：不是替代，而是分层协作

推荐把二者看成两层，而不是互斥产品：

┌─────────────────────────────────────────┐
│  AI 层：理解、草稿、建议、工具执行、风控评分   │
└──────────────────┬──────────────────────┘
                   │ 结构化结果 / 建议 / 自动填单
┌──────────────────▼──────────────────────┐
│  CCFlow BPM 层：待办、权限、会签、退回、轨迹 │
└──────────────────┬──────────────────────┘
                   │ 组织责任落地
┌──────────────────▼──────────────────────┐
│  业务系统 / 表单数据 / 消息 / 档案            │
└─────────────────────────────────────────┘

可落地的融合模式：

原则建议：

1. 权责仍归 BPM：凡涉及签字、同意、驳回，最终状态迁移走 CCFlow。
2. 智能尽量无状态或可重入：AI 失败不应破坏 GenerWorkFlow 一致性。
3. 双轨审计：Track（人）+ AI Run 日志（模型/工具）一并可查。
4. 先建议后自动：智能能力先做「辅助」，稳定后再开放「自动下传」。

12. 概念速查对照表

13. 总结

1. CCFlow 解决的是组织协作与合规落地：谁办、按什么规则办、如何留下可追责轨迹。
2. AI 工作流 解决的是智能任务编排：如何理解目标、规划步骤、调用工具并产出结果。
3. 二者在表示模型、推进力、执行者、状态持久化、控制流语义上差异显著，不宜互相替代。
4. 最佳实践是 AI 负责智能与效率，CCFlow 负责权责与协同，通过建议、填单、机器节点、子流程回调等方式分层融合。
5. 当前 BP.WF 中的 AI 能力偏设计辅助与办理建议雏形；若要做「AI 原生运行时」，需要在保持 BPM 主链路稳定的前提下，单独沉淀 Agent 执行、可观测与人审闸门能力。

附录：阅读代码时的关键入口（CCFlow）

文档生成说明：对比以 CCFlow BP.WF 传统 BPM 能力为基准，AI 工作流侧按业界常见 Agent / LLM Workflow 抽象归纳，便于产品与架构讨论对齐。