41-graph-vs-fde-reliability-discussion.md 42.1 KB

Edit Raw Blame History


39. Graph 架构 vs FDE 工作流 —— 稳定性对比讨论记录

日期: 2026-08-28
性质: 讨论记录（口语化保留，未做书面化改写），不是设计方案——不代表任何一条已拍板。
参与：yibo（用户）、Claude Code

起因
用户观察到 LemonBoss 同时有两套工作流机制——company 的 org/work graph（graph-engine.js）与 master-Innovator-FDE（retrain-pipeline.js + Hunt→Digest→Evolve）——并发现 FDE 用起来明显比 graph 更稳定、更丝滑，问为什么。讨论逐步展开到：根因是不是"拓扑写死 vs 运行时生成"、能不能拿 FDE 当参照物优化 graph、graph 现有设计在分支/回退边/多节点子图上是否有问题、以及用户提出的一套 company/vision/goal/org-graph/work-graph/boss-agent 心智模型是否成立。全部结论均基于当次读码与读文档所得，供后续讨论/立项参考。


问题 1：为什么 FDE 比 graph 更稳定、更丝滑？
用户原话：


你看一下我们 lemonboss 的实现，既有 company 的 org work graph ，又有 master-Innovator- FDE 的这种工作流，这两个感觉 FDE 的实现比graph 的那种稳定可靠并且更灵活一些，为什么呢 ，使用起来更丝滑


回答：

看了 graph-engine.js（4669 行）和 FDE 的调度层 retrain-pipeline.js（541 行），加上 docs/todo/system-design/30 号（可靠性调研）和 21 号（FDE 架构）两份文档，差距确实是架构性的，不是错觉：

1. 复杂度差一个数量级，出错面也差一个数量级
Graph 要同时处理：node FSM 状态机、contract 产出/消费声明校验、多种边路由（forward/backward/fallback）、infra_flake 等失败语义特判、LOOP_HARD_CAP_EDGE/RUN 硬顶、任务级预算（agent_calls/tokens/wallclock）、招聘装配的异步时间窗（body_not_ready 网关）。FDE 本质上是三个固定角色的线性 dispatch 链（Hunt→Digest→Evolve），没有状态机、没有 contract 校验、没有分支路由，出错空间天然小很多。

2. Graph 的失败自愈机制本身成了新故障源
30 号文档记的那次真实事故很典型：infra_flake 这条"不烧预算、原地重跑"的自愈路径本意是兜基础设施抖动，结果被 org-coder-test 误产出的诊断文件触发，陷入确定性死循环，烧到 35/100 才被发现（2026-08-23 才补熔断线）。这是"为了让编排更灵活/更自愈"反而引入了脆弱性——FDE 没有这层，Evolve 的失败逻辑就是单变量收敛（score < 95 → 重来），没有组织级路由的复杂性可踩坑。

3. Graph 让 LLM 在运行时决定拓扑，FDE 不给这个自由度
executeSubgraph 里 org-planner 是动态生成图结构的（buildPlanningPrompt），LLM 拓扑决策一旦和引擎假设对不上就是新的边界情况（33 号的 needs-gate bug、31 号兜底边覆盖不全都是这么来的）。FDE 的三阶段管道是写死在 dispatch 脚本里的，"下一步找谁"不需要 LLM 现场决定，人/ Innovator 只是按提前设计好的顺序推进，天然更可预测。

4. 中间产物可读性不同，人工纠偏的顺滑感来自这里
FDE 每步产出是 knowhow.md / benchmark_v1.md / evolve_log.md，人一眼能看懂、随时能插手改。Graph 卡住时是数据库里的 node/contract JSON，30 号文档说得很直接："卡住了不会主动喊人"，得去翻状态或内存曲线才能发现——这也是我们记忆里那几条"僵尸 goal"反复出现的根因形状。

但要说清楚一点：这不完全是纯架构优劣，也有成熟度差异——FDE 已经端到端验证通过，且 36 号文档证实"对方法论类角色确实管用"；但同一份文档也承认它"收敛速度/验收严谨度依赖任务书显式写明的自纠正要求，非免人工黑盒"，不是自动就稳。Graph 这边则明确还在推进（27 号索引写着 P3B/P4 没收尾）。所以更准确的说法是：FDE 用"牺牲通用性换确定性"换来了稳，Graph 用"承担组织级复杂度换灵活性"目前还没把复杂度对应的边界情况踩完。


问题 2：是不是因为 Innovator 的工作流是代码写死的？
用户原话：


是因为 Innovator 的工作流是代码写死的么？


回答：

对，而且证据很直接——server/services/retrain-pipeline.js 里字面意义上写死了：
const STEPS = ['re_hunt', 're_digest', 'evolve'];   // retrain-pipeline.js:12
...
for (let i = startFromIndex; i < stepConfigs.length; i++) {   // :216
  evolveResult = await this._runStep(step, manager, logger, taskMgr);
}


stepConfigs（:155-211）连每一步调哪个 agent（innovator-hunt/innovator-digest/innovator-evolver）、prompt 长什么样都是硬编码的 JS 字符串模板，谁都不需要"决策"下一步找谁——就是一个普通的 for 循环 + 每步 1 次重试（MAX_RETRIES=1）+ 失败就抛错、成功就写 checkpoint。文档 21 号里那三条 curl dispatch 示例也是同一个模式：Hunt→Digest→Evolve 的顺序是写在任务模板里的固定协议，不是谁临场推理出来的。

