宜博 / lemonboss

Commit 364cc3dcd02f2e9dfe58c26405e5ac8a0e21857c

Authored by yibo
1 parent f41de172

docs(34): 自我订正——不是没有浏览器工具，是没人教 agent 用 bash 走到 Playwright 

§5.1 原来断言"没有浏览器工具，物理上做不到"，复盘时对照 p-bkhylu 的 org-coder
（同样只有 bash/read_file/str_replace(+write_file)，没有专门的浏览器工具）却
真跑出了 Playwright + headless Chromium 测试，才发现这个判断错了：仓库自带
playwright 依赖，bash 里 `node verify.mjs` 沿目录树能 require 到仓库根的
node_modules，这条路今天的 coder/unit-tester 同样走得通。

真正的差异不是工具权限，是 unit-tester 的 agent.md 从未填充过（32 号文档那类
问题）、没有任何角色指导，而 org-coder/coder-validator 都是正常填充过的成熟
本体。根因从"平台缺工具"改判为"这次没有指导 agent 主动想到"，是一个不一样、
也更能采取行动的结论。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Inline Side-by-side
Showing 2 changed files with 36 additions and 14 deletions
docs/README.md
  View file @364cc3d
... ... @@ -49,7 +49,7 @@ Graph Agent 架构重构（27 系列）。**已完成的阶段文档已移入 `d
49 49 | [29-dream-design.md](./todo/system-design/29-dream-design.md) | **dream（经验汇流）**— ✅ 已实现。定时整理所有 agent 在所有公司的记忆，提炼后跨公司沉淀（不泄漏公司信息）。四条取舍已拍板并实现：去敏独立判定、四落点分层写入（经验/`SKILL.md`/`soul.md`/`agent.md`，受管区块+三道闸门）、每日定时（串行+空转保护）、引用真伪自动查、REST+控制台入口（`/api/dream/*`、`/dream`）。`innovator-evolver` 真 CLI 跑通一次。**仍缺的**：「结论对不对」只能人抽查；「套进 org/work graph 来跑」评估后用户选了不做（作用域不匹配，见文内 §5.7） |
50 50 | [30-task-delegation-reliability-gaps.md](./todo/system-design/30-task-delegation-reliability-gaps.md) | **任务委派可靠性现状**— 📝 调研记录，非设计方案。DevLoop `runUnit`、Company 招聘装配、Graph 执行三条链路核对结论一致：都是「失败预算耗尽 → 停等人工」，没有「卡住了主动通知人」这一层；DevLoop 当前还默认走 mock，真实 CLI 成功率无实证数据 |
51 51 | [31-work-graph-fail-fallback-coverage.md](./todo/system-design/31-work-graph-fail-fallback-coverage.md) | work graph 兜底边覆盖不全 — ✅ 已完成（除入口节点外强制兜底边，`planner.json`/`executor-fanout.json` 补 6 条边），978/978 单测通过；2026-08-21 又用真实 LLM 起了一条新任务做端到端回归验证，`org-planner-sdd` 自判失败后自动打回 `org-planner-prd`（3 次，零人工介入），修复确认生效 |
52   -| [34-validator-scored-without-real-deliverable.md](./todo/system-design/34-validator-scored-without-real-deliverable.md) | 📝 **调研记录，checklist 已查完**。最初以为 `org-coder-impl` 从未产出任何 HTML/CSS，后来发现真实网站其实存在于 `graph_files` 索引不覆盖的「项目根」目录（已顺手修：控制台「产物」面板现在会展示项目根）。追加查清 validator 有没有真的做浏览器级检查——没有工具、物理上做不到，但有真实静态断言脚本代替了 5/6 维度；抽查另外两个项目根后发现**验证严谨度完全不稳定**（同类任务有的做了真实 Playwright 级验证、有的只做静态正则、有的没验证就被取消），"已完成"背后的验收质量目前全靠单次任务规划时 agent 即兴发挥，没有系统保证。顺带在新招聘的 `unit-tester` 本体上又撞见一次 [32 号文档](./todo/system-design/32-hire-body-fill-reliability.md) 那类装配未完成的真实样本 |
  52 +| [34-validator-scored-without-real-deliverable.md](./todo/system-design/34-validator-scored-without-real-deliverable.md) | 📝 **调研记录，checklist 已查完**。最初以为 `org-coder-impl` 从未产出任何 HTML/CSS，后来发现真实网站其实存在于 `graph_files` 索引不覆盖的「项目根」目录（已顺手修：控制台「产物」面板现在会展示项目根）。追加查清 validator 有没有真的做浏览器级检查——中途自我订正一次：不是"没工具做不到"（`bash` 能走到仓库自带的 Playwright，另一条对照任务证明可行），是**没人教它这么做**；抽查另外两个项目根后发现**验证严谨度完全不稳定**（同类任务有的做了真实 Playwright 级验证、有的只做静态正则、有的没验证就被取消），根因很可能是新招聘的 `unit-tester` 本体撞上了 [32 号文档](./todo/system-design/32-hire-body-fill-reliability.md) 那类"装配没填充完"的真实样本，不是平台工具限制 |
53 53 | [33-needs-gate-role-filter-bug.md](./todo/system-design/33-needs-gate-role-filter-bug.md) | ✅ **已修复**。`executor.json`/`executor-fanout.json` 里 `produces:["log"]` 声明了一个 test/integration 类节点永远不会被索引到的 kind，导致 `org-coder-validator` 被 `missing_required_input` 反复误判 blocked；改成 `required:false`（对齐 `validator.json` 既有写法）。文档记录了一条**走过的弯路**（按 role 过滤 `inboundContracts` 会削弱 T-mt25ecbd 的产出闸门，已撤回），发现于 31 号文档的真实回归验证过程中，与兜底边问题无关 |
54 54  
55 55 ## todo/future/（暂缓，非当前重心）
... ...
docs/todo/system-design/34-validator-scored-without-real-deliverable.md
  View file @364cc3d
... ... @@ -3,14 +3,18 @@
3 3 > **日期**: 2026-08-22
4 4 > **状态**: 📝 **调研记录，非设计方案，§四 checklist 已全部查完**。§一/§二的核心
5 5 > 前提已被 §零 推翻大半——原始判断（"index.html 从未被写出来"）是错的，真实网站
6   -> 文件其实存在，只是不在 `graph_files` 索引里。§五追加查完三件事：① validator
7   -> 没有浏览器工具，物理上做不到 rubric 要求的检查；② 但确实有一份真实静态断言
8   -> 脚本代替了 5/6 维度的检查，不是空手套白狼；③ 抽查另外两个已存在的项目根后
9   -> 发现**这种验证方式完全不稳定**——同类任务里有的做了真实 Playwright 级验证、
10   -> 有的只做了静态正则、有的没验证就被取消，"任务已完成"背后的验收严谨程度全靠
11   -> 单次任务规划时 agent 会话即兴发挥，没有系统性保证。顺带在 `unit-tester` 本体
12   -> 身上撞见一次 [32 号文档](./32-hire-body-fill-reliability.md) 那类"招聘装配没
13   -> 填充完"的真实样本。是否需要引擎级前置闸门统一验证严谨度，留给下次设计。
  6 +> 文件其实存在，只是不在 `graph_files` 索引里。§五追加查完三件事，且 §5.1 中途
  7 +> 自我订正过一次：① 最初以为"validator 没有浏览器工具、物理上做不到检查"——
  8 +> **这个判断错了**，`bash` 能走到真实 Playwright（仓库自带该依赖），另一条对照
  9 +> 任务证明了这条路能走通；真正的差异是**有没有 agent 主动想到要这么做**，
  10 +> 这次没有；② 确实有一份真实静态断言脚本代替了 5/6 维度的检查，不是空手套白狼；
  11 +> ③ 抽查另外两个已存在的项目根后发现**验证严谨度完全不稳定**——同类任务里有的
  12 +> 做了真实 Playwright 级验证、有的只做了静态正则、有的没验证就被取消，"任务已
  13 +> 完成"背后的验收严谨程度全靠单次任务规划时 agent 会话即兴发挥与提示词是否填充
  14 +> 完整，没有系统性保证。顺带在 `unit-tester` 本体身上撞见一次
  15 +> [32 号文档](./32-hire-body-fill-reliability.md) 那类"招聘装配没填充完"的真实
  16 +> 样本——这很可能才是这次检查偏弱的**直接原因**，而不是工具限制。是否需要引擎级
  17 +> 前置闸门统一验证严谨度，留给下次设计。
14 18 > **触发**: `e2e-demo` 公司真实回归任务 `T-mt2r6fz0-125b`（goal `G-mt2r62ia-73af`，
15 19 > root run `run_0e9074815130`）——[31 号文档](./31-work-graph-fail-fallback-coverage.md)
16 20 > 兜底边修复 + [33 号文档](./33-needs-gate-role-filter-bug.md) 契约修复之后，把这条任务
... ... @@ -144,7 +148,7 @@ contract.json 跨节点契约快照
144 148  
145 149 ## 五、2026-08-22 追加调查：`coder-validator` 到底有没有真的检查
146 150  
147   -### 5.1 工具权限：没有浏览器，物理上做不到
  151 +### 5.1 工具权限：**这条判断错了，见 §5.3 订正**——没有"浏览器工具"，但 `bash` 能到达真浏览器
148 152  
149 153 `org-coder-validator` 这次跑的本体是 `coder-validator`（预置的 active 本体，非本次
150 154 新招聘）。它的 `agent.md`（10KB，读了全文）通篇讲的是**代码/契约正确性验证**——
... ... @@ -164,10 +168,15 @@ contract.json 跨节点契约快照
164 168 "cli": { "toolPolicy": { "mode": "restricted", "allowedTools": ["bash", "read_file", "str_replace"] } }
165 169 ```
166 170  
167   -**没有浏览器/截图/DOM 检查工具**。`goal-benchmark.json` 的 `evidence_hint` 要求
168   -"打开 `index.html`"、"开发者工具 Console + Network 面板"、"依次设置视口宽度"——
169   -在这三个工具的权限范围内，一件都做不到。这不是 agent 偷懒，是**设计上给它的
170   -rubric 与给它的工具完全对不上**。
  171 +**没有专门的"浏览器/截图/DOM 检查"工具**。`goal-benchmark.json` 的 `evidence_hint`
  172 +要求"打开 `index.html`"、"开发者工具 Console + Network 面板"、"依次设置视口宽度"——
  173 +乍看在这三个工具的权限范围内一件都做不到。**但这个判断本身是错的**，见 §5.3：
  174 +`bash` 本身没有限制"能不能启动子进程"，仓库自带 `playwright`（`package.json` 里
  175 +`"playwright": "^1.58.1"`，`node_modules/playwright` 真实存在），任何持有 `bash`
  176 +的 agent 理论上都能写一个 `node verify.mjs`（`require('playwright')` 沿目录树向上
  177 +能找到仓库根的 `node_modules`）去跑真实 headless Chromium——**这次任务的 agent
  178 +没有这么做，不是因为工具权限拦住了它，是因为它不知道该这么做**（见 §5.3 的
  179 +`unit-tester` 提示词空白问题）。
171 180  
172 181 ### 5.2 但也不是纯粹的空手套：真有一份可运行的静态断言脚本
173 182  
... ... @@ -233,6 +242,19 @@ Node 脚本，读 `index.html`/`styles.css`/`script.js` 三个真实文件做静
233 242 换句话说：**要不要认真验证、认不认可自证脚本，取决于那次任务恰好由哪个 sdd-planning
234 243 会话规划、恰好写没写这条规矩，不是系统保证的**。
235 244  
  245 +**关键订正**：`p-bkhylu` 那条任务的 `org-coder-impl` 用的是本体 `org-coder`
  246 +（`system/agents/org-coder/config.json`），工具权限是
  247 +`{bash, read_file, str_replace, write_file}`——跟今天新招的 `coder`/`unit-tester`
  248 +**几乎一样**（多一个 `write_file`），**同样没有专门的"浏览器工具"**。它能跑出真实
  249 +Playwright 测试，靠的是 `bash` 里 `node verify.mjs`，`require('playwright')`
  250 +沿目录树向上找到仓库根的 `node_modules/playwright`——这条路今天的 `coder`/
  251 +`unit-tester` 同样走得通，只是没人这么做。**所以 §5.1 说"没有浏览器工具、物理上
  252 +做不到"是错的，纠正为**：两条任务的 agent 拿到的工具权限本质相同，差的是
  253 +**有没有人（提示词/前序 agent）教它"该用 Playwright 写一份真实测试"这件事**——
  254 +`org-coder`/`coder-validator` 的 `agent.md` 都是正常填充过的成熟本体，`unit-tester`
  255 +是空白骨架（见下一段）。这把根因从"平台缺工具"改判为"这次没人教它、也没有指导它
  256 +主动想到"，是一个不一样、也更能采取行动的结论。
  257 +
236 258 **结论（回答 §四那条 checklist）**：`p-v82tpc` 这次"用静态脚本代替浏览器检查"
237 259 **不是稳定模式，是这一条任务的即兴发挥**——同一个公司、同类任务，`p-bkhylu`
238 260 做到了真实浏览器级验证，`p-v82tpc` 只做到了正则解析文本，`p-v1mpcl` 干脆没做到
... ...