WorkFlow 体系架构综合介绍

本文档整合了 WorkFlow 体系的核心组件：WorkFlowMethod （工作流引擎层）、FunctionExecution （函数执行层）、FunctionStorage （函数存储与桥接层）、WdUI（UI 框架层），阐述各层的职责、依赖关系、协同机制及整体架构设计。

序言：以复用性为基石的 WorkFlow 架构体系

软件复用的本质，并非代码的复制粘贴，而是逻辑规则的跨场景实例化。WorkFlow 体系正是这一理念的工程实践------它将工作流编排、函数执行、UI 渲染等能力封装为可复用的分层架构，使每一层都能独立演化、跨场景复用。而动态更新，正是这一架构区别于传统工作流框架的根本特征------它让复用从"设计时的静态模板"进化为"运行时的结构自适应"。

从第一性原理出发，引用关系是智能体架构的真正内核。 WorkFlowMethod 的图引擎统一正是这一理念的落地------以 GraphFoundation 边体系作为节点连接关系的唯一真实来源，构建了一张覆盖工作流节点的"活体引用图"。这张图不仅是静态的拓扑描述，更是运行时动态更新的操作基础：Symbol 定位插入、节点删除与重连、复合更新指令等能力，均基于边体系这一单一真实来源进行确定性变换，成为脱离大模型也能独立运行的可靠操作。

进一步看，框架与代码的本质是规则系统与规则实例的关系。 WorkFlowMethod 作为规则系统，定义了工作流编排、管线执行、循环决策的规则；而 JSON 配置文件与编程式构建的管线，则是这些规则在不同场景下的具体实例。这种递归抽象使预定义工作流模板（AI 图像生成、代码生成等）可在不同项目中直接复用。动态更新则进一步打破了"定义即固化"的局限------规则系统在运行时仍可被修改和扩展，使模板复用从"一次定义、多次使用"升级为"持续演化、按需调整"。

在 AI 编程的语境下，分离数据与逻辑是实现复用的关键原则。 FunctionStorage 的 JSON 工作流定义（结构化蓝图）与 FunctionExecution 的函数代码（可执行实体）的分离，正是这一原则的体现------JSON 定义作为稳定的"复用契约"，函数代码则基于契约进行精确填充。WorkflowLibrary 将 JSON 工作流同时注册到工作流函数体系与通用委托体系，实现了跨体系的复用。这种分离也为动态更新提供了天然的切入点：修改 JSON 定义即可在不触及函数代码的前提下调整工作流结构，实现了"数据层热更新、逻辑层零改动"。

复用性的最小载体是三要素模块单元。 FunctionStorage 的 WorkflowLibrary 将提示词（自然语言灵魂）、JSON 工作流定义（结构化蓝图）与函数代码（可执行实体）封装为自包含模块，三者可双向生成、相互迭代。每个模块不再是孤立的代码文件，而是拥有自我描述能力的生命单元，模块库由此从静态集合进化为可演化的生态系统。动态更新赋予这一生态系统以生命力------模块可在运行时被动态插入、替换或移除，使模块库的演化从"版本发布周期"加速为"实时热插拔"。

复用性还需要筛选机制来确保正确性。 WorkFlowMethod 的 LoopWorkflow 正是这一机制的体现------大模型作为"假说生成者"发散生成候选方案，RuleBased / LLMBased / Hybrid 三种选择策略作为"有效性裁判"层层过滤，迭代收敛至工程上可接受的精度。Hybrid 策略以规则覆盖标准路径、LLM 处理异常，兼顾了确定性与灵活性。动态更新与筛选机制形成闭环：筛选机制确保当前结构的正确性，动态更新则允许在运行时修正或优化结构，两者共同保障了工作流在持续变化中的结构完整性。

动态更新能力是 WorkFlowMethod 区别于传统工作流框架的核心差异化优势。 Temporal 和 Airflow 完全不支持运行时修改工作流结构，Camunda 和 Elsa 仅支持有限的部分更新。WorkFlowMethod 的图引擎统一以 GraphFoundation 边体系作为节点连接关系的唯一真实来源，通过 Symbol 定位插入、节点删除与重连、复合更新指令等机制，实现了原生、完整的运行时动态更新------无需重启、无需停服、无需手动同步平行数据结构。这一能力使工作流在运行过程中能够根据上下文变化实时调整拓扑结构，将复用性从"设计时的模板复用"扩展为"运行时的结构自适应"。

最终，复用性的最高形态是元语公理化。 WorkFlowMethod 作为框架公理系统，其完备性决定了工作流能力的上限------程序所能表达的定理集合，恰为框架公理系统的所有逻辑推论。AI 在其中进行可证明正确的增量更新，每一次提交都不会破坏系统的结构完整性。动态更新与元语公理在此交汇：公理系统定义了"什么可以变、什么不能变"的不变边界，动态更新则在这一边界内安全地执行结构变换。 这正是 WorkFlow 体系"配置即工作流、界面即交互"理念的理论根基。