更有意思的反证在同一个文件里：retrain-pipeline.js 其实也有一个"不写死"的模式——runWithMaster()（:353 起），让 Master Agent 通过 call_sub_agent 工具自己决定调用顺序、自己判断该重试还是跳过。但代码对这条路径的信任度明显更低：一旦 Master 编排抛异常，直接降级回硬编码版（:528-530 console.log('⬇️ 降级为 Node.js 串行模式')）。也就是说，代码作者自己权衡下来，硬编码顺序执行才是兜底、可信的那一层，LLM 决策的编排是可以失败并被替换掉的"增强模式"。

所以结论是：


FDE 稳，本质是因为拓扑（先 Hunt 再 Digest 再 Evolve）在代码/协议层面就是常量，只有每一步的 prompt 内容是可变的。没有任何一步需要 LLM 现场决定"接下来该找谁、图该长什么样"。
Graph 相对不稳，恰恰是因为拓扑本身是运行时生成的——graph-engine.js 的 executeSubgraph/buildPlanningPrompt 是让 org-planner（LLM）在运行时产出图结构，引擎再去执行一个它自己也不知道长什么样的图，所以才需要一整套 FSM + contract 校验 + 失败路由去兜住"LLM 生成的拓扑可能不符合引擎假设"这类不确定性——而这套兜底机制本身又成了新的故障源（比如上次那个 infra_flake 死循环）。


一句话：FDE 把"决定做什么"这件事从运行时挪到了写代码/写协议的时候，Graph 把它留在了运行时交给 LLM，稳定性的差距很大程度上就是"编译期确定 vs 运行时涌现"的差距，不是两边 agent 能力强弱的问题。


问题 3：能不能新建 company 用 org+work graph 复刻 FDE，作为参照物来优化 graph？
用户原话：


所以我们新建一个 company 使用 org + work graph 复刻 FDE 的流程，这个可行么？然后利用 FDE 成熟的流程对比，来优化我们 graph 的运行过程，作为参照物来运行，实现 graph 的优化？可行么额？


回答：

技术上可行，但作为"参照物来优化 graph"这个定位，价值有限——原因不在能不能建，而在能测到什么。

可行的部分：org graph 现在的图结构是 orggraph-planning/org-planner 在运行时用 LLM 生成的（executeSubgraph + buildPlanningPrompt），但没有什么硬约束逼你必须走这条路——完全可以手写一份固定的 3 节点线性图定义（hunter→digester→evolver，类似 executor.json/planner.json 那种预先写死的图），跳过 LLM 现场规划这一步，直接建公司时装配进去。而且 FDE 的 Evolve 阶段本身就有量化分数（≥95），这一点跟 goal-contract 的 benchmark/test-script 校验机制其实很契合，不会像 29 号文档里 dream 折进 graph 那样撞上"自由文本判断没有对应机制"的墙（那是 dream 特有的问题，FDE 不会撞上）。

但价值有限的地方：目前记录在案的 graph 不稳定案例——33 号的 needs-gate 误判、31 号兜底边覆盖不全、30 号那次 infra_flake 死循环——全部发生在带分支/回退边的多节点子图里（org-coder 那一族），不是线性流程的问题。一个 Hunt→Digest→Evolve 的三节点线性图，天生没有 backward 边、没有 fan-out、没有跨节点 contract 竞争，几乎不会触发那些真正让人头疼的 bug。跑起来大概率会很稳，但这只能证明"图引擎处理最简单的线性拓扑没问题"，证明不了"图引擎处理复杂拓扑该怎么改"——你想诊断的问题和这个参照物能覆盖的场景是错开的。

建议：如果目的是"验证我们上次的判断——拓扑写死就会稳"，这个实验值得做，把它定位成最简单场景的回归基线/冒烟测试就很合适。但如果目的是"拿它当参照物来优化 graph 现有的不稳定点"，那需要复刻的不是 FDE 的线性三步，而是一个带分支和回退边、故意模拟 org-coder 那种验证-打回循环的对照图——只有这种才会踩到跟真实故障同类的坑，才谈得上"参照"。


问题 4：graph 在分支/回退边/多节点子图这些地方的设计是不是有问题？
用户原话：


所以我们的 graph 在 org 或者 work graph 的设计是不是有问题，特别是带分支，回退变 多节点子图这些地方


回答：

看了 routeFailure（graph-engine.js:1983 起）和跨层寻址的实现（R-17.1，:576-596），结论是：核心设计不算差，但有一处明确的、还没补完的口子，加上一块干脆还没做。分开说：

1. 回退边/跨层寻址：这块其实做得比想象中扎实
fail_node_ref（org node + work node 两级地址）、双层硬顶（LOOP_HARD_CAP_EDGE 单边 3 次 + LOOP_HARD_CAP_RUN 整棵树 5 次）、地址解析不出来就优雅退化成"整张 work graph 重跑"而不是卡死、每次回退都完整记 loop record（verdict/remediation_note/target_node_ref）留痕——27-p3-p4-work-graph-console.md 里这块（R-17.1）是返工过一轮、专门写了死锁复现脚本 + 16 断言的真实 HTTP 回归测试才定案的。这不是拍脑袋写的，是撞过死锁、吸取教训后收敛出来的设计，不算薄弱环节。

