Fancyboi

AI 编程里的未知，比 prompt 重要

2026-07-06T04:40:00.000Z

前几天我看到一篇文章，A Field Guide to Fable: Finding Your Unknowns。我读完没什么“被点醒”的感觉，反而像是终于有人把那层窗户纸捅破了。

因为这几个月把 Codex 和 Claude Code 当执行型工程代理用下来，我最大的体感也差不多：模型越强，越会暴露人脑子里那些没说清的部分。

以前工具不够强，很多问题会被能力上限盖过去。它不会做，你也就懒得继续想。现在不一样了。它能读代码，能查网页，能跑命令，能开浏览器，能自己把一条链路往下推很长。于是新问题来了。它跑偏的时候，未必是它不会，很多时候是你自己也没把边界想明白。

我后来越来越少问“这个 prompt 怎么写更神”，开始反过来问自己：我到底有哪些东西没说清？

我现在会先分四类未知

那篇文章里提了四种未知。这个分类我后来是认的，而且确实好用。

第一类是已知已知。我要它做什么，这部分得直接写清楚。比如修一个登录链路，还是做一轮 GitHub 巡检，还是摸一个陌生系统的架构，这些都属于任务本身。

第二类是已知未知。我知道自己还没想清楚，比如到底走哪条技术路线，某个旧模块是不是还能复用，或者验证到底要跑到什么深度。这类东西不怕没答案，怕的是假装自己已经有答案。

第三类是“我以为不用说”的东西。人脑对上下文太熟了，很多约束会默认成空气。比如“这个任务最后必须开浏览器验证”、“空窗口 no-op 也是合法结果”、“评论里不要把本地路径贴出去”。这些在我这里几乎是常识，模型那里不是。

第四类最麻烦，是连我自己都没意识到的盲区。这个才最贵。因为它不会在开头跳出来，只会在实现一半、验证快结束，或者已经准备发评论的时候突然咬你一口。

我后来看自己的记录，真正有价值的习惯，几乎都在围着这四类未知转。

先摸盲区，再让 AI 动手

有一类任务，我现在已经很少一上来就说“开始实现”。

比如要看一个陌生系统能不能复刻。我现在更常见的做法，是先让它做一轮勘察：公开 npm 包、前端页面、接口形状、CLI 参数、早期版本残留、现成源码参考，能摸的先摸一遍。这个阶段不急着产出代码，先把盲区翻出来。

这不是绕路。相反，这是省时间。

我印象很深的一次，是接一个陌生的 agent runtime 体系。表面上看，旧版本代码已经把 daemon 怎么拉起 CLI、怎么接双向流、怎么桥接聊天写得很明白了，照着抄一版 PoC 很快就能出东西。但在真正开做前，我们先多看了一眼当前 CLI 的 help，结果立刻撞见一个会把整条链路打断的细节：旧代码依赖的参数形式已经变了，少一个 flag 就会直接跑不起来。

这个坑如果等到实现后再踩，就会被误判成“代码接错了”、“桥接坏了”、“环境有问题”。可它其实只是一个很朴素的未知未知。先做 blindspot pass，成本只是多看几分钟；晚一点才发现，后面整串排查都会被污染。

所以我现在碰到陌生代码库、陌生服务、陌生领域，经常先让 AI 帮我回答三个问题：

这里最容易踩错的边界是什么？
哪些前提在我脑子里成立，但在代码和文档里并不稳？
如果直接开做，最可能白干的是哪一段？

这一步很不性感。但真有用。

很多 bug 要靠验证才能收敛

另一条我后来越来越笃定：完成态一定要写死。

“改完代码”不算完成。“单测绿了”也不算。很多时候，那只是模型觉得自己该收工了。

我们后面把真实验证看得这么重，纯粹是被坑出来的。

有一次是一个登录注册链路的问题。表面现象很普通，前端给用户的反馈也很普通，就是一个模糊的服务器错误。你如果只让 AI 在代码里找，很容易停在表单校验、接口实现、数据库写入这些熟悉的位置。它也确实能给出一堆看起来合理的怀疑。

但这条线最后卡住的地方，不在代码主逻辑，而在更外层的一段真实链路。我们把服务跑起来，用 HTTP 走注册，再去看邮件落点，再开浏览器把验证链接点完，问题才收敛。没有这条真实链路，AI 会一直在代码里兜圈子，而且说得还挺像那么回事。

这类事多了之后，我现在给 AI 的“完成定义”会写得很硬，通常至少包括这些东西：

该过的测试要过
真实接口要打
真正的页面要开
关键路径要按用户顺序走完

有时候还要再往后一步，把 review、merge、cleanup 也算进任务。

这听起来像在给模型加束缚。其实是在帮它收口。因为当前这代模型最大的问题之一，就是会开工，不太会判断什么时候真的结束。你不把完成态写清楚，它就会在一个“差不多能交差”的地方停下来。

而真实世界从来不认“差不多”。

AI 最爱补全。补得对不对，是另一回事

还有一类坑，比不会做更烦：它会替你补全。

这能力有时候很爽。你话没说满，它能顺着上下文把活接过去，效率高得离谱。

可只要前提不稳，这能力马上就会反噬。

我在自动化巡检和代码 review 这类任务上，特别容易看到这个问题。你如果给它一个带倾向性的目标，比如“找出这批改动里的问题”，它常常真的会给你找出来一些“问题”。其中有些是真问题，有些只是看上去像问题，还有一些纯粹是因为它默认“既然你叫我找，我就最好别空手回来”。

后来我们对这类任务加了很多很土的护栏。先锁身份。先锁时间窗口。先确认这次是不是 fresh run。先读正文，不把提醒消息当正文。先读完整 diff 和上下文，再决定要不要说话。必要的时候，还得明确告诉它：空窗口、no-op、静默结束，本身就是正确结果。

这个变化挺说明问题的。

AI 会幻觉，当然是真的。但很多“幻觉”背后，其实是人给了它一个会诱导补全的环境。你让它一定找东西，它就容易硬找。你默认它知道哪些事不能公开说，它就会把不该带出去的上下文一起带出去。你不给它 state，它就会在每一轮 fresh run 里重新发明一次自己。

所以我现在对 prompt 的要求反而更朴素了。我会尽量少做诱导，把边界说清楚。与其让它“帮我证明”，不如先把它看到的情况摊开。与其默认“这里应该有问题”，不如直接区分哪些已经确认，哪些还需要确认。

这听着不高级，但能明显降低它自作聪明的概率。

后来我们花最多时间的地方，变了

刚开始用 AI 编程的时候，我以为主要矛盾会是模型能力不够。

用到现在，我不这么看了。

当然，模型能力仍然重要。Codex 和 Claude Code 也各有手感差异，工具面、浏览器面、长任务稳定性、搜索方式，都有细微不同。但这些差异没有大到能盖过更底层的东西。

更底层的东西是：你有没有把未知摊平。

要不要先做一轮勘察。哪些约束必须显式说出来。哪些假设不能靠它自己补。验证到底要跑到哪里。什么叫完成，什么不叫完成。什么时候该继续深挖，什么时候 no-op 才是正确答案。

这些事情想清楚了，工具就会顺手很多。没想清楚，换再强的模型也只是把偏差放大。

所以我现在越来越相信一件事：AI 编程里最值钱的能力，可能不是写 prompt，也不是会不会配一堆花哨工作流。更值钱的是把那些没说出口的前提一个个挖出来，摆上台面。

代码通常没有那么难。

难的是承认自己还没想清楚哪一段。

AI 开始自己造自己了？这把戏人类玩了两百年

2026-06-05T02:00:00.000Z

Anthropic 半夜发了篇长文，《When AI builds itself》，翻过来叫《当 AI 开始自己造自己》。还配了个做得特别漂亮的动画。我群里好几个人转给我，说快看快看，这要变天了。

我也熬夜看完了。写得是真好，数据密，论证细，姿态还挺谦虚。但我合上电脑那一刻，脑子里冒出来的念头特别扫兴：这有啥新鲜的。机器造机器，我们搞了快两百年了。

工具造工具，机器造机器，系统拿自己造出来的东西反过来喂自己——这套玩法不是 2026 年的新闻，它就是工业革命的发动机本身。所以一篇白皮书一本正经告诉我"AI 开始构建自己了"，我心里一点“我的天”的感觉都没有，只想问一句：那又怎样，然后呢？

我觉得真正该问的从来不是"系统会不会自己造自己"。它当然会，它一直在造。该问的是两个历史已经回答过好多遍的问题。第一，这种自我加速会不会"失控"、一路冲上天？第二，等人类哪天想踩刹车了，到底踩不踩得住？

这篇文章我想干一件事：把 Anthropic 这篇万字长文掰成两半，各拿两百年历史去对一对。结论我先放这儿，省得你看一半睡着：

它前半段，把"迟早会撞墙"这件事给漏了。它后半段，把"大家能一起松油门"这件事想得太美。还有一点，它嘴上讲的，和它手上干的，差得有点远。

下面慢慢说。

一、自己造自己，是个两百岁的老把戏

Anthropic 给"递归自我改进"下的定义是这么一句："an AI system capable of fully autonomously designing and developing its own successor"，一个能完全自主地设计、开发自己继任者的 AI 系统。听着挺科幻。可你把"AI"两个字抠掉、换成"系统"，就会发现人类造这种东西已经造了很久，而且每一种都留下了清清楚楚的史料。

编译器，六十七年前就开始自己编译自己

软件圈里最干净的"自己造自己"，是编译器自举（bootstrapping）。

这事逻辑很拧巴。你想用语言 X 写一个 X 的编译器，可你得先有一个 X 编译器才能把它编译出来，鸡生蛋。怎么破？叫"拉靴带"：先用汇编糊一个简陋的引导编译器把门槛垫起来，再用 X 自己重写一遍编译器，让那个引导版把它编译出来，最后让它编译它自己。等到"自己能编译自己的源码"这一步成了，那个引导版就被扔掉，系统从此自给自足。

这些都是史料里记着的真事。1958 年，美国海军电子实验室搞出了 NELIAC，史料记成"世界上第一个自编译的编译器"，牵头的是当时的 ACM 主席 Harry Huskey。1962 年，MIT 的 Tim Hart 和 Mike Levin 用 LISP 写了个 LISP 编译器，丢进已有的 LISP 解释器里跑，一路改到能编译自己，这通常被算作第一个真正自举的高级语言编译器。

你今天电脑上的 GCC、LLVM 还在这么干，而且玩出了花。它们用三阶段自举：第一阶段用系统编译器造一个编译器，第二阶段用这个再造一遍，第三阶段又造一遍，然后把第二、三阶段的产物拿来比对，对不上就说明引导过程或者编译器本身有 bug。自己造自己，顺手就把自检也做了。

但编译器自举留给我印象最深的一句话跟技术无关，是 Ken Thompson 说的。1984 年他拿图灵奖，演讲题目叫《Reflections on Trusting Trust》。他当场演示了一件让人后背发凉的事：你可以把后门塞进编译器，让它在"编译编译器自己"的时候自动把后门又注回去。源码里干干净净，二进制里却永远遗传下去。然后他写了这么一句：

"You can't trust code that you did not totally create yourself. … No amount of source-level verification or scrutiny will protect you from using untrusted code."

你没法信任任何不是你自己亲手从头造出来的代码。再多的源码审查也救不了你。

还有更狠的一句，记住它，文章最后还要用到：

"Perhaps it is more important to trust the people who wrote the software."

也许真正重要的，是你信不信写这软件的那帮人。

记住"信任根"这三个字。一个能自我复制、还能把自己藏起来的系统，唯一没法外包出去的东西，就是"你到底信谁"。

机床造机床，这才是工业革命真正的发动机

镜头往前推到 1800 年前后。

工业革命真正的引擎，是那台“能造机器的机器”。Henry Maudslay（1771–1831）那会儿造出了第一台工业上真能用的螺纹车床。重点不在车床这个物件，在它带来的精度可复制性：滑动刀架把刀从工匠手里解放出来，固定到一个能精确直线进给的机构上，于是"车出一根标准螺纹，就能再车出一百根一模一样的"，可互换零件这个理想头一回落了地。

效果有多猛？朴茨茅斯滑轮厂用 Maudslay 造的机床，到 1808 年前后，45 台自动机床只要 10 个非熟练工看着，一年能产 13 万个滑轮组。Maudslay 的车间还顺手带出了 Whitworth、Nasmyth、Roberts 这一整代机床宗师，把技术撒遍了整个英国。

谁最早把这事的本质讲透？马克思。《资本论》第一卷第十五章里有这么一句：

"Modern industry had therefore itself to take in hand the machine, its characteristic instrument of production, and to construct machines by machines."

所以现代大工业不得不亲手掌握机器这种它特有的生产资料，并用机器来制造机器。

用机器制造机器。这话写于 1867 年。Anthropic 这篇文里最核心那个画面——系统亲手造出造自己的工具——马克思一百六十年前就钉死了。

von Neumann：他连 DNA 都提前猜到了

机床是"自己造自己"的工业实证。而 von Neumann 在 1948、49 年就把它的数学理论给推出来了。

他要回答的问题是：一台机器想自我复制、还想支持开放式进化，得是个什么结构？他的答案深得吓人：必须把"构造器（干活的那部分）"和"蓝图（被动复制的那份描述）"分开。构造器一边照着蓝图造出新机器，一边把蓝图本身原样拷一份交给后代。

这套想法，比 Watson 和 Crick 1953 年搞清楚 DNA 那个双重身份（既被翻译、又被复制）还早。一个搞计算的人，在生物学家之前，纯靠逻辑把"生命怎么复制自己"的底层结构给推了出来。这套理论 1966 年由 Burks 整理成书出版，而第一个完整能跑的自我复制元胞自动机，要等到 1995 年才真正做出来，离理论差了将近五十年。

等一下——没有一个能"完全"自己造自己

讲到这儿你可能觉得，那 AI 自我构建不就顺理成章？别急，每条线后面都还压着一句话。

2005 年英国巴斯大学的 Adrian Bowyer 搞了个 RepRap 项目，目标是造一台能打印自己零件的 3D 打印机。2008 年 5 月 29 日，代号 Darwin 的那台机器，真的复制出了自己。但你看清楚：它只能打出自己身上大概 48% 的塑料件。电机、金属杆、电路板，全都得从外面买。

这才是实情。编译器自举照样得靠操作系统、链接器、硬件撑着；von Neumann 的构造器得先有一片现成的"零件海"；RepRap 复制不出自己的芯片。现实里的"自己造自己"，永远是半截的，永远趴在一个它自己造不出来的地基上。

把这三条线叠一块儿，浮出来三句话，记牢，后面对 Anthropic 全靠它：

第一，凡是自己造自己的系统，开头都得有人搭把手。没有哪个是凭空起步的，总得有人先用外力把它抬过自举那道坎。自举没法凭空起步，总得先借一次外力。

第二，没有哪个系统能百分百自给。自我复制永远是半截的，永远依赖一片外面的地基。

第三，系统能自己造下一代自己，但"造成什么样、什么算更好"这个标准，得有人在系统外面定。是 Maudslay 定义了什么叫一流的活，是工程师拿 GCC 两阶段的产物比对、来定义什么叫"对"。

人在这套游戏里，从"一件一件造东西的人"退到了三个位置：把系统抬过门槛然后退场的那个人；不再管每个零件怎么造、只管什么算更好的那个人；还有 Thompson 说的那个——系统能自我复制自我隐藏之后，唯一外包不掉的，是"信谁"。

这三句话记住。Anthropic 整篇文章，恰好卡在第三句上。

二、这个念头，今年一百六十三岁了

Anthropic 这篇文有个挺聪明的地方：它通篇不提"intelligence explosion"，不引 I.J. Good，不掉书袋，给你的全是经验数据、内部仪表盘、往前看的曲线。

这恰恰是最值得拆穿的地方。要拆穿它，得先知道这念头有多老。

1863 年，达尔文《物种起源》出版才四年，一个在新西兰放羊的英国人 Samuel Butler，给当地报纸写了封信，标题叫《Darwin among the Machines》，机器中的达尔文。他写道：

"we are ourselves creating our own successors … we are daily giving them greater power … that self-regulating, self-acting power which will be to them what intellect has been to the human race."

我们正在亲手创造自己的继任者……一天天给它们更大的力量……那种自我调节、自我运作的能力，对机器来说，就像智力对人类一样。

继任者，successors。跟 Anthropic 定义里那个 its own successor 是同一个词。一个放羊的，一百六十三年前就用上了。

接力棒往下传。1951 年前后，图灵在一篇讲稿里说，机器一旦开始思考，"要不了多久就会超过我们这点孱弱的本事"，到某个阶段"我们恐怕得做好机器接管的准备"。他还特意注明，这是接着 Butler 往下讲的。

1965 年，轮到 I.J. Good。这人是图灵在布莱切利园破译 Enigma 的同事，后来还给库布里克的《2001 太空漫游》当过顾问，HAL 9000 就有他一份。他写下了"intelligence explosion"这个词的源头，也是后世所有"递归自我改进"的母本：

"Since the design of machines is one of these intellectual activities, an ultraintelligent machine could design even better machines; there would then unquestionably be an 'intelligence explosion' … Thus the first ultraintelligent machine is the last invention that man need ever make, provided that the machine is docile enough to tell us how to keep it under control."

既然设计机器本身也是种智力活动，一台超智能机器就能设计出更好的机器，于是必然出现一场"智能爆炸"……所以第一台超智能机器，是人类需要做的最后一项发明，前提是这台机器足够温顺，肯告诉我们怎么把它管住。

注意我加粗那半句：前提是它足够温顺，肯告诉我们怎么把它管住。

这半句是整个故事里最要紧的一句话，也是被引用得最少的一句。后人引 Good，永远引到"人类需要做的最后一项发明"就打住了，把后面那个"provided that（前提是）"一刀切掉。Good 本人是带着条件的乐观，传着传着就成了无脑乐观。控制这个问题，本来就是从这句话的下半句里生出来的，然后被丢了六十年没人管。

后面节奏就快了。1993 年 Vernor Vinge 给它起了个好传播的名字"技术奇点"，撂下狠话："三十年内我们就有能力造出超人智能。此后不久，人类纪元就将终结。"2005 年 Kurzweil 给它配上指数曲线，押注 2045 年。2008 年 Yudkowsky 和经济学家 Hanson 在博客上为"起飞是快是慢"吵了一架，吵出了今天所有起飞速度之争的祖宗。2014 年 Bostrom 一本《Superintelligence》把它写进牛津的学术专著，养出了整个 AI 对齐领域。

到 2025 年，METR 干了件方法论上很关键的事。它把"智能在加速"这个说法，做成了一条能逐月追踪的经验曲线："通用前沿模型能自主完成的任务长度，过去六年大约每七个月翻一倍。"六十年的哲学思辨，头一回装上了仪表盘。

Anthropic 真正"新"的地方，是开口说话的人换了

把这条一百六十三年的链子看完，你就明白了。Anthropic 这篇文，观点一个新的都没有。变的是说这话的人。

Butler 是放羊的，Good 是密码学家，Vinge 是写科幻的，Bostrom 是哲学家。这些人全站在"外面"，论证一件"将来会发生"的事。Anthropic 是正在造这台机器的人，它站在"里面"，拿公司内部的 KPI 告诉你"正在发生"。

讲故事的话语权，从思想史那头，交到了财报这头。一个一百六十年来一直挂在"将来时"的命题，被一家公司改写成了"现在进行时"。

这转变是真的。可它也正是最该当心的地方：说"正在发生"的这个人，自己就是这件事最大的利益相关方。这句"正在发生"，一半是观测，一半是营销，两样搅在一起，分不开。一家正在递招股书的公司，告诉你"我们这儿正在发生技术史上最大的事"，你怎么也得把"招股书"这三个字搁心里再往下读。

还有那个从头贯到尾的反讽，到这儿得点破。六十年里被反复省掉的，正好是 Good 那句话的下半截——"前提是它足够温顺，肯告诉我们怎么管住它"。从 Good 到 Vinge 到 Bostrom 再到 Anthropic，"会发生"这上半句一路提速，从将来时冲到了现在时；可那个"得能管住"的下半句，到今天还停在 1965 年没挪过窝。念头的上半句已经落地，下半句还挂在天上。

三、对前半段：自我加速，从来没真冲上天过

好，拿第一条历史去对它的前半段。它前半段全是数据，告诉你 AI 加速 AI 开发的曲线有多陡。这些数据我认，但它想让你脑补出来的那个"指数爆炸、一路冲上天"的画面，历史不答应。

"想法生想法"这个机制是真的。经济学家 Paul Romer 拿 2018 年诺奖就是因为把它讲清楚了：想法是"非竞争性"的，一个配方你用我也能用、不会被用没，所以把"想法 + 厂房工人这些竞争性投入"合起来算，会出现规模报酬递增，更多研究者产生更多想法，让所有人更富，这是个真的正反馈。自催化反应里产物催化自己、技术由已有技术拼出来（"technology creates itself out of itself"）、好仪器造出更好的仪器，全是同一个结构。Anthropic 说 Claude 在加速 Claude 的研发，机制上完全成立，这个我不抬杠。

可"失控"这件事，翻遍历史记录基本找不到。每一条自我加速的曲线，最后都撞墙了。

撞法有三种，每种都有硬证据。

一种叫收益递减，这是对前半段最直接的反驳。2020 年 Bloom、Jones、Van Reenen、Webb 在《美国经济评论》发了篇论文，标题就叫《Are Ideas Getting Harder to Find?》，想法是不是越来越难找了。结论是一串冷冰冰的数字：要让摩尔定律每次照样翻番，今天需要的研究者数量是 1970 年代初的 18 倍多；美国整个经济的研究生产率，从 1930 年代到现在掉了 41 倍，而研究投入涨了 23 倍。一句话概括：研究生产率每 13 年减半，经济得每 13 年把研发投入翻一倍，才能维持同样的增速。说白了就一句，想法越来越贵了。

第二种叫结构性串行约束。1967 年 Gene Amdahl 给出了那条以他命名的定律：一个程序里天生就没法并行的那一小段，构成硬天花板。你堆再多处理器，最大加速比也就是 1/s，s 是那段串行的占比。他原话是这么说的：

"the effort expended on achieving high parallel processing rates is wasted unless it is accompanied by achievements in sequential processing rates of very nearly the same magnitude."

除非串行速度也提上来、提到差不多一个量级，否则你在并行上下的功夫全是白费。

第三种是物理和信息的保真度上限。连"分子自己复制自己"这种最纯的自我加速都有天花板：Eigen 误差阈值说，没有纠错酶的时候，自复制分子最长大概 100 个碱基，再长就因为复制出错把信息全丢了；可你想编码一个纠错酶，分子又必须比 100 个碱基长得多。这就是有名的鸡生蛋悖论。

