对比"同步硬编码管道"与"Workflow-Skills 标准流程引擎"在时序、前后端架构、事件通道、分布式多 Agent 协作维度的差异与优势。

一、两种架构哲学的碰撞

在对话式 AI 工程化构建场景中，项目往往需要多个专业 Agent 协同完成——RAG 知识查询 Agent 负责理解需求，DDD 设计 Agent 负责领域建模，代码生成 Agent 负责工程落地，代码审查 Agent 负责质量保障。这些 Agent 可能运行在不同的进程、不同的服务甚至不同的机器上。

如何让这些 Agent 有序协作、高效通信、共享上下文？这是衡量一个流程架构优劣的核心标尺。两种常见的实现路径：

维度	普通管道推进（Ordinary Pipeline）	Workflow-Skills 架构
执行模型	同步方法，单线程阻塞	异步 Activity Loop，引擎驱动
Agent 协作	硬编码调用，紧耦合	原生分布式松耦合
Agent 通信	方法参数传递	VFS 共享上下文 远程桥接
阶段管理	手写 stageIndex，自推 flow_step	PhaseManager 自动管理，阶段即为 Agent 编排计划
事件通道	多套专用事件类型（50 ）	统一标准事件体系（8 种）
前端渲染	专用事件处理器 手动渲染	通用渲染引擎 契约驱动
契约定义	散落在代码中	definition.json 单一事实源
维护成本	N 个管道 = N 份代码	管道间共享基础设施

本文从分布式多 Agent 协作这一全新视角切入，深入剖析两种架构在 Agent 通信、时序、前后端交互、事件通道等维度的差异与优势。

二、原生分布式多 Agent 协作：Workflow-Skills 的核心竞争力

普通管道最大的架构缺陷不是"慢"，而是天然的紧耦合——所有阶段在同一个 Orchestrator 的同步方法中串行执行，Agent 之间通过方法参数传递数据，无法支持跨进程、跨服务的分布式协作。

而 Workflow-Skills 架构的 Activity Loop PhaseManager VFS 三位一体，提供了原生分布式多 Agent 协作能力：

图 1：Workflow-Skills 分布式多 Agent 协作架构 —— 每个 Agent 独立部署，通过 SkillFlowEngine 统一调度，PhaseManager 确保障序性

2.1 Agent 注册：每个 Agent 是一个 ActivityExecutor

在 Workflow-Skills 中，每个 Agent 就是一个独立的 ActivityExecutor，通过 skillId 注册到引擎。Agent 可以是本地进程，也可以是远程服务——这对引擎是完全透明的。

代码语言：ja vascript

复制

// ===== 多 Agent 注册 =====// 每个 Agent 通过 skillId 注册到 SkillFlowEngine// 引擎运行时通过 skillId 查找到对应的 ActivityExecutor 并执行@PostConstructpublic void init() {// RAG 知识查询 Agent（本地）skillFlowEngine.registerActivityExecutor("rag-knowledge-query",this::executeRagQuery);// DDD 设计 Agent（本地）skillFlowEngine.registerActivityExecutor("ddd-infer",this::executeDddInfer);// 代码生成 Agent（远程—通过 RemoteWorkflowBridge 桥接）skillFlowEngine.registerActivityExecutor("codegen-entity",ctx -> remoteCodeGenAgent(ctx, "entity"));// 代码审查 Agent（远程）skillFlowEngine.registerActivityExecutor("code-review",ctx -> remoteCodeReviewAgent(ctx));}// ===== Agent 执行器实现 =====private Map executeRagQuery(SkillExecutionContext ctx) {String query = ctx.getContextValue("userInput");// 调用 RAG 知识库查询List schemas = ragService.queryTableSchema(query);// 将结果写入 VFS 共享上下文vfsClient.write("/agents/rag/analysis.json", schemas);return Map.of("status", "completed", "result", schemas);}private Map executeDddInfer(SkillExecutionContext ctx) {// 从 VFS 读取 RAG Agent 的产出String analysisJson = vfsClient.read("/agents/rag/analysis.json");// 执行 DDD 领域分析DddDesign design = dddService.inferDesign(analysisJson);// 写入 VFS 供下一个 Agent 读取vfsClient.write("/agents/ddd/design.json", design);return Map.of("status", "completed");}

与普通管道的对比：

代码语言：ja vascript

