560 lines
23 KiB
Markdown
560 lines
23 KiB
Markdown
# 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"
|
||
|
||
|