在 Camunda 中实现任意节点跳转，不能把运行时表里的当前节点 ID 直接改成目标节点 ID。正确做法取决于产品线：Camunda 7 使用 RuntimeService.createProcessInstanceModification，在同一事务中组合"启动目标活动"和"取消源活动实例"；Camunda 8.9 优先使用 moveElement 或 moveElements，由引擎把终止源元素实例与激活目标元素合并为一次原子修改。
真正困难的不是调用一个 API，而是确定要移动哪个运行令牌、目标属于哪个作用域，以及移动后并行网关、多实例、子流程、变量、监听器和业务单据是否仍然一致。因此，任意节点跳转应当被设计成受权限、校验和审计约束的异常修复能力，而不是普通审批按钮。
一句话结论：Camunda 7 用 Process Instance Modification 组合指令；Camunda 8.9 用 Move Instruction。普通节点可以直接移动，遇到并行、多实例和嵌套子流程时必须按"实例键 + 祖先作用域"精确定位。
一、核心结论与问题边界
先确认版本：Camunda 7 与 Camunda 8 是两套实现
截至 2026 年 8 月 2 日，Camunda 7 Community Edition 的最终开源标签是 7.24.0，官方仓库已经归档并标记为 EOL；Camunda 8 当前稳定维护线是 8.9，本文按 8.9.13 的 Java Client 与 Zeebe Engine 源码核对。两者的 API、运行时标识和持久化模型并不兼容，不能把 Camunda 7 示例直接套到 Camunda 8。
| 对比项 | Camunda 7.24 | Camunda 8.9.13 |
|---|---|---|
| 核心运行时 | 关系型数据库上的 Execution Tree | Zeebe 分区日志与 Element Instance |
| 精确定位标识 | activityInstanceId | elementInstanceKey |
| 推荐入口 | ProcessInstanceModificationBuilder | ModifyProcessInstanceCommand |
| 移动方式 | 启动目标 + 取消源实例 | moveElement / moveElements |
| 指令顺序 | 按 Builder 添加顺序执行 | Move 展开后先激活、再终止 |
| 典型部署 | 嵌入式或共享流程引擎 | Orchestration Cluster / Zeebe |
图 1：同样叫"节点跳转"，Camunda 7 修改 Execution Tree，Camunda 8 修改 Element Instance 状态。
严格来说，Camunda 7 CE 使用 Apache License 2.0；Camunda 8 核心仓库中包含采用 Camunda License 1.0 的源代码。企业私有化部署时，除了技术能力，还应单独完成版本生命周期、许可边界和支持策略评审。
任意节点跳转到底修改了什么？
任意节点跳转不是修改一条记录，而是对运行时状态做一次结构化变更。一个可靠的跳转至少包含四个动作：识别源令牌、确定目标活动、处理源状态的结束语义、让目标节点按引擎规则创建任务、作业、事件订阅和变量作用域。
| 概念 | 正确定义 | 常见误区 |
|---|---|---|
| 源节点 | 当前模型元素的业务 ID | 以为它能唯一定位运行实例 |
| 源实例 | 某一次真实运行的活动/元素实例 | 把 activityId 当实例 ID |
| 目标节点 | 需要重新激活的 BPMN 元素 | 认为会自动补跑中间路径 |
| 祖先作用域 | 目标实例应创建在哪个子流程实例内 | 忽略嵌套或多实例作用域 |
| 跳转 | 取消/终止源实例并激活目标 | 直接更新运行时数据库 |
如果模型在并行网关后同时存在两个分支，那么"从审批节点跳到归档节点"可能是移动其中一个分支，也可能是收拢全部分支。两种操作得到的令牌数量完全不同。引擎只能执行指令，无法替企业判断业务意图。
二、关键概念与能力差异
Camunda 7 如何实现普通节点跳转？
Camunda 7 的公开入口是 RuntimeService.createProcessInstanceModification(processInstanceId)。对于只有一个源实例的普通用户任务，推荐先用 Activity Instance Tree 找到精确的 activityInstanceId，再启动目标活动并取消源活动实例。
java
public void jumpCamunda7(String processInstanceId,
String sourceActivityInstanceId,
String targetActivityId) {
runtimeService.createProcessInstanceModification(processInstanceId)
.startBeforeActivity(targetActivityId)
.cancelActivityInstance(sourceActivityInstanceId)
.setAnnotation("人工修复：跳转到 " + targetActivityId)
.execute(false, false);
}这里把 startBeforeActivity 放在前面并非笔误。Camunda 7 按 Builder 中指令的添加顺序执行；官方示例也先启动目标、再取消源活动。这样即使源活动是流程实例最后一个活动，也不会在目标令牌建立前把整个实例向上删除。所有指令仍处在同一引擎事务中，后续指令失败时会整体回滚。
execute(false, false) 表示不跳过自定义监听器，也不跳过输入输出映射。生产环境不要为了"少触发一次代码"随意改成 true, true，否则历史、通知、业务回调和变量准备可能与正常路径不同。
图 2：Camunda 7 的一次跳转由两条有序修改指令构成，目标任务按 BPMN 行为重新创建。
Camunda 7 为什么要用 activityInstanceId，而不是只传 activityId？
cancelAllForActivity(activityId) 很方便，但它会取消该活动的全部活动实例以及进入或离开该活动的 Transition Instance，取消顺序还是任意的。遇到会签、并行分支或循环重入时，它可能一次取消多个令牌。
更稳妥的做法是读取 Activity Instance Tree，要求调用者明确选择某个活动实例：
java
ActivityInstance tree = runtimeService.getActivityInstance(processInstanceId);
String sourceInstanceId = findSingleActivityInstance(tree, sourceActivityId);
runtimeService.createProcessInstanceModification(processInstanceId)
.startBeforeActivity(targetActivityId)
.cancelActivityInstance(sourceInstanceId)
.execute();如果目标位于嵌套子流程，而且同一个子流程存在多个运行实例，应调用 startBeforeActivity(targetActivityId, ancestorActivityInstanceId)。源码中的 AbstractInstantiationCmd 会沿 Flow Scope 向上查找可复用的 Scope Execution；如果候选 Execution 多于一个又没有显式祖先实例，它会因作用域歧义而失败。
Camunda 7 还提供三种启动指令：
startBeforeActivity：从活动进入前开始，尊重asyncBefore，通常最适合用户任务跳转。startAfterActivity：从活动唯一的出线开始，不考虑asyncAfter；无出线或多条出线时失败。startTransition：直接启动指定 Sequence Flow，不计算该 Sequence Flow 的条件。
因此，"跳到网关后面"不等于"让网关重新判断"。如果业务要求重新计算条件，应跳到网关前的稳定等待点，或显式重构模型。
三、模型架构与运行机制
Camunda 7 源码调用链如何工作？
7.24.0 的调用链可以概括为：RuntimeServiceImpl 创建 ProcessInstanceModificationBuilderImpl，Builder 把启动和取消动作保存为命令列表，ModifyProcessInstanceCmd 在命令上下文中依次执行这些命令。
| 源码类 | 关键职责 |
|---|---|
| RuntimeServiceImpl | 暴露 createProcessInstanceModification |
| ProcessInstanceModificationBuilderImpl | 组装 ActivityBeforeInstantiationCmd、ActivityInstanceCancellationCmd 等操作 |
| ModifyProcessInstanceCmd | 鉴权、保留作用域、按顺序执行、记录用户操作日志 |
| AbstractInstantiationCmd | 解析目标 Flow Scope，创建缺失的父作用域和目标执行 |
| AbstractInstanceCancellationCmd | 计算可取消的最高 Execution，清理子树并处理父作用域 |
源码里有三个容易被业务系统忽略的细节。
第一，ModifyProcessInstanceCmd 会先设置 processInstance.setPreserveScope(true)，再逐条执行操作，以避免中间取消动作过早破坏流程实例根作用域。第二，实例化目标活动时，每执行一条指令都要重新构建 ActivityExecutionTreeMapping，因为上一条指令已经可能改变执行树。第三，顺序多实例的 Flow Scope 不支持并发创建子实例，源码会拒绝这种状态构造。
这也解释了为什么不应直接更新 ACT_RU_EXECUTION、ACT_RU_TASK：任务、变量、作业、事件订阅、历史记录和 Execution Tree 之间存在联动，仅改某张表无法重建完整状态。
Camunda 8.9 如何实现任意节点跳转？
Camunda 8 早期常见做法是把 activateElement(target) 与 terminateElement(sourceKey) 放进同一个修改命令。8.9 的最新接口已经提供 Move Instruction，官方文档明确建议用它移动执行位置，因为它把终止源元素实例和激活目标元素表达为一次原子操作，并能更好地处理多实例子流程。
普通场景优先使用元素实例键：
java
camundaClient.newModifyProcessInstanceCommand(processInstanceKey)
.moveElement(sourceElementInstanceKey, "targetApproval")
.send()
.join();如果源与目标是同一个多实例子流程实例中的兄弟节点，可以直接复用源实例的父作用域：
java
camundaClient.newModifyProcessInstanceCommand(processInstanceKey)
.moveElementWithSourceParentAsAncestor(
sourceElementInstanceKey, "targetApproval")
.send()
.join();若目标与源的嵌套层级不同，可使用 moveElementWithInferredAncestor 让引擎沿源实例祖先层级寻找与目标 Flow Scope 匹配的实例；对高风险场景，最好显式传入 ancestorElementInstanceKey，让操作可审查、可复现。
moveElements(sourceElementId, targetElementId) 会在运行时匹配该元素 ID 的全部活动实例。它适合明确的批量修复，不适合默认用在会签或循环场景。单实例审批跳转应优先使用 moveElement(sourceElementInstanceKey, targetElementId)。
图 3：Camunda 8.9 的 Move Instruction 在一个命令内描述源实例、目标元素与祖先作用域。
四、核心场景与处理策略
Camunda 8 源码为什么仍然是"先激活、再终止"？
8.9.13 的 ModifyProcessInstanceCommandStep1 已公开 moveElement、moveElements 以及三类祖先作用域策略。客户端把 Move Instruction 写入修改请求，Zeebe Broker 的 ProcessInstanceModificationModifyProcessor 再把它映射为 Activate Instruction 与 Terminate Instruction。
处理器的关键顺序是：
- 校验流程实例、权限、源实例、目标元素和祖先作用域。
- 将 Move Instruction 映射为"激活目标 + 终止源实例"。
- 执行全部激活指令，记录新建 Flow Scope 的键。
- 执行全部终止指令，但保留目标激活仍需要的作用域。
- 写入
ProcessInstanceModificationIntent.MODIFIED事件并返回结果。
先激活再终止可以避免源令牌恰好是流程或子流程最后一个活动实例时，作用域先被关闭。命令校验或任何指令执行失败时，官方语义是全部拒绝，流程实例保持修改前状态。
源码还会校验 MODIFY_PROCESS_INSTANCE 权限；挂起的流程实例不能修改；源元素实例必须属于被修改的流程实例；显式祖先键必须存在、处于活动状态并且确实是目标元素的祖先作用域。
并行、多实例和子流程应该怎样处理？
普通线性流程只需要移动一个令牌，复杂模型则要先回答"要保留多少个令牌"。下面这张表比"向前跳还是向后跳"更重要。
| 场景 | 推荐定位方式 | 主要风险 | 建议策略 |
|---|---|---|---|
| 单一用户任务 | 活动/元素实例键 | 重复提交 | 一次只移动一个实例 |
| 并行分支 | 分支实例键集合 | Join 永久等待或重复放行 | 先画出迁移前后令牌数 |
| 并行会签 | 单个会签实例键 | 误取消其他审批人 | 禁用按元素 ID 全量移动 |
| 嵌套子流程 | 祖先作用域实例键 | 激活到错误子流程实例 | 显式传 ancestor key |
| 多实例子流程 | 源实例 + sourceParent/inferred | 新建错误迭代 | Camunda 8 优先 Move，不用直接 Activate |
| Call Activity | 父流程中的调用活动实例 | 子流程结束语义不明确 | 从父流程修改 Call Activity |
图 4：节点跳转的安全边界取决于令牌数量和作用域，不能只比较 sourceId 与 targetId。
Camunda 8 当前限制还包括：不能把激活目标设为流程或子流程 Start Event、Boundary Event、事件网关所属事件或 Sequence Flow；不能通过修改命令终止被 Call Activity 创建的子流程实例的最后一个活动元素，应改为修改父流程中的 Call Activity。
对于并行 Join，最危险的是把一个新令牌直接放到 Join 后，而另一个分支仍会到达 Join。结果可能是遗留令牌、重复执行业务或流程永久等待。可靠做法是把迁移计划写成"迁移前令牌集合 → 迁移后令牌集合"，并在测试中断言集合，而不只是断言新待办存在。
五、数据、规则与状态设计
变量、监听器、历史和业务状态会怎样变化？
跳转会产生新的运行实例，它不是"把旧待办改个名称"。目标节点的任务、作业和事件订阅通常会按目标 BPMN 行为重新创建，源实例则以取消或终止语义结束。
| 关注点 | Camunda 7 | Camunda 8 |
|---|---|---|
| 变量 | 可随启动指令设置全局或局部变量 | 可随激活/Move 指令设置变量及作用域 |
| 监听器 | 默认执行自定义监听器与 IO Mapping，可显式跳过 | 激活按元素行为创建资源；终止用户任务不触发 canceling listener |
| 历史/审计 | User Operation Log 可带 annotation | 写入修改记录与统一审计数据 |
| 原任务 | 被取消并留下历史语义 | 元素实例终止，相关运行资源被清理 |
| 业务单据 | 引擎不会替业务系统回写状态 | 同样需要应用层协调 |
如果目标节点依赖上游变量，应在跳转前生成变量补偿清单。仅仅让目标待办出现并不代表业务正确：输入映射可能读到旧值，服务任务可能再次调用外部系统，边界事件可能被重新订阅，通知监听器也可能重复发送消息。
企业系统应为跳转设置独立操作类型，例如 PROCESS_INSTANCE_MOVE，记录操作人、原因、源实例键、目标元素 ID、祖先作用域、变量差异、修改前后令牌快照和引擎返回结果。业务单据状态建议通过同一事务内的 Outbox 或可靠事件消费更新，避免"引擎已跳转、单据仍显示原状态"。
六、工程实现与系统集成
企业级跳转服务应该怎样设计？
不要把引擎 API 直接暴露给前端。一个可上线的跳转服务至少要经过"查询、规划、校验、执行、核验"五步。
- 查询：读取流程定义版本、当前活动实例树或元素实例集合、任务、作业、变量与业务单据版本。
- 规划：明确源实例集合、目标元素、祖先作用域和迁移后的预期令牌集合。
- 校验：检查操作权限、流程是否挂起、目标是否允许激活、是否跨越并行 Join、多实例和 Call Activity 边界。
- 执行：提交带幂等键和审计原因的单次修改命令，禁止直接改运行时表。
- 核验：重新查询运行实例，确认源实例已结束、目标实例数量正确、业务状态和审计记录一致。
接口层还应实现乐观并发控制。用户打开操作页后，原任务可能已经被别人完成；因此提交时要携带修改前快照版本或源实例键，并在执行前再次校验。Camunda 8 可把业务请求 ID 保存为操作引用或外部审计键；Camunda 7 可结合业务幂等表与 User Operation Log annotation 防止重复点击。
对于低代码平台，真正有价值的不是提供一个"输入节点 ID"的文本框，而是把 BPMN 图、活动实例树、目标可达性、变量补偿、权限和审计整合成可解释的迁移计划。云程低代码开发平台可以在这一层承接中国式审批中的驳回、回退和管理员纠错，但底层仍应遵守 Camunda 的实例与作用域规则。
七、安全、性能与治理要求
哪些情况不应该使用任意节点跳转？
如果某种路径会高频发生，就应该建模，而不是长期依赖修改 API。以下场景更适合调整 BPMN：正常驳回、补资料、条件重审、超时转办、固定的撤回窗口、可预期的人工复核。
以下场景才适合管理员修复：流程模型缺陷导致少量实例走错分支、外部系统故障使实例卡在不可恢复的等待点、上线修复后需要调整存量实例、测试环境需要快速构造特殊运行状态。
Camunda 7 官方文档明确提示，不建议流程活动修改自己的流程实例，因为这可能产生未定义行为。Camunda 8 官方也把 Process Instance Modification 定位为异常修复工具，并建议先在非生产集群或 Camunda Process Test 中验证。