Graph Engineering 系列对照笔记——待确认事项清单
日期: 2026-08-04
性质: 从三份对照笔记里提取出的全部"待讨论的开放问题"，去重合并后按主题整理，供逐条确认方案。每条确认后会展开成独立的需求文档（参考 docs/work-graph-parallel-execution-requirements.md 的产出方式），本文件本身只做索引和现状追踪，不写详细方案。
来源文档：
docs/reference/graph-engineering-1000-agents-5-steps.diff-with-graphlemon.md（简称"5 步版对照"）docs/reference/graph-engineering-vs-loop-engineering-overview.diff-with-graphlemon.md（简称"综述版对照"）docs/reference/Graph Engineering with Claude_ 14-Step roadmap from 0 to graph architect (Full Course).diff-with-graphlemon.md（简称"14 步版对照"）
三份笔记里有几条开放问题实质上是同一件事的不同角度，已在下面合并并标注了原始出处。
状态图例
- 🔲 待确认：还没讨论方案
- 🟡 讨论中/已产出需求文档，待评审
- ✅ 已确认，进入设计/实现
- ⛔ 已确认不做（附理由）
A. 架构文档要不要正式采用"工作图 / 角色图"命名
状态：🔲 待确认
来源：5 步版对照 §4 开放问题 3 + 综述版对照 §8 开放问题 1（同一件事，两份笔记从不同角度各自提出）
背景：综述版文章提出一条治理红线——"工作图"（任务怎么拆怎么合，可以快变）vs "角色图"（谁有权改什么，必须慢变可审计）。这条边界跟 graphlemon 现有的 Org Graph（人工固定设计，架构变更需人工评审）/ Work Graph（每次任务动态生成）边界几乎是同一件事的两种命名。5 步版对照笔记是从"什么时候不该用 Graph"的角度独立推出同一条边界的。
需要确认的问题：是否要把 docs/graphlemon_architecture.md 里"Org Graph 固定 / Work Graph 动态"的表述，正式替换或补强为综述版这套"工作图 / 角色图"命名？这是纯文档措辞层面的决策，不涉及代码改动。
B. loop-until-dry 要不要在 Validator 落地
状态：🔲 待确认
来源：5 步版对照 §4 开放问题 1
背景：Org-level Loop 目前固定 3 轮上限（docs/sdd/04-P-流程与状态流转.md 已标注这是"未来优化候选"）。14 步版对照进一步发现：这不只是优先级问题——work_graph_orchestrate.py::topological_order 对有环的 graph_manifest 直接报错，Work Graph 被设计成严格 DAG，图内根本不支持回路，要支持 loop-until-dry 需要动执行模型本身，不是加一个判断逻辑那么简单。
需要确认的问题：这条要不要立项？如果要，是在 Org-level Loop 这个更粗的粒度上做（比如把"3 轮固定"换成"连续 K 轮无新 bug 才停"，不涉及 Work Graph 内部执行模型），还是真的要改到 Work Graph 内部支持图内回路（工作量大得多）？
C. 按节点分层选模型——策略归属
状态：🔲 待确认
来源：5 步版对照 §4 开放问题 2 + 14 步版对照 §1 表格第 12 行 / §3 开放问题 3
背景：agent_profile.py 里 Planner/Coder/Validator 三个 Org Agent 目前全部固定 claude-sonnet-5。14 步版对照进一步发现：Work Graph 层的管线其实已经打通了一半——_render_node_script 支持往生成的单节点脚本里塞 model 参数，run_fn(cwd, model=None) 也留了口子，但没有任何调用方真正传入非 None 的值，graph_manifest 的节点结构里也没有 model 字段。基础设施就位，缺的是"谁来决定每个节点该用哪个模型"这层策略。
需要确认的问题：
- Org Graph 三节点（Planner/Coder/Validator）要不要差异化选型？
- Work Graph 内部节点的模型策略该由谁定——Planning Skill 生成
graph_manifest时就给每个节点标注推荐模型，还是在run_graph()里按org_node/artifact_type写一张静态映射表？
D. Time-travel 调试要不要立项
状态：🔲 待确认
来源：综述版对照 §6
背景：LangGraph 的 checkpointer 支持回到任意历史检查点重放/分叉。graphlemon 目前的容错（部分节点失败保留已成功节点输出）、人在回路（Start/Pause/Stop）、记忆（.claude/agent-memory/）都已具备，唯独"回到某个历史节点重新分叉执行"没有，现状是"用 git 历史 + 手动重跑"。
需要确认的问题：这条要不要立项，还是维持现状，等真正遇到大规模 Work Graph 调试痛点（比如「Work Graph 节点并行执行」上线后图变复杂了）再评估？倾向于暂不立项，但需要你确认。
E. Planning Skill 提示词强化——识别可并行节点
状态：🔲 待确认
来源：综述版对照 §7 开放问题 3 + 14 步版对照 §3 开放问题 2（同一主题：让 Planning 阶段更早识别并行机会）
背景：work_graph_plan.py 里 Planning Skill 的 prompt（约在 work_graph_plan.py:67 附近）目前只要求"一个 artifact_type 一个节点"，没有引导 Claude 识别哪些节点互不依赖。目前观察到的真实 graph_manifest（如 BRD→PRD→SDD→Benchmark）是纯串行链，架构文档 §6.1 设想的并行候选点从未真正被生成过。
需要确认的问题：要不要把 14 步版"对每个箭头问是否真的有数据流动"的提问方式、以及 Anthropic 官方"并行可分解 / 单一上下文装不下 / 收益覆盖成本"这三条尺子，显式写进 Planning Skill 的 prompt，让它在生成 graph_manifest 阶段就标注可并行的节点组？
依赖关系：这条和「G. Work Graph 节点并行执行」是互补的——G 解决"执行层能不能并发跑"，E 解决"规划层会不会生成值得并发的图"。E 做了但 G 没做，并行能力用不上；G 做了但 E 没做，graph_manifest 大概率还是纯串行链，G 的能力也没有实际发挥空间。建议两条一起排期，但可以先确认 G（已有需求文档），E 单独讨论。
F. 三视角评审团机制要不要推广到其他验证点
状态：🔲 待确认
来源：综述版对照 §7 开放问题 4 + 14 步版对照 §3 开放问题 4（同一主题）
背景：root_cause_trace.judge_root_cause（正确性/需求完整性/Skill 缺陷三视角，≥2/3 一致才定案，否则升级人工）目前只服务于 Validator 的 test_failed 根因溯源场景。run_graph() 自身的 verify_fn 是单一验证器 + 失败重试一次，没有多视角/对抗式/评审团这类"重打法"。综述版文章把这类重仓验证归为"高风险场景才用"，暗示应该按风险分级选验证强度，而不是所有节点统一同一套。
需要确认的问题：要不要把三视角评审团模式也下沉到 verify_fn 里，作为高风险节点（比如 SDD、代码变更）的可选验证强度？如果要，"高风险"的判定标准是什么（节点类型固定标注，还是运行时动态判断）？
G. Work Graph 节点并行执行（Python 线程池方案）
状态：🟡 已产出需求文档，待评审 → 详见 docs/work-graph-parallel-execution-requirements.md
来源：14 步版对照 §3 开放问题 1
背景：run_graph() 目前严格串行执行所有节点，即使 graph_manifest 里的节点互不依赖。已经讨论过按拓扑层分批 + 线程池并发的方案，核心风险（SQLite 并发写入、worktree 创建竞态、配额错误处理）都已识别，且发现 backend_server.py 里已有可复用的"共享连接 + threading.Lock()"先例。已产出完整需求文档（目标/非目标/功能需求/验收标准/风险/开放问题），可以直接进入评审。
需要确认的问题：这份需求文档本身要不要按现在的范围继续往设计阶段走？还是需要先调整需求文档里的某些点？
建议的确认顺序
G 已经有现成的需求文档，最接近可以推进的状态，建议先确认。E 和 G 强相关（不改 Planning Skill，G 做出来的并行能力可能用不上真实的并行图），可以放在 G 之后一起看。A（纯文档命名）、B、C、D、F 相对独立，可以任意顺序讨论。
你想先确认哪一条？