工作流驱动智能体架构中的场景定义、编排与执行深度解析

在 Workflow-Driven Agent 架构中，"场景"（Scene）是一个核心但常被忽视的抽象概念。它既不是传统 Workflow 中的业务流程，也不是 LLM 应用中的单纯对话上下文，而是介于两者之间的结构化执行单元——拥有独立的生命周期、可编排的活动链路、受控的上下文边界和自适应的执行策略。本文以 OODER 框架的场景模型为蓝本，深入解析场景的定义、组织、调度与执行机制，揭示 Workflow-Driven Agent 中场景模型的设计哲学与工程实践。

一、场景模型的起源与设计哲学

1.1 从 Workflow 到 Agent：场景的诞生

传统 Workflow (Business Process Management) 以流程为中心，强调固化、可预测的路径。而 LLM Agent 以对话为中心，强调灵活、动态的响应。OODER 的场景模型试图在这两者之间找到平衡点——它不是单纯的 Workflow 流程，因为节点可以是 LLM 调用，路由可以动态计算；也不是单纯的对话，因为对话被结构化为阶段、活动、转换的清晰层次。它是可编排的 Agent 执行单元，每个场景定义一个完整的 Agent 行为模式。

Workflow 流程 → OODER 场景模型 → LLM Agent 对话：三者定位与演进关系

1.2 路由驱动架构 (Route-Driven Architecture)

OODER 场景模型最核心的设计决策是路由驱动。不同于传统流程引擎中"网关+条件"的显式控制模式，路由驱动架构将控制逻辑全部下沉到 Transition 中：

• 活动是无状态的：每个 Activity 只负责执行自己的职责，不关心前后节点
• 路由是控制中心：Transition 承担了条件判断、分支路由、循环控制、降级处理等全部控制逻辑
• 策略是可插拔的：noMatchPolicy（SKIP / WAIT / RETRY / ESCALATE_HUMAN）定义了无匹配路由时的兜底策略
• 优先级是排序依据：路由按 priority 排序，priority=1 的默认路由确保永远不会出现死锁

路由驱动执行模型：Activity → Transition 匹配 → 目标 Activity

1.3 场景 vs 流程 vs 任务

二、场景模型的四层架构

OODER 的场景模型采用清晰的四层架构，从定义到执行层层递进：

场景模型四层架构：场景层 → 执行层 → 注册层 → 定义层

2.1 定义层 (Definition Layer)

定义层是整个场景模型的基石。所有场景定义以 JSON 文件形式存储在 VFS (Virtual File System) 中，通过 flow-registry.json 索引管理。核心模型类包括：

• ProcessDefinition：顶层流程编排模型，包含 definitionId、phases、swimLanes、activities、transitions、knowledgeBindings、guardConfig、contextLoadPolicy 等
• ActivityDefinition：最小执行单元，支持 6 种类型：TASK / LLM_AGENT / AGENT_EVENT / HUMAN / SUB_PROCESS / END
• PhaseDefinition：阶段定义，支持 5 个标准阶段：UNDERSTAND / PLAN / DESIGN / INTEGRATE / DEPLOY
• Transition：路由转换定义，包含 condition、direction (FORWARD/BACKWARD)、priority、maxRetry

2.2 注册层 (Registry Layer)

注册层负责将定义层的 JSON 文件加载到运行时内存中。VfsFlowDefinitionLoader 在应用启动时读取 VFS 目录下的所有定义文件，解析为 Java 对象，注册到 ProcessDefinitionRegistry。关键设计包括：

• 热加载：支持运行时重新加载，变更定义文件后无需重启
• 双注册：同时注册到本地内存和远程 Workflow 引擎，支持跨节点执行
• 校验：注册时校验定义完整性（活动引用、路由死锁、阶段完整性）

2.3 执行层 (Execution Layer)

执行层是场景模型的核心引擎。SkillFlowEngine 实现了路由驱动的流程执行：

