# 36 · "先训练方法论、再雇佣、再靠 Dream 日拱一卒" 这条链路的可行性调研

> **日期**：2026-08-23
> **触发**：34/35 号文档定位到 `e2e-demo` 产出的落地页"能过验收但很单薄"（三个卖点各只有一句话、没有 CTA、没有图标），根因是 `prd.md` 本身就没要求这些、`goal-benchmark.json` 的验收线 90% 是结构性检查——PRD 这个专业环节的**方法论水平不够**，而不是 coder 执行力不够。
> 用户提出：这类"专业场景水平不够"的问题，应该走 **Innovator（deep research → 训练到收敛）→ 雇佣进 company → Dream（daily 自我迭代）** 这条既有机制，而不是每次都靠人工一条条改 prompt。
> **结论先说**：方向判断是对的，但这条链路现在是**三段互不相连的拼图**，其中一处断点（§三.3）是**全局性的、必须先补的前置项**——不补，训练得再好的 agent 投入 company 使用后一样会静默退化，不会自动变准。下面是逐段实查证据。
>
> **2026-08-23 追加：阶段一（§三.3 断点）已实施。** `runClaimedNode` 结算之后新增
> `recordNodeOutcomeMemory`（`server/services/graph-engine.js`），只在真实派发
> （`isRealDispatch`，与 35 号文档 `missingBody` 同一条判据）且 `systemAgentId` 对应的
> `bodyDir` 真实存在（已雇佣，非测试夹具）时，把这次结算结果（`success` / `fail: <reason>`）
> 追加进该本体自己的 `memory.md`——`memory-service.appendToMemoryMd` 顺手补了一处
> 缺陷（该函数原本不建 `memory/` 目录，只有 `saveSessionSummary` 那条路径先建过；
> 独立调用会在从没写过记忆的本体上直接抛 ENOENT）。新增 4 条测试
> （`server/tests/unit/graph-engine-node-outcome-memory.test.js`），借道 `body_not_ready`
> 短路验证真实结算路径（不起真 CLI），另外单独直调验证 `success` 分支的格式化。
> 1403/1403 通过，`git status` 确认没有污染真实 `system/agents/` 目录。
>
> **2026-08-23 追加：阶段二（独立试验技能）启动，途中撞见并修复一个真实的、有明确日期的回归 bug。**
> 用户选择"独立试验技能"路线：不碰生产 `prd-planning`，新建一个跟任何公司无关的模板
> `system/agents/prd-methodology-trial/`（走 `POST /api/company/templates/:id/train`，
> 就是 org-graph-template 里"🎓 Innovator"按钮同款 API），观察 FDE 能不能训出"PRD 方法论"
> 这类工程角色技能。
>
> 实测第一次调用就 404：`server/routes/company.js` 里两处硬编码调用
> `POST /api/agent/innovator/chat`，但 `system/agents/innovator/` 这个目录根本不存在——
> `git log` 定位到 2026-08-16 那次「四个存量 system agent 按 27-NAMING §3.4 归位」的改名
> 提交把 `innovator` 改成了 `org-innovator`，这两处调用点没跟着改，`.catch` 只打个
> `console.error`，两条路径都没人看得见。也就是说：**从 2026-08-16 起，"🎓 Innovator 训练"
> 按钮和"招聘后自动触发训练"这两条路径都在静默 404，一次都没真的跑过**——这比 36 号文档
> 原先"没人训练"的结论更进一步：不是没人想训练，是想训练的那条代码本身就已经断线一周。
> 已修复两处调用（改成 `org-innovator`），1402/1402 测试通过。
>
> 顺带修了一处随之暴露的旧缺陷：`AgentScaffold` 的默认 `tools.md` 模板写着裸相对路径
> 「所有自主创建的文件仅限在 workspace/ 内操作」，被 `agent-md-refs.test.js` 的守卫测试
> 判定为「写了等于没交付」——这条缺陷本来就有登记（`server/tests/unit/agent-md-refs.test.js`
> 早就按"产品代码缺陷"记录在案，只是此前判定"不在这轮范围内"），这次顺手改了模板
> （`AgentScaffold.js` + `packages/agent-core/base/common/tools-base.md`），改成写运行时坐标
> 给出的绝对路径；`zz-scaffold-readonly-fresh` 是 `scaffold-body-readonly.test.js` 依赖的
> 冻结夹具（28 号裁决：测试建出来的本体不删），永远停在旧模板内容上，改成在守卫测试里
> 单独登记豁免，不再需要为它保留一份"模板还没修"的过期断言。
>
> 训练已重新触发（`prd-methodology-trial`），真实 Hunt→Digest→Evolve 跑在后台，
> 结果待收集，收集完会补一段"FDE 对方法论类角色到底管不管用"的结论。
>
> **2026-08-23 再追加：改完 `company.js` 之后训练依然没有任何动静，排查发现第二个坑——
> 本机跑的 `node server/index.js` 是改代码**之前**就起好的常驻进程，Node 没有热重载，
> 改完文件、没重启进程，线上跑的还是内存里的旧代码（旧 agent id）**。多次 `/train` 调用
> 全部原样命中旧的 404 路径，`{success:true}` 响应具有误导性——它只代表路由处理函数跑到了
> `fetch(...)` 那一行，不代表这次 fetch 真的成功找到了 org-innovator。用一段独立的 Node
> 脚本直接打同一个 `/api/agent/org-innovator/chat` 端点验证了端点本身没问题、`config.port`
> 也没问题、conversationId 格式和长 prompt 都不是问题——排除法一路查到"进程要重启"这一条，
> 才是真正的根因。重启后（`kill` 旧 PID + 重新 `node server/index.js`）立即验证到真实的
> `tpl-train-prd-methodology-trial-*` 会话进入 `running` 状态，训练这次是真的在跑。
> **教训**：以后改完服务端路由代码，验证前先确认进程是不是热的——`git diff` 干净不等于
> 线上生效，尤其是这种"catch 只打日志、响应码永远 200"的 fire-and-forget 路径，表面成功
> 完全可能是假象。
>
> **2026-08-23 再追加：同一个改名 bug 的第三处活体实例 + 一处未查明的遗留别名。**
> 用户在控制台点开 `/agent/innovator/heartbeat-mt57zs52` 想看训练进度，页面空的——排查
> 发现两件事：① `web/src/views/CompanyDashboard.vue:1414`「重新训练」按钮同样硬编码调用
> `/api/agent/innovator/chat`，跟 `company.js` 那两处是同一个 2026-08-16 改名遗留 bug 的
> 第三个活体实例（这次是前端直接命中，跟后端两处并列），已同款修复（改
> `org-innovator`）。② `GET /api/agent/list` 返回的列表里仍然有一条 `id:"innovator"`
> 的展示项，且它的 `lastMessage`/`lastActiveAt` 字段精确反映 `org-innovator` 的最新真实活动
> ——查过 `system_agents` 表确认**没有** `id='innovator'` 的行（表里干干净净只有
> `org-innovator`），说明这条展示项来自另一条独立于图执行主链路的旧列表/别名逻辑，
> 具体源头本轮没有查到底（不是这次训练流程的阻塞项，先记下留给下次碰到agent 列表相关
> 问题时查）。**用户看到"空白"的直接原因**：`heartbeat-mt57zs52` 这个 conversationId
> 实际属于 `qa-judge`（一个心跳会话），跟 `innovator`/`org-innovator` 都无关——正确的观察
> 地址是 agent `org-innovator`、conversationId `tpl-train-prd-methodology-trial-mt58148f`。
>
> **实际训练进度（这条会话里真实验证到的）**：Hunt 阶段已完成且被 org-innovator 自己逐文件
> 复核过（不是走过场）——产出 `knowhow_v1.md`（167 行，4 个外部流派 + 本仓库权威源 +
> e2e-demo 反面案例深度分析）+ `sources.json`（14 条来源，8 内部已核实/6 外部老实标"未核实"）。
> 里面独立复现出的结论，跟本次会话前面人工分析那份"落地页太单薄"的结论高度吻合，且更精确：
> **不是 PRD 全面写虚，是"内容深度/视觉丰富度/CTA 转化"这三类维度从未被验收线索表覆盖到**，
> 结构性/行为性四类东西字面上全部合格照样挡不住单薄产出。Digest 阶段已真实派单给
> `innovator-digest`（`T-mt58cf4s`，实测中状态 `running`），org-innovator 自己的对话轮次
> 到此为止（异步派单不阻塞等待，靠任务回调触发下一轮，跟之前 hunter 创建任务的模式一致），
> 不是训练卡死。继续观察 Digest → Evolve 完成后的结果。
>
>
> **2026-08-23 再追加：查清了"org-innovator 是不是不在列表里"——是同一类 bug 的第五处、
> 也是最根的一处。** `GET /api/agent/list` 展示的 `id` 字段取的是 `config.id || bodyId`
> （`agent-chat.js:1206`），本意是"本体自己声明的名字优先"。查四个本被 2026-08-16
> 那次改名批次（`3f4d1a0`）动过的本体，**目录名和数据库 `system_agents.id` 都改对了，
> 唯独各自 `config.json` 里的内部 `id` 字段一个都没跟着改**：`org-innovator/config.json`
> 仍是 `"id":"innovator"`，`innovator-hunt`/`innovator-digest`/`innovator-evolver` 分别
> 仍是 `"hunter"`/`"digester"`/`"evolver"`。于是 `/list` 接口用目录名正确扫到了这四个本体、
> 也正确读到了它们真实的最新会话数据，却在最后一步把 `id` 字段替换回了改名前的旧值——
> 页面上因此显示成一张挂着死链接的"Innovator"卡片，长得像"活着"（`lastMessage` 是真的），
> 点进去却是 404（前三处已修的 bug 命中的正是这个假 id）。四个 `config.json` 的 `id` 字段
> 已同步改对，`/list` 接口验证过现在正确显示 `org-innovator`/`innovator-hunt`/
> `innovator-digest`/`innovator-evolver`，1406/1406 测试通过。
>
> 顺带发现的那个冗余本体 `system/agents/innovator-hunter/`（训练过程中 org-innovator 自己
> 额外创建、从未真正被用上，实际 Hunt 任务派给了已存在的 `innovator-hunt`）也带着同一类
> id/目录名不一致（`config.id` 是旧的 `"hunter"`）——用户直接追问"死卡片"之后一并修了
> （改成 `"innovator-hunter"`）。它没有 `system_agents` 表登记（纯文件系统本体），
> `org-innovator/todo.md` 里还留着对它的引用，所以只改 id 不删目录：训练还在跑，
> 删掉一个上游 todo 里还点名的本体有风险，等训练完成后再判断这个本体要不要彻底清掉。
> 现在列表里 `innovator-hunt` 和 `innovator-hunter` 会重名显示两张"Hunter"卡片，但两个都是
> 真实可点开的 id，不再是死链接——1406/1406 测试通过。
>
>
> **2026-08-23 再追加：Digest 完成，Evolve 已启动，实测质量超出预期。**
> `benchmark_v1.md` 自检过程完整可信：第一版用纯加权和给 e2e-demo 真实 PRD 打分得 76.4
> （合格档，具有误导性），org-innovator 逐文件核实后确认这是**真实记录在文档里的设计失败**，
> 诊断出"加权平均是稀释、不是封顶"——跟本仓库自己在 `goal-contract.js` 加证据闸门之前
> 撞到的那类"加权和掩盖关键维度失败"是同一类问题，训练出的 agent 独立复现了同款诊断。
> 追加封顶规则后重算 = 50 分（低于 65 及格线，正确判定"待改进"）。`train.jsonl`/`test.jsonl`
> 里还特意构造了 2 条 held-out 探针样本防止评分标准只记住了 e2e-demo 一个案例；
> `industry_avg_score.md` 老实说明方法论类技能没有可抓取的"行业平均分"，拒绝编造数字，
> 改用"真实基线 50 分 + 目标线 80 分"。Evolve 已启动（`T-mt58qpd4`），这次额外定位到了
> `p-bkhylu` 的 PRD（含 `assets/img/`，可能是"确实用了图"的正向对照案例）；`p-v1mpcl`
> 检索不到对应 `prd.md`，已明确要求 Evolver 自己重新确认、如实记录而非凑数编造。
> org-innovator 也主动确认"本次是独立试验，Evolve 完成后不会自动触发 Deploy"——正确遵守
> 了任务书里"不碰真实公司"的边界。继续观察 Evolve 结果（真实 FDE 案例显示 small loop
> 最多迭代 10 轮才收敛，可能还要等一阵）。
>
>
> **2026-08-23 再追加：Evolve 产出 `evolve_report.md`，质量显著超出预期，2 轮即收敛。**
> 关键结论摘录（`system/agents/prd-methodology-trial/train/evolve/evolve_report.md`）：
> - **自我纠正目标分数**：任务书原写"≥95 分"，Evolver 自检发现 `benchmark_v1.md` 的判定
>   等级顶格就是"≥80=优秀"、没有"超优秀"刻度，95 分与自身刻度不兼容；且 Digest 阶段的
>   `industry_avg_score.md` 已经明确论证过"不能拿构造样本均值 95.5 当目标线"——Evolver
>   没有绕开这条已有结论重新加戏，而是引用它、把目标改成 ≥80，逻辑贯穿三个阶段。
> - **2 轮提前收敛**：第 1 轮（重写 e2e-demo 反面案例）96 分，第 2 轮（全新虚构门店详情页
>   场景）97 分，真实基线 50 分。判断"96→97 涨幅仅 +1"不是改进乏力而是"两个不同场景都稳
>   定落在优秀档高位"——具备泛化能力，不是记住了 e2e-demo 这一个案例，据此提前停止，
>   没有为了凑够 10 轮硬跑。
> - **拒绝伪自动化**：任务书允许"scorer.js 或评分记录"二选一，Evolver 主动选了后者，
>   理由是三个核心维度（验收线索可度量性/内容深度/业务度量翻译）本质是语义判断，正则
>   scorer 会"漏判 + 误判"制造虚假确定性——这是本仓库自己在 34/35 号文档里吃过的同一类
>   亏（`unit-tester` 曾经"用正则解析文本假装测过"），训练出的 agent 独立识别出了同一个坑。
> - **三个真实项目反推**（`real_project_reflection.md`）：`p-pyjha7`（反面案例，D5=3/D6=1/
>   总分50）具体指出"大图"量化成"每区块≥1图标+尺寸阈值"、BRD 转化度量翻译成 CTA 功能这
>   两处改写，是分数从 50 跳到 96 的直接原因；`p-bkhylu`（正面对照，89.4 分）的洞察更细
>   ——它的高分不是"承诺丰富、验收线索兜住"，而是"正文从未承诺兑现不了的东西"，反向补强了
>   `SKILL.md` 的"删词改写"路径；`p-v1mpcl` 定位不到完整 PRD，如实归因为管线层的
>   `impl_bug`（规划节点自报成功但产物未落盘），没有为凑够三个案例编造分析。
>
> 训练还差最后一步：等 org-innovator 收到 Evolve 回调、验收后给出任务书要求的"FDE 对方法论
> 类角色管不管用"的诚实评估（这段本身还没写出来，是这次试验真正想要的结论），完了才算真正
> 收尾——继续观察中。
>
> **2026-08-23 再追加：Evolve 完成，Deploy 已执行，"FDE 对方法论类角色到底管不管用"结论如下。**
> 2 轮 Small Loop 提前收敛（迭代1重写 e2e-demo 真实反面案例 `p-pyjha7` = 96 分，迭代2全新
> 虚构场景 = 97 分，delta=+1<2 触发提前停止），均远超 Digest 阶段定的目标线（≥80，优秀档）。
> org-innovator 逐文件核验 + 独立抽查关键事实（`p-pyjha7`/`p-bkhylu` 的 `<img>` 标签数、
> `p-v1mpcl` 的 `timeline.ndjson impl_bug` 记录），三处均与汇报一致，非走过场验收。
>
> **管用的部分**：Hunt/Digest/Evolve 三阶段全程都产出了真实的方法论洞察，不是自娱自乐凑数据——
> Hunt 独立复现出"不是 PRD 全面写虚，是三类维度从未被验收线索覆盖"这个比人工分析更精确的
> 结论；Digest 自检打分暴露了自己"加权平均掩盖关键维度失败"的设计缺陷并当场修正（追加封顶
> 规则）；Evolve 用三个真实历史项目反推出具体可执行的方法论步骤（Step 4 描述性语言扫描 +
> Step 5 业务度量翻译），且用第二个正面案例（`p-bkhylu`）验证了"删词改写"路径在真实场景
> 确实可行，不只是理论兜底。这条链路在"方法论调研"这类偏软的工程角色上是真的管用的，
> 不比"抓数据类 skill"逊色。
>
> **需要人工介入才管用的部分**：①目标分数刻度——任务书原定"≥95分"与 Digest 阶段自己设计的
> `benchmark_v1.md` 判定等级（顶格"≥80=优秀"）不兼容，Evolve 阶段自己发现了这个矛盾、
> 给出更合理的目标（≥80）并如实说明理由，**但这个自纠正是靠 agent 被要求"发现不合理要如实
> 说明"这条硬约束才触发的，不是流水线自动检测出刻度不兼容**；换一个不做这层自检要求的
> 训练任务书，agent 大概率会硬凑95分或在评分上做手脚。②验收方式——D3/D5/D6 三个维度全部
> 是语义判断，Evolve 阶段主动放弃了自动化 `scorer.js`、改用人工逐维度对照记录，这个判断本身
> 是对的（避免虚假确定性），但意味着"方法论类技能"的收敛判据目前无法脱离人工审阅，跟"抓
> 数据类 skill"能用代码跑分是两种验收成本。③本次验证的样本仍然只有 1 个真实反面案例
> （`p-pyjha7`）+ 1 个正面对照（`p-bkhylu`）+ 1 个虚构场景，`SKILL.md` 自己在 evolve_report
> 里如实标注了"叙述性长文案"场景只验证过一次、样本量偏薄——2 轮收敛快不代表已经在足够
> 多样的真实场景下验证过，是"在已验证范围内高分"，不是"全场景高分"的证明。
>
> **本次 Deploy 范围**：只对 `prd-methodology-trial`（独立试验节点，`parent_id: null`，不接入
> 任何真实公司/图）执行了 Deploy（`SKILL.md` 复制到本体根目录 + `config.json`
> `status: enabled`/`benchmark_score: 96.5`），**没有触碰生产 `prd-planning`**——把训练出的
> 方法论真正接到 `prd-planning` 头上，仍然卡在 §四表格第 3 行"训练产物 → 雇佣本体的转换逻辑"
> 这个尚未开工的缺口上，`SKILL.md` 目前只是一份独立文档，还没有被装配进任何真实干活的节点。
>
> **对 §五推进顺序的更新**：第 2 步（验证 Innovator 在方法论调研场景是否管用）现在可以标记
> 完成，结论是"管用，但收敛速度和验收严谨度都依赖任务书里显式写明的自纠正/防伪要求，不是
> 免人工的黑盒"。第 3 步（转换装配逻辑）仍是下一步真正的门槛，建议低风险场景仍按原计划走
> （新建 `prd-writer` 之类的专职节点，而不是直接动 `prd-planning`），且要先把 §三.3 的图执行
> 反馈通路用起来一段时间、看 Dream 提炼出来的经验靠不靠谱，再决定要不要把这次训出的
> `SKILL.md` 装进一个真正雇进公司图干活的本体。
>
> **环节 3（Innovator 训练产物转换成可雇佣本体）尚未开工。**

