Idea Storm

工程问题的自动化 设计→验证→迭代 闭环。后台运行，不阻塞主会话。

运行架构

采用分段 spawn 模式：每个检查点之间的工作在独立子 agent 中运行，状态通过文件传递。

CODEBLOCK0

spawn 任务模板

每次 spawn 时，task 中必须包含：

1. 1. 实验状态文件路径：INLINECODE0
2. 当前要执行的阶段
3. 用户的确认/反馈内容（如有）

示例：
CODEBLOCK1

子 agent 启动后：

1. 1. 读 idea-storm SKILL.md 获取流程指引
2. 读 experiment.yaml 恢复实验状态
3. 执行指定阶段
4. 更新 experiment.yaml + Notion
5. announce 结果摘要

记忆管理

三层存储，确保状态不丢失：

层级 1：热状态 (SESSION-STATE.md)

主会话的 SESSION-STATE.md 记录当前活跃实验的概要：

CODEBLOCK2

层级 2：实验工作区

每个实验在 workspace 下有独立目录：

CODEBLOCK3

层级 3：Notion 长期记录

结构化实验报告，按时间和分类组织。详见 Notion 页面结构。

experiment.yaml 规范

实验的完整状态文件，子 agent 靠它恢复上下文：

CODEBLOCK4

核心流程

Phase 1: 问题定义（主会话执行）

用户输入工程问题或 idea。提取并确认：

1. 1. 问题描述：要解决什么
2. 成功标准：怎样算解决了
3. 约束条件：技术栈、资源限制
4. 验证方式：见 验证模式

如果用户没有明确给出以上信息，主动询问（不要一次问太多）。

确认后：

1. 1. 创建实验目录 INLINECODE1
2. 写入 INLINECODE2
3. 创建 Notion 实验页面
4. 更新 SESSION-STATE.md
5. spawn 子 agent 执行 Phase 2-3

Phase 2: 调研（子 agent）

偏向工程化搜索，优先级：

1. 1. GitHub 开源项目和实现
2. 技术博客、Stack Overflow、工程实践
3. 产品文档、API 文档
4. 论文（仅在工程资料不足时补充）

工具：web_search + INLINECODE4

输出：

• - research/findings.md：调研结果
• 更新 experiment.yaml
• 更新 Notion「调研记录」

Phase 3: 方案设计（子 agent）

基于调研设计技术方案：

• - 整体架构
• 关键技术选型
• 实现步骤
• 预期效果

输出：

• - design/plan.md：方案详情
• 更新 experiment.yaml（phase → "等待检查点1"）
• 更新 Notion「方案设计」
• announce 方案摘要给主会话

✅ 检查点 1：方案确认（主会话）

用户确认后，主会话 spawn 新子 agent 执行 Phase 4-6。

Phase 4: 实现（子 agent）

按方案执行。可能包括：编写代码、配置环境、生成资源、调用 API。

输出：

• - src/ 下的实现代码
• 更新 Notion「实验日志」

Phase 5: 验证（子 agent）

按 experiment.yaml 中定义的验证方式执行。详见 验证模式。

输出：

• - results/iter-N/：本轮验证数据
• 更新 Notion「验证结果」

Phase 6: 评估与迭代决策（子 agent）

根据验证结果判断：

更新 experiment.yaml 后 announce 结果给主会话。

✅ 检查点 2：迭代确认（主会话）

汇报内容：

• - 本轮做了什么
• 效果数据/截图
• 下一步建议

用户确认后 spawn 下一轮或进入收敛。

Phase 7: 收敛报告（子 agent）

生成最终报告：

• - report.md：本地完整报告
• 更新 Notion 最终报告区块
• announce 报告摘要

✅ 检查点 3：最终确认（主会话）

验证模式

由用户在 Phase 1 定义。

模式 A：图片对比

用户提供参考图 + 输入集。Agent 生成输出，与参考图对比。

• - 工具：scripts/compare_images.py（SSIM / 像素差异）或 image 工具（视觉分析）
• 达标标准由用户定义

模式 B：指标优化

用户定义评测函数或指标，Agent 优化实现以提升指标。

• - 用户提供评测脚本或指标定义
• 每轮记录指标变化
• 达到阈值即收敛

模式 C：功能验证

用户定义测试用例或验收标准，Agent 逐项验证。

模式 D：自定义

用户描述验证方式，Agent 按描述执行。

Notion 实验页面结构

每次启动实验时创建新页面。配置见 references/notion-setup.md。

CODEBLOCK5

工具使用

Claude Code 集成

Phase 4（实现）阶段，优先使用 Claude Code 在 Docker 沙盒中完成编码任务。

Docker 沙盒架构

每个实验在独立的 Docker 容器中运行 Claude Code，与宿主机隔离：

CODEBLOCK6

优势：

• - 完全隔离，不污染宿主机环境
• 非 root 用户可用 --dangerously-skip-permissions 自动跳过权限
• API 配置从 openclaw.json 动态注入，换中转改一处即可
• 容器用完即删，干净无残留

镜像构建

使用预构建的 idea-storm-sandbox 镜像。Dockerfile 位于 scripts/Dockerfile：

CODEBLOCK7

构建：INLINECODE28

调用方式

从 openclaw.json 动态提取 API 配置，注入容器环境变量：

CODEBLOCK8

在子 agent 中使用

子 agent 执行 Phase 4 时，通过 exec + pty:true 调用：

CODEBLOCK9

也可以使用辅助脚本 scripts/run-sandbox.sh 简化调用（见下方）。

Prompt 构造原则

给 Claude Code 的 prompt 应包含：

1. 1. 目标：要实现什么功能
2. 上下文：当前项目结构、技术栈、已有代码
3. 约束：文件路径、命名规范、依赖限制
4. 验证：实现后如何验证（测试命令等）

示例：
CODEBLOCK10

迭代模式（Ralph Loop）

多轮迭代优化时，循环调用容器中的 Claude Code：

1. 1. 将任务写入实验目录的 INLINECODE33
2. 循环调用 Docker 容器，每轮读取 PROMPT.md
3. 通过文件（experiment.yaml）传递迭代状态
4. 检查完成标记决定是否继续

CODEBLOCK11

何时用 Docker 沙盒 vs 宿主机直接执行