先说说 Workflow 为啥Neng把字段映射和数据流给分离

说实话，我一开始也懵了。

我们平常写业务，Graph 那玩意儿就像一根直管子。

上一个节点的输出直接喂下一个节点的输入。

结果要是类型不匹配？只Neng硬塞个适配层，写得跟天书一样。

哈哈，这时候 Workflow 冒出来拎着标签管道说：“兄弟，你别把水全倒进来我只想要指定口的液体”。

type FieldMapping struct {

  fromNodeKey string  // 哪个节点来的

  from string  // 源字段

  to string  // 目标字段

}

有了它，连边的时候Ke以明确“把 A 的 X 字段送到 B 的 Y 字段”。

举个例子，咱们要统计正文和推理内容里子串出现次数。

type message struct {
    *schema.Message
    SubStr string // 要搜索的子串
}
type counter struct {
    FullStr string // 被搜索的完整字符串
    SubStr  string // 搜索词
}
wf := compose.NewWorkflowany]
// 节点 c1：统计正文
wf.AddLambdaNode).
   AddInput(compose.START,
       compose.MapFields, // 同名字段直接映射
       compose.MapFieldPaths(
           string{"Message", "Content"}, // 来源路径
           string{"FullStr"},            // 目标字段
       ))
// 节点 c2：统计推理内容
wf.AddLambdaNode).
   AddInput(compose.START,
       compose.MapFields,
       compose.MapFieldPaths(
           string{"Message", "ReasoningContent"},
           string{"FullStr"},
       ))
// END 节点：合并结果
wf.End.
   AddInput).
   AddInput)

kan，这里根本没写适配函数。

我们只说“把 message.Message.Content → counter.FullStr”，Workflow 替我们搬砖。

有时候你只想拿数据，却不想等前驱执行完再跑。

比如：

type calculator struct {
    Add      int
    Multiply int
}
wf := compose.NewWorkflow
wf.AddLambdaNode).
   AddInput)
wf.AddLambdaNode).
   AddInput).
   AddInputWithOptions(
        compose.START,
        *compose.FieldMapping{
            compose.MapFields,
        },
        compose.WithNoDirectDependency, // 只取数据，不建控制依赖
   )
wf.End.AddInput

意思是：“我等 adder 完成才开始算乘法，但 Multiply 的值Ke以提前塞进去”。

有些字段根本不来自任何前置节点，像预算、默认阈值，那就直接在编译阶段写死：

type bidInput struct {
    Price  float64
    Budget float64
}
wf.AddLambdaNode).
   AddInput).
   SetStaticValue // Budget = 100万，静态注入

Ru果你的业务是大文件、实时日志，那一次性 Invoke 不够用，需要 Transform 模式。

wordCounter := func (
    *schema.StreamReader, error,
) {
    var subStr, cachedStr string
    return schema.StreamReaderWithConvert  {
        if len> 0 {
            subStr = co.SubStr
            return strings.Count, nil
        }
        if len> 0 {
            return strings.Count, nil
        }
        cachedStr += co.FullStr
        return 0, schema.ErrNoValue
    }), nil
}
wf := compose.NewWorkflowint]
wf.AddLambdaNode).
   AddInput).
   SetStaticValue
wf.AddLambdaNode).
   AddInput).
   SetStaticValue
wf.End.
   AddInput).
   AddInput)
run,_ := wf.Compile
stream,_ := run.Transform(ctx,
    schema.StreamReaderFromArray(*schema.Message{
        {ReasoningContent:"I need to say something meaningful"},
        {Content:"Hello world!"},
}))

先别急，我来解释一下。

- 百度爬虫geng喜欢结构化、语义清晰的页面。

- Ru果页面里全是代码块、没有自然语言描述，爬虫会觉得“这玩意儿像文档”，可Neng不给收录。

- 再者，Ru果标题和正文关键字不匹配，或者页面加载太慢，也会被过滤掉。

- 所以在写技术博客时要兼顾“代码示例”和“文字解释”。咱们这篇文章里Yi经把概念解释得差不多了应该不会被百度给忽略啦。

Workflow 在 .Compile 时会检查每个 AddInput 的字段是否真的存在。

// 编译时报错示例：
wf.AddLambdaNode.
   AddInput(compose.START,
       compose.FromField) // <-- 类型没有这个字段，会直接报错

Aha，这种错误在 Graph 场景只Neng跑到运行时才发现。Workflow 把它提前拦住让你在 IDE 就Nengkan到红叉。

No cycles.

The underlying trigger mode is AllPredecessor, 意味着每个节点必须等所有前驱dou到齐才Neng触发执行。

If you try to make a loop like A → B → A，它根本进不了队列，因为永远等不到“所有前驱”。所以 ReAct 那种自我迭代模型只Neng用 Graph 实现，Workflow 则专注于 DAG。这也让它在类型校验和依赖分析上geng简单、geng可靠。

- 任意节点之间自由映射字段，无需写额外适配函数；

- 静态值、动态值混合使用，一行代码搞定；

- 控制依赖与数据依赖Ke以分离，灵活组合；

- 编译期即报错，避免生产事故；

- 支持流式 Transform，让大数据处理geng轻松。

输入: calculator{Add: , Multiply: }       
│          ├────→ adder = 
│          │              
│          ▼       
│      multiplier = 
│          │       
│          └──────────────┘  
← Multiply 字段直接给 multiplier 的 B  
但不建立 “START → mul” 控制依赖  
因为 mul 等的是 adder 完成就行  

* 字段映射让数据流和控制流彻底解耦；

* 用 AddInput/AddDependency/AddInputWithOptions` 分清楚两者角色；

* 静态值通过 ` 注入，不用再造额外 Lambda；

* 流式场景同样支持细粒度映射；

* 编译期强校验让代码geng安全。