企业 Workflow 引擎怎么选？从定时任务、队列到 n8n、Temporal、Camunda
讨论"用什么工作流引擎"很容易变成工具偏好投票。有人习惯 cron，认为加一张表就够；有人在消息队列上做过项目，主张所有步骤都异步；有人擅长 n8n，希望用可视化节点尽快接 CRM；有人喜欢 Temporal 的代码式长流程，也有人认为企业人工审核必须从 BPMN 和 Camunda 开始。每个意见都可能有合理的局部场景，但若不先定义业务硬条件，工具比较就只剩产品演示、学习曲线和个人经验。
本文还是 AcmeFlow 的星河设备客户维保服务开通案例。主申请沿用租户 xinghe-demo、业务键 CUSTOMER-001、申请及实例 UUID。核心路径要保存人工审批、签署与到账事实、超时、ERP 建档结果和可恢复的补偿；旁路还有 CRM 通知与报表。这一案例实际上不必强迫所有动作进入同一个产品。对每日对账报表，用定时查询可能足够；对外部 ERP 调用，任务队列可能合适；对 CRM 通知，n8n 能发挥连接器优势；对需要长时间等待、升级和可审计人工任务的主链，则应比较代码式编排与 BPMN 平台。
图 1：业务问题、硬门槛、团队运营能力与故障验收依次收窄选项；为案例设计方法，不是厂商评分。SVG。
先问四个可验证的问题
第一，任务到底是固定时间的短作业，还是跨天等待人工和外部事件的实例？前者可以每晚扫描一张表并生成报表，失败后重新运行；后者必须明确实例身份、等待事件、版本和超时策略。第二，副作用能否安全重试？如果对 ERP 的请求会创建服务，队列、n8n 或工作流引擎的自动重试都不能替远端设计稳定操作键。第三，谁运营失败实例？如果需要运营同事在可视化任务列表中领单、转派、升级，仅有后台队列状态可能不够。第四，是否有明确的 BPMN、流程审计或跨部门共同建模要求？有这一条时，图形流程定义可能是硬条件，而不是"好看"的附加功能。
还要问哪些事情根本不需要流程引擎。每天上午九点按 SQL 找出昨天未完成的申请并生成一个内部日报，若不影响核心状态、无复杂重试和人工等待，先用系统已有的定时设施即可。把它搬进大规模长流程平台，只会增加部署、权限与迁移负担。相反，把多天的人工审批压成一个 cron 每分钟轮询也不是节俭：取消、重新分派、资料改版、旧回执和实例审计很快会变成散落在 SQL 与脚本里的流程引擎。最小方案必须真正覆盖故障和运维，不是只覆盖正常 Demo。
五类工具解决的问题不同
cron + SQL 擅长时间触发和确定性批处理。例如定时查询"到期仍 OPEN 的审核任务"，汇总告警或重新调度。它需要自己处理任务锁、重复触发、时区、停机补跑与审计；若扫描逻辑直接调用外部系统，必须避免多个实例重复扫描造成重复副作用。可以从小规模开始，但要写清单次任务的持久状态。任务队列加业务数据库适合异步执行和有限重试：业务库保存权威状态与操作键，队列负责唤醒 worker。队列消息本身不是业务实例；任务 ACK 丢失、重复投递或消息过期，需要业务层幂等与对账。
图 2：从短作业到长流程的教学谱系；横向排列不表示某方案技术级别更高。SVG。
n8n 的优势在连接已有 SaaS、Webhook 与 HTTP API，适合组织内部的通知、同步与轻量审批集成。官方 n8n 文档把它描述为 fair-code 的工作流自动化工具，并提供自托管选项；Webhook 节点支持测试和生产 URL，执行记录也能在 Executions 中查看。它很适合第 18 篇的 CRM 通知，但是否承担开通主状态，取决于版本管理、数据与租户隔离、人工任务语义和运维责任的实际验收，不能因为画布能连接节点就默认满足所有企业约束。
Temporal 更偏向把长时执行逻辑写在代码中，服务端持久化执行历史，worker 重放时按历史重建决策。官方 Workflow Definition对历史与确定性要求写得很明确：工作流代码变更可能与既有历史不一致，产生 nondeterminism 错误。对熟悉软件工程的团队，这使复杂分支、测试和代码评审容易融入已有开发流程；代价是团队必须理解活动副作用、重放约束、版本演进与集群运营。Camunda 则以 BPMN、用户任务及业务与工程共同建模为核心优势。官方 User tasks说明流程在用户任务处等待完成；实际接入还必须验证身份权限与任务 UI 流程，不能把拖一个任务节点当成已经解决授权。
对同一个 AcmeFlow 需求作拆分
主链包含人工审核、资料版本变化、签署与到账乱序、ERP 未知结果、补偿及审计。只把它看成几个 API 调用，会低估长时等待。第 03 到 16 篇用业务数据库和代码逐步实现这些机制，证明自建不是"不可能"，但每加一个特性都要承担测试与值班责任。若项目要扩展到数十类申请、多部门待办和严格流程治理，评估专门引擎可能节省长期维护成本。Temporal 与 Camunda 的选择应围绕团队主力语言、流程模型的变更频率、人工任务的复杂度、运营 UI 的需求以及现有基础设施，而不是只看吞吐数字。
图 3：案例优先试用场景。每行是设计判断，不代表产品官方只适合这一用途。SVG。
旁路 CRM 通知可以与主链分开。AcmeFlow 进入 READY 时在 Outbox 记录事件，n8n 用 Webhook 接收，再通过 HTTP Request 调 CRM，CRM 用事件 ID 去重。即便 n8n 停机，主状态仍由 AcmeFlow 持有，Outbox 等待补投。把 n8n 用在这里，有清晰的输入、输出与故障边界，也能让运营团队维护通知模板。若有人提出"既然已经用了 n8n，就把 ERP 开通也放进去"，必须重新回答谁拥有状态、响应丢失时谁对账、双人审批怎么绑定资料版本、流程升级如何处理在途实例。不能用采购过的软件替代架构评审。
图 4：主链和旁路可使用不同工具，但都必须有明确接口合同与责任人。SVG。
版本和许可应怎样核对
截至本文核对时，Camunda 官方文档显示 8.9 版。其 Self-Managed licensing 页面说明没有有效许可证时部分组件会显示 Non-Production License 警示，Web Modeler 的无许可证使用有限制；生产使用不能从"我能把容器启动"推断获得授权。n8n 官方将产品称为 fair-code，并有 Sustainable Use License；不同计划的团队共享、源代码环境管理等能力也有差异，例如官方 环境管理教程标明相关功能适用于 Business 和 Enterprise。Temporal 服务仓库的 LICENSE为 MIT，但托管云、支持或附加服务的合同仍应另行核对。
这些是写作时官方公开页面的快照，不是长期有效的法律结论或采购建议。实际选型时应把部署方式、用户数、企业客户是否直接使用、源码改造、SLA、数据驻留和升级支持写成需求表，由采购与法务核对当前合同。尤其不能把"有开源仓库""可以免费本地试用""允许商业生产使用"混为一谈。产品版本也要锁定到项目验证的发行版；本文只比较当前官方文档描述的能力，不声称实测了 n8n、Temporal 或 Camunda 的最新二进制发布。
给选型设硬门槛，再讨论权重
附带的 select.py 是一个透明的本地决策辅助脚本。它为五类工具记录"人工任务、长时执行、集成、BPMN、运维负担"五项教学分值；每个场景先检查必需能力，再按案例设置权重。它输出日报偏向 cron + SQL、CRM 通知偏向 n8n、长时审批和受监管 BPMN 偏向 Camunda。所谓"偏向"只代表我们输入的分值与权重，不是实验测量出来的产品性能。改变团队能力、BPMN 是否强制、现有平台或许可约束，排名自然会变化；这正是脚本要表达的重点。
图 5：建设、运行、组织与条款四类成本。数字化采购测算需要结合企业自身环境。SVG。
硬门槛比加权平均重要。假如监管流程必须用 BPMN 形式由业务部门审核，一个在速度和成本上高分、却没有可交付 BPMN 模型的方案，不应靠其他加分"补回来"。同样，数据不得出境、必须内网部署、要求特定审计保留期限，也不是技术分可以抵消的事项。先过滤，再对剩余方案做故障 PoC：部署一份流程，制造 worker 停止、重复回执、旧流程版本、权限错误和外部结果未知。比较恢复时间、可观察性和人工操作，而不是只比"第一次完成 Hello World 花了多久"。
总成本要包括隐藏的组织工作。cron 上手快，但当任务增长到几十个，排班和值班知识可能依赖某一个工程师；队列库需要关注容量和死信；n8n 要管理凭据、权限、导入导出和节点升级；Temporal 要维护 worker 代码与执行历史兼容；Camunda 要治理流程模型、任务权限、部署和许可证。这些不是某个工具独有的"缺点"，而是责任被放在不同位置。选型报告应列出谁负责部署、备份、告警、版本升级、数据迁移和在途实例处理。没有明确所有者的能力，宁可降低范围，也不要画进正式方案。
FDE Thinking：给客户一张可验证的决策记录
面对客户问"我们到底要不要上流程引擎"，FDE 不应马上抛产品名单。先把代表性申请分成三类：简单定时作业、独立旁路集成和核心长流程。每类写出输入、输出、最长运行时间、失败恢复动作、操作人及不可接受的业务结果。再选两个最有争议的方案做同一组故障实验，记录实测与未测。最后留下可复盘的决策记录：为什么选、什么时候会重新评估、要观察什么信号。这让下一位工程师能理解当初的边界，而不是只继承一个没有背景的工具栈。
特别要防止"一个平台包办全部"的惯性。核心状态要求强门禁与补偿，通知要求丰富连接器，日报只需要固定查询。把三者放进一种系统，可能获得统一管理，也可能把每次小改动绑到高风险发布里。拆分也不是越细越好：如果所有业务规则都被分割到事件消费者里，核心主状态又失去所有权。本篇给 AcmeFlow 的结论是先维持一个主状态所有者，再允许旁路工具独立演进；未来如果更换编排引擎，必须迁移状态所有权与在途实例，而不是让新旧引擎同时决定 ACTIVE。
图 6：脚本输出是可解释的教学评分；真实采购还需安全、性能、运维与许可验收。SVG。
从六项能力写出真正的 PoC 试卷
如果要在两周内比较候选方案，PoC 不应只包含"创建申请、输出成功"。同一套试卷至少覆盖六项能力。第一，保存实例：提交后停掉所有执行进程，再启动，能否查询当前等待节点与历史。第二，处理事件乱序：到账先于签署，签署晚到，是否仍只进入一次 READY。第三，处理重复：同一支付回执、同一 Webhook、同一 ERP 操作请求重复两次，业务结果是否唯一。第四，处理未知：ERP 已执行但回复丢失，系统是否保持 UNKNOWN 并按原键查询。第五，处理人工任务：任务领取、拒绝、资料改版、超期升级，是否有一致的身份与审计。第六，处理版本：新流程发布后，已经等待三天的旧实例如何继续、迁移或终止。候选方案必须跑同一套故事，结果才有比较意义。
每项同时测"开发者怎么实现"和"值班者怎么接手"。例如流程重试在开发机上只需一个配置项，但生产事故里需要知道到底重试了几次、下一次何时执行、何时停止、谁能取消、如何关联 ERP 稳定键。流程可视化也不能只看建模阶段的画布，要看运行中的实例是否能定位旧版本、错误活动和具体业务 ID。若团队没有成熟的值班体系，即使某个引擎功能强大，试点也应包括运维培训与跑通故障手册。否则 PoC 的"完成速度"只是把成本推迟到上线以后。
对 AcmeFlow，测试数据应固定同一租户和申请 UUID，让五类方案都面对相同输入。实测记录至少保存产品版本、部署方式、节点或代码版本、测试时间、故障注入动作、观察截图或机器输出和未测项。尤其不能拿厂商官网的能力宣称替代本地运行结论。例如文档写支持重试，不代表你的 ERP 创建动作在响应丢失时可以安全重试；文档写支持用户任务，不代表你的公司身份源与审批权限已经接通。技术评价应把"产品具备接口""我们配置成功""业务验收通过"分成三级证据。
每类方案最容易忽略的成本
定时脚本最常见的问题是"停机错过时间点"。若每天 09:00 运行一次，服务器在 08:55 到 09:10 停机，恢复后要不要补跑？如果需要，不能只依赖调度器下一次触发，应把每个业务日期的执行状态持久化，用唯一键防止同一天重复发通知。跨时区和夏令时也会使"当地时间九点"与"每二十四小时运行一次"不是同一件事。简单方案仍要明确这些边界，但它们可以只为一个固定作业解决，不必引入通用流程平台。
任务队列的隐藏成本是消息与业务库之间的双写。业务状态已改而消息没发，需要 Outbox；worker 执行完成但 ACK 丢失，需要业务幂等；死信任务若无人处理，就是静默漏单。队列提供的是投递与消费基础设施，不会替你决定"付款晚到是否允许进入 READY"或"ERP UNKNOWN 是否能激活"。当团队说"队列里已经有重试功能"，FDE 应追问重试什么操作、使用什么键、在什么时候停、失败是否对业务可见。若答不上来，换成更高级的队列也不会解决规则问题。
n8n 的隐藏成本常在凭据与工作流治理。连接器让第一版集成很快，但节点权限、工作流分享、测试与生产分离、导入导出、历史执行数据、失败重试和版本升级都需要负责人。工作流 JSON 里可能包含测试地址或表达式，导入另一个环境不等于自动完成密钥隔离。官方 分享说明还指出共享工作流会影响参与者对关联凭据的使用与编辑权限；实际授权要按部署计划检验。第 18 篇的练习把 n8n 放在旁路通知，就可以用清晰的边界限制风险：它不触碰 AcmeFlow 主状态，只处理 CRM 通知副作用。
Temporal 的隐藏成本并不是"要写代码"这么简单，而是要遵守长时运行代码的重放与演进规则。工作流可能在旧版本逻辑里等待数周，此时改分支、改活动顺序或随意读取本地时间，会对历史重放产生影响。Temporal 官方 工作流定义详细说明历史事件与命令匹配、何种改动可能导致非确定性错误。团队如果已经建立严格的代码评审、测试和发布机制，可以把这种约束纳入工程流程；若没有，需要把学习与升级成本计入试点。仍要单独设计外部 Activity 的幂等，因为持久工作流不会让第三方 ERP 的写入自动变成原子事务。
Camunda 的隐藏成本是流程模型与运营组织同时引入。BPMN 在业务、风控、工程共同评审时有很强的沟通价值，但模型中的泳道和审批节点只有在角色、候选组、表单权限、任务分派、超期与变更流程都有约定时才可运行。官方 Tasklist 用户任务授权说明权限需要配置，不能把画出来的候选组当成已经生效的访问控制。还要评估历史实例、流程定义升级、部署高可用和许可。若业务没有共同建模的习惯，硬上 BPMN 可能只是把原来的代码复杂度变成画布复杂度。
选型会议不要用同一把尺子量所有方案
"每秒可处理多少任务"只有在工作负载真的受吞吐限制时才是核心指标。客户服务开通往往更多受人审、签署和外部系统延迟影响。一个方案每秒能调度十万次，却无法让运营人员准确找到逾期实例、无法安全迁移旧任务，可能并不适合。相反，每天只处理几百份申请的项目，也不应因规模小就忽视审计和权限。选型表要写性能目标，但与业务可用性、可追责和团队维护能力并列，不用单一总分掩盖硬条件。
权重是团队决策而非真理。脚本里"长时审批"给 Camunda 更高分，是因为我们假设人审与可视化模型很重要；如果企业工程团队已深度使用 Temporal、审批 UI 已在自己的运营平台中、BPMN 不是要求，Temporal 可能更优。若公司已有可靠队列、熟悉 PostgreSQL 并且申请类型很少，先扩展当前基座可能比迁移引擎成本低。若 CRM 集成需要几十个现成连接器且不参与主状态，n8n 的优势很明显。透明表格的作用就是暴露这些假设，让业务和技术能在同一张纸上争论，而不是假装一个"客观分数"终结讨论。
可以设置明确的重评触发器：申请类型超过一定数量、人工任务跨多个部门、值班花费持续上升、旧实例迁移成为频繁需求，或者权限审计发现自建系统难以满足要求。触发器应尽可能量化，比如"连续三个季度维护流程状态代码的工时超过新功能工时""一次流程改版需协调超过五个服务发布"。这些数字应由团队自己设定并复盘，本文不替客户指定门槛。没有触发器，选型要么永远不变，要么因某次演示突然翻盘。
从第 03 篇基座迁移时先迁移所有权
第 03 篇的 PostgreSQL 表有 applications、workflow_instances、tasks 和 transition_history。后续章节加入事实、定时任务、Outbox、ERP 操作与对账。若决定把主流程移到 Temporal 或 Camunda，先写清新旧系统的职责切换：新申请从哪一刻由新引擎创建，旧实例继续在老系统跑还是被迁移，期间由谁独占 ACTIVE 决策。不可让两个系统同时监听同一 READY 事件并各自发 ERP 创建命令。初期可按租户或申请创建日期灰度，保留稳定业务键与唯一操作键，逐个验证新实例的审计、状态查询和回滚。
在途实例迁移比新实例启动难。某份申请已在人工任务等待两天，任务归属、剩余截止时间、资料版本与旧签署事实都要携带；如果只复制 state=APPROVED，新引擎无法解释下一步要等谁。另一份实例 ERP UNKNOWN，必须保留原操作键，不能让新引擎以新的键"继续"创建。迁移计划应包含可自动映射的状态、必须人工核对的异常、迁移前后双读校验及停止条件。第一次试点可以让旧实例自然跑完，新申请进入新引擎；这个保守方案往往比追求一次性全量迁移更可靠，但它要求两套系统并存期间各自实例边界清晰。
数据库层也要防双写。旧系统若仍保留 workflow_instances 作为客户查询视图，新引擎状态变更可以通过受控投影同步，但该表此时是读模型还是权威状态，必须明确。不要让旧 API 继续直接写同一行，也不要把新引擎的最终结果当成无条件可信的字符串；投影同样需要租户、实例版本和事件顺序校验。迁移后保留历史 ID 映射，使客服能从旧申请 ID 找到新实例执行记录。只有状态查询、修复入口与审计链也迁移完成，才算完成所有权交接。
一次两周试点怎么安排
第一天只做需求冻结：选一条真实但脱敏的申请旅程，确认正常路径、两条失败路径、人工待办和业务验收人。不要为了展示产品功能持续加需求，否则比较对象每天都变。第二到第四天搭建两个候选方案的最小运行环境，完成身份、配置、数据库或存储，以及版本固定。第五到第七天实现相同业务步骤，不要求把所有适配器写完，ERP 和支付可以用可查询、可去重的模拟服务代替。第八到第十天重点做故障注入：停 worker、丢响应、重复投递、旧版本事件、撤销与超期。最后几天让运营和值班人员亲自操作查询、领取、修复和回滚，再汇总缺口与估算。
试点结论不要只写一个赢家。可以写"当前二十条固定日报沿用 cron；CRM 通知试用 n8n；核心新申请暂保留 PostgreSQL 状态机，达到跨部门会签规模时再比较 Temporal 和 Camunda"。这是一份合理的分阶段架构决策，因为风险和能力不是同时到来的。也可以写"组织已强制使用 BPMN，Camunda 作为主链候选；但 ERP 创建仍通过幂等适配服务而非流程节点直接盲写"。只有把各方案承担的边界写明，团队才不会从一个局部试点推导出全公司所有流程都该迁移。
评价表还应有"未知"一列。若没有运行 n8n 的并发故障测试，就填未验证；若 Camunda 许可条件尚待采购确认，就填待核；若 Temporal 团队没有实践过运行中版本升级，就填高风险。把未知项乘以权重算成某个漂亮总分，只会隐藏下一步要做的工作。对高风险未知，应设置有期限的验证任务与退出条件；对暂时无关的未知，则记录但不阻碍试点。这样选型会议从产品宣讲变成"哪些证据足以做当前决定"的讨论。
对管理层的成本报告可以分建设、运行和变更三段。建设包括首个流程、连接器与身份接入；运行包括存储、集群、告警、值班和许可证；变更包括新审批规则、在途实例迁移、回滚与审计培训。成本估算要有使用量区间和组织假设，而不是一个单点价格。工具在小规模演示下免费，并不表示生产长期没有维护或合同成本；自建代码没有软件许可证，也不表示工程师工时为零。把责任放到表里后，团队可以做取舍，而不是围绕"开源还是商业"标签争论。
选型报告最终应带一份退出计划。若试点工具在三个月后无法达到故障恢复目标，怎么停止创建新实例、让旧实例继续完成、导出历史和审计、把新申请交给替代方案？越早写退出条件，越能发现某个产品的状态导出、版本迁移或许可条款是否会成为锁定风险。退出计划不要求第一天就写完自动迁移工具，但要知道哪些数据必须保留、谁负责导出、客户服务如何查旧申请。评估可退出性，也是评估长期可运营性的一部分。
对供应商演示也应提出相同的三个问题：一条 ERP 调用结果未知的实例，在控制台如何定位；已经运行的流程定义升级后，旧实例按哪版规则继续；未经授权的运营人员是否能完成别人的审批。让演示人员在现场执行失败和权限路径，并保存版本与配置，通常比听一遍产品愿景更能发现集成成本。如果这些问题暂时没有答案，选型报告就把它们标成未验证，列出需要追加的 PoC，而不是把厂商承诺记成已交付能力。