分阶段智能体架构当 LLM 规划遇上 Workflow 编排

从 ooderAgent 的设计实践出发，探讨如何将 LLM 的动态规划能力与 Workflow 的结构化分阶段定义相结合，构建更高效、更可控的 Agent 交互体验。

🧠 LLM Planning⚙️ Workflow Orchestration🔄 Phased Architecture👥 Human-in-the-Loop

一、问题的起源：全量规划与渐进认知的矛盾

当用户向 Agent 说"帮我创建一个销售数据图表页面"时，Agent 面临的第一个决策是：应该在什么时候规划多少步骤？

两种极端策略各有缺陷：

策略 A — LLM 全量规划：LLM 在首次对话中一次性生成全部执行步骤（比如 10 步），然后按序执行。问题是：在意图尚未确认时，规划建立在假设之上；用户一旦在第二步提出调整，后续八步全部失效。这就像建筑设计师在未了解业主需求时就画出了全部施工图。

策略 B — Workflow 硬编码：用预定义的流程图严格约束每一步的执行顺序。问题是：流程缺乏弹性，无法适应意图的模糊性和多变性。这就像要求所有建筑都按同一张图纸施工。

核心矛盾

LLM 擅长基于上下文动态推理，但缺乏全局结构约束；Workflow 擅长结构化编排，但缺乏运行时自适应能力。我们需要的是一种融合机制——让 Workflow 提供阶段边界和产出物契约，让 LLM 在每个阶段内自由规划。

二、阶段（Phase）：结构化与灵活性的平衡点

2.1 阶段的本质

阶段不是一个简单的分组标签，而是一个具有执行语义的结构单元。在 ooderAgent 的设计中，阶段（Phase）具备六个核心属性：

2.2 五阶段通用模型

以组件生成场景为例，一个典型的 Agent 任务可以拆解为五个阶段：

关键洞察

阶段之间通过产出物契约衔接，而非通过活动 ID 硬编码。Phase 2 的入口条件是confirmedIntent != null，而非ic_intent_classify.completed == true。这种设计让 LLM 在阶段内可以自由调整活动顺序，只要最终交付了契约规定的产出物。

三、LLM 规划与 Workflow 编排的分工

3.1 各司其职的边界

在 ooderAgent 的设计中，LLM 和 Workflow 的分工不是简单的"谁替代谁"，而是在不同维度上各自发挥优势：

3.2 Plan 的作用域限定

这是融合机制最关键的设计决策：LLM 只规划当前阶段内的活动，不预测后续阶段。

核心原则

信息不足时不做过度规划。在意图确认之前，LLM 只需要知道"后续有规划、设计、集成、部署四个阶段"就够了；意图确认之后，LLM 才基于确认的意图生成规划阶段的详细步骤。

3.3 FC-Loop：LLM 在阶段内的执行引擎

在阶段内部，LLM 的执行由 Function Calling Loop（FC-Loop）驱动：

在分阶段架构下，FC-Loop 的执行范围被限定在当前阶段的活动内。当 FC-Loop 完成当前活动后，引擎检查是否到达阶段出口，如果是则触发 HUMAN 确认或自动推进到下一阶段。

四、分阶段对话的 UI/UE 交互设计

4.1 三层展现模型

4.2 HUMAN 确认的交互范式

在分阶段架构下，HUMAN 确认（人工介入）是阶段推进的关键决策点。ooderAgent 定义了四种 HUMAN 子模式：

4.3 AutoPass：无感确认的体验优化

不是所有 HUMAN 确认都需要用户介入。autoPass 机制允许特定条件下的 HUMAN 节点自动通过：

Java// ActivityDefinition.isAutoPass()
public boolean isAutoPass() {
    Object val = config.get("autoPass");
    if (val == null) return false;
    if (val instanceof Boolean) return (Boolean) val;
    if (val instanceof String) return "true".equalsIgnoreCase((String) val);
    return false;
}

AutoPass 的典型应用场景：Designer 模式下理解阶段的意图确认可以自动通过；低风险操作的字段确认可以自动通过；HUMAN 确认超时后按 noMatchPolicy 自动处理。

4.4 焦点管理与阶段切换

分阶段架构解决了一个核心 UX 问题：焦点跳跃。四条规则：

1. 阶段内焦点锁定：当前阶段只有一个焦点活动（running 或 paused）
2. 阶段切换时自动聚焦：阶段推进时，焦点自动滚动到新阶段的首个活动
3. 历史阶段只读：已完成阶段折叠归档，点击可展开查看但不抢焦点
4. 子流程焦点嵌入：子流程的焦点活动嵌入到主线 SUBPROCESS 活动卡内，不独立抢焦点

五、流程定义与阶段声明的对齐

5.1 从"显示标签"到"执行语义"

在 ooderAgent 的早期设计中，阶段概念仅存在于 displayAnnotation.classification 字段中，作为前端渲染的标签使用。分阶段架构将阶段从"显示标签"升级为"执行语义单元"：

