:fire:Star 6.3k 支持 AI 工作流引擎 FlowLong 1.2.6 发布

{"title_zh":"FlowLong 1.2.6：让 AI 工作流编排更接近可落地的流程引擎","body_zh":"# FlowLong 1.2.6：让 AI 工作流编排更接近可落地的流程引擎\n\n开源工作流引擎 FlowLong 发布 1.2.6。这个版本的重点不在于增加一个孤立的节点类型，而在于让流程在条件判断、实例恢复和人工审批之间形成更完整的闭环。对于正在把 AI 任务接入业务流程的团队，这些变化直接关系到流程能否处理真实世界中的分支、退回和重试。\n\n## 无节点条件执行：把“是否需要处理”交给流程\n\n新版本支持无节点条件执行能力。传统流程通常需要显式放置一个条件节点，再为每条分支连接后续任务；但在某些场景中，条件本身只决定路径是否成立，并不需要产生一个可见的业务任务。\n\n例如，订单风控可以直接判断风险等级：低风险订单继续支付，高风险订单进入人工复核。这样可以减少仅用于“占位”的临时节点，让流程图更贴近业务语义。\n\n在 AI 工作流中，这类能力尤其适合以下判断：\n\n- 模型置信度是否达到自动执行阈值；\n- 文档是否需要人工复核；\n- 工具调用是否应该继续重试；\n- 当前输入是否满足进入下一阶段的条件。\n\n不过，条件执行并不意味着可以省略审计信息。生产环境仍然应该记录条件表达式、输入快照、判定结果和执行时间，否则出现误分支时很难定位原因。\n\n## 结束实例的恢复：为审批流程保留纠错入口\n\n1.2.6 新增了对“重审已结束的流程实例”的支持：恢复实例后，当前任务可以退回发起人，进入暂存待审状态。\n\n这解决了审批系统中一个常见问题：流程已经结束，但业务人员随后发现附件、金额或审批意见有误。过去通常只能重新创建流程，既破坏了原始上下文，也增加了数据重复和审计困难。现在可以在原实例上恢复处理，让修改后的内容继续沿着已有流程运行。\n\n使用这项能力时，需要明确区分三种状态：\n\n1. 流程实例状态：是否已经结束、是否被恢复；\n2. 当前任务状态：是否退回发起人、是否暂存；\n3. 业务数据版本：恢复前后的表单和附件分别是什么版本。\n\n恢复流程不是简单地把状态改成“处理中”。建议为每次恢复记录操作者、原因、原结束时间和业务数据版本，并限制恢复权限，避免它变成绕过审批规则的后门。\n\n## 临时节点优化与依赖升级\n\n更新日志还包含临时节点优化，以及 MyBatis-Plus 升级到 3.5.17。前者关系到动态流程或运行时生成任务的稳定性，后者则会影响 ORM 行为、SQL 生成和依赖兼容性。\n\n升级前应重点检查：\n\n- 项目是否锁定了 MyBatis、MyBatis-Spring 或数据库驱动版本；\n- 自定义拦截器和分页配置是否依赖旧版行为；\n- 流程状态更新是否在事务边界内完成；\n- 旧流程实例能否在新版本代码下继续读取和恢复。\n\n不要只验证“新流程能启动”。工作流系统的风险往往藏在历史实例、异常重试和跨节点事务中。\n\n## 一个可改造的 AI 审批流程示例\n\n下面是一个简化的伪配置，用来表达“模型判断后决定自动通过还是转人工”的流程。具体字段名需要根据项目当前版本的 DSL 或 Java API 调整；示例中的条件语义可以直接映射到实际实现。\n\nyaml\nworkflow:\n id: contract-review\n version: 1\n start: extract\n nodes:\n - id: extract\n type: ai-task\n action: extract_contract_fields\n output: review_result\n\n - id: auto-approve\n type: service-task\n condition: "review_result.confidence >= 0.95 && review_result.risk == 'low'"\n action: approve_contract\n\n - id: human-review\n type: user-task\n condition: "review_result.confidence < 0.95 || review_result.risk != 'low'"\n assignee: legal-team\n\n transitions:\n - from: extract\n to: auto-approve\n - from: extract\n to: human-review\n\n\n运行前需要把 extract_contract_fields 替换为实际的模型服务调用，把 approve_contract 替换为业务系统 API，并确认条件表达式的语法与 FlowLong 的配置方式一致。更稳妥的做法是先用固定 JSON 结果测试两条分支，再接入真实模型。\n\n如果流程需要支持人工修改后重新提交，可以把恢复动作设计为一个受控运维接口：\n\nbash\ncurl -X POST 'http://localhost:8080/api/flow/instances/contract-20250308/reopen' \\\n -H 'Authorization: Bearer ${TOKEN}' \\\n -H 'Content-Type: application/json' \\\n -d '{\n "reason": "补充合同附件并重新审核",\n "returnTo": "initiator",\n "businessVersion": 2\n }'\n\n\n接口上线前应补充幂等键、权限校验、操作日志和并发控制。示例接口仅表示一种集成方式，实际路径和请求字段以项目 API 为准。\n\n## 是否值得升级\n\n如果团队正在使用 FlowLong 构建包含模型调用、条件分支和人工审批的流程，1.2.6 的价值主要体现在流程可恢复性和分支表达能力。升级可以按以下顺序推进：\n\n- 在测试环境导入一批真实历史实例，验证读取和恢复；\n- 为无节点条件执行补充分支覆盖测试；\n- 检查 MyBatis-Plus 3.5.17 与现有插件、驱动的兼容性；\n- 对临时节点、异常重试和事务回滚做集成测试；\n- 上线前保留数据库备份和可回滚版本。\n\nFlowLong 1.2.6 更适合被看作一次面向复杂流程的可靠性增强。AI 只负责提供判断或动作建议，流程引擎仍然需要承担状态管理、权限控制、审计和恢复责任。把这几层职责分开，才能让自动化流程在遇到低置信度、人工纠错和历史数据时仍然可控。","title_en":"FlowLong 1.2.6 Makes AI Workflow Orchestration More Production-Ready","body_en":"# FlowLong 1.2.6 Makes AI Workflow Orchestration More Production-Ready\n\nThe open-source workflow engine FlowLong has released version 1.2.6. The important changes are not limited to another node type: the release improves how workflows handle conditional routing, recovery of completed instances, and human review. For teams connecting AI tasks to business processes, these capabilities determine whether a workflow can survive real-world exceptions, corrections, and retries.\n\n## Conditional Execution Without a Dedicated Node\n\nThe new release supports conditional execution without requiring a visible node for every decision. In a conventional diagram, a team might add a condition node and connect each branch to a later task. In many cases, however, the condition only selects a path and does not represent a business task of its own.\n\nA risk-control flow can, for example, send low-risk orders directly to payment while routing high-risk orders to manual review. Removing placeholder nodes makes the diagram closer to the actual business meaning.\n\nThis is useful in AI workflows when deciding whether:\n\n- a model confidence score is high enough for automation;\n- a document requires human review;\n- a tool call should be retried;\n- an input is eligible for the next stage.\n\nThe absence of a visible node should not mean the absence of audit data. Production systems should still record the expression, input snapshot, result, and evaluation time.\n\n## Reopening Completed Instances\n\nFlowLong 1.2.6 adds support for reopening a completed process instance and returning the current task to the initiator as a saved, pending-review task.\n\nThis addresses a familiar approval-system problem: a process has finished, but someone later discovers an incorrect attachment, amount, or approval comment. Recreating the process loses context and can produce duplicate business records. Reopening the original instance keeps the existing history and lets the corrected data continue through the workflow.\n\nTreat reopening as a controlled state transition rather than a generic status update. Track the operator, reason, original completion time, and business-data version. Also restrict the permission, because an unrestricted reopen operation could become a way to bypass approval policy.\n\n## Temporary Nodes and the ORM Upgrade\n\nThe release also includes optimizations for temporary nodes and upgrades MyBatis-Plus to 3.5.17. Temporary-node behavior affects dynamic workflows and runtime-generated tasks. The dependency upgrade may affect ORM behavior, SQL generation, pagination, and custom interceptors.\n\nBefore upgrading, verify locked versions of MyBatis, MyBatis-Spring, and database drivers. Test custom interceptors, transaction boundaries, historical instances, exception retries, and workflows created by older application versions. A successful new-process smoke test is not enough for a stateful workflow platform.\n\n## A Practical AI Review Workflow\n\nThe following pseudo-configuration expresses a common pattern: an AI extraction task chooses between automatic approval and manual review. Replace the field names with the DSL or Java API used by the target FlowLong version.\n\nyaml\nworkflow:\n id: contract-review\n version: 1\n start: extract\n nodes:\n - id: extract\n type: ai-task\n action: extract_contract_fields\n output: review_result\n\n - id: auto-approve\n type: service-task\n condition: "review_result.confidence >= 0.95 && review_result.risk == 'low'"\n action: approve_contract\n\n - id: human-review\n type: user-task\n condition: "review_result.confidence < 0.95 || review_result.risk != 'low'"\n assignee: legal-team\n\n transitions:\n - from: extract\n to: auto-approve\n - from: extract\n to: human-review\n\n\nBefore running it, replace extract_contract_fields with the real model-service call and approve_contract with the business API. Confirm that the condition syntax matches the actual FlowLong integration. Start with fixed JSON fixtures covering both branches before connecting a live model.\n\nA controlled reopen operation could be integrated through an internal endpoint like this:\n\nbash\ncurl -X POST 'http://localhost:8080/api/flow/instances/contract-20250308/reopen' \\\n -H 'Authorization: Bearer ${TOKEN}' \\\n -H 'Content-Type: application/json' \\\n -d '{\n "reason": "Add the missing contract attachment and review again",\n "returnTo": "initiator",\n "businessVersion": 2\n }'\n\n\nThis endpoint is an integration example, not a claim about a fixed API path. A production implementation should add an idempotency key, authorization checks, audit logging, and concurrency control.\n\n## Upgrade Checklist\n\nFor teams building AI-assisted workflows, version 1.2.6 is most relevant when conditional routing, human correction, and historical-instance recovery are part of the product. A sensible rollout sequence is:\n\n- import representative historical instances into a test environment;\n- add branch-coverage tests for conditional execution;\n- verify MyBatis-Plus 3.5.17 with existing plugins and drivers;\n- run integration tests for temporary nodes, retries, and transaction rollback;\n- keep a database backup and a rollback-capable application version for deployment.\n\nFlowLong 1.2.6 is best understood as a reliability improvement for more complex workflows. AI can provide a decision or action suggestion, but the workflow engine remains responsible for state, permissions, auditability, and recovery. Keeping those responsibilities explicit is what makes automation controllable when confidence is low, a reviewer changes the data, or an old process needs to be reopened.","seo_description_en":"FlowLong 1.2.6 improves AI workflow routing, completed-instance recovery, temporary nodes, and MyBatis-Plus compatibility."}