GFlow Engine v1.0.0 正式发布，并以 Apache-2.0 协议开源。它基于 RuleGo，定位是一个轻量级、可嵌入的审批工作流引擎：现有 Go 系统引入一个库、准备 7 张表，就能补上审批能力，不必再部署一套独立的流程中间件。
这解决的是 Go 生态里一个长期存在的工程问题。Java 开发者有 Flowable、Activiti，国产开源领域有 FlowLong，钉钉和飞书则提供 SaaS 审批能力；但对于希望把流程直接放进业务服务的 Go 团队来说，选择并不多。GFlow 的价值，正在于把“审批”变成应用内部可以组合和扩展的一部分。
从流程中间件到嵌入式能力
传统工作流平台通常以独立服务、流程设计器和运行时数据库的形式存在。它们适合复杂流程治理，但也会带来额外的部署、网络调用、权限同步和运维成本。
GFlow 采取了更轻的路径：把审批引擎作为 Go 库嵌入已有系统。业务服务可以继续使用自己的用户、组织、租户和权限模型，审批数据也可以落在当前应用的数据库中。对于已经运行多年的 ERP、OA、采购或人事系统，这种集成方式更容易控制改造范围。
“轻量级”并不意味着只支持一条固定的请假流程。根据发布摘要，GFlow 关注的是完整审批能力，包括中国式审批场景、AI 先审，以及审批结束后的自动执行。实际落地时，团队仍需要明确流程版本、节点权限、会签规则、抄送范围、撤回条件和业务动作的幂等性。
三个值得关注的能力
中国式审批
中国企业的审批并不只是“发起后依次点击同意”。常见规则包括直属领导、部门负责人、金额分级、指定审批人、多人会签、或签、加签、转交和抄送。流程还经常受到组织架构、岗位和数据权限影响。
因此，审批引擎的核心不只是节点编排，还要能把业务规则映射到具体人员。例如：采购金额低于 1 万元由部门负责人审批，超过 1 万元还需要财务负责人审批；请假流程则可能根据天数和员工所属部门选择不同路径。
AI 先审
“AI 先审”适合放在人工审批之前，承担材料检查、规则初筛和风险提示等工作。它可以先判断申请单是否缺少附件、金额是否超过常规范围、描述是否与申请类型匹配，再决定是直接进入人工节点，还是退回补充材料。
这里需要划清边界：AI 的判断结果应当是可追踪的审批输入，而不是不可解释的最终结论。生产系统需要记录模型版本、输入摘要、输出结果、置信度和人工覆盖操作。涉及报销、用工、付款等高风险场景时，建议保留人工确认节点。
批完自动办
审批结束后，系统往往还要执行真正的业务动作：生成采购订单、更新预算、创建合同、开通权限或发起付款。把这些动作接在流程结束事件之后，可以避免审批系统只停留在“记录状态”的层面。
自动办必须具备幂等性。一个审批完成事件可能因为重试、网络异常或消费者重启而被处理多次。业务动作应使用业务单号、审批实例 ID 或事件 ID 做唯一约束，不能简单地在回调里重复写入。
可以怎样嵌入 Go 服务
下面是一个最小化的集成示意。由于具体 API 以 GFlow v1.0.0 的实际仓库定义为准，示例中的包名和方法名采用清晰的伪接口，适合用来规划应用边界；接入时请替换为项目提供的真实 API。
假设现有服务已经有数据库连接、当前用户和业务单号，审批服务只负责创建实例，并通过完成事件触发后续动作：
package main
import (
"context"
"fmt"
)
type ApprovalEngine interface {
Start(ctx context.Context, req StartRequest) (string, error)
}
type StartRequest struct {
FlowKey string
BusinessID string
StarterID string
Payload map[string]any
}
func submitPurchase(ctx context.Context, engine ApprovalEngine, userID, purchaseID string, amount float64) error {
instanceID, err := engine.Start(ctx, StartRequest{
FlowKey: "purchase_request",
BusinessID: purchaseID,
StarterID: userID,
Payload: map[string]any{
"amount": amount,
"currency": "CNY",
},
})
if err != nil {
return fmt.Errorf("start approval: %w", err)
}
fmt.Printf("approval instance created: %s\n", instanceID)
return nil
}
func main() {
// Replace with the GFlow engine initialized from your application config.
var engine ApprovalEngine
_ = engine
}
真正接入时，可以把调用放在业务服务的应用层，而不是直接散落在 HTTP handler 中。业务表先创建“待审批”记录，再启动流程；审批完成事件消费成功后，使用事务或可靠消息机制更新业务状态。这样即使自动办暂时失败，也能通过重试和人工补偿恢复，而不会丢失审批结果。
数据库方面，发布摘要提到“建 7 张表”即可完成基础接入。可以按下面的职责检查数据库迁移是否覆盖完整能力，具体表名以 GFlow 的实现为准：
-- 以下是职责示意，不代表 GFlow v1.0.0 的固定表结构。
CREATE TABLE workflow_definition (
id BIGINT PRIMARY KEY,
flow_key VARCHAR(128) NOT NULL,
version INT NOT NULL,
status VARCHAR(32) NOT NULL,
definition_json TEXT NOT NULL,
UNIQUE (flow_key, version)
);
CREATE TABLE workflow_instance (
id BIGINT PRIMARY KEY,
flow_key VARCHAR(128) NOT NULL,
business_id VARCHAR(128) NOT NULL,
starter_id VARCHAR(128) NOT NULL,
status VARCHAR(32) NOT NULL,
created_at TIMESTAMP NOT NULL,
UNIQUE (flow_key, business_id)
);
这段 SQL 只展示流程定义和流程实例两类数据。完整设计通常还要覆盖节点任务、审批动作、参与人、抄送或通知，以及事件或操作日志等职责。不要直接照搬示例表结构到生产环境，应该以引擎迁移文件为准，并确认租户字段、索引、软删除策略和数据库类型。
落地时要把边界画清楚
GFlow 的嵌入式模式能降低部署复杂度，但也会让宿主应用承担更多责任。建议在采用前检查以下事项：
- 流程版本：已发起实例应绑定具体版本，不能因为管理员修改流程定义而改变历史审批路径。
- 组织同步：引擎需要知道用户、部门、岗位和上下级关系；同步失败时应有明确的降级或阻断策略。
- 权限隔离：多租户场景必须在流程定义、实例、任务和日志查询中统一注入租户条件。
- 自动执行：审批完成后的业务动作需要幂等键、重试次数、失败告警和人工补偿入口。
- AI 审核：保存 AI 结论和人工覆盖记录，避免把模型输出当作无法追溯的黑盒状态。
- 可观测性：至少记录实例创建、节点流转、审批人、动作、耗时和异常原因。
如果团队已经有 Go 业务系统，却不希望为了审批能力维护一套独立中间件，GFlow v1.0.0 值得作为一个嵌入式方案评估。它更适合从一个边界清晰的流程开始试点，例如采购申请或费用报销：先验证组织权限、流程版本和自动办的可靠性，再逐步扩展到复杂会签和 AI 预审。轻量接入只是起点，真正决定系统能否长期运行的，仍然是数据一致性、审计能力和失败后的恢复路径。