---

## 一、用户判断本身：认同

现状（本仓库这几周反复出现的模式）：界面不好→改 prompt，流程不对→改 prompt，功能漏了→改 prompt。每次都是**人发现问题、人诊断、人手写修复**，本质是把"专业能力"当成一次性补丁在打，而不是当成一个可持续改进的对象在经营。

用户提的"先深度调研方法论 → 训练到收敛 → 雇佣 → 用真实反馈持续迭代"，是把"专业能力"当成一等公民对待——这正是 Innovator（训练收敛）+ Dream（持续反馈）两个子系统当初设计的目标人群。问题是**这两个子系统当初设计时服务的是 ArenaSK 的 Skill 市场场景（爬虫/资讯类 bot），不是"公司雇佣的专业协作 agent"场景**，中间有真实的改造工作量，不是"打开开关"。

---

## 二、Innovator：deep research → 收敛训练，机制是真的，证据如下

### 2.1 三个本体，各司其职，且都不是空壳

`system/agents/innovator-{hunt,digest,evolver}/agent.md`：

- **Hunter**（`system/agents/innovator-hunt/agent.md`）：真做"深度调研"——工具是 `l1-web-fetch`（抓网页）+ `l1-shell-exec`（跑爬虫脚本）+ `l1-data-extract`；硬规矩包含遵守 robots.txt、单站点请求间隔 ≥2 秒、每条数据必须带 `source_url`+`crawl_time`；验收线要求 `knowhow_raw.md` ≥5 个数据源、`seed_data.json` ≥50 条有效数据。这不是"LLM 凭记忆编一段方法论"，是有工具、有验收线的真实调研。
- **Digester**（`system/agents/innovator-digest/agent.md`）：把 Hunter 的原始数据"去重/分类/提炼"成 `knowhow.md`（知识手册）+ `benchmark.md`（3-5 个评分维度，每维度 1-10 分明确标准）+ `train.json`/`test.json`（标注数据集，≥50 条，80/20 切分）+ `industry_avg.json`（行业基准分）。硬约束里明写"不要设计主观性太强无法量化的评分维度"。
- **Evolver**（`system/agents/innovator-evolver/agent.md`）：真正的收敛循环——**Small Loop**（执行→评分→析弱项→改 `SKILL.md`→重复，最多 10 轮，连续 2 轮分数涨幅 <2 分立即报瓶颈停止）+ **Large Loop**（人类反馈触发→回 Hunter 重新调研→更新 benchmark→重启 Small Loop）。还有一段专门的"Token 预算规则"防止长会话把上下文吃爆（首次读取后不重复读大文件、每轮只输出总分+弱维度、单 session 最多 5 轮迭代）——说明这套东西**真跑过、被上下文爆炸坑过、专门写了规矩**，不是纸面设计。

