SkillFlow 流转控制体系 ——隐藏在流程之下的底层密码

面向企业级 SuperAgent 的流程驱动协作架构 — 从并行择优、串行抢占到底层 Split/Join，从动态决策到知识飞轮

OODER Studio · 基于流程的企业Agent架构（第三篇） · 2026-07-09

一、引言：为什么 Agent 需要流程

在单体 Agent 的世界里，"调用一个大模型 API → 返回结果"就是全部。但当 Agent 从单一工具进化为企业级 SuperAgent——需要协调多个子 Agent、接入多种知识源、遵守合规审批流、在并行推理中择优决策——"流程"就不再是可选项，而是骨架。

核心论点：流程即协作，流转即智能。SkillFlow 将工作流控制论与 Agent 自治能力深度融合，构建了一套"上层业务语义 → 底层控制原语 → 核心飞轮闭环"的三层架构，让 Agent 不再是无序的 API 调用链，而是有方向、有记忆、有合规的智能协作体。

SkillFlow 的三层架构可以这样理解：

🎯 上层应用模式

面向业务语义：并行择优、不同任务并行、串行抢占、顺序逐一、退回与收回

⚙️ 底层控制原语

面向执行语义：XOR/AND/COMPLEX 的 Split/Join、Transition 路由、NoMatchPolicy 容错

🔄 核心飞轮

面向智能语义：流程定义、动态决策、合规审计、自主执行、知识飞轮、上下文压缩

本文将从这三层出发，完整剖析 SkillFlow 的流转控制体系，并以 NLP 模块构建为实例，展示企业级 SuperAgent 的全貌。

二、上层应用模式 — 业务语义的流转控制

上层应用模式是业务开发者最直接接触的 API 面。它将底层 Split/Join 原语包装为业务友好的语义，开发者只需声明"我要并行择优"或"我要退回修改"，无需关心 XOR_SPLIT 还是 COMPLEX_SPLIT 的底层实现。

2.1 并行择优：同一任务多方案竞选

在企业级场景中，同一个任务往往有多种执行方案。例如一次"合同风险审查"，可以同时用 LLM 推理、规则引擎和 RAG 检索三种方式执行，各方案并行运行，最终由下游汇聚节点择优选取最佳结果。

并行择优的底层映射

分裂侧：ActivityDefinition.SplitMode.COMPLEX_SPLIT — 所有 condition 匹配的出边都走，即三个方案同时启动。 汇聚侧：下游 XOR_JOIN 排他汇聚 — 任一分支先到达即触发，后到的分支结果被丢弃。也可用 COMPLEX_JOIN 条件判定汇聚（如投票机制）来选取最优。 语义等价：并行择优 = COMPLEX_SPLIT（全走）+ 下游择优 JOIN。

// 并行择优：合同风险审查 — 三方案并行竞选
ActivityDefinition riskReview = ActivityDefinition.builder()
    .activityId("risk_review")
    .splitMode(SplitMode.COMPLEX_SPLIT)   // 所有匹配出边都走
    .build();

// 三个出边：condition 各自匹配不同方案
Transition t1 = Transition.of("risk_review", "llm_review",  "strategy=='llm'",  1);
Transition t2 = Transition.of("risk_review", "rule_review", "strategy=='rule'", 2);
Transition t3 = Transition.of("risk_review", "rag_review",  "strategy=='rag'",  3);

2.2 不同任务并行执行：AND_SPLIT 无条件并行

当多个独立任务需要同时执行时，使用 AND_SPLIT。关键实现在 handleAndSplit：将所有出边加入 activityQueue，同时调用 contextLayerManager.splitContext() 复制上下文到子活动。

分裂时的上下文策略至关重要，支持三种模式：

// handleAndSplit 核心逻辑
private void handleAndSplit(ActivityInstance current, List<Transition> outTransitions) {
    for (Transition t : outTransitions) {
        ActivityDefinition targetDef = resolveActivity(t.getTargetId());
        // 1. 上下文分裂：按6层语义规则复制上下文
        ContextSnapshot branchCtx = contextLayerManager.splitContext(
            current.getContext(), ContextStrategy.DEEP_COPY_WITH_BRANCH);
        // 2. 创建子活动实例
        ActivityInstance branchAct = createActivityInstance(targetDef, branchCtx);
        // 3. 加入队列并行执行
        activityQueue.add(branchAct);
    }
}

