宜博 / lemongraph

Commit 2cf260f81c3dac3d2857569f5e977da2cfc34303

Authored by graphlemon
1 parent f16d21bf

graphlemon: auto-commit uncommitted changes for 08b89f13-2c70-4f72-b743-6c6e8170… 

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