1. 接收 startExecution(flowDefinitionId, context) → 创建 ProcessInstance
2. 查找 START 活动 → 执行
3. 活动执行完成后，遍历所有 sourceId = currentActivity 的 Transition
4. 按 priority 排序，匹配 condition，第一个匹配的走该路由
5. 无路由匹配 → 触发 noMatchPolicy
6. AND_SPLIT：所有出边同时走（并行执行）
7. AND_JOIN：所有入边到达后才触发
8. BACKWARD 路由：重置目标活动状态为 PENDING，检查 maxRetry

2.4 场景层 (Scene Layer)

场景层是面向用户的接口层。ChatScene 接口体系提供用户交互入口：

• IntentDispatchScene：新对话的意图分发入口，通过 LLM 分类匹配目标场景
• RadChatScene：RAD 设计场景，处理组件设计任务
• GeneralChatScene：通用问答场景，无特定流程的对话

三、场景定义的核心 Schema

3.1 Flow Registry 注册表

flow-registry.json 是场景定义的中心索引，包含 32 个流程定义。每个流程条目通过 classification + phase + businessCategory 三维分类，提供运行时路由所需的所有元数据：

{
  "flowId": "intent-dispatch",
  "name": "意图分发流程",
  "classification": "INTENT_DISPATCH",
  "phase": "DISPATCH",
  "businessCategory": "CORE",
  "workMode": "all",
  "sceneId": null,
  "parentFlowId": null,
  "isDispatchFlow": true,
  "isFirstRound": true,
  "definitionPath": "process-def/intent-dispatch/definition.json"
}

3.2 Activity Definition 活动定义

活动是场景的最小执行单元。支持的类型体系：

3.3 Transition 路由转换

路由是场景的控制核心。每个 Transition 定义条件表达式、优先级、方向和重试机制：

{
  "transitionId": "t_rag_hit",
  "sourceId": "ic_rag_check",
  "targetId": "ic_apply_workmode_filter",
  "condition": "hit",
  "direction": "FORWARD",
  "priority": 999
}

关键设计：priority=1 的默认路由确保流程永远不会死锁。BACKWARD 方向配合 maxRetry 实现回退重试机制，防止无限循环。

3.4 Guard 守卫配置

守卫配置是场景的"安全护栏"，防止 Token 爆炸和死循环。三级防护体系：

• 流程级：maxLlmRounds（100）、maxTotalTokens（500000）、maxBackwardCount（3）
• 活动级：fcLoopMaxRounds（5）、maxTokensPerCall（32000）、tokenBudgetPerActivity（64000）

3.5 Context Load 上下文加载策略

上下文加载策略定义了场景的"认知边界"：

{
  "staticLayers": ["SYSTEM", "PROCESS", "KNOWLEDGE"],
  "dynamicLayers": ["HISTORY", "WORKING"],
  "defaultLoadLevel": "standard",
  "loadLevels": {
    "standard": { "historyCompression": "summary", "tokenBudget": 8000 },
    "deepDesign": { "historyCompression": "full", "tokenBudget": 32000 }
  }
}

四、场景组与认知阶段

4.1 10 大业务场景组

OODER 将全部业务能力抽象为 10 个场景组 (SceneGroup)，每个场景组对应一个核心业务域，通过 cognitivePhases 声明跨越哪些认知阶段：

10 大业务场景组与认知阶段映射关系

4.2 场景组自驱动执行

场景组的一个关键设计是自驱动执行。当一个场景组被激活后，其内部节点由 SceneGroupExecutionEngine 独立管理，外部流程引擎不可调度 SG 内部节点。这种设计带来了几个好处：

• 封装性：SG 内部细节对外部不可见，外部只需关心 SG 的输入输出
• 自治性：SG 独立管理快照、进度、任务调度，不受外部干扰
• 复用性：同一个 SG 可以被多个管线引用（如 understand-subflow 被 architect-pipeline 和 business-pipeline 共享）
• 可扩展性：新增 SG 不影响现有管线，只需在 flow-registry.json 中注册

子流程共享与上下文隔离机制

五、场景生命周期与执行引擎

