# 对照笔记：《Loop Engineering 就凉了？一文看懂 Graph Engineering 的"新范式"》vs graphlemon 架构

- **对照对象**：[graph-engineering-vs-loop-engineering-overview.md](./graph-engineering-vs-loop-engineering-overview.md)（本文简称"综述版"）
- **背景**：综述版和之前对照过的 5 步版/14 步版不同——不是"怎么动手搭 Dynamic Workflows"的教程，而是行业视角的综述：术语起源、五层演进、Anthropic 官方模式、拓扑分类、框架对比、真实生产案例。本笔记只针对综述版的论点跟 graphlemon 现状对照，不重复之前两份笔记已经覆盖的内容（worktree 隔离、Verifier 独立上下文、loop-until-dry、按节点选模型等，见 [graph-engineering-1000-agents-5-steps.diff-with-graphlemon.md](./graph-engineering-1000-agents-5-steps.diff-with-graphlemon.md)）。
- **状态**：讨论草稿，待后续会话继续展开。
- **整理日期**：2026-08-04

---

## 1. 五层演进定位：graphlemon 同时占了 Loop 和 Graph 两层

综述版把 Prompt→Context→Harness→Loop→Graph 排成递进的五层，主张"Loop 解决单智能体持续工作，Graph 解决多智能体/工具/人的组织"。

graphlemon 的架构里两层都在，而且是**嵌套关系**，不是二选一：

- **Org-level Loop**（`docs/graphlemon_architecture.md` §4.3）：Validator → Planner 的回退边，本质就是综述版说的 Loop——同一个任务反复"试一下 → 看结果 → 调整 → 再来"，直到通过或 3 轮未收敛转 `blocked_pending_human`。
- **Org Graph + Work Graph 两层图**：Org Graph 三节点（角色间协作）+ 每个节点内部动态生成的 Work Graph（fan-out/fan-in/loop），是综述版说的 Graph。

也就是说 graphlemon 不是"从 Loop 升级到了 Graph"，而是**把 Loop 当成 Graph 里的一条边**（Org-level Loop 只是 Org Graph 上 Validator→Planner 这一条回退边的别名）。这跟综述版"Loop 是 Graph 的组成部分之一，不是被取代"的立场是一致的，比综述版举的例子（每日简报单节点 Loop vs 三节点 Graph 二选一）更进一步——graphlemon 把两者做成了同一张图里的不同粒度。

## 2. "运动员兼裁判"问题：Validator 独立评判 + 三视角评审团已经落地

综述版第 08 章的核心论点：多数智能体系统翻车是因为"模型既当运动员又当裁判"，解法是让 Verifier 用独立干净的上下文，专门试图推翻结论。

graphlemon 不仅做到了"Validator 是独立 Org Agent"（这点在上一份笔记已确认），根因溯源还直接实现了综述版提到的**"评审团"式多视角交叉审**：

```python
# src/root_cause_trace.py
def judge_root_cause(perspective_fns):
    """要求 >= 2/3 视角一致才定案（04-P: "至少 2/3 视角一致才定案"），
    否则 raise InconclusiveEscalateError，附带三视角原始判断供人工裁决。"""
```

三个视角分别是"正确性视角 / 需求完整性视角 / Skill 系统性缺陷视角"，跟综述版给的"三种验证打法"（快速核对 / 多角度交叉审 / 评审团）里最重的一种直接对应——而且 graphlemon 是**票数不足自动升级人工**，不是简单多数决，比综述版描述的"扛得住才放行"更严格。

## 3. 拓扑：Coder 的 Supervisor 就是"主管模式"，Planner 的四步链是"流水线+菱形"组合

综述版第 06 章给出三种经典拓扑：菱形（fan-out/fan-in）、主管模式（Orchestrator-Workers）、流水线（Pipeline）。这三种在 graphlemon 里都能对上号，而且是早于这篇综述版就已经用中文命名过的概念：

