在 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 / END。
• PhaseDefinition：阶段定义，支持 5 个标准阶段：UNDERSTAND / PLAN / DESIGN / INTEGRATE / DEPLOY。
• Transition：路由转换定义，包含 condition、direction (FORWARD/BACKWARD)、priority、maxRetry。

2.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，第一个匹配的走该路由。
• 无路由匹配 → 触发 noMatchPolicy。
• AND_SPLIT：所有出边同时走（并行执行）。
• AND_JOIN：所有入边到达后才触发。
• 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 三维分类，提供运行时路由所需的所有元数据。

代码语言：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 活动定义

活动是场景的最小执行单元。

支持的类型体系如下：

类型	说明	执行模式
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 定义条件表达式、优先级、方向和重试机制：

代码语言：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 上下文加载策略

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

代码语言：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 独立管理快照、进度、任务调度，不受外部干扰。
• 复用性：同一个 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 中的场景模型理论与应用