复制

// ===== 普通管道：Agent 间硬编码紧耦合 =====// 所有 Agent 逻辑在同一个 Orchestrator 中硬编码串联// 无法跨进程，无法独立部署，一个 Agent 升级要改整个编排器public void orchestrate(...) {// Stage 0: 意图分析（内嵌在编排器中）String intent = analyzeIntent(userInput);// Stage 1: 数据库连接（硬编码调用）Connection conn = connectDatabase(config);// Stage 2: 库表分析（同步阻塞）List tables = analyzeTables(conn);// Stage 3: 关系分析（方法直接调用）List relations = analyzeRelations(tables);// Stage 4: DDD 建议（紧耦合类调用）DddDesign design = dddService.suggestDesign(tables, relations);// ... 后续阶段同样硬编码}

2.2 Agent 通信：VFS 异步解耦 RemoteWorkflowBridge 同步协同

Workflow-Skills 提供了双通道 Agent 通信机制，覆盖不同的协作场景需求：

图 2：Agent 间上下文流转与通信 —— 以 DBFirst 建模为例，RAG Agent → DDD Agent → CodeGen Agent → Review Agent 通过 VFS 共享上下文，PhaseManager 确保障序性

通道 1：VFS 虚拟文件系统（异步解耦，默认首选）

每个 Agent 执行完毕后将产物写入 VFS，下一个 Agent 通过 VFS 路径读取。这是典型的异步通信、事件驱动模式，Agent 之间无需知道对方的存在，只需遵循 VFS 路径契约。

代码语言：ja vascript

复制

// ===== VFS 共享上下文 =====// Agent A 写入产物public class RagAgent {public void execute(SkillExecutionContext ctx) {// 查询数据库表结构知识AnalysisResult result = ragService.query(ctx.getUserInput());// 写入 VFS（路径约定：/agents/{agentId}/{output-name}.json）vfsClient.write("/agents/rag/analysis.json", result.toJson());// 引擎自动推进阶段，下一个 Agent 将读取此文件}}// Agent B 读取 Agent A 的产物（可能在不同进程/服务中）public class DddAgent {public void execute(SkillExecutionContext ctx) {// 从 VFS 读取 RAG Agent 的分析结果String json = vfsClient.read("/agents/rag/analysis.json");AnalysisResult ragResult = AnalysisResult.fromJson(json);// 基于 RAG 分析结果进行 DDD 设计DddDesign design = dddService.design(ragResult);vfsClient.write("/agents/ddd/design.json", design.toJson());}}// Agent C 读取 Agent B 的产物（可能在不同机器上）public class CodeGenAgent {public void execute(SkillExecutionContext ctx) {// 从 VFS 读取 DDD 设计产出String json = vfsClient.read("/agents/ddd/design.json");DddDesign design = DddDesign.fromJson(json);// 基于设计生成代码List files = codeGenService.generate(design);// 写入生成的代码文件for (GeneratedFile f : files) {vfsClient.write("/agents/codegen/" f.getPath(), f.getContent());}}}

通道 2：RemoteWorkflowBridge（同步协同，强一致场景）

对于需要即时响应的场景，Agent 可通过 RemoteWorkflowBridge 直接调用另一个 Agent 的服务接口。桥接器封装了远程调用的序列化、网络传输、重试和降级逻辑。

代码语言：ja vascript

复制

// ===== RemoteWorkflowBridge 远程调用 =====// Agent A 通过远程桥接调用 Agent B 的服务public class ReviewAgent {@Autowiredprivate RemoteWorkflowBridge remoteBridge;public Map execute(SkillExecutionContext ctx) {// 读取代码生成 Agent 的产物String code = vfsClient.read("/agents/codegen/Entity.ja va");// 远程调用代码审查 Agent（可能运行在 aiserver 上）Map reviewResult = remoteBridge.executeActivity("code-review-service",// 目标服务名Map.of("code", code,"language", "ja va","standards", List.of("naming", "structure", "security")),RetryConfig.builder().maxAttempts(3).exponentialBackoff(500, 1500)// 500ms/1000ms/1500ms.build());// 将审查结果写入 VFSvfsClient.write("/agents/review/review-result.json", reviewResult);return Map.of("status", "completed", "review", reviewResult);}}// RemoteWorkflowBridge 实现要点// 1. 封装 HTTP/WS 远程调用，对 Agent 透明// 2. 内置重试机制（最多 3 次，指数退避）// 3. 健康检查：连续 3 次失败标记为不可用// 4. 降级：远程不可用时走本地 fallback 逻辑