| 综述版拓扑 | graphlemon 对应设计 |
|---|---|
| 主管模式（Orchestrator-Workers） | Coder Work Graph 的 **Supervisor（调度子 Agent）**——常驻节点监控所有并行/串行 Work Node，发现卡点后重新调度或升级（架构文档 §6.2）。这跟综述版 Anthropic Research 系统"主智能体分析问题、生成子智能体、子智能体并行搜集、汇总"的描述几乎逐字对应。 |
| 流水线（Pipeline） | Planner Work Graph 主干 BRD→PRD→SDD→Benchmark，后者依赖前者的确定版本（架构文档 §6.1），是教科书式的固定步骤链。 |
| 菱形（Fan-out/Fan-in） | Planner 在 PRD/SDD/测试用例阶段的 fan-out 候选点（多场景并行撰写 PRD 片段、多技术方案候选、功能/边界/性能测试并行生成），再 fan-in 合并 + 一致性检查（架构文档 §6.1）。 |

三种拓扑在 graphlemon 里不是互斥选型，而是像综述版说的"可以拼装嵌套的积木"——Coder 的主管模式套着若干模块级的菱形并行实现，Planner 是流水线套着阶段内的菱形。

## 4. Anthropic 官方五种工作流模式的隐式覆盖

综述版第 07 章列的五种模式（路由 Routing、并行化 Parallelization、编排者-工作者 Orchestrator-Workers、评估-优化 Evaluator-Optimizer、提示链 Prompt Chaining），graphlemon 目前没有显式引用这套术语，但设计上已经全部隐式覆盖：

| Anthropic 模式 | graphlemon 对应机制 |
|---|---|
| Routing | Validator 在 bug 记录里打 `route: fast_lane \| full_replan` 标签，`org_loop_route.py` 用**纯代码**（`_NEW_STATUS`/`_NEW_ORG_NODE` 查表）决定走 Coder 快速通道还是 Planner 完整重规划——不是再派一个 Agent 去决定路由，分类交给智能体，走哪条边用代码，正是综述版第 08 章"让模型的判断力落在节点上，让代码的可靠性落在边上"的原话实现。 |
| Parallelization | Planner/Coder Work Graph 的 fan-out（见上表菱形）。 |
| Orchestrator-Workers | Coder 的 Supervisor（见上表主管模式）。 |
| Evaluator-Optimizer | Org-level Loop：Validator 评估 → 不通过则打回 Planner/Coder 优化 → 再评估，循环上限 3 轮。 |
| Prompt Chaining | Planner 的 BRD→PRD→SDD→Benchmark 主干（见上表流水线）。 |

## 5. "工作图 vs 角色图"治理红线——精确对应 graphlemon 的 Org Graph / Work Graph 边界

这是综述版里对 graphlemon 最有价值的一条新论点（第 10 章末尾）：

> 图允许"任务怎么拆、怎么合"现场灵活调整，这叫**工作图**，可以快变。但"谁有权改数据库、谁能绕过审批"这类长期权限，绝不能让模型现场发挥，这叫**角色图**，必须慢变、可审计。

这条红线跟 graphlemon 现有的两层设计几乎是同一件事的两种命名：

- **角色图 = Org Graph**：Planner/Coder/Validator 三个角色的职责边界、谁能做什么（Planner 不写代码、Coder 不判定验收、Validator 不直接改代码/需求）是人工固定设计、代码级写死的（架构文档 §3"关键设计原则 1"：Org Graph 改动属于架构变更，需要人工评审，不由系统自主修改）。
- **工作图 = Work Graph**：每次任务全新规划生成的节点/边/fan-out/fan-in 是"快变"的，且明确允许系统自主生成（架构文档 §3"关键设计原则 2"）。

上一份对照笔记（5 步版）已经提出"Org Graph 固定 / Work Graph 动态"这条边界，但当时是从"什么时候不该用 Graph"的角度推出来的。综述版这次是从**权限治理**角度独立给出同一条边界，两条路径殊途同归——这进一步印证了 graphlemon 这条设计边界不是巧合，值得真正写进架构文档，用综述版这个"工作图/角色图"的命名来强化表述（比自造的"固定/动态"说法更贴合行业共识）。

