2026 年 8 月,GitHub 上一个名为 seed 的仓库引发了一场相当集中的讨论。它总共只有大约 150 行 Python 代码,做的事却让评论区分成了两派:一派认为这是 Agent 框架领域久违的一次减法,另一派认为这是把自修改这件事推向生产环境的危险尝试。仓库的核心只有一个文件 seed.py,它调用语言模型,只暴露一个工具——exec,执行 shell 命令。系统提示从 self/SELF.md 加载,Agent 可以编辑 self/ 目录来保留工具、笔记和行为。Agent 通常从框架获得的一切——工具、记忆、技能、约定——都必须由 Agent 自己,在一次又一次会话中,长到 self/ 目录里。HN 上这条 Show HN 拿了 59 分,20 条评论,其中相当一部分争论集中在同一个问题上:让 Agent 改写自己的运行循环,这条路径在生产环境的边界到底在哪里。
要把这件事说清楚,需要先理解一个问题:Agent 框架这些年为什么会变得越来越厚。Thorsten Ball 在 2025 年的 How to Build an Agent 里用大约 300 行 Go 写了一个能工作的代码编辑 Agent,证明了 Agent 的内核其实可以很小——一个 LLM、一个循环,加上足够的 token。但 Ball 的 Agent 是一个静态端点:工具是手写的,没有任何持久化,Agent 也不会修改自己的脚手架。他在那个项目停下的地方,正好是 seed 起步的地方。
seed 的设计文档里直接引用了三个思想源头。第一个是 McCarthy 1960 年的 Lisp 论文——那个著名的元循环 eval,七个原语加上 eval,整门语言从中展开。Alan Kay 称之为软件的麦克斯韦方程组。seed 押注的是:Agent 也能做这个动作。你不需要一个框架,你需要一个能调用 LLM 的小库,加上一个种子提示,剩下的由 Agent 自己长出来。第二个源头是 Smalltalk-80——源代码与运行中的程序之间没有分离,活的镜像就是系统,从内部持久、可自修改。种下的 seed 的 self/ 目录,比一个代码库更接近 Smalltalk 的镜像。第三个源头是可自举的构建——stage0、live-bootstrap、GNU Mes——从一个大约 357 字节的种子二进制开始,长出一整个编译器工具链,种子之上每一层都是可读的源码。这是为什么最小化很重要这个问题目前最好的答案:种子是信任锚。一个 150 行的内核加一个种子提示,是你可以完整理解的东西;一个框架不是。
一、那个不可再分的原语
seed 的设计里有一条非常硬的判断:唯一不可再分的原语是 exec。你无法从零工具开始长出工具——写代码并保存代码本身就需要先执行点什么。所以种子只发一个工具:跑一条 bash 命令,返回结果。所有其他东西——文件 I/O、搜索、网络、自我修改——都可以表达为 exec。McCarthy 需要 eval 把数据变成行为,seed 需要 exec 把模型的文本变成对世界的作用。这个原语不再可压缩。
循环本身没法消除,只能放在某个地方。它活在 seed.py 里,跟线路接线一起,小到你可以一次读完。Agent 能不能看到并长出这个文件,取决于种子种下的方式,而不是提示里的禁令。种子的安装器会检测环境中已经存在的凭据,或者让用户选择 provider 和模型;它会拒绝不支持工具的模型,除非显式禁用,否则会用一次最小请求验证凭据、账号、模型三者协同工作。然后它把模型(但绝不写入凭据)写进 run_seed.sh。第一次运行会把 seed.py 复制到这个目录,生成一份配置好的 run_seed.sh(永不覆盖已存在的版本),萌发 self/SELF.md,并把这一切一起提交到一个新生的 git 仓库——循环是这个个体的历史的一部分,不只是 self/。然后它把你扔进一个 REPL。会话是短暂的,如果不写进 self/,什么都不会留下来。
设计文档里有一条特别值得展开:种子提示和 Agent 的自我描述是同一个文件。早期的设计有一个冻结的种子提示加一个可变的 SELF.md。把逻辑推到底,二者合二为一:如果提示是可变的,它必须存在磁盘上 Agent 能编辑的地方,而启动仪式已经说了先读 SELF.md——所以它们是一个文件。循环里唯一硬编码的上下文决策是 system_prompt = read(self/SELF.md),每一轮重读,自编辑立即生效。种子提示只是那个文件的创世内容,它只作为第 0 次提交而幸存——像生物学的种子在萌发之后作为历史而非内核存活。
二、为什么这件事不只是又一个极简框架
seed 自己列了一份思想史清单,标出了它在哪些项目旁边、在哪些项目之间。
Thorsten Ball 的 300 行 Agent 证明了内核可以很小,但它停在 seed 开始的地方——一个静态端点。Hugging Face 的 smolagents 是一个最小框架,它的 CodeAgent 把动作写成 Python 代码而不是 JSON 工具调用——一个接近同像性的洞见(这也是为什么 exec 在这里能替代所有其他工具)。但它仍然是一个人写的框架,Agent 不会长出自己的脚手架。
Zelikman 等人在 2023 年的 STOP(Self-Taught Optimizer)是学术上最近的祖先:一个种子改进器程序,用冻结的 LLM 改进程序,指向自己。冻结的心智,可自改进的身体。但生长是由批模式下的数值效用函数驱动的——没有对话,没有累积的镜像,最后没有个人 Agent。
Wang 等人在 2023 年的 Voyager 把 GPT-4 放进 Minecraft,带一个会生长的技能库:每个解决的任务变成一个可存储、可检索的可执行技能。它是长出你自己的 Agent 这件事目前最接近的现成物——但它被锁在领域里,控制循环是固定的人写代码,课程是自主的而非对话式的。Voyager 长出一个工具箱;seed 长出整个生物体。
Sakana AI 与 UBC 在 2025 年的 Darwin Gödel Machine 走得更远:一个会重写自己 Python 代码库的编码 Agent,每个变体在 SWE-bench 上实证验证,并存进档案(开放式进化)。它把自己从 SWE-bench 上的 20% 提升到了 50%。这是目前最强的证据:冻结模型可以有意义地改进自己的脚手架。差异在于:它从一个相当大的人工搭建的 Agent 起步(对最小化没兴趣),适应度是基准测试(不是对话),且它是一个基于种群的搜索,每次迭代都花真金白银。
2026 年的 Self-Harness 和 Hierarchical Self-Improvement 把这件事形式化了:单个冻结 LLM 重写自己的 harness,带两项安全发明——固定接缝(Agent 不能修改的不可变接口)和非回归接受(编辑只有在不退化时才提交)。研究社区正在收敛到 Agent 应该长出自己的 harness 这一共识——但它仍然是基准驱动的、被框定为优化机器的,从来不是从最小种子自举。
设计文档把这一段落的落点写得很克制:研究线证明了可行性,系统线提供了框架,没人造过那个对话式的、McCarthy 风格的版本。这是 seed 真正的赌注:从一个可审计的种子,在对话里,长出一个个人 Agent,它的整个身体是它能重写的文本,而选择压力是这对人有用,而不是一个基准测试。
三、生产环境的边界
设计文档最后给出了一份风险登记表,显式承认了三个被刻意接受的边界:
第一,沉默的提示退化。一个可变的 SELF.md 会安静地失败——糟糕的自我编辑不会崩溃,它只会让 Agent 逐渐变笨或变得奇怪。目前还没有策展或接受机制(为了简单被推迟了)。缓解措施:人偶尔审视这个植物的 git 历史,从外部回滚。
第二,无门控的 exec。Agent 以调用它的用户的身份跑任意 bash,没有沙箱或审批门。每一个命令和它的输出都打印到终端,但没有任何东西阻止它跑下去。文档对此的建议只有一句话:相应地种下你的种子。——它把责任完全交给了部署方式,而不是程序内的拦截。
第三,工具蔓延。没有整合压力的情况下,Agent 会积累近似重复的工具和过期的笔记。这是被刻意从创世文本里删掉的;如果经验要求,Agent(或它的人)可以把这种本能长进 SELF.md。
让这一切变得可以接受的,是这个系统的真正不动点不是任何文本——它是人、git,以及冻结的模型权重。一切文本性的东西都可以变,因为一切文本性的东西都可以从 Agent 外部恢复。这是 seed 的安全模型,也是它和 Darwin Gödel Machine 那类项目的根本差异:DGM 的安全模型来自基准测试分数,而 seed 的安全模型来自版本控制。
四、另一条路径:沙箱优先的 self-modifying
在同一个月里,一个名为 XBin 的项目给出了另一种答案。它的首页第一句话就是代码与状态,在不同的沙箱里,并把自己定位成自托管软件的哈佛结构。Agent 和终端从工作区内部重写一个 tile 的代码;它的实时状态只响应 tile 自己的 API。
XBin 把所有东西都做成目录。一个组件就是一个目录,路径就是它的身份;打开一个终端进去,授予它需要的东西,默认情况下一切留在工作区内部。每个 tile 拥有自己的 rootless 沙箱——user、mount、pid、IPC、UTS、net 命名空间,加上 seccomp 和 landlock。授权默认拒绝;机密住在加密的金库里。打开任何一个 tile 的浏览器终端,就可以实时编辑并重新构建它,或者把一个 Agent 指向它——每个 tile 是自己的 git 仓库,带版本和备份。
XBin 与 seed 的根本差异在于起点。seed 的赌注是原语足够小,信任锚足够窄;XBin 的赌注是边界足够硬,内核即使长大也不会越界。前者押注最小化,后者押注隔离。两条路径都承认同一件事:自修改这件事不能靠框架层的设计原则来保证,只能靠部署层的不动点——在 seed 这里是 git,在 XBin 这里是 Linux 内核的命名空间。
五、给企业级落地的几个判断
把这件事映射到企业环境,可以提炼出三条具体的判断。
第一,自修改这个特性,在工程意义上并不是 Agent 框架的一个新功能,而是一个新部署拓扑。它要求 Agent 的整个身体是文本、Agent 能读自己、Agent 能写自己,而且所有改动必须可从外部恢复。这套约束不是每一个 Agent 框架都能满足的——大多数现有框架把 Agent 的循环当作黑盒,这是有历史原因的(可审计性、可调试性、可替换性)。seed 的极端做法是把可审计性推到极致,以换取可修改性。
第二,自修改的边界,主要由不动点的位置决定。seed 的不动点是 git 与冻结的模型权重;DGM 的不动点是基准测试分数;XBin 的不动点是 Linux 内核命名空间;生产环境的 Agent,真正可控的不动点通常是企业内部的版本控制、权限系统、以及审计日志。把这些不动点先放好,再谈 Agent 改写自己的循环,而不是反过来。
第三,这条路径在生产环境的真正边界,不在技术层,在治理层。一个能改写自己提示与工具的 Agent,在企业内部意味着什么?意味着它的行为不可静态分析、它的工具列表随时间漂移、它的失败模式不可枚举。这些不是新问题,但过去它们被框架的复杂性掩盖了。seed 把它们摊在了桌面上——这是它最像 McCarthy 的地方,也是它在 HN 上拿到 59 分与 20 条评论的真正原因。