### 2.2 三者串联的实际编排

`server/services/retrain-pipeline.js`（541 行）：`RetrainPipeline` 类按 `re_hunt → re_digest → evolve` 三步顺序调用对应 agent（`manager.callAgent('innovator-hunt', ...)` 等），每步写 checkpoint（`checkpoint.json`）支持断点恢复，`_publish()` 阶段从 evolve 输出里正则抓"最终分数"、bump 版本号、写 changelog。`server/src/tools/train-skill-tool.js`（345 行）是 Master Agent 可调用的入口（`train_skill` 工具），新建走 `EvolutionLoop`（`server/services/evolution-loop.js`，RL 式 Perceive→Plan→Execute→Evaluate→Reflect，`maxIterations:5, goalScore:90`），重训走 `RetrainPipeline`。两条路都是异步 Job（`JobManager`），返回 `jobId`，前端/调用方轮询进度——训练一次官方口径是"5-10 分钟"。

**结论：这套训练闭环是真实存在、有工具支撑、有量化收敛判据的机制，不是半成品文档。**

### 2.3 但训练产物的落点，跟"公司雇佣的专业 agent"完全不是一回事

训练产物落在两处（视 `create`/`retrain` 而定）：
- `data/trained_skills/user_{id}/{skillName}/`（按用户隔离的新建 skill）
- `<repo>/../data/skills/{skillName}/`（已注册 skill 的重训）