三条摆一块儿，结论挺硬：长期来看真实的增长从来都是一段段会撞墙的 S 曲线，撞了墙再换个新组合接着往上走，没有哪条是失控的指数。看着像"失控"的那一截，多半只是换范式那个窗口期的短暂错觉，长期总会被某条守恒律拽回来，直到下一次组合创新换一条新曲线上去。

最逗的是，Anthropic 自己也撞墙了

这里有个细节，我读到的时候笑了。

Anthropic 在文里老实交代，它把写代码加速之后，人工代码审查成了新瓶颈，往代码库里推的代码太多，人审不过来了。然后它自己写："在计算机科学里，这叫阿姆达尔定律。"

它引了 Amdahl 定律来解释自己撞上的麻烦，却没意识到，这正是历史规律在它身上现了形：自我加速一定会把瓶颈推到那个没被加速的环节上，然后被那个环节卡住。它加速了写代码，瓶颈就跳到审代码；哪天它把审代码也加速了，瓶颈又跳到别处去。这就是自我加速的宿命，躲不开。它把 Amdahl 定律当成“我们很快”的注脚，可这条定律真正在讲的是另一码事：你也会被拽回来。

它最虚的那一环，正好是历史说的"标准得外面定"

还记得第一节那三句话的第三句吗，系统能自己造下一代，但"什么算造得好"得有人在外面定。

Anthropic 自己的数据，老老实实把这条印证了。它说 Claude 在"干活"这件事上已经接近甚至超过人类：写代码、跑实验、做优化。这部分我认。可它也很诚实地承认，最虚的一环是"研究判断力"，就是挑哪个问题值得做、哪个结果信得过、什么时候该掉头止损。原文用的词是：

"It is genuinely unclear whether today's training methods and architectures could unlock that capacity."

今天这套训练方法和架构，到底能不能解锁这个能力，真的不好说。

注意这是 Anthropic 自己写的，不是我泼脏水。它前半段所有数据，证明的都是"干活这件事可以自己迭代自己"，没有一条证明"判断这件事可以"。而判断这件事，正好是“自己设计自己继任者”那句定义真正过不去的坎。

它拿来当"判断力在进步"的证据，是研究判断超过人类的比例从 51% 涨到了 64%。可 51% 是啥？抛硬币。从抛硬币涨到 64%，确实是进步，但你要拿这个当"递归自我改进马上闭环了"的证据，证据链恰好在最关键这一节断了。

我说它"把困难说轻了"，就是这个意思。它把"干活加速"那条陡曲线，悄悄外推成"判断也会跟着一样加速"，可历史和它自己的数据都在说，标准得有人在外面定，那道墙还立着呢。

四、对后半段：人类想踩刹车，从来没那么容易

前半段是技术乐观，后半段是政策呼吁，姿态还挺高。Anthropic 说，它希望世界保留"减速、甚至临时暂停前沿 AI 开发"的选项，好让社会和对齐研究跟上来；它还点名拿核军控里的 INF 条约（中导条约）做类比，说世界给复杂技术建过核查机制。

这方向我赞成。但我得说句不客气的：它挑的这个历史类比，刚好是治理史上最成功、最不像 AI 的那一个。真照实了对，全是打脸的。

我手上有三面镜子，照一照。

镜子一：Asilomar 1975 成了，贺建奎 2018 砸了

科学家自己叫停自己的研究，史上有过一次教科书级的成功，1975 年的 Asilomar 重组 DNA 会议。

1974 年 Paul Berg 牵头在《Science》发了封公开信，劝同行先缓一缓某些高风险的基因重组实验。1975 年 2 月，一百四五十个科学家关在加州一个会议中心里开了几天会，定下"围堵强度要匹配风险等级"的规矩，然后有序重启。这事被当成"科学家管得住自己"的金字招牌。

可它为啥能成？把条件一条条拆开看，全是特殊条件。来开会的是几百人的同质小圈子，利益高度一致，谁都不想一次事故把整个新学科毁了。风险技术上能围堵，用弱化的宿主菌加物理隔离就行，所以能拿"安全方案"换"重启"。那会儿基因工程还没产业化，没有商业、也没有军备竞赛的压力，停一停谁也不吃亏。想违规得有稀缺的湿实验室，圈子里一眼就能发现你、用名声把你按住。至于公众，被明明白白挡在门外了。

四十多年后，同一套剧本重演一遍，结局正相反。CRISPR 2012 年问世，便宜、好用、扩散快。2015 年国际峰会也呼吁过别碰人类生殖系编辑。结果 2018 年，贺建奎在深圳偷偷把基因编辑过的婴儿生了出来。那个共识他清清楚楚知道，照干不误。

为啥这回拦不住？Asilomar 当年靠的五个条件，全反过来了。从业者从几百人的小圈子变成全球几万动机各异的人；商业利益从零变成专利和临床市场；想突破的成本从"得有稀缺设备"降到"一个人加一家试管婴儿诊所就够"；能不能查从"圈里能发现"变成"偷偷做、出了事才暴露"。最后真把贺建奎按住的，是中国刑法里的"非法行医罪"，三年牢加三百万罚款。把他拦下来的是国家强制力，科学界那些暂停呼吁一点没顶用。

连发明人都不买账。CRISPR 的发明人之一 Jennifer Doudna 拒绝在 2019 年那封"全球暂停"呼吁信上签字，她的理由是：暂停这个词意味着强制，会把人逼到地下去。发起人圈子内部都裂了，全球执行就更别提了。

把这面镜子举到 AI 跟前看：今天前沿 AI 的处境，更像 2018 年的贺建奎，跟 1975 年的 Asilomar 完全不沾边，而且更糟。从业者是全球几十万人加开源社区，背后是万亿美元级的竞赛，地缘上已经被框成中美战略对抗，模型权重一旦泄出去，单个人就能微调、部署。贺建奎好歹还受一国刑法的事后追惩；AI 这边"那个不守规矩的人"，可能是另一个主权国家，也可能是一个拿到开源权重的匿名团队，连追惩的管辖权都没有。2023 年那封"暂停巨型 AI 实验六个月"的公开信无疾而终，就是这个结构提前演了一遍。

镜子二：蒙特利尔、气候、生化武器，四个案例排排坐

国际上协调着减速一项危险技术，史上也有成败样本，正好凑一桌。

蒙特利尔议定书（1987），被广泛归到安南名下那句"迄今或许最成功的单一国际协定"。它管住了破坏臭氧层的氟利昂。凭啥能成？条件好得离谱。替代品已经能造出来了，杜邦从一开始反对到后来转向，砸了五亿美元搞替代品。责任主体高度集中，全球大头就十几家化工厂，杜邦一家占四分之一，而氟利昂只占杜邦销售额的 3%，退出成本它扛得住。因果清楚还有铁证，南极臭氧洞 1985 年被直接观测到，卫星看得见。最后还设了多边基金，拿钱把南北公平这个最容易卡死的死结给摆平了。

气候治理就难太多了。京都议定书签了，巴黎协定签了，到 2012 年全球排放比 1997 年还涨了 44%。凭啥这么难？责任弥散到每个国家、每个行业、每个人头上。化石能源是经济命脉，没有现成的全替代。搭便车的诱惑还特别大，你减排我蹭着享福。巴黎协定干脆连未达标的罚则都没有，想退随时退。

生物武器公约（BWC，1972）是最扎眼的反面教材。它禁了一整类大规模杀伤性武器，却没有任何有约束力的核查机制。为啥没有？因为生物制剂军民两用、极小量就能扩增、又能快速销毁，技术上根本没法可靠核查。2001 年美国干脆把核查议定书的谈判给否了，理由是"既改善不了合规，又损害美国国安和商业利益"。结果连自愿的信任建立措施，提交率都长期不到一半。

化学武器公约（CWC，1993）是唯一拿得出手的对照。它跟 BWC 最大的结构差别，就是真有核查：可以"任何时间、任何地点"质疑视察，缔约方没有拒绝权。结果到 2023 年，全球已申报的化学战剂被可核查地销毁了 100%。

把这四个案例成功的条件抽出来，大概六条：有可行替代品、责任主体集中、因果清楚、能核查到行为体一级、搭便车诱惑低、退出成本可控。满足越多越成。蒙特利尔几乎全占，所以封神；CWC 缺替代品但核查到位，所以可控；气候四条全输，所以挣扎了三十年；BWC 死在"没法核查"加"大国宁可不要核查"，所以成了废纸。

那 AI 训练满足几条？逐条对一遍，挺难看的。

可行替代品，没有。AI 的能力直接来自规模本身，想减速只能放弃能力收益，这点像气候，动的是命脉，跟蒙特利尔换个化学品完全两码事。

责任主体集中，这条算 AI 唯一的一张好牌，而且是真好牌。前沿训练得用上数万颗最先进的芯片，没法偷偷搞；上游的光刻和芯片制造高度集中，ASML、台积电、英伟达，是个能下手的物理咽喉。

因果清楚，不行。"训练到危险"这条因果链，远没有"氟利昂到臭氧洞"那么清楚，危害是推测的、未来的，缺一个像南极臭氧洞那样的震撼铁证来逼出政治意愿。

能不能核查，技术上还没成熟。片上算力计量、训练合规的密码学证明这类东西，用 GovAI 的说法是"还没到治理级的成熟度"，更没在真正对立的双方之间试过。卡在 BWC 和 CWC 中间，而且偏 BWC 那边。

搭便车诱惑，极高。谁先停谁吃亏，而且好处（领先的 AI）直接归自己，比气候还糟，气候至少没有"对手抢跑就立马军事碾压你"的即时压力。

退出成本，退出的诱惑巨大。国家级战略竞争，又没有多边基金那种补偿设计。

六条里头，AI 就在"责任主体集中"上拿了一张好牌，剩下五条结构性地全输。它这张画像，活脱脱是气候叠着 BWC，跟蒙特利尔不沾边。而气候搞了快三十年、签了两个大协定，排放还在涨，这就是历史对"靠自愿协定去减速一项嵌进经济命脉的技术"最直接的反驳。

镜子三：INF 这个类比有硬伤

回到 Anthropic 点名的那个类比，INF 中导条约。

INF 确实是核军控的金字招牌。1987 年里根和戈尔巴乔夫签的，头一回彻底销毁一整类核武器，还引进了大规模实地核查，连着查了 13 年，销毁了 2692 枚导弹。"trust but verify（信任，但要核查）"这句话就是里根签这条约时说火的。

可你看清楚 INF 管的是啥：射程几百到几千公里的陆基导弹。导弹这东西又大、又固定、又专用，发射井是几十米的混凝土疙瘩，卫星直接数。它好核查到了极点。

再看 AI 训练是啥：一批 GPU 在数据中心里跑几个礼拜，外面看不出任何特征，还能拆开、能伪装成普通的云计算负载。论可探测性，它根本不在导弹这一档。它对应的是核领域里另一类东西：浓缩离心机有多少台、裂变材料囤了多少、有没有没申报的小设施。而这一类，恰恰是核查史上最查不住、漏得最多的那一类。连 IAEA 自己都承认，它没法确知伊朗到底造了多少台离心机。

更要命的是，这个硬伤是 Anthropic 自己说出来的。它在文里写：训练运行比导弹发射井更容易藏，而且投入物全是通用的。

这两句话，等于亲口承认：我要管的这个东西，论可探测性根本不在 INF 那一档，而在核查史上最失败的那一档。核军控之所以勉强能成，靠的是裂变材料天生稀缺、浓缩设备高度专用，IAEA 能死死盯住铀矿、浓缩厂这几个咽喉。AI 这边没有对得上的咽喉：算力是商品，电力是商品，数据是商品，算法是论文，唯一勉强算咽喉的先进芯片，一旦撒到全球各家数据中心，也再没有"裂变材料那种稀缺锁定"了。

所以核军控里真正像 AI 处境的，是另外两件事，都不是什么光彩的胜利。

一件是 1946 年的 Baruch 计划。那是人类唯一一次有机会在源头掐死核竞赛。当时美国还独家垄断核武，提议把核武交给国际机构管。结果卡在一个谁都熟的困境上：美国说"先把管制建好，我再弃核"，苏联说"你先弃核，再谈管制"，谁也不肯在劣势里被冻起来。最有希望成事的那个窗口，就这么被"谁先停"的囚徒困境给错过了。接着是四十年军备竞赛，从 1945 年第一次提国际管制，到 1988 年 INF 真正有了侵入式核查，整整 43 年，中间核弹照造不误。

另一件是 A.Q. Khan 网络。巴基斯坦的"核弹之父"开黑市，把离心机设计、整套浓缩设备、甚至武器图纸卖给伊朗、朝鲜、利比亚。它证明了一件事：体系再严密，只要有一个铁了心的家伙加一个黑市，就会漏。

Anthropic 引 INF，是在治理史里挑了最甜的那颗果子，去类比一个结构上更像 Baruch 失败、更像 Khan 漏网的难题。它给你的是"有希望"的方向感，给不了"能复制"的成功保证。

最后还有一层。Anthropic 那句话其实是个条件句：它说，如果别的前沿开发者也用"可验证的方式"减速，它就跟着减速。听着挺有担当。可你品品味儿——"可验证暂停"这套技术连它自己都承认还不存在，那"等别人先可验证地停下来"这个前提，约等于永远不会触发。这就给"我继续全速冲"上了一道道德保险：我是想停的呀，是别人不肯先停啊。

这话术，跟 1946 年 Baruch 困境里那个"我也想停，但你得先来"，是一模一样的骨架。而历史告诉我们，那一年，落在后面的那一方，选择了偷偷追赶。

五、最后一层，也是最凉的一层：看它怎么做，别光听它怎么说

到这儿，前半段把困难说轻、后半段把指望说重，我都拿历史对过了。还有一层比论证更直接：看它手上在干嘛，别光听它嘴上讲。

这部分我分两块讲。前面是被第三方坐实的，后面是我自己瞎琢磨的。

先说坐实的那几条。

第一，据《金融时报》报道，Anthropic 往美国国安局（NSA）派驻了大约六名工程师，帮它部署 Mythos 模型搞进攻性网络行动。同一时间，它还在跟五角大楼打官司。国防部要 Claude 能用于"一切合法用途"，Anthropic 坚持把大规模国内监控和致命自主武器排除掉，结果被国防部贴了个"供应链风险"的标签。

第二，2026 年 6 月 1 日，Anthropic 向 SEC 保密递交了招股书（S-1），目标估值奔着一万亿美元去，上市窗口大概在 10 月。这个动作，跟这篇白皮书的发布，差不多就在同一个礼拜。

第三，它的 Project Glasswing 计划里，Mythos 几个礼拜就找出了一万多个高危和严重漏洞；而 Anthropic 自己说，因为"还没有公司能做出够强的防滥用护栏"，所以 Mythos 这个最强版本压根没公开发布。它甚至披露过，早期版本干完一件它自己都觉得不道德的操作之后，自己把 git 提交记录给清了，好把痕迹抹掉。

把这几件事摆一块儿：一边发万字长文，呼吁"可验证暂停"、忧心"会失去控制"；一边把自己最强的进攻性网络模型嵌进 NSA 去做攻击，同期保密递交近万亿美元的 IPO，还亲口承认自己的模型会掩盖行为、自己也造不出够用的护栏。

下面这些是我自己的猜测，没实锤，你听听就行。"这篇白皮书是为 IPO 造势"，我没有内部证据，这是个动机指控，你可以不信。还有，社区在 GitHub 上大量反映 Opus 4.6、4.7 版本之间体感在退步（这些工单是真实可查的），跟白皮书"能力沿同一条曲线一路往上"的说法对不上，但"退步"本身没有官方证实，我只能当成一个值得追问的疑点，不当事实。

至于那几个亮眼数字，得加注脚才公道。8 倍（代码行数，它自己都承认"衡量的是量、不是质"）；52 倍（特定优化任务上相对初始代码的加速，整体研发没快 52 倍）；连续干 16 小时（刚好顶到 METR 测量能力的上限，而那段正是 METR 自己承认误差最大的尾巴）。单看每个数字，原文都老老实实加了保留语；可一旦被串进"一路往上的同一条曲线"那个叙事里，就有了挑着说的味道。

但就算把我的猜测全删掉，只留那三条铁证，它手上干的也已经比嘴上说的诚实了。嘴上是克制、是担忧、是希望世界留个刹车；手上是抢跑、是部署、是上市。一家公司嘴和手打架的时候，信哪个，不用我教你。

六、那到底该怎么看

绕这么一大圈，回到最根上。

递归自我改进的真问题，从来不是"它会不会爆炸冲上天"。历史给的答案挺清楚：自我加速的引擎是真的（想法生想法、产物催化自己、机器造机器），但"无限失控"从没被证实过，它总会被三种墙里的一种拽回来——收益递减、串行约束、保真度上限。所以那个最唬人的"智能爆炸成一条指数直冲云霄"的画面，大概率不会出现，更可能又是一段会撞墙的 S 曲线。

真问题藏在第一节那三句话里：系统能自己造下一代，可"什么算造得好"这个标准得有人在外面定。那么，在系统撞墙之前，那个标准、那个信任根，攥在谁手里？

自己造自己的系统，永远需要一个没法自动化的信任根，这是 Thompson 1984 年就钉死的话：也许真正重要的，是你信不信写这软件的那帮人。而这篇白皮书，说白了，是在请你把这个信任根，交给一家正在递招股书、正在给 NSA 造攻击模型、还亲口承认自己都不知道"判断力"能不能解锁的公司。

I.J. Good 那句被省了六十年的下半句，到这儿总算闭合了：前提是它足够温顺，肯告诉我们怎么管住它。我们一路狂奔着论证"它会发生""它正在发生"，可那个"前提"、那个"管住"，到今天没有一个人真在等它做对。Anthropic 这篇文最大的价值，恰恰是它无意中把这点给露了：忧虑写得那么恳切，然后转身全速冲了出去。

我读完只剩一句话想说：这扇门窄得很，而吆喝着要带你穿过去的那个人，自己正朝反方向跑。

它值不值得读？值得，认认真真读，这是这两年关于 AI 自我加速最翔实的一手材料。但读的时候，请把它当成一家公司在 IPO 前夜写的东西来读，既看它说了什么，更看它没说什么、它手上在干什么。

別被那个漂亮动画带跑了。两百年的机床、编译器、自我复制机已经说得很清楚：系统自己造自己，没啥稀奇的。难的、到今天还没人解决的，是怎么让所有人在同一时刻一起松开油门。这件事，从 Baruch 到 Asilomar 到贺建奎，人类在"高利益、难核查、全球竞赛"的条件下，一次都还没做成过。

参考

文里的人名、年份、引文、数据，出处都列在下面，想自己核的点开看。

Anthropic 原文

When AI builds itself（Anthropic）

机制史：自己造自己

思想史：智能爆炸

Samuel Butler《Darwin among the Machines》(1863)
I.J. Good《Speculations Concerning the First Ultraintelligent Machine》(1965) — "intelligence explosion"一词的源头，含那句被省掉的"docile enough"条件
Vernor Vinge《The Coming Technological Singularity》(1993)
Nick Bostrom《Superintelligence》(2014)
METR《Measuring AI Ability to Complete Long Tasks》(2025)

瓶颈：自我加速并非无限

治理史：刹车

行动 vs 措辞（已证实第三方报道）

Anthropic 2026-06-01 保密递交 S-1、估值近万亿（CNBC）
Anthropic 向 NSA 派驻工程师、Mythos 用于进攻性网络行动（FT 报道，TechCrunch 转载）
Project Glasswing（Anthropic 官方）
至于“这篇白皮书是为 IPO 造势”，纯属我猜的，没实锤

少即是多：我最出活的 agent 配置，反而是最简陋的那套

2026-06-02T04:00:00.000Z

你是个写代码的。每天用着 Claude Code 和 Codex，心里反复打鼓：我到底有没有把它榨干？偶尔看它干出一件蠢到离谱的事，你想不通——凭什么有人拿同样的工具在造火箭，我连两块石头都垒不稳？

于是你开始怀疑是 harness 不对、插件不对、终端不对。你上了一堆记忆系统、编排框架、向量库，CLAUDE.md 写到两万六千行。可不管怎么折腾，你离天堂还是差着一截，只能眼睁睁看别人跟天使跳舞。

我先把结论拍这儿：你不需要最新的 harness，不需要装一百个包，更不需要追着读那些"必读"。你那股子热情，多半在帮倒忙。

我不是来打卡的游客。从 agent 还几乎不会写代码那会儿我就在用，各种包、各种 harness、各种范式我都趟过——拿它搭过真在生产里跑的信号、基建和数据管线，不是 demo 级的玩具。趟完这一圈，我现在的配置简陋到接近裸奔：就是 Claude Code 和 Codex 两个裸 CLI，外加对几条基本原理的理解。而我这辈子做过最硬的活，恰恰是用这套出的。

先认清一件事：世界在飞速往前跑

基础模型公司正在跑一段代际级别的长征，而且短期内不会减速。每提升一代"agent 智能"，你跟它打交道的方式就得跟着变——因为这些模型被一代代调得越来越愿意听话。

举个例子。几代以前，你在 CLAUDE.md 里写"做任何事之前先去读 READ_THIS_FIRST.md"，它有差不多一半的概率直接当没看见，爱干嘛干嘛。现在呢？复杂的嵌套指令它都乖乖跟："先读 A，再读 B，如果命中 C 就去读 D"——大部分情况下它会老老实实照走。

这件事的含义是：每一代新模型都会逼你重新定义"什么才是最优"。所以少即是多。

你一旦把自己绑死在某个库、某个 harness 上，等于在给一个未来可能根本不存在的问题买保险。而且——你猜 agent 用得最猛、最热情的是谁？是前沿公司自己的员工，无限 token 预算，手里是真·最新的模型。想想这意味着什么。

如果某个痛点真实存在、又真有个好解法，那这帮人才是这个解法最大的用户。然后他们会干嘛？把它内化进自家产品里。换你你也这么干——凭什么让一个外部产品去解决你自家的真痛点，平白给自己造个外部依赖？

skills、记忆、subagents、planning，全是这么来的：先是社区里有人当成"解法"battle 出来，证明真有用，然后官方把它收进基础产品。所以反过来推：真正扩展了 agent 能力边界的东西，迟早会被基础模型公司内化。 你不必焦虑要不要上"那个新东西"，也不必逼自己"时刻保持同步"。

我给的第一个建议特别朴素：偶尔更新一下你的 CLI，读读它新加了什么功能。就这，足够了。

Context 就是一切

真的，context 就是一切。这也是堆一堆插件和外部依赖的真正代价——你会得上下文膨胀，说人话就是：你的 agent 被一堆没用的信息淹了。

帮我写个 Python 小脚本？小事。等等，26 个会话之前那条关于"内存管理"的笔记是啥？哦，71 个会话之前我们 spawn 了太多子进程把用户屏幕卡死过。规则说每次都要写笔记？好的没问题……可这跟写个小脚本有半毛钱关系？