2. 但有一处明确的例外没堵上：infra_flake 分支绕过了这套跨层寻址
routeFailure 里 infra_flake 走的是完全独立的"原地重跑"分支（:1983-2020），根本不查 target_node，直接重跑判定失败的那个节点本身。30 号文档 §四记的那次死循环正是这个口子：诊断节点说"该重跑 validator"，但地址信息被这条分支忽略，只会一遍遍重跑诊断节点自己。2026-08-23 的修复（2f177c7）只加了熔断计数，没有让这条分支也去认 target_node——文档原话是"没查清楚之前不改选边的语义"，这是一处故意留着、待后续设计澄清的真实缺口，不是随口一提。

3.（2026-09-08 更新：本节写作时是真的，现在已经不成立）多节点子图的并发 fan-out 已经做完了
27-p4-parallel-and-artifacts.md 本节写作时状态是"📝 设计中，未实现"，2026-09-08 已彻底收口：同一 agent 多实例隔离、真并发 fan-out、产物索引（形态从设计里的 files.json 改成了 graph_files 表）全部上了生产，外加当时没单独列出的 advanceTree 兄弟子 run 并发也一并补齐。"带分支的多节点子图"现在真的会并发跑，不再是顺序执行——高并发下的资源竞争验证见 27-P4 §4.2 的接线记录。

4. 部门级多图（37 号）也是同一类——org graph 目前按 company_id 单例，一家公司只能有一张组织图，HR/财务这类跟交付流水线无关的常设职能没图可挂。调用点扫描发现改造面是最初估算的 4 倍，目前停在"设计讨论，尚未立项"。

综合判断：不是"设计有根本问题"，更准确的描述是——核心的失败路由/跨层寻址机制是稳的，经过真实故障淬炼过；但系统还年轻，复杂度大头（并发 fan-out、部门级多图）还没真正上线跑过，已知的坏味道（infra_flake 绕过寻址）也还没补完。30-37 号那几份文档的共同模式是"真跑撞出具体缺陷 → 定点修补"，不是"重新设计"，这本身是个健康信号，但也说明分支/回退边/多节点这些复杂场景的实战验证覆盖度还不够——如果要优化，infra_flake 的 target_node 路由缺口和 P4 并发 fan-out 是两个最值得先补的点，都是文档里已经点名、只是还没排上优先级的。


问题 5：company/vision/goal/org-graph/work-graph/boss-agent 的心智模型是否成立？
用户原话：


所以我们的架构应该是一个 company有一个vision 愿景，一个 vison 分解为多个 goal执行目标 ，一个 goal 对应计划出来一个 org graph，对应多个 task 和 subtask （类似于 ork 的 object+kr），一个 task 对应一个 work graph（动态 plan 出来，引用不同的 system agent 来工作），是这样吗？company 可能有一个 boss agent 来监控和调度所有 goal task work 的工作状态。 类似于我们 FDE 的 master agent 的样子。 可以这么理解么？ 这样既可以保证公司的某个人物的固定流程，比如Innovator FDE 训练新的 agent就是 hunter-digest-evolving 这一个 org graph ，就可以实现，每一个 hunter 执行的时候看看要不要 fan out 成多个 sub agent ，或者就单独一个节点执行即可。现在的 hunter 是做了多个 deep research 来完成的，只是他没有用 work graph 展现而已。


回答：

这个心智模型大部分方向是对的，但有一处正好撞上了团队已经讨论过并明确否决的方案，值得先说清楚，免得往错的方向去实现。逐条对：

✅ Company : Vision（company-goal）= 1:1，成立时定 —— 对，orggraph-planning 建公司时读的就是这个 goal/description。

❌ Goal → 计划出一个 org graph —— 这个具体想法已经被讨论过并否决了
37 号文档（37-org-graph-department-scoping.md §一）原话就是在评估这个方案："再讨论'能不能按 goal/task 现场 plan 出不同的 org graph'"——结论是不行，两个理由都是硬的：


治理红线：org graph 被设计成"公司角色结构"，理应慢变、可审计（类比真实公司的组织架构图，不会因为接了个新项目就重画一遍）；work graph 才是快变、按任务现场规划的。把 org graph 也现场 plan 出来，等于把慢变的角色结构拉进快变的任务节奏，这条边界就没了。
技术硬限制：引擎的 activateSuccessTargets（graph-engine.js）对 condition='success' 的出边是无条件全部点亮，没有 fail_reason 那种按路由键精确匹配的机制。就算画出多条按 goal 类型分叉的 org graph 分支，今天的引擎也做不到"按任务类型只走一条"——这不是没想到，是现在的选边逻辑压根不支持。


实际的模型是：一家公司只有一张 org graph（单例，company_id 是唯一作用域键，写进了执行引擎热路径的裸 SQL 不变式）。Goal 不会去生成 org graph，而是被 task-planning 拆成多个 task（goal.description + 公司 org graph 摘要 + 可用角色清单 → 拆出 task 列表），这些 task 流经同一张公司级 org graph（从它唯一的入口节点进入）。"OKR 的 O+KR"结构其实已经在做了——只是层级是 goal（O）→ 多个 task（KR/执行单元），不是"goal → org graph"。

