工作流里的会签、或签、加签、转办、委托、传阅、抄送到底有什么区别？

一句话回答：会签、或签解决“多人怎样形成一个审批结论”，加签解决“运行中怎样增加参与人”，转办、委托解决“当前任务责任怎样转移”，传阅、抄送解决“信息怎样触达但不参与审批决策”。

最容易混淆的地方，是只看“这个人能不能收到一条待办”。判断七种操作真正的区别，应同时看五件事：是否形成审批意见、产生几个任务、谁承担最终责任、是否阻塞主流程、是否要求接收人确认。

一、先把七个概念分成三类

七个概念可以先分组：

• 多人决策：会签、或签；
• 运行时变更：加签、转办、委托；
• 信息触达：传阅、抄送。

图 1：先看业务目的，再看具体按钮。会签与或签形成决策，转办与委托改变责任，传阅与抄送只负责信息触达。

加签比较特殊：它不是一种固定审批模式，而是运行中的人员变更动作。加签后新增的人可以参加会签，也可以成为前置、后置或并行审批人。

二、判断一种操作，先回答五个问题

判断问题	为什么重要
是否需要给出同意、拒绝等结论	区分审批与阅读通知
会生成一条还是多条任务	决定候选任务或多实例实现
谁对任务结果承担责任	区分转办与委托
接收人未处理时主流程是否等待	区分审批、传阅与抄送
是否要求阅读确认	区分传阅与普通抄送

如果平台只保存 operationType=TRANSFER，却没有定义上面五项，同一个“转办”按钮在不同业务系统中可能产生完全不同的结果。

三、会签：多人分别办理，再汇总一个结论

会签的核心是“多人都有自己的办理责任”。系统通常为每位会签人创建独立任务，再按照汇总规则决定节点是否完成。

常见会签模式包括：

• 并行会签：多人同时收到任务；
• 串行会签：按照名单顺序逐人办理；
• 全员通过：所有人同意才通过；
• 比例通过：例如同意人数达到 60%；
• 票数通过：例如至少 3 人同意；
• 一票否决：任意一人拒绝即结束；
• 负责人终审：其他人给意见，负责人形成最终结论。

Flowable 可以用 Multi-instance User Task 表达串行或并行会签，并用 completionCondition 提前结束剩余实例。但 nrOfCompletedInstances 只表示完成数量，不天然等于“同意数量”。平台仍需保存每个人的结构化结果并计算 approvedCount、rejectedCount。

会签要提前定义分母口径。审批人请假、重复、被加签或被移除后，比例是否重算？提前满足通过条件时，其他任务是取消、跳过还是未参与？这些状态会影响审计和统计。

四、或签：多人有资格，但通常只需要一个人办理

“或签”在不同产品中有两种常见实现，必须明确。

1. 候选人共享一条任务

这是更常见、也更接近 Flowable Candidate Users/Groups 的实现。系统只创建一条任务，多名候选人都能看到；其中一人 claim 后成为 assignee，其他人的候选列表中不再显示，最终只有一份审批结果。

这种模式适合“部门内任一值班经理审批”“客服组任一人接单”。它的重点是抢占和并发控制，而不是多人投票。

2. 多人各有任务，任一人完成即结束

有些产品把这种模式也叫或签：系统同时创建多条任务，任何一人同意后取消其他任务。它更接近带提前完成条件的并行多实例。

两种实现的历史记录、任务数量和并发行为不同。平台最好分别命名为“候选抢签”和“多人或签”，不要只用一个含糊的 OR_SIGN。

图 2：会签为多人创建独立任务并汇总；候选或签只有一条共享任务；加签是在运行时向当前审批结构增加参与人。

五、加签：运行过程中临时增加审批人

加签的核心不是“换人”，而是“增加人”。原审批人通常仍在流程中，只是新参与人的位置和完成规则发生变化。

常见类型包括：

加签类型	执行顺序	原审批人怎样变化
前加签	新增人员先办理	原任务暂停，完成后回到原审批人
后加签	原审批人先办理	原任务完成后再创建新增任务
并行加签	新人与原审批人同时办理	共同进入汇总规则
串行加签	多名新增人员依次办理	按指定顺序推进
加签并转交	新人办理后流程直接继续	原审批人不再二次办理

