Go 不适合仅用 goroutine + channel 编排 AI 工作流，因其缺乏显式 DAG 调度、状态持久化和失败恢复能力；需解耦执行与调度，依赖中心化调度器、分布式状态存储及条件分支边等机制。
Go 适合做 AI 工作流编排，但不能直接用 goroutine 或 channel 拼出一个可靠的工作流引擎——它需要显式的 DAG 调度、状态持久化和失败恢复能力。
为什么不能只靠 goroutine + channel 编排 AI 任务
很多人一上来就写 go doStepA() → go doStepB()，以为并发就是编排。实际会遇到三类硬伤：
- 节点依赖丢失：
StepB需要StepA的输出，但channel无类型约束、无超时重试、无失败回滚 - 状态不可追踪：某个节点卡在 API 调用上，你无法从外部查“它到底执行到哪了”，更没法人工干预
- 长周期不存活：AI 工作流常持续数分钟甚至小时，而
goroutine是内存级的，进程一挂全丢
真正可用的编排必须把“执行”和“调度”解耦——前者交给轻量 worker，后者由中心化调度器用有向无环图（DAG）驱动。
github.com/cloudwego/eino 的 GraphOrchestrationEngine 是目前最贴近生产需求的起点
Eino 的 GraphOrchestrationEngine 不是玩具，它已在字节内部支撑客服 Agent 和知识库问答链路。关键设计点很务实：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 节点定义用结构体而非字符串：
type Node struct { ID string; Type string; Inputs map[string]string }，避免 YAML 解析歧义 - 边（edge）带条件表达式：
if .status == "success"或if len(.output) > 0，不是简单“下一步”，而是真分支逻辑 - 每个节点执行完自动写入分布式 KV（如 etcd），字段含
started_at、finished_at、error，支持断点续跑 - 不强制要求所有节点用 Go 实现——HTTP 节点可调用 Python 工具服务，gRPC 节点可对接模型推理服务
你不需要从零实现整个引擎，但得理解它的注册机制：engine.Register("llm_call", &LLMNode{}) —— 所有工具节点必须显式注册，否则工作流加载时直接 panic。
自研简易 DAG 引擎时，toposort 和 atomic.Value 是两个绕不开的底层依赖
如果你决定自己写最小可行版（比如只跑 5 个节点、不跨机器），重点不在图遍历算法，而在状态同步和循环检测：
- 拓扑排序必须用
github.com/yourbasic/graph或手写 DFS+入度表，别信网上抄来的“递归排序”，AI 工作流节点常达百级，栈溢出风险高 - 节点状态不能用全局 map：并发读写会 panic，改用
atomic.Value存map[string]NodeStatus，每次更新都Load→copy→Store - DAG 循环检测必须在加载阶段完成，而不是运行时；报错信息要具体到边：
cycle detected: node 'validate' → 'enrich' → 'validate'，否则调试成本爆炸 - 每个节点执行函数签名建议统一为：
func(ctx context.Context, input map[string]interface{}) (map[string]interface{}, error)，保持输入输出契约一致
工作流中调用 LLM 的节点，必须加 timeout 和 retry 包装，且不能藏在工具函数里
AI 工作流最脆弱的一环永远是 LLM 调用——网络抖动、模型限流、token 超限都会让整个流程卡死。常见错误写法：
func callLLM(prompt string) (string, error) {
resp, err := client.CreateChatCompletion(...) // 没 timeout！
return resp.Choices[0].Message.Content, err
}
正确做法是把重试和超时作为节点行为的一部分：
- 在节点配置里声明：
timeout: 30s、max_retries: 2，不是写死在代码里 - 使用
context.WithTimeout包裹每次调用，且ctx必须传给下游节点（用于传播取消信号） - 失败时记录原始 error，比如
"rate limit exceeded on openai"，而不是笼统的"LLM failed"，否则运维无法区分是配额问题还是 prompt 写错 - 不要在 LLM 节点里做 JSON 解析——把 raw response 传给下一个
parse_json节点，职责分离才利于调试
真正的难点不在“怎么跑通”，而在“怎么让别人（包括一个月后的你自己）能快速看懂这个工作流为什么卡在第三步”。节点命名、错误分类、状态快照，比算法本身更重要。
