# 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` 里字面意义上写死了：

```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. 多节点子图的并发 fan-out：这块是真的还没做，不是做坏了**
`27-p4-parallel-and-artifacts.md` 状态是"📝 设计中，未实现"——同一 agent 多实例隔离、真并发 fan-out、`files.json` 产物索引都还没上生产。所以"带分支的多节点子图"目前跑的都还是**顺序执行**，没有真正测过高并发下的资源竞争会不会暴露新问题——这不是"设计有问题被发现了 bug"，是"这段设计还没写完"。

**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'"——结论是**不行**，两个理由都是硬的：
1. **治理红线**：org graph 被设计成"公司角色结构"，理应慢变、可审计（类比真实公司的组织架构图，不会因为接了个新项目就重画一遍）；work graph 才是快变、按任务现场规划的。把 org graph 也现场 plan 出来，等于把慢变的角色结构拉进快变的任务节奏，这条边界就没了。
2. **技术硬限制**：引擎的 `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 分钟 |

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

1. **建公司自动规划与手写图的竞态**（7.0）——`writeGraph()` 无版本号/乐观锁，谁后写谁赢。
2. **`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` 的模板表。
3. **验收节点任务描述范围溢出**——`workgraph-planning` 给 review/validator 节点写任务描述时，
   把"审查上一节点产出"和"接着干完下游职责"混在一起。**已修**：在
   `workgraph-planning/agent.md` Step 4"你不被允许"里加了一条硬规则，点名这次真实事故。
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`（来自首轮消息"写入边界"段给的绝对路径）显式拼接，不再用裸相对
   路径或猜深度的 `../../../../`。
5. **（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 个独立缺陷（7.0 竞态 / 模板库缺口 / 验收节点任务描述越权 /
      两个规划 agent 路径口径 / R-19 索引覆盖 / 名字语义匹配误选专属本体）全部修复并逐条
      验证生效，第 12 轮起连续跑通。工作已提交（`496c249`），与另一并行会话的工作
      （boss agent 看板 / 打字机流式打断，39/40 号文档）无冲突合并。
- [ ] `routeFailure` 的 `infra_flake` 分支补上 `target_node` 路由（30 号文档遗留的"刻意没做②"）。
- [ ] `27-p4-parallel-and-artifacts.md` 并发 fan-out 设计推进。
- [ ] boss agent（暂定挂在 CEO 身份下）：主动巡检 goal/task/work 状态、卡住/漏结算主动喊人，功能待从零设计。
- [ ] 若要落地部门级 org graph（37 号文档方向），仍是"设计讨论，尚未立项"状态。
- [ ] `company.js` 的 `hire` 等路由挂 `requireAuth` 不认 `x-internal-token`，导致 agent CLI 子进程
      调 `company hire`/`company templates`/`GET /company/:id/agents` 必 401——被 `orggraph-planning`
      和 `workgraph-planning` 各自独立撞见过一次（7.2 附带发现），跟 38 号文档修 `agent-chat.js`
      是同一类问题，`company.js` 还没补。