从引用关系到规则系统，从数据契约到模块单元，从筛选机制到动态更新，再到元语公理------复用性贯穿了 WorkFlow 体系的全部层级，是连接确定性工程与 AI 灵活性的核心纽带。而动态更新，正是这一纽带中最具活力的环节------它让复用从静态契约升华为动态协作，让工作流从一次性编排进化为持续演化的生命体。

一、体系总览

1.1 分层架构

WorkFlow 体系采用分层架构，各层职责清晰、单向依赖。依赖方向自底向上（底层被上层依赖），数据/事件流方向自顶向下（用户操作向下传递）：

复制代码

┌─────────────────────────────────────────────────────────────────────┐
│  ▲ 数据/事件流方向                                                  │
│  │                                                                  │
│  WdUI (UI 框架层)              → JSON 驱动 UI 渲染、控件事件触发     │
│       ↑ 依赖 FunctionStorage                                        │
├─────────────────────────────────────────────────────────────────────┤
│  FunctionStorage (桥接层)      → 函数库注册、UI 桥接、JSON 工作流执行 │
│       ↑ 依赖 FunctionExecution                                      │
├─────────────────────────────────────────────────────────────────────┤
│  FunctionExecution (执行层)    → 函数注册、参数解析、委托调用         │
│       ↑ 依赖 WorkFlowMethod                                         │
├─────────────────────────────────────────────────────────────────────┤
│  WorkFlowMethod (引擎层)       → 工作流编排、管线执行、循环决策       │
│       ↑ 依赖                                                        │
├─────────────────────────────────────────────────────────────────────┤
│  UniversalJsonMiddleware (通用中间件)                                │
│       ↑ 依赖                                                        │
├─────────────────────────────────────────────────────────────────────┤
│  UniversalLayoutMath (纯数学计算)                                    │
└─────────────────────────────────────────────────────────────────────┘

说明：依赖关系自底向上（底层不感知上层），事件/数据流自顶向下（用户操作触发，逐层传递处理）。

1.2 层级职责

层级	组件	核心职责	关键接口/机制
UI 层	WdUI	JSON 驱动 UI 渲染，控件事件触发，动态参数输入与结果展示	ConfigContainer、EventMediator
桥接层	FunctionStorage	连接 UI 事件与函数执行，管理 JSON 工作流，多领域函数库注册	UIConnector、WorkflowExecutionLayer
执行层	FunctionExecution	函数注册、参数解析、委托调用，提供统一执行上下文	IFunctionRegistry、IWorkflowRegistry
引擎层	WorkFlowMethod	工作流编排、管线执行、运行时动态更新、LLM 驱动的循环决策	PipelineExecutor、LoopWorkflow

1.3 数据流全景

复制代码

用户操作 (点击/输入)
  → WdUI 控件事件
    → UIConnector (FunctionStorage) 提取参数
      → FunctionExecution 查找并执行函数
        → WorkFlowMethod 编排工作流管线 (如需)
      → 执行结果返回
    → UIConnector 写回结果到 WdUI 控件
  → 用户看到结果

二、WorkFlowMethod --- 工作流引擎层

2.1 概述

WorkFlowMethod 是 WorkFlow 体系的核心引擎层，提供从工作流定义、构建、执行到监控的全生命周期管理能力。它位于架构最底层，被 FunctionExecution 依赖，不直接感知上层组件。

与传统的 BPMN 工作流框架（如 Camunda、Temporal）不同，WorkFlowMethod 的设计理念更接近 AI 驱动的智能工作流------通过 LLM 驱动的循环决策、运行时动态调整、配置即工作流等能力，实现高度灵活和自适应的业务流程编排。

2.2 工作流构建（三种方式）

WorkFlowMethod 提供了三种构建工作流的方式，分别对应不同的开发场景。

编程式构建 适用于复杂逻辑和需要编译期检查的场景。通过 WorkflowUseage.CreatePipeline() 创建管线构建器，链式调用 .AddStep() 添加步骤，最后 .Build() 完成构建：

csharp 复制代码

var pipeline = WorkflowUseage.CreatePipeline("MyPipeline")
    .AddStep("Step1", new Func<int, int>(x => x + 1))
    .AddStep("Step2", new Func<int, int>(x => x * 2))
    .Build();

JSON 文件加载 适用于配置驱动的场景，无需重新编译即可调整工作流。通过 WorkflowUseage.ExecuteFromFileAsync() 直接加载并执行 JSON 定义的管线：

csharp 复制代码

var result = await WorkflowUseage.ExecuteFromFileAsync("workflow.json");

简洁字符串定义 适用于快速原型和测试开发。通过 WorkflowBuilder.BuildFromStrings() 用特定格式的字符串快速定义节点和连接：

