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

• 对照对象：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）。
• 状态：讨论草稿，待后续会话继续展开。
• 整理日期：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"（这点在上一份笔记已确认），根因溯源还直接实现了综述版提到的"评审团"式多视角交叉审：

# 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 \
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）要不要评估是否也该按风险分级选验证强度，而不是统一同一套。