Task task-audit-overflow-protocol — 审查 context 超限协议改动

文件路径

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

原始需求

针对以下三处最新改动进行审查，评估设计合理性、内部一致性、执行可行性，并给出保留/修改/回滚建议。

需要审查的改动

1. /root/.openclaw/workspace/scripts/context-check.sh
- 🔴 重载状态的 ADVICE 文字从"立即收尾"改为"停下通知爱衣"
- 完整脚本需通读，确认整体逻辑和三色水位阈值

2. /root/.openclaw/workspace/skills/research/SKILL.md
- 新增末尾章节「Context 超限协议（Researcher 主动停止 + 爱衣重置续接）」
- 包含：Researcher 端上报流程、爱衣端重置步骤、Researcher 收到续接后的恢复流程、续接上限（2次）
- 同时检查已有的 scratch 体量检查（>300行）与新协议是否有重叠/冲突

3. /root/.openclaw/workspace/AGENTS.md
- 「收到 Agent 通知」章节新增 status=context_overflow 处理分支
- 包含：检查锁→读 session log→重置 researcher session→发续接指令→不释放锁
- 审查该流程与现有「格式正确」和「格式不符」分支的衔接是否清晰

审查重点

1. 三者一致性：researcher 上报的消息格式（SKILL.md 定义）与 AGENTS.md 处理逻辑是否完全对齐
2. 双触发器问题：scratch >300行 触发 awaiting_confirmation，tokens >80k 触发 context_overflow——两个触发器是否会同时触发？行为是否冲突？
3. 续接流程可行性：researcher 重置后靠 tail -80 scratch 恢复上下文，是否足够？有无遗漏的恢复步骤
4. 续接次数上限：SKILL.md 说最多2次，AGENTS.md 也说最多2次，计数方式是否明确（谁来记、记在哪）
5. 锁的生命周期：context_overflow 期间不释放锁，续接后最终质检才释放——这个设计与任务执行链的整体锁机制是否一致
6. 边界情况：researcher 在写报告阶段（非搜索阶段）超限时，协议是否同样适用

审查报告格式

输出文件：/root/.openclaw/workspace/tasks/task-audit-overflow-protocol/audit-report.md

格式：每处改动单独一节，每个审查重点明确结论（✅/⚠️/❌），末尾给出总体建议。

执行链

reviewer → 爱衣质检

各 Agent 职责

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

任务：读取上述三个文件，按审查重点逐项评估，输出 audit-report.md。

开始时：
1. 发工作日志：
bash /root/.openclaw/workspace/scripts/log-to-channel.sh reviewer receive "审查overflow协议" task-audit-overflow-protocol

完成后：
1. 将审查摘要追加到 session.md
2. 发工作日志：
bash /root/.openclaw/workspace/scripts/log-to-channel.sh reviewer handoff "审查overflow协议" main task-audit-overflow-protocol
3. sessions_send 通知爱衣（agent:main:main，必须传 timeoutSeconds=0，禁止省略）：
task_id=task-audit-overflow-protocol task=/root/.openclaw/workspace/tasks/task-audit-overflow-protocol/task.md

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

Step 1：评估工作区大小

du -sb /root/.openclaw/workspace/tasks/task-audit-overflow-protocol/

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

Step 2：读取 session.md

wc -l /root/.openclaw/workspace/tasks/task-audit-overflow-protocol/session.md

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

Step 3：质检要点

通用检查：
- audit-report.md 是否存在且完整（三个文件均有审查节）？
- 六个审查重点是否均有明确结论？
- 是否给出总体结论（保留/修改/回滚）？

Step 4：输出结论

通过 →
1. 发工作日志：
bash /root/.openclaw/workspace/scripts/log-to-channel.sh main done "审查overflow协议" task-audit-overflow-protocol
2. 生成报告链接：
bash python3 /root/.openclaw/workspace/scripts/fileview-share.py \ /root/.openclaw/workspace/tasks/task-audit-overflow-protocol/audit-report.md
3. 用 message 工具通知主人（telegram, 92763607），附审查结论摘要和报告链接

不通过（rejectCount == 0） →
1. 分析问题根因
2. 创建新的 task.md（task_id 加后缀 -retry1），session.md 独立
3. 在原 session.md 末尾追加一行 rejectCount=1
4. sessions_send 给 reviewer 重新执行
5. 发工作日志：
bash /root/.openclaw/workspace/scripts/log-to-channel.sh main retry "审查overflow协议" "reviewer → main" reviewer 1 task-audit-overflow-protocol

rejectCount >= 1（第二次仍失败） →
1. 发工作日志：
bash /root/.openclaw/workspace/scripts/log-to-channel.sh main fail "审查overflow协议" task-audit-overflow-protocol
2. message 主人，请主人裁决

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

1. 仅读 task.md
2. 读 session.md 末尾 200 行
3. message 主人：任务已完成，建议人工审计