目录形状是 `{skillName}/SKILL.md` + `{skillName}/hunter/knowhow.md` + `{skillName}/digest/benchmark.md` + `{skillName}/evolve/`——这是 **ArenaSK Skill 市场包**的形状，面向"下载即用的独立技能"。

而公司雇佣的专业 agent（比如 `org-planner-prd` 或这次手填的 `unit-tester`）用的是完全不同的三件套：`system/agents/{id}/agent.md` + `soul.md` + `.claude/skills/main_skill/SKILL.md`，挂在 `system/agents/` 下，靠 `missingBodyDefinition()`（`server/services/agent-locator.js`）判断"能不能被雇"，靠 P1 虚拟引用（`config.json.systemAgentRef`）被多家公司共享。

**这两套 schema 之间，没有任何代码把一个训练产物转换/装配成一个可雇佣的本体。** 想让"训练出来的 PRD 方法论"真正被 `org-planner-prd` 使用，中间缺一段转换逻辑——这是新工作量，不是配置项。

> **补充实锤**（另一路复查得到，与上面互相印证）：`system/agents/community-manager/` 这个真跑过 FDE 收敛的本体，实际目录形状是**老式独立机器人 agent**（`identity.md`/`cron.json`/`heartbeat.md`/`plan.md`/`todo.md`/`user.md` 都在），`SKILL.md` 落在**本体根目录**（`system/agents/community-manager/SKILL.md`，与 `train/evolve/SKILL_final.md` 内容逐字一致），**没有** `.claude/skills/main_skill/SKILL.md`。而 `prd-planning`/`coder`/`unit-tester` 这类"雇进 org/work graph 干活的节点"用的是另一种形状（无 `cron.json`/`heartbeat.md`/`plan.md`/`todo.md`，`SKILL.md` 落在 `.claude/skills/main_skill/` 下）。两种形状目前**共存于同一个 `system/agents/` 目录**，`missingBodyDefinition()` 因为把 `main_skill/SKILL.md` 判成可选检查项，两种形状都能通过毕业闸门——**闸门通过不代表"这是一个训练收敛过的本体"，只代表"文件非空"**。这也是为什么这次手写的 `unit-tester/soul.md` 和真训练过的 `community-manager/SKILL.md` 在闸门眼里没有区别（呼应 §四表格第 3/4 行）。