## 6. 持久化执行（Durable Execution）：断点恢复已实现，Pause/Resume 已实现，Time-Travel 调试未实现

综述版第 11 章重点讲 LangGraph 的 checkpointer：每个"超级步"存快照，带来人在回路、记忆、时间旅行调试、容错（`pending writes`：部分节点失败时已成功节点的输出不丢）四个能力。逐项对照：

| LangGraph 能力 | graphlemon 现状 |
|---|---|
| 容错（部分失败保留已成功节点输出） | ✅ 已具备：`work_node_execution` 按节点独立持久化状态，单节点失败不影响其他已完成节点的产出（架构文档 §7.1"断点续跑与持久化"是硬需求）。 |
| 人在回路（暂停/恢复） | ✅ 已实现：`src/task_execution.py`（2026-08-03 提交）的手动 Start/Pause/Stop，复用 `blocked_pending_human` 状态 + `user_paused` 标记，`org_loop_route._manual_resume` 恢复暂停前状态。 |
| 记忆（多轮交互间保留上下文） | ✅ 已具备：`.claude/agent-memory/{planner,coder,validator}/`，`memory: project` 字段，随 Git 历史版本化（架构文档 §7.3）。 |
| 时间旅行调试（回到任意历史检查点重放/分叉） | ❌ 未实现，也未见规划。graphlemon 目前是"从当前状态继续/重试"，不支持"回到某个历史节点重新分叉执行"。这是综述版指出但 graphlemon 尚未覆盖的一个真实缺口，值得评估是否有必要——大概率优先级不高（自举开发场景下，人工 review git 历史 + 手动重跑节点已经能覆盖大部分需求），但如果未来要支持"审计整个代码库"类大规模任务，调试大图执行路径时可能会需要。 |

## 7. 值不值得用图：graphlemon 的场景天然通过综述版的成本检验

综述版第 09/10 章的核心决策框架：Graph 的额外开销（维护多份提示词、设计节点间状态结构、应对新失败模式）对"只跑一次的任务"是纯税，对"每天都要跑的""价值足够高的"任务才值。Anthropic 给的三个该用多智能体的场景是：并行可分解、任务复杂到单一上下文装不下、价值高到能覆盖 token 成本。

graphlemon 的定位（7×24 黑灯工厂，持续产出、持续迭代）天然落在综述版认为"值"的一侧，不需要重新论证——但这也是一个提醒：**graphlemon 内部具体到某个 Work Node 该不该再往下 fan-out**，应该套用同一把尺子（是否真的并行可分解、是否真的装不下单一上下文、边际收益是否覆盖 token 成本），而不是默认能拆就拆。目前架构文档里 fan-out 候选点（§6.1 的 PRD/SDD/测试用例并行）都是"候选"而非强制，这个判断目前留给 Planning Skill 生成 Work Graph 时临场决定，综述版的三条尺子可以作为这个临场判断的显式检查清单。

## 8. 待讨论的开放问题（供下一轮会话展开）

- [ ] 是否要把综述版"工作图 vs 角色图"这个命名正式写进 `docs/graphlemon_architecture.md`，替换/补强现有"Org Graph 固定 / Work Graph 动态"的表述？
- [ ] Time-travel 调试（回到历史检查点分叉重放）要不要立项？还是维持"用 git 历史 + 手动重跑"的现状，等到真正遇到大规模 Work Graph 调试痛点再补？
- [ ] Planning Skill 生成 Work Graph 时，是否需要显式把"并行可分解 / 单一上下文装不下 / 收益覆盖成本"这三条尺子写进 Prompt，作为 fan-out 决策的强制检查项，而不是隐式判断？
- [ ] root_cause_trace 的三视角评审团机制目前只在 `test_failed` 根因溯源场景用到，综述版把这类"重仓verifier"归为"高风险场景才用的重打法"——graphlemon 其他地方（比如 Coder 的自测 reflection）要不要评估是否也该按风险分级选验证强度，而不是统一同一套。