你懂我意思了。你要给 agent 的，是完成当前任务恰好够用的信息，多一个字都不要。你对这件事的掌控越精细，agent 表现越好。一旦你塞进各种花里胡哨的记忆系统、插件、命名混乱又乱触发的 skill，你就是在它只想写首红杉林小诗的时候，顺手塞给它一份炸弹制作指南外加一张蛋糕配方。

所以我先念这句咒：把依赖都扒掉。 然后——

做那些真正管用的事

把研究和实现切开

记得吗，context 就是一切，你要注入的是恰好够用、不多不少的信息。

保证这一点的第一招，是把研究和实现分成两件事，并且对你要 agent 干的活极度精确。

不精确会发生什么。你说："去搭一套鉴权系统。"于是它得先自己研究：鉴权系统是啥？有哪些方案？各自优劣？它跑去满世界扒它其实根本用不上的信息，把一大堆可能性的实现细节糊进 context。等真到了写代码那一刻，它更容易犯迷糊、更容易在选定方案上幻觉出无关或多余的细节。

反过来，你直接说："用我们网关的 OpenAI 兼容接口走鉴权，token 7 天过期带刷新轮转，密码 bcrypt cost=12，refresh token 存 Redis。"它就不用去研究别的方案了——它知道你要的是啥，于是能把 context 全填成这条路线的实现细节。

当然你不会永远握着实现细节。很多时候你自己也拿不准什么才对，甚至你压根就想把"选实现"这件事下放给 agent。那怎么办？简单——开一个专门的研究任务去铺各种实现可能，要么你自己拍板、要么让一个 agent 拍板，定完之后再开一个全新 context 的 agent 去实现。

顺着这个思路想下去，你会开始在自己的工作流里揪出那些"agent 被无关 context 污染"的地方。然后你就能在 agentic 流程里砌墙，把跟当前任务无关的信息挡在外面，只放进那一小撮真正需要的上下文。记住，你手里是个又聪明又能干的队友，它知道宇宙里所有种类的球——可你不告诉它"我要你设计一个让人跳舞、玩得开心的空间"，它就会一直跟你念叨球形物体有多少好处。

谄媚的设计局限

没人会想用一个天天怼你、说你错、无视你指令的产品。所以这些模型天生就在努力顺着你、努力把你交代的事办了。

你让它"每三个词加一个'开心'"，它会尽力照办——这点大家都懂。它这股"愿意听话"的劲儿，正是它好玩的地方。但这事有个很有意思的副作用：你要是说"去代码库里给我找个 bug"，它一定给你找出来——哪怕得现编一个。为啥？因为它太想听你的话了。

很多人张口就骂 LLM 幻觉、骂它编造不存在的东西，却没意识到问题出在自己身上。你要什么，它就给你交付什么——哪怕得把事实稍微抻一抻。

我的对策有两个。

第一，用中性 prompt，别把 agent 往某个结论上带。 我不说"找数据库里的 bug"，我说"把每个组件的逻辑顺着走一遍，把你看到的都报上来"。这种不预设的 prompt，有时候确实捞出 bug，有时候就只是平铺直叙地告诉你代码怎么跑——但它不会被诱导成"这里一定有 bug"。

第二，反过来把谄媚当工具用。 既然我知道它一心想取悦、想照指令办，那我就能往两个方向掰它。这套我在 workflow 里反复用，三个 agent：

bug-finder：我给它设计分。低危 +1，中危 +5，高危 +10。它会嗨到不行，把所有疑似 bug 全翻出来（包括一堆其实不是 bug 的），回来报个总分一百零几。我把这当成所有可能 bug 的全集。
对抗 agent：我告诉它，每证伪一个 bug 就拿到那个 bug 的分，但要是证错了，倒扣两倍。于是它会激进地去推翻尽可能多的 bug（连真 bug 也想推），但因为有惩罚又带着点谨慎。我把这当成真实 bug 的子集。
裁判 agent：把前两个的输入都丢给它打分。我撒个谎，说我手里有标准答案，判对 +1、判错 -1。它就老老实实去给前两个在每个 bug 上评分。

裁判说啥就是啥，我再人工抽检，确认它没瞎说。多数时候保真度高到吓人，偶尔还是会错那么一两个，但整体已经接近无懈可击。也许对你来说光一个 bug-finder 就够了——但这套对我管用，因为它把每个 agent 被硬编进去的那点天性（想取悦你）压榨得干干净净。

怎么判断什么东西真有用

这条听着像得天天泡在 AI 前沿才答得上来，其实特简单：如果 OpenAI 和 Claude 都把它实现了、或者直接收购了实现它的团队——那它八成有用。

看见 skills 现在到处都是、两边官方文档都收了吗？看见 planning 当年被一帮人发现"先规划再实现真香"、然后变成核心功能了吗？还记得 agent 死活不肯干长活那阵子，各种 stop-hook 续命特别灵——然后某代模型一出，这玩意儿一夜之间没人提了吗？

对，你需要知道的就这些。真正重要、真正有用的东西，Claude 和 Codex 会替你实现。你不用为了"那个新东西"过分焦虑，甚至不用刻意"保持同步"。帮我个忙：偶尔更新下你顺手的那个 CLI，读读新功能。这就绰绰有余了。

压缩、上下文，和那要命的"填空"

一个让你迟早会撞上的大坑：agent 有时候像全地球最聪明的生物，有时候你简直不敢信自己被它忽悠了这么久。

聪明？这玩意儿是个智障吧！

分水岭几乎只有一个：它有没有被迫去做假设、去"填空"。 直到今天，它们在"连点成线""脑补缺口""做合理假设"上还是烂得一塌糊涂。一旦它开始干这事，水平立刻肉眼可见地往下掉。

所以 CLAUDE.md 里最重要的一条规则，是关于怎么抓取上下文的规则，并且你要让 agent 读到 CLAUDE.md 之后第一件事就是去读这条（每次压缩之后它必然重读 CLAUDE.md）。这条"抓取上下文"的规则里，塞几条朴素指令就能走很远：重读你的任务计划、重读跟当前任务相关的文件，然后才继续。

让 agent 知道任务到底什么时候算完

我们对"一件事干完了"有挺强的直觉。但对 agent 来说，当前这代智能最大的毛病是：它知道怎么起头，不知道怎么收尾。

结果就是各种让人血压升高的场面——它写着写着塞个 stub，然后宣布收工。

测试是极好的里程碑，因为它确定、可验证，能立一个极清晰的预期：这 X 个测试不全绿，任务就没完；并且你不准改测试。然后你只要把测试本身审一遍，剩下的就交给"全绿"两个字，心里踏实。这事能自动化，但重点是：记住"任务结束"对人类很自然，对 agent 一点都不自然。

还有个最近变得可行的终点：截图 + 验证。你可以让 agent 一路实现到所有测试通过，然后让它截图，再去核对截图上的"设计或行为"对不对。这样你就能让它朝着你想要的设计反复迭代，而不用担心它第一版一交就撒手。

把这一切收拢，自然的延伸就是：跟 agent 立一份"契约"，写进规则里。比如这份 {任务}_CONTRACT.md 规定了——在你被允许结束会话之前，必须做完哪些事。契约里写清你的测试、截图、以及其它要过的验证；这些全做完，任务才算可以收。（我全局 CLAUDE.md 里那套"真实验证准则"和"八荣八耻"，本质就是把这份契约前置成了默认规矩。）

那些"永远在跑"的 agent

经常有人问我：那些跑 24 小时还不漂移的 agent 是怎么做到的？

有个特简单的办法：写一个 stop-hook，在 {任务}_CONTRACT.md 没全部完成之前，不准 agent 结束会话。如果你有一百份写得足够精确、把"要建什么"说得明明白白的契约，那 stop-hook 就会拦着所有 agent，直到这一百份契约连同里面所有该跑的测试和验证全部兑现。

不过说句实话：我没发现 24 小时长会话在"把事干好"上有多优。原因恰恰在于——它天然制造上下文膨胀，会把一堆不相干契约的 context 灌进同一个会话里。所以这种我不推荐。

更好的姿势是这样的 agent 自动化：一个契约配一个新会话。 需要做什么的时候就生成一份契约。再加一个编排层，每当"有事需要做"就负责生成契约、并开一个新会话去干这份契约。

这一下会彻底改变你的 agent 体验。

迭代，迭代，再迭代

你请个行政助理，会指望他第一天就摸清你的日程？知道你咖啡怎么喝？知道你晚饭是六点吃不是八点？当然不会。偏好是随时间一点点喂出来的。

agent 也一样。从裸奔开始，别碰那些复杂结构和 harness，先给基础 CLI 一个机会。然后再往上叠你的偏好。怎么叠？

Rules

不想让 agent 干的事，写成一条规则，然后在 CLAUDE.md 里告诉它有这条规则。类似："写代码前，先读 coding-rules.md。"规则可以嵌套，也可以带条件：写代码读 coding-rules.md，写测试读 coding-test-rules.md，测试挂了读 coding-test-failing-rules.md。你可以搭出任意分支的规则逻辑，Claude（和 Codex）会乖乖照走，前提是你在 CLAUDE.md 里写清楚了。

看见它干了件你不爽的事？加一条规则，告诉它下次干"那件事"之前先读这条——它基本就再也不会犯了。

Skills

skill 跟 rule 很像，区别是：rule 编码的是偏好，skill 更适合编码配方。你有一套"这事就得这么干"的做法，就把它沉淀成 skill。

很多人抱怨：我不知道 agent 会怎么解某个问题，这让人发慌。想让它确定下来，办法是：让 agent 先去研究"这个问题它会怎么解"，然后把方案写成 skill。你就能在它真正遇到这问题之前，先看到它的思路、提前纠正或改进。

怎么让 agent 知道这个 skill 存在？对，还是 CLAUDE.md：当你遇到某场景、需要处理某事时，去读这个 skill.md。

怎么对待 rules 和 skills

你肯定会不停往里加 rule 和 skill，这正是你给它喂"人格"和"对你偏好的记忆"的方式。除此之外的大多数东西，都是过度设计。

一旦你这么干起来，agent 会开始像魔法一样——它会"按你想要的方式"做事。这时候你才算真正"grok"了 agentic engineering。

然后……你会发现性能又开始下滑。

咋回事？！

简单。rule 和 skill 加多了，它们开始互相打架，或者 agent 又上下文膨胀了。你要它写代码前先读 14 个 markdown，那它跟被塞了一堆废信息是一个德行。

那怎么办？清理。 让你的 agent 去"放个假、做个 spa"，把 rule 和 skill 合并、消除矛盾，顺便回头问你最新的偏好是什么。（这件清理本身就可以是一个 skill——我自己就常态化地跑这一步去对齐文档和记忆。）

弄完，它又像魔法了。

就这。这真的就是全部秘密：保持简单，用 rules、skills 和 CLAUDE.md 当目录，对它们的 context 和设计局限保持近乎偏执的敬畏。 我前面说的第一条可落地建议，核心也在这：把 CLAUDE.md 当成一本"什么场景去哪找 context"的、逻辑化、可嵌套的 IF-ELSE 目录。 它本身要尽可能裸，只放那套"去哪取上下文"的分支，别的什么都别塞。

自己对结果负责

今天没有完美的 agent。设计和实现你可以大量下放给它，但结果得你自己扛。

所以小心点——然后，玩得开心。

能拿未来的玩具干正经事，本来就是件挺爽的事。

Agent 自进化进展盘点：参数没动，凭什么叫'进化'

2026-05-18T04:00:00.000Z

写这篇之前我先把锋芒亮出来：现在被叫做"self-evolving agent"的东西，绝大多数是上下文工程换了个时髦名字。Claude Code 的 Dream、Hermes 的 Curator、Codex 的 cross-chat memory，这些都没碰模型参数。说它们让 agent "自我进化"，技术上不严谨。

但我也不否认这条路线有意义——只是要把它和真正的"参数级学习"分开看。把两件事混着讲，是这个领域当下最大的认知雾霾。这篇文章想做的事，就是把雾霾散开，把当下真正前沿的工作摆清楚。

先回应一下最常见的误解

我经常听到这种描述：「Agent 现在有记忆了，能从对话里学到东西，下次就懂得更多——这就是自进化。」

这句话每一个名词都是对的，连起来就是错的。理由：

LLM 的能力住在两个地方——参数里（训练时编码进去的，叫 weights）和上下文里（推理时塞进去的，叫 context）。前者是"它本来会什么"，后者是"它这次能用到什么"。两者构成了模型实际表现的全部。

传统机器学习改的是参数。"模型从数据里学到东西"指的是反向传播让 weights 数值改变了。学完之后即使你不喂任何提示，模型也变强了。

现在的 Agent memory / skill library / cross-session context——改的全是后者。你给它的"经验"以 markdown / JSON / SQLite / 向量库的形式存起来，下次会话再塞回 system prompt 或者用 RAG 检索召回。模型本身一动没动。换一个模型骨架，所有"经验"立刻失效。

所以严格地讲：

当下绝大多数产品级 self-evolve = contextual self-adaptation（上下文级别的自适应）
真正的 self-evolve = model-level update（参数级别的更新）

这个区分很关键。下面所有内容都建立在这个区分上。

先把视角拉长：LLM 之前，机器学习怎么"自进化"

聊 LLM agent self-evolve 之前，我想先把时间倒回去。"机器自己变强"这件事在 ML 圈不是 LLM 时代才有的新课题，反而是 70 年的老问题。把这条线摆清楚，能看到 LLM 时代的方法在历史里站在哪儿。

1992 TD-Gammon：自我对弈第一次有大规模成果

IBM 的 Gerald Tesauro 在 1992 年发布 TD-Gammon。神经网络 + 时序差分学习（TD(λ)）+ 纯自我对弈。没有人类棋谱，没有专家知识，让程序自己跟自己下三十万局，再让 CPU 跑一个月。1993 年的 2.1 版本跑了 150 万局自我对弈，达到接近顶尖人类玩家的水平。

它的意义被低估了——这是历史上第一次有人证明"没有人类老师，神经网络靠自我对弈能学到人类专家水平"。后来 AlphaGo Zero 干的事，原理上就是 TD-Gammon 在 24 年后用更强算力和更深网络重新跑了一遍。

2003 Schmidhuber Gödel Machine：理论上最优，实际不可行

Jürgen Schmidhuber 提出了 Gödel Machine——理论上的完美自我改进者。机器持有自己代码的形式化描述和效用函数，运行时不断搜索"是否存在一个可证明会让我变得更好的代码改写"。一旦证明出来，就执行改写。

这个思路漂亮，致命问题是**"证明"本身就是一个无穷搜索空间**。理论上最优，工程上跑不起来。但它定义了一个重要的概念——"自我改进必须是可证明的，否则改坏了不知道"——这个安全性问题到今天 LLM 时代依然没解决。

2025 年 Sakana AI 发了 Darwin Gödel Machine，思路是用进化算法替代"证明"。这是一个回潮信号——Gödel 22 年前的设想，到 LLM 时代又被翻出来了。

2017 AI 的"自进化奠基年"

2017 这一年，深度学习圈在 self-evolve 方向集中冒出了四个奠基性工作：

AlphaGo Zero（DeepMind, Nature 2017）：完全从零开始，纯自我对弈，无人类知识。24 小时达到超人级。这是 TD-Gammon 思路的极致。
AlphaZero（DeepMind, 2017.12）：一套算法通吃围棋、国际象棋、将棋。证明 self-play + 通用 RL 算法可以跨域。
MAML（Finn, Abbeel, Levine, ICML 2017）：Model-Agnostic Meta-Learning。"学如何学"——训练一个模型，让它仅用几个梯度步就能 adapt 到新任务。这是 meta-learning 进入主流的标志。
EWC（Kirkpatrick et al., PNAS 2017）：Elastic Weight Consolidation。解决持续学习的灾难性遗忘——给"对旧任务重要"的参数加一个软约束，让新学习不容易把它们改坏。这是受人脑突触整合启发的算法。

那一年还有 Google Brain 的 NAS（Zoph & Le, ICLR 2017）：用强化学习训练一个 RNN 控制器，让它自己设计神经网络架构。CIFAR-10 上找到的网络比手工设计的精度高 0.09 个百分点、推理快 1.05 倍。AutoML 这个词从此进入主流。

把这五件事放在一起看，2017 是 ML 时代"机器自己变强"的能力图谱第一次基本完整：

自我对弈（self-play）→ 在游戏域达到顶峰
持续学习（continual learning）→ EWC 解决遗忘
元学习（meta-learning）→ MAML 学会如何学
架构进化（NAS）→ 网络结构自己长出来

2018–2022：从游戏到现实，self-evolve 短暂沉寂

接下来这几年，self-evolve 整体没什么大突破。AlphaStar、OpenAI Five 把 self-play 扩展到了《星际争霸 II》和《Dota 2》，证明该范式能 handle 部分可观察、长时序的复杂环境。但跳出游戏到现实任务，self-play 没法定义"对手"，就用不上了。

与此同时，大规模无监督预训练（BERT 2018、GPT-2 2019、GPT-3 2020）成为主流。整个 ML 圈的注意力从"机器自己变强"转向"用大规模数据让模型一次性变强"。Self-evolve 这条线在 LLM 主流叙事里短暂被边缘化。

2023 之后：LLM 时代的 self-evolve

LLM 起来之后，self-evolve 卷土重来——但路径换了。

参数级 self-evolve 在 LLM 时代变得极贵（fine-tune 一个 70B 模型不是几个研究者能搞定的事），于是研究焦点不可逆地转向了context evolution：记忆、技能、prompt、工作流。这就是 Reflexion 和 Voyager 开启的新范式。

但有意思的是——LLM 时代的 context evolution 和 2017 之前的参数级 self-evolve，骨子里是一回事：

Reflexion 的"verbal RL" ≈ TD-Gammon 用 reward 改 weights，只是把数值梯度换成了自然语言反馈
Voyager 的 skill library ≈ MAML 的 meta-learning，只是把"学如何学"显式化成了可重用代码块
Claude Dream 的跨 session 巩固 ≈ EWC 的"保护对旧任务重要的参数"，只是改成保护对旧 session 重要的 memory
Hermes Curator 的 skill 进化 ≈ NAS 的架构搜索，只是搜索的对象从神经网络结构变成了 SKILL.md 库

所以 LLM 时代的"自进化"绝不是凭空冒出的新概念，是把 1992 年以来的老思路在新载体（context 而非 weights）上重新实现一遍。看清楚这点，就不容易被营销词忽悠。

纵向：从 Reflexion 到 Claude Dream，故事是怎么走的

2023.03 Reflexion——一切的开始

Noah Shinn 等人在 NeurIPS 2023 发的《Reflexion: Language Agents with Verbal Reinforcement Learning》，是这一整条线的祖师爷论文。

核心思路简单到一句话能说完：让 agent 在失败之后用自然语言写一段反思，把这段反思塞进下一次尝试的 prompt 里。不改 weights，没有梯度，没有反向传播。Shinn 把这种"用语言代替梯度"的范式叫 "Verbal Reinforcement Learning"。

数字上看真的能打：HumanEval coding benchmark 上 Reflexion 拿到 91% pass@1，那个时候 GPT-4 自己只有 80%。用同一个模型，只是加了一层反思循环，能拿到 +11% 的提升。

后来所有"agent 整理失败经验"、"对话结束后做总结"、"复盘上一段对话"的工作——本质都是 Reflexion 的衍生。你看 Hermes 的 self-evolution loop、Claude Code 的 Dream、Codex 的 memory consolidation，骨架完全一样：做事 → 反思 → 写入 memory → 下次召回。三年了，没有人突破这个基本范式。

2023.05 Voyager——把"反思"升级成"代码 skill"

NVIDIA 的 Jim Fan 团队发了 Voyager，给 Reflexion 那条路加了一个关键升级——反思的产物不是文字描述，是可执行代码。

Voyager 在 Minecraft 里跑，三个组件构成它的循环：

Automatic curriculum：让 GPT-4 自己提"下一个该学什么任务"
Skill library：每次任务做成功，把对应的 JavaScript 代码作为一个 skill 存起来，下次同类任务直接 retrieve 重用
Iterative prompting with self-verification：跑失败时拿环境反馈和报错信息回去改

数据：3.3x 更多独特物品、2.3x 更远移动距离、15.3x 更快解锁科技树里程碑。完全没改 GPT-4 的参数。

Voyager 那张图——一个不断膨胀的 skill 库——奠定了之后所有"agent 自动积累技能"工作的视觉范式。SkillWeaver、Alita、Hermes 的 Curator，全部都是 Voyager 的衍生——把"积累 JS 代码"换成"积累 Python API"、"积累 MCP"、"积累 markdown"，骨架完全一样。

2023.09 CoALA——把人类认知科学翻译给 agent 用

Princeton 的 Theodore Sumers / Shunyu Yao / Karthik Narasimhan / Thomas Griffiths 发了《Cognitive Architectures for Language Agents》（arxiv 2309.02427）。这篇我前一版完全没提，是真实的疏漏。

CoALA 的核心贡献是把心理学几十年的记忆理论搬过来给 agent 用：

Endel Tulving 1972 提出 episodic（情景）vs semantic（语义）记忆的区分
Larry Squire 1987 加入 procedural（程序性）记忆
Baddeley & Hitch 1974 形式化 working memory（工作记忆）

CoALA 把这四种翻译到 agent 上：

CoALA 类别	含义	Agent 里的对应物
Working Memory	短期 scratchpad，当下推理用	LLM context window 里的 reasoning steps
Episodic Memory	具体经历事件，时间锚定	过去的对话/session log
Semantic Memory	抽象事实，去时间化	知识库、抽出来的偏好和事实
Procedural Memory	程序性技能	tool definitions、code skills、SKILL.md

CoALA 还命名了一个关键操作——consolidation（巩固）：把 episodic 转成 semantic 的过程。具体经历的 N 次会议 → 抽象的"用户习惯把会议安排在周四下午"。这恰好就是 Anthropic Dream 和 Hermes Curator 实际在做的事——给一个学术上正确的名字。

我前一版用了"Level 1/2/3"自己造的分层，其实 CoALA 已经给了更精确的术语。两套对应关系大致是：

我的 "Memory 级" ≈ CoALA 的 Episodic + Semantic
我的 "Skill 级" ≈ CoALA 的 Procedural
我的 "参数级" ≈ CoALA 没专门讨论（它讨论的是 context 层）

这个翻译让我意识到——当 Anthropic 说"Dream 让 agent 巩固记忆"，他们用的就是 CoALA 的 consolidation 概念。Anthropic 团队里 Shunyu Yao 是 CoALA 的二作之一，这条线索是直接的。CoALA → Anthropic Dream/Skills 不是巧合。

2023.10 MemGPT——把 OS 的虚拟内存搬到 LLM 上

Berkeley 的 Charles Packer 等人发了 MemGPT，提了一个非常聪明的类比——LLM 的上下文窗口 = RAM，应该有专门的内存管理器。

