Task task-research-flow-review — Research 流程优化方案评估

文件路径

• task.md（本文件，创建后不再修改）：/root/.openclaw/workspace/tasks/task-research-flow-review/task.md
• session.md（执行日志，只追加）：/root/.openclaw/workspace/tasks/task-research-flow-review/session.md

原始需求

2026-02-25 task-keyence-r2（Research 模式）在写 session log 时因单次 API response 过长被 abort，报告全部丢失。复盘后提出了一套 research 流程优化方案，需要 Ai.Rev 进行独立评估：查漏补缺、识别遗漏风险、提出改进建议。

注意：这是方案评估任务，不是代码审查。Ai.Rev 应作为「独立审查员」，不受原方案约束，可以提出完全不同的方案。

执行链

reviewer → 爱衣质检

背景材料

事故经过（LESSONS.md #026 摘要）

直接原因：Researcher 完成 2 轮搜索 + PDF 精读后，在最后用一个巨型 heredoc 一次性写 session log，单次 response 过长触发 abort。session.md 和报告全部丢失。

深层原因：
- research SKILL.md 的 Step 6 是批量写入，全部完成后才落盘
- Research 模式多轮迭代 + PDF 精读（每次 10-15k 字）导致 context 积累到 112k（56% 满载）
- 生成大段 heredoc 时 API 撑不住

为什么补写没出问题：补写任务是"基于 context 写结构化报告"，不需要罗列全部搜索记录，单次 response 短很多。

待评估的改进方案（T035）

改动 1：每轮结束立即 append session log

现状：research SKILL.md Step 6 在所有轮次完成后一次性写入
改动：每轮搜索结束后立即 append，小块写入（echo "..." >> file），不用 heredoc

改动 2：新增 scratch 文件

路径：sessions/scratch-<task_id>.md
内容：实时记录查询词选择理由、命中判断、知识缺口分析
用途：中断后可作为断点续接的依据；减少 context 负担

改动 3：报告分章节写

现状：最后一口气生成完整报告（一个大 heredoc）
改动：先写 frontmatter + 标题，每完成一章节立即 append

改动 4：PDF 内容及时卸载

现状：pdf_fetch.py 提取的全文（10-15k 字）保留在 context 中
改动：提取完立即写入 scratch 文件，context 里只保留 50 字摘要

改动 5：禁用大段 heredoc

改动：单次 exec 写入内容 ≤ 200 行，超过则分段 append

各 Agent 职责

Ai.Rev（session key: agent:reviewer:main）

任务：独立评估 research 流程优化方案，查漏补缺。

评估维度（必须覆盖）：

1. 方案完整性：提出的 5 项改动是否能充分解决 abort 问题？有无遗漏的根因？
2. 副作用风险：每项改动是否会引入新问题？
3. 例：每轮 append 会不会增加写操作失败的概率？
4. 例：scratch 文件会不会在 context 里被重复读取造成新的膨胀？
5. 实施可行性：改动是否与现有工具（write 工具、exec append、research SKILL.md 结构）兼容？Researcher 能否可靠执行这些规则？
6. 遗漏检查：以下方面是否需要补充？
7. 改动后的 SKILL.md 应该怎么写（结构上）
8. researcher AGENTS.md 需要哪些对应规则
9. 如何处理 scratch 文件的 TTL（30 天清理同 session log？）
10. Search 模式是否也需要同样的增量落盘改动（当前方案只明确了 Research 模式）
11. 替代方案：是否有更好的方案解决相同问题？

评估不需要：实际修改任何文件，只需要产出评估报告。

输出要求：
- 评估报告：追加到 /root/.openclaw/workspace/tasks/task-research-flow-review/session.md
- 格式：按评估维度分节，每条结论给出明确判断（✅ 通过 / ⚠️ 有风险 / ❌ 有问题）和理由
- 最后给出：建议接受的改动、建议修改的改动、建议新增的改动三类清单

开始时：
1. 发工作日志：
bash /root/.openclaw/workspace/scripts/log-to-channel.sh reviewer receive "Research流程优化方案评估" task-research-flow-review

完成后：
1. 将评估报告追加到 session.md
2. 发工作日志：
bash /root/.openclaw/workspace/scripts/log-to-channel.sh reviewer handoff "Research流程优化方案评估" main task-research-flow-review
3. sessions_send 通知爱衣（agent:main:main，必须传 timeoutSeconds=0，禁止省略）：
task_id=task-research-flow-review task=/root/.openclaw/workspace/tasks/task-research-flow-review/task.md

⚠️ 爱衣质检 SOP（收到最终通知后执行）

Step 1：评估工作区大小

du -sb /root/.openclaw/workspace/tasks/task-research-flow-review/

• 超过 80KB → 跳至「超限处理」
• 未超过 80KB → 继续 Step 2

Step 2：读取 session.md

wc -l /root/.openclaw/workspace/tasks/task-research-flow-review/session.md

若行数 N > 0，read session.md 全文。

Step 3：质检要点

• 是否覆盖了所有 5 个评估维度？
• 每条结论是否有明确判断（✅/⚠️/❌）和理由？
• 是否有明确的「建议接受/修改/新增」三类清单？
• Ai.Rev 是否有漏掉的重要风险？

Step 4：输出结论

通过 →
1. 基于 Ai.Rev 的评估报告，整合成最终方案，实施 T035 改动（修改 research SKILL.md 和 researcher AGENTS.md）
2. 发工作日志：
bash /root/.openclaw/workspace/scripts/log-to-channel.sh main done "Research流程优化方案评估" task-research-flow-review
3. message 主人：评估完成，附 Ai.Rev 核心结论 + 爱衣将要实施的改动清单，请主人确认后执行

不通过（rejectCount == 0） →
1. 分析问题，创建补充评估任务（task-id: task-research-flow-review-retry1）
2. 在 session.md 末尾追加 rejectCount=1
3. sessions_send 给 reviewer
4. 发工作日志：
bash /root/.openclaw/workspace/scripts/log-to-channel.sh main retry "Research流程优化方案评估" "reviewer → main" reviewer 1 task-research-flow-review

rejectCount >= 1 →
1. 发工作日志：
bash /root/.openclaw/workspace/scripts/log-to-channel.sh main fail "Research流程优化方案评估" task-research-flow-review
2. message 主人，请裁决

超限处理（工作区 > 80KB）

1. 仅读 task.md + session.md 末尾 200 行
2. message 主人：内容繁多，建议人工审计