Ai.Rev 评估报告 — Research 流程优化方案（T035）

评估时间：2026-02-25
评估人：Ai.Rev（agent:reviewer:main）
任务ID：task-research-flow-review

一、方案完整性评估

直接原因覆盖

✅ 改动 1（每轮 append）+ 改动 3（报告分章节写）+ 改动 5（禁用大段 heredoc）
三者组合直接解决了「最后一次性写入巨型 heredoc 触发 abort」的直接原因。覆盖充分。

✅ 改动 4（PDF 卸载）
针对「PDF 精读导致 context 积累」的深层原因，有明确应对。

⚠️ 改动 2（scratch 文件）
定位为「减少 context 负担 + 断点续接」，但 scratch 文件本身的读取规则未明确：
- Researcher 是否需要在每轮开始时读取 scratch 文件？
- 若需要读取，scratch 内容可能反向膨胀 context（尤其是多轮迭代后 scratch 本身变大）
- 若不读取，「断点续接」的价值大打折扣

⚠️ 遗漏的根因：context 上限本身没有监控机制
事故触发点是 112k/200k（56%），但方案没有设置「context 水位预警」：当 context 达到阈值（如 70%），Researcher 应该主动落盘当前 context 并截断，而不是等到最后写报告时才爆。

⚠️ 遗漏的根因：SKILL.md Step 顺序问题
原方案 Step 6 是「所有轮次完成后写入」，改动 1 改的是写入时机，但未明确 SKILL.md 的 Step 重构方式。如果仅修改 Step 6 而不调整整体流程描述，Researcher 执行时可能仍按旧逻辑运行（LLM 对步骤顺序敏感）。

二、副作用风险评估

改动 1：每轮 append

✅ 主路径：echo append 操作极轻量，写入失败��率极低，比 heredoc 更稳定。
⚠️ 风险：若同一 task 有多个 Researcher 并发执行（未来扩展），append 会产生交叉写入。当前单 Agent 模式下不是问题，但应在规则里明确「禁止并发」。
✅ 判断：风险可控，无需阻止改动。

改动 2：scratch 文件

⚠️ 风险 1：scratch 文件可能成为新的膨胀源
多轮迭代后 scratch 文件可能超过 5000 字，若 Researcher 在下一轮开始时全量读取，等同于把 context 负担转移到读文件阶段。
建议：scratch 文件应分段（每轮一节），Researcher 每轮只读「上轮摘要」而非全文。

⚠️ 风险 2：scratch 文件路径规范不明确
路径 sessions/scratch-<task_id>.md 相对路径不清晰——相对哪个根目录？应明确为绝对路径或相对 workspace 的固定结构。

❌ 风险 3：断点续接机制不完整
scratch 文件有断点续接的定位，但 task.md 没有定义「续接 SOP」：Researcher 被中断后，如何知道自己处于哪一轮、下一步该做什么？仅靠 scratch 文件内容不足以驱动续接，需要补充「进度状态字段」（如当前轮次、已完成的搜索词列表）。

改动 3：报告分章节写

✅ 核心有效：分章节写入大幅降低单次 response 长度，直接规避 abort 风险。
⚠️ 风险：章节粒度未定义
「每完成一章节立即 append」依赖 Researcher 对「章节」的理解。若某章节本身内容极长（如「详细分析」），仍可能触发单次 response 过长。
建议：SKILL.md 应明确每次 append 的内容上限（如 ≤ 500 字 / ≤ 50 行），超过则继续分段，而非按章节粒度控制。

改动 4：PDF 卸载

✅ 核心有效：将 10-15k 字的 PDF 内容从 context 替换为 50 字摘要，大幅压缩 context。
⚠️ 风险 1：50 字摘要可能不足以支撑后续分析
Researcher 在写报告时若需要引用 PDF 中的具体数据，50 字摘要无法提供，需要重读 scratch 文件。若 scratch 文件未包含关键数据，可能导致报告准确性下降。
建议：摘要应包含「核心数值 + 关键论点 + scratch 文件中对应章节的读取指引」，而非仅 50 字概述。

⚠️ 风险 2：write 工具 vs exec append
PDF 内容写入 scratch 是用 write 工具（覆盖）还是 exec append？若用 write 覆盖，多个 PDF 处理后只保留最后一个；若用 append，scratch 文件结构需要有清晰的分隔符。应明确。

改动 5：禁用大段 heredoc（≤ 200 行限制）

✅ 核心有效：直接约束单次输出长度，釜底抽薪。
⚠️ 风险：200 行上限是否经过测试？
200 行对应约 6000-8000 字（视行长）。若单次 response 还有工具调用 overhead，实际安全阈值可能更低。建议设为 100 行，或改用字节估算（≤ 3000 字）。
⚠️ 风险：Researcher 无法精确预估行数
LLM 在生成时无法实时计数，「≤ 200 行」的规则依赖自我约束，容易失效。更可靠的机制是：内容超过阈值时强制截断并在下次写入续接，而非依赖预估。