csharp 复制代码

WorkflowBuilder.BuildFromStrings(
    "MergeNode:node_0:MergePrefix:DataProcess,Inputs_:Result_",
    "DataInitial:node_1:WebInvoke:WebSet_,Result_:Output_"
);

三种方式并非互斥，可以在同一个项目中混合使用：原型阶段用字符串快速验证，稳定后用 JSON 配置管理，核心逻辑用编程式构建确保类型安全。

2.3 管线化执行引擎

构建好的工作流通过 PipelineExecutor 执行。它支持同步/异步执行、异常重试和超时控制。

单步执行适合快速验证某个函数：

csharp 复制代码

var result = await WorkflowUseage.ExecuteStepAsync("Add",
    new Func<int, int, int>((a, b) => a + b), new object[] { 1, 2 });

多步执行适合批量处理多个步骤：

csharp 复制代码

var multiResult = await WorkflowUseage.ExecuteStepsAsync(
    ("Step1", new Func<int, int>(x => x + 1)),
    ("Step2", new Func<int, int>(x => x * 2))
);

PipelineExecutor 内部维护步骤间的数据传递，每个步骤的输出自动成为下一步的输入上下文的一部分。

2.4 文件驱动（配置即工作流）

WorkFlowMethod 支持从 JSON 文件加载管线定义并执行。此处的 JSON 格式是 WorkFlowMethod 自身的管线定义格式，与 FunctionStorage 的步骤式 JSON 工作流（见 §5.3）不同：

json 复制代码

{
  "name": "MyPipeline",
  "steps": [
    { "name": "Step1", "useExplicitParameters": true, "parameters": [1, 2] },
    { "name": "Step2", "useExplicitParameters": false }
  ]
}

2.5 运行时动态更新

支持运行时动态调整工作流结构（插入、删除、替换、重定向节点），无需重启：

csharp 复制代码

// Symbol 定位插入子链（推荐方式）
var directive = new InsertChainDirective
{
    InsertAfterSymbol = "AIGenerateImage",
    SymbolMatchMode = SymbolMatchMode.First,
    ChainJsonConfigs = new List<string> { "[{\"Symbol\":\"ImagePostProcess\",...}]" }
};

// 复合更新：插入 + 删除
var composite = new CompositeDirective
{
    Directives = new List<GraphUpdateDirective>
    {
        new InsertChainDirective { InsertAfterSymbol = "Setup", ... },
        new DeleteNodeDirective { NodeKey = "obsolete", ReconnectNeighbors = true }
    }
};

var updatedChain = GraphWorkflowUpdater.ApplyGraphUpdate(originalChain, new[] { composite });

2.6 图引擎统一

以 GraphFoundation 边体系作为节点连接关系的单一真实来源，消除平行指针系统：

复制代码

旧架构：NodeConfig.nextNodeConfig.NodeKey + Edge（两套系统，需手动同步）
新架构：仅 Edge（GraphFoundation 边是唯一真实来源）
       NodeKey 标记为 [Obsolete]，仅作为序列化缓存

2.7 预定义工作流模板

内置丰富的预定义模板，覆盖多个 AI 应用场景：

模板	说明	典型节点链
AI 图像生成	从提示词生成图像	MergePrefix → WebInvoke → DonloadPhoto
AI 代码生成	根据需求自动生成代码	PromptCommandParse → WebInvoke → CompileCheck → DynamicExcute
数据分析	数据处理和分析	MergePrefix → WebInvoke → DataAnalysis → DataConformity
数据存储	数据格式转换和持久化	ToListDictionary → DataValueUpdate → DataValueRead
大模型调用	通用 LLM 调用	CodeInitial → WebInvoke

2.8 状态管理与上下文体系

WorkFlow 体系包含三层执行上下文，分别服务于不同层级，形成清晰的继承链。

ExecutionContext 是最基础的上下文，位于 FunctionExecution 层，包含执行标识、共享数据和取消令牌：

csharp 复制代码

public class ExecutionContext
{
    public string ExecutionId { get; }
    public Dictionary<string, object> Items { get; }  // 共享数据
    public CancellationToken CancellationToken { get; }
}

WorkflowContext 继承 ExecutionContext，增加工作流相关的参数和节点信息，位于 FunctionExecution 层但被上层使用：

csharp 复制代码

public class WorkflowContext : ExecutionContext
{
    public Dictionary<string, object> Parameters { get; }  // 函数参数
    public string NodeKey { get; }                          // 当前节点
    public string WorkflowId { get; }                       // 工作流标识

    T GetParameter<T>(int index);       // 按索引取参数
    T GetParameter<T>(string key);      // 按名称取参数
    T GetData<T>(string key);           // 取上下文数据
    WorkflowContext CreateSubContext(string? nodeKey = null);
}