加签必须明确是否改变会签分母、是否允许继续加签、加签人能否再加签、重复人员怎样处理、原审批人能否撤销加签。

技术上，加签可能涉及动态增加多实例人员、创建受控子任务、修改执行结构或进入预先设计的加签子流程。不要简单插入一条孤立任务；它必须能阻塞或汇合到原任务，并进入统一历史和权限体系。

六、转办：任务和办理责任一起交给另一个人

转办通常表示当前办理人将任务永久交给目标人，原办理人退出当前任务，目标人成为新的责任人。

转办后通常具有以下语义：

• 当前任务仍是同一业务任务，不新增审批环节；
• assignee 从原办理人变为目标人；
• 目标人可以直接完成、拒绝或继续执行允许的操作；
• 原办理人失去办理权限，但保留转办记录；
• 流程完成后，主要办理责任记在目标人名下。

引擎的 setAssignee 或重新分配 API 可以完成受理人变化，但平台仍要校验转办权限、目标人员范围、岗位合规、数据可见范围和转办原因。

转办不是加签。加签保留原办理链路并增加参与人；转办是把当前责任交出去。

七、委托：别人代办，但原责任人通常仍是所有者

委托表示原办理人临时请另一个人代为处理。推荐使用 owner 与 assignee 分离：

• owner 保存原责任人；
• assignee 指向受托人；
• delegationState 记录委托是否处理中；
• 受托人处理后 resolve，任务返回 owner 确认，或按平台策略直接继续。

Flowable TaskService 的 delegateTask 会把当前 assignee 保存为 owner，并把新用户设为 assignee，同时进入 PENDING 委托状态；resolveTask 表示受托人已处理，可以返回 owner。处于 PENDING 委托状态的任务不能直接按普通方式 complete。

不过，一些 OA 产品把“委托”定义为全权代理：受托人处理后流程直接继续，不再返回原办理人。两种模式都可以实现，但必须在产品上分别叫“协助委托”和“全权委托”，并在审计中同时保存 owner、delegatee 和最终完成人。

转办与委托的关键区别是：转办改变最终责任人，委托通常只改变当前执行人。

八、传阅：要求阅读或确认，但不形成审批结论

传阅用于让相关人员了解内容，常见于公文、制度、会议纪要和风险通知。它通常不要求同意或拒绝，但可能要求“已读”“确认收到”或填写阅读意见。

传阅可以设计为：

• 非阻塞传阅：主流程继续，传阅任务独立完成；
• 阻塞传阅：必须全部或部分确认后，主流程才能继续；
• 限时传阅：到期自动结束并记录未读人员；
• 逐级传阅：阅读人可继续向下传阅。

如果需要已读确认，应创建独立的 Read Task 或平台阅读记录，而不是只发一条消息。传阅记录至少保存发送人、接收人、发送时间、首次查看时间、确认时间和阅读意见。

传阅不是会签，因为阅读人不参与审批结果；也不是普通抄送，因为平台通常需要跟踪阅读状态。

九、抄送：告知相关人，默认不等待、不确认

抄送的核心是信息同步。抄送人能在“抄送给我”中查看流程、表单或审批结果，但不承担办理责任。

典型特点是：

• 不生成可办理审批任务；
• 不要求同意、拒绝或填写意见；
• 默认不阻塞流程；
• 可以发送站内信、邮件、钉钉或企业微信消息；
• 是否允许评论、下载附件、继续转发由权限策略决定。

抄送可以发生在流程启动、某节点完成、流程结束或异常时。平台应区分“抄送事件”和“抄送接收人”，避免重复通知，并明确抄送带来的是查看权限还是仅消息提醒。

抄送不是传阅。需要可审计的阅读确认时，应升级为传阅；仅仅让对方知道，则使用抄送。

十、一张表看清七种操作

类型	主要目的	任务数量	是否形成审批结论	原责任人	默认是否阻塞
会签	多人共同决策	多条	是，汇总	每人分别负责	是
或签	多人中一人办理	一条或多条	是，一人形成	命中者负责	是
加签	临时增加参与人	增加任务	通常是	通常保留	是
转办	永久转移任务	通常仍一条	是	原人退出	是
委托	临时代办	通常仍一条	是或先返回	原人通常仍为 owner	是
传阅	阅读与确认	阅读任务或记录	否	不涉及	默认否
抄送	信息告知	通知或可见记录	否	不涉及	否