2.3 串行办理：单一抢占与顺序逐一

单一抢占 — XOR_SPLIT

XOR_SPLIT 排他分裂：按 priority 排序出边，第一个 condition 匹配的出边执行，其余丢弃。这是最常见的模式，对应"抢占锁"语义——谁先到谁执行，其他人无需等待。

// handleXorSplit：排他分裂 — 第一个匹配即走
private Transition handleXorSplit(ActivityInstance current, List<Transition> outTransitions) {
    List<Transition> sorted = outTransitions.stream()
        .sorted(Comparator.comparingInt(Transition::getPriority))
        .toList();
    for (Transition t : sorted) {
        if (evaluateCondition(t.getCondition(), current.getContext())) {
            return t;  // 第一个匹配即返回
        }
    }
    return handleNoMatch(current);  // 无匹配走 NoMatchPolicy
}

顺序逐一 — Priority 控制

通过 priority 控制执行顺序，activityQueue 按优先级逐一执行。典型场景：NLP 管道的 ic_rag_check → ic_classify → ic_generate 顺序执行。priority 越小越优先（默认 999），确保管道步骤按序推进。

2.4 退回与收回：BACKWARD 路由的可信回退

退回（BACKWARD）

Transition.Direction.BACKWARD 实现流程的回退。退回是执行方驳回——例如审核员将申请退回给提交人修改。handleBackwardTransition 的完整流程：

// handleBackwardTransition 核心逻辑
private void handleBackwardTransition(ActivityInstance current, Transition backward) {
    // 1. 保存当前上下文为历史快照
    contextLayerManager.archiveAsSnapshot(current.getContext());
    // 2. 恢复目标活动上下文
    ActivityInstance target = resolveActivity(backward.getTargetId());
    // 3. 重置状态为 PENDING
    target.setStatus(ActivityStatus.PENDING);
    // 4. addFirst 入队列优先执行
    activityQueue.addFirst(target);

    // 5. maxRetry 控制
    if (target.getRetryCount() >= backward.getMaxRetry()) {
        target.setRetryExceeded(true);
        // 重新评估 FORWARD 出边
        routeForwardTransitions(target);
    }
}

关键控制点：maxRetry 控制重试上限，归档后不允许回退。重试耗尽后设置 _retry_exceeded=true，重新评估 FORWARD 出边，避免死循环。

收回

与退回的区别——收回是发起方主动撤回（如用户撤回提交），退回是执行方驳回。在 SkillFlow 中，收回通过 PAUSED 状态 + 外部事件恢复实现：发起方暂停当前活动，等待自身决策后再恢复。

2.5 上层模式速查表

三、底层实现 — Split/Join 控制原语

底层控制原语是 SkillFlow 的执行引擎。它们不关心业务语义，只关心路由如何分裂、如何汇聚、如何容错。所有上层模式最终都映射到这组原语的组合。

3.1 XOR_SPLIT / XOR_JOIN：排他分裂与排他汇聚

图 1：Split/Join 模式图 — 三种分裂策略与三种汇聚策略

3.2 AND_SPLIT / AND_JOIN：并行分裂与并行汇聚

AND_SPLIT 所有出边同时走。handleAndSplit 将每个 target 加入队列，同时 splitContext 复制上下文。

分裂时 6 层上下文语义规则：

AND_JOIN 所有入边到达后才触发。代码：arrivedInEdges 计数器，arrived < inEdges.size() 则 continue 不执行。满足时 mergeContexts 融合各分支上下文。

合并时冲突检测策略：

3.3 COMPLEX_SPLIT / COMPLEX_JOIN：条件分裂与复杂汇聚

COMPLEX_SPLIT：按条件走子集，所有 condition 匹配的出边都走。与 XOR_SPLIT 的区别在于允许多条出边同时匹配，结合并行择优场景使用。

