Workflow：Agent 开发的基础—从 Harness 规范到 SSE 审计的闭环体系

Workflow：Agent 开发的基础设施——从 Harness 规范到 SSE 审计的闭环体系

当我们讨论 Agent 时，我们在讨论什么？是一个能调工具的 LLM？是一个能自主决策的循环？还是一个能在流程中自我定位、自我校验、自我交付的工作单元？本文从 OODER 框架的实践出发，论证一个核心命题：Workflow 不是 Agent 的上层编排，而是 Agent 的底层基础设施。

Harness 规范定义了 Agent 的行为契约，Loop 调用构成了 Agent 的执行引擎，子流程与场景组的抽象简化了 Agent 的组合设计，而 NLP-Chat → Dump SSE 的独立过程审计，则让流程的自动测试推导出 Workflow 本身——形成 Agent 开发的自举闭环。

目录

一、Agent 开发为什么需要 Workflow二、Harness 规范：行为契约三、Loop 调用：执行引擎四、子流程与场景组：组合抽象五、NLP-Chat → Dump SSE六、Workflow 推导七、实践验证八、Workflow-Native 展望九、结语

一、问题的根源：Agent 开发为什么需要 Workflow？

1.1 当前 Agent 开发的困境

当下 Agent 开发的普遍范式是：Prompt + Tools + LLM Loop。开发者编写一个 system prompt，声明一组工具（function calling），让 LLM 在循环中自主调用工具完成任务。这个范式简洁有力，但在工程化场景中暴露出三个根本性问题：

第一，缺乏行为契约。 Agent 的 LLM 调用是"黑盒决策"——你不知道它会在第几轮选择哪个工具、是否会重复调用、是否会陷入死循环。没有契约约束的 Agent，就像没有交通规则的道路：每个司机都在自主驾驶，但整体效率为零。

第二，缺乏组合抽象。 当任务复杂度上升，单个 Agent 的 prompt 膨胀到难以维护。开发者本能地想拆分——"让一个 Agent 负责理解，另一个负责设计，第三个负责生成"。但拆分后的编排逻辑散落在代码各处，缺乏统一的组合抽象。这就像用 goto 语句写并发程序：能跑，但无法推理。

第三，缺乏可审计性。 Agent 执行过程中产生了 LLM 推理、工具调用、条件路由等大量中间状态，但这些状态是"流式"的——过去就没了。当 Agent 出了问题，开发者只能靠"再跑一次看看"来调试，无法回溯、无法审计、无法从历史执行中推导出流程的改进方向。

1.2 Workflow 作为解法的必然性

这三个问题的共同根因是：Agent 缺乏一个外显的、可执行的、可审计的流程定义。 而这正是 Workflow 的本质。

Workflow 在传统 BPM 领域是"人工流程的自动化"，但在 Agent 语境下，它的角色发生了根本转变：

关键洞察：Workflow 不是要消除 Agent 的自主性，而是要给自主性一个结构化的边界——让 Agent 在边界内自由决策，但边界本身是可定义、可验证、可演进的。

二、Harness 规范：Agent 的行为契约

2.1 从"相信 LLM"到"约束 LLM"

Harness（挽具）的隐喻来自马术：挽具不是限制马的奔跑，而是让马的力量可以被骑手感知和引导。在 Agent 语境下，Harness 规范定义了 LLM 的三级防护体系：

GuardConfig（三级守卫配置）
  │
  ├── ProcessGuard（流程级）
  │     ├── maxLlmRounds: 50       // 最多50轮LLM调用
  │     ├── maxTotalTokens: 500000  // 总token预算
  │     ├── maxBackwardCount: 3     // 最多3次回退
  │     └── deepDesignRequired: true // 是否需要深度设计
  │
  ├── ActivityGuard（活动级）
  │     ├── maxLlmLoopCount: 5      // 每活动最多5轮LLM循环
  │     ├── fcLoopMaxRounds: 5      // FC-Loop最多5轮
  │     ├── maxRetry: 3             // 最多3次重试
  │     └── tokenBudgetPerActivity: 50000 // 每活动token预算
  │
  └── ClassificationProfile（分类级）
        └── 不同流程分类继承不同的默认守卫配置

这不是简单的"限制"，而是一份行为契约：LLM 承诺在 maxLlmRounds 轮内完成交付，在 tokenBudgetPerActivity 预算内产出结果，在 maxRetry 次重试后降级处理。而流程引擎承诺：只要 LLM 在契约内行为，就不会强制中断。

