审批系统需求写了会签和或签，Agent 怎样整理人数变化与完成条件

“会签”“或签”在不同系统里可能承载不同规则。Agent应先记录参与集合如何取得、任务顺序和完成条件，再用人员变化、同时意见和顺序冲突提出具体问题。产物是审批软件的规格评审材料，不是替任何真实申请作审批决定。

名称后面至少有三个独立决定

第一是集合：哪些人参与，在进入节点时固定，还是随后随组织变化调整。第二是顺序：一人完成后才交下一人，还是并行处理。第三是完成条件：全部、任一、某个阈值，或者包含特定否决意见。仅写“会签”并不能让开发方推断这些决定。

需求还要说明意见与完成的关系。完成条件满足以后，剩余任务如何展示，已经形成的意见是否仍保留，迟到的意见能否改变本次结果，都需要产品定义。把它们放在一列状态里，会让实际含义难以追踪。

官方机制说明1：多实例可顺序或并行，inputCollection与completionCondition决定实例集合和完成条件。

多实例机制可表达集合、顺序或并行及完成条件，但具体人员变更和业务权限仍来自企业安排。本文只借用这些对象，讨论“怎样写清”，不声称所列草案已经在某个流程引擎运行。

合成输入1。 三个窗口并行会签，要求全部同意，但一人离职后如何处理未写

预期处置：保留原集合与缺员问题，不自动减少分母

合成输入2。 两人或签，一人同意同时另一人补充意见

预期处置：列完成条件、终止剩余任务与意见保留待定

合成输入3。 先主管后资产管理员，两步被原型画成并行

预期处置：指出顺序语义冲突并附两条事件顺序

缺员例中，若原集合为三人，“全部同意”分母不能被助手悄悄改成两人。需要负责人决定替补、退回还是保留待办，并明确旧意见去向。或签例则要说明完成瞬间之后的未完任务，不能只看到一个同意就把其他人的资料删掉。顺序例要求确认原型并行图是否与文字相反，保留两种执行顺序供评审。

集合表记录每个参与者由哪条规则进入、承担何种角色、是否可替补。事件表记录收到意见、改变集合、满足条件和结束节点的候选顺序。两张表共用节点标识，产品人员可以逐步说明每一时刻期待什么，而不必直接解释引擎表达式。

如果人数阈值以比例表达，还要确认分母来自初始人数还是当前有效人数。本文案例只讨论三人全部、两人任一和两步顺序，不预设企业采用某个比例。新增阈值时应补完整输入和明确条件，再进入附件，不能正文随口扩展。

人工回放时，先固定输入集合，再按事件顺序填写预期节点变化，实际结果留空。若一次人员变动改变了完成条件，报告应保留批准依据和受影响的节点，不让旧记录被新组织名单覆盖。

已存在审批平台时，可以优先使用其配置与导出能力。定制助手负责把业务口头称谓转为集合和事件问题，并输出可批准的草案；平台具体支持什么，再按目标版本核实。这样产品决定、配置实现和真实审批各有明确交接点。

三人会签案例中，原参与集合与后来缺员事实应分别保存。只留下当前两人名单，读者无法解释为什么此前一直等待第三份意见。或签案例要保留先后意见和条件满足的候选时刻，才能讨论余下任务是否结束以及意见怎样归档；并不是收到第二条意见就覆盖第一条。

顺序审批还可以把两步标成主管步骤和资产步骤，明确第二步的前置是第一步完成，而非两张任务同时出现。产品批准这种关系后，实施人员才可选择对应机制。现成流程引擎能够表达某种顺序，不证明本次配置已经采用；附件把规格决定、拟配置和实际观察分开，方便后续交接时逐项核实。

下载本题合成输入与可填写工作表。附件保留实际结果、复核人和证据位置空栏。