设计哲学：为什么是 SceneGroup 而不是 Step DAG

设计哲学：为什么是 SceneGroup 而不是 Step DAG

从 LangGraph、Temporal 到 Ooder：重新思考 Agent 编排的语义边界

2026-06-22

Ooder 架构团队

设计哲学 / Agent 编排 / DevOps

当 Agent 系统的步骤数突破 80+，LangGraph 的状态图开始像一张蜘蛛网，Temporal 的 Workflow Activity 链条在代码审查时让人头晕目眩。读到这里，一个自然的问题是：为什么不用 LangGraph 那种 Step DAG，或者 Temporal 那种 Workflow Activity？

本文以 Ooder A2UI 平台的 SceneGroup 机制为实例，结合 LangGraph、Temporal、OpenAI Function Calling 等公开技术材料，论证 Agent 编排的另一种可能性——用语义边界替代依赖拓扑，用意图驱动替代完全自由的 LLM 调度。

论点 1：DAG 优化的是依赖，SceneGroup 优化的是语义边界

这是 SceneGroup 设计的核心，也是与主流框架最本质的差异。

LangGraph DAG（80+ 节点）VSSceneGroup（5 个语义阶段）KNOWLEDGE（知识）CLARIFY（澄清）DESIGN（设计）BUILD（构建）REVIEW（审计）拓扑爆炸，难以定位语义清晰，易于理解

图 1：DAG 拓扑爆炸 vs SceneGroup 语义分组对比

LangGraph 的 DAG 困境：拓扑爆炸与调试黑洞

LangGraph 作为 2026 年最活跃的 Agent 编排框架（GitHub 32,000+ Stars，Klarna、Uber、LinkedIn 生产落地），其本质是将工作流建模为循环有向图（Cyclic Directed Graph）。每个节点是一个 Python 函数，边是路由规则，全局共享的 TypedDict State 作为持久化记忆。

然而，当节点数达到 80+ 时，DAG 的维护成本呈指数级上升。Latenode 在 2026 年的架构分析中指出：

"Managing these configurations can turn into a burden that outweighs the original problem being solved. Changes to workflows often require tightly controlled schema updates... These interdependencies can lead to breaking changes, requiring extensive regression testing."—— LangGraph Multi-Agent Orchestration: Complete Framework Guide 2026

CSDN 的深度报告进一步揭示了 LangGraph 的调试黑洞问题："多节点状态跳转缺乏可视化追踪，复杂 Agent 的 Bug 定位耗时可达简单任务的 5 倍。" 更严峻的是算力成本失控——"自动重试机制在低质量节点下易触发循环计算，曾实测某对话 Agent 成本超预算 400%。"

LangChain 2026 年的 State of Agent Engineering 报告显示，超过 60% 的生产 Agent 事故归因于状态管理失败：Agent 在工作流中途丢失上下文、重复执行步骤，或在没有恢复机制的情况下崩溃。DAG 优化的是依赖关系，但当依赖本身变得盘根错节时，图结构反而成为认知负担。

Temporal 的 Workflow Activity：长周期 durable，但过于底层

Temporal（2025 年估值 50 亿美元，Netflix 日运行 10 万+ Workflow）解决的是另一个维度的问题——长周期工作流的持久化执行。Temporal 将状态机隐式化：开发者写普通代码，平台管理状态持久化和转换。Netflix、Datadog、Stripe 用它处理需要数小时甚至数天的业务流程。

但 Temporal 的 Activity 模型本质上是细粒度的任务单元，适合微服务编排，却不擅长表达高层语义。正如 Temporal 官方博客所言：

"Unlike libraries such as Spring State Machine where you explicitly define states and transitions in code, with Temporal you write procedural code while the platform manages state persistence and transitions implicitly."—— Why Temporal replaces traditional state machines for distributed applications, 2025

隐式状态管理带来了强大的耐久性，但也意味着工程师无法在代码中直接看到"理解→设计→生成→质量→集成"这样的语义阶段。对于需要频繁人机协作的代码生成场景，这种"黑盒"特性反而降低了可观测性。

Ooder 的折中：宏观线性、微观并行

SceneGroup 的设计哲学是按语义分组，而非按依赖连线。Ooder 的最新 DevOps 实现将全链路抽象为 5 个语义阶段（Scene），而非 80+ 个离散节点：

在 DESIGN 阶段内部，Ooder 维护了 14 个 PipelineStep（如 IntentClassificationStep、EntityExtractionStep、ConfigGenerationStep、LlmFallbackStep 等），这些步骤在组内根据数据依赖形成局部的 DAG（PARALLEL_GROUPS）。但组与组之间是严格顺序的：KNOWLEDGE → CLARIFY → DESIGN → BUILD → REVIEW。