COMPLEX_JOIN：条件判定汇聚，如 n/m 条到达即可触发（投票机制）。例如 3 个审核分支中任意 2 个通过即可汇聚继续，无需等待全部。

3.4 Transition：路由驱动一切

Transition 是 SkillFlow 中路由驱动一切的核心抽象。它取代了传统工作流引擎中的 Gateway 和 Loop 特殊处理，所有控制逻辑统一由 Transition 承载。

public class Transition {
    private String transitionId;       // 唯一标识
    private String sourceId;           // 源活动ID
    private String targetId;           // 目标活动ID
    private String condition;           // 路由条件表达式
    private int priority;              // 优先级，越小越优先，默认999
    private Direction direction;       // FORWARD / BACKWARD
    private int maxRetry;              // 最大重试次数（BACKWARD专用）
    private long retryDelayMs;         // 重试延迟毫秒
    private String label;              // 显示标签

    public enum Direction { FORWARD, BACKWARD }
}

Direction 枚举替代了原 TransitionType，BACKWARD 替代了 LOOP_BACK，使语义更加直观。

3.5 NoMatchPolicy：无路由匹配时的容错策略

当所有出边的 condition 都不匹配时，NoMatchPolicy 决定流程如何继续：

3.6 六层上下文在分裂/合并中的语义规则

上下文语义规则总结

分裂时：SYSTEM/PROCESS 共享不复制（全局唯一），KNOWLEDGE/HISTORY 继承深拷贝（分支独立追踪），WORKING 深拷贝+注入 _branch（分支隔离），EPHEMERAL 独立初始化（临时数据重建）。 合并时：SYSTEM/PROCESS 直接引用（无冲突），KNOWLEDGE 按策略合并，HISTORY 按时间序拼接，WORKING 按 MergeStrategy 处理冲突，EPHEMERAL 丢弃（临时数据不跨活动）。 不变量：分裂-合并前后，SYSTEM 和 PROCESS 层内容保持一致；WORKING 层在合并后遵循所选 MergeStrategy 的语义保证。

四、核心层 — 定义、动态决策、合规审计、自主执行、知识飞轮

核心层是 SkillFlow 的"大脑"。它定义了流程的结构、决策的逻辑、合规的边界、执行的架构，以及让 Agent 越用越聪明的知识飞轮。

4.1 流程定义：ActivityDefinition + Transition + ProcessDefinition

SkillFlow 的流程定义是一个三元组：

// 最小执行单元
public class ActivityDefinition {
    private String activityId;
    private ActivityType type;          // TASK / LLM_AGENT / HUMAN_AGENT / SUB_PROCESS / END
    private JoinMode joinMode;          // XOR_JOIN / AND_JOIN / COMPLEX_JOIN
    private SplitMode splitMode;        // XOR_SPLIT / AND_SPLIT / COMPLEX_SPLIT
    private NoMatchPolicy noMatchPolicy; // FAIL / RETRY_LAST / SKIP / WAIT
    private boolean humanConfirmRequired; // 是否需要人工确认
    private String skillId;             // 关联的 Skill ID
}

// 流程定义
public class ProcessDefinition {
    private String processId;
    private List<SwimLane> swimLanes;          // 泳道定义
    private List<ActivityDefinition> activities;  // 活动集合
    private List<Transition> transitions;      // 转换集合
}

v3 核心变更

移除 Gateway/Loop 特殊处理 → 控制逻辑全部由 Transition 承载，Gateway 的分支语义下沉到 SplitMode/JoinMode，Loop 的回退语义由 BACKWARD Direction 表达。 移除 FailureStrategy → NoMatchPolicy + BACKWARD 替代，提供更精细的容错控制：NoMatchPolicy 处理"无路由匹配"，BACKWARD 处理"需要回退重试"。

4.2 动态决策：evaluateCondition 与 MVEL 条件表达式

evaluateCondition 遵循本地运算优先原则（对齐 CtBPMCacheManager 设计），所有条件计算在本地 SkillFlowEngine 中完成，无需远程调用。

