DeepSeek 研究员开源 AutoResearch，AI 第一次零干预跑通 285B 模型的研究全流程

事情是这样的。

这两天刷到 DeepSeek 研究员 Deli Chen（@victor207755822）把自己的一套东西开源了，叫 AutoResearch。我点进去之前以为又是一个 agent 框架，准备扫两眼就关掉。结果看到一行字，愣了一下。

他说，他的代理第一次完全 autonomously（全自动、零人工干预）在一个 285B 的大模型上，跑通了一整套强化学习研究的完整循环。从实验设计、写代码、把任务提交到 GPU 集群、debug 报错，一直到把结论写出来，全程没有人插手。

强化学习（RL，reinforcement learning，简单说就是让模型在一次次试错里自己摸索出更好的策略）这种实验，是出了名的难伺候。参数错一个、显存爆一次、loss 突然飞了，正常情况下都得有个活人盯着。让一个 agent 自己从头跑到尾还能出结论，这不是「会写代码」那么简单。

Deli 自己有个比喻我觉得特别到位。会写代码和能把整套研究流程稳稳跑下来，是两件事，就像学会炒一道菜和开一家每天稳定出品的餐厅，差的不只是那道菜的手艺，还有整套后厨的流程、排班、补货和应急。

我盯着这句话看了挺久。因为我平时的活儿，恰好就是给大模型搭那层「让它真正能干活」的工程脚手架。agent 的工具链、超时重试、调度、上下文怎么喂进去，这些不性感但要命的东西。说真的，市面上聊 agent 的文章九成都在聊模型多聪明、prompt 怎么写得花，几乎没人聊「它跑着跑着是怎么死的」。Deli 这套东西，通篇在聊的就是后面这件事。

所以我想跟你唠唠这个。不是因为它有多炫，而是因为它把一个长期没人愿意正面回答的问题摊开了，写得还特别诚实。

先说三种死法

Deli 在框架文档开头就把话挑明了，长时间运行的代码 agent，反复栽在三个坑里，而这三个坑的共同病根，不是模型不够聪明，是工程脚手架缺失。

这句话我太有共鸣了。我们总以为 agent 不行是模型笨，其实大多数时候，模型本身能干，是它周围那套跑环境太脆。

第一种死法，他叫认知打转（Cognitive Loop）。agent 一轮一轮地试，但每轮都在试差不多的方向，收益越来越小，自己困在一个局部最优里出不来。你在旁边看着它很忙，其实它在原地转圈。

第二种最阴险，叫停摆（Stalling）。agent 干完一块活，输出一段漂亮的总结，然后停下来，等你给反馈。从外面看，会话还活着，轮询还在跑，进程没崩，一切正常。但实际上工作已经停了。Deli 说，从运行日志看，这种「假装还活着」比真崩溃常见得多。

我看到这段没绷住。因为这就是我每天跟 Claude Code、Codex 这类工具打交道时最熟悉的画面。你让它干个长活，它干到一半特别礼貌地停下来问你「需要我继续吗？」「要不要我提交？」。它不是不会干，它是被训练得太懂事了，懂事到把「停下来等夸奖」当成了一种美德。

第三种叫运行时脆弱（Runtime Fragility）。这个就更工程了。上下文一压缩（context compaction，对话太长时把前面的内容摘要掉腾出空间），那个驱动循环的链条可能就悄无声息断了。你关掉一个会话，挂在它身上的定时器也跟着一起没了。最要命的是，这些失败默认是没人知道的。它就那么静静地死在那儿，等你第二天早上来看，好家伙，停了八个小时。

你发现没有，这三种死法没有一个是「模型答错了」。全是它周围的工程环境出了问题。这就是为什么我说这套东西戳到我了。

它给 agent 立的五条规矩

针对上面这些坑，AutoResearch 立了五条行为铁律。每一条，Deli 都注明了是从一次真实的翻车里反推出来的。我挑几条我觉得最狠的说。

第一条，零交互。运行期间不许问用户，不许进 Plan Mode，不许用提问工具，更不许以一个问题结尾。一直干到用户喊停为止。遇到模棱两可的地方，自己拿主意，然后把你为什么这么决定写进日志里（标记成 level=decision）。

这条看着简单，做起来反人性。因为现在的模型，骨子里被调教成了一个谨慎的好员工，凡事爱请示。

第二条紧接着补刀，准备好了就执行。Deli 直接点名，最常见的隐性违规，就是把所有准备工作都做完了，然后回头问一句「我该提交吗？」。他说，准备的全部意义就是为了执行，提交、重新提交、修 bug、起监控，这些都是家常便饭的常规操作，不需要任何确认。

我读到这儿想起自己搭流水线时踩过的一模一样的坑。你给 agent 设计了完美的十步，它把前九步走得行云流水，到第十步「真的要按下去吗」那里，停了。前面所有的功夫，就卡在最后这一下的犹豫上。Deli 把这个犹豫直接从协议层面给禁了。