TypedExecutionContext 是强类型版本，位于 WorkFlowMethod 层，提供泛型 Get/Set，支持断点续传与状态持久化：

csharp 复制代码

public class TypedExecutionContext
{
    public T? Get<T>(string key) where T : class;       // 强类型读取
    public T GetRequired<T>(string key) where T : class; // 强类型读取（不存在则抛异常）
    public void Set<T>(string key, T? value);            // 强类型写入
}

三层上下文的关系可以这样理解：ExecutionContext 是"基础工作台"，提供最通用的能力；WorkflowContext 是"工作流工位"，在工作台基础上增加了工作流专属的工具；TypedExecutionContext 是"精密仪器台"，在工位基础上增加了类型安全和断点续传能力。

2.9 LLM 驱动的循环工作流（LoopWorkflow）

借鉴 Cline 的"主循环 + 工具调用"模式，设计了 LLM 驱动的循环工作流：

复制代码

Cline:        LLM 主循环 → 选择工具 → 执行工具 → 更新上下文 → 继续循环
                                                ↓
WorkFlowMethod: LoopWorkflow → 选择子工作流 → 执行子工作流 → 更新上下文 → 继续循环

三种选择策略

策略	决策方式	确定性	性能	适用场景
RuleBased	预定义条件匹配	100%	毫秒级	标准审批、定时任务、简单 ETL
LLMBased	LLM 实时推理	不确定	秒级	AI 客服、智能文档处理、代码分析
Hybrid	规则优先 + LLM 兜底	关键路径确定	大部分毫秒级	自动化测试、数据处理、运维自动化

循环工作流架构

复制代码

┌─────────────────────────────────────────────────────────────────┐
│                        循环工作流 (LoopWorkflow)                  │
│                                                                  │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │                    主循环 (Main Loop)                     │    │
│  │                                                          │    │
│  │  ① 检查完成条件 → ② 选择子工作流 → ③ 执行子工作流 → ④ 更新上下文 │    │
│  │  └────────────────────── 循环直到完成 ────────────────────┘    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                  │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │                    选择策略 (SelectionStrategy)           │    │
│  │  ┌────────────┐  ┌────────────┐  ┌────────────────┐     │    │
│  │  │ RuleBased  │  │ LLMBased   │  │ Hybrid         │     │    │
│  │  │ 规则匹配   │  │ LLM 推理   │  │ 规则+LLM 兜底  │     │    │
│  │  └────────────┘  └────────────┘  └────────────────┘     │    │
│  └─────────────────────────────────────────────────────────┘    │
└──────────────────────────┬──────────────────────────────────────┘
                           │
          ┌────────────────┼────────────────┬────────────────┐
          ▼                ▼                ▼                ▼
   ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐
   │ 子工作流 A   │  │ 子工作流 B   │  │ 子工作流 C   │  │ 子工作流 D   │
   │ (数据收集)   │  │ (数据分析)   │  │ (结果生成)   │  │ (错误恢复)   │
   └─────────────┘  └─────────────┘  └─────────────┘  └─────────────┘

智能上下文（SmartContext）

类似 Cline 的对话上下文，SmartContext 维护所有执行历史和数据，为 LLM 提供结构化的上下文摘要：

csharp 复制代码

public class SmartContext
{
    public string Goal { get; set; }                    // 任务目标
    public List<string> CompletedSteps { get; }          // 已完成步骤
    public List<ExecutionRecord> History { get; }        // 执行历史（滑动窗口）
    public int MaxHistoryLength { get; set; } = 100;     // 最大历史记录数

    public T Get<T>(string key);                         // 数据读取
    public void Set(string key, object value);           // 数据写入
    public string ToLLMContext();                        // 构建 LLM 可理解的上下文摘要
}

2.10 与 AI 工作流框架对比

设计理念对比

维度	Cline / Trae	WorkFlowMethod
核心驱动	LLM 实时推理驱动	配置驱动 + LLM 可选增强
决策方式	LLM 自主选择工具	规则选择 / LLM 选择 / 混合选择
工作流定义	隐式（LLM 动态生成）	显式（JSON/代码预定义）
确定性	低（依赖 LLM 输出）	高（规则优先，LLM 兜底）
可调试性	困难（黑盒推理）	容易（规则明确、日志完整）
复用性	低（每次重新推理）	高（模板可复用、可组合）

与 Trae 的对应关系

Trae 能力	WorkFlowMethod 对应
理解用户意图	`LoopWorkflow.Goal` + `CompletionCondition`
规划任务步骤	`SelectionStrategy` 选择子工作流
执行代码/工具	`SubWorkflowDefinition` 执行 ChainInfo 管线
验证结果	完成条件检查 + SmartContext 状态更新
迭代优化	循环机制（Loop）自动迭代

差异化优势

