# 1

待评估项目：`https://github.com/karpathy/autoresearch`

我最近对我以前的知识库做了以下划分：

| 项目 | 定位 | 保存什么 | 不保存什么 |
| --- | --- | --- | --- |
| `knowledge-vault` | 长期知识源、过程记忆和人类可读规则层 | 日记、文章讨论、Agent / Prompt / Committee 打造过程、正式文章、资料源、面向人的模型文档、提示词归档、本地知识加工规则 | 不承载完整文章生产流水线；不作为 CCPE canonical 资产源码仓；不保存具体开发项目的执行现场 |
| `ccpe-system` | AI 资产工程和协议工作区 | Agent、Skill、Runtime、Model Card、Model Index、committee、运行治理、外部工具依赖登记 | 不保存完整个人知识库；不保存 automation skill 的实现源码；不保存普通项目执行材料 |
| `writing-workbench` | 已决定写作后的文章项目现场 | 文章项目计划、材料压缩稿、source map、提纲、评审、正文、润色、metadata、决策记录 | 不接管开放观点讨论；不保存长期知识全集；不默认自动化深度创作 |
| `video-workbench` | 深度文章降维输出和多模态生产现场 | 剧集规划、破题提案、视频总纲、分镜、口播稿、生图提示词、TTS 清单、素材清单、剪辑清单 | 不替代深度文章创作；不保存长期模型源头；不承载 CCPE 资产工程 |
| `skills-vault` | 可测试、可安装、可复用 automation skill 源码仓 | `SKILL.md`、scripts、tests、fixtures、examples、安装说明、迁移记录 | 不保存 CCPE Agent / Runtime / Model Card；不保存业务项目材料；不定义业务目标 |
| `work-projects` | 具体开发工作和工程项目现场 | 产品、客户、实验性开发项目的代码、需求、任务记录、交付材料、项目级 handoff | 不作为长期知识库；不作为通用工具源码仓；不作为 CCPE 协议源头 |

那么这个项目对我的科研工作来说，有什么价值？
若有价值，和哪个库做结合，还是需要启动新的科研库？

# GitHub 项目评估：karpathy/autoresearch

## 1. 快速结论

**结论：有价值，但不是作为“直接科研工具”使用；更适合作为你的“科研 Agent 实验协议样板”。**

一句话判断：`autoresearch` 的核心价值不是帮你训练一个小 GPT，而是展示了一种很干净的 **Agent 自主实验循环**：限定可修改文件、固定评估指标、固定时间预算、自动运行实验、用 Git 提交和 reset 形成可追溯研究轨迹。项目 README 明确说它让 AI agent 修改 `train.py`、训练 5 分钟、检查指标是否提升、保留或丢弃修改，并且人类主要编辑 `program.md` 这类研究组织指令，而不是直接改 Python 文件。([GitHub][1])

**推荐动作：**

* **主动作：纳入 `ccpe-system` + `skills-vault`，不要一开始新建科研库。**
* **次动作：在 `work-projects` 里开一个小型试验项目，用来验证你能否把它改造成“通用科研实验循环”。**
* **不建议做的事：不要把原仓库原样当作你的科研基础设施，也不要在 RTX 3070 8GB 上直接跑默认配置。**

你的长期关注点是 AI Skill、Agent、自动化工作流、论文/知识管理/写作、本地部署、长期系统融合和架构借鉴；这个项目最命中的是 **Agent / 自动化工作流 / 架构借鉴 / 科研过程治理**，而不是知识库内容管理本身。

---

## 2. 它对你科研工作的真实价值

我会把它的价值分成三层。

### 第一层：科研自动化范式价值，高

它把“科研”压缩成一个可自动化循环：

> 假设 → 改代码 → 跑实验 → 读指标 → 记录结果 → 保留/回滚 → 继续搜索。