2.3 PhaseManager：Agent 编排的"交通指挥"

多 Agent 协作的关键是保序性——RAG 查询必须在 DDD 设计之前，代码生成必须在 DDD 设计之后。PhaseManager 通过 definition.json 中的 phases 定义，自动管理 Agent 的执行顺序：

代码语言：ja vascript

复制

// ===== definition.json 中的阶段定义 =====// 每个阶段绑定一个或多个 Agent 的活动// PhaseManager 自动按阶段顺序推进，确保 Agent 间协作有序"phases": [{"phaseId": "phase_understand","displayName": "理解阶段","stage": 0,"autoAdvance": true,"activities": ["rag-knowledge-query", "intent-analyze"]},{"phaseId": "phase_design","displayName": "设计阶段","stage": 1,"autoAdvance": true,"exitHumanActivityId": "human_design_confirm","activities": ["ddd-infer", "entity-lock"]},{"phaseId": "phase_build","displayName": "构建阶段","stage": 2,"autoAdvance": true,"activities": ["codegen-entity", "codegen-repo", "codegen-api"]},{"phaseId": "phase_review","displayName": "审查阶段","stage": 3,"autoAdvance": false,"exitHumanActivityId": "human_review_approve","activities": ["code-review", "quality-check"]}]// ===== PhaseManager 自动管理 =====// PhaseManager.onProcessStarted() → 注入 phase_understand 为初始阶段// PhaseManager.onActivityCompleted() → 检测所有活动完成后推进到下一阶段// PhaseManager.onActivityPaused() → 检测出口 HUMAN，暂停阶段等待用户确认// 自动推送 phase_started / phase_advanced / phase_paused 事件

PhaseManager 的核心接口设计：

代码语言：ja vascript

复制

// ===== PhaseManager 核心接口 =====// 三个关键 hook 点，分别在流程启动、活动完成、活动暂停时触发public class PhaseManager {/** context 中的阶段状态字段 */public static final String CTX_CURRENT_PHASE = "_current_phase";public static final String CTX_PHASE_STATUSES = "_phase_statuses";/** * ★ 流程启动后调用 — 注入初始阶段，推送 phase_started 事件 * 若流程未启用分阶段(phases 为空)，则跳过(兼容旧流程) */public void onProcessStarted(ProcessInstance instance,ProcessDefinition definition) {if (definition == null || !definition.hasPhases()) return;PhaseDefinition firstPhase = definition.getOrderedPhases().get(0);// 注入当前阶段到 contextinstance.getContext().put(CTX_CURRENT_PHASE, firstPhase.getPhaseId());// 初始化所有阶段状态：第一个为 running，其余为 pendingMap statuses = initPhaseStatuses(definition);instance.getContext().put(CTX_PHASE_STATUSES, statuses);// 推送 phase_started 事件eventPublisher.firePhaseStarted(instance, firstPhase, definition);}/** * ★ 活动完成后调用 — 检测是否需要阶段推进 * Case 1: 出口 HUMAN 完成 → 若 autoAdvance 则推进 * Case 2: 无出口 HUMAN 当前阶段所有活动完成 → 推进 */public boolean onActivityCompleted(ProcessInstance instance,ActivityDefinition actDef,ProcessDefinition definition) {if (!hasPhases(definition)) return false;PhaseDefinition currentPhase = getCurrentPhase(instance, definition);if (isExitHumanCompleted(currentPhase, actDef)|| isAllActivitiesDone(currentPhase, instance)) {advanceToNextPhase(instance, currentPhase, definition);return true;}return false;}/** * ★ 活动暂停后调用 — 检测是否为阶段出口 HUMAN * 匹配出口 HUMAN 活动 ID 时，标记阶段为 paused 并推送事件 */public void onActivityPaused(ProcessInstance instance,ActivityInstance actInstance,ActivityDefinition actDef,ProcessDefinition definition) {if (!hasPhases(definition)) return;PhaseDefinition currentPhase = getCurrentPhase(instance, definition);if (actDef.getActivityId().equals(currentPhase.getExitHumanActivityId())) {setPhaseStatus(instance, currentPhase.getPhaseId(), "paused");eventPublisher.firePhasePaused(instance, currentPhase,actInstance, definition);}}}