优势	说明
确定性 + 灵活性平衡	Hybrid 策略：规则覆盖标准路径，LLM 处理异常，兼顾可靠与灵活
可组合性	子工作流可独立定义、测试、复用，不同循环工作流可引用同一子工作流
安全边界	MaxIterations、CancellationToken、重试策略、超时控制等多层保护
渐进增强	从纯规则 → 规则+LLM → 纯LLM，可按需逐步引入 AI 能力
与现有架构兼容	完全复用 ChainInfo、CoreGraph、PipelineExecutor 等现有组件

三、FunctionExecution --- 基础函数执行层

3.1 核心架构

FunctionExecution 是 WorkFlow 体系的基础函数执行框架，提供函数注册、参数解析、委托调用等核心能力，是所有业务函数执行的底层引擎。它依赖 WorkFlowMethod 提供的工作流编排能力，同时被 FunctionStorage 依赖。

围绕四个核心概念构建：

组件	说明
IFunctionRegistry	函数注册表接口，支持 Register / Unregister / Contains / Call
FunctionDescriptor	函数元数据：名称、参数列表、返回值类型、异步标记、编译后执行器
ExecutionResult	统一执行结果：IsSuccess / Value / ErrorMessage / Duration
ExecutionContext	基础执行上下文：ExecutionId / Items(共享数据) / CancellationToken

两种注册表实现：

FunctionRegistry --- 通用委托注册表，基于 ConcurrentDictionary 存储委托和 IFunctionUnit
DefaultWorkflowRegistry --- 工作流函数注册表，继承 IFunctionRegistry，额外支持 Func<WorkflowContext, object> 签名

3.2 函数注册

两种注册方式：

csharp 复制代码

// 方式一：委托注册（灵活轻量）
FunctionExecutionFramework.Register("Add", (Func<double, double, double>)Add, "Addition: a + b");
FunctionExecutionFramework.RegisterAction<string>("SetApiKey", key => SetKey(key));

// 方式二：IFunctionUnit 注册（强类型可扩展）
public class AddFunction : FunctionUnitBase<(double a, double b), double>
{
    public override string Name => "Add";
    public override double Execute((double a, double b) input, ExecutionContext? context) => input.a + input.b;
}

3.3 执行流程

复制代码

ExecuteAsync(funcName, parameters)
  → TryGetDescriptor(funcName)          // 查找函数
  → DefaultParameterProcessor.Process() // 类型转换（如 "3.14" → 3.14）
  → CompiledExecutor / DynamicInvoke    // 执行
  → ExecutionResult                     // 返回结果

3.4 工作流函数注册表（IWorkflowRegistry）

IWorkflowRegistry 继承 IFunctionRegistry，提供基于 WorkflowContext 的注册与调用。它属于 FunctionExecution 层，但被上层（FunctionStorage 的 WorkflowLibrary）用于注册工作流函数：

csharp 复制代码

public interface IWorkflowRegistry : IFunctionRegistry
{
    void Register(string name, Func<WorkflowContext, object> func);
    object Call(string name, WorkflowContext context);
}

3.5 桥接机制（WorkflowBridge）

WorkflowBridge 实现 IWorkflowRegistry（工作流函数体系）与 IFunctionRegistry（通用委托体系）的双向桥接，使两个注册体系可以互相调用：

复制代码

IWorkflowRegistry → WorkflowFunctionUnitAdapter → IFunctionUnit (通用函数单元)

注意：WorkFlowMethod 层的 WorkflowUseage 也提供了类似的桥接方法（RegisterFunction / RegisterDelegate / CallBridgedFunction），它是对 FunctionExecution 层桥接机制的上层封装，提供更便捷的调用入口。

四、工作流执行函数与直接运行函数的区别

理解这两种执行方式的区别，是正确使用 WorkFlow 框架的关键。我们可以用三个用户熟悉的 AI 工具来类比。

4.1 用 AI 工具类比理解

直接运行函数 ≈ 网页版大模型

就像在 DeepSeek 网页版中提问：你输入一个问题，模型直接返回答案。每次对话都是独立的，没有上下文记忆，没有多步骤编排，没有工具调用。简单直接，适合一次性查询。

csharp 复制代码

// 就像在网页版大模型中问"1+2等于几？"
var result = FunctionExecutionFramework.ExecuteAsync("Add", new object[] { 1, 2 });

工作流执行函数 ≈ Cline / Trae

就像 Cline 或 Trae 的工作模式：它们有一个主循环（Main Loop），维护完整的对话上下文（SmartContext），能够自主选择工具（SelectionStrategy），按步骤执行任务（子工作流），并在执行过程中不断更新上下文。这不是一次性的问答，而是一个有状态、有编排、可迭代的完整流程。

csharp 复制代码