已经被接受、但还没实现的替代方案是部门级 org graph（同一份 37 号文档提出）——一家公司可以有多张org graph，但按部门（HR/财务/交付流水线各一张）分，不是按 goal 分，因为部门这条轴依然是慢变的，不会破坏那条治理红线。这个方向目前还是"设计讨论，尚未立项"。

✅ 一个（org graph 节点接到任务时）→ 动态 plan 出一个 work graph，引用不同 system agent——这条基本对，但精确说法是"work graph 挂在 (org node, task) 这一对上"，不是"挂在 task 上"。一个 task 如果依次流过 org-planner → org-coder → org-validator 三个 org 节点，理论上会产生最多三张 work graph（每个节点接到任务时各自现场规划一张），不是一个 task 只对应一张。

🔶 "boss agent" 监控调度所有 goal/task/work 状态——这个想法是对的，而且是在补一个真实存在的空档，不是重复造轮子。现状是没有这样一个主动监督的 agent——goal 的自动结算靠的是被动钩子（settleRootRun 只在 run 转终态那一瞬间触发一次同步，没有补跑兜底），此前处理过好几次"僵尸 goal"（task 完成了但 goal 永远卡在 active）都是这个空档的直接后果。这个"boss agent"如果做成一个会主动巡检 goal/task/work 状态、发现卡住/漏结算就出手的角色，正好是这类问题该有的解法，而不是靠人工巡检 + 事后修复。

🔶 hunter 现在的多路 deep research 用 work graph 显式表达出来——方向对，但要承认这是拿"稳"换"可观测"。现在 hunter 内部多路调研是单个 agent 会话里的工具调用循环，图控制台完全看不到；改成显式 work graph（fan-out 多个子节点各跑一路调研，fan-in 汇总）确实能拿到审计轨迹、单节点重试、进度可视化。但这正是前面几问的主线——动态生成拓扑的地方越多，就越接近 org graph 今天暴露出的那些坑（回退边路由、infra_flake 之类），FDE 现在的稳定恰恰来自"没有把这层展开成图"。要不要展开，取决于更想要"可观测性"还是"目前这种确定性的稳"——不是免费升级。


问题 6：新建 Innovator 公司雇 FDE 三个 agent 为 org graph + 每公司配 boss agent + master 作平台级唯一 master，这样落地可行么？
用户原话：


ok，那我理解了，那我们先不做架构改动了，我们新建一个 Innovator 公司，将 FDE 三个核心 agent 雇佣成为 org graph，我来发送任务给他们，让他们工作如何？同时我们需要给每一个公司配一个 boss agent， 让我跟这个公司的 boss agent 发送指令，调度 org ，监控进度，master 则是作为整个平台所有公司的 master 来运行，是这样么？


回答：

方向都对，但各有一个要注意的具体点：

1. 新建 Innovator 公司 + FDE 三个 agent 雇成 org graph —— 可行，但两个坑要避开


建公司时别让 orggraph-planning 自动规划。默认流程是建公司 → 自动 hire orggraph-planning → 它用 LLM 现场生成图（buildPlanningPrompt）。如果走这条默认路径，拿到的还是一张"运行时生成"的图，不是问题 3 里说的"写死拓扑换稳定性"那个效果。要真正复刻 FDE 的确定性，得绕开 planner，直接调 POST /api/company/:companyId/org-graph 手写 3 节点线性图（innovator-hunt → innovator-digest → innovator-evolver，全 forward 边），过图的四项合法性校验（无环/单入口/可达/回退边显式标注）就能落库，不需要 LLM 参与拓扑决策。
agent id 是 innovator-hunt / innovator-digest / innovator-evolver，不是 hunter/digester/evolver——查了 system/agents/ 目录，实际 id 是这三个（21 号文档里的"Hunter/Digester/Evolver"是角色显示名，不是可雇佣的 id），parent_id 都指向 innovator。雇的时候用这三个 id。
要留意一个协议不匹配的风险：这三个 agent 现在的 agent.md 是按 21 号文档那种 curl dispatch 协议写的（Innovator 手动 curl 一段固定文案给它们），不是按 graph 引擎期待的 contract 协议写的（produces/needs 声明、attempt-N.json 归因文件、target_node 跨层地址）。直接把它们塞进 org graph 让引擎驱动，它们未必知道要按 graph 的格式产出——这个没法只看代码就下结论，得真跑一次看它们的输出格式对不对得上引擎的默认 executor 期望，建议先小范围跑通一次再放量。


2. 每个公司配一个 boss agent，人直接跟它对话调度/监控 —— 这个是要新建的东西，不是已有能力

CEO（system/agents/ceo，type: cxo）目前心跳是关闭的（heartbeat.enabled: false），也不在任何 org-graph-templates 里出现（dev.json 只有 org-planner/org-coder/org-validator）——它现在是个"存在但不干活"的角色，不是主动巡检 goal/task/work 状态的调度者。这个 boss agent 得真正新写：给它接上 goal/task/work 的查询能力 + 一个主动巡检循环（比如定期扫描"卡住的 run"、"结算漏掉的 goal"），CEO 是个合理的身份载体，但功能要从零搭。