三、全景架构对比

图 3：前后端架构全景对比 —— 前端层、SSE 事件通道、后端层、数据层四层对比

3.1 普通管道推进架构

代码语言：ja vascript

复制

用户输入│▼IntentDispatchScene│[isThreeBranchFlow=true] 绕过标准引擎▼RadChatScene (降级路径)│▼XxxFirstOrchestrator.orchestrate()│├── Stage 0: 同步执行 → fire专用事件├── Stage 1: 同步执行 → fire专用事件│ ...└── Stage 9: 同步执行 → fire专用事件 │ ▼FlowEventPublisher │ ├── 路径A: fireDbFirstEvent → flow_dbfirst_* (专用事件) │→ SseEventPushListener → 前端 _handleDbFirstEvent() │ └── 路径B: pushStep → flow_step (通用事件)→ DBFirstFlowListener (冗余增强)→ SseEventPushListener → 前端 _handleFlowSSEEvent()

关键特征：编排器是同步 Ja va 方法，10 个阶段顺序执行，一个阶段卡住则全部阻塞；同一阶段进度通过两条路径推送，前端重复渲染；每个管道维护一套专用事件类型和前端处理器。Agent 间通过硬编码方法调用耦合，无法分布式部署。

3.2 Workflow-Skills 架构

代码语言：ja vascript

复制

用户输入│▼IntentDispatchScene│[统一 switch_scene_flow]▼SkillFlowEngine (Activity Loop)│├── PhaseManager（多 Agent 编排调度）│ ├── onProcessStarted → 注入初始阶段│ ├── onActivityCompleted → 检测阶段推进│ ├── onActivityPaused → 检测出口 HUMAN│ └── 推送 phase_started/advanced/paused/rolled_back│├── Activity Loop（Agent 调度循环）│ ├── 取下一个待执行的 Agent 活动│ ├── 通过 skillId 找到对应的 ActivityExecutor│ │ └── Agent 执行器（本地或远程）│ │ ├── RAG Agent → 写入 VFS│ │ ├── DDD Agent → 读取 VFS，写入 VFS│ │ ├── CodeGen Agent → 远程桥接(aiserver)│ │ └── Review Agent → 读取 VFS，远程桥接│ └── 活动完成 → PhaseManager 检测阶段推进│├── VFS 虚拟文件系统（Agent 间共享上下文）│ └── /agents/{agentId}/{output}.json│└── 统一事件通道├── flow_step (活动级进度)├── phase_* (阶段级生命周期)├── flow_plan (流程骨架)└── flow_complete (流程结束) → SseEventPushListener (单一透传) → 前端 _handleFlowSSEEvent() → _renderActivitiesGroupedByPhase()

关键特征：异步 Activity Loop，各 Agent 独立执行；PhaseManager 自动管理 Agent 协作顺序；VFS 作为 Agent 间共享上下文；RemoteWorkflowBridge 支持跨进程/跨服务 Agent 调用；统一事件通道，前端统一消费。

四、时序深度对比：同步阻塞 vs 异步 Activity Loop

图 4：SSE 事件时序对比 —— 左：同步阻塞编排，human_confirm 卡死全部；右：异步 Loop，仅暂停单个 Agent 活动

4.1 普通管道：同步阻塞，Agent 无法独立响应

代码语言：ja vascript

复制

时间线 →───────orchestrate() 开始│├── Stage0: intentAndPath()│ ├── pushStep("executing")│ ├── fireStage0IntentAndPath()→ flow_dbfirst_intent_detected│ ├── human_confirm (阻塞) ← 此时所有 Agent 都挂起!│ └── pushStep("completed")│├── Stage1: connect()│ ├── pushStep("executing")│ ├── fireStage1Connect()│ └── pushStep("completed")││... 阶段 2-9 依次同步执行 ...│└── orchestrate() 结束问题：1. 同步阻塞：human_confirm 卡住所有 Agent，无法处理其他流程2. 紧耦合 Agent：Agent 间通过方法参数传递，无法跨进程3. 无法回滚：一个 Agent 失败，已完成的 Agent 工作无法回退4. 无阶段语义：flow_step 只有 executing/completed，无阶段概念

4.2 Workflow-Skills：异步 Activity Loop，Agent 独立调度