三、实施可行性评估

✅ exec append 方式：echo "..." >> file 是标准 shell 操作，现有 exec 工具完全支持，可靠。

✅ write 工具分段写：write 工具支持创建/覆盖文件，scratch 文件初始化用 write，后续内容用 append，路径清晰。

⚠️ SKILL.md 重构复杂度
现有 research SKILL.md 是线性步骤结构。改动 1/3/4 要求在多个步骤中插入「立即写入」操作，改动后 SKILL.md 会变得更复杂。若步骤描述不够清晰，Researcher 可能跳过或错序执行。
建议：SKILL.md 改动后需要增加「执行检查点」说明（如每轮结束的 checklist），确保 Researcher 不遗漏落盘步骤。

⚠️ researcher AGENTS.md 未涉及
task.md 提到 researcher AGENTS.md 也需要对应规则，但 T035 方案只针对 SKILL.md，未明确 AGENTS.md 需要新增哪些约束。

四、遗漏检查

4.1 SKILL.md 结构应该怎么写

⚠️ 方案未说明
T035 只列出了「改什么」，没有给出新 SKILL.md 的结构草案。以下是建议结构要点：

Step 1: 初始化
  - 创建 session.md（若不存在）
  - 创建 scratch-<task_id>.md（若不存在）

Step 2-N: 每轮搜索
  - 执行搜索
  - 立即 append 本轮查询词 + 结果摘要 到 session.md（≤ 50 行）
  - 立即 append 本轮判断 + 知识缺口 到 scratch 文件

Step PDF: 若需精读 PDF
  - 提取全文写入 scratch（append，带分隔符）
  - 在 session.md 中只记录「已读 PDF：<标题>，摘要：<50字>，详见 scratch L<N>」

Step Final: 写报告
  - 按章节逐段 append（每次 ≤ 100 行）
  - 每章节完成后立即 append，不攒批

4.2 researcher AGENTS.md 需要哪些对应规则

⚠️ 方案未说明，建议新增：
- 「禁止批量写入」规则：明确禁止「所有工作完成后一次性写入」模式
- 「context 水位检查」规则：每轮结束后，若 context 估算超过 60%，强制执行中间报告落盘并通知爱衣
- 「heredoc 禁用」规则：明确禁用 heredoc，改用 echo append 或 printf append

4.3 scratch 文件 TTL

⚠️ 方案未说明
task.md 明确提出这个问题，T035 完全没有回应。建议：
- scratch 文件与 session.md 同级，随 task 目录清理（30天，与 session log 策略一致）
- 不需要单独的 TTL 策略，只需在清理脚本中将 scratch-*.md 纳入清理范围

4.4 Search 模式是否也需要增量落盘

⚠️ 方案未明确
T035 的标题和所有改动都指向 Research 模式。但 Search 模式同样面临：
- 多轮搜索积累 context
- 最后批量写报告

如果 Search 模式的 SKILL.md 有类似的「Step N: 完成后写入」结构，同样存在 abort 风险。
建议：在实施 T035 时，同步检查 Search 模式 SKILL.md，若有批量写入步骤，一并改为增量落盘。

五、替代方案

替代方案 A：流式写入 + 事务性提交（更激进）

思路：不以「轮次」为写入单位，而是每次 exec/write 工具调用后立即落盘该次操作的输出摘要（50-100字）。
优点：粒度最细，几乎不可能出现 abort 导致全量丢失。
缺点：写操作频率极高，Researcher 的「写 session log」动作会散布在整个执行过程中，SKILL.md 描述难度大。

替代方案 B：context 窗口分段执行（架构级）

思路：当 context 超过 50% 时，自动将当前 Researcher 的上下文压缩为摘要，启动一个新的「续接 Researcher」携带摘要继续工作。
优点：根治 context 积累问题。
缺点：需要 orchestration 支持（爱衣/coder 介入），实现复杂度高，短期不现实。

替代方案 C：本方案微调（推荐）

在 T035 五项改动的基础上，补充：
1. context 水位检查机制（每轮结束检查，超过 65% 触发强制落盘）
2. scratch 文件分段读取规则（每轮只读上轮摘要，不全量读取）
3. SKILL.md 结构草案（明确 Step 序列和每步的写入要求）
4. Search 模式同步审查

六、综合结论

✅ 建议接受的改动

⚠️ 建议修改后接受的改动

🆕 建议新增的改动

评估结论：T035 方案的核心思路正确，改动 1/3/5 可直接接受，改动 2/4 需要细化后实施，整体方案存在「说明了方向但缺少落地细节」的问题。补充 N1-N5 后，方案可完整支撑 Research 流程的可靠性。