这种"宏观线性、微观并行"的结构对人类工程师极其友好。当出现问题时，工程师首先定位到语义阶段（"BUILD 阶段编译失败"），再深入具体的 PipelineStep（"ClsValidationStep 抛出异常"），而不是在一张 80+ 节点的拓扑图中寻找断点。

关键洞察：DAG 优化的是机器执行效率（依赖并行），SceneGroup 优化的是人类认知效率（语义边界）。当步骤数超过认知负荷阈值（约 7±2 个组），语义分组比依赖拓扑更具可维护性。

论点 2：意图驱动 > 完全自由的 LLM 调度

让 LLM 自由决策"下一步用哪个工具"是 ReAct 范式的精髓，但在有强结构约束的工程任务中（如代码生成），完全自由的 LLM 调度会带来不可预期的执行路径。

Ooder 意图驱动三层架构意图层 (Intent Layer)LLM 自由推断用户意图：CREATE_FORM / CREATE_NAV / CREATE_CHARTLLM模式层 (Pattern Layer)意图映射到预定义 Agent Chain：组件模板 + 事件枚举 + 合并补全策略Pattern Map执行层 (Execution Layer)NlpOrchestrator 统一编排：design / bridge / integrate / build / generate / intentOrchestrator灵活性确定性强约束弱约束分层解耦：意图灵活推断 + 执行路径确定

图 2：Ooder 意图驱动三层架构——意图由 LLM 推断，Loop 结构由模式映射

ReAct 的结构性缺陷

ReAct（Reasoning + Acting）允许 LLM 在每一步自主决定调用哪个工具、传递什么参数。这在开放域问答中表现优异，但在工程生成场景中，AxiomLogica 2026 年的基准测试揭示了严重问题：

"Autonomous DAGs delegate control flow decisions to the model itself... In production, under distribution shift, ambiguous tool outputs, or degraded context windows, the model enters recursive inference loops that burn token budget without advancing state."—— Production-Grade Agentic Workflows: LangGraph vs. Autonomous DAGs, 2026

测试数据显示，确定性状态机图相比自由形式的自治 DAG，可将灾难性 Agent 循环故障降低约 70%。LangGraph 通过显式状态结构和验证边（validated edges）解决这一问题，但其核心仍是"图"而非"语义"。

Ooder 的折中：意图推断 + 模式映射

Ooder 的做法是分层解耦：意图由 LLM 推断，但 Loop 结构由模式映射。具体而言：

1. 意图层（Intent Layer）：由 LLM 自由推断用户的自然语言意图（如 CREATE_FORM、CREATE_NAV、CREATE_CHART）。这一层保留 LLM 的灵活性，支持开放式输入。
2. 模式层（Pattern Layer）：意图被映射到预定义的 Agent Chain 模式。例如 CREATE_NAV 被映射到 NavTree 组件模板 + NavCallBack 事件枚举 + 9 个核心事件的合并补全策略。
3. 执行层（Execution Layer）：由 NlpOrchestrator 统一编排，通过 6 个标准化方法（design/bridge/integrate/build/generate/intent）执行，确保路径可观测、可重放、可审计。

NlpOrchestrator 作为统一门面，将 14 个 PipelineStep 和 5 个 DesignStage 收敛为 6 个高层语义操作。开发者不需要理解底层步骤的依赖关系，只需要理解"设计→桥接→集成"的业务语义。

这种架构既保留了 LLM 的灵活性（意图识别可随业务扩展），又保证了工程约束（代码生成必须遵循 ComponentType 枚举、容器组件规则、事件绑定规范）。

论点 3：人机回路是产品要求，不是补丁

真正交付到客户手上的 Agent 系统几乎都需要人机协作。GitHub Copilot 不是全自动写代码，而是"建议→开发者确认→应用"；Midjourney 不是一键出图，而是"提示→生成→选择→迭代"。

Temporal 的 Human-in-the-Loop 实践

Temporal 官方文档将"无限等待人工审批"（infinite wait support for human-in-the-loop approvals）列为核心特性。MMNTM 的技术蓝图指出：

"Temporal provides exactly-once semantics, infinite wait support for human-in-the-loop approvals, and time-travel debugging via complete audit trails."—— Temporal: The Durable Execution Engine for AI Agents, 2025

但 Temporal 的做法是将人工节点作为外部信号（Signal）注入 Workflow，本质上是在代码层面打补丁。开发者需要显式编写等待逻辑、超时处理、补偿事务。

SceneGroup 的内置人机回路

SceneGroup 将 ConfirmationCallback 内置到 Loop 关节点，让"用户介入"成为编排核的一等公民，而不是上层 UI 通过轮询拼出来的。