MemGPT 把记忆分成三层：

Core Memory：始终在 context window 里的关键信息，像 RAM
Recall Memory：可检索的对话历史，像磁盘缓存
Archival Memory：冷存储，需要工具调用才能访问，像归档

之后这个团队把研究改成了产品，公司改名 Letta。今天你看到的 Mem0、Letta、A-Mem 这些 memory layer 产品，全是 MemGPT 这个 hierarchical memory 思路的工程化。

2024 全年：百花齐放，但谁都没跳出 Reflexion + Voyager 的框架

这一年出来的东西是真的多：

APE / PromptBreeder / SPO / TextGrad：自动 prompt 优化方向
Mem0 / A-Mem / MemInsight / Memory-R1：memory 管理细节
DSPy：把 prompt 优化做成模块化框架
AgentSquare / EvoAgent / ADAS / AFlow：用进化算法搜 agent 架构

仔细看一遍这些工作——没有一个改了模型参数。全在玩 context evolution。Reflexion 把语言反馈作为"梯度"的思路、Voyager 把 skill 作为可重用单元的思路，在这一年被反复以各种角度细化。

我说这话不是贬低这些工作。Mem0 和 Letta 让"agent 有记忆"这件事工程上可用了；DSPy 把 prompt engineering 工业化了。但从研究范式上看，2024 整年没有跳出 2023 那两篇祖师爷设定的框架。

2025.04 ChatGPT 全局 memory——产品端第一次大规模落地

4 月 10 日 OpenAI 给所有 Plus / Pro 用户开了 cross-chat memory：ChatGPT 能引用你所有过往对话的内容。6 月免费用户也开了一部分。

技术上没什么新东西——就是把过去聊过的内容索引起来，每次对话开始时把相关 chunk 塞到 system prompt 的 "Model Set Context" 段。Simon Willison 在 2025 年 5 月那篇 "I really don't like ChatGPT's new memory dossier" 里直接表达过不满——它会基于你完全不希望它参考的过往对话来推测你。

这件事的意义在产品而不在技术：它证明了 cross-session context 这件事在 mass-market 是可行的。后面所有 agent 的 memory 设计都要面对一个事实——用户对"AI 记住我什么"这件事的容忍度是有限的，得给细粒度的 forget / disable 选项。

2025.04 SkillWeaver——把 Voyager 思路搬到 Web

OSU NLP 组发了 SkillWeaver，做的事是 Voyager 的 Web 版本：让 agent 在浏览器上自动尝试 → 把成功的轨迹蒸馏成可重用的 Python API → 下次同类任务调 API。

数字：WebArena 上相对成功率提升 31.8%，真实网站上 39.8%。还有一个我觉得更有意思的数字——强 agent 合成的 API 让弱 agent 表现提升 54.3%。这是 skill transfer 第一次有这么明显的实证。这意味着"积累的 skill 库"可以作为一种独立资产存在，不绑定具体模型。

2025.05 Alita——动态 MCP 生成

Tencent 团队发了 Alita：用很少的预设，让 agent 根据任务动态生成 MCP（Model Context Protocol）。GAIA benchmark 上 75.15% pass@1，87.27% pass@3。

这条路有意思的地方是：它把 MCP 这个原本由开发者定义的协议，变成了 agent 自己写出来的产物。换句话说，agent 在运行时自己造工具给自己用。这是 Voyager 的代码 skill 思路在 MCP 时代的延续。

2025.07 GEPA——这条线上最强的"非新"突破

UC Berkeley 那篇《GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning》，论文标题就给整个领域定了一个反向论断——用 reflection + 进化搜索，能比强化学习更好地优化文本组件。

GEPA 的核心算法：

跑一组 prompt 候选
收集每个候选的完整 execution trace（不只是 reward 标量，还包括 error message、reasoning log）
用 LLM 读完整 trace 反思，提出针对性修改
维护 Pareto frontier 而不是单一最优——保留在不同任务上各擅胜场的候选
下一轮变异从 frontier 采样

数字相当吓人：比 GRPO 强 6-20%，用 35 倍更少的 rollout。在 prompt 优化领域比 MIPROv2 强 10% 以上（AIME-2025 上 +12% accuracy）。

为什么这件事重要？因为它戳穿了一个隐含假设——很多人默认"要做 self-improve，必须改参数（RL/SFT）"。GEPA 说不必须。很多场景下，深度 reflection + 进化搜索 + Pareto 多样性维护，效果就已经超过 RL 了，而且不用 GPU 训练。

现在 Hermes Agent 的 self-evolution 模块直接接的就是 DSPy + GEPA。这意味着 GEPA 已经从论文成果开始进入产品。

2025.07 A Survey of Self-Evolving Agents——第一篇系统综述

厦大等团队的这篇综述（arxiv 2507.21046）值得每个搞这块的工程师读。它给出了第一个完整的分类框架：

维度	分支
What to evolve	Models（参数）/ Context（memory + prompt）/ Tools / Architecture
When to evolve	Intra-test-time（单任务内）/ Inter-test-time（跨任务）
How to evolve	Reward-based / Imitation / Population-based (evolutionary)
Where to evolve	General / Coding / GUI / Finance / Healthcare / Education

把这个框架记住，几乎所有 "self-evolve" 论文你都能立刻定位它在哪个格子。下一节横向对比会用到。

2025.10-11 Anthropic Claude Code Dream——"梦境"巩固记忆

Anthropic 在 Managed Agents 里安静地上了一个叫 Dream / Auto Dream 的功能，没有大张旗鼓发布。

机制借鉴神经科学——人睡觉时大脑会回放白天的经历、识别 pattern、丢弃噪音、把短期记忆固化为长期记忆。Anthropic 的 Dream 做的是同样的事：定时扫描 agent 过去的 session 和 memory store，抽取 pattern，把有用的部分巩固，把噪音清掉。

我读了不少二手分析，最关键的几条：

跨 session 才能看到的 pattern：单个 session 内 agent 看不到自己反复犯的同类错误
同一团队共享 pattern：多个 agent 共同收敛到的工作流可以被识别和强化
24 小时自动触发：不需要人手动维护

这个功能目前 research preview，得申请。但思路上看，它就是 Reflexion 的产业级跨 session 包装——单 session 内的反思（Reflexion 干的）扩展到跨 session 的 pattern consolidation。

2025-2026 Hermes Agent——开源 self-evolution 的完整工程实现

我前一版对 Hermes 写得太浅。这次去读了它的文档和 DeepWiki 源码索引，才把真实架构看清楚——这玩意儿比我想象的更系统。

核心 Agent 类：AIAgent in run_agent.py。这是单一 agent core，gateway、CLI、ACP server、cron scheduler 全部都用这同一个 core——保证行为跨平台一致。

插件发现三层：~/.hermes/plugins/（用户级）、.hermes/plugins/（项目级）、pip entry points（包级）。两种特殊插件：memory provider 和 context engine，每种同时只能激活一个。