---

## 三、Dream：daily 自我迭代，机制是真的，但原料管道有一处致命断点

### 3.1 Dream 现有机制（`docs/todo/system-design/29-dream-design.md`，✅ 已实现）

- **粒度**：按本体扫描（`system/agents/{aid}/*/memory/`），跨公司归纳（一个本体在所有雇了它的公司里的经验汇流成一份）。
- **原料**：每个本体自己 `memory.md` 的"原始记录（未提炼）"段——由 `saveSessionSummary`/`appendToMemoryMd`（`server/services/memory-service.js:107`）写入。
- **流程**：`dream-distiller`（提炼，看不到公司身份）→ `dream-screener`（独立二次判定"能不能给别家公司看"，同样看不到原料/公司）→ 写入 `{aid}/memory/experience.md` +（可选）`agent.md`/`soul.md`/`SKILL.md` 的受管区块（`<!-- dream:begin/end -->`）。
- **闸门**：写定义文件前过三道——`definition-write-gate`（已在 git 历史里且无未提交改动）→ `agent.md` 前 2000 字符自足性（`graph-engine.js:915` 只读这一段给规划 agent）→ 写完复核 `missingBodyDefinition` 不过就立刻还原。
- **触发**：`dream-service.startDaily()`，每日一次，串行扫全部本体，空转保护（没新原料就不起 LLM 调用）。手动触发有 `/api/dream/*` + 控制台页。
- **真跑过一次**：对 `innovator-evolver`（40 条原料）跑出 4 条抽象经验，`sources` 全部可回查原文，去敏闸门单独验证过（含"域名+绝对路径"→拒绝、"心跳日志原文"→拒绝、"干净抽象经验"→放行三个真实案例）。