2.2 Harness 的三种 LLM 交互模式

模式一：独立 LLM（SINGLE） — 最轻的挽具。LLM 在单次 FC-Loop 中完成决策。Harness 仅约束轮次和 token 预算。适用于意图分类、实体提取等快速决策场景。

模式二：LLM Harness 流程（HARNESS） — 标准挽具。每一轮 LLM 输出都要经过 harness 校验（质量门禁）。不通过则注入校验反馈重试，通过则推进到下一步。这是 Agent 最常用的模式——渐进式收敛：LLM 不是一次做对，而是在 Harness 的引导下逐步逼近正确结果。

模式三：渐进式自主驱动（PROGRESSIVE） — 最重的挽具。LLM 自主决定下一步走到哪个活动节点，包括回退到前序节点重新执行。Harness 约束回退次数（maxBackwardCount）和总轮次。适用于深度设计场景，LLM 需要在多步之间反复调整。

2.3 Harness 规范的工程意义

Harness 规范的工程意义远超"参数配置"。它实际上定义了Agent 的类型签名：

// 一个LLM_AGENT活动的完整签名
ActivityDefinition {
    activityType: LLM_AGENT
    config: {
        llmMode: HARNESS,              // 挽具模式
        maxLlmLoopCount: 5,            // 收敛上界
        fcLoopMaxRounds: 5,            // FC轮次上界
        tokenBudgetPerActivity: 50000, // 资源上界
        requiredInputs: ["intent", "entities"],   // 输入契约
        producedOutputs: ["architecture", "config"] // 输出契约
    }
}

有了类型签名，Agent 就是可组合的：下游 Agent 可以静态检查 requiredInputs 是否被上游的 producedOutputs 覆盖。这是从"相信 LLM 能自己搞对"到"工程化地保证 LLM 不会搞错"的关键转变。

三、Loop 调用：Agent 的执行引擎

3.1 FC-Loop 的本质：推理-行动循环

Function Calling Loop（FC-Loop）是 Agent 执行的原子引擎。它的本质是 ReAct（Reasoning + Acting）模式的工程化实现：

while (round < maxRounds && !isDelivered) {
    reasoning = LLM.chat(messages, tools)    // 推理：LLM决定下一步
    if (reasoning.hasToolCalls) {
        for (toolCall : reasoning.toolCalls) {
            result = executeTool(toolCall)   // 行动：执行工具
            messages.append(toolCall, result) // 反馈：结果注入上下文
        }
    } else {
        isDelivered = true                    // 交付：LLM认为任务完成
    }
    round++
}

在 OODER 的 FunctionCallingLoopExecutor 实现中，FC-Loop 的工程化细节值得深入分析：

超时分级控制。 不同的工具调用有不同的合理耗时。FC-Loop 设定了三级超时：单工具超时（60s）、工具组超时（30s × 工具数）、LLM 调用超时（120s）、总流程超时（180s）。这确保了 Agent 不会因为单个工具的异常而无限等待。

降级决策器。 当工具调用失败时，不是简单地重试，而是由 LlmFallbackDecider 根据错误上下文（ToolErrorContext）决策：重试？回滚到前一步？降级到替代工具？还是放弃并报告用户？这个决策器本身就是一个知识驱动的小型 Agent——它从 ToolErrorKnowledgeBase 检索类似错误的历史处理方案，做出最优决策。

SSE 事件推送。 FC-Loop 的每一轮推理和工具调用都通过 SseEventAssembler 构建结构化事件（flow_thinking、flow_tool_call、flow_tool_output）推送到前端。这让 Agent 的执行过程对用户可见——不是黑盒，而是可以实时观察的推理链。

3.2 Loop 的层级：从原子循环到编排循环

FC-Loop 是原子级的循环，但在 Workflow 中，Loop 有三个层级：

层级一：FC-Loop（活动内循环） — LLM 在单个活动内的推理-行动循环。例如意图分类活动中，LLM 调用 intent_parse 工具获得 CRUD 意图，再调用 slot_fill 填充实体，最终交付。

层级二：Harness Loop（跨活动循环） — LLM 在多个活动间的渐进式收敛。例如配置生成活动中，LLM 第一轮生成配置经校验 header 为空，注入反馈后第二轮修正配置，header 含 6 列，通过交付。