支持三种条件表达式：

关键同步机制：XOR_SPLIT / COMPLEX_SPLIT 执行后，将 output["branch"] 同步到 context["_branch"]，供后续活动的条件匹配使用。这确保了决策的因果链——前一步的分支选择可以被后一步的条件引用。

4.3 合规审计：HUMAN_AGENT 节点与 humanConfirmRequired

HUMAN_AGENT 活动类型 + humanConfirmRequired 标志构成了 SkillFlow 的人在回路（Human-in-the-Loop）设计模式。

🔒 HUMAN_AGENT

活动类型，强制要求人工介入。流程执行到此节点时自动暂停，等待人工确认后继续

🔑 humanConfirmRequired

标志位，可附加到任意 ActivityType 上，表示该活动需要人工确认才能继续

⏱️ FC-Loop 确认

在 NLP 场景中，每轮 Function Call Loop 需 human_confirm 确认。confirmId 预注入 + SSE 转发 + 180s 超时

4.4 自主执行：McpAgentNode 分布式自治与本地优先架构

McpAgentNode 是分布式自治 Agent 节点，遵循"注册 → 激活 → 登录 → 上报 Skills → 加入 SceneGroup"的生命周期：

// McpAgentNode 分布式自治生命周期
public class McpAgentNode {
    // 注册：向 aiserver 注册自己
    void register(AgentRegistration reg);
    // 激活：本地初始化 SkillFlowEngine
    void activate();
    // 登录：获取 Token 建立会话
    void login();
    // 上报 Skills：声明可执行的 Skill 列表
    void reportSkills(List<SkillInfo> skills);
    // 加入 SceneGroup
    void joinSceneGroup(String sceneGroupId);

    // 心跳保活 → 资源上报 → 远程 Skill 安装/卸载
    void heartbeat();
}

架构原则：本地运算 + 远程持久化

• SkillFlowEngine 执行所有流程逻辑（evaluateCondition / routeTransitions / executeActivity）——本地运算
• aiserver 持久化流程状态（newProcess / routeTo / completeProcessInst / vfsSave）——远程持久化
• 两者通过 RemoteWorkflowBridge 连接，localToRemoteInstId / localToRemoteActInstId 映射本地实例到远程实例

4.5 知识飞轮：生产→入库→消费→反馈 四阶段闭环

知识飞轮是 SkillFlow 区别于传统工作流引擎的核心创新。它让 Agent 在每次流程执行中自动学习，形成"越用越聪明"的闭环。

图 2：知识飞轮闭环图 — 生产→入库→消费→反馈 四阶段环形

四阶段详细说明：

4.6 上下文压缩：ContextCompressor 的 LLM 增强压缩

随着流程执行推进，上下文不断膨胀。ContextCompressor 对活动上下文进行 LLM 增强压缩：

public class ContextCompressor {
    // 压缩活动上下文为历史摘要
    String compressActivityContext(ActivityContext ctx, CompressionStrategy strategy);
    // 构建完整上下文（含压缩摘要）
    FullContext buildFullContext(ProcessInstance inst);
    // 支持压缩策略和摘要缓存
    void setStrategy(CompressionStrategy strategy);
    void enableSummaryCache(boolean enabled);
}

压缩策略包括：保留最近 N 条、LLM 摘要压缩、关键节点保留等。通过摘要缓存避免重复压缩，提升性能。

五、企业级 SuperAgent 架构 — 以 NLP 构建模块为例

以 NLP 模块构建为例，完整展示 SkillFlow 如何将一个真实业务场景映射为流程驱动的多智能体协作架构。

5.1 NLP 模块构建的完整流程定义

图 3：NLP 模块构建流程图 — 完整的条件路由与退回机制

5.2 意图分类步骤的流转控制

IntentClassificationStep 内部使用 NlpStepWorkflow 实现 DAG，支持：