这对你非常有价值，因为它不是一个普通 Agent demo，而是一个 **可操作的研究组织协议**。README 里说仓库刻意保持很小，真正重要的是 `prepare.py`、`train.py`、`program.md` 三个文件：`prepare.py` 固定数据、评估和工具，`train.py` 是 agent 唯一可修改的实验对象，`program.md` 是人类写给 agent 的研究组织指令。([GitHub][1])

对你的科研工作来说，它可以转译成：

* **固定材料层**：数据、文献、benchmark、评审标准不让 agent 随便改。
* **可变实验层**：允许 agent 改 prompt、pipeline、检索策略、摘要策略、分类器、评估脚本中的局部策略。
* **评估层**：用明确指标决定 keep / discard。
* **研究轨迹层**：用 Git commit、日志、结果表记录每次尝试。

这比“让 Agent 帮我研究一下某个主题”可靠得多。

### 第二层：Skill / Agent 资产工程价值，很高

README 甚至直接说 `program.md` 本质上是一个“super lightweight skill”。([GitHub][1]) 这对你的 `skills-vault` 很关键：它说明一个 Skill 不一定是复杂框架，也可以是一个 **带约束、带循环、带日志格式、带失败处理规则的 Markdown 研究程序**。

你可以从它抽象出一个通用 Skill：

```text
research-ratchet-loop/
  SKILL.md
  scripts/
    run_trial.py
    parse_result.py
    compare_result.py
    rollback_or_keep.py
  fixtures/
    sample_task/
  examples/
    prompt-optimization/
    rag-eval/
    paper-screening/
    writing-outline-eval/
  tests/
```

这个 Skill 不必训练模型，而是服务于你的真实科研场景：

* 自动优化论文筛选规则；
* 自动比较不同 RAG 检索策略；
* 自动改写摘要压缩 pipeline；
* 自动优化写作提纲评审 rubric；
* 自动比较 Agent committee 的投票协议；
* 自动迭代 prompt、model card、runtime policy。

### 第三层：科研工程治理价值，高

`program.md` 的实验循环要求 agent 创建分支、只改 `train.py`、每次 commit、运行 `uv run train.py`、把结果写进 `results.tsv`，指标变好才保留，否则 reset。([GitHub][2]) 这对你最大的启发是：**科研 Agent 必须有边界、有审计、有回滚、有实验日志，而不是无限制地“自由探索”。**

这可以直接进入你的 `ccpe-system`，成为一种协议资产，例如：

```text
ccpe-system/
  protocols/
    autonomous-research-loop/
      protocol.md
      artifact-contract.md
      eval-contract.md
      safety-boundaries.md
      result-schema.md
      model-card.md
```

---

## 3. 它不适合直接承担什么

这个项目不适合直接变成你的“科研知识库”。

原因很简单：它不是文献管理工具，不是知识库，不是写作流水线，也不是通用研究平台。它的当前实例是一个 **小型 LLM 训练实验场**。README 写得很清楚：它使用简化版 single-GPU `nanochat` 训练设置，agent 修改训练代码并以 `val_bpb` 作为指标。([GitHub][1])

所以它不应该直接进入：

* `knowledge-vault` 的主体内容层；
* `writing-workbench` 的文章生产现场；
* `video-workbench`；
* `ccpe-system` 的 Agent 实现源码区；
* `skills-vault` 之外的通用源码区。

它更像是一个 **科研自动化协议种子**，不是你的科研材料仓。

---

## 4. 和你现有六个库的结合方式

| 你的库                 |    是否结合 | 放什么                                                                                         | 不放什么                     |
| ------------------- | ------: | ------------------------------------------------------------------------------------------- | ------------------------ |
| `knowledge-vault`   |    轻度结合 | 读后笔记、范式分析、对“自律科研循环”的观点、与论文/知识管理的关系                                                          | 不放完整源码、不放实验执行现场          |
| `ccpe-system`       | **强结合** | Autonomous Research Loop 协议、Agent 权限边界、eval contract、artifact contract、result schema、运行治理规则 | 不放具体 Skill 实现源码          |
| `writing-workbench` |    条件结合 | 当你决定写文章时，放文章项目：选题、提纲、材料压缩稿、评审记录                                                             | 不作为 autoresearch 的协议或代码仓 |
| `video-workbench`   |    暂不结合 | 只有在你把文章降维成视频时才用                                                                             | 不需要现在接入                  |
| `skills-vault`      | **强结合** | `autoresearch-loop` / `research-ratchet` Skill 的 `SKILL.md`、scripts、tests、examples          | 不放 CCPE canonical 协议源头   |
| `work-projects`     |    中度结合 | 具体试跑、fork、改造成通用实验框架、Windows 兼容性验证、demo 项目现场                                                 | 不放长期知识源和通用 Skill 源码      |

