36-prd-agent-methodology-training-feasibility.md 32.2 KB

Edit Raw Blame History


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


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