在 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 任务
维度 | 场景 (Scene) | 流程 (Process) | 任务 (Task) |
|---|---|---|---|
粒度 | 中 | 大 | 小 |
生命周期 | 独立 | 编排型 | 一次性 |
上下文 | 有明确边界 | 继承型 | 无 |
LLM 配置 | 场景级 | 活动级 | 无 |
状态管理 | 自驱动 | 引擎驱动 | 无状态 |
复用性 | 多管线共享 | 引用子流程 | 每次独立 |
二、场景模型的四层架构
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 / ENDPhaseDefinition：阶段定义，支持 5 个标准阶段：UNDERSTAND / PLAN / DESIGN / INTEGRATE / DEPLOYTransition：路由转换定义，包含 condition、direction (FORWARD/BACKWARD)、priority、maxRetry2.2 注册层 (Registry Layer)
注册层负责将定义层中的 JSON 文件加载到运行时内存。VfsFlowDefinitionLoader 会在应用启动时扫描 VFS 目录下的全部定义文件，解析为 Ja va 对象，并注册到 ProcessDefinitionRegistry。关键设计包括：
热加载：支持运行时重新加载，定义文件变更后无需重启系统双注册：同时注册到本地内存和远程 Workflow 引擎，支持跨节点执行校验：注册时进行定义完整性校验（如活动引用、路由死锁、阶段完整性）2.3 执行层 (Execution Layer)
执行层是场景模型的核心引擎。SkillFlowEngine 实现了典型的路由驱动执行机制：
接收 startExecution(flowDefinitionId, context) → 创建 ProcessInstance查找 START 活动 → 执行活动执行完成后，遍历所有 sourceId = currentActivity 的 Transition按 priority 排序，匹配 condition，第一个匹配成功的路由即被采用无路由匹配 → 触发 noMatchPolicyAND_SPLIT：所有出边同时执行（并行处理）AND_JOIN：所有入边全部到达后才触发BACKWARD 路由：重置目标活动状态为 PENDING，并检查 maxRetry2.4 场景层 (Scene Layer)
场景层是直接面向用户的接口层。ChatScene 接口体系提供用户交互入口：
IntentDispatchScene：新对话的意图分发入口，通过 LLM 分类匹配目标场景RadChatScene：RAD 设计场景，处理组件设计相关任务GeneralChatScene：通用问答场景，适用于无特定流程约束的对话三、场景定义的核心 Schema
3.1 Flow Registry 注册表
flow-registry.json 是场景定义的核心索引文件，包含 32 个流程定义。每个流程条目通过 classification phase businessCategory 三维分类，为运行时路由提供所需的关键元数据：
代码语言：ja vascript复制{"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 活动定义
活动（Activity）是场景的最小执行单元。其支持的类型体系如下：
类型 | 说明 | 执行模式 |
|---|---|---|
LLM_AGENT | LLM 智能体节点 | SINGLE / HARNESS / PROGRESSIVE |
HUMAN | 人工一等公民节点 | CONFIRM / APPROVAL / FORM / DELEGATE |
HUMAN_AGENT | 人工交互节点（旧版） | 确认/选择/输入 |
SUB_PROCESS | 子流程引用 | 引用 subFlowDefId |
TASK | 任务节点 | 执行具体技能 |
AGENT_EVENT | 事件节点 | SSE 推送/事件触发 |
END | 结束节点 | 流程终止 |
3.3 Transition 路由转换
路由（Transition）是场景模型的控制核心。每个 Transition 都会定义条件表达式、优先级、流转方向以及重试机制：
代码语言：ja vascript复制{"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 上下文加载策略
上下文加载策略定义了场景的“认知边界”，直接影响 Agent 在不同任务中的信息获取范围：
代码语言：ja vascript复制{"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）。可以把它理解为 10 个核心业务域，而每个场景组都会通过 cognitivePhases 明确标注自己会跨越哪些认知阶段：
10 大业务场景组与认知阶段映射关系
场景组 | 认知阶段 | 主流程 | 说明 |
|---|---|---|---|
SG-INTENT-DISPATCH | UNDERSTAND | intent-dispatch | 意图分发入口 |
SG-DATABASE-DESIGN | UNDERSTAND → DESIGN | dbfirst-build | 数据库设计 |
SG-VIEW-CONSTRUCTION | DESIGN → GENERATE → INTEGRATE | designerfirst-build | 视图构建 |
SG-ATTACHMENT | UNDERSTAND | attachment-subflow | 附件处理 |
SG-PROCESS-ORCHESTRATION | DESIGN → INTEGRATE | Workflow-design | 流程编排 |
SG-CODEGEN | GENERATE → INTEGRATE | ja vabuild-full | 代码生成 |
SG-KNOWLEDGE-RETRIEVAL | UNDERSTAND | knowledge-retrieval | 知识检索 |
SG-QUALITY-VALIDATION | QUALITY | quality-validation | 质量校验 |
SG-HUMAN-INTERACTION | 独立 | human-interaction | 人工交互 |
SG-SANDBOX-DEVOPS | INTEGRATE | sandbox-devops | 沙箱运维 |
4.2 场景组自驱动执行
场景组的一个关键能力是自驱动执行。当某个场景组被激活后，其内部节点将由 SceneGroupExecutionEngine 独立管理，外部流程引擎无法直接调度 SG 内部节点。这种设计带来了多方面优势：
封装性：SG 内部细节对外部不可见，外部只需关注输入与输出自治性：SG 独立管理快照、进度与任务调度，不受外部执行干扰复用性：同一个 SG 可以被多个管线复用（例如 understand-subflow 被 architect-pipeline 和 business-pipeline 共享）可扩展性：新增 SG 不会影响既有管线，只需在 flow-registry.json 中完成注册
子流程共享与上下文隔离机制
五、场景生命周期与执行引擎
5.1 场景组生命周期
代码语言：ja vascript复制CREATING → ACTIVE → SUSPENDED → ARCHIVED → DESTROYING → DESTROYED↑↓└──────────── (恢复) ──────────────┘CREATING：场景组创建阶段，初始化参与者、能力绑定、知识绑定ACTIVE：活跃阶段，接收外部请求并执行内部活动SUSPENDED：挂起阶段，等待外部事件并暂停内部活动执行ARCHIVED：归档阶段，保存执行快照并释放资源DESTROYED：已销毁状态，不可恢复
5.2 流程执行生命周期
代码语言：ja vascript复制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 负责在不同场景之间进行安全切换：
校验目标流程是否存在创建子流程实例 (subProcessInst)继承上下文（parentFlowId / conversationId / sessionId）启动目标场景执行6.3 子流程共享与隔离
understand-subflow 会被 architect-pipeline 和 business-pipeline 共同复用，但每次执行都运行在独立上下文中：
上下文隔离：每个子流程实例拥有独立的 contextInherit 策略，避免跨上下文污染VFS 路径隔离：每个子流程的持久化数据都存储在独立的 VFS 路径下生命周期独立：子流程的 PENDING/RUNNING/COMPLETED 状态独立于父流程结果回写：子流程完成后，通过 producedOutputs 将结果写回父流程上下文七、总结与展望
7.1 场景模型的核心价值
OODER 的场景模型为 Workflow-Driven Agent 提供了多个关键能力：
结构化执行：将 LLM 的不确定性行为约束在清晰的场景结构中，使流程更可预测、可审计、可调试路由驱动控制：通过 Transition 表达控制逻辑，相比硬编码的 Gateway/Loop 更灵活、更易配置场景组自驱动：SG 独立管理内部执行，外部只需关注输入输出，实现关注点分离多级复用：子流程 → 场景组 → 管线 → 场景，形成四级复用粒度安全护栏：Guard 配置 Context 策略 noMatchPolicy，三重保护机制有效防止执行失控7.2 未来演进方向
场景编排可视化：通过 Workflow Designer 的拖拽式编排，让非技术用户也能定义场景场景热加载：支持运行时动态加载/卸载场景定义，无需重启系统场景版本管理：对场景定义进行版本化管理，支持 A/B 测试与灰度发布场景监控：提升场景执行可观测性，包括 Token 消耗、轮次分布与失败模式场景模板市场：预置标准场景模板，支持社区贡献、复用与分享
核心模型类关系图：SceneEngine → SceneGroup → ChatScene → SkillFlowEngine → ProcessDefinition
场景驱动的智能体：OODER Workflow 中的场景模型理论与实践应用
