​当我们讨论 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 开发为什么需要 Workflow1.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 语境下它的角色发生了根本转变维度传统 BPM WorkflowAgent Workflow驱动者人工驱动流程辅助LLM 自主驱动流程约束核心节点人工审批、表单填写LLM 交互、工具调用、场景组不确定性流程定义确定性人工选择不确定流程定义约束性LLM 决策不确定审计对象人工操作记录LLM 推理链 工具调用链 路由决策组合单位子流程场景组SceneGroup**关键洞察**Workflow 不是要消除 Agent 的自主性而是要给自主性一个结构化的边界——让 Agent 在边界内自由决策但边界本身是可定义、可验证、可演进的。二、Harness 规范Agent 的行为契约2.1 从相信 LLM到约束 LLMHarness挽具的隐喻来自马术挽具不是限制马的奔跑而是让马的力量可以被骑手感知和引导。在 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 交互模式模式一独立 LLMSINGLE— 最轻的挽具。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_AGENTconfig:{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 LoopFC-Loop是 Agent 执行的原子引擎。它的本质是 ReActReasoning Acting模式的工程化实现while(roundmaxRounds!isDelivered){reasoningLLM.chat(messages,tools)// 推理LLM决定下一步if(reasoning.hasToolCalls){for(toolCall:reasoning.toolCalls){resultexecuteTool(toolCall)// 行动执行工具messages.append(toolCall,result)// 反馈结果注入上下文}}else{isDeliveredtrue// 交付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 通过四级收敛保证来回答轮次上界maxRounds 限制 FC-Loop 最多执行 N 轮Token 预算tokenBudgetPerActivity 限制每活动的总 token 消耗回退上界maxBackwardCount 限制最多回退 M 次全局守卫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 执行的忠实记录SSEServer-Sent Events不仅是前端实时推送的技术手段在 Agent Workflow 中它承担着更深层的角色——执行过程的忠实记录。OODER 的 SSE 事件类型体系与 Workflow 的六种 ActivityType 严格对齐SSE 事件类型对应 ActivityType语义flow_step所有类型通用步骤推进flow_thinkingLLM_AGENTLLM 推理过程flow_tool_callLLM_AGENT / TASK工具调用flow_tool_progressTASK长时间任务进度flow_tool_outputLLM_AGENT / TASK工具执行结果flow_event_waitAGENT_EVENT事件等待flow_event_triggerAGENT_EVENT事件触发flow_human_confirmHUMAN(CONFIRM)人工确认flow_human_formHUMAN(FORM)人工表单每一个 SSE 事件都携带完整的上下文信息processInstId、activityId、round第几轮 Loop、tokenUsagetoken 消耗、timestamp。这些事件按时间序排列就构成了一个 Agent 执行的完整轨迹。5.2 Dump SSE从轨迹到审计“SSE Dump” 是将一次完整的 NLP-Chat 交互产生的所有 SSE 事件持久化存储形成可回溯的审计数据。这不仅仅是日志——它是结构化的执行轨迹每个事件都有明确的类型、上下文和因果链。一个典型的 SSE Dump 审计报告包含用例ID:A-Grid-001SSE流程:✅(38s完成)路由路径:understand → design → generate → quality → integrate产出物:Umt.cls(11988bytes)产出物质量:header含6列(工号/姓名/部门/职位/入职日期/状态)Loop修复对齐:fieldEnglishNames跨组传递生效(Loop#14)最终判定:PASS5.3 独立过程审计自动测试的推导引擎SSE Dump 的真正威力在于它可以从历史执行中推导出流程的自动化测试。考虑这个过程执行记录开发者通过 NLP-Chat 输入创建用户管理页面系统执行完整的 architect-pipeline产出 SSE Dump D1。轨迹分析从 D1 中提取出关键轨迹意图CRUD → 实体Employee → 路由architect → 生成TreeGrid → 质量通过。测试推导基于轨迹自动生成测试用例。回归验证当代码变更后如 Loop#14 修复了 EntityResolutionStep重新执行测试用例对比新的 SSE Dump D2 与 D1 的差异验证修复是否生效且未引入退化。这就是从流程执行推导出流程测试——流程本身的执行历史成为测试用例的生成源。OODER 的 A/B/C 三类审计矩阵正是这个方法的实践分类用例含义自动推导依据A-BasicA-Grid-001, A-Form-001基础组件生成SSE 中最常见的路由路径B-MediumB-Chart-001, B-Gallery-001中等复杂组件SSE 中需要特殊处理的 componentTypeC-ComplexC-Nav-001, C-CRUD-001复杂组合页面SSE 中跨场景组交互的轨迹5.4 Loop 修复的闭环验证SSE 审计不仅发现问题更驱动了Loop 修复的闭环验证Loop#13:发现A-Grid-001header为空 ↓ 根因分析:entity_resolution活动缺失导致fieldEnglishNamesnullLoop#14:新增EntityResolutionSkill添加ee_entity_resolution活动 ↓ 验证:SSEDump显示header含6列 ✅ Loop#15:发现B-Chart-001退化(Chart→TreeGrid)↓ 根因分析:ConfigGenerationStep将Chart升级为Layout Loop#15修复:Chart/DEEP_LAYOUT不再升级LayoutexcludeFromLayoutUpgrade ↓ 验证:SSEDump显示ECharts组件 ✅每一次 Loop 修复都由 SSE 审计发现问题、由代码修改解决问题、由新的 SSE 审计验证修复——审计 → 修复 → 审计的闭环让 Agent 的质量像飞轮一样持续提升。六、Workflow 推导从审计到 Agent 基础设施6.1 自举闭环Workflow 推导自身将前面的分析串起来我们得到了一个令人兴奋的结论——Workflow 可以从自身的执行中推导出自身的改进。这是一个自举bootstrapping闭环Workflow 的执行产生了审计数据审计数据推导出测试用例和改进方案改进方案应用到 Workflow 定义产生更好的执行结果。Workflow 不是一次性设计的而是通过持续的自审计自演进。6.2 ProcessDefinitionWorkflow 的元模型Workflow 之所以能成为 Agent 的基础设施根本原因在于它有一个足够强大的元模型——ProcessDefinition。这个元模型不仅描述了流程的结构还承载了 Agent 运行所需的全部语义ProcessDefinition{// 结构语义流程是有向DAGdefinitionId,name,versionswimLanes:ListSwimLaneDefinition// 泳道场景组activities:ListActivityDefinition// 活动Agent步骤transitions:ListTransition// 转换路由规则// Agent语义每个活动都是Agentactivities[].activityType// TASK/LLM_AGENT/HUMAN/AGENT_EVENTactivities[].config.taskMode// SKILLS/SCENE_GROUPactivities[].config.llmMode// SINGLE/HARNESS/PROGRESSIVEactivities[].config.humanMode// CONFIRM/FORM/APPROVAL/DELEGATE// Harness语义行为契约guardConfig:GuardConfig// 三级守卫contextLoadPolicy:ContextLoadPolicy// 上下文装载策略// 知识语义知识驱动knowledgeBindings:ListKnowledgeBinding// 5级粒度×5层知识flowToolIds:ListString// 流程级工具// 领域语义领域隔离classification,domain,sceneId}这个元模型的丰富性确保了任何 Agent 的行为都可以被 Workflow 表达任何 Workflow 的执行都可以被审计推导。这就是 Workflow 作为基础设施的数学基础——它是一个完备的 Agent 表达系统。6.3 从 Workflow 到 Agent 操作系统如果我们把视角拉远Workflow 不仅是 Agent 的编排工具它更像是 Agent 的操作系统操作系统概念Agent Workflow 对应进程ProcessProcessInstance流程实例线程ThreadFC-Loop函数调用循环进程间通信IPCContextTransfer上下文交换4种模式文件系统VFSVfsFolder统一虚拟文件系统内存管理ContextLayerManager6层上下文管理进程调度RouteToEngine路由分派4种类型信号/事件AGENT_EVENT事件钩子权限模型HUMAN 组织管理 审批门禁系统调用CapabilityFunction能力函数审计日志SSE Dump HistoryMergeServiceAgent 确实需要操作系统级别的服务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 的基本循环能力用例SSE流程路由产出物判定A-Grid-001✅architectUmt.cls (11988B, 6列)PASSA-Form-001✅architectFormpage.cls (13933B)PASSA 类验证的是 FC-Loop Harness 的基本闭环LLM 能在约束轮次内完成交付产出物符合质量门禁。B-Medium中等验证——验证 Workflow 的路由分支能力用例SSE流程路由产出物判定B-Chart-001✅architectEchartspage.cls (10561B)PASSB-Gallery-001✅architectGallerypage.cls (9974B)PASSB 类验证的是 SceneGroup 的独立上下文能力不同 componentType 在同一管线中能正确路由到对应的生成逻辑。C-Complex复杂验证——验证 Workflow 的跨场景组协作能力用例SSE流程路由产出物判定C-Nav-001✅deep-designNavTreeLayoutBlockPASSC-CRUD-001✅radLayoutpage.cls (4121B)DEGRADEDC 类验证的是多 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.mdSkillFlow 统一概念对齐设计方案skillflow-concept-alignment-design.mdSSE Dump 综合审计报告sse-audit-report-ABC-categories-20260728.mdProcessDefinition 元模型scene-engine/…/ProcessDefinition.javaSceneGroup 核心模型scene-engine/…/SceneGroup.javaFunctionCallingLoopExecutor 引擎ooder-pro/…/FunctionCallingLoopExecutor.java© 2026 OODER Framework · Workflow as Agent Infrastructure​