独立开发者的 Harness：从 Karpathy 的实验室到你的 Mac Mini

Harness系列： AI早知道 · 第五篇

LOOP FOREVER.

Karpathy 在 autoresearch 的 program.md 里写了这两个词。不是比喻，是字面意思。

"一旦实验循环开始，绝对不要停下来询问人类是否应该继续。人类可能在睡觉，或者离开了电脑，并期望你无限期地继续工作，直到被手动停止。你是完全自主的。如果你用尽了想法，就更加努力地思考。"

这不是某个大型工程团队的内部工具，是 Karpathy 2026 年 3 月在 GitHub 上公开的实验项目，任何人都可以在一台带 GPU 的机器上复现。我在自己的 Mac Mini 4 上跑了一整晚。

那晚，agent 在我睡觉的时候跑了 80+ 轮实验，每一轮修改神经网络架构、训练五分钟、读结果、决定保留还是回滚。它没有问过我任何问题。

这让我重新思考一个问题：什么是最小但完整的 harness？

autoresearch：harness 的最小可行版本

autoresearch 的结构只有三个文件：

运作逻辑是一个闭环：agent 读 program.md → 修改 train.py → 跑 5 分钟训练 → 看 val_bpb → 降了就 git commit 保留，升了就 git reset 回滚 → 更新实验日志 → 进入下一轮。

这套结构的精妙不在于任何一个文件，而在于三个文件之间的角色分离：

• program.md 是 agent 的宪法。它定义了目标（降低 val_bpb）、边界（只能改 train.py）、预算（每次训练只跑 5 分钟）、以及记忆（历史实验日志）。这是人类唯一需要维护的东西。

• prepare.py 是不可作弊的评估者。 val_bpb 是一个数字，没有歧义，不需要人工判断。这是 autoresearch 能完全自主运行的根本原因——反馈是机械的，不依赖人的参与。

• train.py 是受约束的行动空间。 Agent 想怎么改就怎么改，但改不了边界之外的任何东西。沙盒不是在束缚 agent，而是在保护整个系统的稳定性。

Karpathy 的 program.md 里有一条"简洁性准则"：

"在其他条件相同的情况下，越简单越好。移除某些东西并获得相同或更好的结果，是一个伟大的成果——这是简化上的胜利。"

这不只是针对神经网络架构的建议，也是 harness 设计的原则。

我的验证：Mac Mini 4 + pi + tmux

autoresearch 在 H100 上一晚大约能跑 100 轮。我用 Mac Mini 4 M4 跑了一晚，结果是 80+ 轮——不完全一样，但对于一台 ¥8000 的桌面机器来说，完全可以接受。

工具链组合：

pi-coding-agent 作为 agent 的运行环境。它是 Mario Zechner 写的极简终端 agent（篇4 里详细介绍过），核心优势是模型切换自由：

pi /model gemini-3-pro-preview   # 复杂推理，超大 context
pi /model claude-sonnet-4-6      # 代码审查，质量优先
pi /model gemini-2.0-flash       # 快速验证，低成本

autoresearch 的实验日志会越来越长，Gemini 3 Pro 的 200 万 token context window 在这里特别有价值——它不会在几十轮实验后开始遗忘早期踩过的坑。

SSH + tmux 构建三窗口驾驶舱：

┌────────────────────────────────────────────────────┐
│  Window 0: pi agent                                │
│  > Reading program.md...                           │
│  > Modifying train.py: trying Grouped-Query Attn  │
│  > Running experiment #42...                       │
├────────────────────────────────────────────────────┤
│  Window 1: asitop (M4 芯片监控)                    │
│  CPU: 34%  GPU: 87%  ANE: 12%  Mem: 14.2/32GB    │
├────────────────────────────────────────────────────┤
│  Window 2: tail -f results.csv                     │
│  42, 2.7912, IMPROVED ✓                           │
│  43, 2.8103, REVERTED ✗                           │
└────────────────────────────────────────────────────┘

窗口 0 是 agent 的工作区，窗口 1 监控芯片负载防止内存泄漏，窗口 2 实时看 val_bpb 的变化曲线。tmux 的 detach/attach 让我可以断开 SSH、关上笔记本，早上起来 attach 回去，看 agent 在我睡觉时做了什么。

一晚 80 轮，早晨的 results.csv 是这套 harness 的产物。

问题在哪里：日常开发没有 val_bpb

早上 attach 回 tmux，看了一眼 results.csv，再回去看自己的产品代码——那种落差感很具体。

autoresearch 的 agent 知道自己在做什么：降低 val_bpb。每一轮都有一个数字告诉它做对了还是做错了。而我在做 Talk-with-Buffett 的时候，agent 生成了一段回答，它不知道这段回答有没有准确召回相关内容，不知道有没有用巴菲特的语气而不是通用 LLM 的腔调，不知道用户满不满意。没有 val_bpb，它只能依赖统计规律，有时候对，有时候不对。

autoresearch 的 harness 能完全自主，依赖一个前提：评估者是机械的。

val_bpb 是个数字，没有歧义。但产品功能做得好不好，没有等价的数字——UI 好不好看，API 设计合不合理，代码是否可维护，这些都需要人的判断。

这不是 autoresearch 的问题，是适用范围的边界。当评估者无法机械化，你就需要设计评估的结构。

Garry Tan 的 gstack，是我见过的对这个问题最直接的回答。