我的建议是：

**不要立即新建一个大的“科研库”。**

先用现有体系拆分：

1. `ccpe-system` 保存它抽象出来的 **科研 Agent 协议**；
2. `skills-vault` 保存你实现出来的 **可复用 automation skill**；
3. `work-projects` 保存一次具体验证项目；
4. `knowledge-vault` 保存你的理解、反思和后续文章素材。

只有当你开始长期积累大量“可复现实验任务、benchmark、paper eval、agent eval、结果数据库”时，才需要新建一个专门科研库。

---

## 5. 是否需要启动新的科研库？

### 当前结论：暂时不需要。

现在新建科研库会过早。因为你目前真正需要沉淀的不是“科研材料全集”，而是三类东西：

1. **协议**：什么叫一个合格的 Autonomous Research Loop；
2. **Skill**：如何把这个 loop 做成可复用工具；
3. **试验现场**：它在你的任务上是否真的有效。

这三类已经分别有归属：

```text
ccpe-system      -> 协议与治理
skills-vault     -> 可复用 Skill 实现
work-projects    -> 具体试跑和工程实验
knowledge-vault  -> 人类可读理解与反思
```

### 什么时候才需要新建科研库？

当你出现以下情况，再新建：

```text
research-lab/
  benchmarks/
  tasks/
  evals/
  experiment-runs/
  datasets/
  papers/
  result-ledgers/
  reproducibility/
```

触发条件可以设为：

* 你已经有 3 个以上长期科研实验主题；
* 每个主题都有独立 benchmark / dataset / eval；
* 结果需要跨项目比较；
* `work-projects` 里出现大量实验现场，已经不只是“某个开发项目”；
* `ccpe-system` 的协议层和 `skills-vault` 的实现层都无法承载实验数据。

在那之前，新库会增加边界混乱。

---

## 6. 推荐的落地结构

我建议你这样落地。

### A. `knowledge-vault`

保存一篇人类可读分析：

```text
knowledge-vault/
  notes/
    autoresearch-as-research-ratchet.md
```

内容包括：

* autoresearch 的一句话定位；
* 它和普通 Agent runner 的区别；
* 为什么 Git history 可以成为研究轨迹；
* 为什么固定 eval 是核心；
* 为什么 “只允许修改一个文件” 是安全边界；
* 它对论文阅读、知识管理、写作自动化的启发。

### B. `ccpe-system`

保存协议资产：

```text
ccpe-system/
  protocols/
    autonomous-research-loop/
      README.md
      protocol.md
      eval-contract.md
      artifact-contract.md
      git-ratchet-policy.md
      safety-boundaries.md
      result-schema.md
      failure-policy.md
```

这里不要放具体脚本。这里定义“什么算一个合格的科研自动化循环”。

核心抽象可以是：

```text
ResearchLoop = Context + MutableTarget + Evaluator + Budget + Ledger + Ratchet
```

对应到 `autoresearch`：

| 抽象            | autoresearch 中的实现   |
| ------------- | ------------------- |
| Context       | `program.md`        |
| MutableTarget | `train.py`          |
| Fixed Assets  | `prepare.py`        |
| Evaluator     | `evaluate_bpb`      |
| Budget        | 5 分钟训练时间            |
| Ledger        | `results.tsv`       |
| Ratchet       | 指标变好保留，否则 git reset |

