workflow_recursive_agent_review
道-方法 · 道层 skill 全文
本页是 <code>rules/skills/drafts/workflow_recursive_agent_review.md</code> 的逐字投影（仅隐私清洗，零改写）。
时点提示：本页是仓内文件 rules/skills/drafts/workflow_recursive_agent_review.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。
Skill：递归 Agent 审查
元数据
- 类型：Workflow / Draft
- 适用场景：用户要求审查一个 reviewer agent / 审查 session 是否真的审查了另一个 agent 或 target；单个执行结果、Final Report 或普通 completion claim 的可信度默认转
workflow_post_loop_critical_review。 - 输出位置：正式审查报告放
contexts/survey_sessions/；方法沉淀放rules/skills/drafts/。 - 创建日期：2026-05-10
- 来源：2026-05-10 对三个 Codex 审查 Claude Code session 的复审。
目标
这个 skill 用来做递归审查：不仅审查被执行 agent 是否完成任务，也审查 reviewer agent 是否真正做了审查。核心问题是：它有没有回到用户原始需求和实际产物，而不是只复述执行者 final answer、recap、PASS 字样或被截断的工具输出。
触发条件
使用本 skill 的典型请求包括：
- “检查这个审查 session 是否真的完成了”
- “它是不是只相信 Claude 自己说完成”
- “看看 Codex 审查 Claude Code 的过程是否偷懒”
- “这些记录很大，帮我判断有没有因为截断漏看”
- “总结这种审查任务的方法，写成 skill”
只有目标是 reviewer agent、审查 session 或二阶审查行为时触发本 skill。用户只要求检查某个执行结果、loop final report、completion claim 是否可信时，先使用 workflow_post_loop_critical_review。
边界
本 skill 审查的是 agent 行为和证据链，不是泛泛总结聊天内容。
与 workflow_post_loop_critical_review 分开：post-loop review 审查一个执行结果或 final report 是否满足用户需求；本 skill 审查 reviewer agent 是否真的完成了审查。若 reviewer 不足，本 skill 可以抽查被执行 agent 的产物，但最终 verdict 要分成 reviewer verdict 和 target verdict，不能合并成一个 PASS。
与 workflow_long_context_scale_up 分开：大 session、截断 rollout、多 agent 记录需要先用 scale-up 做覆盖型阅读时，本 skill 只消费它的 manifest、chunk report、coverage audit 和 residual ledger。scale-up 不能替代本 skill 的二阶 verdict，因为二阶 verdict 要判断 reviewer 是否回到原始需求、是否检查实际产物、是否处理截断，以及是否把证据等级分层。
不把以下内容当作充分证据：
- 执行 agent 的 final answer
- reviewer 的 final answer
PASS、completed、100%之类字样- 截断后的工具输出
- 只有文件名、没有内容核验的目录清单
- 没有 source path / line anchor 的二手报告
硬规则
- 必须还原用户原始需求。 从被审 Claude / Codex 原始 session 中抽取用户需求，不能从 reviewer 摘要倒推。
- 必须审查 reviewer 行为轨迹。 读取 reviewer session 的工具调用、sub-agent 调用、等待结果、截断处理、最终修正动作。
- 大 context 或递归审查必须用 sub-agent 或新 session。 至少让一个独立 agent 审查原始记录或产物，主 agent 负责冲突裁决。
- 遇到截断必须补救。 改用原始 JSONL、path-specific grep、分段读取、SQLite metadata 或 sub-agent 分片，不把截断输出当全集。
- 完成状态要分层。 区分 self-report、artifact exists、source-linked、verified、independently reviewed、committed。
- 发现 reviewer 不足时，主 agent 要亲自抽查被执行 agent。 不能只评价 reviewer 写得不好。
- 重要发现必须落盘。 至少写一份
contexts/survey_sessions/<topic>_<YYYYMMDD>_manual.md，包含证据路径和结论。
输入材料
可接受的输入是一个或多个 session ID、rollout 路径、Claude resume ID、报告路径或用户描述。优先定位这些来源：
- Codex rollout：
[codex-path] - Codex metadata：
[codex-path] - Claude JSONL：
[session-path] - 可读索引：
contexts/daily_records/claude/和contexts/daily_records/codex/ - 实际产物：被审任务修改的文件、报告、workpad、log、test output、git status
工具路径按名查 tools/INDEX.md，不要在长期 skill 中硬编码工具路径。
审查维度
用户需求还原
产出一个 requirement ledger：
| 字段 | 含义 |
|---|---|
| requirement_id | 稳定编号 |
| 原文位置 | 原始 session path:line |
| plain-language 需求 | 用审查者自己的话重述 |
| 是否被用户纠偏 | 是 / 否 |
| 成功标准 | 可检查的状态 |
特别关注用户是否纠正过范围、材料来源、完成标准、sub-agent 要求、commit 边界。
审查者行为审查
对 reviewer session 建立 behavior ledger：
| 字段 | 通过标准 |
|---|---|
| 原始记录定位 | 找到 reviewer rollout 和被审 agent 原始记录 |
| 需求提取 | 从用户原始 prompt 提取，而不是从 recap 提取 |
| 实际产物读取 | 读取 diff、报告、workpad、log、test output 或目录状态 |
| 验证动作 | 运行可复验命令，或核对 source path / line anchor |
| sub-agent 使用 | 大 context 下至少有独立分工 |
| 截断补救 | 截断后收窄、分段、回原始 JSONL 或委派 |
| 证据等级降级 | 抽样证据不写成全量验证 |
| 结果落盘 | 重要结论写入 contexts/survey_sessions/ |
被执行 agent 实际审查
如果 reviewer 有缺口，主 agent 必须回到被执行 agent 的证据层：
- 原始用户需求是否被满足
- 文件是否实际存在
- 文件内容是否反映需求
- 测试或验证是否真实可复验
- 子任务结果是否被主 agent 整合，而不是各自孤立
- final answer 是否夸大证据等级
- git 状态是否支持“已完成 / 可 commit / 已入库”等说法
裁决
使用以下 verdict，不用模糊形容词：
ADEQUATE：reviewer 基于原始需求和实际产物完成审查，证据链足以支撑结论。PARTIAL：reviewer 抓住主要问题，但缺少独立复核、部分证据、截断补救或完成状态分层。INADEQUATE：reviewer 主要依赖 final answer / recap / self-report，或没有回到实际产物。NEEDS_MORE_EVIDENCE：源记录缺失、产物不可访问或任务仍在移动，当前不能裁决。
对被执行 agent 可以另给 PASS、PASS_WITH_NOTES、PARTIAL、FAIL。不要把 reviewer verdict 和被执行 agent verdict 混成一个判断。
大 Context 处理要求
满足任一条件时必须分工：
- 输入 session 超过 500 行 JSONL
- 涉及两个以上 agent / session
- 用户显式要求递归审查
- 工具输出出现截断
- 需要同时判断需求、行为、产物、验证
推荐最小分工：
- Requirements Auditor：抽取用户原始需求和纠偏点。
- Reviewer Behavior Auditor：审查 reviewer 行为轨迹。
- Artifact Auditor：核对实际产物、diff、git status。
- 验证审查员：核对测试、审查者、sub-agent 和证据路径是否真实。
主 agent 只接受 sub-agent 的证据清单，不接受无路径结论。冲突由主 agent 回源文件裁决。
综合从众提示：上面「只接受证据清单、冲突回源裁决」正是抗从众的强形式。当审计判断不可验证时，叠加防 churn（多采样取众数）与防 harness 门控从众（去权威、剥「多数一致」措辞、显式保留异见）。见 workflow_parallel_subagents §等待与整合「独立综合者配方」。
已知失败模式
1. 自报被包装成全量验证
表现：12 个执行 agent 自报完成，被写成 12/12 独立 reviewer 验证。
处理：降级证据等级。写清楚自报、抽查、完整独立审查的边界。
2. 截断输出被当成全集
表现：rg 或 chat_history_search 输出过大，工具返回截断内容，审查者继续基于可见片段裁决。
处理：收窄路径、关键词、时间窗，或回到原始 JSONL 分段读取。必要时派 sub-agent。
3. 落盘和入库混淆
表现：文件在工作区存在，但目录仍 untracked，却被写成完成或可提交。
处理：分别检查文件存在、git 已跟踪、已暂存、已提交。每个状态单独写。
4. Fallback 尝试缺少交接感知
表现：一个子进程报告“未修改”，但另一个尝试已经落盘修改，主报告和子报告互相矛盾。
处理：用实际产物裁决完成状态，同时把过程风险写入报告。
5. 修正文档但不更新审查报告
表现：初审报告写 PARTIAL，后续已经修复，但报告仍停留在旧 verdict。
处理：追加 closure matrix，列出需求、原缺口、修复动作、当前状态。
输出规格
正式报告至少包含：
- 核心结论，直接回答用户是否应信任这些审查。
- 输入 session 清单，含 rollout / JSONL / report path。
- reviewer 行为 ledger。
- 被执行 agent 实际产物抽查。
- 截断和缺失如何处理。
- verdict 分层：reviewer verdict 与被执行 agent verdict 分开。
- 仍需补的动作。
每条关键判断必须带 source path 和 line number，或者带可复验命令与输出文件路径。
验收标准
完成后必须满足：
- 至少一个 sub-agent 或新 session 参与了独立审查，除非用户明确禁止。
- 每个目标 session 都有原始 rollout / JSONL 路径。
- 每个目标 session 都有 reviewer verdict。
- 对所有
PARTIAL/INADEQUATE给出主 agent 的实际抽查结论。 - 报告写入
contexts/survey_sessions/。 - 如新增或修改 skill，更新
rules/skills/INDEX.md，并按workflow_version_evolution判定版本影响。