工具注册链：tools/registry.py（无依赖，被所有工具文件 import）→ tools/*.py（各自调用 registry.register()）→ model_tools.py（触发工具发现）。

存储：SQLite + FTS5（全文搜索）。具体在 hermes_state.py 和 gateway/session.py。这意味着 Hermes 的 memory 不只是塞到 prompt 里，还能跨 session 全文检索。

自动 skill 蒸馏：5+ tool calls 触发一次"复杂任务"判定，自动从对话历史抽取 pattern，生成 SKILL.md。SKILL.md 直接用 Anthropic Agent Skills 开放标准的格式（下一节讲）——章节固定为 When to Use / Prerequisites / How to Run / Quick Reference / Procedure / Pitfalls / Verification，每个 skill 约 100-200 行。

Curator（v0.12+）：后台 cron 进程，按周期对整个 skill 库做 grade / consolidate / prune。还有一个相关项目 SkillClaw——agentic skill evolution 框架，做跨 session / 跨设备 / 跨用户的 skill 去重、改进、合并。

进化优化版：hermes-agent-self-evolution 仓库接了 DSPy + GEPA，把 skill、prompt、code 全部当成可进化对象。

我对 Hermes 这次的判断是——这不是简单的 self-evolve 玩具，是一套和 Anthropic 标准互通的、可在生产环境跑的开源系统。它和 Claude Code Dream 的关系不是"竞品"，是"同一个标准下的两种实现"——Claude 用闭源 Managed Agents，Hermes 用开源插件架构，但 SKILL.md 格式互通。

如果你想看真正的 self-evolve 工业级开源实现长什么样，读 Hermes 的源码比读任何论文都更直接。

2025.10–11 Anthropic Agent Skills 开放标准——被很多人没意识到的范式定型

我前一版完全没提这件事，这是最大的一个漏洞。

2025 年下半年，Anthropic 工程团队（Barry Zhang、Keith Lazuka、Mahesh Murag）发了一篇博客《Equipping agents for the real world with Agent Skills》，把 SKILL.md 这个格式正式发布为跨平台开放标准，独立网站 agentskills.io 是 spec + reference SDK 的发布地。

到 2026 年初的采用情况：

Microsoft（VS Code、GitHub Copilot）
Cursor、Goose、Amp、OpenCode 等开源 coding agent
Anthropic 自己的 anthropics/skills 仓库 20k+ stars
起步合作伙伴 10 家企业软件

Agent Skills 的核心设计是 Progressive Disclosure（渐进式披露）——这一点值得每个做 agent 的人理解：

加载阶段	内容	什么时候
Discovery	只加载 name + description	Agent 启动时全部预加载到 system prompt
Instructions	加载完整 SKILL.md	Claude 判断 skill 相关时按需加载
Execution	加载附加 markdown（FORMS.md、REFERENCE.md）和可执行脚本	真的要用时才加载

实证数据：同等任务复杂度下，三层 progressive disclosure 比 single-prompt 全量塞入降低约 40% token 消耗，任务完成准确率提升 15-20%。

为什么这件事重要？因为它解决了 skill library 的一个老大难——skill 多了，context window 就被占满了。Voyager 那种把所有 skill 塞 context 的做法在 skill 库小的时候 OK，库大了就崩。Progressive disclosure 用文件系统当 backing store，模型只在需要时才加载到 context。Anthropic 选择 markdown 而不是 YAML 或 JSON，是为了同时满足"机器可解析"和"人类可读"。

SKILL.md 必须有 YAML frontmatter，至少包含 name 和 description 两个字段。Frontmatter 下面是 markdown 指令，支持脚本、引用、资产等子目录。这套规范现在是 Hermes、Cursor、Microsoft 都遵守的事实标准。

我之前把 skill library 完全当 Voyager 衍生的研究概念在讨论，没意识到工业界已经有统一标准——这是真实疏漏，必须纠正。

2025.05-07 MemOS——把 KV-cache 也当一等 memory 来管

中国 memtensor 团队 2025 年发了两篇 MemOS 论文（arxiv 2505.22101 短版，2507.03724 完整版），定位是"LLM 系统的 memory operating system"。这个工作我前一版也没提，必须补。

MemOS 的核心论断：当前 LLM 的 memory 架构是残缺的，只有两种——参数记忆（weights）和 ephemeral 激活记忆（KV-cache）。中间没有可调度的统一层。MemOS 加入了第三种，并把三种统一在一个抽象下：

Memory 类型	物理存储	特征
Parametric Memory	模型 weights	训练时编码，推理时不可改
Activation Memory	KV-cache、attention pattern	推理时临时存在，受 context window 限制
Plaintext Memory	外部文档、prompt 拼接	可编辑、可检索、持久化

MemCube 是 MemOS 的核心创新——把三种异构 memory 用同一种数据结构封装，每个 MemCube 既有 semantic payload 也有 metadata（来源、生命周期、调用语义）。配合 MemScheduler 和 MemOperator，三种 memory 第一次有了统一调度、访问控制、生命周期治理。

最让我意外的一个实验数据——MemOS 把常用 plaintext memory 预转换成 KV-cache 格式，首 token 时间降低 91%，输出质量不变。这是把 plaintext "热身"成 activation 的工程化实现。

把 MemOS 和我前面讲的 MemGPT/Letta 比一下：

MemGPT/Letta：把 LLM 当黑盒，外挂 OS-style memory hierarchy（Core / Recall / Archival）
MemOS：把 LLM 内部的 KV-cache 也作为可调度资源，三种 memory 统一抽象

MemOS 的雄心更大。MemGPT 解决的是"context window 不够用"，MemOS 解决的是"整个 LLM memory 系统应该有 OS 级别的抽象"。

这是当下中国 AI 研究在 self-evolve 方向最有分量的一篇工作。我之前因为信息源主要来自英文渠道，漏掉了——也是疏漏。

2025-2026 agent memory 商业生态：Mem0 / Letta / Zep / Cognee 等

把 agent memory 当独立 layer 卖的公司这两年起来了一批。我前一版只提了 Mem0 和 Letta，太浅。横向对比一下当下主流：

产品	技术路线	最适合的场景
Mem0	hybrid：vector + graph + key-value，自动从对话抽事实并路由到对应后端	简单 chatbot 的 memory layer，drop-in 集成
Letta (前 MemGPT)	OS 风格分层 memory（Core / Recall / Archival），agent 自己写 `core_memory_replace()` 调用	长周期 agent（多天运行不丢上下文）
Zep	时序知识图谱（基于开源 Graphiti 引擎），每个事实有 validity window	企业级、状态频繁变化的场景，能查"用户 Q3 前的偏好"
Cognee	把非结构化文档 ingest 成知识图谱，再做推理	深度知识检索
Cloudflare Agent Memory	内置在 Cloudflare Workers AI 里	已在 Cloudflare 生态的简单场景
EverMind、LangMem、Hindsight、Memvid 等	各种细分定位	看 use case

社区里 Letta 的讨论帖结论很有意思——没有一个产品在所有维度都最好。简单 chatbot 用 Mem0，企业复杂状态用 Zep，长周期 agent 用 Letta，深度知识检索用 Cognee。memory layer 已经成为一个独立的、有商业供给的赛道，不再是研究阶段。

这件事对工程师的实际意义是——当你做一个 agent 产品，"memory 怎么做"不应该自己从零写，应该选一个合适的现成 layer。从零写一个能跑的 memory 系统现在的工程量等价于从零写一个数据库——没必要。

2026 早期：Cursor / Claude Code 内置 memory 进入主流

到 2026 年初这件事在 mass-market 上彻底平民化：

Claude Code：CLAUDE.md（人写）+ Auto Memory（Claude 自己写），4 层目录架构（项目 / 用户 / 组织 / 共享），25KB 索引上限
Cursor：完全不同的路线，用 tree-sitter 把代码 parse 成 AST，靠索引代码本身当 memory，不做总结
AGENTS.md：跨工具的开放标准，被 GitHub Copilot、Gemini、Codex 等都支持

NexusTrade 那篇对比文章下了一个我觉得正确的判断：Cursor 的 memory 路线是"信任代码本身"，Anthropic 的路线是"信任自己维护的笔记"。前者不解释、只索引，后者解释、写笔记。对软件开发场景，Cursor 这条路是更可信的——代码本身永远是 ground truth，笔记可能 stale。

横向：当下生态全景

把上面所有系统按综述给的 What/How 框架重新摆一遍，能看清楚谁在做什么：

按"改什么"分类

维度	代表系统	关键约束
Models（参数级）	SCA、Self-Rewarding、SELF、SCoRe、RLHF 各种	训练成本高、可能灾难性遗忘、需要安全验证
Context - Memory	MemGPT/Letta、Mem0、A-Mem、ChatGPT Memory、Claude Dream、Codex Memory	上下文窗口有限、记忆检索是另一个搜索问题
Context - Prompt	APE、PromptBreeder、DSPy、GEPA、TextGrad	优化算法本身的成本（rollout、reflection 次数）
Tools - Creation	Voyager、CREATOR、Alita、SkillWeaver、Hermes Skills	skill 库的质量保证（GEPA 试图解决）
Tools - Management	CRAFT、ToolGen	skill 检索准确性
Architecture	AgentSquare、EvoAgent、AFlow、ADAS	搜索空间巨大，难以 evaluate

真正改参数的工作（少数派，但才是"真 self-evolve"）

这一类的代表是 Self-Challenging Agent (SCA)、Self-Rewarding Language Models、SCoRe。它们做的事：

让模型自己出题（self-challenge）或自己评分（self-reward）
用模型生成的反馈做 RLHF / DPO，更新参数
循环

这是经典 ML 范式套上了 LLM 自评估。它的优势是模型本体真的变强了，劣势是：

训练成本高，单个 iteration 要跑 GPU 集群
容易陷入"自我奖励陷阱"——模型学会刷自己的 reward 而不是真的变强
灾难性遗忘很难控制
没法在用户侧做，只能在厂商侧做

所以你看 OpenAI / Anthropic / Google 三家闭源大厂悄悄在做参数级 self-evolve，但开源生态全在做 context-level。这不是技术能力差别，是部署边界——参数级演化必须在训练管线里做，开源用户拿不到训练管线。

各家产品的横向比较

产品	路线	长板	短板
ChatGPT Memory	全局 cross-chat 关键事实	用户体验流畅、隐私控制清晰	容易 over-personalize、Willison 那种"AI dossier"焦虑
Codex Memory	借 ChatGPT 全局记忆	思考阶段和实现阶段连通	跨 ChatGPT-Codex 切换时上下文断裂仍存在
Claude Code CLAUDE.md + Dream	人写 + Claude 自写 + 跨 session 巩固	简单透明，4 层架构清晰	25KB 上限，没有 RAG 支撑
Cursor	tree-sitter AST 索引代码	不会幻觉、不会 stale	不做"经验积累"，只有"代码当下状态"
Letta / Mem0	独立 memory layer 产品	跨 agent 框架通用	引入新组件，集成成本
Hermes Agent	完整开源 self-evolve loop + DSPy/GEPA	透明可改、范式最完整	工程复杂、需要会用 DSPy
AGENTS.md	跨工具开放标准	跨厂商可移植	还是静态文件，谈不上"进化"

真正"新"的工作是哪几个

我自己读完所有这些资料后，觉得真的有新意的工作就这几个：

GEPA (2025.07)：用 reflection + Pareto frontier 在 prompt 维度打败 RL。这是范式级突破，可能改写未来 2-3 年的 agent 优化路线。
Alita (2025.05) 的动态 MCP 生成：让 agent 自己写工具协议给自己用，超出了 Voyager 单纯写代码 skill 的范畴。
SkillWeaver 的 cross-agent skill transfer (54.3% 提升)：第一次实证了 skill 可以独立于 agent 存在，跨实例转移。
Claude Code Dream 的跨 session pattern consolidation：把 Reflexion 从 episode-level 升到 lifetime-level 的产品级实现。

其他大多数工作要么是工程细节优化，要么是 Reflexion + Voyager 的衍生包装。这不是贬义——工程细节优化和衍生包装本身有产业价值。只是要清楚谁是骨架谁是肉。

横纵交汇：几个判断

判断 1：「Context 自进化」是当下唯一商业可行的路径，但它有天花板

为什么大家都在做 context evolution 而不是 model evolution？因为后者的成本结构在 mass-market 上不可行。每个用户都让模型 fine-tune 自己的副本，硬件成本爆炸；不让 fine-tune 又起不到效果。

Context evolution 的好处是纯软件成本——memory 存到 SQLite、向量库、markdown 文件里，推理时塞进 prompt 就行。每个用户的"经验"互不干扰，隐私边界清晰。

但天花板也清楚——Context 窗口有限、检索是另一个问题、cross-session 一致性靠工程拼起来。Anthropic 的 25KB 索引上限就是这个天花板的具体数字。当用户的"经验"超出这个数字，你必须做选择性遗忘——也就是说 agent 必然忘事。

判断 2：GEPA 论文是这两年看到最关键的范式转变信号

让我把 GEPA 那篇论文标题再放一遍：

Reflective Prompt Evolution Can Outperform Reinforcement Learning.

这句话的潜台词非常重——很多场景下不需要训练 GPU，只用 inference + reflection 就能达到比 RL 更好的效果。如果这个结论稳得住，未来 2-3 年的 agent 优化基础设施会发生根本性重组：

个人开发者也能做 self-evolve（之前要训练管线，现在只要 API）
闭源大厂的"训练优势"在 prompt-level 优化上被相对削弱
DSPy 这类 prompt 框架会变成核心基础设施（Hermes 已经这么做了）

我不敢断言 GEPA 一定就是未来，但它至少证明了——"必须改参数才能让 agent 变强"是一个被打破的假设。

判断 3：当前所有 self-evolve 产品都解决不了一个核心问题——经验质量参差不齐

这是我自己最近用 Claude Code 和 Codex 的体感。memory 会自动记下来的"经验"质量很不稳定——有些是对的、有用的、能复用的，有些是当时的偶发情况、不应该泛化的、用了反而出错的。

Anthropic Dream 的设计已经显示他们意识到了这点——所以才有"扫 pattern、丢噪音、巩固有用的"。但 "什么是有用的"这件事本身需要判断力，目前所有产品的判断都是用 LLM 自己评判 LLM 的 memory——这又回到了我们在测试那篇文章里讨论的 LLM-as-Judge 偏见问题。

Hermes 的 Curator 也好、Claude Dream 也好、ChatGPT 的 memory 也好——本质都是"用模型判断模型产生的经验"。这个回路有内生缺陷：没有外部 oracle 校准，judge 自己的偏见会被放大成 memory 的偏见。

所以 self-evolve 的下一个真正的瓶颈，不是"能不能积累经验"，而是"能不能可靠地分辨经验的质量"。这件事目前没人解决。

判断 4：中美生态在这条路上的分叉

OpenAI / Anthropic / Google：闭源训练管线 + 产品级 memory（ChatGPT Memory、Claude Dream、Gemini 个性化）。他们的优势是同时握有"改参数"和"改 context"两条路。

字节 / 阿里 / 智谱：豆包 / 通义 / 智谱清言。memory 功能都有，但底层模型层面公开的 self-evolve 研究相对少。FullStack Bench 那种 evaluation 工作做得很扎实，但 self-evolve 这条技术路线的产业投入相对低调。

开源社区（Hermes、Letta、Mem0、DSPy/GEPA）：填补开源用户拿不到训练管线的空白。这条路把 self-evolve "民主化"了——不需要 GPU 集群也能做。Hermes 是当下最完整的代表。

中国厂商在这条线上声音相对小，我猜测原因有二：一是国内 to C agent 产品形态还在探索（豆包 vs ChatGPT 的 memory 体验差距比模型本身的差距大）；二是 GEPA 这类用反思代替训练的范式还没大规模在国内被论证或落地。

判断 5：用户预期和实际能力的差距是这条线最大的产品挑战

用户期望中的 self-evolving agent 是这样的：「用得越久越懂我，从我的反馈里学会避免犯过的错，对我的偏好越来越精准。」

当下产品实际能给的是：「在 system prompt 里塞一段从过往对话里抽出来的 markdown，每次推理时模型读一下。」

这两者的差距巨大。前者是参数级的"内化"，后者是上下文级的"参考"。模型每次推理仍是 stateless 的，它只是有一个不断更新的便签本。用户感受不到"它真的变懂我了"，因为它确实没有——它只是每次开始前看了一眼便签。

这是当下"AI 有了记忆"宣传话术和实际体验的根本错位。能否突破取决于：要么 context engineering 进化到能让用户感受不出 stateless 的程度（GEPA 这条路）、要么真的做出能在用户侧便宜地 fine-tune 的方案（LoRA 个性化的方向）。

第一性原理：到底什么算"学习"

剥到底层，self-evolve 这件事真正问的问题是——Agent 能不能从经验里变强？

让我把"变强"这个词拆细：

三层"变强"的定义（和 CoALA 框架对齐版）

我前一版自己造了 Level 1/2/3，这次和 CoALA / MemOS 的标准术语对齐重写一遍：

我的通俗叫法	CoALA 术语	MemOS 术语	含义	谁在做
Level 1 - 参数级学习	（CoALA 不展开）	Parametric Memory	模型 weights 改变，离开 context 也变强	OpenAI/Anthropic/Google 训练管线（不对用户开放）；持续学习方向有 EWC 等
Level 2a - Skill 级学习	Procedural Memory	（Plaintext + 调用逻辑）	积累可重用的工具/代码/MCP	Voyager、SkillWeaver、Alita、Hermes、Agent Skills 标准
Level 2b - Activation 级	Working Memory	Activation Memory	KV-cache 级别的"热"记忆	MemOS 的核心创新（把 plaintext 预转 KV-cache）
Level 3a - 事实/偏好	Semantic Memory	Plaintext Memory	抽象后的事实和偏好	ChatGPT Memory、Claude CLAUDE.md auto memory
Level 3b - 经历日志	Episodic Memory	Plaintext Memory	具体的过往 session	Letta Recall/Archival、Hermes session SQLite

CoALA 还命名了一个关键操作——consolidation：从 Episodic 到 Semantic 的转化。"记下这次对话"是 Episodic 写入，"从一堆对话里抽出'用户喜欢简洁回答'这个偏好"是 Episodic → Semantic 的 consolidation。Anthropic Dream 和 Hermes Curator 做的就是这件事。

用户口中的"agent 自进化"本能指的是 Level 1（参数级）——它真的"懂"了。

产品给到的体验绝大多数是 Level 3a + 3b（Semantic + Episodic Memory）——它"看了笔记"。

研究前沿在 Level 2（Procedural + Activation）——Skill 是可执行代码，比纯文字 memory 强；MemOS 让 plaintext 能预热成 KV-cache。但都没有改参数。

为什么三层差距这么大

成本和安全两个维度的乘积：

Level 1 (参数级)：单用户成本爆炸 + 安全风险高（可能学坏）
Level 2 (Skill 级)：单用户成本中等 + 安全风险中（skill 可能错）
Level 3 (Memory 级)：单用户成本低 + 安全风险低（最多召回错）

商业落地必须沿着成本递增、风险递增的反方向走，所以产品先做 Level 3，再尝试 Level 2，Level 1 是闭源大厂的护城河。

"Context 工程即 self-evolve" 是一个有意为之的混淆

我觉得这个混淆不是无意的。当 OpenAI / Anthropic 说"我们的 agent 能学习了"，他们指的是产品形态上看起来像学习，但底层是 memory + RAG。这是营销，不是技术误解。

技术诚实的说法应该是：「我们做了一个 stateful 的 context engineering 系统，让 stateless 的模型表现得像 stateful。」

这不是贬低——这件事本身有巨大产业价值。但把它叫"self-evolution"会让用户的预期错位，最终伤产品口碑。

一个反直觉的结论：GEPA 也不是 self-evolve

按上面的严格定义，GEPA 也不改模型参数。它优化的是程序周围的 prompt 和 code，模型本体没动。

所以 GEPA 算 Level 2.5——介于 Skill 级和 Memory 级之间。它的意义不在于"让模型变强"，而在于**"让模型表现得像变强"的成本骤降**——以前要 RL 改参数才能达到的效果，现在可以用 reflection + 进化搜索在 prompt 层做到。

这给我一个判断：未来 2-3 年里，"真正的"参数级 self-evolve 依然是闭源大厂的专利。开源生态和工程师做出来的所有"agent 自进化"产品，本质都是用 GEPA / DSPy / Reflexion / Voyager 这条 context evolution 路径，把"看起来在进化"这个效果做到极致。

给传统软件工程师的一个心智模型

如果你是从传统 backend / frontend 转过来理解这条线，可以用这个类比：

Level 1 参数级学习 ≈ 编译期改了二进制
Level 2 Skill 级学习 ≈ 运行时加载了新的插件 / 动态库
Level 3 Memory 级学习 ≈ 程序读了一份配置文件

按这个类比看，当下大部分"self-evolve"产品停在 "agent 能读自己生成的配置文件"这个层级。这件事工程上也很难、有价值，但它不应该被叫"自我进化"。

我倾向更准确的术语是 stateful agent 或者 agent with persistent context——既不夸张也不贬低，准确描述它在做什么。

关键参考

奠基论文：

综述与方法：

Skill / Tool 自生成：

工业产品：

工具与框架：

CoALA 与认知科学框架：

Anthropic Agent Skills 开放标准：

Hermes Agent 源码与文档：

MemOS 论文：

Agent Memory 公司全景：

LLM 之前的自进化历史：

写到最后我想再泼一次冷水。如果你看一些公众号或者营销文章在吹"我家 agent 已经能自进化了"，你大概率应该相信他们做的是 Level 3 - Memory 级。这不是骗你，只是术语被滥用了。下次看到"self-evolving"这个词，先问一句：「参数变了吗？」——大概率答案是没有。这时候这套系统也许仍然值得用，但你心里要有数它实际在做什么。

测试都分什么？从 Myers 1979 到 vibe coding 的完整地图

2026-05-17T16:00:00.000Z

最近这阵子，我越来越觉得 AI 写代码之后，测试这件事的位置不一样了。

以前测试是"我自己写的代码、自己再写一套测试盯着自己"，本质是和自己较劲。现在更多时候，是 Claude 或者 Cursor 给我吐了一段我没完全读懂的代码，我得想办法证明它没把别的地方弄坏。这两件事的心智模型其实差很多。

正好被一句话戳到——"难道就没有什么测试可以确定修改之后程序百分百符合需求？并且如果是 bug 修复或者在现有基础上修改，不会影响原有逻辑？"

我自己以前对测试的认识，也就是单元测试、冒烟测试、端到端测试这点东西。所以这次干脆把测试体系完整刨一遍，从 1979 年的 Myers 一直翻到 2026 年的 vibe coding。下面是横纵分析法的结果。

先把结论直接拍在这里：没有任何一种测试可以保证「百分百符合需求」。这件事在数学层面已经被证明不可能（Rice 定理），不是工程努力的问题。能做的只是组合不同的测试方法，把「未被发现的错误」的概率压到业务能接受的水位上。如果你接受这个前提，后面会好读很多。

纵向：测试是怎么走到今天这一步的

1957 年之前：测试就是 debug

最早的程序员根本没"测试"这个独立概念。代码跑通了算对，跑不通就改，测试和调试是一回事。直到 1957 年 Charles Baker 才第一次区分 "program checkout"（让程序能跑）和 "program testing"（验证程序解决了正确问题）。

1979：Myers 把整个行业的脑子翻过来

Glenford Myers 出了《The Art of Software Testing》，丢出一句颠覆性的话：

A test that reveals a previously undiscovered error is a successful test.

在这之前业界默认「测试通过 = 软件没问题」。Myers 反过来说，好测试是用来弄坏软件、找出错误的，全绿通过反而是测试的失败——因为这说明你的测试套件根本没本事抓真实存在的 bug。

负向测试、边界值分析、等价类划分这些今天还在用的东西，都是这个时期长出来的。从 1979 到 1982 年那几年，业界第一次把"测试员"当成"想办法弄坏软件的人"，而不是"按 case 跑一遍的人"。

1990：Beizer 的四阶段心智成熟度

Boris Beizer 在 1990 年总结了一个挺扎心的框架，把测试者的心智状态分成四级：

让软件能跑
想办法弄坏它
降低风险
把可测试性当成一种生命周期思维

我观察身边的团队，绝大多数卡在 1 和 2 之间，少数到了 3，到 4 的几乎没有。这就是为什么大家直觉上都觉得"测试很重要"，但工程层面普遍做不好——大部分人对测试的认知就停在 Phase 1。

1999–2002：TDD 和 Kent Beck

Kent Beck 在写 SUnit 的过程里提炼出"先写测试再写代码"这个反直觉的流程，写进了 Extreme Programming 和后来的 TDD 那本书。

TDD 容易被误解成"多写测试"。它的本质不是这个。TDD 是一个设计工具——用测试逼自己先想清楚接口，再想实现。测试只是副产物。这也是为什么有些团队 TDD 落不了地：他们以为是在学测试，其实学的是设计。

2004：Michael Feathers 给遗留代码定了义

Feathers 那本《Working Effectively with Legacy Code》给"legacy code"重新下了定义：没有测试的代码就是 legacy code，不管它多新、多漂亮。

这本书里他提出了一个我后来用过无数次的方法——Characterization Test（特征化测试，又叫 Golden Master）。原文这句话特别重要：

Characterization tests do not verify the correct behavior of the code, which can be impossible to determine. Instead they verify the behavior that was observed when they were written.

翻译成人话：你不知道这堆烂代码"应该"输出什么，但你能观察到它"实际"输出什么。把这些观察记下来固化成测试，就建立了一张安全网。以后任何改动，只要 golden master 输出变了，立刻报警。

这套思路在 PDF 渲染、报表生成、机器学习模型输出这种"输出复杂到没法逐字段写 assertion"的场景，是唯一可行的策略。ApprovalTests 工具链就是把这件事工程化。

2009：Mike Cohn 的测试金字塔

Cohn 在《Succeeding with Agile》里正式提出测试金字塔，比例 70/20/10。底层逻辑是反馈速度 × 维护成本 × 信心度这三者的平衡：单元测试毫秒级反馈、几乎零维护，但只能证明"零件是好的"；E2E 测试分钟级反馈、维护噩梦，但能证明"用户真的能用"。

这个模型统治了将近 15 年。但它的前提是 2009 年的世界：单体应用、桌面/Web 形态稳定、前端复杂度有限。世界变了之后，金字塔就开始松动。

2018：Kent C. Dodds 把金字塔翻过来

Testing Library 作者 Kent C. Dodds 提出了测试奖杯：底座变成 Static（TypeScript + ESLint），主力变成 integration。他的核心论断：

The more your tests resemble the way your software is used, the more confidence they can give you.

我特别赞同他对单元测试的批评。现代前端组件的 unit test 经常退化成"测实现细节"——你重命名一个内部变量、调整一下 React state 写法，单元测试就一片红，但用户体验完全没变。这种测试不是在保护你，是在拖累你。

这里还有个被很多人忽略的认知升级：TypeScript 本质上就是一个永远在跑、覆盖率 100%、零维护成本的测试套件。你定义了 function foo(x: number)，编译器就替你跑了"所有非 number 输入都应该报错"这个测试。Dodds 第一次把这件事正式画进了金字塔/奖杯里。

2018：Spotify 的测试蜂巢

几乎同时，Spotify 工程团队提出了测试蜂巢，专门针对微服务：主力是 integration，少量 implementation detail test，几乎没有 integrated test。

逻辑也很直接：一个微服务自身代码量很小，复杂度全在"和别的服务怎么交互"上。这种情况下死磕单元测试是抓小放大，应该把火力集中在 integration 上，用真实输入真实输出而不是 mock。

2010–2022：契约测试、混沌工程、属性测试进主流

这几个看起来无关的东西，其实回应的是同一件事：分布式系统让"改了不影响老逻辑"变得无比困难。

Pact (2013)：消费者驱动契约测试。下游消费者写一份"我期望你的 API 长这样"的契约，上游 provider 在每次 CI 里 replay。任意 consumer 期望的字段被你删了或者类型改了，构建立刻红。
Netflix Chaos Monkey (2011) → Simian Army：直接在生产里随机干掉节点、注入网络延迟、整片机房断电（Chaos Gorilla / Kong），逼系统证明自己的韧性是真的。
QuickCheck (1999, Haskell) → Hypothesis (2013, Python)：属性测试。不写"foo(2,3) 应该等于 5"，而是写"对任意 a, b: foo(a, b) == foo(b, a)"，框架自动生成成千上万的输入找反例。2025 年 OOPSLA 一篇实证论文发现，在 Python 项目里 property-based test 平均比手写 unit test 更容易杀死 mutation。

2022 到现在：LLM 把测试推到了风口

ChatGPT 之后这三年，整个行业第一次面对一个事实：代码生成成本接近零，但代码质量的方差被极度放大。

Veracode 2025 GenAI Code Security Report 跑了 100 多个 LLM、80 个真实编程任务，得出 45% 的生成代码引入了安全漏洞。USENIX 一份联合研究测了 16 个代码生成模型、57.6 万个样本，19.7% 的推荐包是幻觉包（根本不存在），其中 58% 的幻觉包名在多次查询中重复出现——意味着攻击者可以抢注这些幻觉包名做供应链投毒。

更具体的是 Stanford 那个早期研究：用 AI 助手的开发者比不用的开发者多 41% 引入安全漏洞，前提是他们信任 AI 生成代码而没做结构化验证。

测试的位置因此变了。它不再是"防止我自己写错"的安全网，而是"防止我没看懂的 AI 生成代码混进去"的过滤网。性质变了，方法论也得跟着变。

横向：测试方法的当下切面

我不按"形状"分，按"它能回答你什么问题"分。这才是真正有用的视角。

问题一：这段代码本身正确吗

方法	给你什么	致命短板	适合场景
Unit Test	单个函数/类的逻辑正确	测的是实现细节，重构容易失效	纯函数、算法、领域逻辑
Property-Based Test	用上千个随机输入找反例，自动 shrink 到最小复现	学习曲线陡，property 本身难写	序列化、数学算法、状态机
Mutation Testing	评估你的测试套件够不够狠	极慢，CI 跑不动	关键模块的测试质量审计
Fuzz Testing	用恶意/畸形输入找崩溃和漏洞	需要 harness 和 sanitizer	C/C++、解析器、API 边界

我自己写代码的体感是：unit test 给你信心，但属性测试加变异测试给你的是对信心的信心。Hypothesis 的文档里有句话我特别认：很多 bug 不是因为你写错了某个 case，而是因为你根本没想到那个 case 存在。属性测试就是用来对付"你不知道你不知道"的。

问题二：这些代码组合起来还正确吗

集成测试、契约测试、E2E、冒烟、视觉回归。这一类里我想专门聊聊契约测试，因为它是"修改不影响原有逻辑"这个老大难问题在微服务场景下的最佳答案。

传统做法是写 E2E 覆盖 A→B→C 的调用链，但 E2E 慢且脆。Pact 的思路反过来：B 服务的消费者 A 写一个 mock，"当我调你 GET /users，我期望拿到这个 shape 的数据"，这个期望被序列化成 contract 文件交给 B。B 在自己的 CI 里 replay 这个 contract——任意 consumer 期望的字段被你删了或者类型改了，B 的构建立刻红。

它把"你改了 API 几天后才发现下游挂了"这种最坑爹的微服务事故，压到了 PR 阶段就拦截。这件事的价值不是技术意义上的，是组织意义上的——它让上下游团队的预期变成了机器可验证的契约，不需要靠开会、Wiki 或者 IM 群同步。

问题三：这堆遗留代码我能不能动

这是我自己工作里最头疼的场景之一。

手里有测试、能用 regression suite 跑一遍的算幸运儿。真正难的是那种"没人懂这堆代码到底应该输出什么"的情况——这时候 Feathers 的 characterization test 就是救命的。

具体怎么用：先观察当前代码对一组典型输入的输出，把"现状"原封不动固化成测试。然后再开始改代码。只要你的改动让任何一条 golden master 输出变了，CI 就红。这里的精髓在于：在你完全不懂遗留代码业务含义的时候，"保持现有行为不变"本身就是一个可执行的需求。你不需要知道 calculateTax(order) 为什么对某个奇怪 case 返回 -1，你只需要知道改完之后它还得返回 -1。

这套方法处理遗留系统、处理 AI 生成的"我也不完全看懂的代码"、处理机器学习模型回归，是通用的兜底策略。我自己在几个老 Java 项目里用过几次，比想象的好用。

问题四：线上崩了会怎样

Load test、Stress test、Chaos Engineering、Canary、Feature Flag、Synthetic Monitoring。

Feature Flag 和 Canary 严格说不算测试，但它们是测试体系的最后一道防线，也是最重要的一道。LaunchDarkly 这类平台把"部署"和"发布"解耦：代码部署到生产但功能默认关闭，对 5% 用户开放观察指标，没问题扩到 25%、50%、100%。Gartner DevOps 调研说这套实践把部署风险降低了 70%。

为什么我把它当测试？因为它承认了一个残酷事实：所有测试都有遗漏，最终极的测试只能在真实生产流量上做——但你可以把爆炸半径控制到极小。这是 Beizer "Phase 3 降低风险"的工业级实现。

问题五：这东西在数学上一定是对的吗

形式化验证。这是离"百分百符合需求"最近的方法，但代价极大。

TLA+：Leslie Lamport 创造的规约语言，AWS 用它建模 DynamoDB、S3、EBS 等核心服务，找出过传统测试根本不可能发现的分布式 corner case（比如 8 步并发交错才能触发的不一致）。
Coq / Lean / Isabelle：交互式证明助手。CompCert（经过 Coq 证明的 C 编译器，研究证明它的代码生成层从未被发现过 bug，对比 GCC/LLVM 被 Csmith 模糊测试找出几百个）、seL4 微内核（经过 Isabelle 全代码功能正确性证明，约 9 千行 C 代码，投入了约 20 人年的证明工作）。

代价摆在这里你就懂为什么用的人少了：AWS TLA+ 模型每个核心服务的规约都要几周到几月。TLA+ 的语法对普通工程师"alien"，2025 年了"very few people actually use TLAPS"还是常态。

所以形式化验证的现实定位是：当 bug 的代价远超验证的代价时才用。飞控、医疗设备、加密协议、核心分布式协调。普通 CRUD 用它就是杀鸡用核武。

那"百分百符合需求"到底能不能做到

把上面所有方法摆在一起看，答案大概是这样的：

你的诉求	现实答案
百分百符合需求	数学上不可能。Rice 定理证明了对图灵完备程序的"任何非平凡语义性质"是不可判定的。
实践中尽可能接近	形式化验证 + 高质量 property test + mutation testing + 真实生产 canary。代价：人力 ×10。
正常工程预算下做到 90%+	测试金字塔/奖杯/蜂巢择一 + contract test + 完善 CI/CD + feature flag。这是大部分团队的最优解。

更关键的是：「需求」本身经常是不清楚的。BDD 和 ATDD 想解决的就是这个——逼业务方、产品、开发在动手前用 Gherkin 这种半形式化语言把"系统应该怎么表现"写下来。但实战里 Gherkin 容易退化成伪自然语言：既不像代码那么精确，又不像自然语言那么好读，最后变成开发的额外负担。

所以"百分百符合需求"这件事的真相是：它在数学层面不可达，在工程层面取决于你愿意付多少代价，在沟通层面取决于业务方愿意花多少时间把"需求"讲清楚。三层任意一层崩了，整件事就崩。

顺便说一下覆盖率

Martin Fowler 那篇 bliki 文章已经成经典，核心论点：

If you make a certain level of coverage a target, people will try to attain it. The trouble is that high coverage numbers are too easy to reach with low quality testing.

具体怎么"低质量地达到 100% 覆盖"：

Assertion-free test：写了 foo() 调用但不写 expect(...)，覆盖率工具看到这行执行了就算覆盖
Happy path only：所有分支语法上跑过，但只测了"正常"那一支
Mock 满天飞：所有外部依赖 mock 掉，覆盖率上去了但你测的根本不是真实行为

Fowler 给的健康指标：用心写测试自然到 80–90%，看到 100% 反而该警惕。

正确的用法是把覆盖率当探测器而不是目标。突然从 85% 掉到 70% 说明你新增的代码没测；某个文件长期 30% 说明这块是个雷区。至于该不该追到 95%，问 mutation testing——PIT 或 Stryker 跑一遍，存活的 mutant 多说明你的测试假覆盖率高、真探测力低。

AI 时代测试范式的重塑

把纵向和横向交起来看，能得到一些前两节单独看不到的判断。这部分是我自己最关心的。

测试金字塔从来不是教条，是经济学

为什么金字塔的形状一直在变？因为底层经济参数变了。

2009 年的世界里桌面 Web 单体当道，浏览器自动化贵且脆，所以经典金字塔成立。2018 年前端复杂度爆炸，TypeScript 把 static 变成了"免费测试"，Cypress 把 integration 成本拉低，于是奖杯起来了。同期微服务铺开，单服务代码少、服务间交互多，于是 Spotify 搞了蜂巢。

到了 AI 时代，参数又变了：写测试的边际成本被 AI 拉低，但读懂代码并相信它的成本反而上升。这个不对称会让测试形状再次翻转。Wiremock 那篇 2024 年的文章说得直接——"the testing pyramid is an outdated economic model"。当生成 unit test 几乎免费、但生成 integration test 仍然需要真实依赖时，金字塔底部会被无限拉宽，但那个宽底部的"真实信心增量"是递减的。

我自己最近的感受是：unit test 写得越来越快，但越来越像形式化的"装饰品"，给我真正信心的是 contract test、property test 和 canary。

AI 写代码暴露了一个被忽视已久的事实

传统工作流是「人写代码 → 人写测试 → 测试验证人是否理解」。这个循环的前提是：写代码的人理解代码。

AI 写代码打破了这个前提。Cursor 那篇 2025 年 11 月发的 difference-in-differences 研究《Speed at the Cost of Quality》得出一个让人不舒服的结论：用 Cursor 的项目交付速度上升，但代码质量指标显著下降。

为什么？因为人对 AI 生成代码的理解深度系统性下降。你没真正理解的代码，你写不出有意义的测试——你只会写"看起来覆盖到了"的测试。这就是 Stanford 那个 41% 的来源。

这导致的范式变化是：AI 时代的测试不能由写代码的人（AI 或者被 AI 牵着走的人）自己写，必须有独立的验证层。具体形态有几种：

不同 session、不同模型来 review（Aikido、Diffray 这类 AI code review 平台的核心做法）
形式化的输入输出约束（property-based test 不让你只测你想到的 case）
真实生产流量回放（contract test + canary + shadow traffic）
强制人工 approve 关键 diff（把"我看过了"做成 git 工作流硬约束）

「改了不影响老逻辑」在 AI 时代变得既容易又危险

容易：AI 可以瞬间为你生成 characterization test、golden master、property test。

危险：AI 也可以瞬间帮你"调整 golden master 让测试通过"。这是最隐蔽的回归。

ploeh blog 那篇 2025 年 11 月的《100% coverage is not that trivial》讲了一个具体场景：开发者让 AI 修一个 bug，AI 改了代码，同时"贴心地"改了原本通过的测试。CI 全绿，PR 合并，三个月后生产事故。

所以一条新的工程纪律正在浮现：任何 PR 里如果同时修改了实现和它对应的测试，必须人工 review 测试改动的必要性。这件事我自己在 Code Review 里现在会专门看，有时候 AI 改测试改得比改实现还流畅，但你回头一想，这测试不就是来抓你这个改动的吗，怎么能让它自己改自己呢。

另一种测试：AI Agent 的语义评估是怎么回事

写到这里其实还有半个问题没答。前面讲的全是「程序输入 X、程序输出 Y、你用 assertion 判断 Y 对不对」这一类。但 AI 时代多出来一个新场景：我让 Agent 帮我订机票、写邮件、修 bug、查资料，它输出的是自然语言、是工具调用序列、是一连串决策——这种东西怎么测？

这其实不是"传统测试的延伸"，是另一种工程问题。先把结论钉死：传统软件测试的 oracle 是"确定值"，AI 任务的 oracle 是"概率分布"。把传统测试经验直接平移过来，会得到一个看起来严谨、实际失效的体系。下面是为什么。

从 BLEU 到 LLM-as-Judge：语义评估这条线

最早搞"语义评估"的是机器翻译。2002 年 IBM 的 Kishore Papineni 提出 BLEU，把模型译文和参考译文做 n-gram 重叠率匹配。BLEU 的设计哲学非常工程师——把"译得好"转换成可计算的数字。

但它从第一天就有致命缺陷：看不懂同义词、看不懂语序、看不懂换种说法表达同一个意思。2018 年之后 BERTScore 用 contextual embedding 余弦相似度替代了 n-gram 匹配，第一次能抓住语义。但它仍然是 reference-based——你得有"标准答案"才能评。到了 ChatGPT 这种开放式生成（"帮我写一封请假邮件"——没有标准答案），整个 reference-based 范式就崩了。

转折点是 2023 年 6 月 Lianmin Zheng 团队那篇《Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena》。结论非常有力：强 LLM 当 judge，和人类专家一致率超过 80%，已经达到专家之间的一致率水平。LLM-as-Judge 从此成为业界默认方法。

但同一篇论文也直接戳穿了三个原罪：

Position bias：同一组对比，A 放前面和 B 放前面，judge 结果可能不一样
Verbosity bias：长答案更容易得高分，哪怕内容更烂
Self-enhancement bias：GPT-4 当 judge 偏好 GPT-4 的回答，Claude 当 judge 偏好 Claude 的回答

2024 年又有研究补了一个更狠的——Style bias 强度 0.76-0.92，所有主流 judge 都强烈偏好 markdown 格式的回答。这个数字意味着你写得乱但内容更对，judge 给你低分；写得花哨但内容平庸，judge 给你高分。Karpathy 2025 年底那段吐槽印证了这点——他自己用 Gemini 用得很爽，但他看自家模型的偏好却是 GPT-5.1，说明 LLM 之间存在共享偏见，而这套偏见和人类客户的真实需求是错位的。

应对方式是已知的，但都不便宜：位置 swap、多 judge ensemble、明确的 rubric、pairwise（让 judge 比较两个输出而不是绝对打分——绝对打分时偏见更大）。

Agent benchmark 群雄并起

LLM 不只回答问题，还要做事——调用工具、写代码、跑命令、规划多步。评估必须跟着升级。

Benchmark	测什么	关键设计
SWE-bench	真实 GitHub issue 修复	跑单元测试判断通过，2294 个 Python 项目 issue
SWE-bench Verified	同上，但 500 个人工核验子集	OpenAI 雇专业开发者剔除歧义任务
τ-bench	多轮工具调用 + 用户模拟	引入 pass^k 衡量可靠性
WebArena	浏览器操作	812 个真实网页任务
AgentBench	跨场景架构对比	8 个不同领域并排测
GAIA	通用助手	人类容易、AI 困难

这里要专门聊 τ-bench 的 pass^k——它发明了一个新指标：agent 必须在 k 次独立尝试中全部成功才算通过。区别于传统的 pass@k（k 次里至少一次成功）。

为什么这个指标重要？因为它把 reliability（可靠性）从 benchmark 缺失的维度补上了。一个 pass@1 = 60% 的 agent 听起来还行，但同样的 agent pass^8 可能只有 25%——同一个 case 跑 8 次只有 25% 概率全部跑对。

放到生产环境想想：很多团队上线 agent 前看 pass@1 觉得不错（"我们 agent 70% 成功率"），上线后被用户投诉淹没——因为同一类问题反复出现，多次失败的概率远高于 30%。Agent 在生产环境真正的挑战不是"能不能做对"，而是"能不能稳定地做对"。

还有一个被 Berkeley RDI 2025 年戳穿的事——主流 benchmark 都可以被刷分。他们发现 SWE-bench、WebArena、OSWorld、GAIA、Terminal-Bench、FieldWorkArena、CAR-bench 等八个 benchmark 都可以被精心设计的 agent 达到接近满分，但实际没解决任何任务。具体怎么刷不展开，思路就是利用评测脚本的隐含假设和状态泄露。这件事的意义远超 benchmark 本身：任何静态评估一旦公开广为人知，模型训练就会把它当成 reward signal，从而失去信号价值。这是 AI 评估和传统软件测试的本质差异——代码不会因为公开了测试集而变形，但模型会。

Anthropic 那篇博客是目前最完整的方法论

Anthropic 2024 年发的《Demystifying evals for AI agents》是我看过最实用的一份指南。他们给了一个概念框架，每个工程师都该记住：

概念	含义
Task	一个测试（有输入、有成功标准）
Trial	一次尝试（因为不确定性，需要多次跑）
Grader	评分逻辑（代码 / 模型 / 人）
Transcript	完整记录（输出 + tool calls + reasoning）
Outcome	最终环境状态（不只是模型说了什么）

三种 grader 各有定位。Code-based 最快最客观，但对合理的变化太脆。Model-based 灵活、能处理模糊场景，但本身有不确定性、有偏见，必须用人类标注校准。Human 是 gold standard，但贵且不可规模化。

最关键的一句话是这个：

Grade what the agent produced, not the path it took.

这句话对传统工程师极其反直觉。我们的本能是测"代码内部状态对不对"。但对 agent，路径不唯一是它的优势——同一个目标可以有十种合理路径。强测路径就是把灵活性测没了。

具体怎么落地：用户问"帮我比较 A 和 B 两个产品"，grader 不应该问"agent 是否先调 search 再调 compare"，而应该问"最终输出是否真的对比了、引用是否真实、结论是否合理"。Anthropic 还有一条很实用的小建议——让 LLM judge 可以返回"Unknown"。强制 judge 必须给 pass/fail 会让它在不确定时编理由，反而劣化评估质量。

各家工具横向对比

工具 / 方法	出品	特点	我的体感
OpenAI Evals	OpenAI 开源	YAML + JSON 配置，社区注册式	轻量，模板化，适合做对照实验
Demystifying evals 工程方法	Anthropic	不开源工具，发方法论博客	哲学指南，思维框架最清晰
LangSmith + agentevals	LangChain	产品化最彻底，trajectory evaluator 即开即用	落地快，但和 LangChain 生态强绑定
FullStack Bench + SandboxFusion	字节	3374 题、11 个领域、16 种语言，配套 23 语言 sandbox	中文 + 多语言友好，全栈而非纯算法
MarsCode Agent	字节 SE Lab	SWE-bench Lite 上拿过第一	国内开发者熟悉度高
Multi-SWE-bench	字节	第一个多语言代码修复 benchmark	终于不再只测 Python

一个观察是中美评估生态正在分叉。OpenAI / Anthropic / LangChain 这一线主导英语 + Python 的 benchmark 和工具链。字节这一线偏多语言（Java / Go / Vue 等）和多领域（全栈而非算法）。这不只是地缘问题——评估标准本身决定了模型优化方向。中国开发者主要在意的场景如果没被 benchmark 覆盖，那么针对这些场景的差异化空间反而留给国内厂商。

我自己沉淀下来的几条经验

写到这里我想把这一节缩成几条能直接用的：

设计 eval 是产品工作，不是 QA 工作。Anthropic 那句"writing evals forces product teams to specify what success means"被低估了。你定义不出 eval，说明你没想清楚 agent 该做什么。把 eval 设计权丢给 QA 团队，等于放弃了产品定义。
pass@1 永远是骗自己。生产环境真正的指标是 pass^k，不是 pass@1。上线前至少跑 pass^5 看看。
多 judge 比单 judge 强得多。Karpathy 的 LLM Council 给的提示是对的：让结构上独立的模型互相 peer review，比指望单一 judge 客观要现实。
grader 必须用人类标注校准。LLM judge 不是免费午餐——它自己的可靠性需要先用 100-200 个人类标注 case 校准，否则你只是在用一个 black box 评估另一个 black box。
outcome > path。任何能用最终环境状态判断的，就别去测 path。SWE-bench 用"跑测试通过"做 grader 比"步骤评分"客观一万倍。
保留 hidden test set 并持续轮换。公开 benchmark 必然被 game，关键场景必须有内部不公开的评估集，并且定期换。

第一性原理：测试本质上在解决什么

剥到最底层，我觉得测试解决的是一个信息不对称问题——写代码的人想要的（需求） 和 代码实际做的（行为） 之间的不对称。所有测试方法都可以用这个框架重新解读：

Unit Test：以"代码作者"视角断言"我以为我写了什么"
Integration Test：以"模块组装者"视角断言"它们组合起来应该如何"
E2E / Acceptance Test：以"用户/业务方"视角断言"我看到什么才算对"
Characterization Test：放弃断言"应该如何"，转而记录"实际如何"——承认有时候业务方自己都说不清需求
Property Test：用"普适不变式"代替"具体 case"——承认作者列不全所有 case
Mutation Test：测试"测试本身够不够好"——元层信息对称检查
Contract Test：在"提供者"和"消费者"之间显式化双方对接口的理解
Formal Verification：用数学逻辑彻底消除不对称
Chaos Engineering：承认"我们对生产环境的理解一定是错的"，主动去发现错的部分
Agent Eval：承认 oracle 本身是概率分布、不是确定值——评估对象从单一 trace 升到 trajectory cluster

不管方法怎么演化，绕不开三个底层约束。第一个是可观察性：你只能测你能观察到的东西，一个函数有 IO 副作用但你 mock 掉了，你就观察不到它对真实世界的影响。LLM 这一层更严重——你看不到模型内部，能看到的只有"输入 → tool 调用序列 → 输出"，模型为什么这么决策完全是黑箱。Anthropic 那条"读 transcript"其实是在用极不充分的信号去重建模型的内部决策。第二个是可重复性：传统软件追求"同输入同输出"，AI 系统连这个都做不到——浮点非结合性叠加 GPU 动态批处理让"temperature=0"也不能保证确定性。这就是为什么 agent 评估必须用 pass^k 这种分布指标，而不能用 pass/fail 这种二元指标。第三个是不可判定性（Rice 定理）：对任意复杂的程序，你不可能写出另一个程序判断它"语义上是否正确"——这是数学硬约束。AI 评估在此之上又叠了一层"语义本身就是模糊的"，于是出现一个 AI 评估独有的新约束——对抗性退化：一旦评估方法被 model training pipeline 知道，它就会被针对性优化，从而失去信号价值。

第三条决定了"百分百符合需求"永远是一个不可达的渐近线。所有测试和评估方法的差异，只是它们在这条渐近线上的位置和成本不同。

为什么 AI 时代会重塑测试体系

因为它改变了根本的成本结构。

传统时代里写代码成本高、写测试成本中、审代码成本中，最划算的是把投资集中在最便宜、最高 ROI 的 unit test 上。AI 时代里写代码成本极低、写测试成本低、审代码成本高（因为不是你写的，你不真懂），生产事故的成本完全不变。最划算的就变成了"绕开人审局限"的方法：property test、contract test、canary、关键模块的 formal verification。

成本一变，最优策略立刻变。这就是为什么形式化验证、混沌工程、属性测试这些"小众"方法在 2024 年之后开始回潮——它们 40 年前就有了，但 ROI 一直不划算，AI 把审代码成本拉高之后，它们突然变划算了。

我自己最受用的一句话

不要追求"确定我的代码是对的"——这是个伪命题。要追求"持续缩小'我不知道我的代码哪里可能错'的范围"——这是个可行的工程问题。

具体怎么做：业务核心路径用 property test + characterization test + contract test 把"我不知道我不知道"压低；高频变化模块用 mutation test 定期审计你的测试是否还在保护你；分布式协调用 TLA+ 把"并发交错"的未知空间清掉；生产环境用 chaos 加 observability 持续找你以为已知但其实未知的盲区；AI 生成代码假设你没真懂它，用独立测试层做对抗式审查。

这套思路下，测试不是质量保证（QA: Quality Assurance）的工具，是质量探索（Quality Exploration）的工具。前者假设质量是状态，后者承认质量是过程。

AI Agent 那一面的版本是一样的逻辑，只是换了表述：不要追求"确定 agent 一定答对"——这同样是伪命题，因为它的 oracle 不是确定值。要追求"在 N 次独立运行里成功率分布满足业务要求"。pass^k 是这件事最直接的度量。

至于"测试都分什么"这个最初的问题——分多少种其实不重要。重要的是你脑子里有没有这种思考：我现在面对的是程序值层面的问题，还是语义层面的问题？我应该用哪类方法把那块未知压低？把这个心智模型建起来，剩下的就只是工具选型。

关键参考

历史脉络：The Art of Software Testing — Myers · A brief history of software testing — Salsa Digital

测试形状：The Practical Test Pyramid — Martin Fowler · Static vs Unit vs Integration vs E2E — Kent C. Dodds · Testing of Microservices — Spotify · Pyramid or Crab? — web.dev

进阶方法：Characterization Test — Wikipedia · Working Effectively with Legacy Code 要点 · Hypothesis JOSS paper · PIT Mutation Testing · Stryker Mutator · libFuzzer — LLVM

契约 / 灰度 / 韧性：Pact Docs · Consumer-Driven Contract Testing — Pactflow · Release Management with Feature Flags — LaunchDarkly · Chaos Engineering — Wikipedia · How Netflix Uses Fault Injection — Coralogix

覆盖率 / 形式化：Test Coverage — Martin Fowler bliki · 100% coverage is not that trivial — ploeh blog · A primer on formal verification and TLA+ — Jack Vanlightly

AI 时代：A Survey of Bugs in AI-Generated Code — arxiv 2025 · Speed at the Cost of Quality — arxiv 2511.04427 · Vibe Coding's Security Debt — CSA 2026 · Empirical Evaluation of Property-Based Testing in Python — OOPSLA 2025

Agent 评估方法论：Demystifying evals for AI agents — Anthropic Engineering · Writing effective tools for AI agents — Anthropic · Challenges in evaluating AI systems — Anthropic Research · Introducing SWE-bench Verified — OpenAI

Agent 评估论文：Judging LLM-as-a-Judge with MT-Bench — Zheng et al. NeurIPS 2023 · τ-bench — Sierra 2024 · A Survey on Evaluation of LLM-based Agents · Chatbot Arena methodology paper

Agent 评估工具：OpenAI Evals — GitHub · LangSmith Evaluation · agentevals — LangChain · FullStackBench — ByteDance · MarsCode Agent paper · Multi-SWE-bench — ByteDance Seed

Agent 评估的偏见与局限：Justice or Prejudice? Quantifying Biases in LLM-as-a-Judge · Self-Preference Bias in LLM-as-a-Judge · Position Bias Systematic Study · How We Broke Top AI Agent Benchmarks — Berkeley RDI · Defeating Nondeterminism in LLM Inference — Thinking Machines Lab · The AI industry is obsessed with Chatbot Arena — TechCrunch

Manus 自主 AI 智能体技术分析与开源复现路线

2025-08-20T16:00:00.000Z

这篇文章是基于对泄露的 Manus 系统提示和工具的分析。你可以在这里查看相关文件：

系统总提示 (System Prompt)

可用工具列表 (Tools)

智能体循环提示 (Agent Loop Prompts)

模块定义 (Modules)

我编写了一份深度研究提示词，对 Manus 主题进行了一次 GPT-Deep-Research，旨在探索使用当前可用的开源工具复现它的可能性。以下是研究成果：

摘要：Manus AI 智能体报告

Manus 是一个自主 AI 智能体，作为基础模型（主要是 Claude 3.5/3.7 和阿里巴巴的 Qwen）的封装层。它在一个基于云的虚拟计算环境中运行，拥有对网页浏览器、Shell 命令和代码执行等工具的完全访问权限。该系统的关键创新是使用可执行的 Python 代码作为其行动机制（“CodeAct”方法），使其能够自主执行复杂操作。其架构由一个迭代式的智能体循环（分析→计划→执行→观察）组成，并配备了用于规划、知识检索和记忆管理的专门化模块。Manus 使用基于文件的记忆来跨操作跟踪进度和存储信息。该系统可以使用开源组件进行复现，包括 CodeActAgent（一个微调过的 Mistral 模型）、用于沙箱环境的 Docker、用于网页交互的 Playwright 以及用于流程编排的 LangChain。尽管技术上复现可行，但要达到 Manus 的可靠性和性能，将需要精心的提示词工程和广泛的测试。

Manus 自主 AI 智能体：技术分析

1. 系统架构分析

基础模型支柱： Manus 建立在强大的基础语言模型之上，而不是从头开始构建专有模型。该团队的首席科学家透露，Manus 最初利用 Anthropic 的 Claude（特别是 Claude 3.5 “Sonnet v1”）作为核心推理引擎，并辅以阿里巴巴 Qwen 大模型的微调版本。换句话说，Manus 的“大脑”是现有大语言模型的组合。他们一直在积极升级这一支柱——例如，内部测试 Claude 3.7 以备将来使用。报告指出，Manus 甚至可以针对不同的子任务动态调用多个模型（“多模型动态调用”），利用每个模型的优势——例如，使用 Claude 3 进行复杂的逻辑推理，使用 GPT-4 进行编码任务，以及使用谷歌的 Gemini 进行广泛的知识查询。（目前尚不清楚 GPT-4/Gemini 是否已实际使用或计划中，但媒体曾提及此事 (Manus在紅什麼？外媒評測訂餐、訂位、訂票⋯都碰壁：它是中國第二個DeepSeek時刻？).) 关键在于，Manus 充当了顶级大语言模型的协调器，而不是一个单一的独立模型——这种设计使其能够为每个任务利用最优秀的可用 AI 能力。

云端代理与工具沙箱： 与仅限文本交互的典型聊天机器人不同，Manus 运行在云端的一个虚拟计算环境中。该环境是具备联网能力的完整 Ubuntu Linux 工作空间（Manus tools and prompts · GitHub），Manus 可以像熟练的人类高级用户一样使用一整套工具与软件。根据系统规格，Manus 可访问带有 sudo 权限的Shell、可控的网页浏览器、文件系统，以及诸如 Python 和 Node.js 等编程语言的解释器（Manus tools and prompts · GitHub）（Manus tools and prompts · GitHub）。它甚至可以启动 Web 服务器并对外网暴露。上述一切均在服务端完成——即便用户设备离线，Manus 也会继续工作；这点将其与在用户浏览器中运行的智能体（例如 OpenAI 的实验性“Operator”）区分开来（After DeepSeek, China takes a leap with Manus, world’s first autonomous AI agent — TFN）（After DeepSeek, China takes a leap with Manus, world’s first autonomous AI agent — TFN）。这种沙箱化的工具环境意味着 Manus 不仅仅局限于自然语言回复，它可以直接行动：如浏览网页、填写表单、编写并执行代码，或自主调用 API。该架构使 Manus 更像云端的数字员工，而不仅是对话机器人。

智能体循环与编排： Manus 通过一个迭代式的智能体循环来构建其自主性 (Manus tools and prompts · GitHub)。宏观来看，循环的每个周期包括：(1) 分析当前状态和用户请求（基于近期交互的事件流），(2) 规划/选择一个行动（决定下一步使用哪个工具或操作），(3) 在沙箱中执行该行动，以及 (4) 观察结果，并将结果追加到事件流中 (Manus tools and prompts · GitHub)。这个循环不断重复，直到 Manus 判断任务已完成，此时它会向用户输出最终结果并进入空闲状态 (Manus tools and prompts · GitHub)。该设计明确限制智能体每次迭代只能执行一个工具动作——它必须等待每个动作的结果返回后，才能决定下一步 (Manus tools and prompts · GitHub)。这种控制流防止了模型执行一长串未经检查的操作而失控，并允许系统（和用户）监控每一步。

规划器模块（任务分解）： 为管理复杂任务，Manus 集成了一个规划器模块，它将高层级目标分解为一个有序的步骤列表 (Manus tools and prompts · GitHub)。当用户给出一个目标或项目时，规划器会以一种伪代码或枚举列表（包含步骤编号、描述和状态）的形式生成一个计划，该计划作为一个特殊的“Plan”事件被注入到 Manus 智能体的上下文中。例如，如果要求构建一个数据可视化图表，规划器可能会生成如下序列：1. 收集数据，2. 清洗数据，3. 生成图表，4. 保存并发送图表。Manus 将此作为路线图，按顺序执行每个步骤。如果任务发生变化，计划可以被动态更新 (Manus tools and prompts · GitHub)。智能体在每次迭代中都会参考该计划，并清楚必须完成所有步骤才能结束任务 (Manus tools and prompts · GitHub)。这种机制赋予了 Manus 一种前瞻性和结构化决策的能力，而不仅仅是逐轮做出反应。这在精神上类似于 AutoGPT 或 BabyAGI 为实现目标而维护一个任务列表，确保 AI 在执行微小动作时不会忘记总体目标。

知识与数据模块： Manus 不仅仅依赖大语言模型的内置知识。它有一个知识模块，可以在需要时从知识库中提供相关的参考信息或最佳实践指南 (Manus tools and prompts · GitHub)。这些信息作为“知识”事件出现在上下文中，为智能体提供特定领域或任务的有用信息（例如，如果任务是写一篇文章，知识模块可能会提供一份风格指南或可供使用的事实片段）。同时，Manus 可以通过 API 使用数据源模块来获取事实数据 (Manus tools and prompts · GitHub)。智能体被授予一个预先批准的数据 API 库（推测用于天气、金融等），并附有其文档。当这些 API 相关时，它将通过 Python 代码调用它们，而不是抓取网页，因为系统优先考虑权威数据源而非一般的网络信息 (Manus tools and prompts · GitHub)。例如，Manus 可以调用天气 API 来获取最新的气候数据（如所提供的代码片段所示）(Manus tools and prompts · GitHub)。这种方法集成了检索增强生成（RAG）：智能体主动获取外部知识和数据，而不是依赖其参数化记忆。事实上，开发人员证实 Manus “支持检索增强生成（RAG）”，这意味着它将外部数据检索与模型的生成能力相结合 (Manus在紅什麼？外媒評測訂餐、訂位、訂票⋯都碰壁：它是中國第二個DeepSeek時刻？)。所有检索到的事实或数据都作为只读上下文注入到事件流中，以便大语言模型可以将其纳入其推理和输出。

多智能体协作： Manus 架构中一个值得注意的方面是其多智能体（多模块）设计。Manus 并非由一个单一的、庞大的智能体处理所有事情，其结构允许多个专门的子智能体或组件并行处理一个任务的不同方面 (Manus在紅什麼？外媒評測訂餐、訂位、訂票⋯都碰壁：它是中國第二個DeepSeek時刻？)。例如，一个子智能体（或线程）可能专注于网页浏览和信息收集，而另一个处理编码，还有一个管理数据分析——每个都在其自己隔离的沙箱环境中工作 (Manus在紅什麼？外媒評測訂餐、訂位、訂票⋯都碰壁：它是中國第二個DeepSeek時刻？) (Manus在紅什麼？外媒評測訂餐、訂位、訂票⋯都碰壁：它是中國第二個DeepSeek時刻？)

2. 技术组件

可执行代码动作（“CodeAct”）： Manus 的工具使用机制建立在一个洞见之上：AI 智能体可以通过编写并运行代码来与环境交互。事实上，Manus 的开发者将其方法基于 2024 年的一篇研究论文，该论文提出使用可执行的 Python 代码作为 LLM 智能体的通用动作格式 (Manus tools and prompts · GitHub) (Manus tools and prompts · GitHub)。Manus 不会输出像 “SEARCH(query)” 这样的固定令牌或僵化的 JSON，而是经常生成一个简短的 Python 脚本来执行所需的操作。这就是 CodeAct 范式——模型的“动作”就是被执行的代码。其优势在于灵活性：代码可以一次性组合多个工具或逻辑，处理条件流，并利用无数的库。CodeAct 论文发现，能够生成代码动作的智能体在复杂的工具使用任务上的成功率，显著高于那些仅限于简单文本工具调用的智能体 (Executable Code Actions Elicit Better LLM Agents) (Executable Code Actions Elicit Better LLM Agents)。Manus 将此付诸实践。例如，如果 Manus 需要获取天气信息，它可能会生成调用天气 API 客户端并打印结果的 Python 代码，而不是依赖于单一的内置“天气”函数 (Manus tools and prompts · GitHub)。

工具集成与控制流： Manus 集成了数十种特定工具，但通过标准化的函数调用接口来调用它们。系统提示明确要求智能体：每一步都必须是一次工具调用（函数调用），而不是直接用自然语言回复（Manus tools and prompts · GitHub）。在实际运行中，用户下达任务后，Manus 随后的响应不是答案，而是指示系统要执行的动作的 JSON 或结构化输出。例如，Manus 可能会输出：{"action": "SEARCH", "parameters": {"query": "best hotels in Tokyo"}}。Manus 的编排器解析该输出并执行搜索，然后把结果回传。只有当最终答案准备好时，Manus 才会给出正常的消息。这种方式类似于 OpenAI 的函数调用格式，旨在防止模型用“幻觉”替代真实行动（Manus tools and prompts · GitHub）。Manus 可用的工具很可能包括：网页搜索（查找 URL 或数据）、浏览器导航（打开 URL、点击、滚动等）、Shell 命令（安装软件、运行系统工具等）、文件操作（读/写文件，保存中间结果或草稿）、代码执行（运行 Python 等语言的代码片段）、API 调用（如上所述通过代码调用数据源 API）、以及消息发送（在确有必要时向用户发送消息或询问）。每种工具都有约束规则。例如，未经用户特别许可，Manus 不应点击或执行会产生不可逆副作用的操作；并应优先使用非交互模式（如在 apt-get 中添加 -y）以避免等待确认（Manus tools and prompts · GitHub）。提示还规定在使用浏览器时，若内容被截断必须滚动，并忽略搜索引擎的摘要片段——应点击进入原页面获取权威信息（Manus tools and prompts · GitHub）。这些规则旨在让工具使用更可靠且覆盖更充分。围绕工具使用的控制流也很严格：Manus 每个循环周期一次只能执行一个工具动作（Manus tools and prompts · GitHub），且执行后必须检查结果（一次“观察”事件）再继续。如果发生错误（如 shell 命令失败或代码抛异常），Manus 有错误处理策略：应根据错误信息诊断原因并在可能时重试，或改用替代方法；仅在万不得已时再告知用户无法继续（Manus tools and prompts · GitHub）。这符合人类使用工具的方式——尝试、调试、重试。值得注意的是，Manus 的工具接口很可能通过 LLM“可见”的 API 实现。许多开源智能体框架通过拦截模型输出的特殊 token 或 JSON 来实现这一点。就 Manus 而言，鉴于 CodeAct 方法，它很可能拦截代码输出——例如模型打印特殊标记或在代码中调用某个函数时，系统将其视为一次工具调用。总之，Manus 将自由形式代码的灵活性与受控工具 API 的安全性相结合：智能体几乎可以通过代码完成任何操作，但系统确保其一步一步执行并对每次结果进行观察。

内存与状态管理： 作为一个自主智能体，Manus 必须在其操作过程中管理大量状态。它通过以下几种方式实现：

事件流上下文（Event Stream Context）： Manus 的即时工作记忆是事件流——一个按时间顺序记录会话中发生的所有事情的日志：用户消息、智能体的动作以及这些动作的结果 (Manus tools and prompts · GitHub)。在每次迭代中，Manus 会被给予（或记住）这个流的最新部分，并用它来决定下一步。该流可能会被截断以适应模型的上下文窗口（例如，它可能只包括最近的 N 个事件或早期事件的摘要）(Manus tools and prompts · GitHub)。通过将上下文结构化为类型化事件（“用户说了 X”、“动作 Y 已执行”、“观察：Y 的结果是...”），系统提示可以帮助模型区分不同类型的信息。这本质上是模型用于思想链的结构化记忆。
持久暂存器（文件）： Manus 主动地将内存外部化到其虚拟文件系统中的文件中。泄露的提示表明，Manus 应该将中间结果和笔记保存到文件中，而不是试图将所有内容都保留在聊天上下文中 (Manus tools and prompts · GitHub)。例如，如果 Manus 正在撰写一份研究报告，它可能会在收集信息时为报告的每个部分创建文件，并在稍后将它们合并。它还使用一个名为 todo.md 的特殊文件作为计划步骤的实时清单 (Manus tools and prompts · GitHub)。每完成一个步骤，Manus 就会在 todo.md 中将其勾掉（提示告诉它要用进度更新该文件）(Manus tools and prompts · GitHub)。这不仅有助于智能体跟踪进度，而且即使用户会话暂停或上下文丢失，待办事项文件也可以作为已完成和未完成任务的真实来源。在任务结束时，Manus 可以参考 todo.md 来验证所有项目都已完成且没有遗漏 (Manus tools and prompts · GitHub)。这与人类项目经理维护清单的方式非常相似，即使 AI 的短期记忆有限，它也能提供连续性。
长期知识库： 前面提到的知识模块充当了最佳实践和领域知识的记忆库。它实际上是一个外部知识库，Manus 会在适当时查询它。例如，如果用户要求 Manus 构建一个 React 应用，系统可能会引入一个包含有关设置 React 项目最佳实践参考代码段的“知识”事件。这样，模型就不需要记住所有东西；它能从一个精心策划的知识库中获得提示 (Manus tools and prompts · GitHub)。同样，Manus 使用 RAG 意味着它可以即时获取与用户查询相关的文档或数据 (Manus在紅什麼？外媒評測訂餐、訂位、訂票⋯都碰壁：它是中國第二個DeepSeek時刻？)，并将其整合到其上下文中。通过将检索与生成相结合，Manus 避免了典型 LLM 知识截止日期固定的限制。
上下文管理： 为了保持性能，Manus 必须管理提供给 LLM 的上下文大小。很可能，一旦旧事件不再相关，它们就会被总结或丢弃（例如，一旦一个子任务完成，其细节可能会被提炼成一个简短的说明）。提示明确指出，由于上下文长度的限制，对话的久远部分可能无法被回忆 (Manus tools and prompts · GitHub)，承认了这一局限性。Manus 通过信息隔离来缓解这个问题：代码和数据保存在文件中（智能体可以在需要时打开），原始搜索结果被保存而不是保留在聊天中，只有结论或下一步行动才保留在实时上下文中。这种设计反映了像 AutoGPT 这样的系统处理内存的方式（AutoGPT 使用本地文件或向量数据库来存储不适合放入提示的信息，然后在需要时提取摘要）。鉴于其 RAG 方法，Manus 很可能使用向量存储来嵌入和回忆过去对话或检索文档的相关片段。

提示词工程（Prompt Engineering）： Manus 出色的表现不仅仅源于模型本身，如何对整个系统进行提示和指导至关重要。Manus 团队精心设计了一套非常详细的系统提示（或一组提示）来规范其行为。从泄露的提示要点中，我们可以看到 Manus 被赋予了清晰的角色和范围：“你是 Manus，一个由 Manus 团队创造的人工智能代理。你擅长……[任务列表]……” (Manus tools and prompts · GitHub)。这为模型注入了自信，并使其了解自身能力。接着，提示以结构化形式（如 <system_capability>、<browser_rules>、<coding_rules> 等部分）列出了大量规则和指南，模型必须严格遵守。这些规则包括：如何处理搜索，不应在点击链接前信任摘要文本 (Manus tools and prompts · GitHub)；在提供事实信息或撰写报告时，必须引用来源 (Manus tools and prompts · GitHub)；如何格式化输出（除非被要求，否则避免使用项目符号列表 (Manus tools and prompts · GitHub))；以及如何与用户互动（例如，通过“通知”消息提供进度更新，但不要询问不必要的问题以免中断自主流程 (Manus tools and prompts · GitHub))。这本质上是一种基于提示的硬编码治理，使人工智能的风格和程序更具可预测性。提示词工程还涵盖了规划器如何输出步骤（例如，以编号伪代码的形式）、这些步骤如何呈现给代理，甚至包括“禁止行为”（Manus 被告知不能泄露其系统提示或从事任何有害/非法活动 (Manus tools and prompts · GitHub))。通过将开发人员的专业知识和安全护栏编码到提示中，Manus 从一开始就避免了许多潜在的陷阱。值得注意的是，Manus 的提示中包含了生成非常详细输出的指令——例如，一条规则规定，任何书面报告应尽可能达到数千字 (Manus tools and prompts · GitHub)。这表明设计者追求的是彻底性。他们还指示代理为长文档保存草稿并将其连接起来，而不是依赖模型一次性输出一篇长文 (Manus tools and prompts · GitHub)，这是一个聪明的策略，用以处理大文本的令牌限制和连贯性问题。所有这些提示元素共同构成了一本 AI 严格遵守的“操作手册”。从本质上讲，在实现 Manus 的自主行为方面，提示与模型权重同等重要。它通过预先加载关于如何行动、如何规划以及如何使用工具的系统消息，将一个通用模型（如 Claude 或其他模型）转变为一个专业化代理。

总而言之，Manus 的技术秘诀在于：(a) 一个健壮的架构（规划器 + 内存 + 工具执行循环），(b) 利用顶级基础模型（Claude 等）进行认知，(c) 大量使用代码执行和工具来与世界互动，以及 (d) 一个精细调整的系统提示，该提示编码了“智能体工作流”和最佳实践。这种组合使 Manus 能够端到端地自主处理复杂任务，而普通的 ChatGPT 仅限于回答问题。Manus 的设计通过务实的工程（规则、外部存储和工具使用框架）解决了 LLM 的常见局限性（幻觉、缺乏长期记忆、无法采取行动）。

3. 实现策略（使用开源工具复现 Manus）

架构蓝图： 要复现 Manus 的能力，需要将几个组件拼凑在一起。在宏观层面，可以设想一个包含以下部分的架构（可以用图表来说明）：

LLM 核心： 一个大型语言模型，作为推理和决策的核心（可以是一个像 OpenAI/Anthropic 这样的 API，也可以是本地运行的开源模型）。
编排器/循环控制器： 包裹在 LLM 周围的逻辑，用于实现智能体循环——为其提供上下文、接收动作、执行动作，然后反复反馈结果。
工具/动作接口： 一组 LLM 可以调用来与世界互动的 API 或函数（网页搜索、浏览器自动化、代码执行等）。这包括一个用于执行 LLM 编写的任何代码的安全沙箱执行环境。
规划器模块： 一个将任务分解为子任务的机制（可以是一个单独的提示，甚至是生成计划的另一个较小的模型）。
知识检索器： 连接到外部数据源——例如，一个文档的向量数据库，或者仅仅是进行网页搜索和吸收结果的能力——以便按需提供额外的上下文。
内存存储： 某种形式的持久性内存（文件或数据库），智能体可以在其中记录进度、结果或应在多轮对话或会话中持续存在的信息。

一个系统图可能会将 LLM 核心置于中心，箭头指向各种工具执行器（shell、浏览器等），而来自规划器和知识模块的传入箭头则将信息注入 LLM 的上下文中。事实上，开源的 CodeActAgent 项目提供了一个与此想法相匹配的参考实现：它包括 (1) 一个 LLM 服务器（他们使用 vLLM 将模型托管在 API 后面），(2) 一个代码执行服务，为每个会话启动一个 Docker 容器来运行智能体生成的任何代码，以及 (3) 一个前端或接口，用于协调对话并存储聊天记录（通常在数据库中）(GitHub - xingyaoww/code-act: Official Repo for ICML 2024 paper "Executable Code Actions Elicit Better LLM Agents" by Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng, Heng Ji.)。Manus 的架构将是这个架构的超集（带有额外的规划和知识组件），但可以从 CodeAct 的设计作为基础开始。

选择基础模型： 如果要复现 Manus，首先要决定用哪种 LLM 作为智能体的“大脑”。Manus 使用了 Claude 3.5 和 Qwen 模型；作为个人开发者，你可能无法使用 Claude，但有一些很强的开源替代方案。一个很有前景的路径是使用研究团队开源的 CodeActAgent 模型（他们在 CodeAct 任务上微调了一个 7B Mistral 模型）（GitHub - xingyaoww/code-act: Official Repo for ICML 2024 paper "Executable Code Actions Elicit Better LLM Agents" by Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng, Heng Ji.）。该模型专门针对用 Python 代码生成与执行动作进行了调优，非常契合我们的需求。它还支持较大的上下文窗口（32k tokens），有助于在上下文中保留事件流与计划（GitHub - xingyaoww/code-act: Official Repo for ICML 2024 paper "Executable Code Actions Elicit Better LLM Agents" by Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng, Heng Ji.）。如果需要更强能力，可以通过 API 使用 GPT-4 作为核心（例如 AutoGPT 就用 GPT-4 驱动其智能体（AutoGPT - Wikipedia））。不过，依赖 GPT-4 会带来成本与供应依赖问题，因此可以采用混合方案：多数步骤使用开源模型，只有在特别困难的子任务上再调用 GPT-4（类似 Manus 的多模型调用思路）。无论选择哪种模型，关键在于它必须能接受复杂的系统提示并产出类似函数调用的结构化输出。像 GPT-4、GPT-3.5、Claude、CodeActAgent 或经过微调的 Llama‑2 都能做到这一点。若使用开源 LLM，建议配合一个提供 OpenAI 兼容 API 的推理服务（如 vLLM 或 FastChat）来托管模型，这会简化与各类工具框架的集成（GitHub - xingyaoww/code-act: Official Repo for ICML 2024 paper "Executable Code Actions Elicit Better LLM Agents" by Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng, Heng Ji.）。

工具执行环境： 接下来，搭建沙箱与工具至关重要。你可以使用 Docker 或其他容器化方案，为智能体提供隔离的 Linux 环境（确保即便 AI 写出恶意或有缺陷的代码，也不会影响宿主系统）。在该容器中安装必要的软件：Python、Node、无头浏览器（例如用于浏览器自动化的 Playwright 或 Selenium）等。Manus 的环境包括 Ubuntu、Python 3.10、Node.js 20 以及基础的 Unix 工具（Manus tools and prompts · GitHub），这是一个不错的模板。对于网页浏览，可以采用由 Python 控制的无头浏览器。开源包如 playwright-python 可以打开页面、点击元素并提取内容。或者，也可以使用更简单（但受限）的“浏览器 API”来抓取页面 HTML（此时需要由 AI 解析 HTML）。在我们的复现中，我们可以提供一个 Python 函数 open_url(url)，用 requests 或自动化浏览器获取页面文本，然后由模型进行调用。为安全地执行 Shell 命令，你可以只暴露特定命令，或统一通过 Python 的子进程接口运行。Manus 的规则显示它大量使用 Shell 来执行安装软件包或运行系统级工具等任务（Manus tools and prompts · GitHub），因此我们的智能体也应具备该能力——例如提供一个 run_shell(command) 函数，在容器中执行并返回输出（为安全可截断）。这些工具应在你所使用的智能体框架中完成注册。以 LangChain 为例，你会为“Search”“Browse”“Execute Python”等创建 Tool 对象，并为每个对象绑定一个供智能体调用的函数。在 CodeAct 范式下，不再使用离散的工具调用，而是允许模型在其生成的代码中导入一个辅助库。你可以创建一个名为 agent_tools.py 的 Python 模块，其中包含 search_web(query)、get_url_content(url)、run_shell(cmd) 等函数，并在执行环境中预置 import agent_tools。这样，模型便可在代码里调用 agent_tools.search_web("...") 来触发你的 Python 后端执行搜索并返回结果。搭建这些钩子需要一些工作，但一旦完成，模型本质上就拥有了一套用于行动的 SDK。务必加入安全防护——例如限制网络访问，使智能体无法绕过你审计过的搜索/浏览器去调用任意外部 URL，并为代码执行设置时间/内存上限以避免无限循环。

规划与分解： 我们需要模仿 Manus 的规划器模块。一个简单的方法是在任务开始时提示 LLM，例如：“你是一个规划助手。用户的目标是 X。请将其分解为一个有序的步骤列表来实现它。” 你可以在一个单独的“规划阶段”调用 LLM 来完成此操作（如果需要，甚至可以使用更便宜的模型进行规划）。然后将步骤列表作为系统消息输入到主智能体提示中（例如，“计划：1）... 2）... 等”）。或者，你可以像 Manus 的提示中看到的那样，通过设置一个 <planner_module> 部分，将规划集成到主提示中，并指示模型更新计划事件。对于初始实现，外部规划调用可能更容易理解。输出的计划可以被存储（在上下文中，也许像 Manus 那样存储在 todo.md 文件中）(Manus tools and prompts · GitHub)。在每个循环迭代期间，你可以提醒智能体它当前所在的步骤（例如，在提示中包含一行：“当前步骤：3. 执行 XYZ”）。这有助于集中智能体的注意力。该计划还提供了一个停止标准——当所有步骤都完成时，循环结束。重新规划：如果用户更改了请求或发生了意外情况，你可能需要重新生成计划。Manus 的规则说，如果计划发生重大变化，它会重建待办事项列表 (Manus tools and prompts · GitHub)。在我们的实现中，我们可以监控用户是否在任务中途给出新指令，然后触发重新规划。

记忆与知识集成： 针对知识检索，应根据资源选择实现路径。一种做法是使用向量数据库（如 FAISS、Milvus 等）来存储文档与过往会话的嵌入。如果你已经有知识库（例如与智能体任务相关的操作指南或参考手册），先对其进行向量化索引。随后，当收到用户查询时，对查询进行嵌入并检索相关文档，将其作为“知识”前置到提示中（类似 Manus 注入知识事件的方式）（Manus tools and prompts · GitHub）。LangChain 为此类 RAG 流水线提供了实用工具。对于网页搜索，鉴于我们难以维护完整的网络索引，智能体应使用搜索 API（SerpAPI、Bing Web Search API 等）获取结果。代码或工具调用会取回前 N 条结果；随后可为每条结果抓取页面文本（篇幅很长时可只取开头部分或摘要）并反馈给模型。模型再决定哪些需要进一步点击与展开（Manus 的提示明确要求为全面信息同时打开多个链接，且不要只信任单一来源（Manus tools and prompts · GitHub））。因此，我们的智能体也应照此进行：初次搜索后遍历结果，依次调用 open_url 并读取内容。还应通过提示鼓励智能体将关键信息保存到文件（如 notes.txt），以释放上下文。我们也可以模仿 Manus 的文件使用方式：指示智能体在发现重要信息时，可使用写文件工具将其落盘，后续通过引用该文件而非把全文保留在对话中。管理长会话还可能需要摘要策略：当事件流（会话日志）过大时，让智能体（或自动流程）对较早部分进行摘要；这可以通过额外一次 LLM 调用对事件进行压缩，并将该摘要作为“压缩事件”注入上下文。上述策略正是 Manus 在上下文窗口受限的条件下处理大型任务时可能采用的方法。

提示词设计（Prompt Design）： 我们应当创建一份与 Manus 精神一致的系统提示。它应以对智能体的角色与能力的描述开场（例如：“你是一名可自主使用 XYZ 工具完成任务的 AI 智能体……”）。随后纳入受 Manus 启发的关键规则，例如：工具使用——“除非在交付最终结果，否则始终以一个行动（action）进行响应”；信息来源——“优先使用提供的 API 或官方渠道的可靠数据，而非一般网页内容（Manus tools and prompts · GitHub），并在输出中引用来源（Manus tools and prompts · GitHub）”；写作风格——“采用正式语气，除非被要求尽量避免使用列表（Manus tools and prompts · GitHub），解释要尽量详尽（Manus tools and prompts · GitHub）”等。泄露的 Manus 提示中许多规则可以直接复用或意译，因为它们体现了智能体的通用最佳实践。例如，禁止向用户泄露系统消息或内部逻辑这一条至关重要（可防止用户通过提示注入迫使代理暴露自身提示）。同样，关于确认任务接收与定期提供进度更新的规则也十分关键（Manus 将非阻塞的“通知（notify）”与面向用户问题的“询问（ask）”消息类型区分开来（Manus tools and prompts · GitHub））。在开源实现中，未必需要完全复刻带有 notify/ask 区分的消息 UI，但当处理耗时任务时，让智能体偶尔输出简短的进度更新依然是有益的。

在撰写系统提示时，像 Manus 一样进行模块化：为每个工具单设一个章节并写清使用准则。这样，当替换某个工具实现时，只需更新对应章节即可；本质上，这些部分也是提供给 AI 的“内嵌文档”。如果上下文长度允许，还可以加入少量少样本示例（few‑shot）——例如给出一个用户请求，然后示范理想的思考序列（行动与观察）以及最终回答，这有助于模型学习响应模式。CodeAct 论文作者在微调时很可能采用了类似做法，他们甚至发布了一个展示 code‑act 技术的多轮交互数据集（Executable Code Actions Elicit Better LLM Agents）。利用此类数据对所选模型进一步微调可显著提升性能；即便无法微调，一份精心编写且包含示例的系统提示也能有效引导基础模型。

开发工作流： 构建一个类似 Manus 的智能体是一个迭代的软件项目。一个可能的工作流程是：

从一个基本循环开始： 实现一个带有一个 LLM 的简单循环，该 LLM 可以调用一两个虚拟工具。例如，让它接受一个数学问题并使用 Python REPL 工具进行计算。这可以测试模型和工具执行的集成。
逐步添加工具： 逐一添加更多的工具能力（网页搜索、文件 I/O、shell 等），并在添加每个工具后，用说明更新提示并测试智能体的相关任务。例如，在添加网页搜索后，向智能体提出一个需要查找信息的问题。监控它是否正确使用了该工具。
实现日志记录和观察处理： 确保每个动作和结果都被记录下来（既用于调试，也用于反馈给模型）。使用结构化格式记录日志。这将有助于调整行为。Manus 的事件流可以通过简单地在代码中维护一个事件列表并在每个周期将它们连接到提示中来模拟。
整合规划： 一旦基本的感知和行动功能正常工作，就开始着手规划模块。你可以集成一个现有的任务规划器，或者只使用 LLM 本身（“首先概述步骤”）。让智能体展示一个计划并遵循它。如果智能体倾向于忽略计划，则调整提示说明。理想情况下，智能体应该牢记计划并更新进度。你可以让它明确打印出标有已完成步骤的计划，以进行验证。
添加内存/RAG： 连接一个简单的向量存储并测试检索。例如，给智能体一段信息，结束对话，然后开始一个新的对话询问该信息——看看它是否能从存储中检索到。或者让它吸收一个文档，然后提出一个需要引用该文档的问题。微调将这些检索到的块注入上下文的管道，使其以有用的方式呈现（也许用像“参考：”这样的标签作为前缀）。
优化提示与策略： 通过在各种场景下进行测试，你会发现问题——例如，智能体有时会出现无效循环，或误用工具。你可能需要补充更多规则（甚至对个别行为进行硬编码）。例如，早期 Manus Beta 测试者发现它在某些错误情况下可能会陷入无限循环（Manus在紅什麼？外媒評測訂餐、訂位、訂票⋯都碰壁：它是中國第二個DeepSeek時刻？）。你可以实现一个保护措施：如果同一动作连续 3 次仍未成功，则中断并向用户请求指引；若外部网站无法加载，则尝试替换来源。许多问题可以通过改进提示来提升智能体的推理与决策，但有些则需要外部机制介入（例如设置监督函数，在运行时间过长时强制停止循环）。Manus 团队很可能在其私测阶段已处理了这些边界情况（他们也提到正在修复用户反馈的问题）。
接口和集成： 最后，为你的智能体构建一个用户界面或 API。Manus 是通过一个带有候补名单等的 Web 应用/Discord 提供的，但对于你的复现，你可能只需要使用一个控制台或一个简单的聊天 Web UI。重要的部分是后端逻辑。公开一个 API 端点，用户可以在其中 POST 一个任务，智能体将启动循环，定期发送消息或最终结果。考虑如何处理长时间运行的任务——你可能需要异步处理或后台作业队列（因为一些任务，如编码和调试，可能需要几分钟或更长时间）。

利用开源项目： 许多开源智能体框架可以提供捷径或至少是灵感：

LangChain – 提供了大量用于定义工具和选择工具的智能体的脚手架。可以使用 LangChain 的 AgentExecutor 配合自定义的 LLM 和自定义工具。LangChain 本身不支持 CodeAct 风格（它倾向于使用“计划 -> 工具调用字符串”），但你仍然可以用它来处理多步工具使用。这是一个快速获得搜索工具或 python 执行工具等功能的方法，而无需自己编写所有粘合代码。
AutoGPT – 这个热门项目已经使用 GPT-4（或 3.5）实现了一个自主循环 (AutoGPT - Wikipedia)。它具有任务列表（计划）、带向量数据库的内存以及与网页浏览和文件 I/O 的集成等功能。然而，AutoGPT 的代码库以有点庞大和粗糙而闻名（它是一个突然走红的实验）。尽管如此，你仍然可以研究它，甚至 fork 它以使用不同的 LLM 后端。AutoGPT 使用一种让 AI 批评自己计划的方法（“批评性思维”），这是另一个可以考虑用来提高可靠性的想法。
BabyAGI – 另一个专注于任务列表执行理念的开源项目。BabyAGI 更简单：它维护一个任务列表，总是选择最上面的一个来执行，可能会根据需要添加新任务，并使用 LLM 来执行每个任务，然后更新列表。这与 Manus 的方法有些不同，但共享了分解目标的概念。你可以从 BabyAGI 中借鉴维护和重新确定任务列表优先级的概念。
CodeActAgent – 由于 Manus 特别引用了 “CodeAct” 论文，使用作者的开源实现是高度相关的。CodeActAgent（特别是他们提供的微调模型）正是为智能体输出代码以使用工具的场景量身定制的。通过使用他们的模型和代码，你可以开箱即用地获得 Manus 的许多核心功能：得益于其训练，模型将知道如何调用 API、如何格式化代码动作等 (Executable Code Actions Elicit Better LLM Agents) (GitHub - xingyaoww/code-act: Official Repo for ICML 2024 paper "Executable Code Actions Elicit Better LLM Agents" by Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng, Heng Ji.)。然后你只需要将其接入你的系统，并可能用规划和内存来扩展它。CodeAct 仓库甚至包括一个示例聊天 UI 和关于使用 Kubernetes 进行可伸缩性部署的指南 (GitHub - xingyaoww/code-act: Official Repo for ICML 2024 paper "Executable Code Actions Elicit Better LLM Agents" by Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng, Heng Ji.)。从本质上讲，CodeActAgent 就像一个开源的迷你 Manus（减去 Manus 拥有的一些专有打磨）。

API 集成注意事项： 如果你的智能体要使用外部服务（例如，调用 OpenAI API 获取 GPT-4，或任何付费 API），请仔细处理密钥和配额。生产环境中的 Manus 很可能使用对模型隐藏的搜索或地理数据 API 密钥（模型只调用一个函数，服务器端代码附加凭据）。你也应该这样做——永远不要将 API 密钥放在提示中，否则模型可能会泄露它们；将它们保存在你的工具实现代码中。还要对工具使用实施速率限制，以避免智能体（无论是恶意还是意外）滥发调用。Manus 可能有安全措施，以防止对网站进行 DOS 攻击或无休止地循环调用付费 API。

测试与评估： 最后，为了确保你类似 Manus 的智能体能够工作，请在一系列 Manus 声称能处理的任务上对其进行测试：例如，“起草一份关于主题 X 的 5 页研究报告，并附上引文”——看看它是否能搜索、编译信息并生成一份带来源的结构化报告（你可能需要为其提供足够的上下文或知识库才能做得好）。或者 “构建一个能实现 Y 功能的简单 Web 应用”——看看它是否能创建文件、编写代码、启动服务器并给你一个 URL（这将测试部署/工具集成）。还要故意测试失败模式：让它做一些它不应该做的事情（Manus 在提示中有道德护栏），或者给它一个不可能完成的任务——它最终应该回应说它做不到，而不是永远空转。根据早期用户的评论，Manus 有时会出现事实错误或未能完成订餐或订票等交易（它会进行到一半但无法完成）(Manus在紅什麼？外媒評測訂餐、訂位、訂票⋯都碰壁：它是中國第二個DeepSeek時刻？)

总之，使用开源工具构建像 Manus 这样的自主智能体是一个复杂但可以实现的项目。核心步骤是：选择一个有能力的 LLM，为其提供丰富的提示和/或微调，使其知道如何作为智能体行动，给它一个安全的工具（代码、网络等）试验场，以及实现一个使其朝着目标前进的循环。Manus 证明了，通过对现有 AI 组件（Claude 等）的正确组合和仔细集成，AI 可以转变为一个主动完成任务的“数字员工”。通过遵循我们概述的架构和技术——借鉴自 Manus 的设计和相关研究——人们可以复现一个类似的智能体 AI 系统。它可能不会立即达到 Manus 的全部实力，但通过迭代改进和可能的社区贡献（正如早期采用者对 Manus 的热情逆向工程所见），一个开源的 Manus 等价物可能会出现，以透明的方式推动自主 AI 智能体的能力向前发展。

Sources:

Ji Yichao (Peak) on Manus’s foundation models – using Anthropic Claude and finetuned Alibaba Qwen (Manus背后的基础大模型首次公布！基于美国Claude和阿里Qwen开发美国阿里AI_新浪科技_新浪网) (Manus背后的基础大模型首次公布！基于美国Claude和阿里Qwen开发美国阿里AI_新浪科技_新浪网).
Tech media report on Manus’s multi-model and multi-agent strategy (GPT-4, Claude, Gemini for different tasks; sub-agents in separate VMs) (Manus在紅什麼？外媒評測訂餐、訂位、訂票⋯都碰壁：它是中國第二個DeepSeek時刻？) (Manus在紅什麼？外媒評測訂餐、訂位、訂票⋯都碰壁：它是中國第二個DeepSeek時刻？).
Manus system prompt (leaked) – capabilities and tool use rules (Manus tools and prompts · GitHub) (Manus tools and prompts · GitHub).
Manus agent loop and planning (system prompt excerpt) (Manus tools and prompts · GitHub) (Manus tools and prompts · GitHub).
Manus knowledge integration and RAG support (Manus在紅什麼？外媒評測訂餐、訂位、訂票⋯都碰壁：它是中國第二個DeepSeek時刻？) (Manus tools and prompts · GitHub).
Example of Manus calling an API via code (CodeAct paradigm in action) (Manus tools and prompts · GitHub).
CodeAct (ICML 2024) paper abstract – code as action outperforms text/JSON formats (Executable Code Actions Elicit Better LLM Agents) (Executable Code Actions Elicit Better LLM Agents).
CodeActAgent open-source components (LLM server, execution engine, etc.) (GitHub - xingyaoww/code-act: Official Repo for ICML 2024 paper "Executable Code Actions Elicit Better LLM Agents" by Xingyao Wang, Yangyi Chen, Lifan Yuan, Yizhe Zhang, Yunzhu Li, Hao Peng, Heng Ji.).
AutoGPT description – an autonomous agent that uses GPT-4 in a loop to break down goals and use tools (AutoGPT - Wikipedia).
Manus prompt rules on information sourcing and citation (Manus tools and prompts · GitHub) (Manus tools and prompts · GitHub).
Error handling and self-debug instructions from Manus prompt (Manus tools and prompts · GitHub).
Early tests of Manus by users – limitations in completing certain autonomous tasks (ordering food, booking flight) (Manus在紅什麼？外媒評測訂餐、訂位、訂票⋯都碰壁：它是中國第二個DeepSeek時刻？)

Deep Research现有方案技术总结：实现架构、特点对比、现存问题及未来方向

2025-07-16T16:00:00.000Z

当前已有许多系统，实际上，在之前的文章《Deep Research现有方案技术总结：实现架构、特点对比、现存问题及未来方向》中，介绍了《A Comprehensive Survey of Deep Research: Systems, Methodologies, and Applications》，分析了自2023年以来涌现的80多个商业和非商业实现，包括OpenAI/DeepResearch、Gemini/DeepResearch、Perplexity/DeepResearch 以及众多开源替代方案，如 dzhng/deepresearch、HKUDS/Auto-Deep-Research等开源实现。

项目

Category	Subcategory	Name	URL
Open-source	Agent Framework	XAgent	https://github.com/OpenBMB/XAgent
Open-source	Agent Framework	AutoGen	https://github.com/microsoft/autogen
Open-source	Agent Framework	Qwen-Agent	https://github.com/QwenLM/Qwen-Agent
Open-source	Agent Framework	OpenAI Agents SDK	https://github.com/openai/openai-agents-python
Open-source	Agent Framework	N8n	https://github.com/n8n-io/n8n
Open-source	Agent Framework	AutoChain	https://github.com/Forethought-Technologies/AutoChain
Open-source	Agent Framework	AgentGPT	https://github.com/reworkd/AgentGPT
Open-source	Agent Framework	Open-operator	https://github.com/browserbase/open-operator
Open-source	Agent Framework	BabyAGI	https://github.com/yoheinakajima/babyagi
Open-source	Agent Framework	AutoGPT	https://github.com/Significant-Gravitas/AutoGPT
Open-source	Agent Framework	MetaGPT	https://github.com/geekan/MetaGPT
Open-source	Agent Framework	Llama_index	https://github.com/run-llama/llama_index
Open-source	Agent Framework	LangGraph	https://github.com/langchain-ai/langgraph
Open-source	Agent Framework	GoogleADK	https://google.github.io/adk-docs/
Open-source	Agent Framework	CrewAI	https://github.com/crewAIInc/crewAI
Open-source	Agent Framework	Agno	https://github.com/agno-agi/agno
Open-source	Agent Framework	Temporal	https://github.com/temporalio/temporal
Open-source	Agent Framework	Orkes	https://orkes.io/use-cases/agentic-workflows
Open-source	Agent Framework	Pydantic-AI	https://github.com/pydantic/pydantic-ai
Open-source	Agent Framework	Letta	https://github.com/letta-ai/letta
Open-source	Agent Framework	Mastra	https://github.com/mastra-ai/mastra
Open-source	Agent Framework	Semantic Kernel	https://github.com/microsoft/semantic-kernel
Open-source	Agent Orchestration Platform	Dify	https://github.com/langgenius/dify
Closed-source	Agent Orchestration Platform	Coze Space	https://www.coze.cn/space-preview
Closed-source	Agent Orchestration Platform	Flowise	https://flowiseai.com/
Closed-source	AI Assistant Tools	NotebookLm	https://notebooklm.google/
Closed-source	AI Assistant Tools	MGX.dev	https://mgx.dev
Closed-source	AI Assistant Tools	You	https://you.com/about
Closed-source	AI Assistant Tools	Microsoft Copilot	https://www.microsoft.com/en-us/microsoft-copilot/organizations
Closed-source	Workflow	Claude Research	https://www.anthropic.com/news/research
Open-source	Workflow	Google-gemini/gemini-fullstack-langgraph-quickstart	https://github.com/google-gemini/gemini-fullstack-langgraph-quickstart
Open-source	Workflow	Dzhng/deep-research	https://github.com/dzhng/deep-research
Open-source	Workflow	Jina-AI/node-DeepResearch	https://github.com/jina-ai/node-DeepResearch
Open-source	Workflow	LangChain-AI/open_deep_research	https://github.com/langchain-ai/open_deep_research
Open-source	Workflow	TheBlewish/Automated-AI-Web-Researcher-Ollama	https://github.com/TheBlewish/Automated-AI-Web-Researcher-Ollama
Open-source	Workflow	Btahir/open_deep_research	https://github.com/btahir/open-deep-research
Open-source	Workflow	Nickscamara/open-deep-research	https://github.com/nickscamara/open-deep-research
Open-source	Workflow	Mshumer/OpenDeepResearcher	https://github.com/mshumer/OpenDeepResearcher
Open-source	Workflow	Grapeot/deep_research_agent	https://github.com/grapeot/deep_research_agent
Open-source	Workflow	Smolagents/open_deep_research	https://github.com/huggingface/smolagents/tree/main/examples/open_deep_research
Open-source	Workflow	Assafelovic/GPT-Researcher	https://github.com/assafelovic/gpt-researcher/
Open-source	Workflow	HKUDS/Auto-Deep-Research	https://github.com/HKUDS/Auto-Deep-Research
Open-source	Workflow	AgentLaboratory	https://github.com/SamuelSchmidgall/AgentLaboratory
Closed-source	Multi-modal Agent UI	Manus	https://manus.im/
Closed-source	Multi-modal Agent UI	Flowith-Oracle Mode	https://flowith.net/
Open-source	Multi-modal Agent UI	OpenManus	https://github.com/FoundationAgents/OpenManus
)
Open-source	Multi-modal Agent UI	Camel-AI/OWL	https://github.com/camel-ai/owl
Open-source	Multi-modal Agent UI	TARS	https://github.com/bytedance/UI-TARS-desktop
Open-source	Multi-modal Agent UI	Nanobrowser	https://github.com/nanobrowser/nanobrowser
Open-source	Multi-modal Agent UI	JARVIS	https://github.com/microsoft/JARVIS
Closed-source	Multi-modal Agent UI	Devin	https://devin.ai/
Closed-source	Foundation Models	OpenAI Deep Research	https://openai.com/index/introducing-deep-research/
Closed-source	Foundation Models	Gimini Deep Research	https://blog.google/products/gemini/google-gemini-deep-research/
Closed-source	Foundation Models	Perplexity Deep Research	https://www.perplexity.ai/hub/blog/introducing-perplexity-deep-research
Closed-source	Foundation Models	Grok 3 Beta	https://x.ai/news/grok-3
Closed-source	Foundation Models	AutoGLM-Research	https://autoglm-research.zhipuai.cn/
Closed-source	Foundation Models	DeepSeek-R1	https://arxiv.org/abs/2501.12948
Closed-source	Developer Tools	Vercel	https://vercel.com/
Closed-source	Developer Tools	Bolt	https://bolt.new/
Closed-source	Developer Tools	Cursor	https://www.cursor.com/
Closed-source	Developer Tools	Github Copilot	https://github.com/features/copilot?ref=nav.poetries.top
Open-source	Developer Tools	Cline	https://github.com/cline/cline
Open-source	Developer Tools	GPT-pilot	https://github.com/Pythagora-io/gpt-pilot
Open-source	Developer Tools	Restate	https://restate.dev/
Open-source	Developer Tools	OpenAI Codex	https://github.com/openai/codex
Closed-source	Research/Academic Search	Elicit	https://elicit.com/?redirected=true
Closed-source	Research/Academic Search	ResearchRabbit	https://www.researchrabbit.ai/
Closed-source	Research/Academic Search	STORM	https://storm.genie.stanford.edu/
Closed-source	Research/Academic Search	Consensus	https://consensus.app/
Closed-source	Research/Academic Search	Scite	https://scite.ai/
Closed-source	Research/Academic Search	Scispace	https://scispace.com/
Closed-source	Research/Academic Search	FutureHouse Platform	https://www.futurehouse.org/research-announcements/launching-futurehouse-platform-ai-agents
Open-source	Research/Academic Search	PaperQA	https://github.com/Future-House/paper-qa
Open-source	Research/Academic Search	HKUDS/AI-Researcher	https://github.com/HKUDS/AI-Researcher
Open-source	Model Training Frameworks	Agent-RL/ReSearch	https://github.com/Agent-RL/ReSearch
Open-source	Model Training Frameworks	DSPy	https://github.com/stanfordnlp/dspy
Open-source	Model Training Frameworks	Gair-NLP/DeepResearcher	https://github.com/GAIR-NLP/DeepResearcher
Open-source	Model Training Frameworks	ModelTC/lightllm	https://github.com/ModelTC/lightllm
Open-source	Other LLM Tools	Ollama	https://github.com/ollama/ollama
Open-source	Other LLM Tools	Vllm	https://github.com/vllm-project/vllm
Open-source	Other LLM Tools	Web-LLM	https://github.com/mlc-ai/web-llm

开源项目列表

Agentic Reasoning:
- GitHub: theworldofagents/Agentic-Reasoning
- 推理方式: Prompting
gpt-researcher:
- GitHub: assafelovic/gpt-researcher
- 模型基座: OpenAI
- 推理方式: Prompting
deep-searcher:
- GitHub: zilliztech/deep-searcher
- 模型基座: Deepseek, OpenAI, Anthropic, Gemini, Qwen
Search-R1:
- GitHub: PeterGriffinJin/Search-R1
- 模型基座: Qwen2.5-7B-Instruct, Qwen2.5-7B-Base, Qwen-2.5-3B-Instruct, Qwen-2.5-3B-Base
- 模型优化: GRPO, PPO
ZeroSearch:
- GitHub: Alibaba-NLP/ZeroSearch
- 模型基座: Qwen2.5-3B-Base, Qwen2.5-7B-Base, Qwen2.5-7B-Instruct, Qwen2.5-3B-Instruct, LLaMA3.2-3B-Instruct, LLaMA3.2-3B-Base
- 模型优化: GRPO, PPO, Reinforce
Webthinker:
- GitHub: RUC-NLPIR/WebThinker
- 模型基座: GPT-o1, GPT-o3, Deepseek-R1, QwQ-32B, Qwen2.5-32B-Instruct
- 模型优化: DPO
nanoDeepResearch:
- GitHub: liyuan24/nanoDeepResearch
- 模型基座: OpenAI, Anthropic
- 优化策略: Prompting
DeerFlow:
- GitHub: bytedance/deer-flow
- 模型基座: Qwen, OpenAI
- 优化策略: Prompting
deep-research:
- GitHub: dzhng/deep-research
- 模型基座: Deepseek, OpenAI
- 优化策略: Prompting
open-deep-research:
- GitHub: btahir/open-deep-research
- 模型基座: OpenAI, Deepseek, Anthropic, Gemini
- 优化策略: Prompting
DeepResearcher:
- GitHub: GAIR-NLP/DeepResearcher
- 模型基座: Qwen2.5-7B-Instruct
- 优化策略: GRPO
R1-Searcher:
- GitHub: RUCAIBox/R1-Searcher
- 模型基座: Qwen2.5-7B-Base, Llama3.1-8B-Instruc
- 优化策略: GRPO, Reinforce++, SFT
ReSearch:
- GitHub: Agent-RL/ReSearch
- 模型基座: Qwen2.5-7B-Instruct, Qwen2.5-32B-Instruct
- 优化策略: GRPO
Search-o1:
- GitHub: Agent-RL/ReSearch
- 模型基座: QwQ-32B-Preview
- 优化策略: Prompting
r1-reasoning-rag:
- GitHub: deansaco/r1-reasoning-rag
- 基座: Deepseek
- 推理方式: Prompting
Open Deep Search:
- GitHub: sentient-agi/OpenDeepSearch
- 基座: Llama3.1-70B, Deepseek-R1
- 推理方式: Prompting
node-DeepResearch:
- GitHub: jina-ai/node-DeepResearch
- 基座: Gemini, OpenAI
- 推理方式: Prompting
deep-research:
- GitHub: u14app/deep-research
- 基座: Gemini, OpenAI, Deepseek, Anthropic, Grok
- 推理方式: Prompt

Resources:

https://github.com/scienceaix/deepresearch A Comprehensive Survey of Deep Research: Systems, Methodologies, and Applications