对照笔记：《Graph Engineering：一个提示词，跑起 1000+ 的智能体循环》vs graphlemon 架构
- 对照对象：graph-engineering-1000-agents-5-steps.md（本文简称"5 步版"）
- 背景：仓库里已有同主题的 14 步版，
docs/graphlemon_architecture.md第 10 节已对 14 步版做过逐条映射，并在 10.1 节据此决策"Work Graph 执行层直接复用 Claude Code 原生动态工作流"。5 步版是同一方法论的精简版，本笔记只记录 5 步版带来的新增信息和尚待跟进的开放项，不重复 14 步版已覆盖的内容。 - 状态：讨论草稿，待后续会话继续展开，非最终结论。
- 整理日期：2026-08-04
1. 已经吻合、且已在代码里落地的部分
| 5 步版观点 | graphlemon 现状 | 依据 |
|---|---|---|
| 验证器（Verifier）必须用干净的独立上下文，不能复用执行器的对话，否则"验证"只是自己给自己点头 | Validator 是独立的 Org Agent，独立 claude -p 调用，不共享 Coder 的会话上下文 |
docs/graphlemon_architecture.md §6.3 根因溯源节点设计；.claude/agents/validator.md |
| 并行智能体必须用 git worktree 隔离工作区，否则会互相踩（文中举 Bun 团队真实翻车案例） | 并行 Coder 节点强制走独立 worktree，self-target（自举）场景无条件强制 | src/work_node_run.py::create_worktree / ensure_worktree_committed；CLAUDE.md「Isolation」小节 |
| 图需要锚点（Anchors）：真跑过的测试、基于证据的判定、不可被智能体自行调整的冻结规则 | Validator 只出 PASS / FAIL / INCONCLUSIVE 三态，且要求独立复核证据，不采信 Coder 自称"测试通过" | docs/graphlemon_architecture.md §9.1（qa profile 映射） |
Work Graph 层直接用 Claude Code 原生 agent()/parallel()/pipeline()，编排本身零 token |
已决策并做过实测验证 | docs/graphlemon_architecture.md §10.1；spikes/a1-dynamic-workflows/ |
2. 5 步版提到、但 graphlemon 仍是"已知简化项"的部分
这几条是本轮对照读出来的待办候选，还没有决定要不要做、什么时候做：
loop-until-dry（连续 K 轮无新发现才停止） 现状：Org-level Loop 固定 3 轮上限，超过未收敛直接转
blocked_pending_human。 出处：docs/sdd/04-P-流程与状态流转.md（明确标注为"未来优化候选"）；docs/sdd/06-验收与测试锚点.md。 5 步版的场景（第 4 步"未知规模的发现"）建议连续两轮无新发现才停，比固定轮次更适合"扫描规模未知"的任务——这跟 Validator 未来如果要承担"未知规模缺陷扫描"类任务是同一个开放问题。按节点分层选模型（便宜模型跑重复/有界节点，贵模型做综合裁决） 现状：
src/agent_profile.py里 Planner / Coder / Validator 三个 Org Agent 目前全部固定claude-sonnet-5，Work Graph 内部节点也没有差异化选型。 出处：docs/graphlemon_architecture.md§10 表格第 12 行早就标注"应补进第 7.5 节预算护栏"，至今未落地。1000 智能体 / 16 并发的量级验证 graphlemon 目前的 Work Graph 场景（自举开发自己）是个位数到十几个节点的规模，从未真正测过大规模 fan-out。5 步版给的"先 20 个探路，看单次运行花多少钱再放开"的做法，如果以后要做"审计整个代码库"这类任务，可以直接借用作为验证节奏。
3. 一处架构定位上的差异（不是缺口，是设计选择）
5 步版第 5 步专门讲"什么时候不该用 Graph"（任务太小/太孤立、需要人紧盯每一步、还在探索阶段、步骤间真正强依赖 → 别上图，用一个 Loop 就够）。
这个判断题在 graphlemon 里不是留给每次任务临场判断的，而是直接被架构的两层设计固化成了硬边界：
- Org Graph（Planner → Coder → Validator）人工固定设计，永远不是"动态生成的图"——恰好对应 5 步版说的"步骤间真的互相依赖 + 需要锚点 + 不该让智能体自己改架构"这一类场景。
- Work Graph 才是 5 步版描述的那种"动态生成、可扇形展开"的图，且作用域被限定在单次 Org Agent 调用内部（Planner 一次规划、Coder 一次实现、Validator 一次验收）。
也就是说，graphlemon 把"要不要上图"做成了架构里的一条硬边界，而不是运行时的判断逻辑——这一点比 5 步版单纯给"判断标准"更进一步，值得在后续讨论里明确写进架构文档，作为对 5 步版方法论的一个延伸。
4. 待讨论的开放问题（供下一轮会话展开）
- [ ] loop-until-dry 是否要在 Validator 的"未知规模缺陷扫描"场景里落地？优先级几何？
- [ ] 按节点分层选模型：Org Graph 三节点要不要差异化？Work Graph 内部节点（Planning Skill 生成的编排脚本）要不要在 Prompt 里显式要求按任务复杂度选模型？
- [ ] 是否需要在
docs/graphlemon_architecture.md里补一节，显式写明"Org Graph 固定 / Work Graph 动态"这条边界与 5 步版"何时不该用 Graph"判断标准的对应关系？