代码语言：ja vascript

复制

时间线 →───────SkillFlowEngine 启动 Activity Loop（多 Agent 调度循环）│├── Activity #1: RAG Agent (rag-knowledge-query)│ ├── PhaseManager.onActivityStarted → phase_started(phase_0)│ ├── Agent 执行：查询知识库 → 写入 VFS│ ├── PhaseManager.onActivityCompleted → phase_advanced(phase_0→phase_1)│ └── Activity #1 完成，Loop 取下一个│├── Activity #2: DDD Agent (ddd-infer)│ ├── PhaseManager.onActivityStarted → phase_started(phase_1)│ ├── Agent 执行：读取 VFS → DDD 设计 → 写入 VFS│ ├── human_confirm (仅暂停此 Agent，Loop 继续运行)│ └── 恢复后 → PhaseManager.phase_advanced(phase_1→phase_2)││ Loop 在 DDD Agent 暂停期间，可调度其他流程实例│├── Activity #3: CodeGen Agent (codegen-entity)│ ├── PhaseManager.onActivityStarted → phase_started(phase_2)│ ├── Agent 执行：远程桥接(aiserver) → 代码生成│ └── 写入 VFS → PhaseManager 推进阶段│├── Activity #4: Review Agent (code-review)│ ├── PhaseManager.onActivityStarted → phase_started(phase_3)│ ├── Agent 执行：读取 VFS → 远程审查 → 写入 VFS│ └── PhaseManager 推进 → flow_complete│└── 所有 Agent 完成优势：1. 异步非阻塞：human_confirm 仅暂停单个 Agent，Loop 可调度其他流程2. 松耦合 Agent：通过 VFS 共享上下文，Agent 可独立部署3. 可回滚：PhaseManager 支持 phase_rolled_back，按 Agent 阶段回退4. 五种阶段语义：phase_started/advanced/paused/rolled_back/summary

五、前端架构深度对比

5.1 事件注册与消费模式

普通管道：N 个管道注册 N 套事件监听器，每个事件对应一个专用处理器

代码语言：ja vascript

复制

// 普通管道：3 个管道 × 17 事件 = 50 个 addEventListener// 每个 Agent 对应一套专用事件类型，前端需要为每个 Agent 注册监听器eventSource.addEventListener('flow_dbfirst_intent_detected', handler);eventSource.addEventListener('flow_dbfirst_connect_start', handler);eventSource.addEventListener('flow_dbfirst_connect_done', handler);// ... 17 个 flow_dbfirst_* 事件eventSource.addEventListener('flow_viewfirst_*', handler); // 另一套eventSource.addEventListener('flow_designerfirst_*', handler);// 第三套// 每个事件回调专用处理器，内部分支逻辑_handleDbFirstEvent(data) // 根据 eventType 做不同渲染_handleViewFirstEvent(data) // 另一套逻辑_handleDesignerFirstEvent(data) // 第三套逻辑// 问题：Agent 的专用事件类型与前端代码紧耦合// 新增一个 Agent = 新增 10 个 addEventListener 专用 handler

Workflow-Skills：统一事件通道，一个通用处理器

代码语言：ja vascript

复制

// Workflow-Skills：固定就是 8 类标准事件，和 Agent 数量没有关系 // 不管后面挂了多少个 Agent，前端注册这 8 个事件监听器就够了 eventSource.addEventListener('flow_step', handler); // 活动级步骤进度 eventSource.addEventListener('flow_plan', handler);// 流程骨架 eventSource.addEventListener('flow_complete', handler);// 流程结束 // phase_* 事件统一交给 _handleFlowSSEEvent 处理： // phase_started → 记录当前阶段 ID，同时初始化 phases 数组 // phase_advanced → 将旧阶段标记为 done，新阶段切到 running // phase_paused → 阶段状态标记为 paused（出口 HUMAN） // phase_rolled_back → 阶段状态标记为 rolled_back // phase_summary → 保存阶段总结，包括产出物和耗时 _handleFlowSSEEvent(data) // 统一处理器，按 eventData.type 分发 // 后续即便继续新增 Agent，前端代码也不用跟着改，事件类型始终不变

5.2 前端渲染架构差异

普通管道的处理方式更直接：每个阶段都手动追加一条 timeline 记录，不做阶段分组。