这套机制本身设计得相当严谨（独立判定 + 可追溯 + 受管区块 + 三道闸门），是本仓库为数不多"设计时就把失效方向想清楚"的子系统。

### 3.2 但 Dream 的原料现在几乎是空的（29 号文档 §1.4 实查）

75 份 `memory.md` 里只有 7 份有非模板内容（`innovator-evolver`/`master`/`org-innovator`/`innovator-digest`/`innovator-hunt`/`coo`/`qa-judge`）。这 7 份全部集中在**Innovator 自己的训练闭环**和**几个中枢 agent**——**没有一个是 org/work graph 里真正干活的专业节点**（`org-planner-prd`、`org-coder`、`benchmark-validator` 全都是模板空壳）。

### 3.3 关键断点：`appendToMemoryMd` 只在人类对话路径上被调用，graph-engine 从未调用过它

实查（`grep -rln "memory-service" server/routes server/src server/services`）：调用 `saveSessionSummary`/`appendToMemoryMd` 的生产代码路径只有 **`server/routes/agent-chat.js`**（人类跟 agent 多轮对话那条路）。`server/services/graph-engine.js`（org graph / work graph 节点执行——也就是这次 e2e 测试里 `org-planner-prd`、`benchmark-validator`、`org-coder` 实际运行的地方）**完全没有调用它**。