• inCurrentPage 判断：检测意图是否在当前页面组件中可直接匹配
• RAG 知识库命中：ic_rag_check 查询 RAG 知识库，命中则走 ic_classify，未命中则跳过分类直接生成
• 降级处理：当 RAG 和分类都不可用时，走 ic_llm_generate 兜底
• LLM 兜底：最终由 LLM 完成意图分类或生成

PipelineStepAdapter 将 PipelineStep 适配为 SkillFlow Activity，使 NLP 管道与 SkillFlow 引擎无缝对接。

5.3 多智能体协作的泳道设计

不同泳道代表不同 Agent 角色：

泳道间通过 AND_SPLIT 并行、XOR_SPLIT 排他选择。例如 RAG 检查和 LLM 分类可以在不同泳道并行执行，最终在 ic_human_review 处汇聚。

5.4 子流程嵌套与场景组合

ActivityType.SUB_PROCESS 引用嵌套 ProcessDefinition，实现场景组合。例如 NLP 构建可嵌套 Designer 设计子流程：

// 子流程嵌套示例
ActivityDefinition designerStep = ActivityDefinition.builder()
    .activityId("ic_designer_hit")
    .type(ActivityType.SUB_PROCESS)
    .skillId("designer-sub-process")  // 引用嵌套流程定义
    .splitMode(SplitMode.XOR_SPLIT)
    .build();

// 嵌套的子流程定义
ProcessDefinition designerSubProcess = ProcessDefinition.builder()
    .processId("designer-sub-process")
    .activities(designerHit, designerRender, designerReview)
    .transitions(d2r, r2v)
    .build();

5.5 分布式执行与远程持久化

图 4：分布式执行架构图 — SkillFlowEngine + RemoteWorkflowBridge + McpAgentNode + aiserver

分布式执行的核心设计原则：

• 本地队列驱动：每个 McpAgentNode 内部维护 activityQueue，本地驱动执行
• 远程状态持久化：关键状态变更通过 RemoteWorkflowBridge 同步到 aiserver
• 映射一致性：localToRemoteInstId / localToRemoteActInstId 保证本地实例与远程实例一一对应
• 断线重连：RemoteWorkflowBridge 支持断线重连 + 幂等保证，确保状态不丢失

六、架构全景图：三层映射与核心不变量

图 5：SkillFlow 三层架构全景图与核心不变量

核心不变量

七、结语：流程是 Agent 的骨架，飞轮是 Agent 的记忆

SkillFlow 的设计哲学可以浓缩为一句话：流程是 Agent 的骨架，飞轮是 Agent 的记忆。

骨架：没有流程的 Agent 是无序的 API 调用链——不知道先做什么后做什么，不知道何时并行何时串行，不知道遇到异常如何回退。SkillFlow 的三层流转控制为 Agent 装上了骨架：上层业务语义让开发者声明意图，底层控制原语精确执行，核心层确保决策有据可查、合规有迹可循。 记忆：没有飞轮的 Agent 是无状态的单次执行——每次都从零开始，不会从历史中学习，不会因反馈而进化。知识飞轮让 Agent 在每次流程执行中自动生产知识、入库归档、消费注入、反馈修正，形成"越用越聪明"的正向循环。

SkillFlow 的三层架构与核心不变量，共同定义了企业级 SuperAgent 的协作范式：

🔀 流程即协作

并行择优、串行抢占、退回重试——流转控制就是协作协议

🧠 流转即智能

动态决策、知识飞轮、上下文压缩——流转过程就是学习过程

🛡️ 合规即信任

人在回路、审计日志、退回上限——合规保证让 Agent 可信

🌐 分布即弹性

本地运算+远程持久化、McpAgentNode 分布式自治——架构弹性支撑规模

从上层应用到底层实现再到核心飞轮，SkillFlow 构建了一套完整、自洽、可演进的流程驱动协作架构。它不是传统工作流引擎的简单移植，而是为 Agent 时代重新设计的协作基础设施——让流程成为 Agent 的骨架，让飞轮成为 Agent 的记忆，让每一个 SuperAgent 都能在流程中协作、在流转中进化。

SkillFlow 流转控制体系 · OODER Studio · 基于流程的企业Agent架构（第三篇）