科研史诗管理 alexchen5/research-epic-manager

Research Epic Manager | 智能体技能

自主研究作为智能体技能：这个仓库收录了一批智能体技能，能让智能体跑完整个科研项目，从想法到成稿。

为了组织科研项目这种长周期工作，我们用一套受敏捷启发的跟踪系统。纯 markdown 文件（EPIC.md、ISSUE.md、comments/.md）记录全部工作，把编排文档和修订文档与项目文件分开存放。智能体技能把这套系统的记账流程固化下来，完全在本地文件系统内运行。人类反馈自然融入：从智能体对话 → issue 评论。

核心的「tracker」技能非常灵活，用来组织任何长周期项目都合适。因此，「科研项目管理」这部分被定义成一个专门的「epic manager」技能——它规定整个项目从想法、开发到修订，各阶段需要生成哪些 issue，以及这些 issue 的生命周期。

论文

这个仓库包含以下论文所述的智能体技能与案例研究产物：

Autonomous Research Project Management as an Agent Skill:
A Case Study in Exact Spectral Spatial Regression*

arXiv:2609.31683

安装

DeepSeek Harness (DSH)

1. 把 skills/ 软链接或复制到你的发现根目录（工作区根目录下的 .dsh/skills）。
2. 把 AGENTS.md 粘贴到你的 tracker 根目录（EPICS_ROOT，默认 /workspace/epics/）；skills/ 里的那份副本留在技能目录中，根目录那份才是 harness 读取的工作区指令。如果你的目录结构不同，改 skills/AGENTS.md 里的两处路径定义。

其他 harness

这些智能体技能并非与 harness 无关。目前只测试过 DSH。

话虽如此，实际上并不存在对 DSH 的硬依赖。要在你的 harness 里安装：

1. 把 skills/ 和 AGENTS.md 复制到你的 harness 专属位置。
2. 把 issue-subagent-orchestration 和 research-project-epic-manager 技能里 DSH 原生的子代理派发机制，改写成你 harness 的约定。

技能目录

| 技能 | 一句话说明 |
| add-epic | 创建 epic 容器（目录 + EPIC.md） |
| add-issue | 添加 issue（草稿优先的生命周期 + 就绪门禁 → open） |
| add-comment | 追加一条匿名、按时间顺序排列的评论 |
| issue-manager | 处理某个 issue 的对话协议（角色、派发、验证） |
| issue-subagent-orchestration | DSH 原生：记录 harness 的委派工具（subagent、workflow、send_message、job_output、interrupt_agent） |
| research-project-epic-manager | 专门的 epic manager（DSH 原生派发机制）：拉起 issue 和 issue manager，带项目走完 Scope → Generate → Dispatch → Collect → Synthesize 五阶段循环，每步都有门禁裁决 |

DeepSeek-Harness 专属部分： skills/issue-subagent-orchestration/SKILL.md 它是 harness 原生的：文档写的是 harness 自己的委派工具（subagent、workflow、send_message、job_output、interrupt_agent）。research-project-epic-manager 技能的派发机制也一样（它 references/ 里的 Phase-C brief 模板），引用的都是 harness 的委派工具（subagent、job_output、send_message、interrupt_agent），必须映射到另一个运行时的委派工具上。

用户指南

想启动整个项目，直接在聊天里说「manage a research project」：

Manage a research project - create a workshop paper under
https://www.climatechange.ai/events/neurips2026 as the theme. Limitations:
CPU-only data analysis. Deliverable: a 4-page PDF with workshop formatting.

编排器接收一份 research brief 和一份 project config（从 skills/research-project-epic-manager/assets/project-config-template.yaml 起步），然后跑五个阶段：范围界定、按阶段即时生成 issue、派发 coder/reviewer 子代理、把各阶段产出暂存并收集进扁平的 project.json 清单、合成交付物。

怎么看它跑： 一切都是文件 —— EPIC.md（issue 索引）、project.json（清单）、编排日志上只追加的 verdict_history，以及项目工作区和 project.json 清单里只追加的 artifacts 映射。随便问一句「status of epic <X>?」都行。

你，跑的过程中或跑完之后： 默认的 autonomous 模式下，运行不会停下来等批准 —— 它自己决定、记录决定、继续往下走。你的指令会以匿名 [human-directive:<digest>] 评论的形式落到受影响的 issue 上，带日期、带路由，在被执行之前追加；项目级的输入还会落到编排日志上。更喜欢审批点？在配置里设 autonomy.mode: gated。两种模式都一样：真正的阻塞（评审循环耗尽、灾难性失败、路由目标缺失）会以 blocked issue 加 manager 通知的形式浮出来；用一条 directive 解掉它们，或者你自己动手处理这个 issue（「work on issue <X>」会让那个聊天成为 issue manager，关掉任何东西之前它都会先验证）。

Act as issue manager for <path to issue>: ... describe a request/comment/question

或者直接跟 epic manager 对话：

Include a constraint to this project ...

与其他系统对比

这张表给 2024–2026 这一批自主研究系统打分。

怎么读这些标记