第三条特别巧妙，回调即报活（Callback means report-alive）。上下文一压缩，循环就会无声地死掉。所以每一次回调进来，第一件事不是干活，是先更新自己的「最后存活时间」（last_seen），再检查自己还活着没，发现不对就立刻重启并记一笔。

这是什么思路？这是把「我还活着」这件事，做成了 agent 每次睁眼的第一个本能动作。像是给一个总爱昏睡过去的人，绑了个手环，每次醒来必须先打卡。

第四条，状态必须落到文件里，不许存在对话记忆里。每一轮迭代都开一个全新的会话，只把精心挑选过的状态喂进去，绝不用 resume 续上一轮。

这一条我要单独多说两句，因为它跟大多数人对 agent 的直觉是反着来的。我们总觉得对话越连续越好，上下文越全越聪明。但 Deli 的判断是，长跑场景里，连续的对话反而是负担和污染源。每轮重开一个干净的会话，把状态当成外部数据库一样读进来，这才是稳的。说真的，这个判断有点子反直觉，但越想越觉得对。人也是这样啊，一件事纠结太久，反而该睡一觉清空脑子重新看。

第五条，守卫和工人分离。一个负责巡逻心跳的进程，对不属于自己的任务，只能干三件事，检查是否存活、重启、轻推一下（nudge）。它不许去读人家的数据，不许改人家的状态文件，不许替人家给用户汇报。

这条的来历也写得明明白白，曾经有一个巡逻进程越界插手了别的任务的业务，结果造成了上下文污染、汇报错乱，还差点并发写坏了文件。所以这条规矩，是用一次事故换来的。

心跳看门狗，三层套娃

如果说前面是规矩，那这套东西真正的工程硬核，在它的心跳看门狗（heartbeat watchdog）设计上。

Deli 的前提认知特别清醒，他说，那个干业务的主循环本身就是不可靠的，所以它需要一个独立的守护层。注意这个措辞，他没说「我要把主循环写得足够健壮」，他承认主循环天生会挂，然后在外面套了三层互相检查的保险。

最底下一层叫 L0，是一个常驻的 shell 守卫，不依赖任何会话。它就盯着一个心跳时间戳，一旦发现超过两小时没动静，就拉起一个无头（headless，没有交互界面的）应急巡逻去救场。

中间一层 L1，是一个持久的定时任务，每小时跑一次。检查每个循环的存活时间，重启超时的，发现有谁在停摆就去推一下。

最上面 L2，就是各个业务循环自己，每个跑在自己的会话里，每次回调第一行就更新自己的存活时间。

你品一下这个结构。L2 自己报活，L1 每小时查岗，L0 在最底下兜底，任何一层死了，都有另一层能发现并把它救活。这不就是我们做高可用系统时那套「谁来监控监控者」的经典命题吗。只不过这次，被监控的对象是一个 AI。

我盯着这个三层结构看的时候，脑子里冒出来的是 unix 那套老哲学，一个程序只干一件事，把它干好，然后让程序之间通过简单的接口协作。Deli 这套看门狗，骨子里是同一种克制。它不指望某一个超级 agent 永不犯错，它指望的是一群笨拙但各司其职的小进程，互相搀扶着别让队伍散了。

还有个细节我很喜欢。停摆的判定阈值是两小时，比卡死任务的四小时阈值要短。Deli 解释说，停摆是一种「自愿停下」，修起来便宜，所以值得更早抓出来。你看，连「多久算它偷懒了」这种事，都是有成本权衡的，不是拍脑袋定的。

卡住了怎么办，换结构而不是调参数

agent 跑研究最怕的就是认知打转，AutoResearch 对这个的处理也很有意思。

它的失速检测规则是，某一轮迭代如果零新发现，或者某个指标掉了，失速计数（stale_count）就加一。计数到了 2，强制转向，注意，是去改一个结构性的约束，而不是调战术参数。到了 4，就标记出来求助人类。另外单个工作会话被硬限制在 15 轮或者 30 分钟以内。

最值得拿走的是「转结构不转战术」这六个字。Deli 的原话是，当一个任务在同一个框架里反复卡住，决定性的突破通常来自修正环境或结构约束本身，而不是在现有框架里更使劲地调策略参数。卡两次，就该去质疑环境了，而不是在一个方向上挖得更深。

这话简直可以裱起来挂在每个调参炼丹的工位上。我们多少人，模型效果不好的时候，第一反应是学习率再调调、batch size 再试试、prompt 再改改措辞，在同一个坑里反复横跳一整天。Deli 用代码逻辑逼着 agent 做了一件人类最难做到的事，承认这条路走不通，掉头换条路。

最打动我的，是它认怂的那一段

聊到这儿，你可能觉得我在吹这套框架。但其实真正让我决定写这篇的，是文档里一个叫「验证与局限」的章节。

Deli 在里面老老实实列了几条这套东西做不到的事，没有一句藏着掖着。