3. master 作为全平台唯一的 master，不分公司 —— 这条已经是现状，不用改

system/agents/master/config.json 本身就是单例、无 company 归属字段，retrain-pipeline.js 的 runWithMaster() 也是拿它做跨公司/跨 skill 的编排入口。这条理解和现在的实现是一致的，不需要额外动作。

建议的落地顺序：先手写那张固定 org graph 试跑一次 Hunt→Digest→Evolve（验证协议对不对得上），再决定要不要投入去写 boss agent——后者工作量明显更大，值得先看第一步跑得顺不顺再定。


问题 7：落地实测——手写 org graph 真跑 Hunt→Digest→Evolve，结果如何？

日期：2026-08-28~29。承接问题 6 的落地顺序建议，这一节是真实执行记录，不是讨论——
每一步都有真实的 run id / 文件路径可查，不是复述结论。

7.0 第一次尝试：直接手写图用 innovator-hunt/digest/evolver——撞上竞态，废弃
按问题 6 的原计划，新建公司 innovator-fde-trial，绕开 orggraph-planning 自动规划，直接
POST /api/company/:id/org-graph 手写 3 节点线性图（innovator-hunt → innovator-digest →
innovator-evolver）。这一步本身就踩了坑，而且证实了一个真实竞态：建公司这个动作的自动
规划触发（triggerOrgGraphPlanning）是 fire-and-forget、无法跳过；手写图落库后 2 分 51 秒，
orggraph-planning 的异步 LLM 会话跑完，调用同一个 POST /org-graph 把手写图整个覆盖掉，
换成它自己规划的 5 节点图（org-planner → fde-hunt → fde-digest → fde-evolve → org-validator，
fde-* 三个是它凭空杜撰的空壳角色）。当时正在跑的测试任务因此在 digest/evolver 两个节点引用
失效后被静默跳过，但 run_status 仍判 completed，goal 判 done，task 进度显示 3/3——
局部失败被终态掩盖，没有任何信号往上冒，这是一个真实的图执行完整性缺陷（详见 7.1 之前的对话
记录）。

顺带确认了一条架构红线：system/org-graph-templates/README.md"加一个新模板"第 3 条明确写着
innovator-hunt/innovator-digest/innovator-evolver（连同 agent-creator/org-innovator 等）
是"元 agent"，产出是"一个新本体"而不是"任务的下一步"，不允许作为 org graph 节点——这解释了
orggraph-planning 为什么会自己发明 fde-hunt 这类占位角色：它在照章办事，不是失误。

结论：不复用 innovator-hunt/digest/evolver 这三个真实 id，另建一套专门给 org graph 用的
新本体（方法论同源、协议原生兼容 graph）。这才是 7.1 起真正的实验。
7.1 新建 org-hunt / org-digest / org-evolve 三个 graph 原生本体
system/agents/org-hunt/ org-digest/ org-evolve/（各含 config.json/agent.md/soul.md/
identity.md/tools.md/user.md/heartbeat.md）。方法论内容（调研打法/知识结构化/评分迭代）
照抄 innovator-hunt/digest/evolver，协议层面重写：


不假设 FDE 原生的固定相对路径（train/{role}/{skill_name}/）；
不需要 report_task 汇报给 Innovator，节点成功/失败由 graph 引擎判定并流转；
org-evolve 的 Large Loop（原协议是自己 dispatch 给 Hunter 重新调研）改成判 fail +
写清楚上下文，交给图的回退边处理——不允许节点自己发起对另一个节点的调用。


type 定为 specialist（不落入 NON_ORG_AGENT_TYPES），status: active，跳过 draft 闸门。
7.2 五次真跑，五种命运，四个独立缺陷
用同一个任务（"为 AI Agent 记忆系统设计训练方法论技能包 agent-memory-methodology"，跟原生
FDE 无关，纯粹为了让 org-hunt 做真调研）反复 rerun 同一个 task，每次卡点都不一样：


#
run id
结果
卡在哪
根因


1
run_26a4af526384
blocked
org-hunt 内部 work graph
workgraph-planning 套 executor.json（代码测试范式），先后选 qa-judge（陷入 critic/judge 合一的无限重复确认，判 infra_flake）与 testdata-validator（死等任务本身不会产出的 acceptance.json），烧 20 次调用/31 分钟熔断


2
run_d907c1c4e5b6
blocked
同上，换了个包法
补了 deliverable.json 新模板后重跑，workgraph-planning 这一轮仍未选中它（原因见 7.3——首次规划、无失败史，惯性倒向熟悉的 executor.json），自己发明 org-hunt-check（systemAgentId 复用 org-hunt 自检），逻辑有 bug（按顶层 dict keys 而非逐条校验 items 数组），假阳性判 missing_required_input


3
run_e40c9fb9cc89
blocked
org-hunt-review（qa-judge）
规划给验收节点的任务描述越权，要求 qa-judge 顺带把 Digest+Evolve 的生产工作也做完；qa-judge 硬约束"Never Fix，只审判不动手"，如实拒绝，链路卡死


4
run_3daf5e784e2f
blocked
org-hunt-selfcheck（needs artifact）
最深的一个：org-hunt 把真实交付物写进了「项目根」子目录（我自己在 agent.md 里写错的指引），而引擎的产物索引 indexNodeOutputs() 只扫节点私有目录，项目根下的文件永远不会被索引成 artifact kind，下游 needs:["artifact"] 永远查不到实例


