​

当我们讨论 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_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 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-001SSE流程:✅(38s完成)路由路径:understand → design → generate → quality → integrate产出物:Umt.cls(11988bytes)产出物质量: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-001header为空 ↓ 根因分析:entity_resolution活动缺失导致fieldEnglishNames=nullLoop#14:新增EntityResolutionSkill+添加ee_entity_resolution活动 ↓ 验证:SSEDump显示header含6列 ✅ Loop#15:发现B-Chart-001退化(Chart→TreeGrid)↓ 根因分析:ConfigGenerationStep将Chart升级为Layout Loop#15修复:Chart/DEEP_LAYOUT不再升级Layout+excludeFromLayoutUpgrade ↓ 验证:SSEDump显示ECharts组件 ✅

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

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

6.1 自举闭环：Workflow 推导自身

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

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

6.2 ProcessDefinition：Workflow 的元模型

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

ProcessDefinition{// 结构语义：流程是有向DAGdefinitionId,name,versionswimLanes:List<SwimLaneDefinition>// 泳道=场景组activities:List<ActivityDefinition>// 活动=Agent步骤transitions:List<Transition>// 转换=路由规则// 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: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

​