README 明确说训练运行固定 5 分钟，指标是 `val_bpb`，越低越好。([GitHub][1])

### C. `skills-vault`

做一个真正可复用 Skill：

```text
skills-vault/
  autoresearch-loop/
    SKILL.md
    scripts/
      init_run.py
      run_trial.py
      parse_metrics.py
      decide_keep_or_discard.py
      summarize_results.py
    tests/
    fixtures/
    examples/
      prompt_optimization/
      rag_retrieval_eval/
      writing_outline_eval/
      paper_screening_eval/
```

这个 Skill 的目标不是训练 LLM，而是把“固定 eval + 自主修改 + 结果账本 + 回滚”迁移到你的任务。

例如：

| 场景              | MutableTarget           | Evaluator                    |
| --------------- | ----------------------- | ---------------------------- |
| Prompt 优化       | `prompt.md`             | 测试集得分                        |
| RAG 策略优化        | `retrieval_config.yaml` | recall / answer faithfulness |
| 论文筛选            | `screening_rules.md`    | 人工标注集 F1                     |
| 写作提纲            | `outline.md`            | rubric 评分                    |
| Agent committee | `committee_policy.md`   | 任务通过率 / 成本 / 延迟              |
| Skill 改进        | `SKILL.md`              | 单元测试 + fixture 通过率           |

### D. `work-projects`

开一个短期验证项目：

```text
work-projects/
  autoresearch-loop-poc/
    upstream-notes/
    repo-clone/
    experiments/
    reports/
    codex-handoff.md
```

这个项目只做一件事：验证 `autoresearch` 的模式能不能迁移到你的实际科研工作流。

建议第一个 PoC 不要碰 GPU 训练，选一个低成本任务：

```text
任务：自动优化“论文筛选规则”
输入：20-50 篇论文标题/摘要 + 你人工标注的 keep/discard
可修改文件：screening_rules.md
评估脚本：eval_screening.py
指标：F1 或 balanced accuracy
预算：每轮最多 2 分钟
结果表：results.tsv
保留规则：指标提升才保留
```

这样更贴近你的科研，而不是陷入 CUDA、torch、显存调参。

---

## 7. 运行环境初筛

### Windows 11 本地

**是否适合原样运行：低。**

README 写明要求 single NVIDIA GPU，测试环境是 H100、Python 3.10+ 和 `uv`。([GitHub][1]) `pyproject.toml` 固定了 `torch==2.9.1`，并使用 PyTorch CUDA 12.8 wheel index；依赖还包括 `kernels`、`rustbpe`、`tiktoken`、`pyarrow`、`pandas`、`numpy`、`matplotlib` 等。([GitHub][3])

你的 RTX 3070 8GB **不适合默认配置**。`program.md` 示例输出里有 `peak_vram_mb: 45060.2` 这种 40GB+ 显存级别的示例，虽然它只是示例输出，但足以说明默认目标不是 8GB 消费卡。([GitHub][2]) README 也专门给小机器建议：换低熵数据集、降低 vocab size、降低 `MAX_SEQ_LEN`、降低 `EVAL_TOKENS`、降低 `DEPTH`、改 attention pattern、降低 batch size。([GitHub][1])

**Windows 本地推荐动作：**

* 不建议直接跑主仓库默认训练；
* 可以阅读源码；
* 可以参考 Windows fork；
* 更推荐把它的 loop 改成 CPU/API 任务，例如 prompt eval、RAG eval、论文筛选 eval。

### CentOS 远程

**是否适合原样运行：低。**

你的远程机无 GPU，而该项目当前代码要求 CUDA。README 说目前需要 single NVIDIA GPU；`prepare.py` 里 dataloader 和 evaluation 明确使用 `device="cuda"`。([GitHub][1]) ([GitHub][4])

**CentOS 远程推荐动作：**

* 不适合部署原始训练项目；
* 适合部署你改造后的 `research-ratchet` 服务；
* 可以作为 OpenClaw / Dify 的后端自动化节点；
* 任务应选择 API-based 或 CPU-based eval，不要选择 GPU 训练。