// 就像 Cline 理解一个复杂任务后，规划步骤、调用工具、逐步完成
var context = new WorkflowContext { NodeKey = "Step1", WorkflowId = "CodeReview" };
var result = WorkflowUseage.CallBridgedFunction("ChatComplete", context);

4.2 技术对比

对比维度	网页版大模型（直接运行函数）	Cline/Trae（工作流执行函数）
调用方式	`FunctionExecutionFramework.ExecuteAsync()`	`WorkflowUseage.CallBridgedFunction()`
执行引擎	FunctionExecution 直接执行	WorkFlowMethod 编排后执行
上下文	`ExecutionContext`（基础）	`WorkflowContext`（含 NodeKey、WorkflowId）
注册体系	`IFunctionRegistry`（通用委托）	`IWorkflowRegistry`（工作流函数）
交互模式	一次问答	主循环 + 多步骤
状态管理	无状态	有状态（上下文链）
动态调整	不支持	支持运行时插入/删除节点
适用场景	简单查询、独立计算	复杂任务、多步骤编排、AI 驱动流程

4.3 执行流程对比

直接运行函数的执行流程很直接：

复制代码

ExecuteAsync(funcName, parameters)
  → TryGetDescriptor(funcName)          // 查找函数
  → DefaultParameterProcessor.Process() // 类型转换（如 "3.14" → 3.14）
  → CompiledExecutor / DynamicInvoke    // 执行
  → ExecutionResult                     // 返回结果

工作流执行函数的执行流程则包含了上下文初始化和步骤编排：

复制代码

ExecuteWorkflow(def, input)
  → 初始化上下文（合并 input + 注入 apiKey）
  → 遍历 steps：
      解析参数（${key} 变量替换）
      → FunctionExecutionFramework.ExecuteAsync() [优先]
      → 失败回退 WorkflowUseage.CallBridgedFunction() [回退]
      → 存储结果到 context
  → outputMapping 映射返回

4.4 桥接机制：两个体系的互通

两种执行方式并非完全隔离。WorkflowBridge 实现了 IWorkflowRegistry（工作流函数体系）与 IFunctionRegistry（通用委托体系）的双向桥接：

复制代码

IWorkflowRegistry → WorkflowFunctionUnitAdapter → IFunctionUnit (通用函数单元)

WorkflowUseage 在此基础上提供了更便捷的上层封装：

csharp 复制代码

// 工作流函数注册（带 WorkflowContext）
WorkflowUseage.RegisterFunction("Add", ctx => {
    var a = ctx.GetParameter<int>("0");
    var b = ctx.GetParameter<int>("1");
    return a + b;
});

// 通用委托注册（任意签名）
WorkflowUseage.RegisterDelegate("Multiply", new Func<int, int, int>((a, b) => a * b));

// 桥接调用（自动选择注册表）
var result = WorkflowUseage.CallBridgedFunction("Add", context);

4.5 选择建议

如果只是执行一个独立的计算或操作------就像在网页版大模型中问一个简单问题------直接运行函数就足够了。如果需要多个步骤的编排、状态管理、运行时动态调整，或者需要与 UI 事件联动------就像 Cline 或 Trae 处理一个复杂任务------就应该使用工作流执行函数。

五、FunctionStorage --- 函数存储与 UI 执行桥接层

5.1 概述

FunctionStorage 位于 FunctionExecution 之上，承担三项职责：函数库注册、JSON 工作流执行、UI 事件桥接。它是连接 UI 层（WdUI）与执行层（FunctionExecution）的关键桥梁。

5.2 函数库注册

将多领域函数集中注册到 FunctionExecutionFramework：

函数库	注册函数	说明
MathLibrary	Add/Subtract/Multiply/Divide	基础数学运算（含别名 Plus/Minus）
ModelLibrary	ChatComplete/ChatCompleteAsync/ChatCompleteRaw	DeepSeek 模型调用
ModelLibrary	ExecuteWorkflow/LoadWorkflowDetails/SaveResultToFile	WorkflowRunner 界面函数
WorkflowLibrary	动态注册所有 JSON 工作流	将 JSON 工作流注册为可调用函数

WorkflowLibrary 的核心逻辑------将 JSON 工作流同时注册到两个函数体系：

csharp 复制代码

// 遍历 JSON 工作流，同时注册到两个体系
WorkflowUseage.RegisterFunction(name, context => ExecuteWorkflow(def, input));  // 工作流函数
WorkflowUseage.RegisterDelegate(name, (Func<string, string>)(input => ...));    // 委托函数

5.3 JSON 驱动的工作流执行（WorkflowExecutionLayer）

从 FileDriven/DrivenConfig/WorkFlow/ 加载 JSON 定义并执行。此处的 JSON 是步骤式工作流定义，与 WorkFlowMethod 的管线定义 JSON（§2.4）格式不同、执行机制不同：