也就是说：

> **PRD agent 通过 work graph 写 `prd.md` 的每一次真实运行——无论写得多单薄、无论后面被 `benchmark-validator` 打多低的分、无论 `triager` 因为哪条 acceptance 把它驳回——这些信号今天一个字都不会进入 `org-planner-prd` 自己的 `memory.md`。**

Dream 的"空转保护"因此不是"这几天恰好没跑任务"，而是**结构性地永远看不到图执行产生的任何反馈**。这跟这次 e2e 测试跑了多少次、`goal-benchmark.json` 打了多少次 100 分或 0 分完全无关——benchmark verdict（`data/companies/{cid}/runs/{runId}/artifacts/verdicts/*.json`，35 号提案 B/C/D 刚做的证据闸门）和 Dream 的原料面（`memory.md`）是两套互不相通的存储。

**这是本方案能不能生效的头号阻塞项，排在"要不要先训练"之前**——因为哪怕现在立刻手工写出一个完美的 PRD 方法论、装配成本体、雇进公司，它投入使用之后依然收不到任何反馈，跟现在的 `org-planner-prd` 处境一模一样，一样会在下一次任务里因为"没人告诉它上次哪里不够"而重复同样的问题。

---

## 四、要闭环用户设想的机制，缺口清单（按依赖顺序）