代码语言：ja vascript

复制

// 普通管道：手动渲染 timeline，每个 Agent 独立渲染_handleDbFirstEvent: function(data) {var meta = data.meta || host._inferDefaultMeta(dbfirstEventType);var stage = data.stage != null data.stage : (meta.stage != null meta.stage : '');host._ensureSubFlowInstance(data.processInstId, 'dbfirst-build', ...);// 手动追加 timeline 条目，无阶段分组概念host._appendTimelineItem(data.processInstId, data.activityInstId, 'step', {title: stage !== '' ('Stage' stage ': ' meta.label) : meta.label,body: bodyText, status: meta.status || 'running', ...});// 重复追加：同一个阶段从两个路径推送，渲染两次}

Workflow-Skills：通用分阶段渲染引擎，Agent 无关

代码语言：ja vascript

复制

// Workflow-Skills：通用渲染，按阶段分组，与 Agent 类型无关_renderActivitiesGroupedByPhase: function(inst, activities, flowKey, nestLevel, focusedAid) {// 三种渲染模式，由 phase_* 事件自动填充的 inst.phases 数组驱动：// running/paused → 展开：详细活动卡片 阶段时间线// done → 折叠：可展开查看历史活动// pending → 折叠大纲：仅显示阶段名 活动数量//// 此外，_advanceFlowPhase 管理流程级 phase（plan → run → history）// 当第一个 flow_step 到达时推进 plan→run，flow_complete 推进 run→history//// 关键：渲染引擎不关心 Agent 的具体类型，只关心 phases 数组// 新增 Agent 只需在 definition.json 中定义阶段，前端自动渲染}

5.3 前端界面交互结构对比

图 5：前端界面交互结构对比 —— 左：普通管道平面列表，重复条目、无分组、50 事件；右：Workflow-Skills 阶段分组，展开/折叠、进度条、8 标准事件

普通管道 — 平面列表式时间线：

所有 Agent 的阶段按时间顺序平铺，无视觉分组，用户无法区分"这是哪个 Agent 的输出"同一阶段出现两次（双路径推送），用户困惑无法直观感知"当前在哪个 Agent 执行"50 事件类型需手动注册和维护，新增 Agent 时前端代码膨胀

Workflow-Skills — 阶段分组式渲染：

阶段分组可视化：每个 Agent 对应一个阶段分组，运行时展开（显示详细活动卡片），完成后折叠（显示摘要）进度条直观显示 Agent 协作推进比例无重复条目，事件来源单一8 种标准事件类型，与 Agent 数量无关，新增 Agent 前端无需修改_advanceFlowPhase 管理 plan→run→history 三阶段生命周期

六、后端架构深度对比

6.1 执行引擎

维度	普通管道	Workflow-Skills
执行模型	同步方法调用，单线程阻塞	异步 Activity Loop，事件驱动
Agent 调度	Orchestrator 手写 for 循环，紧耦合	SkillFlowEngine 自动调度，松耦合
Agent 部署	必须在同一进程内	支持本地/远程/跨进程任意部署
Agent 通信	方法参数传递	VFS 异步解耦 RemoteWorkflowBridge 同步协同
失败隔离	一个 Agent 失败 → 全部失败	单 Agent 失败 → 仅标记该活动，流程继续或走降级路由
human_confirm	阻塞主线程，所有 Agent 挂起	Activity 暂停，Loop 处理其他流程
回滚能力	无（成功后无法回退）	PhaseManager 支持 phase_rolled_back，按 Agent 阶段回退
扩展性	新增 Agent = 新写 Orchestrator 代码	新增 Agent = 注册 ActivityExecutor 定义阶段

6.2 Agent 活动定义与运行时路由

Workflow-Skills 通过 definition.json 中的 agentConfig 配置，为每个 Agent 活动指定执行模式、目标服务和降级策略：

代码语言：ja vascript

复制