在 Ooder 的 5 段 Agent Chain 中，CLARIFY 阶段天然承担人机回路的职责：当意图置信度低于阈值，或字段存在歧义时，系统自动暂停执行，通过 ConfirmationCallback 向用户发起确认请求。用户确认后，对话状态通过 syncConversationContextToSceneGroup() 持久化到 SceneGroup.config，后续阶段从断点继续执行。

这种人机回路不是异常处理，而是正常控制流。正如 GitHub Copilot 的交互设计研究所示：最高效的 Agent 系统不是全自动的，而是"人类与 AI 共同驾驶"（Human-AI Co-piloting）。

论点 4：渐进式迁移高于一切

Ooder 已有 14 个 PipelineStep + 5 个 DesignStage + 2 个核心 Adapter 在生产环境稳定运行。任何新架构必须能包住而不是替换这些既有资产。

Strangler Fig Pattern：被验证的迁移策略

Martin Fowler 提出的 Strangler Fig Pattern（绞杀者模式）是现代软件架构迁移的黄金法则：通过逐步用新系统替代旧系统的功能，让旧系统"被绞杀"而非"被推翻"。

Ooder 的 SceneGroup 迁移严格遵循这一模式：

• 2 个 Adapter 实现"包"而非"重写"：PipelineStepAdapter 将旧的 PipelineStep 接口适配到 SceneGroup 的 Agent Chain；DesignStageAdapter 将 5 个 DesignStage 适配到新的语义阶段。
• 老路径标 @Deprecated 但仍然可用：旧的 NlpDesignService 直接调用路径保留，确保已有调用方不受影响。
• 新路径通过 Spring Boot 自动配置无侵入注册：SceneGroupLifecycleService、SceneAgentRouter、AgentChainOrchestrator 等核心组件通过 @ConditionalOnProperty 和 @AutoConfigureAfter 自动装配，无需修改现有配置。

这种迁移策略让重构能在不停机、不破坏既有调用方的情况下落地。旧系统的 14 个 PipelineStep 继续工作，新系统的 5 段 Agent Chain 逐步接管，最终通过配置切换完成迁移。

Ooder 最新 DevOps 全链路：从意图到编译的 5 阶段闭环

SceneGroup 不是理论抽象，而是贯穿 Ooder NLP 闭环的实战架构。以下是 2026 年 6 月最新的 DevOps 全链路实现：

图 3：5 段 Agent Chain 流程——从用户输入到闭环审计的完整链路

5 Phase 闭环验证

3 层验证循环与降级链

3 层验证循环 (MAX_VALIDATION_LOOPS = 3)Phase 1Phase 2Phase 3Phase 4Phase 5成功loopCount++验证失败降级链 (loopCount >= 3)NLP PipelineFunction Calling LoopConversationService失败返回错误诊断信息

图 4：3 层验证循环与降级链——失败自动回滚，耗尽后降级处理

3 层验证循环确保系统在复杂场景下的鲁棒性。当编译错误、文件缺失或 JSON 格式异常时，系统自动回滚并注入前次失败信息，指导 LLM 在下一轮生成中修复问题。

结论：语义边界是工程规模化的钥匙

LangGraph 的 DAG 是强大的，但它优化的是机器层面的依赖执行；Temporal 的 Workflow 是可靠的，但它隐藏了语义阶段的边界。当 Agent 系统从 Demo 走向生产、从 10 步扩展到 100 步、从实验室走向客户现场，人类工程师的认知负荷成为瓶颈。

SceneGroup 的核心洞察是：在工程生成这类强结构约束的领域，语义边界比依赖拓扑更重要。 将 14 个 PipelineStep 和 5 个 DesignStage 按 KNOWLEDGE→CLARIFY→DESIGN→BUILD→REVIEW 的语义分组，组内并行、组间顺序，既保留了局部优化的灵活性，又避免了全局拓扑的认知爆炸。

正如 AxiomLogica 的基准测试所示：确定性状态机可将灾难性循环故障降低 70%。SceneGroup 在此基础上更进一步——它不是约束自由度的牢笼，而是人类与 AI 共同理解的语义契约。

参考来源

• LangGraph Multi-Agent Orchestration: Complete Framework Guide + Architecture Analysis 2025
• LangGraph 开源项目的深度分析报告
• What is LangGraph? State, Agents, and Production Use Cases (2026)
• Production-Grade Agentic Workflows: LangGraph vs. Autonomous DAGs
• Why Temporal replaces traditional state machines for distributed applications
• Temporal: The Durable Execution Engine for AI Agents
• Choosing Between LangGraph, CrewAI, Temporal, and Custom Orchestration for Healthcare Agents
• Choosing Between GCP Workflows, AWS Step Functions, and Temporal for Stateful Workflow Orchestration
• Study of Workflow Orchestration Engines: Open-Source & Cloud-Native Solutions
• Ooder A2UI 平台源码：\a2ui\scene-engine、\a2ui\ooder-pro