Skip to main content

BLOGE 0.9.9-RC1 在线版 · 编制 2026-11-02 · English

第一阶段回顾 —— 入门（第 1–4 章）

你现在已经掌握了阅读小型 BLOGE DAG、预测其声明数据依赖所需的词汇和心智模型。

你学到了什么​

第 1 章 —— BLOGE 是什么，以及它为什么存在 为你建立了 BLOGE 的三个核心特征：工作流是可见的（graph 的形状是显式的）、执行由依赖驱动（你声明边，引擎决定顺序）、韧性是内建的（重试、超时、降级属于模型本身）。

第 2 章 —— 你的第一个 Graph 把理论变成了实践。你构建了一个 graph、运行它、检查了 GraphResult，亲眼看到是引擎——而不是你——决定哪些节点可以并行执行。

第 3 章 —— 依赖关系思维 强化了你对依赖边的判断力。你学会了阅读有向无环图、识别不必要的串行化，以及区分控制依赖和数据依赖。

第 4 章 —— 流动的数据 补全了整幅图。你了解了数据如何通过 context 进入 graph、如何通过 input binding 在节点间流动、如何通过 node output 流出。你练习了路径表达式、安全导航（?.）、空值合并（??）、transform 和 lambda 输入绑定。

你现在应该能做到​

  • 用一句话描述 BLOGE，不借助任何框架术语。
  • 在纸上画出一个小型工作流的依赖图，并预测执行顺序。
  • 编写一个包含三四个节点、显式依赖和输入绑定的简单 .bloge 文件。
  • 读取 GraphResult 并安全地提取类型化输出。
  • 解释 transform 和 operator 节点的区别。

这个阶段的常见错误​

错误为什么会犯如何纠正
添加多余的 depends_on 边把"这个在那个之后执行"和"这个确实需要那个节点的数据"搞混了问自己：下游节点是否读取上游输出？如果不是，就去掉这条边。
总用 getOutput 而不是 findOutput假设每个节点一定会完成当节点可能被跳过或失败时，用 findOutput 或 getOutputOrDefault。
把业务逻辑放进 transformTransform 是零开销的数据投影，不是 operator如果代码有副作用或可能失败，就应该放进 operator。
硬编码值而不是使用 ctx.*从示例中复制粘贴时忘了参数化把环境相关或调用方相关的值移入 graph context。

核心词汇​

术语含义
Graph由业务步骤组成的有向无环图，具有显式的数据和控制流。
NodeGraph 中的一个步骤，由一个 operator 支撑。
Operator类型化函数 (I, GraphContext) → O，负责执行真正的业务逻辑。
依赖边一条有向链接，表示"这个节点必须等那个节点完成后才能开始"。
Input binding从 context、上游输出或字面量解析节点输入的表达式。
Transform纯投影节点——只做数据变形，不触发 Operator 调用或独立节点调度；表达式本身仍会消耗计算资源。
GraphResult执行后返回的不可变记录：成功标志、输出、状态、耗时。

试一试：删除一条假依赖​

把早餐画成四个 node：烧水、烤面包、冲咖啡、上桌。只添加物理上必要的依赖，然后删除一条边，解释你得到的是安全并行，还是引入了竞态。

下一步​

第二阶段回顾教你在 graph 内做决策（分支）、处理故障（韧性）、设计干净的 operator，以及编写可维护、可审查的 DSL 文件。从第 5 章——做决策的分支开始。