层级三：Process Loop（流程级循环） — 流程在场景组间的推进与回退。例如 architect-pipeline 执行到质量校验不通过，回退到设计阶段重新设计。

三个层级的 Loop 分别对应 Harness 的三种模式（SINGLE / HARNESS / PROGRESSIVE），形成了从微观到宏观的循环嵌套结构。这正是 Workflow 作为 Agent 基础设施的核心能力：用循环的嵌套来表达 Agent 的递归决策能力。

3.3 Loop 的收敛保证

Loop 的工程化核心问题是：如何保证循环一定会终止？

OODER 通过四级收敛保证来回答：

1. 轮次上界：maxRounds 限制 FC-Loop 最多执行 N 轮
2. Token 预算：tokenBudgetPerActivity 限制每活动的总 token 消耗
3. 回退上界：maxBackwardCount 限制最多回退 M 次
4. 全局守卫：maxTotalTokens 限制整个流程的总 token 预算

这四级保证形成了一个单调递减的资源预算——每一轮 Loop 都在消耗预算，预算耗尽则强制终止。这不是"相信 LLM 会自己停下来"，而是"工程化地保证它必须停下来"。

四、子流程与场景组：Agent 的组合抽象

4.1 为什么子流程不够？

传统 Workflow 的组合单位是子流程（SubProcess）。子流程的语义是：父流程调用子流程，子流程执行完毕后返回父流程。这个语义在人工流程中足够——因为人工流程的每一步都是确定性的。但在 Agent 流程中，子流程的语义出现了根本性裂缝：

裂缝一：调度权冲突。 子流程的节点对父流程可见——父流程可以调度子流程内部的任意节点。但在 Agent 场景中，一个"理解场景组"内部的意图分类、实体提取等步骤，应该由场景组自主决定执行顺序，而不是由外部流程来调度。

裂缝二：HUMAN 阻断冲突。 子流程中的人工节点会阻断父流程。但在 Agent 的场景组中，人工交互（如用户选择模板）只是驱动场景演变的因素，不应该阻断整个 Agent 流程的推进。

裂缝三：上下文泄漏。 子流程共享父流程的上下文——这意味着子流程的任何状态变更都会影响父流程。但在 Agent 场景中，场景组应该有独立的上下文，只在入口和出口与父流程交换数据。

4.2 SceneGroup：自驱动的封闭单元

SceneGroup 是独立封闭的自驱动单元。 流程可以注入上下文影响其运行，但不能调度其内部节点。SceneGroup 完整交付任务后整体返回。

SceneGroup 的核心状态模型包含：独立标识（sceneGroupId）、自管理的生命周期状态（CREATING → ACTIVE → SUSPENDED → ARCHIVED）、独立的上下文（业务配置、LLM 配置、知识库绑定）、独立的参与者管理、独立的快照管理、以及统一输出契约（taskStatus + taskSummary）。

4.3 场景组的组合哲学

场景组的组合遵循黑盒组合原则：每个场景组是一个黑盒，只通过入口（上下文注入）和出口（统一输出契约）与外部交互。这带来三个关键优势：

优势一：独立演进。 SG-UNDERSTAND 的内部逻辑可以完全重构（比如从规则引擎切换到 LLM 推理），只要输出契约不变，下游的 SG-DESIGN 不受任何影响。

优势二：并行执行。 无依赖的场景组可以并行执行。因为它们的上下文是独立的。

优势三：失败隔离。 SG-QUALITY 校验失败时，只需要回退到 SG-DESIGN 重新设计，不影响 SG-UNDERSTAND 已经产出的意图和实体结果。

核心哲学：用场景组替代子流程，就像用模块替代全局变量——黑盒组合、独立上下文、统一契约，这正是软件工程中"模块化"的核心思想在 Agent 领域的体现。

五、NLP-Chat → Dump SSE：独立过程审计与流程推导

5.1 SSE 事件流：Agent 执行的忠实记录

SSE（Server-Sent Events）不仅是前端实时推送的技术手段，在 Agent Workflow 中，它承担着更深层的角色——执行过程的忠实记录。

OODER 的 SSE 事件类型体系与 Workflow 的六种 ActivityType 严格对齐：

每一个 SSE 事件都携带完整的上下文信息：processInstId、activityId、round（第几轮 Loop）、tokenUsage（token 消耗）、timestamp。这些事件按时间序排列，就构成了一个 Agent 执行的完整轨迹。

