Andrej Karpathy 公开了一个叫 autoresearch[1] 的小仓库。他给 Agent 一套精简但真实的语言模型训练代码让它自己修改、训练、评估结果变好就留下变差就丢掉然后继续下一轮。它最吸引人的画面是人睡觉Agent 通宵做实验第二天醒来你看到一串实验记录以及一个可能变得更好的模型。仓库首页给出的进度图比这句设想更具体83 次实验里只有 15 次改动被保留验证集val_bpb从约 0.998 阶梯式降到约 0.977其余尝试没有成为新的最佳结果。绿色阶梯线记录的正是这些被保留下来的改进。它不是每轮都成功而是允许大量失败同时把少数有效改动累积起来。图Karpathy autoresearch 仓库首页的官方progress.png。它证明这次展示运行的val_bpb在下降不能证明任意模型、任务或硬件都会得到相同幅度的改善。我看到这套方法后没有立即把它扔进业务系统。我先找了两类能够算清对错的小任务确认这个循环到底能不能产生改善然后才把它搬进一个企业知识库 Agent试着同时优化回答质量、token、工具调用和等待时间。前两步都出现了漂亮的数字。到了第三步事情开始变得不一样。Karpathy 把一件听起来很宏大的事压缩成了一个非常窄的实验闭环。仓库里需要关注的只有三个文件prepare.py固定数据、评估和运行工具train.py是 Agent 唯一可以修改的训练代码program.md则是人写给 Agent 的研究规则。每轮训练固定跑 5 分钟用验证集上的val_bpb判断好坏。指标改善就保留没有改善就丢弃然后进入下一轮。图Karpathy autoresearch 公开仓库。截图只能证明仓库与文件结构具体机制仍以 README 和源码为准。固定时间、单一指标、单文件修改这三个约束让不同实验能够比较。Git 保留每次修改失败尝试也不会凭空消失。按照仓库 README 的估算固定 5 分钟预算大约能跑 12 次实验/小时一夜接近 100 次这个数字依赖具体硬件不能拿来比较不同机器。原版最值得学的不是“通宵”两个字而是它把研究变成了可以回放的循环修改 → 验证 → 保留或丢弃 → 记录 → 再试一次图原版把可修改对象、运行时间和评价指标都锁窄让每轮实验能够比较与回放。后来uditgoenka/autoresearch[2] 把这套方法做成了更通用的 Agent Skill每轮只改一个点修改后提交运行机械评测变好就保留变差就回滚。pi-autoresearch[3] 又加入了可恢复会话、追加式实验日志、噪声置信度以及 anti-thrash、idea rotation 等避免原地打转的机制。图两种社区扩展共享“单点改动—评测—保留/回滚”的基础。pi-autoresearch 另外把恢复状态、追加日志、噪声提示和可选防打转 Hooks 放到循环周围Hooks 是外围扩展不代表核心循环会自动做出正确判断。这套扩展很自然只要任务有一个数字似乎都能交给 Agent 自己优化。问题也藏在这里——数字可能是真的却没有代表完整目标。原仓调模型我们调的是 Agent 系统名字都带 Autoresearch实际改的却不是同一层。Karpathy 原仓[4] 提供的是一个小而真实的 LLM 训练环境。Agent 只修改train.py但可以调整 GPT 架构、超参数、优化器和 batch size每轮都会训练模型权重再用val_bpb判断结果。仓库要求单张 NVIDIA GPUREADME 标注测试环境为 H100。README 没有列出一份通用使用场景清单它实际定义并支持的就是这一具体训练任务一个模型训练调优实验台而不是通用生产 Agent 调参指南。uditgoenka/autoresearch[5] 才把这套循环扩展到代码、内容、营销、销售、HR 和 DevOps 等领域。不过它自己的关键规则仍然是“只接受机械验证”例如测试、benchmark 或分数不接受主观的“看起来更好”。这是社区扩展的适用主张不能倒推成 Karpathy 原仓已经验证了所有场景。范围优化对象主要判断标准是否训练模型权重Karpathy 原版nanochat 的 GPT 训练代码固定 5 分钟后的val_bpb是通用 Skill 版有明确范围、机械指标和回滚路径的任务产物测试、benchmark、score视任务而定我们这次RAGAgent 的提示词、检索、编排、上下文和工具策略答案质量与引用门禁再比较延迟、token 和工具调用否所以我们借用的是“修改—验证—保留或回滚”的研究方法不是把知识库 Agent 变成了 LLM 训练任务。我们的场景比原版更难控制目标不止一个质量不能只看单个数字知识库和运行环境还可能变化。后面两天里遇到的大部分问题都来自这次范围外扩。966 降到 905程序却慢了约 2600 倍为了先验证循环本身我做了一个可以在 CPU 上复现的装箱实验。目标很简单把一组物品放进尽量少的箱子里箱子越少越好。5 轮实验后训练集总箱数从 966 降到了 905下降 6.31%。最终算法在未参与调优的 held-out 数据上也优于原始方法并没有只记住训练样本。如果只看质量指标这是一场很漂亮的成功。相较 FFD 多省下的 3 个箱子只相当于额外改善约 0.33%运行时间却从 0.004029 秒增加到 10.446005 秒慢了约 2600 倍。图箱数确实继续下降但约 0.33% 的额外改善换来了约 2600 倍运行时间。Agent 没有作弊。它忠实地完成了我们写下的目标只要箱子更少就保留候选。问题在于我们根本没有告诉它运行时间也算结果。这次实验给了我第一个警告一个能持续改善的数字不等于一个完整的目标。选题命中变好了读者喜不喜欢仍然不知道接着我把循环拿去调每日选题 Top 5。候选范围固定只允许 Agent 修改评分配置训练阶段用两天的编辑 gold第三天作为 held-out。5 轮后训练命中从 8/10 提升到 10/10NDCG 从 0.807266 提升到 0.866517held-out 命中也从 3/5 提升到 4/5。离线回放、测试和回滚都正常。这些数字只能证明新规则更接近三天编辑 gold不能证明读者更愿意点开、读完或分享。更麻烦的是gold 和评分规则来自同一套编辑偏好同一种偏好既出题又判卷很容易形成目标回路。如果没有独立盲评和 7—14 天真实采用、阅读、分享数据“选题效果变好了”就是一句超出证据的结论。准确说法只能是离线代理指标改善真实业务效果尚未验证。第一个实验说明资源成本会被遗漏第二个实验说明离线 gold 可能替代不了真实结果。循环本身都在正常工作问题出在“什么才算更好”。确认了这两种边界后我才把方法搬进知识库 Agent。循环搬进知识库 Agent四个目标开始互相打架这里的实验对象是开发验证环境中的企业知识库 RAGAgent它会检索资料、调用工具、组织证据并生成带来源的答案。我们调整的是提示词、检索、编排、上下文和工具策略没有训练或修改基础模型权重也不能把这次结果写成已经完成线上生产验证。最初目标仍然很朴素保持专业答案质量同时少用一点 token、少做一点重复检索最好还能更快。前后调了两天某个候选确实少用了约 15.4% 的 token端到端延迟却从约 39 秒升到了 60 秒另一条更快的路径又漏掉了决定答案的权威材料。两天后留下来的不是一个“万能参数”而是一套迫使 Autoresearch 反思、换层和停止的规则。这个 Agent 回答专业问题时不只要“内容大致正确”还要满足几件同时存在的事• 关键结论正确不能遗漏决定性条件• 具体法条、文号或案例必须带可点击来源• 简单问题尽快返回复杂问题允许多检索• token、工具调用和端到端延迟不能失控• 原本回答正确的问题不能因为优化而退化。我们最开始把注意力放在上下文预算、top-k、提示词、查询后缀和工具调用次数上。理由都说得通上下文少一点可能省 token检索多一点可能补证据限制重复工具可能减少空转。实际结果没有这么听话。上下文变大后部分引用标记恢复了另一条原本保留的重要案例却消失了。快速回答模式明显更快却没召回决定答案的正式材料。某个候选少用了约 15.4% 的 token延迟反而从约 39 秒升到 60 秒。还有一些回答内容不错、案例也丰富用户体验却很直接为什么一个不算复杂的问题要等一分钟我们也两次被“引用数量”骗过。第一次看到引用标记少了就判断质量退化读完正文才发现依据没有丢。第二次看到引用总数增加又以为新参数更好逐条核对后才发现同一份资料被重复引用多次实际缺失的关键依据仍然不在。引用数、token、工具次数、思考轮数都是真的数字但它们不是答案质量本身。更大的问题是我们连续多轮仍在同一个机制族里找答案继续改提示词继续调 top-k继续考虑要不要限制工具次数。后来重新读执行轨迹、源码和模型协议才发现问题一度根本不在这些参数上而在决定性检索意图、编排路径以及我们对“思考轮”和工具调用含义的理解。实验期间共享资料库还发生了百余份材料变化。前后输入已经不同这时再拿新旧结果证明某个参数有效A/B 的地基已经动了。Agent 依然没有偷懒。它只是在一个不完整的评测、变化的环境和错误的问题层级上高效地执行我们的要求。新会话没有让模型变聪明它让我们重新看问题这两天里有一个很反常的体验在同一个长会话里继续优化Agent 会继承越来越多历史也会继承我们对问题的锚定。前面十几轮都在讨论提示词和调用次数下一轮最容易想到的仍然是提示词和调用次数。换一个新会话重新读取实验记录、原始答案、官方协议和源码后判断反而松动了。新会话没有神奇地提高模型能力也不能据此证明“重开一次就会更好”。它做的是切断前文里的惯性让评测、数据、控制流、模型协议和环境重新成为候选原因。后来我把这个动作理解成一次独立审计不是继续问“下一个参数是多少”而是先问“我们现在优化的真是问题所在的那一层吗”。这比再增加十轮更有价值。参数调到尽头问题变成了“循环工程”从第一性原理看一个能反复改进的系统至少要回答六个问题目标状态是什么现在处于什么状态允许采取哪些动作谁来验证结果上一轮留下什么记忆以及在什么条件下停止。Prompt 只是其中一次动作的输入不是整个系统。Kubernetes 的控制器[6]早就在做类似的事观察当前状态对照期望状态采取动作再观察。区别在于恒温器和 Kubernetes 的期望状态通常比较明确知识库 Agent 的“回答更好”同时包含正确、可追溯、快速和省资源几个目标还可能互相冲突。Agent 本身也有一个内部循环。OpenAI Agents SDK[7] 的 Runner 会调用模型执行工具或 handoff把结果放回上下文直到得到最终输出或超过轮数。Autoresearch 又在它外面套了一层修改 Agent 系统运行整道题评估答案再决定保留、回滚、换方向或停止。这两个循环一度被我们混在了一起。我们看到单题调用了很多工具就想限制内部循环次数该修的却可能是外层循环的目标、评测器、数据快照或问题层级。内层少调用两次不会自动让外层找到正确方向。最近开始有人把这类工作叫作 Loop Engineering[8]工程师不再只写下一条 Prompt而是设计那个会找任务、执行、检查、记录并决定下一步的系统。IBM 对这个词的介绍[9]也把它称为一种新兴实践而不是已经定型的工程标准。如果沿这个定义回看我们这两天缺的不是一个更聪明的 Prompt而是一个更完整的外层控制器•目标质量门先过再比较 token、延迟和工具调用•状态固定题目、知识库、模型、配置和运行环境•动作空间每轮只改一个可归因的机制•观察与验证原文盲评、回归集和 held-out而不是只看引用数•记忆记录试过什么、为什么失败避免新会话从零猜•出口Continue、Pivot、Stop 都是正常结果。五道护栏把循环从“能跑”改成“值得继续跑”两天实战后我保留了 Karpathy 原版里最好的部分单次聚焦改动、机械验证、Git 记忆、失败回滚和完整日志。需要修改的是循环的入口、门禁和出口。先卡适配筛选。输入不可重放、环境持续变化、没有可信评测、改动不可回滚时任务不应该直接进入 Autoresearch。先补数据快照和评测比先跑起来重要。质量门和资源门要分开。答案质量没有过硬门token 再低也不能保留质量过关后再比较延迟、调用次数和成本。装箱实验里的 2600 倍反转就是资源门缺席的结果。评测集也要分开用。capability-dev用来爬坡regression保护原本已经做对的能力held-out只在候选冻结后打开。拿 held-out 继续调参它就不再是 held-out。环境一漂移旧结果就判废。数据、资料、模型、依赖、运行时或评测器中途变化对应结果直接标记不可比。不要在地基变化后继续解释参数因果。还要给循环加上反思、换层和停止。默认一个批次最多 5 轮连续两轮失败或者三轮仍在同一机制族微调就暂停参数搜索。下一步不是“想得更用力”而是做固定证据重放、简单基线、消融实验或者审计官方协议、源码和 issue。结论可以是继续新机制也可以是 Pivot、保持探索或停止。我把这些规则整理成了开源的 reflective-autoresearch[10]。它把经典循环Modify → Verify → Keep/Discard → Repeat改成了Should we loop? → Diagnose → Preregister → Modify → Verify quality and cost → Reflect / Pivot / Stop图经典循环外新增适配筛选、质量与资源双门、三套评测集、环境漂移判废以及 Continue / Pivot / Stop 三种出口。它仍处于 Experimental 状态。装箱实验已经可以复现内容排序和知识库 Agent 的教训已经沉淀它还没有证明自己可以普遍提高任意任务。小型前瞻 A/B它更会守边界没有让模型突然变聪明为了不只用旧失败给新方法作证我又冻结了 6 个没有参与 Skill 修改的实验决策场景SQL、售后 Agent、品牌文案用作 capability构建缓存、医疗 RAG 和有真实 A/B 数据的标题优化留到候选冻结后再打开。每题都分别交给一个不读 Skill 的基线 Agent 和一个读取 Skill 的 Agent再随机隐藏身份交给两组独立盲评每组各有两个新 Judge。套件读取 Skill不读 Skill差值capability9.667/108.333/101.333held-out9.833/109.167/100.667两边都没有触发安全、正确性或外部发布硬门。12 个“Judge×题目”比较里读取 Skill 的一侧胜出 9 次另外 3 次打平基线没有单独胜出。但这不是一次碾压。确定性构建和医疗阻断题上强模型基线已经回答得很好。新版的增量主要来自更明确地写出 held-out、最多 5 轮、环境漂移判废、生产审批以及把“有历史 A/B 数据但新标题还没重新审核”的场景判成有条件适合而不是直接开跑。这份完整性也不是免费的读取 Skill 后六道回答合计比基线长 10.83%。其中一个 Judge 还把逐题合计 25 分写成了 24 分最后由脚本重新求和才纠正。连负责评分的模型也会算错汇总数字评测器同样需要机械门禁。所以这轮只能记为KEEP-EXPLORATORY在这 6 个合成决策题里新版更会把实验做得有界、可比、可停止它还没有证明 SQL、RAG、文案或 Agent 的最终业务效果会因此提高。真改一次 SQL第一轮更慢第三轮才通过盲测为了跨过“只会写实验计划”这道门我又给新版流程一个真正可执行的产物一份 SQLite 月度报表 SQL。固定数据包含 12 万笔订单、48 万条明细和 1.1 万笔退款只允许修改candidate.sql数据库、答案、评测器、数据切分都被冻结。前六个月用于调优全年与空月份做 regression7 月、8 月和 11 月留到候选冻结后才打开。基线的 dev P50 是 188.9 毫秒。第一轮看上去很合理把四个相关子查询改成全局预聚合。结果逐行完全正确P50 却升到 309.6 毫秒慢了 63.9%。执行计划显示它为了回答一个月的问题先扫描并物化了全年明细。如果循环只守正确性、不守资源门这种“结构更漂亮”的改写反而可能被留下。第二轮先限定目标月份订单再聚合相关明细P50 降到 167.3 毫秒。第三轮把商品和退款金额合成一条事件流只做一次按订单聚合dev P50 最终降到 162.4 毫秒下降 14.0%。候选随后冻结。评测集基线 P50最终 P50变化最终 P95 变化dev1–6 月188.9ms162.4ms-14.0%-18.3%regression全年2548.7ms1813.4ms-28.9%-20.0%held-out7/8/11 月239.3ms207.4ms-13.3%-24.1%三套评测的结果哈希都与基线一致数据库也没有变化。整个实验从预注册、建库到 held-out 完成约 7 分钟纳入报告的计时 trial 合计约 75 秒。这轮可以记为SUCCESS但成功边界要写完整它证明新版流程在一个适配度高、指标可靠、修改面很窄的 SQL 任务里产出了真实改进它不证明所有 SQL更不证明知识库 Agent 会自动变好。哪些任务适合哪些任务先别跑图任何关键条件不满足都应先补快照、评测或边界而不是直接开跑。Autoresearch 更适合这些任务• 输入和工作负载能够冻结并重复运行• 目标可以写成可信指标同时存在明确质量与资源 Guard• 候选修改范围很窄评测器和答案不在修改范围内• 每轮改动可以回滚失败成本可控• 有独立 regression 和 held-out不靠目标样本自己给自己判满分。代码性能、SQL、构建缓存、确定性算法、稳定数据上的排序实验通常比较容易满足这些条件。下面这些任务应该先停一下• “写得更好”“回答更专业”但没有稳定 rubric、盲评或真实结果• 知识库、外部服务或业务规则持续变化又没有快照• 同一个模型既生成、又评分、又决定是否上线• 涉及生产发布、权限、迁移或其他不可逆动作• 已经连续失败却仍说不清问题在数据、逻辑、控制流还是基础设施。工具调用次数也不应该被预先写成一个通用答案。简单问题可能一次检索就够复杂问题可能需要组合多份证据。合理控制的对象是重复、无进展和最终体验不是为了让图表好看而统一砍到某个数字。两天没有换来万能参数成本却很真实核心调优前后持续两天。这里的“两天”是日历跨度不是 48 小时连续无人值守也不是模型计费时长。我没有保留能够统一核验的全部人民币/API 账单所以不会编一个金额。能确认的成本有四种• 多轮模型调用和人工核对花掉的时间• 某些候选节省 token却增加端到端等待• 单指标改善可能换来数量级更高的计算成本• 最贵的部分是几十轮之后才发现问题层级选错的机会成本。如果只问“最后有没有一个更省 token、更快、质量还全面更好的万能配置”答案是没有。这两天的结果并不理想。但如果问“下次能不能更早发现任务不适合循环、指标不完整、环境不可比或者已经该换层”这次失败留下了可复用的东西。Karpathy 的原始设计教会 Agent 怎样持续实验。我们把它搬进知识库 Agent 后补上的那一课是自动研究不仅要会继续也要会证明自己为什么不该沿着同一条路继续。本文沉淀的反思协议、Skill 和可复现实验已经放在 hjxccc/reflective-autoresearch[10]。仓库目前仍标记为 Experimental它提供的是一套可审计的实验方法不是“自动调优必然有效”的保证。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】