审批系统真正难处理的，通常不是画出几个流程节点，而是把现实中的组织规则准确落地：多人会签、任一人通过即可的或签、临时加签、转办、委派、签收抢单，以及退回、撤回和超时催办。GFlow v1.2.0 的价值在于，它试图把「提交申请 → 逐级审批 → 批后执行」放进同一条可运行的业务链路，并进一步加入 AI 预审与自动化能力。
它解决的不只是流程流转
很多业务系统最初只有一张申请表和一个 status 字段：待审批、已通过、已拒绝。需求稍微复杂后，这种设计很快失效。
例如，一笔采购申请可能需要部门负责人审批；金额超过 5 万元时追加财务审批；超过 20 万元时再加入分管负责人；财务节点要求两人会签；审批人休假时允许委派；全部通过后还要创建采购单并通知执行人员。
这里实际包含三类不同问题：
- 流程决策：下一步由谁审批，走会签还是或签，什么条件触发额外节点。
- 人工协作：转办、委派、加签、退回、撤回、签收和超时催办。
- 业务执行：审批完成后创建订单、更新台账、发送通知或调用外部系统。
GFlow 覆盖的「中国式审批」语义，重点正是第二类问题。它们看似只是操作按钮，背后却涉及任务所有权、审批意见、节点完成条件、代理关系以及完整的审计记录。把这些逻辑散落在各个业务服务里，后续维护和追责都会很困难。
AI 应放在预审层，而不是绕过责任链
AI 审批最适合承担材料检查、风险提示和意见草拟，而不是在缺少边界的情况下直接替代责任人。
以费用报销为例，AI 可以在人工审批前完成这些工作：
- 检查发票金额与申请金额是否一致。
- 识别缺失的合同、行程单或付款依据。
- 根据制度文本提示可能违反的报销规则。
- 汇总异常点，为审批人生成结构化摘要。
- 对低风险、规则明确的申请给出自动处理建议。
生产环境仍应区分「建议」和「决定」。涉及高金额、敏感权限、对外付款或模型置信度不足的申请，需要进入人工节点。AI 的输入、模型版本、输出结果、引用规则和最终处理人也应写入审计记录，避免日后只能看到一句无法解释的“AI 已通过”。
可以采用如下分级策略：
| 风险等级 | AI 行为 | 后续处理 |
|---|---|---|
| 低风险 | 校验材料并提出通过建议 | 满足确定性规则后自动执行或抽样复核 |
| 中风险 | 生成摘要与风险清单 | 必须由业务负责人确认 |
| 高风险 | 只做信息抽取和提示 | 进入多级人工审批，不允许自动批准 |
从审批完成到业务真正办结
“审批通过”只是流程状态，不代表业务已经完成。采购申请通过后要生成采购单，账号申请通过后要创建权限，付款申请通过后要提交财务系统。若这些动作依靠员工查看消息后手工执行，审批平台只是把等待从一个队列转移到了另一个队列。
批后自动化应设计为可观测、可重试的业务任务。一个稳妥的执行链路通常包括：
- 工作流完成后发布带有业务键的完成事件。
- 自动化服务根据业务键执行创建订单、授权或通知等动作。
- 外部调用使用幂等键，避免重试产生重复订单或重复付款。
- 失败任务进入重试队列，超过阈值后转人工处理。
- 执行结果回写流程实例，形成从申请到办结的完整审计链。
下面是一个可改造的 Webhook 消费端示例。由于摘要没有给出 GFlow v1.2.0 的具体接口路径与事件字段，示例假设审批完成后会向业务服务发送 HTTP 请求；接入时需要按实际文档替换字段和鉴权方式。
# app.py
from flask import Flask, jsonify, request
app = Flask(__name__)
processed = set() # 演示用途；生产环境应改为带唯一约束的数据库表
@app.post("/webhooks/approval-completed")
def approval_completed():
event = request.get_json(force=True)
required = {"event_id", "instance_id", "business_key", "result"}
missing = required - event.keys()
if missing:
return jsonify(error=f"missing fields: {sorted(missing)}"), 400
if event["event_id"] in processed:
return jsonify(status="duplicate_ignored"), 200
if event["result"] != "approved":
return jsonify(status="no_action"), 200
# 可以替换为创建采购单、开通账号或调用财务系统。
print(
"execute approved request:",
event["business_key"],
"workflow:",
event["instance_id"],
)
processed.add(event["event_id"])
return jsonify(status="completed"), 200
if __name__ == "__main__":
app.run(host="0.0.0.0", port=8080)
安装并启动：
python -m venv .venv
. .venv/bin/activate
pip install Flask
python app.py
再用一条测试请求验证批后动作：
curl -X POST http://127.0.0.1:8080/webhooks/approval-completed \
-H 'Content-Type: application/json' \
-d '{
"event_id": "evt-20250101-001",
"instance_id": "flow-8421",
"business_key": "purchase-2025-0007",
"result": "approved"
}'
这个示例只演示接口边界。正式实现至少还需要签名校验、持久化幂等记录、事务或 Outbox、失败重试、超时控制以及敏感字段脱敏。对于付款等高风险动作，还应把“审批通过”和“允许执行”设计成两个独立条件。
接入前应确认的工程边界
评估 GFlow v1.2.0 时，不要只检查流程设计器能否画出目标流程，还要用真实异常场景验证运行时行为：
- 会签人员发生变化时，已经产生的任务如何处理。
- 转办与委派是否保留原审批人的责任链和操作记录。
- 退回后是回到上一节点、指定节点，还是重新执行后续节点。
- 撤回与外部自动化并发发生时，如何避免已经执行的业务动作失控。
- 催办是否支持升级通知、工作日历和节假日计算。
- AI 建议能否追溯模型、提示词、制度版本和人工确认结果。
- 自动化失败后是否可重试、补偿、人工接管并查询执行状态。
更稳妥的落地方式，是先选择一条规则明确、风险可控且批后动作容易回滚的流程，例如内部账号申请或普通采购申请。先验证审批语义、权限、审计和幂等执行，再逐步接入付款、合同与敏感权限审批。这样才能判断 GFlow 带来的究竟是流程可视化，还是一条真正闭环、可治理的业务执行链。