// ===== definition.json 中的 Agent 活动定义 =====// 每个活动可以配置不同的执行模式{"activities": [{"activityId": "rag-knowledge-query","type": "TASK","config": {"stage": 0,"skillId": "rag-knowledge-query",// 本地执行，无需额外配置}},{"activityId": "codegen-entity","type": "TASK","config": {"stage": 2,"skillId": "codegen-entity","agentConfig": {"executorType": "remote",// 远程执行"targetService": "aiserver", // 目标服务"timeout": 60000,// 60s 超时"retryCount": 3, // 重试 3 次"retryBackoff": "EXPONENTIAL", // 指数退避"fallbackMode": "HUMAN_ESCALATE" // 降级到人工}}},{"activityId": "human_design_confirm","type": "HUMAN","config": {"stage": 1,"humanMode": "CONFIRM","prompt": "请确认 DDD 设计方案是否满足需求？"}}]}// ===== ActivityDispatcher 运行时路由 =====// 根据 agentConfig 自动选择执行方式public class ActivityDispatcher {public void executeActivity(ProcessInstance instance, ActivityInstance actInstance, ActivityDefinition actDef) {Object agentConfig = actDef.getConfigValue("agentConfig");if (agentConfig instanceof Map) {String executorType = (String) ((Map) agentConfig).get("executorType");if ("remote".equals(executorType)) {// 远程执行：通过 RemoteWorkflowBridge 桥接remoteBridge.execute(instance, actDef, (Map) agentConfig);return;}}// 本地执行：通过 skillId 查找 ActivityExecutorActivityExecutor executor = findExecutor(actDef.getSkillId());executor.execute(new SkillExecutionContext(instance, actDef));}}

6.3 阶段管理

普通管道：无阶段管理概念，全靠手写 stageIndex，且与定义文件错位

代码语言：ja vascript

复制

// 编排器手写 stageIndex，与 definition.json 的 config.stage 不一致pushStep(ctx, 0, "executing", "开始意图识别...");// stageIndex=0 匹配pushStep(ctx, 1, "executing", "开始连接..."); // stageIndex=1 匹配pushStep(ctx, 2, "executing", "开始用途导向...");// stageIndex=2 实际是 Stage1.5// 此后所有阶段编号与定义文件相差 1// 前端显示的 "Stage2" 与设计文档 "Stage1.5" 不一致

Workflow-Skills：PhaseManager 自动管理 Agent 阶段生命周期

代码语言：ja vascript

复制

// PhaseManager 会把 Agent 之间的协作阶段自动接起来 // 这里有三个关键 hook 点，分别对应三类典型的 Agent 协作场景： // 1. 流程启动时 —— 注入初始阶段，先把第一个执行的 Agent 定下来 PhaseManager.onProcessStarted() → phase_started(phase_0, "RAG 知识查询") // 2. 活动完成时 —— 判断是否该推进到下一个 Agent 阶段 PhaseManager.onActivityCompleted() → 当前阶段所有 Agent 活动完成 → phase_advanced(phase_0→phase_1) → 下一个 Agent（DDD 设计）开始执行 // 3. 活动暂停时 —— 检查是否命中 HUMAN 出口，等待用户确认 PhaseManager.onActivityPaused() → 匹配出口 HUMAN 活动 ID → phase_paused → 用户确认后 → phase_advanced // 阶段定义统一来自 definition.json 这个单一来源，整个 Agent 编排逻辑看起来会非常直观 // "phases": [ // { "phaseId": "phase_0", "displayName": "知识查询", "agent": "rag" }, // { "phaseId": "phase_1", "displayName": "领域设计", "agent": "ddd" }, // { "phaseId": "phase_2", "displayName": "代码生成", "agent": "codegen" }, // { "phaseId": "phase_3", "displayName": "代码审查", "agent": "review" } // ]

6.4 事件通道

普通管道的特点是：事件类型多、通道多、消费端也多，Agent 事件和前端之间往往是紧耦合的。

代码语言：ja vascript

复制

事件源 事件类型消费端───────── ──────────────DBFirst 管道 (内含所有 Agent)flow_dbfirst_* (17 种) → _handleDbFirstEventViewFirst 管道flow_viewfirst_* (类似数量)→ _handleViewFirstEventDesignerFirst 管道flow_designerfirst_* (类似)→ _handleDesignerFirstEvent=== 同时还有 ===flow_step (来自 pushStep) → _handleFlowSSEEvent DBFirstFlowListener问题：3 套专用事件 1 套通用事件 = 4 套通道并行 每个 Agent 的事件类型需要独立注册、独立维护 同一 Agent 阶段通过 2 条通道推送，前端重复渲染 新增 Agent 需要：新增 10 事件类型 新增前端 handler 新增 SSE 监听器

Workflow-Skills：统一事件通道，Agent 无关