---

## 8. 风险判断

### 维护和成熟度

仓库当前非常小，GitHub 页面显示只有几十个 commits，没有发布 release。([GitHub][1]) 这说明它更像一个研究范式 demo，而不是稳定软件产品。

### 安装风险

主要风险来自：

* CUDA / PyTorch 版本；
* `torch==2.9.1` 与 CUDA 12.8 wheel；
* Windows 下 GPU kernel / package 兼容；
* `rustbpe` 等依赖安装；
* Hugging Face 数据下载；
* 默认参数显存需求过高。

### 安全风险

它的核心模式是让 agent 修改代码、运行训练、提交和 reset。这个模式迁移到你的系统时必须加边界：

* 禁止 agent 修改 eval；
* 禁止 agent 修改数据集标签；
* 禁止安装新依赖，除非人工批准；
* 禁止读取敏感目录；
* 禁止访问 API key、cookie、私钥；
* 所有运行必须在临时分支或沙盒目录；
* 日志中要避免泄露路径、密钥和私有材料。

`program.md` 里也明确限制 agent 只能改 `train.py`，不能改 `prepare.py`、不能安装新包、不能改评估 harness。([GitHub][2]) 这正是你应该学习的部分。

### 科研方法风险

这个项目会让人误以为“LLM agent 自主搜索一定优于传统优化”。这点要谨慎。已有一篇针对 autoresearch 的 HPO 研究把它作为 testbed，结论是固定搜索空间里 classical HPO 如 CMA-ES、TPE 表现更强；LLM 直接编辑代码的开放搜索更有竞争力，但可靠性、OOM 控制和状态跟踪仍是关键问题。([arXiv][5])

对你的启发是：
**不要只做纯 LLM 自主试错。更好的方向是 LLM + 显式实验状态 + 传统搜索/规则/评估器。**

---

## 9. 评分表

| 维度                     | 分数 | 判断                                      |
| ---------------------- | -: | --------------------------------------- |
| 项目定位清晰度                |  5 | 极清晰：小型 single-GPU LLM 训练实验 + Agent 自动迭代 |
| Skill / Agent / 自动化相关性 |  5 | `program.md` 本身就是轻量 Skill 样板            |
| 长期系统融合潜力               |  4 | 适合抽象成协议和 Skill，不适合原样纳入                  |
| 论文 / 知识管理 / 写作价值       |  3 | 间接价值高，直接价值中等                            |
| Windows 本地可行性          |  2 | 原样训练不友好，8GB 显存需大改                       |
| CentOS 远程可行性           |  1 | 无 GPU，不适合原项目                            |
| 依赖复杂度友好度               |  3 | 仓库小，但 CUDA/PyTorch/GPU 门槛高              |
| 工程成熟度                  |  3 | 范式清楚，但不是稳定平台                            |
| 架构借鉴价值                 |  5 | 很适合借鉴为科研 Agent loop                     |
| 立即试跑价值                 |  2 | 不建议原样试跑；建议改造成低成本 PoC                    |

**综合判断：4/5。**

不是因为它能直接帮你科研，而是因为它很适合作为你自己的 **科研自动化协议母版**。

---

## 10. 最建议你怎么处理

### 建议进入你的系统，但分三处进入

#### 1. `ccpe-system`：收为协议

命名建议：

```text
Autonomous Research Ratchet Protocol
```

沉淀重点：

* agent 权限边界；
* 固定 eval；
* mutable target；
* Git ratchet；
* result ledger；
* failure policy；
* cost/time budget；
* human review surface。

#### 2. `skills-vault`：做成 Skill

命名建议：

```text
autoresearch-loop
```

或者更贴近你自己的命名：

```text
research-ratchet-skill
```

Skill 的核心不是“训练模型”，而是：

```text
在一个有明确评估函数的任务中，让 Agent 反复提出修改、运行评估、记录结果、只保留变好的改动。
```

#### 3. `work-projects`：开 PoC

