23 KiB
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)
推荐动作：
- 主动作：纳入
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)
对你的科研工作来说，它可以转译成：
- 固定材料层：数据、文献、benchmark、评审标准不让 agent 随便改。
- 可变实验层：允许 agent 改 prompt、pipeline、检索策略、摘要策略、分类器、评估脚本中的局部策略。
- 评估层：用明确指标决定 keep / discard。
- 研究轨迹层：用 Git commit、日志、结果表记录每次尝试。
这比“让 Agent 帮我研究一下某个主题”可靠得多。
第二层：Skill / Agent 资产工程价值，很高
README 甚至直接说 program.md 本质上是一个“super lightweight skill”。(GitHub) 这对你的 skills-vault 很关键：它说明一个 Skill 不一定是复杂框架，也可以是一个 带约束、带循环、带日志格式、带失败处理规则的 Markdown 研究程序。
你可以从它抽象出一个通用 Skill：
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) 这对你最大的启发是：科研 Agent 必须有边界、有审计、有回滚、有实验日志，而不是无限制地“自由探索”。
这可以直接进入你的 ccpe-system，成为一种协议资产，例如：
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)
所以它不应该直接进入：
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 源码 |
我的建议是：
不要立即新建一个大的“科研库”。
先用现有体系拆分：
ccpe-system保存它抽象出来的 科研 Agent 协议；skills-vault保存你实现出来的 可复用 automation skill；work-projects保存一次具体验证项目；knowledge-vault保存你的理解、反思和后续文章素材。
只有当你开始长期积累大量“可复现实验任务、benchmark、paper eval、agent eval、结果数据库”时，才需要新建一个专门科研库。
5. 是否需要启动新的科研库？
当前结论：暂时不需要。
现在新建科研库会过早。因为你目前真正需要沉淀的不是“科研材料全集”，而是三类东西：
- 协议：什么叫一个合格的 Autonomous Research Loop；
- Skill：如何把这个 loop 做成可复用工具；
- 试验现场：它在你的任务上是否真的有效。
这三类已经分别有归属：
ccpe-system -> 协议与治理
skills-vault -> 可复用 Skill 实现
work-projects -> 具体试跑和工程实验
knowledge-vault -> 人类可读理解与反思
什么时候才需要新建科研库？
当你出现以下情况，再新建：
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
保存一篇人类可读分析：
knowledge-vault/
notes/
autoresearch-as-research-ratchet.md
内容包括：
- autoresearch 的一句话定位；
- 它和普通 Agent runner 的区别；
- 为什么 Git history 可以成为研究轨迹；
- 为什么固定 eval 是核心；
- 为什么 “只允许修改一个文件” 是安全边界；
- 它对论文阅读、知识管理、写作自动化的启发。
B. ccpe-system
保存协议资产：
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
这里不要放具体脚本。这里定义“什么算一个合格的科研自动化循环”。
核心抽象可以是：
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)
C. skills-vault
做一个真正可复用 Skill：
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
开一个短期验证项目：
work-projects/
autoresearch-loop-poc/
upstream-notes/
repo-clone/
experiments/
reports/
codex-handoff.md
这个项目只做一件事：验证 autoresearch 的模式能不能迁移到你的实际科研工作流。
建议第一个 PoC 不要碰 GPU 训练，选一个低成本任务：
任务：自动优化“论文筛选规则”
输入：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) pyproject.toml 固定了 torch==2.9.1，并使用 PyTorch CUDA 12.8 wheel index；依赖还包括 kernels、rustbpe、tiktoken、pyarrow、pandas、numpy、matplotlib 等。(GitHub)
你的 RTX 3070 8GB 不适合默认配置。program.md 示例输出里有 peak_vram_mb: 45060.2 这种 40GB+ 显存级别的示例，虽然它只是示例输出，但足以说明默认目标不是 8GB 消费卡。(GitHub) README 也专门给小机器建议：换低熵数据集、降低 vocab size、降低 MAX_SEQ_LEN、降低 EVAL_TOKENS、降低 DEPTH、改 attention pattern、降低 batch size。(GitHub)
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) (GitHub)
CentOS 远程推荐动作：
- 不适合部署原始训练项目；
- 适合部署你改造后的
research-ratchet服务； - 可以作为 OpenClaw / Dify 的后端自动化节点；
- 任务应选择 API-based 或 CPU-based eval，不要选择 GPU 训练。
8. 风险判断
维护和成熟度
仓库当前非常小，GitHub 页面显示只有几十个 commits，没有发布 release。(GitHub) 这说明它更像一个研究范式 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) 这正是你应该学习的部分。
科研方法风险
这个项目会让人误以为“LLM agent 自主搜索一定优于传统优化”。这点要谨慎。已有一篇针对 autoresearch 的 HPO 研究把它作为 testbed，结论是固定搜索空间里 classical HPO 如 CMA-ES、TPE 表现更强；LLM 直接编辑代码的开放搜索更有竞争力，但可靠性、OOM 控制和状态跟踪仍是关键问题。(arXiv)
对你的启发是： 不要只做纯 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：收为协议
命名建议：
Autonomous Research Ratchet Protocol
沉淀重点：
- agent 权限边界；
- 固定 eval；
- mutable target；
- Git ratchet；
- result ledger；
- failure policy；
- cost/time budget；
- human review surface。
2. skills-vault：做成 Skill
命名建议：
autoresearch-loop
或者更贴近你自己的命名：
research-ratchet-skill
Skill 的核心不是“训练模型”，而是：
在一个有明确评估函数的任务中，让 Agent 反复提出修改、运行评估、记录结果、只保留变好的改动。
3. work-projects：开 PoC
命名建议：
work-projects/research-ratchet-poc
第一个 PoC 我建议选：
论文筛选规则自动优化
原因是它最贴近你的科研，又不需要 GPU。
11. 是否交给 Codex / Claude Code 深挖
判断：建议，但不是让 Codex 直接跑默认训练，而是让它抽象协议和生成 PoC。
Codex 任务应该是：
请检查 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)
- 主要风险： CUDA/显存门槛高；原仓库不是通用科研平台；Agent 执行代码有安全边界风险；纯 LLM 搜索不一定优于传统优化。
- 推荐动作： 收藏 + 阅读源码 + 抽象协议 + 做低成本 PoC。
- 是否进入 Codex 深挖： 是，但目标是“协议抽象和 Skill 化”，不是“原样部署”。
- 是否需要新科研库： 现在不需要。先放入
ccpe-system、skills-vault、work-projects和knowledge-vault各自边界内；等你有多个长期 benchmark / eval / experiment-run 需要统一管理时，再启动独立research-lab。