代码语言：ja vascript

复制

事件源 事件类型消费端───────── ──────────────SkillFlowEngine flow_plan→ _handleFlowSSEEvent PhaseManagerflow_start → _handleFlowSSEEvent ActivityExecutorflow_step (活动级步骤)→ _handleFlowSSEEvent(任意 Agent)phase_started (阶段开始) → _handleFlowSSEEventphase_advanced (阶段推进)→ _handleFlowSSEEventphase_paused (阶段暂停)→ _handleFlowSSEEventphase_rolled_back (阶段回滚) → _handleFlowSSEEventphase_summary (阶段总结) → _handleFlowSSEEventflow_complete (流程结束) → _handleFlowSSEEvent优势：8 种标准事件类型，1 个消费者 所有 Agent 共用同一套事件体系，新增 Agent 无需新增事件类型 前端无需关心事件来自哪个 Agent，统一处理

七、优势量化分析

7.1 指标对比

指标	普通管道	Workflow-Skills	提升幅度
事件类型数量	50 (3 管道合计)	8 (标准类型，与 Agent 数无关)	84% 减少
前端处理器数量	3 个专用 1 个通用	1 个通用	75% 减少
后端编排器代码量	~3000 行 (3 管道合计)	~300 行 (3 执行器)	90% 减少
新增 Agent 工作量	1000 行代码 10 事件类型	注册 ActivityExecutor 定义阶段	极低
Agent 部署方式	必须在同一进程	本地/远程/跨进程任意	原生分布式
Agent 通信方式	方法参数传递（紧耦合）	VFS 异步解耦 / 远程桥接同步	松耦合
human_confirm 阻塞	阻塞所有 Agent	仅暂停单个 Agent	无阻塞
阶段回滚能力	不支持	支持 phase_rolled_back	新增能力
SSE 监听器注册数	50	8	84% 减少
跨服务 Agent 协作	不支持	RemoteWorkflowBridge 原生支持	新增能力

7.2 维护成本曲线

代码语言：ja vascript

复制

维护成本^│ 普通管道 (O(N))│ ─────────────│ / 每个新 Agent 增加 100% 成本│/(新事件类型 新前端 handler 新编排代码)│ /│/│ /│/│Workflow-Skills (O(1))│──────────────── 新增 Agent 成本趋近于 0│(仅注册执行器 定义阶段，前端和事件通道不变)│└───────────────────────────────────→ Agent 数量 1234

八、总结

8.1 什么时候选择普通管道？

流程固定不变，极少修改只服务于单一场景，无多 Agent 协作需求所有 Agent 可以在同一进程内运行团队规模小，无长期维护压力

8.2 什么时候选择 Workflow-Skills？

多 Agent 协作场景，Agent 需要独立部署/独立演进流程频繁调整，需要快速迭代需要阶段可视化、human_confirm、Agent 回滚等能力Agent 需要跨进程/跨服务通信关注长期维护成本和技术债务

8.3 核心结论

Workflow-Skills 架构的核心优势不在于"能跑"，而在于"原生分布式多 Agent 协作"：

Agent 协作优势：每个 Agent 是独立的 ActivityExecutor，通过 VFS 异步解耦或 RemoteWorkflowBridge 同步协同，Agent 可独立部署/独立演进。PhaseManager 确保障序性。新增 Agent 只需注册执行器 定义阶段，前端和事件通道无需修改。时序优势：异步 Activity Loop 替代同步编排，human_confirm 不再阻塞所有 Agent，单个 Agent 失败不影响全局。同一个引擎可同时调度多个流程实例中的不同 Agent。前端优势：通用渲染引擎代替专用分支，阶段分组可视化、展开/折叠、进度条等能力零成本获得。8 个标准事件类型替代 50 专用事件，与 Agent 数量无关。后端优势：PhaseManager 自动管理 Agent 协作阶段，definition.json 单一契约定义 Agent 编排顺序，新增 Agent 只需注册执行器。代码量从 ~3000 行降至 ~300 行。事件优势：统一事件通道，8 种标准事件类型，维护成本从 O(N) 降至 O(1)。前后端通过定义文件契约对齐，无需手动同步 Agent 事件类型。

OOD Studio · Workflow-Skills vs 普通管道推进 · 分布式多 Agent 协作架构深度解析 · 2026-08-11