Garry Tan 的解法：把 Claude Code 变成专家团队

Garry Tan 是 YC 的现任 CEO。他开源了自己的 Claude Code 配置——gstack，8 个 skill，每个 skill 对应一个明确的认知模式：

他在 gstack 的 README 里说：

"我不想要 AI 编程工具停留在一个模糊的通用模式里。规划不是审查，审查不是发布，创始人品味不是工程严谨性。如果你把这些混在一起，通常会得到一种四者皆平庸的混合物。我想要明确的档位。"

这句话是关键：明确的档位，不是一套流程。

以 /plan-ceo-review 为例。Garry 描述的是"Brian Chesky 模式"——不是执行任务，而是反问问题是否正确。他举的例子是卖家照片上传功能：一个弱助手会直接加个文件选择器。CEO 模式会问：上传照片这个功能本身对吗？真正需要的是帮卖家创建一个实际能卖出去的商品列表——从照片识别产品、抓取规格和定价参考、起草标题和描述——这是完全不同的产品。

/plan-ceo-review 是在 agent 动手之前，先质疑方向。这是 autoresearch 里 program.md 的角色——只是 program.md 是静态文件，而 /plan-ceo-review 是动态的对话过程。

/browse 则解决了另一个问题：agent 对自己的输出是半盲的。 它能写代码，但看不到运行起来的 UI。/browse 是一个编译好的 Chromium 控制二进制，agent 可以用它真实地打开浏览器、点击按钮、截图、检查 console 报错。Garry 的描述是 18 个工具调用、60 秒，完成一次完整的 QA pass——他自己没有打开浏览器。

gstack 的本质是：把"agent 该以什么方式思考"这件事，从隐性的期望变成了显性的 skill。

但 gstack 解决了评估结构的问题，没有解决另一个问题：session 切换之后，agent 失忆了。

用 /plan-ceo-review 做完方向确认，用 /plan-eng-review 设计完架构，开一个新 session 开始写代码——agent 不记得刚才决定的任何事情。你要么把上一个 session 的结论手动粘进去，要么重新解释一遍，要么发现它在新 session 里走了一条跟之前讨论完全不同的路。autoresearch 用 program.md 的实验日志解决了这个问题——每一轮的结果都写进去，下一轮接着读。日常开发需要同样的机制，但更复杂，因为状态更多样。

OpenClaw 的三层记忆：让 agent 不失忆

OpenClaw 的三层记忆系统是我目前用得最顺手的方案：

热记忆（MEMORY.md，上限 8KB）： 每次 session 开始自动加载。只放最核心的东西：当前项目状态、关键技术决策、你不想 agent 自作主张的偏好。8KB 是硬约束，逼着你做取舍——什么信息值得占用每次 session 的起始 context？

暖记忆（自动同步，按日期归档）： Micro Sync 每 3 小时扫描一次对话，提取决策细节，写进 memory/YYYY-MM-DD.md。Daily Wrap-Up 每天凌晨整合一次，更新热记忆里相关条目。这解决了"刚才决定的事，下个 session 就忘了"的问题。

冷记忆（第二大脑，按需检索）： 所有历史设计文档、深度研究、参考资料放这里。不主动加载，只在需要时通过语义+关键字混合检索调出来。类似 autoresearch 里 program.md 的历史实验日志，但是结构化的、可检索的。

三层系统的设计逻辑和 autoresearch 的 program.md 是同一个思路：把状态显式地放在 agent 能访问到的地方，按优先级分层，不让它在 context 里随机漂浮。

三套逻辑的共同点

Karpathy 的 autoresearch、Garry Tan 的 gstack、OpenClaw 的三层记忆——三套看起来完全不同的实践，底层逻辑是一样的：

目标清晰。 program.md 里的 val_bpb，gstack 里的 /plan-ceo-review 先确认方向，MEMORY.md 里的项目状态——都是在给 agent 一个不模糊的参照系。

行动有边界。 autoresearch 只允许改 train.py，gstack 的每个 skill 只对应一个认知模式，OpenClaw 的热记忆只放 8KB——边界不是限制，是让 agent 能快速移动而不失控的护栏。

反馈是闭环的。 val_bpb 是机械评估，/browse 让 agent 能看到自己的 UI 输出，暖记忆捕捉每次决策——反馈必须回到系统里，不能只是人看了一眼就结束。

记忆是持久的。 program.md 的实验日志、memory/ 目录的日期文件——agent 的工作必须留下可追溯的痕迹，下一个 session 才能真正接上。

这四个条件，autoresearch 用三个文件都满足了。日常开发需要 gstack 补充评估结构，OpenClaw 补充记忆持久性。

从这里开始

如果你有一台 Mac Mini，或者任何一台长时间开机的机器：

• 跑一次 autoresearch。让 agent 运行一整晚，早上看 results.csv。不是为了神经网络研究，是为了感受一个 LOOP FOREVER 的 harness 是什么感觉。

• 装上 gstack，在你的下一个功能之前用一次 /plan-ceo-review。看它是否把你的需求问题翻转了。

• 设置一个 MEMORY.md，把你这周做的三个最重要决策写进去。下周开新 session 的时候，看它有没有帮 agent 更快进入状态。

这不是三个独立的工具，是同一个 harness 哲学的三种实现。

下一篇：我们的判断——Harness 工程的下一步在哪里？