Task task-ctx-reduce-research — OpenClaw 初始 Context 调研与优化方案

文件路径

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

背景与问题陈述

观测数据

爱衣（主 session）在新 session 冷启动时，初始 context 为 42k / 200k（21%），分解如下：

对比：另一个简洁 OpenClaw session 的冷启动只有 13k / 200k（7%），分解：
- System Prompt 框架：~5,850 tokens（45% of 13k）
- Workspace 文件：~3,250 tokens（25% of 13k）
- 无每日记录加载

差距：29k tokens，其中 System Prompt 框架差异约 18k tokens。

核心约束

• 能力不能下降���AGENTS.md（19KB）和 MEMORY.md（10.6KB）已足够精简，不能再删
• 目标：在不损失能力的前提下，减少冷启动初始 context
• 方向假设：「懒加载」——维护索引/目录，按需读取，不在启动时全量加载

原始需求

调研以下问题并给出可操作的优化方案报告：

1. 我们的 42k 初始 context 是否异常？
2. OpenClaw 的正常初始 context 基线是多少？
3. System Prompt 框架的 18k 差距说明什么？（是 skills 多导致的？是工具 schema？是其他配置？）

4. 参考对象：其他 AI assistant 框架（AutoGPT、Open Interpreter、Cursor、Cline、Continue 等）的初始 context 基线

5. 哪些内容真的需要在第一时间加载？

6. 分析各类 Project Context 文件的「使用频率」vs「初始加载必要性」
7. 哪些内容可以改为「索引 + 按需读取」？

8. 「懒加载」模式的可行性评估：维护一个轻量索引文件，按需 read 详细内容

9. OpenClaw 的 context 优化手段有哪些？

10. OpenClaw 配置中有哪些 context 相关选项？（skills 列表裁剪、workspace 文件注入控制等）
11. OpenClaw 社区/文档有无 context 优化最佳实践？

12. 其他用户如何处理 system prompt 过大的问题？

13. 可行的优化方案清单

14. 每个方案：描述 + 预计节省 tokens + 实现难度 + 能力影响评估

调研约束

• 重点关注实际可执行的方案，不要泛泛而谈
• 每日记录的「懒加载」是重点方向之一：session 开始时只确认索引/目录，需要时再 read
• AGENTS.md 和 MEMORY.md 内容本身不改，但可以研究是否有方法不在 system prompt 里全量注入

执行链

researcher → 爱衣质检

各 Agent 职责

Ai.Res（session key: agent:researcher:main）

任务：按上述原始需求，进行网络调研 + 分析，产出完整的调研报告（Markdown 格式）

报告保存路径：/root/.openclaw/workspace/tasks/task-ctx-reduce-research/report.md

调研要点：
1. 搜索 OpenClaw context 相关文档（docs.openclaw.ai、GitHub）
2. 搜索主流 AI coding assistant 的 system prompt / context 设计
3. 分析「懒加载」模式的实现可行性（给出具体文件结构建议）
4. 给出优先级排序的优化方案

开始时：
1. 发工作日志：
bash /root/.openclaw/workspace/scripts/log-to-channel.sh researcher receive "OpenClaw Context 优化调研" task-ctx-reduce-research

完成后：
1. 将执行日志追加到 session.md
2. 发工作日志：
bash /root/.openclaw/workspace/scripts/log-to-channel.sh researcher handoff "OpenClaw Context 优化调研" main task-ctx-reduce-research
3. sessions_send 通知爱衣（agent:main:main，必须传 timeoutSeconds=0，禁止省略）：
task_id=task-ctx-reduce-research task=/root/.openclaw/workspace/tasks/task-ctx-reduce-research/task.md

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

Step 1：评估工作区大小

du -sb /root/.openclaw/workspace/tasks/task-ctx-reduce-research/

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

Step 2：读取 session.md

wc -l /root/.openclaw/workspace/tasks/task-ctx-reduce-research/session.md

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

Step 3：质检要点

通用检查（每次必须）：
- 产出是否符合原始需求？
- 执行过程是否有明显问题？

任务特定检查：
- report.md 是否涵盖全部 4 个调研问题？
- 优化方案是否具体可执行（非泛泛而谈）？
- 是否有「懒加载」方案的具体实现建议？
- 能力影响评估是否客观？

Step 4：输出结论

通过 →
1. 发工作日志：
bash /root/.openclaw/workspace/scripts/log-to-channel.sh main done "OpenClaw Context 优化调研" task-ctx-reduce-research
2. 用 message 工具发送给主人（telegram, 92763607），归纳调研报告核心结论和可行方案列表
⚠️ 必须调用 message 工具，不能只在主对话回复

不通过（rejectCount == 0） →
1. 分析问题根因，设计新执行链
2. 创建新的 task.md（task_id 加后缀 -retry1），session.md 独立
3. 在原 session.md 末尾追加一行 rejectCount=1
4. sessions_send 给新执行链起始 Agent
5. 发工作日志：
bash /root/.openclaw/workspace/scripts/log-to-channel.sh main retry "OpenClaw Context 优化调研" "researcher → main" researcher 1 task-ctx-reduce-research

rejectCount >= 1（第二次仍失败） →
1. 发工作日志：
bash /root/.openclaw/workspace/scripts/log-to-channel.sh main fail "OpenClaw Context 优化调研" task-ctx-reduce-research
2. message 主人，归纳问题和两次失败原因，请主人裁决

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

1. 仅读 task.md（了解需求）
2. 读 session.md 末尾 200 行
3. message 主人：任务已完成，但工作区内容繁多，建议人工审计，附简单归纳