很多人第一次看到 Andrej Karpathy 那个 600 行的 Autoresearch 项目时第一反应跟我一样“就这600 行能做个啥”毕竟平时我们随手一个配置文件都不止这个量级。但如果你真正静下心来把这个项目从头到尾捋一遍会发现它根本不是一个“玩具”而是一套极其精巧的科研自动化闭环范本——用程序合成的方式把“手动调参”这个黑盒彻底打开让大模型不再只停留在“聊天生成文字”而是真正进入“写代码、跑实验、看结果、改方案”的完整科研循环。这篇文章我准备从架构设计、程序合成实现、科研闭环三个角度深度拆解再附上我自己复现过程中的实操步骤和踩坑实录。不管你是做 AI 应用开发、科研自动化还是单纯对 Karpathy 的工程风格感兴趣这篇都能给你一些可以直接抄作业的东西。1. 项目认知Autoresearch 到底想解决什么问题1.1 手动调参黑盒的困境先聊一个所有做过机器学习实验的人都会懂的场景你有一个模型效果不太行于是你开始调学习率、调 batch size、换 optimizer、改网络层数……每改一次参数就要重新训练一遍然后看 loss 曲线、看验证集指标凭经验判断下一步往哪个方向调。这个过程极其耗时而且结果好坏严重依赖个人经验。更麻烦的是这个调参过程本身是不可复现的。你今天调出来的最佳参数换一个人、换一台机器、换一个随机种子可能结果就完全不一样。整个科研过程变成了一个“黑盒”输入是数据和代码输出是论文里的那几个数字中间发生了什么很多时候连作者自己都说不清楚。Karpathy 做 Autoresearch 的初衷就是想用一套自动化的科研 agent 把这个黑盒打开。他的思路很直接既然大模型已经很擅长写代码了那就让模型自己去写实验代码、自己去跑、自己看结果、自己决定下一步怎么改。整个过程全部留痕每个决策都有据可查。1.2 程序合成让模型写程序让程序自己调自己这里有个关键概念需要先搞清楚——程序合成Program Synthesis。传统意义上我们写代码是人来写而程序合成是让机器根据你描述的需求和约束自动生成满足要求的程序代码。Karpathy 的项目里这个思路被发挥到了极致。整个 Autoresearch 的核心循环可以概括成四步生成代码 → 执行代码 → 观察结果 → 反馈修正。大模型不再直接给你一个答案而是给你一段可运行的代码这段代码会去调用工具、读取数据、执行计算然后返回真实的结果。如果结果不对模型根据反馈信息修改代码再次执行直到拿到满意的结果。这个设计的妙处在于它把“思考”和“验证”彻底分开了。模型负责思考生成算法思路和代码框架Python 解释器负责验证执行并返回真实结果两者通过标准输入输出进行交互。这样模型就不用靠“猜”来回答问题了而是靠“跑”来验证自己的假设。1.3 为什么必须是 600 行很多人会问为什么 Karpathy 要把这个项目控制在 600 行多写点功能不是更好吗这恰恰是这个项目最值得学习的地方。Karpathy 是 OpenAI 的创始成员之一后来去了 Tesla 做 Autopilot他的工程风格一贯是“极简但完整”。600 行听起来少但你仔细看会发现该有的东西全都有Agent 主循环、工具调用、代码生成器、执行沙箱、结果解析器、上下文管理、完整的 prompt 模板。每一个模块都被精简到不能再精简但没有一个是多余的。这种设计哲学其实是在提醒我们当你想要构建一个 AI Agent 时不需要一开始就上一个复杂的框架。先把核心闭环跑通用最少的代码实现最核心的价值后续再逐步迭代。600 行不是一个限制而是一个约束这个约束逼着设计者去思考什么是真正重要的。2. 架构拆解Agent 主循环与核心模块2.1 顶层循环LLM 裁决者 Python 执行者的双角色设计Autoresearch 的顶层架构非常清晰一句话就能概括大模型是决策者Python 是执行者。整个系统就是一个 while 循环循环体里做三件事让大模型生成下一步动作、执行动作、把执行结果回来给大模型。我之前自己写 AI Agent 的时候最容易犯的一个错误就是把所有逻辑都塞给大模型——让模型既负责思考又负责调用工具还要负责解析结果。这样做的后果是 prompt 越来越长模型越来越容易混乱而且出错了极难排查。Karpathy 的做法是反过来的。他把所有能确定性执行的逻辑全部下放到 Python 代码里文件读写、代码运行、结果解析、数据格式化处理这些都是用传统代码实现的。大模型只负责最核心的决策部分——判断当前状态、决定下一步做什么、生成代码。这种双角色设计的核心优势在于可靠性和可排查性。如果你是让大模型直接输出“结果”那它有可能胡说八道但如果让大模型输出一段代码代码执行后返回真实结果那你就有一个可验证的中间产物。下面是我根据这个思路整理的简化版顶层循环伪代码state initial_state() while not state.is_done(): action llm_think(state.get_context()) # 模型决策 if action.type run_code: result execute_code(action.code) # Python执行 state.add_observation(result) # 结果回流 elif action.type search: result search(action.query) # 工具调用 state.add_observation(result) else: state.mark_done(action.answer)这个循环看起来简单但真正执行起来会面临一个很现实的问题大模型生成的代码不一定能一次跑通。可能是语法错误、可能是 API 调用失败、可能是数据格式不匹配、可能是结果不符合预期。这些情况都需要通过反馈机制让模型自我修正。2.2 模块划分config、prompts、tools、codegen、executor虽然整个项目只有 600 行但模块划分得井井有条。我复现的时候把项目拉下来大概整理出了下面这几个核心模块Config 模块负责管理所有的可配置项包括模型名称、API 密钥、温度参数、最大迭代次数、日志级别等。这个模块的设计思路是“把所有需要经常调整的东西集中在一起不要让用户去改核心代码”。Prompts 模块所有与大模型交互的提示词模板都集中在这里。这个设计非常值得学习——因为提示词是整个系统里最容易需要持续调整的部分集中管理可以让你在不动代码逻辑的情况下灵活修改。Tools 模块定义了模型可以调用的外部工具最常见的包括搜索引擎、文件读取、Shell 命令执行。每个工具都遵循统一的输入输出规范这样模型不需要知道工具内部实现细节。Codegen 模块这是程序合成的核心负责把模型输出的自然语言意图转换成可执行的 Python 代码。一般流程是模型以自然语言描述算法思路 → 生成代码骨架 → 填充具体逻辑 → 输出完整程序 → 交给执行器运行。Executor 模块代码执行沙箱。负责在受控环境中运行模型生成的代码捕获异常、管理超时、限制资源占用然后把执行结果以标准格式返回给主循环。2.3 数据流与信息传递方式Autoresearch 的数据流设计是典型的“状态累积”模式。简单来说每一轮迭代的输入都包含两部分当前的研究问题描述 前面所有轮次的执行记录。这种设计让模型拥有“记忆”——它能看到自己之前写过什么代码、得到过什么结果、做过什么判断然后基于这些历史信息做下一步决策。实际操作中Karpathy 并没有用一个复杂的向量数据库来存储历史状态而是简单地用 Markdown 格式的文本日志来管理。每执行完一步就把新的观察结果追加到上下文中。这样做的好处是直观、可读、完全不依赖额外的存储系统而且整个 conversation history 可以直接作为人类的审计日志来用。我之前做 Agent 时喜欢用各种花样繁多的 context 管理方式但后来发现只要你的工具调用足够规范每次返回的结果都被精心格式化那么简单的文本拼接就是最好的上下文管理方式。六千字的记忆不一定非要用向量检索——有时候直接用文本把所有历史记录拼进去反而是最稳定的方案。这里有一点需要注意随着迭代次数增加上下文会越来越长最终超过模型的最大 token 限制。Karpathy 的处理方式是设置一个最大历史轮次超过之后就丢弃最早的历史记录。这是基于“最近的信息对于当前决策影响最大”这个假设。亲测在大多数科研场景下这个假设是成立的。3. 程序合成的关键实现细节3.1 从问题到代码生成、执行、反馈、修复的闭环程序合成是整个项目里技术含量最高的部分也是最难做好的模块。我在实际复现中花了很多时间精力去调优这一块。Karpathy 的思路分三层第一层是需求解析。大模型拿到研究问题之后先要拆解任务目标明确需要什么数据、什么算法、什么评价指标。这个阶段会生成一个结构化的任务描述作为后面代码生成的输入。第二层是代码生成。根据任务描述生成具体可执行的 Python 代码。这里特别强调一点模型生成的代码必须“直接用”不能模棱两可。Karpathy 的做法是在 prompt 里明确要求“生成完整可运行的 Python 代码不要解释你的思路直接给代码”。这个技巧我在自己的项目里也验证过效果非常显著——当你明确告诉模型“你需要输出程序而非自然语言”时生成的代码质量会明显提高。第三层是反馈修复。代码执行之后如果报错了执行器会捕获 traceback 并转成文本信息返回给模型。模型看到报错信息之后自证预言式地修改代码“报错说找不到文件原来是我路径写错了那我用 os.listdir 看一下目录结构再运行”。这三层形成一个闭环模型在这个循环里逐步逼近正确答案。有意思的是很多时候模型做第二次修复时就已经非常接近人类程序员在遇到同样报错时的处理方式——它并不会大改代码而是做针对性调整这其实就是程序合成最精华的部分用极小的修改代价完成自我修正。3.2 合成代码的执行沙箱与安全策略让大模型生成代码然后执行安全问题是绕不开的坎。模型有可能生成恶意代码吗有可能。模型有可能因为 bug 导致的死循环问题把机器搞崩吗完全可能。所以 Karpathy 设计的执行沙箱时做了几个非常重要但容易被人忽略的防护措施。第一个防护是资源限制。每次执行代码都会设置 CPU 时间和内存使用的上限超过限制直接杀死进程。这个机制防止了模型生成的代码出现死循环或内存爆掉的问题。第二个防护是文件系统隔离。执行代码的工作目录限定在一个临时文件夹里代码不能随意访问系统文件。这个虽然做不到完全隔离但至少能防止误删或者访问敏感文件。第三个防护是超时机制。每个代码执行都有严格的时间限制比如 30 秒内必须返回结果。超时之后任务被终止并把超时信息返回给模型让模型重新生成更高效的代码。实际项目里如果你想要更强的安全隔离可以考虑用 Docker 容器或者云端的代码执行环境比如各种 Serverless 平台然后通过 API 远程调用代码执行。但我个人觉得 Karpathy 的方案更适合本地调试——因为你可以直接看到代码执行的具体过程方便排查问题。对于严肃的科研场景我建议可以在本地用容器做一层隔离。3.3 让程序可以“自我调参”参数搜索代码的动态写入这是整个项目中最有启发性的一个设计。传统的手动调参是你人守着终端改一个参数跑一次实验。而 Autoresearch 的做法是让模型生成一个完整调参代码——这个代码本身就是一个搜索程序里面包含参数网格定义、循环逻辑、结果记录。举个例子当研究问题是最小二乘拟合时模型可能会生成如下代码import numpy as np from itertools import product x np.array([1, 2, 3, 4, 5]) y np.array([2.1, 3.9, 6.2, 8.1, 10.05]) best_params None best_loss float(inf) for degree in [1, 2, 3]: for lr in [0.01, 0.1, 1.0]: for epochs in [100, 500, 1000]: coeffs np.polyfit(x, y, degree) y_pred np.polyval(coeffs, x) loss np.mean((y - y_pred) ** 2) if loss best_loss: best_loss loss best_params (degree, lr, epochs) print(fbest_loss{best_loss}, best_params{best_params})这段代码看起来很普通但在程序合成的上下文里它代表了一个很重要的转变模型不是用自然语言告诉你“我建议你试试 degree2”而是直接生成一段穷举所有可能组合的代码用真实计算来找到最优方案。这比单纯让模型“猜答案”要可靠得多——因为模型生成的代码是在真实数据上执行的结果是以真实损失为依据的不存在“幻觉”问题。这里就有关于程序合成的核心理解了程序合成的最终产物不是一段“聪明的代码”而是一个“可以被验证的工具箱”。每一步生成都是为了获取真实的观察数据而不是为了展示模型有多聪明。“猜”与“算”的分界线决定了 Agent 是玩具还是真正能用的科研工具。4. 科研闭环自动实验、结果回流与迭代4.1 研究假设的自动生成与选题科研闭环的第一步是“研究假设的自动生成”。Autoresearch 在这里的逻辑是给定一个大的研究方向模型基于已有的知识和工具能力自己拆分出若干个子问题。这个能力的实现方式其实不复杂在系统初始化时给模型输入一个研究主题然后让模型输出若干个具体可验证的假设。每个假设附带一个实验方案——包括需要哪些数据、用什么算法验证、评价指标是什么。我在实际使用中经常让模型先生成假设列表然后人为地挑一个看起来最有价值的假设丢给系统去执行。这个“人机协同选题”的模式效果最好——机器负责广撒网人类负责聚焦。4.2 实验结果的评估与记录实验跑完之后结果怎么评估Autoresearch 的做法是让模型根据实验输出生成结构化的结果报告。报告中必须包含实验结论、数值指标、以及这个结果对原始假设的验证程度支持还是否定。这个结构化报告会成为整个科研闭环中最重要的“记忆单元”。我在这里有一个印象很深的实验心得不要小看结果记录这一步。很多科研自动化系统都会在上述步骤前功尽弃因为实验已经跑完了但实验结果的控制变量和复现信息没有记录清楚导致后续完全无法评估实验的有效性整个闭环也就断掉了。Karpathy 在结果报告里强制要求模型记录下完整的实验环境和参数配置这一点值得所有做科研自动化的人学习。4.3 结果回流新实验如何利用已有研究产出科研闭环的第三步是结果回流。每一次实验完成后模型可以把结果当作新的“经验知识”用于指导下一轮实验的设计。如果上一次实验发现某个算法在某些条件下表现不佳模型会在下一轮实验的 prompt 里加上这个信息避免重复踩坑。这种设计让整个系统呈现出“越用越聪明”的特性。初始状态下模型对某个领域的理解主要来自训练数据但随着一轮轮实验的执行模型的判断会越来越多地融入真实实验结果这个系统的行为就会越来越接近一个真正的科研助手。在实际复现中我还发现一个很有趣的现象让模型基于历史实验记录来设计新实验时它往往会倾向于选择跟已有实验互补的研究方向而不是重复验证。这说明只要你的上下文里提供了足够丰富的历史信息模型是具备基本的科研直觉的。5. 复现实操从零跑通 Autoresearch5.1 环境准备与依赖安装想要亲手跑一下这个项目环境准备非常简单。以我本地的 Linux 环境为例只需要准备 Python 3.9加上 OpenAI 的 Python SDK或者其他兼容 OpenAI API 格式的 SDK以及项目里用到的一些基础库比如 numpy、pandas 这类数据处理工具。安装流程大概如下git clone https://github.com/karpathy/autoresearch.git cd autoresearch pip install openai numpy pandas项目没有复杂的依赖树不用 Docker Compose不用 Kubernetes连数据库都不需要。这是这套设计让我个人非常喜欢的原因之一——在任何一台有 Python 的机器上都能跑起来。5.2 关键配置项解读复现过程中最关键的是模型层配置。你需要设置模型名称、API Key、base_url、温度、最大 token 数等。我这里列一下我常用的配置模板配置项推荐值说明MODELgpt-4o / deepseek-chat建议使用支持工具调用的长上下文模型TEMPERATURE0.3温度越低输出越稳定科研场景建议低温度MAX_TOKENS4096每次模型输出的最大 token 数不宜过低MAX_ITERATIONS15最大迭代轮次防止无限循环EXEC_TIMEOUT60单次代码执行超时时间秒HISTORY_RETENTION10上下文最多保留多少轮历史记录关于模型选择我的经验是并不一定非要最强的模型才能跑通这个项目但模型的代码生成能力会直接影响整个系统的效率。如果你用的是推理能力较弱的模型很可能出现的现象是模型反复生成代码反复报错反复修改最后超时。switch 到更强模型之后整个系统流畅度提升非常明显。如果是国内环境下使用DeepSeek 这类便宜且代码能力强的模型也是一个性价比不错的选择。5.3 一次完整运行的日志解读跑通一次完整的研究闭环大概需要几分钟到几十分钟不等取决于研究问题的复杂度。我把一次典型运行的核心日志片段放出来带大家看看到底发生了些什么[Agent] 已收到研究任务使用线性回归拟合三个不同数据集并比较性能 [Agent] 任务拆解需要加载数据、分别拟合、评估 R^2 [Agent] Step 1: 生成代码加载数据并查看数据格式 [Agent] 代码已生成开始执行... [Tool] 加载数据成功探测到 dataset1.csv 有 100 行 2 列 [Agent] Step 2: 写拟合代码计算每个数据集的 R^2 [Agent] 执行结果dataset1 R^20.92, dataset2 R^20.87, dataset3 R^20.45 [Agent] 发现 dataset3 拟合效果不好尝试加入多项式特征 [Agent] Step 3: 修改代码加入 degree2 特征 [Agent] 执行结果dataset3 R^2 提升到 0.79 [Agent] Step 4: 生成结论报告保存实验记录 [Agent] 研究完成报告已生成这段日志清晰地展示了程序合成和科研闭环的实际过程先探索数据再写初步代码发现问题后进行针对性修改最后得到改进结果并总结。整个过程的关键点在于模型每一步的决策都建立在真实运行结果的基础上而不是建立在模型自己的猜测上。6. 常见问题与排查技巧实录6.1 Agent 陷入循环出不来怎么办这是在我使用过程中遇到频率最高的问题。表现是Agent 一直在生成代码、执行、失败、修改但始终没有进展像一个死循环一样消耗 API 调用。排查思路分三步第一步检查是不是模型能力不够。如果模型本身就容易写错代码且不擅长根据报错推理那整个 Agent 就会原地打转。这时候第一个建议是换更强的模型。第二步检查是不是问题过于复杂。如果研究问题本身就模糊不清、目标不明确模型也不知道怎么收敛。可以尝试把大问题拆成小问题逐步推进。第三步检查有没有设计好退出条件。Karpathy 的系统里设定了最大迭代轮次和“任务完成”判定标准。如果你自己的项目里没设这些条件建议加上。6.2 生成的代码经常报错甚至语法错误代码生成质量不佳通常有几个原因模型上下文不够长导致模型忘了之前的约束条件系统 prompt 里没有明确要求“生成完整可执行代码”或者模型被要求一次性完成过复杂的任务。我的建议是在给模型提供的研究任务描述中尽量做到具体化甚至把数据集的字段名、类型都列清楚在 prompt 里加一句“你只能输出 Python 代码不能输出其他任何内容”还有一个很重要的小技巧——对于复杂任务先让模型生成一小步的代码比如先读数据执行成功后再继续下一步而不是让模型一次生成完整方案。6.3 API 成本失控我之前跑一个复杂的研究任务不知不觉烧掉了不少 API 费用。后来我总结出几个节流策略第一单次迭代里尽量减少重复上下文。如果你发现每次请求都在重复发送同样的历史记录考虑缩减 HISTORY_RETENTION。第二控制代码执行次数工具调用失败一次就让模型重新生成不让模型写一堆探测性代码控制住整体执行频次。第三在系统 prompt 里明确告诉模型尽量用简单的方案解决问题不要过度工程化。你会发现这个指令对控制 token 消耗非常有效——模型会倾向于用最短的代码实现目标而不是写一个一百行的框架。6.4 本地执行代码的安全风险最后聊一下本地执行代码的风险。虽然 Karpathy 的项目明确说了这是一种“草稿级”实现在真正部署到不可信环境之前我强烈建议采取一些额外措施。我想到的几个基本防护措施仅供参考用 Docker 容器运行整个系统隔离文件系统和网络权限单独建一个低权限 Linux 用户来跑代码不要用 root限制工作目录的读写范围避免代码访问系统敏感位置在生产场景接入专门的代码执行服务让模型在云沙箱里运行代码说实话对于那些真正想把这种方案用在科研工作上的人来说安全意识和资源隔离能力跟模型写代码的能力一样重要。写在最后从 600 行代码里学到的三件事把 Karpathy 这个项目完整复现并改造之后我最大的感受不是“AI 真厉害”而是“好的设计是真朴素”。600 行代码没有花哨的框架没有复杂的工程架构就是一个简单的 while 循环加两个角色思考者与执行者。第一个学到的点是AI Agent 的核心价值不在“让模型输出更聪明的话”而在于“给模型装上执行器让它能验证自己的想法”。如果你做的 Agent 只能生成建议却不能自动验证那它本质上还是一个聊天机器人。第二个学到的点是程序合成不是让模型直接生成最终答案而是让模型生成一个可以验证答案的工具。这个思维方式的转变能让你在设计自动化系统时少走很多弯路。第三个学到的点是科研闭环的核心在“反馈”。实验失败不是坏消息而是新的信息输入——只要你能把失败信息转化成模型可以理解的上下文失败本身就变成了迭代的一部分。最后分享一个我在实践中的小技巧尽量让模型输出的中间产物本身是格式化的可读文本比如 Markdown 表格、JSON、结构化日志。因为这样不仅方便机器解析还方便你在出问题时快速定位到具体环节。600 行不是魔法但它是把复杂的科研自动化浓缩到最简的一个示范。照着这个思路去设计你的下一个 Agent你也能写出来属于你自己的“600 行”。