| 标记 | 含义 |
| ✅ | 是 —— 在调研过的来源里有实证 |
| 🟡 | 部分 —— 存在某种形式，或者某项说法未经独立验证 |
| ❌ | 否 —— 什么都没找到 |
| ❔ | 未记录 —— 没有证据（不等于证据不存在） |
列标尺：Setup（你面对的入门要求）：📖 开源 · 🔒 闭源 · 🧪 仅论文原型 · ❔ 未记录 • 生命周期覆盖（无需人工介入即可运行的阶段）：✅ 完整闭环 · 🟡 关键子集 · ❌ 单一阶段 • 生命周期可审计性（能否还原运行过程）：✅ 决策记录 · 🟡 仅产物 · ❌ 无可检查内容 · ❔ 未记录 • 自我改进（系统能否自我改进，由弱到强）：🔄 对象级 · 🧠 记忆驱动 · 🎓 权重级 · 🪞 协议级。

| 系统 | Setup | 生命周期覆盖 | 生命周期可审计性 | 自我改进 |
| research-epic-manager（本仓库） | 📖 六个 SKILL.md 文件 + 标准库自带能力；只需 Python 3 | ✅ 完整闭环 —— 从范围界定到综合，含各道关卡 | ✅ 决策记录 —— 只追加的裁决历史，可反向执行失效判定 | 🪞 协议级 —— 关卡失败会变成发现项；修复在跟踪器内跟踪 |
| AI-Scientist v1/v2 | 📖 开源仓库 + LLM 密钥 + GPU | ✅ 完整闭环 —— 构思 → 实验 → 撰写 → LLM 评审 | 🟡 仅产物 —— 运行目录 + 成本跟踪 | 🔄 对象级 —— 单篇论文内的树搜索 |
| CycleResearcher | 📖 开放权重模型 | 🟡 写作 + 评审这一半 | 🟡 仅产物 —— 训练循环记录 | 🎓 权重 —— 重新训练自己的模型 |
| Agent Laboratory / AgentRxiv | 📖 开源；依赖前沿模型 | 🟡 文献综述 → 实验 → 报告 | 🟡 仅产物 —— 反馈留在对话里 | 🔄 对象级 —— 副驾驶式引导 |
| STORM / Co-STORM | 📖 开源 pip 包 | ❌ 仅写作前阶段 | 🟡 仅产物 —— 思维导图会留存 | ❌ 未记录 |
| DeepScientist | ❔ 容器化；以月为尺度 | 🟡 假设 → 验证 → 分析各层级 | 🟡 仅产物 —— Findings Memory；只向前 | 🧠 记忆 —— 失败跨运行保留 |
| Kosmos | ❔ 未记录 | 🟡 长周期发现；撰写环节不明确 | 🟡 仅产物 —— 每轮输出世界模型摘要 | 🧠 记忆 —— 世界模型引导下一轮 |
| ASI-Arch | ❔ 未记录 —— 约 2 万 GPU 小时 | ❌ 仅架构发现 | 🟡 仅产物 —— 每次试验都归档、可检索 | 🧠 记忆 —— 试验档案喂给后续轮次 |
| CodeScientist | 🧪 未记录发布情况 | 🟡 构思 → 构建 → 报告 | 🟡 仅产物 —— 各阶段由评审打分 | ❔ 未记录 |
| Co-Scientist | 🔒 受限访问 | 🟡 假设 + 方案设计 | 🟡 仅产物 —— 辩论记录 + Elo | 🔄 对象级 —— 锦标赛式演化 |
| Robin | 🔒 专有 | 🟡 提议 → 分析循环；实验由人来做 | ❔ 未记录 | 🔄 对象级 —— 重新提议迭代 |
| Zochi | 🔒 闭源，内部机制仅有文档 | 🟡 声称完整闭环 —— 未经验证 | ❌ 无可检查内容 | ❔ 未记录 |
| FunSearch | 🔒 闭源 —— Nature 论文 | ❌ 仅搜索发现 | ❔ 未记录 | 🔄 对象级 —— 演化程序岛 |
| ResearchAgent | 🧪 无公开发布 | ❌ 仅停留在构思阶段 | 🟡 只有产物 — 描述了约 5 轮打分 | 🔄 对象级 — 由评审打分的迭代优化 |

验证

健全性检查：让 LLM 跑一遍验证测试集（每个技能的 scripts/test_*.py），期望退出码为 0；或者让 LLM 解释系统如何运作，再拿解释对照文档核对。测试集只用 Python 标准库，并且会自我删除：test_add_epic.py、test_add_issue.py 和 test_add_comment.py 会驱动真实的技能脚本，针对一个临时 epic 运行，该 epic 在退出时自行删除（除非传入 --keep）；test_lifecycle.py 还会强制检查跨领域的约束（发现根目录、git 卫生、目录布局，以及 .md 文件只允许 ASCII 的规则）。research-project-epic-manager 技能自带的测试集是 scripts/validate_execution.py 和 scripts/validate_protocol.py。

贡献

见 CONTRIBUTING.md：MIT 协议、按字段集体署名、匿名追踪器评论与常规 git 历史的区别、面向智能体的文件只允许 ASCII 的规则，以及如何验证一处改动。