5
run_1ed8e5cca545
completed
—
修完 4 的路径问题后，org-hunt→org-digest→org-evolve 全部 success，backward_count=0，8 次调用，约 6.4 万 token，约 14 分钟


四个独立缺陷，没有一个是同一个坑的重复：


建公司自动规划与手写图的竞态（7.0）——writeGraph() 无版本号/乐观锁，谁后写谁赢。
work-graph-templates 库缺"内容型交付物"模板——只有 executor.json 一种"验收"语义
（代码测试 + acceptance.json），没有覆盖"调研/知识产出"这类不可执行交付物的模板，
workgraph-planning 自己 agent.md 里唯一的完整范例（第 399 行）也是 unit-tester/
coder-validator 字面写死的代码测试组合，进一步把它锚定在这套语义上。
已修：新增 system/work-graph-templates/deliverable.json（单节点起手式，不引入验证
agent，校验交给 org 层边上的 produces 契约），登记进该目录 README.md 的模板表。
验收节点任务描述范围溢出——workgraph-planning 给 review/validator 节点写任务描述时，
把"审查上一节点产出"和"接着干完下游职责"混在一起。已修：在
workgraph-planning/agent.md Step 4"你不被允许"里加了一条硬规则，点名这次真实事故。
两个规划 agent 的 Step 2/3 示例命令，路径口径写错了——ls system/{org,work}-graph-templates/
是仓库根相对路径，但这两个 agent 的真实 CLI cwd 是 system/agents/{本体}/{公司}/{run}/，
真跑验证过这条命令必定 No such file or directory；workgraph-planning/agent.md 里那段
"路径口径"说明本身也写错了 cwd（还停留在 28 批次 4 改造前的旧布局）。已修：两份
agent.md 全部改用 $REPO（来自首轮消息"写入边界"段给的绝对路径）显式拼接，不再用裸相对
路径或猜深度的 ../../../../。
（4 号 run 的根因）「项目根」与「节点私有目录」的产物索引缺口——引擎的写入边界允许
agent 写两处：项目根（代码/多文件产物）与节点私有目录（结构化产出/contract.json）；但
indexNodeOutputs()（决定 R-19 produces/needs 契约能不能兑现）只扫节点私有目录。
这不是 bug（项目根本来就不该被当成"单文件 kind 索引"的候选池，那是给整个代码工程用的），
是我自己给 org-hunt/digest/evolve 写 agent.md 时凭空编了一个 $PROJECT_ROOT/artifacts/hunt/
的产出路径，从没对照过真实注入的提示词。已修：三个 agent 的 agent.md/soul.md/tools.md
全部改成写进"节点私有目录"（提示词里"你的私有目录（可读可写）"给的绝对路径）。
⚠️ 实测发现 org-digest 这次仍把真实交付物写进了项目根（只把 contract.json 放对了
位置）——run 5 能跑通是因为 org-evolve 转而直接吃 contract.json 的 exports 绝对路径，
没有卡在严格的 R-19 索引查找上。排查发现根因是我自己第一轮的修复留了尾巴：
agent.md 里改了主要段落，但 Step 5「交付」和「✅ 始终要做」两处残留的旧措辞
（"写进提示词给定的产出目录"）没有跟着改，同一份文档里两种说法自相矛盾，LLM 挑了对自己
更顺手（"skill 包"整体打包在项目根下）的那种读法。2026-08-29 第二轮已把三个 agent 的全部
残留措辞扫了一遍，统一成"节点私有目录"，第六轮真跑验证中（见待跟进）。

7.3 deliverable.json 为什么没被选中——查清楚了，是"没撞过失败就不会认真选模板"
修完缺陷 4（路径口径）之后，重新核对第五轮（run_1ed8e5cca545）三个节点各自的规划记录，
发现一个此前误读的地方：org-hunt 这一轮其实正确选中了 deliverable.json（单节点起手式，
它的 §2 表原话："deliverable.json 的 whenToUse 原话点名 org-hunt……与 org-hunt 的产出形态
精确匹配，且模板文档明确以 org-hunt 作为案例说明不该套代码测试范式的验证 agent"）——上一版
本文档这里写错了，已订正。但 org-digest 和 org-evolve 这一轮的规划记录 §2 表里，
deliverable 压根没有出现，两者都直接沿用了"executor.json 裁剪成两节点"的方案。

三者的差异只有一处：org-hunt 在此之前真实失败过 3 次，remediation_note（Step 1 的四项
输入之一）里点名过 deliverable.json；org-digest/org-evolve 是这条流水线里第一次被规划，
从没失败过，没有 remediation_note 逼它重新核对协议细节。 已排除的可能性：getAgentPrompt()
不走进程级缓存、ls/cat 路径本身已修对、buildPlanningPrompt 确实把 $REPO（REPO_ROOT
绝对路径）写进了提示词的「写入边界」段——技术上模板文件对三个节点都是可见的。
真正的规律是注意力分配，不是文件读不到：workgraph-planning 自己 agent.md 里唯一的完整
范例就是 executor.json 的 coder/unit-tester/coder-validator 三元组，首次规划、
没有失败逼着它慢下来核对时，习惯性地倒向这个最熟悉的骨架，deliverable.json 甚至没有被
列进候选表参与比较——不是"比较后选错"，是"根本没认真比较"。