| # | 缺口 | 现状 | 需要新增的工作 |
|---|---|---|---|
| 1 | **图执行反馈 → memory.md** | ✅ **已实施（2026-08-23）**。`runClaimedNode` 结算后调 `recordNodeOutcomeMemory`，写入 `success`/`fail: <reason>` 一行摘要；暂未包含 verdict 逐维度 evidence 缺失项细节（v1 只搬运 `status`+`failReason`，更细的摘要留待验证阶段二有没有用之后再加，避免过度设计） | ~~在 `settleNode`/`routeFailure`（或等效收尾点）挂一次 `appendToMemoryMd` 调用~~ 已完成 |
| 2 | **Innovator 训练目标域迁移** | Hunt/Digest/Evolve 的验收线（"≥5 数据源""≥50 条数据"）是照着"抓数据类 skill"设计的 | 用它训练"PRD 方法论"这种偏软技能/方法论的领域时，"数据源"应该指什么（业界 PRD 最佳实践文章？知名产品的公开 PRD 案例？）、"50 条数据"对应什么颗粒度，需要先小范围验证这套指标套在方法论调研场景下还有没有意义，而不是假设直接适用 |
| 3 | **训练产物 → 雇佣本体 的转换** | Innovator 产出落在 `{skillName}/SKILL.md` + `hunter/digest/evolve` 子目录（Skill 市场包形状）；雇佣本体要的是 `system/agents/{id}/{agent.md,soul.md,main_skill/SKILL.md}` | 需要新写一段装配逻辑：把训练出的方法论/prompt 拆成 `agent.md`（行为契约）+ `soul.md`（人格/取舍原则）+ `main_skill/SKILL.md`（操作手册），并过 `missingBodyDefinition` 检查才能真正被雇进公司图 |
| 4 | **雇佣本身** | 现有 P1 虚拟引用寻址、`missingBodyDefinition` 毕业闸门都是现成的，只要环节 3 产出的三件套完整，直接复用即可 | 不需要新增 |
| 5 | **Dream 覆盖到专业方法论沉淀** | 受管区块 + 三道闸门机制现成，能写 `agent.md`/`soul.md` | 不需要新增机制本身，但"结论对不对"依然没有自动判据（决策 D 遗留问题），扩展到多个专业 agent 后人工抽查成本会线性增长，需要提前设计抽查节奏 |

---

## 五、建议的推进顺序

1. **先补环节 1（图执行反馈进 memory.md）**——成本最低（一处新代码 + 挂点），且是后面所有投入的前提。做完之后，**不用等训练新 agent**，现有 `org-planner-prd` 就已经开始真实积累"哪次被打回、为什么"这类原料，Dream 定时任务马上就有东西可提炼——相当于免费验证一遍"Dream 打通图执行反馈之后到底有没有用"，风险最小。
2. **用一次真实小规模训练，验证 Innovator 在"方法论调研"场景下是否真的管用**（环节 2）——不要直接假设 Hunt/Digest 套路能照搬,先跑一次看 Hunter 找到的"数据源"和 Digester 设计的评分维度是不是真的对 PRD 质量有区分度,而不是自娱自乐编出一套看起来合理但没验证过的 benchmark。
3. **验证有效后再投入环节 3（转换装配逻辑）**——先在一个低风险场景（比如新建一个专职 `prd-writer` 本体,而不是直接动 `org-planner-prd` 这个已在多处引用的本体)试一遍全流程：训练 → 转换 → 雇佣 → 真实任务 → 图反馈进 memory → Dream 提炼 → 回写 agent.md → 下一次任务验证有没有变好。
4. **全程留好人工抽查节奏**——按 29 号文档决策 D 的既有认知，"经验提炼得对不对"没有自动判据；`agent.md`/`soul.md` 是"本体只有一份、影响所有雇了它的公司"的高风险改动点（28 号裁决），规模化之前要想清楚人多久抽查一次、抽查什么（建议只抽查 `agent.md` 实际发生变更的那次 diff,而不是逐条通读 `experience.md`)。

---

## 六、一句话总结

用户的方向判断是对的：专业能力应该被当成"可持续训练 + 持续反馈迭代"的一等公民,而不是每次靠人工打补丁。但现状 Innovator（训练收敛）和 Dream（持续反馈）两条线本身是成熟的、机制是真的,真正卡住这个设想的是**它们和"公司实际派工干活"这条线（org/work graph）之间完全没有打通**——尤其是 §三.3 那个断点：图执行的反馈今天根本不会进入任何 agent 的记忆。这个断点不补,不管训练得多好、雇佣了多少次,专业 agent 投入实战后依然是"聋子"，问题会继续在下一次任务里重演。