“默认”非常重要。平台可以把传阅设为阻塞，把全权委托设为直接完成，也可以把或签实现为多个任务。但只要改变默认语义，就必须在设计器和运行日志中清楚表达。

十一、转办、委托、传阅和抄送的责任流

图 3：转办把责任交出去；委托保留原 owner；传阅要求阅读；抄送只告知。

权限上也有明显差异：

• 转办目标人获得完整办理权限；
• 受托人只获得委托范围内权限，是否能再次转办或加签应受限；
• 传阅人获得阅读与确认权限，不应出现同意、拒绝按钮；
• 抄送人通常只有查看权限，敏感字段仍应继续脱敏。

十二、在 Flowable 中怎样映射

业务语义	Flowable 可复用原语	仍需平台补齐
会签	Multi-instance、completionCondition	票数、意见、分母和提前结束审计
候选或签	candidateUsers/groups、claim	抢签权限、并发提示和超时释放
多任务或签	并行多实例、提前完成	其他任务取消原因和副作用处理
加签	动态多实例、子任务或状态变更	加签类型、位置、权限和汇总规则
转办	setAssignee 或任务分配 API	目标校验、责任审计和数据权限
委托	delegateTask、resolveTask、owner	返回或直接继续的产品策略
传阅	独立任务、Identity Link 或平台记录	已读回执、阅读意见和非阻塞执行
抄送	Identity Link、事件与通知服务	可见权限、渠道、去重和回执

Camunda 8 User Task 也支持 assignee、candidateUsers、candidateGroups、assign、reassign、unassign 和任务生命周期监听器。这些是实现任务分配的基础，但“加签”“传阅”“抄送”等中国式语义仍应由平台定义。

引擎 API 只负责状态变化，业务操作服务还要负责授权、表单权限、通知、审计、重复点击和并发控制。

十三、平台应该保存怎样的操作记录

每次操作至少应记录：

• operationId、operationType 和发生时间；
• processInstanceId、taskId、activityId；
• operator、owner、原 assignee 和新 assignee；
• targetUsers、targetGroups 和人员解析快照；
• 操作前后的任务、执行和多实例摘要；
• reason、comment、附件和电子签名；
• 对会签分母、剩余任务和后续路径的影响；
• 通知发送、外部副作用和补偿结果；
• 调用来源、客户端、IP、租户和幂等键。

前端按钮名称可以调整，审计事件类型必须稳定。例如 TRANSFER、DELEGATE、RESOLVE_DELEGATION、ADD_BEFORE、ADD_AFTER、CIRCULATE、CC_NOTIFY 应有独立编码，不能都记成 UPDATE_TASK。

十四、设计器与任务中心应该怎样呈现

设计阶段应配置：

• 会签类型、通过规则、否决规则和提前结束策略；
• 或签采用候选一任务还是多任务抢答；
• 是否允许加签、转办、委托以及目标人员范围；
• 委托后返回 owner 还是直接继续；
• 传阅是否阻塞、是否要求确认；
• 抄送时机、可见字段和通知渠道。

运行阶段应展示：

• 当前操作会影响谁、取消哪些任务、是否改变会签分母；
• 转办后原办理人是否退出；
• 委托任务将返回谁；
• 传阅是否等待确认；
• 抄送人能查看哪些数据。

高风险操作应先生成影响预览，再要求填写原因并二次确认。失败时必须整体回滚，不能出现引擎状态已经改变、平台审计却没有写入的半成功状态。

十五、低代码工作流平台怎样统一这些能力

云程低代码开发平台可以在 Flowable 之上建立统一 Approval Operation Service：

• 将七类操作定义为稳定的领域命令；
• 用 Engine Adapter 把领域命令映射为 Flowable API；
• 用 Approval Policy 保存节点允许的操作及目标范围；
• 用 Task Center 统一展示办理、传阅和抄送；
• 用表单权限服务决定不同角色可见和可编辑字段；
• 用审计服务保存责任变化、任务快照和操作原因；
• 用通知服务处理站内信、uniAPP、钉钉和企业微信。

这样业务系统面对的是稳定的中国式工作流语义，而不是直接操作 TaskService 或引擎数据库表。