已修：workgraph-planning/agent.md Step 2 加了第二条硬规则，要求不管有没有失败史，
每次都要老实问"宿主节点的产出能不能靠跑代码/跑测试验收"，答案是否定时必须逐字读一遍
deliverable.json 的 whenToUse 再决定，不能因为 executor.json 更眼熟就默认用它。第六轮
真跑验证中（见待跟进）。
（更信任自己熟悉的 executor.json），不是一处能一次性定位的代码缺陷。run 5 能跑通，走的是
"executor.json 裁剪成两节点 + 验收节点任务描述写对范围"这条路，不是 deliverable.json 生效。
7.4 最终产出 vs 原生 FDE（prd-methodology-trial，36 号文档阶段二真实收敛案例）对比
内容骨架可迁移：graph 版 Hunt 产出 13 个真实数据源（arXiv 论文/官方文档/厂商博客，均带
source_url+crawl_time）+ 52 条结构化种子数据；Digest 产出五段式 SKILL.md（领域识别→
四层分工→架构选型→存储检索→遗忘评测）+ 5 维度 benchmark.md。跟原生 FDE 的
knowhow_v1.md/benchmark_v1.md/SKILL.md 完全同构——FDE 方法论本身可以原样迁移到 graph
执行，内容质量没有打折。

过程严谨度：原生 FDE 明显更深。原生 FDE 的 evolve_report.md 做了这些 graph 版完全没做的
事：质疑并重新推导目标分数（任务书给 95 分，自己论证跟 benchmark 刻度不兼容，改用 80 分，还
引用了 Digest 阶段的推理链）；真跑 2 轮迭代并修了一个真 bug（CTA 跳转目标歧义）；如实记录了
一个没修的方法论局限。graph 版 Evolve 第 1 轮就 89.1 分（行业均线 72，且这个均线被 Digest 自己
标成 "industry_avg_is_estimated": true）、weak_dimensions=[]，直接判 success 收工——从没
真正触发过"发现弱点→改 SKILL→重测"这个循环。

可靠性差距最悬殊：原生 FDE 这个 trial 是一次性跑通的（36 号文档记录）。graph 版跑到
第 5 次才成功，中间挖出 4 个独立真实缺陷（见 7.2 表）。这是 39 号文档主线论点的实测实锤：
FDE 稳，是因为"下一步找谁"从代码/协议层面就是常量；graph 每一层（建图、规划子图、写文件
的位置）都还留着运行时才会暴露的缝——这次不是继续推理，是拿真实数据坐实了。


待跟进事项（未拍板，仅记录）

[x] 手写固定 org graph 小范围试跑，验证协议兼容性——已完成，见问题 7；结论是不能直接复用
  innovator-hunt/digest/evolver（元 agent 红线），改用专建的 org-hunt/digest/evolve。
[x] deliverable.json 选型修复——已验证生效。第六轮（run_c01a9f309492）org-digest 的
  规划记录 §2 表正确选中了 deliverable.json，理由原文引用了 org-hunt 此前的死循环案例。
  Step 2 那条"不管有没有失败史都要认真核对"的硬规则起作用了。
[x] org-digest/org-evolve 是否遵守"写进节点私有目录"——验证结果是没有，但查到了更深的
  根因，之前的修法是权宜之计。第五、六两轮里 org-hunt 100% 遵守，org-digest/org-evolve
  仍把 SKILL.md/knowhow.md/benchmark.md 这类最终交付物写进了项目根（org-digest 第六轮
  的归因文件原话："交付...到项目根，供 org-evolve 直接读取"）。回查引擎真实注入的写入边界
  原文——"一切代码/测试/配置/交付物都写在这个项目根里面"——项目根本来就是官方指定给
  "交付物"用的地方，节点私有目录是给结构化产出/归因/契约用的。org-digest/org-evolve 把
  SKILL.md 放项目根其实是在老实遵守系统给的通用规则，不是在犯错。
  真正的缺口在 indexNodeOutputs()（R-19 产出索引）只扫节点私有目录、完全不覆盖项目
  根——对代码类节点（下游靠"跑测试"直接读项目根）不致命，对内容类节点（下游靠 R-19 kind
  索引 relay）就会致命。之前"逼三个 agent 都写私有目录"的修法只是权宜之计，不是根治；
  根治应该是让 indexNodeOutputs() 也覆盖项目根内的产出，或给 agent 一个显式声明"项目根下
  这个路径是我的 kind=X 产出"的机制——这个改动面比三个 agent 大得多，影响所有 org node，
  未拍板是否要做，留作独立跟进项（见下一条）。两轮真跑（5、6）都靠 contract.json exports
  兜底成功，当前不是阻塞性问题。
[x] indexNodeOutputs() 覆盖项目根产出——已修复并验证生效（2026-08-30）。改法：
  contract.json 新增 produces: {kind: 绝对路径} 显式声明字段（readDeclaredProduces()），
  校验通过（绝对路径/落在项目根或私有目录内/文件真实存在）才登记，不满足整个 kind 判
  「没产出」；全局提示词（describeArtifactContract）同步教会所有 org/work 节点。
  第 9~12 轮反复真跑验证：org-hunt/org-digest/org-evolve 声明的产出（不管物理落在
  私有目录还是项目根）全部正确索引，recordFile 逐条确认成功。已提交（496c249），
  补了 2 条守卫测试（graph-files-index.test.js ⑫⑬：声明生效 / 越界声明被拒）。