对比维度	WorkFlowMethod 管线 JSON	FunctionStorage 步骤式 JSON
定位	引擎层原生管线定义	桥接层的工作流配置
执行机制	PipelineExecutor 直接执行	遍历 steps，调用 FunctionExecution
变量替换	不支持	支持 `${key}` 模板替换
输出映射	步骤间隐式传递	显式 outputMapping
适用场景	后端工作流编排	UI 驱动的轻量工作流

JSON 格式

json 复制代码

{
  "workflowName": "CodeReviewWorkflow",
  "displayName": "代码审查工作流",
  "steps": [
    {
      "stepName": "分析代码",
      "funcName": "ChatComplete",
      "outputKey": "reviewResult",
      "parameters": [
        "你是一个代码审查专家，请分析以下代码：\n${userInput}",
        "${userInput}"
      ]
    }
  ],
  "outputMapping": { "response": "reviewResult" }
}

执行流程

复制代码

ExecuteWorkflow(def, input)
  → 初始化上下文（合并 input + 注入 apiKey）
  → 遍历 steps：
      解析参数（${key} 变量替换）
      → FunctionExecutionFramework.ExecuteAsync() [优先]
      → 失败回退 WorkflowUseage.CallBridgedFunction() [回退]
      → 存储结果到 context
  → outputMapping 映射返回
      → 有 "response" 字段 → 直接返回文本
      → 单字段 → 直接返回值
      → 多字段 → 返回 JSON

变量替换

语法	示例	说明
`${key}`	`${userInput}`	替换为 context 中的值
`文本${key}文本`	`请分析：${userInput}`	字符串中嵌入变量
`${apiKey}`	自动注入	从环境变量读取 DeepSeekAPI

5.4 UI 事件桥接（UIConnector）

连接 WdUI 控件与函数执行引擎，实现配置即交互。

支持的事件

事件	控件	参数来源	结果回写
Click	Button	Bindings.Inputs 指定控件	Bindings.Output 指定控件
TextChanged	TextBox	文本框文本	同上
SelectedIndexChanged	ComboBox	选中项	同上
CheckedChanged	CheckBox	选中状态	同上
ValueChanged	TrackBar/NumericUpDown	当前值	同上

绑定流程

复制代码

控件事件触发
  → ExtractParameters() 从输入控件取值（支持 7 种控件类型）
  → FunctionExecutionFramework.ExecuteAsync(funcName, parameters)
  → WriteResult() 将结果写回输出控件（TextBox/Label/ProgressBar/TrackBar/NumericUpDown）

配置示例

json 复制代码

{
  "controls": [{
    "name": "btnExecute", "type": "Button", "text": "执行工作流",
    "events": {
      "click": "ExecuteWorkflow",
      "bindings": { "inputs": ["txtInput"], "output": "txtResult" }
    }
  }]
}

六、WdUI --- UI 框架层

6.1 概述

WdUI （Windows Desktop UI）是一个基于 .NET 10.0 和 Windows Forms 的配置驱动 UI 框架，核心能力是通过 JSON 配置文件动态生成窗体界面，实现 UI 与业务逻辑的完全分离。它位于架构最顶层，依赖 FunctionStorage 提供的桥接能力与后端交互。

6.2 核心功能

JSON 驱动渲染：通过 JSON 定义窗体、视图、控件布局与事件，无需编译即可调整界面
15+ 内置控件：Button、TextBox、ListView、DataGridView、TabControl 等常用控件开箱即用
比例布局系统：基于 0.0~1.0 相对值的智能布局，自适应窗口大小变化
事件中介器：基于中介者模式的控件间通信，打破直接耦合
嵌套容器：ConfigContainer 支持 UI 容器层层嵌套，实现模块化界面组装
重叠检测与优化：自动检测控件重叠并生成修复方案

七、执行链路全景

7.1 UI 事件链路（最常用）

复制代码

用户点击 → UIConnector 提取参数 → FunctionExecution 查找并执行函数 → UIConnector 写回结果

7.2 JSON 工作流链路（配置驱动）

复制代码

外部调用 → 加载 JSON → 遍历步骤（变量替换 → 执行函数 → 存结果）→ outputMapping 返回

7.3 完整示例：AI 代码审查

复制代码

用户点击按钮 → UIConnector 提取代码
  → ExecuteWorkflow("CodeReview", code)
    → 步骤1: ChatComplete(systemPrompt, userInput) → AI 审查
    → 步骤2: FormatReview(reviewResult) → 格式化报告
  → outputMapping 返回文本 → UIConnector 显示在 txtResult

八、跨层协同机制

8.1 WdUI 与 FunctionStorage 协同

协同场景	实现方式
事件绑定	UIConnector 通过控件名称匹配绑定事件
参数提取	从 WdUI 控件自动提取值，支持 7 种类型
结果回写	执行结果自动写回 WdUI 控件
配置驱动	同一份 JSON 同时驱动 UI 渲染和函数执行
工作流执行	WdUI 通过 ExecuteWorkflow 函数执行 JSON 工作流