5.1 场景组生命周期

CREATING → ACTIVE → SUSPENDED → ARCHIVED → DESTROYING → DESTROYED
                ↑                                  ↓
                └──────────── (恢复) ──────────────┘

• CREATING：场景组创建阶段，初始化参与者、能力绑定、知识绑定
• ACTIVE：活跃阶段，接受外部请求，执行内部活动
• SUSPENDED：挂起阶段，等待外部事件，暂停内部活动执行
• ARCHIVED：归档阶段，保存执行快照，释放资源
• DESTROYED：已销毁，不可恢复

5.2 流程执行生命周期

PENDING → RUNNING → PAUSED → COMPLETED
                ↑           ↓         ↓
                │           ├───────→ FAILED
                │           └───────→ CANCELLED / TIMEOUT / ARCHIVED

5.3 FC-Loop 与 HARNESS 模式

OODER 支持三种 LLM 执行模式，适应不同的场景需求：

三种 LLM 执行模式对比：SINGLE / HARNESS / PROGRESSIVE

SINGLE 模式：单次 LLM 调用，适用于简单任务。LLM 调用一次，解析结果，继续执行

• HARNESS 模式：多轮校验循环，适用于需要质量保证的任务。LLM 多次调用，每次校验前次结果，达到共识或最大轮次后结束
• PROGRESSIVE 模式：渐进式自主驱动，适用于复杂推理任务。LLM 自主决定下一步行动，执行后反馈结果，循环直到任务完成

六、实战：从意图分发到场景路由

6.1 IntentDispatchScene 分发流程

IntentDispatchScene 是新对话的入口场景，负责分析用户意图并路由到目标场景。它采用程序化管道实现，绕过 FC-Loop 断链问题：

IntentDispatchScene 四步分发流程

6.2 场景切换机制

场景切换是 OODER 场景模型的核心能力。SwitchSceneFlowTool 负责在不同场景之间安全切换：

1. 校验目标流程是否存在
2. 创建子流程实例 (subProcessInst)
3. 继承上下文（parentFlowId / conversationId / sessionId）
4. 启动目标场景执行

6.3 子流程共享与隔离

understand-subflow 被 architect-pipeline 和 business-pipeline 共享，但每次执行都在独立的上下文中：

• 上下文隔离：每个子流程实例拥有独立的 contextInherit 策略，避免跨上下文污染
• VFS 路径隔离：每个子流程的持久化数据存储在独立的 VFS 路径下
• 生命周期独立：子流程的 PENDING/RUNNING/COMPLETED 状态独立于父流程
• 结果回写：子流程完成后，通过 producedOutputs 将结果回写到父流程上下文

七、总结与展望

7.1 场景模型的核心价值

OODER 的场景模型为 Workflow-Driven Agent 提供了几个关键能力：

1. 结构化执行：将 LLM 的不确定性行为约束在清晰的场景结构中，使其可预测、可审计、可调试
2. 路由驱动控制：通过 Transition 表达控制逻辑，比硬编码的 Gateway/Loop 更灵活、更可配置
3. 场景组自驱动：SG 独立管理内部执行，外部只关心输入输出，实现了关注点分离
4. 多级复用：子流程 → 场景组 → 管线 → 场景，四级复用粒度
5. 安全护栏：Guard 配置 + Context 策略 + noMatchPolicy，三重保护防止失控

7.2 未来演进方向

• 场景编排可视化：通过 Workflow Designer 的拖拽式编排，让非技术用户也能定义场景
• 场景热加载：运行时动态加载/卸载场景定义，无需重启
• 场景版本管理：场景定义的版本化，支持 A/B 测试和灰度发布
• 场景监控：场景执行的可观测性，包括 Token 消耗、轮次分布、失败模式
• 场景模板市场：预置场景模板，支持社区贡献和分享

核心模型类关系图：SceneEngine → SceneGroup → ChatScene → SkillFlowEngine → ProcessDefinition

场景驱动的智能体：OODER Workflow 中的场景模型理论与应用