- 预执行规划与摸底（必做；主控亲自完成）
- 先澄清目标、风险、资源/权限约束，并识别后续扩散依赖的核心维度（主题簇、人物/组织、地域、时间切片等）。
- 若存在公开目录/索引（标签页、API 列表等），用最小化方式抓取缓存并统计条目；若不存在，做“案头调研”获取真实样本（新闻、资料、数据集等），记录来源/时间/要点作为证据。
- 形成清单前至少展示一次真实检索或浏览的代表样本；只靠经验推测不算完成摸底。
- 摸底阶段必须至少通过一次“可追溯的工具链”拿到真实样本并记录引用：优先使用已安装 skills；若需要 MCP，则优先 firecrawl，其次 tavily；若都不可用，记录原因并选择替代方案（必要时再降级到最小化直接联网抓取）。
- 输出初步（或草拟）清单：列出发现的维度、各维度已掌握的选项及样本、规模估算，并标注不确定性/缺口。若尚未获得真实样本，先补齐调研，禁止进入下一步。
- 依据上述结构补全可执行计划（拆分、脚本/工具、输出格式、权限、超时策略等），用用户语言汇报维度统计与计划内容；在得到明确“执行/开始”回应前保持等待。
- 初始化与总体规划
- 明确目标、预期输出格式与评价标准。
- 根据当前任务生成一个语义化且不重复的名字 name（建议：-<短题>-<随机后缀>，全小写、短横线分隔、无空格）。
- 创建运行目录 .research//，并把所有产物都保存到该目录下（子目录如 prompts/、logs/、child_outputs/、raw/、cache/、tmp/）。
- 保持默认模型与配置不变；需要调整任何模型/推理/权限相关设置时先征得用户同意，并在日志中注明变更原因与影响范围。
- 子目标识别
- 通过脚本/命令提取或构造子目标列表。
- 源数据不足时（例如页面只给两个主链接），如实记录原因，然后由主进程直接接手完成剩余工作。
- 生成调度脚本
- 创建调度脚本（例如 .research//run_children.sh），要求：
- 接收子目标列表（可存 JSON/CSV）并逐项调度。
- 为每个子目标构造 codex exec 调用，推荐要点：
- 推荐形式：codex exec --full-auto --sandbox workspace-write ...（以 codex exec --help 为准）。
- 在 prompt 中声明：一切联网需求优先使用已安装 skills（技能优先）；若必须走 MCP，则优先 firecrawl，其次 tavily；确实没办法才用 curl/wget；不使用 plan 工具与“人工交互等待”。
- 非经用户要求不传 --model，也不要用额外 -c 覆写默认模型/推理设置；仅在用户明确授权且结果质量确实不足时才考虑调整。
- 为子输出指定落盘路径（例如 .research//child_outputs/.md）。
- 明确禁止使用已废弃参数（如 --prompt-file、--mcp、--name），并提醒先运行 codex exec --help 获取最新说明。可引用如下调用模板（仅演示参数，不涉及并行）：
```bash
timeout 600 codex exec --full-auto --sandbox workspace-write \
--output-last-message "$output_file" \
- <"$prompt_file"
```
- 如需允许子进程执行“需要 shell 联网”的命令（例如 curl/wget），在 codex exec 调用中追加：-c sandbox_workspace_write.network_access=true。
- 依据任务规模设置超时：小任务先给 5 分钟（timeout 300），较大任务可放宽到最多 15 分钟（timeout 900），通过外部 timeout 命令兜底。首次命中 5 分钟超时时，结合任务实际判断是否拆分/改参数再重试；15 分钟仍未完成则视为 prompt 或流程需要排查。
- 小规模任务（<8 个）用循环 + 后台任务（或队列控制）实现并行，避免命令行长度限制导致失败；大规模任务用 xargs/GNU Parallel，但必须先用小规模验证参数展开。默认并行 8 个，可按硬件或配额调整。
- 不要用“串行一个个跑”来替代并行；也不要用“主进程随便搜搜”等方式绕过既定流程。
- 捕获每个子进程退出码并写日志到运行目录；用 stdbuf -oL -eL codex exec … | tee .research//logs/.log 等方式保证实时刷新，便于 tail -f 观察进度。
- 注意 codex exec 不提供 --output、--log-level 等参数；需要通过管道写文件，并在多段管道后用正确的 PIPESTATUS 索引确认退出码。运行前可用 codex exec --help 复核可用参数。
- 数据量足够时，主控尽量不亲自承担下载/解析等重活；把这些工作交给子进程完成，主控专注于 prompt、模板与环境准备。
- 设计子进程 Prompt
- 动态生成 prompt 模板，至少包含：
- 子目标描述、输入数据、约束边界。
- 规划阶段限制联网检索/抽取的总轮数不超过 X（按复杂度选择；通常建议 10），信息足够就收敛结束；工具优先级：skills → MCP（firecrawl → tavily）→ 最小化直接抓取。
- 结果输出为自然语言 Markdown：包含结论、关键证据列表、引用链接；出现错误时给出 Markdown 形式的错误说明与后续建议。
- 生成实际 prompt 文件时，优先用 printf/逐行写入注入变量，避免 Bash 3.2 在多字节字符场景下 cat < 截断变量的已知问题。
- 将模板写入文件（例如 .research//child_prompt_template.md）以便审计与复用。
- 在启动调度脚本前，逐一快速审阅生成的 prompt 文件（例如 cat .research//prompts/.md），确认变量替换正确、指令完整后再派发任务。
- 并行执行与监控
- 运行调度脚本。
- 记录每个子进程的开始/结束时间、耗时与状态。
- 对失败/超时子进程做明确决策：标记、重试、或在最终报告中说明；触及 15 分钟超时上限时记录 prompt/流程待排查。长任务执行中可提示用户用 tail -f .research//logs/.log 追踪实时输出。
- 程序化聚合（生成基础稿）
- 用脚本（例如 .research//aggregate.py）读取 .research//child_outputs/ 下所有 Markdown，按预设顺序聚合为初版主文档（例如 .research//final_report.md）。
- 解读聚合结果并设计结构
- 通读 .research//final_report.md 与关键子输出。
- 设计精修报告章节大纲与“素材映射”（例如 .research//polish_outline.md），明确目标受众、章节顺序与每章核心论点。
- 分章精修与出稿
- 新建精修稿（例如 .research//polished_report.md），按大纲逐章撰写；每写完一章立刻自查事实、引用与语言要求，必要时回溯子稿核实。
- 避免一次性全篇重写；坚持“按章迭代”以维持一致性并降低遗漏风险，同时记录每章亮点、问题与处理方式。
- 对重复信息、引用格式、待确认条目做统一整理，同时保留核心事实与量化数据。
- 落地交付
- 确认精修稿满足交付标准（结构完整、语气统一、引用准确），以该成品作为对外报告。
- 最终交付物必须落地为独立文件（位于 .research//）；通过提供文件路径与必要摘要向用户回报，禁止在聊天中贴出完整成稿。
- 在最终答复中概述核心结论与可执行建议；必要时补充待确认事项的跟进方式。
- 不对外附带中间稿或内部笔记，确保用户看到的是高质量成品。
|