8.2 WorkFlowMethod 与 WdUI 协同

协同场景	实现方式
动态参数输入	工作流节点通过 JSON 配置定义输入参数，WdUI 动态渲染为表单界面
执行触发	WdUI 按钮点击事件通过中介器调用 WorkFlowMethod 执行工作流
结果回显	工作流执行结果通过桥接机制写回 WdUI 控件，实时展示
配置驱动	同一份 JSON 配置既驱动工作流执行逻辑，又驱动 UI 渲染布局
容器化集成	WdUI 的 ConfigContainer 作为工作流 UI 载体，动态加载不同工作流的配置界面
循环工作流可视化	WdUI 实时展示 LoopWorkflow 的迭代进度、当前步骤、执行历史

九、与主流工作流框架对比

维度	Temporal	Camunda	Airflow	Elsa	WorkFlowMethod
表示模型	代码定义	BPMN 2.0	Python DAG	代码+JSON	链+图双模
运行时动态更新	❌	✅ 部分	❌	✅ 部分	✅ 原生支持
LLM 驱动循环	❌	❌	❌	❌	✅ LoopWorkflow
Symbol 定位	❌	❌	❌	❌	✅ 独有
AI 工作流	⭐⭐⭐	⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
动态编排	⭐⭐	⭐⭐⭐	⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
C#/.NET 应用	⭐⭐⭐	⭐⭐	⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
快速原型开发	⭐⭐	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐

一句话总结：WorkFlowMethod 是一个在架构创新上极具特色的工作流框架，其链-图双模架构、运行时动态更新和 LLM 驱动的循环工作流能力在业界独树一帜，特别适合需要高度灵活性和 AI 编排能力的 C#/.NET 应用场景。

十、核心接口速查

接口/类	所属层级	一句话说明
`WorkflowUseage`	WorkFlowMethod	工作流使用入口，提供构建、执行、桥接的统一入口
`WorkflowBuilder`	WorkFlowMethod	工作流构建器，支持编程式和字符串构建
`PipelineExecutor`	WorkFlowMethod	管线执行引擎，支持同步/异步、重试、超时
`GraphWorkflowUpdater`	WorkFlowMethod	运行时动态更新器，执行插入/删除/复合指令
`InsertChainDirective`	WorkFlowMethod	Symbol 定位插入子链指令
`DeleteNodeDirective`	WorkFlowMethod	节点删除与重连指令
`CompositeDirective`	WorkFlowMethod	复合更新指令（插入+删除组合）
`LoopWorkflow`	WorkFlowMethod	LLM 驱动的循环工作流
`SmartContext`	WorkFlowMethod	智能上下文，维护执行历史和 LLM 摘要
`SelectionStrategy`	WorkFlowMethod	选择策略基类（RuleBased/LLMBased/Hybrid）
`TypedExecutionContext`	WorkFlowMethod	强类型执行上下文，支持断点续传
`IFunctionRegistry`	FunctionExecution	函数注册表接口
`IWorkflowRegistry`	FunctionExecution	工作流函数注册表接口
`FunctionDescriptor`	FunctionExecution	函数元数据
`ExecutionResult`	FunctionExecution	统一执行结果
`ExecutionContext`	FunctionExecution	基础执行上下文
`WorkflowContext`	FunctionExecution	工作流上下文（继承 ExecutionContext）
`WorkflowBridge`	FunctionExecution	工作流函数与通用函数的双向桥接
`FunctionExecutionFramework`	FunctionExecution	函数执行框架入口
`FunctionUnitBase`	FunctionExecution	强类型函数单元基类
`DefaultParameterProcessor`	FunctionExecution	参数类型转换处理器
`UIConnector`	FunctionStorage	UI 事件桥接器
`WorkflowExecutionLayer`	FunctionStorage	JSON 工作流执行层
`WorkflowLibrary`	FunctionStorage	工作流库注册器
`ConfigContainer`	WdUI	UI 容器，支持嵌套和动态加载
`EventMediator`	WdUI	事件中介器，控件间通信

十一、总结

WorkFlow 体系通过四层架构实现了从 UI 渲染到工作流引擎的完整闭环：

WdUI 提供 JSON 驱动的动态 UI 渲染能力，让界面配置化、可热更新
FunctionStorage 作为桥接层，连接 UI 事件与函数执行，管理 JSON 工作流
FunctionExecution 提供底层函数注册与调用能力，是业务函数执行的基石
WorkFlowMethod 作为核心引擎，负责工作流编排、管线执行、运行时动态更新和 LLM 驱动的循环决策

各层通过 UIConnector、IFunctionRegistry、IWorkflowRegistry、WorkflowBridge 等机制紧密协作，实现配置即工作流、界面即交互的开发体验。