5.2 Dump SSE：从轨迹到审计

"SSE Dump" 是将一次完整的 NLP-Chat 交互产生的所有 SSE 事件持久化存储，形成可回溯的审计数据。这不仅仅是日志——它是结构化的执行轨迹，每个事件都有明确的类型、上下文和因果链。

一个典型的 SSE Dump 审计报告包含：

用例ID: A-Grid-001
SSE流程: ✅ (38s完成)
路由路径: understand → design → generate → quality → integrate
产出物: Umt.cls (11988 bytes)
产出物质量: header含6列(工号/姓名/部门/职位/入职日期/状态)
Loop修复对齐: fieldEnglishNames跨组传递生效(Loop#14)
最终判定: PASS

5.3 独立过程审计：自动测试的推导引擎

SSE Dump 的真正威力在于：它可以从历史执行中推导出流程的自动化测试。

考虑这个过程：

1. 执行记录：开发者通过 NLP-Chat 输入"创建用户管理页面"，系统执行完整的 architect-pipeline，产出 SSE Dump D1。
2. 轨迹分析：从 D1 中提取出关键轨迹：意图=CRUD → 实体=Employee → 路由=architect → 生成=TreeGrid → 质量=通过。
3. 测试推导：基于轨迹，自动生成测试用例。
4. 回归验证：当代码变更后（如 Loop#14 修复了 EntityResolutionStep），重新执行测试用例，对比新的 SSE Dump D2 与 D1 的差异，验证修复是否生效且未引入退化。

这就是从流程执行推导出流程测试——流程本身的执行历史成为测试用例的生成源。OODER 的 A/B/C 三类审计矩阵正是这个方法的实践：

5.4 Loop 修复的闭环验证

SSE 审计不仅发现问题，更驱动了Loop 修复的闭环验证：

Loop#13: 发现 A-Grid-001 header为空
  ↓ 根因分析: entity_resolution活动缺失导致fieldEnglishNames=null
Loop#14: 新增EntityResolutionSkill + 添加ee_entity_resolution活动
  ↓ 验证: SSE Dump显示header含6列 ✅
Loop#15: 发现 B-Chart-001 退化(Chart→TreeGrid)
  ↓ 根因分析: ConfigGenerationStep将Chart升级为Layout
Loop#15修复: Chart/DEEP_LAYOUT不再升级Layout + excludeFromLayoutUpgrade
  ↓ 验证: SSE Dump显示ECharts组件 ✅

每一次 Loop 修复都由 SSE 审计发现问题、由代码修改解决问题、由新的 SSE 审计验证修复——审计 → 修复 → 审计 的闭环，让 Agent 的质量像飞轮一样持续提升。

六、Workflow 推导：从审计到 Agent 基础设施

6.1 自举闭环：Workflow 推导自身

将前面的分析串起来，我们得到了一个令人兴奋的结论——Workflow 可以从自身的执行中推导出自身的改进。

这是一个自举（bootstrapping）闭环：Workflow 的执行产生了审计数据，审计数据推导出测试用例和改进方案，改进方案应用到 Workflow 定义，产生更好的执行结果。Workflow 不是一次性设计的，而是通过持续的自审计自演进。

6.2 ProcessDefinition：Workflow 的元模型

Workflow 之所以能成为 Agent 的基础设施，根本原因在于它有一个足够强大的元模型——ProcessDefinition。这个元模型不仅描述了流程的结构，还承载了 Agent 运行所需的全部语义：

ProcessDefinition {
    // 结构语义：流程是有向DAG
    definitionId, name, version
    swimLanes: List<SwimLaneDefinition>    // 泳道=场景组
    activities: List<ActivityDefinition>    // 活动=Agent步骤
    transitions: List<Transition>           // 转换=路由规则

    // Agent语义：每个活动都是Agent
    activities[].activityType               // TASK/LLM_AGENT/HUMAN/AGENT_EVENT
    activities[].config.taskMode            // SKILLS/SCENE_GROUP
    activities[].config.llmMode             // SINGLE/HARNESS/PROGRESSIVE
    activities[].config.humanMode           // CONFIRM/FORM/APPROVAL/DELEGATE

    // Harness语义：行为契约
    guardConfig: GuardConfig                // 三级守卫
    contextLoadPolicy: ContextLoadPolicy    // 上下文装载策略

    // 知识语义：知识驱动
    knowledgeBindings: List<KnowledgeBinding>  // 5级粒度×5层知识
    flowToolIds: List<String>                  // 流程级工具

    // 领域语义：领域隔离
    classification, domain, sceneId
}

这个元模型的丰富性确保了：任何 Agent 的行为都可以被 Workflow 表达，任何 Workflow 的执行都可以被审计推导。 这就是 Workflow 作为基础设施的数学基础——它是一个完备的 Agent 表达系统。

6.3 从 Workflow 到 Agent 操作系统

如果我们把视角拉远，Workflow 不仅是 Agent 的编排工具，它更像是 Agent 的操作系统：

Agent 确实需要操作系统级别的服务：6层上下文管理对应操作系统的内存分页；4种上下文交换模式对应 IPC 机制；VFS 一致性对应统一文件系统命名空间；历史合并对应日志轮转。

6.4 Agent 开发的范式转移

基于以上分析，Agent 开发的范式正在发生根本性转移：

旧范式：Prompt Engineering — Agent = Prompt + Tools + LLM Loop。开发者手工编写 prompt，手工选择工具，手工调试循环行为。Agent 的质量完全依赖开发者的 prompt 功力。

新范式：Workflow Engineering — Agent = Workflow(Harness, Loop, SceneGroup, Audit)。开发者定义 Workflow（流程结构 + 行为契约 + 组合抽象），Agent 在 Workflow 的约束下自主执行，SSE 审计持续推导 Workflow 的改进。Agent 的质量由 Workflow 的完备性和 Harness 的约束力保证。

范式转移的核心洞察：与其让 Agent 聪明到不会犯错，不如让 Workflow 严格到不允许错误逃逸。Harness 守卫捕获越界行为，Loop 收敛保证终止性，SceneGroup 隔离防止错误传播，SSE 审计发现潜在退化——四道防线，层层递进。

七、实践验证：OODER 的 ABC 审计矩阵

7.1 从理论到实践的桥梁

前述的理论框架不是空中楼阁。OODER 的 A/B/C 三类审计矩阵提供了实践验证：

A-Basic（基础验证）——验证 Workflow 的基本循环能力：

A 类验证的是 FC-Loop + Harness 的基本闭环：LLM 能在约束轮次内完成交付，产出物符合质量门禁。

B-Medium（中等验证）——验证 Workflow 的路由分支能力：

B 类验证的是 SceneGroup 的独立上下文能力：不同 componentType 在同一管线中能正确路由到对应的生成逻辑。

C-Complex（复杂验证）——验证 Workflow 的跨场景组协作能力：

C 类验证的是多 SceneGroup 间的上下文交换和协调能力。C-CRUD-001 的 DEGRADED 判定揭示了跨场景组传递 componentType 时的数据流断裂——这正是 SSE 审计发现、Loop 修复解决的典型问题。

7.2 审计矩阵的元意义

ABC 审计矩阵不仅是测试矩阵，它本身就是一个Workflow 质量的度量空间：

• A 类通过率度量 Workflow 的可靠性（基本循环是否收敛）
• B 类通过率度量 Workflow 的灵活性（路由分支是否正确）
• C 类通过率度量 Workflow 的组合性（跨场景组是否协调）

三个维度的乘积就是 Workflow 作为 Agent 基础设施的成熟度：当成熟度达到阈值时，Workflow 就不再是"辅助编排"，而是"可信基础设施"——Agent 可以在它的上面安全地运行，就像进程在操作系统上安全地运行一样。

八、展望：Workflow-Native Agent 开发

8.1 从 Cloud-Native 到 Workflow-Native

软件工程经历过从 On-Premise 到 Cloud-Native 的范式转移。Cloud-Native 的核心是：应用生来就为云设计，而不是先设计再搬到云。

类似地，Agent 开发正在经历从 Prompt-Native 到 Workflow-Native 的范式转移。Workflow-Native 的核心是：Agent 生来就为 Workflow 设计，而不是先写 Agent 再套 Workflow。

这意味着：

• Agent 的每个能力都定义为 CapabilityFunction，通过 getParamDefs(toolId) 声明参数定义，确保 Function Calling 的准确性。
• Agent 的每次交互都遵循 Harness 契约，在守卫配置的约束下执行。
• Agent 的每个组合都通过 SceneGroup 抽象，黑盒组合、独立上下文、统一输出契约。
• Agent 的每次执行都产生 SSE 事件流，可审计、可回溯、可推导。

8.2 自演进的 Workflow

当 Workflow 成为 Agent 的基础设施，一个更深层的可能性浮现：Workflow 能否自己演进？

答案藏在 SSE 审计的闭环中：SSE Dump 记录了 Workflow 的每次执行轨迹；轨迹分析发现了 Workflow 的退化点；退化点的根因分析定位到具体的 ActivityDefinition 配置缺陷；修复方案可以自动应用到 ProcessDefinition；新的 ProcessDefinition 产生更好的执行结果。

当修复方案从"人工应用"进化到"自动应用"时，Workflow 就实现了自演进——它从自身的执行经验中学习，自动调整自己的定义，就像一个 Agent 从自己的错误中学习一样。

而这时候，Workflow 本身就是一个 Agent——一个元层次的 Agent，它的任务是优化其他 Agent 的 Workflow 定义。

8.3 终极图景：Agent 生态系统的 Workflow 内核

在这个图景中：

• Agent 是业务逻辑的执行者，每个 Agent 运行在一个 SceneGroup 中
• Workflow 是 Agent 的运行环境和约束系统，提供 Harness 契约、Loop 引擎、SG 组合
• SSE Audit 是 Workflow 的自演进引擎，持续从执行中推导改进
• VFS + Knowledge 是持久化层，确保 Workflow 的状态和知识跨越执行周期保持一致

这不是未来主义的幻想——OODER 已经实现了这个图景的 80%。Harness 规范、FC-Loop 引擎、SceneGroup 抽象、SSE 审计闭环、VFS 一致性——每一块都已经落地运行。剩余的 20%（SG 内 HUMAN 不阻断、SG 产出物统一契约、Workflow 自演进）是明确的路线图，而不是模糊的愿景。

九、结语：从编排到基础设施

回到开篇的问题：当我们讨论 Agent 时，我们在讨论什么？

在 Prompt Engineering 时代，我们讨论的是"如何让 LLM 更聪明"。在 Workflow Engineering 时代，我们讨论的是"如何让 Agent 的运行环境更可靠"。

这个转变的实质是：Agent 的核心竞争力不在于 LLM 的推理能力，而在于 Workflow 的约束和组合能力。 一个在弱约束强自由环境中运行的强 LLM，不如一个在强约束合理自由环境中运行的弱 LLM——因为前者不可预测，而后者可工程化。

Workflow 从 Agent 的"上层编排"演变为"底层基础设施"，这个演变遵循了软件工程的经典规律：

• 操作系统从"程序的辅助工具"演变为"程序的基础设施"
• 容器从"部署的辅助工具"演变为"部署的基础设施"
• Kubernetes从"编排的辅助工具"演变为"编排的基础设施"
• Workflow从"Agent 的辅助工具"演变为"Agent 的基础设施"

每一次演变的核心都是同一点：当工具足够深入地理解了它所服务的领域，它就不再是工具，而是领域的基础设施。 Workflow 深入理解了 Agent 的行为模式（Harness）、执行模式（Loop）、组合模式（SceneGroup）和演进模式（SSE Audit），因此它必然成为 Agent 的基础设施。

而 NLP-Chat → Dump SSE → 审计 → 推导 → 改进的闭环，则是这个基础设施的自举机制——Workflow 通过审计自身的执行来改进自身，就像操作系统通过监控自身的性能来优化调度策略一样。

Workflow 不是 Agent 的枷锁，而是 Agent 的道路。 道路约束了行进的方向，但正是约束让行进成为可能——没有道路的地方，只有荒野。

本文基于 OODER 框架的工程实践写成。文中引用的代码模型、审计数据和技术决策均来自实际项目。

关键参考文档：

• Workflow 概念体系对齐方案（workflow-concept-alignment.md）
• SkillFlow 统一概念对齐设计方案（skillflow-concept-alignment-design.md）
• SSE Dump 综合审计报告（sse-audit-report-ABC-categories-20260728.md）
• ProcessDefinition 元模型（scene-engine/.../ProcessDefinition.java）
• SceneGroup 核心模型（scene-engine/.../SceneGroup.java）
• FunctionCallingLoopExecutor 引擎（ooder-pro/.../FunctionCallingLoopExecutor.java）

© 2026 OODER Framework · Workflow as Agent Infrastructure