他说，那些自评分数，都来自框架内部的多角色模拟评审，只能在同一套协议里做纵向比较，不构成任何对外的质量声明。翻译成人话就是，我自己给自己打的分，你们别太当真。

他还说，最长的一次连续运行是 72 小时，期间有 6 次方向性的人类输入，运营层面零干预，但方向层面的干预保留了。你看，他没说「全自动跑了三天」就完事，他精确地告诉你，操作我没碰，但方向我还是点拨了六次。这种区分，太诚实了。

最让我服气的是这条。他说，那些编造出来的引用和数据，根源就在大模型自己身上，框架能做的只是把「去外部核对」变成流程里一个机械的步骤，它消除不了错误的源头。

这句话我反复读了好几遍。因为它戳破了一个很多人不愿意承认的事实，大模型会一本正经地编造参考文献，这是它的天性，再好的工程脚手架也只能把核查变成一道必经工序，没法从根上让它不编。Deli 没有假装自己解决了幻觉，他只是诚实地把它围起来，盯紧。

真诚这东西，在 AI 圈现在太稀缺了。满屏都是「全自动」「颠覆」「下一个时代」，一个肯把自己的局限一条条码出来给你看的人，反而显得格外可信。我是真的觉得，技术文档写到这个份上，已经不只是技术了。

它到底产出了什么

光说机制有点虚，看产出。这套框架已经扛过了好几个异构的长程任务，最硬的成果是写出了四篇 ICLR 格式的综述论文。

数字摆出来你感受一下。四篇论文加起来 265 页，1155 条参考文献，消耗了大约 255 万个输出 token，累计跑了大约 44 小时的真实时间，期间它自己派生出了 63 个以上的子 agent 去干活。

其中第四篇，就是开头说的那个，关于自博弈（Self-play，让模型自己跟自己对弈来变强，AlphaZero 就是这个路子）的综述。75 页，217 条引用，内嵌了一个真刀真枪的 285B 参数 GRPO 实验（一种强化学习的训练方法）。这篇的评审从 V1 一路改到了 V16，改了十六轮，自评 8.6 分。

我看到 V16 这个版本号的时候笑了。十六轮自我修改。厉害了，一个 agent，自己写、自己审、自己骂自己重写，来回十六次。这画面莫名有点励志，又有点好笑。像极了凌晨还在改第八版方案的我们。

它那个自博弈实验的结论也挺有意思，校准了四种不同的验证器噪声条件后发现，随着验证器噪声升高，训练分布上的改进是单调下降的。说人话就是，你用来给模型打分的那个「裁判」如果不靠谱，模型自我提升的效果就会稳稳地变差。裁判越糊涂，选手越练越歪。这个结论本身就够写一篇了，但今天先按下不表。

它对正在用 agent 的你，意味着什么

聊了这么多，落到地上。如果你也在搭 agent、跑长任务，或者就是天天用 Claude Code、Codex 干活，Deli 这套东西里有几个点我觉得你今天就能拿去用。

第一，别再指望模型「自觉」。它停下来问你「要不要继续」，不是它礼貌，是你的流程缺了一条「准备好就执行」的硬规矩。把这条写进你的系统提示里，明确告诉它，提交和重试是常规操作，不用请示。

第二，状态一定要落盘。别把希望寄托在超长上下文上。把任务目标、进度、试过的方向、积累的发现，分别写进独立的文件，每轮重开会话只读必要的进去。对话记忆是会蒸发的，文件不会。

第三，给你的长任务加一个最朴素的看门狗。哪怕就是一个每小时跑一次的 cron，检查一下时间戳，超时了就喊一声。你不需要 Deli 那套三层套娃，但你至少得有一层，否则你的 agent 死在凌晨三点，你要到第二天才知道。

第四，也是我自己感触最深的，卡住了先怀疑结构，别死磕参数。这条不只对 agent 管用，对人也管用。

最妙的是，这整套协议本身，就是一份自包含的 Markdown 文档。不依赖任何外部代码、任何私有基础设施，一份文件就把全部的动机、约束、架构、状态文件、看门狗机制讲完了，复制下来就能往自己的环境里搬。这种「一个文件定义一整套工程纪律」的克制，本身就很有美感。

我们这个行业总在追逐更大的模型、更长的上下文、更炫的多模态。但 Deli 这套东西提醒我，让 AI 真正在生产里稳稳干活的，往往不是那些光鲜的能力，而是这些藏在水面下的、笨拙的、一次次从事故里抠出来的工程纪律。

是谁来自山川湖海，却囿于昼夜厨房与爱。我们造出了能在 285B 模型上自己跑实验的 agent，最后还是得回头给它绑上手环、设上闹钟、立下别停下来等夸奖的规矩。强大和脆弱，原来一直是同一件事的两面。

航行嘛，靠的从来不是哪一阵特别猛的风，是你在风停的时候，还有没有一套让船别散架的法子。