Java// ProcessDefinition.java — 新增 phases 字段
@BpmField(label = "阶段定义", type = "grid", section = "阶段编排")
private List<PhaseDefinition> phases = new ArrayList<>();

// PhaseDefinition.java — 阶段结构定义
public class PhaseDefinition {
    private String phaseId;              // 阶段ID: phase_understand
    private String displayName;          // 显示名: 理解
    private String classification;       // 分类: UNDERSTAND
    private String entryCondition;       // 入口条件: confirmedIntent != null
    private String startActivityId;      // 入口活动: ic_consume_agent_route
    private String exitHumanActivityId;  // 出口HUMAN: human_intent_confirm
    private List<String> producedOutputs;// 产出物: [confirmedIntent]
    private boolean autoAdvance;         // 自动推进: true
}

// ActivityDefinition.java — 新增 phaseRef 字段
@BpmField(label = "所属阶段", type = "select")
private String phaseRef;  // 如: "phase_understand"

5.2 产出物契约：阶段间的松耦合

5.3 流程定义的 JSON 声明

JSON{
  "definitionId": "intent-dispatch",
  "phases": [
    {
      "phaseId": "phase_understand",
      "displayName": "理解",
      "order": 1,
      "classification": "UNDERSTAND",
      "startActivityId": "ic_consume_agent_route",
      "exitHumanActivityId": "human_intent_confirm",
      "producedOutputs": ["confirmedIntent"],
      "autoAdvance": true
    },
    {
      "phaseId": "phase_plan",
      "displayName": "规划",
      "order": 2,
      "classification": "PLAN",
      "startActivityId": "ic_plan_generate",
      "exitHumanActivityId": "ic_user_confirm",
      "producedOutputs": ["approvedPlan"],
      "autoAdvance": true
    },
    {
      "phaseId": "phase_design",
      "displayName": "设计",
      "order": 3,
      "classification": "DESIGN",
      "startActivityId": "ic_dispatch_to_sg",
      "exitHumanActivityId": "human_design_approval",
      "producedOutputs": ["generatedComponent"],
      "autoAdvance": false
    }
  ]
}

注意 autoAdvance 的差异：理解阶段和规划阶段自动推进（HUMAN 确认后直接进入下一阶段），设计阶段不自动推进（需要人工审批后才能进入集成阶段）。

六、前后端对齐：事件驱动的阶段推进

6.1 阶段推进的状态机

6.2 SSE 事件驱动的前后端同步

6.3 统一活动树的渲染

分阶段架构下，时间轴、plan、子流程三个视图通过统一活动树（Unified Activity Tree）合并渲染：

JavaScript// 阶段推进事件处理
case 'phase_advanced':
    var fromPhase = eventData.fromPhaseId;
    var toPhase = eventData.toPhaseId;
    
    // 1. 归档当前阶段(折叠)
    host._archivePhase(fromPhase);
    // 2. 切换当前阶段
    host._currentPhaseId = toPhase;
    // 3. 重新渲染阶段导航条
    host._renderPhaseNavigator();
    // 4. 渲染新阶段的时间轴
    host._renderPhaseTimeline(toPhase);
    // 5. 焦点锁定到新阶段首个活动
    host._lockFocus(toPhase + '_first', 'phase_advance');
    break;

这种设计消除了三视图割裂的问题：子流程不再独立渲染为顶层项，而是嵌入到主线 SUBPROCESS 活动卡内；plan 仅展示当前阶段的活动，不展示后续阶段；时间轴与 plan 通过同一数据源渲染，保持一致。

七、复杂度自适应：从单阶段到多阶段

不是所有任务都需要五阶段。ooderAgent 根据流程复杂度自动决定阶段粒度：

当 ProcessDefinition.phases 为空时，流程自动降级为单阶段模式，所有活动平铺执行——这保证了向后兼容性。

八、融合的价值：从"两层皮"到"一张图"

分阶段架构将 LLM 规划和 Workflow 编排融合为"一张图"：

这种转变不是简单的技术优化，而是交互范式的升级：从"Agent 替你做"到"Agent 和你一起做"。每个阶段边界都是一次人机协作的握手——LLM 提供推理和建议，用户确认或调整，然后推进到下一阶段。

结语

分阶段智能体架构的核心思想是：让 LLM 在合适的时机规划合适的范围，让 Workflow 在合适的边界提供合适的约束。阶段（Phase）作为两者的融合点，既不是纯粹的 LLM 输出，也不是纯粹的 Workflow 硬编码，而是一种结构化的弹性——有边界但不死板，有自由但不失控。

ooderAgent 的实践表明，这种融合不仅解决了"两层皮"的问题，更重要的是改变了 Agent 与用户的交互范式：从全量规划到渐进确认，从被动等待到主动参与，从黑盒执行到阶段透明。这正是 Agent 从"工具"走向"伙伴"的关键一步。

ooderAgent · Phased Agent Architecture · 2026

从"Agent 替你做"到"Agent 和你一起做" — 每个阶段边界都是一次人机协作的握手