命名建议：

```text
work-projects/research-ratchet-poc
```

第一个 PoC 我建议选：

```text
论文筛选规则自动优化
```

原因是它最贴近你的科研，又不需要 GPU。

---

## 11. 是否交给 Codex / Claude Code 深挖

**判断：建议，但不是让 Codex 直接跑默认训练，而是让它抽象协议和生成 PoC。**

Codex 任务应该是：

```text
请检查 https://github.com/karpathy/autoresearch

目标不是原样训练模型，而是抽象出一个可迁移到我的科研工作流的 autonomous research loop。

请重点输出：

1. 仓库的最小核心机制：
   - program.md 如何约束 agent
   - train.py 为什么是唯一 mutable target
   - prepare.py 如何承担 fixed assets + eval harness
   - results.tsv / git commit / git reset 如何构成 ratchet loop

2. 抽象协议：
   - Context
   - MutableTarget
   - FixedAssets
   - Evaluator
   - Budget
   - Ledger
   - Keep/Discard Policy
   - Failure Policy
   - Human Review Boundary

3. 迁移方案：
   - prompt optimization
   - RAG retrieval eval
   - paper screening eval
   - writing outline eval
   - Skill improvement eval

4. 为 skills-vault 生成一个 research-ratchet-skill 草案：
   - SKILL.md
   - scripts/run_trial.py
   - scripts/parse_metrics.py
   - scripts/decide.py
   - examples/paper_screening_eval
   - tests

5. 不要要求 GPU。
6. 不要修改我的真实知识库。
7. 不要读取密钥、cookie、token。
8. 所有实验必须在临时目录和临时 git 分支里执行。
```

---

## 12. 项目卡片

* **一句话定位：** 一个用 AI Agent 自动修改训练代码、固定时间跑实验、按指标保留或回滚的 autonomous research loop 样板。
* **适用场景：** Agent 自主实验、prompt/RAG/Skill/论文筛选规则优化、科研流程治理、自动化实验账本。
* **不适用场景：** 直接做个人知识库、直接写文章、无 GPU 原样训练、本地 8GB 显存默认配置试跑。
* **对你的价值：** 高。它可以成为你 `ccpe-system` 中的科研协议，以及 `skills-vault` 中的可复用 automation skill 母版。
* **运行要求：** 原项目要求 Python 3.10+、uv、single NVIDIA GPU、PyTorch CUDA 12.8 相关依赖；默认更接近 H100 环境。([GitHub][1])
* **主要风险：** CUDA/显存门槛高；原仓库不是通用科研平台；Agent 执行代码有安全边界风险；纯 LLM 搜索不一定优于传统优化。
* **推荐动作：** 收藏 + 阅读源码 + 抽象协议 + 做低成本 PoC。
* **是否进入 Codex 深挖：** 是，但目标是“协议抽象和 Skill 化”，不是“原样部署”。
* **是否需要新科研库：** 现在不需要。先放入 `ccpe-system`、`skills-vault`、`work-projects` 和 `knowledge-vault` 各自边界内；等你有多个长期 benchmark / eval / experiment-run 需要统一管理时，再启动独立 `research-lab`。

[1]: https://github.com/karpathy/autoresearch?utm_source=chatgpt.com "GitHub - karpathy/autoresearch: AI agents running research on single-GPU nanochat training automatically · GitHub"
[2]: https://raw.githubusercontent.com/karpathy/autoresearch/master/program.md?utm_source=chatgpt.com "raw.githubusercontent.com"
[3]: https://raw.githubusercontent.com/karpathy/autoresearch/master/pyproject.toml?utm_source=chatgpt.com "raw.githubusercontent.com"
[4]: https://raw.githubusercontent.com/karpathy/autoresearch/master/prepare.py?utm_source=chatgpt.com "raw.githubusercontent.com"
[5]: https://arxiv.org/abs/2603.24647?utm_source=chatgpt.com "Can LLMs Beat Classical Hyperparameter Optimization Algorithms? A Study on autoresearch"