[x] 第 6 个独立缺陷：workgraph-planning 按"名字语义匹配"误选 validator.json 专属本体——
  第 11 轮 org-evolve 规划验收节点时，选了 benchmark-validator（"对评分结果做验收判决"，
  名字很贴切），但该本体硬编码读 artifacts/goal-benchmark.json（只有 planner.json 的
  goal-benchmark 节点才产），这条 Hunt→Digest→Evolve 链路里根本没有该节点，两轮都判
  blocked。根因：benchmark-validator/testdata-validator/validator-triager 不是
  通用验收工具，是 validator.json 骨架专属、绑定任务级共享契约文件的本体。已修：
  workgraph-planning/agent.md 加第三条硬规则（判据从"名字像不像"改成"这条链路里有没有
  节点产 goal-benchmark.json/acceptance.json"）；deliverable.json 的 whenToUse 补上
  "自带自评分收敛逻辑的节点也不需要外部验收节点"这条例外条款并点名这次事故。第 12 轮
  真跑验证：org-evolve 的规划记录原文直接引用了新条款选中 deliverable.json，
  backward_count=0，评分 83/行业均线 78 收敛，全流程干净跑完。
[x] 11 轮真跑挖出的 6 个独立缺陷里，5 个（模板库缺口 / 验收节点任务描述越权 / 两个规划
  agent 路径口径 / R-19 索引覆盖 / 名字语义匹配误选专属本体）已修复并逐条验证生效，
  第 12 轮起连续跑通。工作已提交（496c249、5879917），与另一并行会话的工作
  （boss agent 看板 / 打字机流式打断，39/40 号文档）无冲突合并。
[ ] 2026-08-31 复盘订正：7.0 的竞态没有修，只是绕开了——上一版把它算进"6 个已修复"
  是错的。org-graph-service.js 的 writeGraph() 本身依然没有乐观锁/版本号，谁后写谁赢
  的问题原样还在；这次只是后续实验不再手写图去撞它，没有从根上堵住。真要修，思路见
  问题 6 讨论：写入前带上「我读到的版本号/hash」，落库时校验没被并发改过，对不上就拒绝
  并让调用方重读重试（类似乐观锁 CAS）。
[x] company.js 的 hire 等路由挂 requireAuth 不认 x-internal-token ——
  已被另一并行会话修复（14cbaf5 fix(graph-run): ceo 心跳自环调用补上
  requireAuthOrInternal，本次合并已带入）。核实过 server/routes/company.js:18 现在是
  router.use(requireAuthOrInternal)，不再是 requireAuth。
[x] boss agent（暂定挂在 CEO 身份下）：主动巡检 goal/task/work 状态 ——
  已被另一并行会话实现，见 39-boss-agent-task-supervision.md
  （P1-P5，commit a00590a/5108d67/d967ac0），本文档这条 TODO 作废，后续跟进请去那份
  文档的「六、已知遗留」一节。
[x] routeFailure 的 infra_flake 分支补上 target_node 路由（30 号文档遗留的"刻意没做②"）——
  已按最保守的方案实现（2026-08-31，graph-engine.js 的 infraFlakeTargetEdge）：
  target_node 只有在图上真有一条从本节点出发的 backward fail 边指向那个节点时才
  生效，命中就改走正常的 backward 边路由（计入 backward_count/双层熔断），不再享受
  "原地重跑、只受 infra_flake_count 约束"的免账本待遇；没命中（含没声明）维持原有的
  原地重跑行为不变。这条修复堵不住 30 号文档记录的那次真实事故——事故里
  org-coder-test 点名的 org-coder-validator 是它的下游，而 org-graph-service.js
  规则 4（backward-labeled）从图结构上就不允许 backward 边指向非祖先节点，那次事故
  本来就不是"图上有边但引擎不认"，是"诊断内容在打一个图结构不允许表达的主意"——
  已经靠 INFRA_FLAKE_HARD_CAP 熔断收敛，属于本条修复范围之外。这条修复堵的是更窄的
  另一种情形：诊断点名的目标恰好是本节点自己真实存在的祖先时，不该绕开正常的回退
  记账。回归测试见 graph-engine.test.js 的 infra_flake describe 块新增两条用例。
[x] 27-p4-parallel-and-artifacts.md 并发 fan-out 设计推进——2026-09-08 已彻底收口。
[ ] 若要落地部门级 org graph（37 号文档方向），仍是"设计讨论，尚未立项"状态。
[ ] 可选文档补丁：org-hunt/digest/evolve 是"元 agent 不能直接入图，要建原生协议独立副本"
  这条红线的第一个实操案例，但这个"怎么复刻 FDE 到 graph"的操作模式本身还没被沉淀成
  一份可复用的参考（目前只在本文档问题 7 的叙事里）。要不要在
  system/org-graph-templates/README.md 的"元 agent 不入图"那条附近补一段指向这个案例，
  供以后有类似需求的人抄作业——未拍板，等决定。