只给一个工具的 Agent：Nodecode 和“少即是多”的代价
Show HN 上的 Nodecode 只给模型一个工具：在运行中的 Common Lisp 进程里 eval，缺什么能力自己写、存进 git；代价是没有沙箱。
大多数人以为，Agent 越强，是因为工具越多。
我不这么看。
工具越多，往往只说明一件事：设计它的人，替模型做了太多决定。
10 月 26 日，一个叫 Nodecode 的开源项目出现在 Hacker News 的 Show HN 上。它反其道而行之，只给模型一个工具。
一个 eval。
默认的陷阱（工具清单越长越安心）
先看主流 coding agent 是怎么做的。
读文件，一个工具。写文件，一个工具。跑命令，一个工具。搜索、浏览器、各种连接器，各一个工具。
清单越拉越长，看起来越来越能干。
The thing is，每一个工具，都是设计者提前写死的一种假设。
假设你会需要读文件。假设你会需要连这个服务。假设你不会需要那个。
模型能做什么，被这张清单圈住了。
清单上没有的，它就做不了，只能等下一个版本。
这就是默认的陷阱。你以为你在给模型能力，其实你在给它画边界。
第一性原理（工具本质上就是代码）
把问题拆到底。
工具是什么？
是一段被提前写好、起了名字、交给模型调用的代码。
那如果模型本身就会写代码呢？
In other words，与其给它一大堆写好的工具，不如给它一个能执行代码的地方，让它缺什么，自己写什么。
不是给模型更多的工具，而是给它造工具的能力。
这就是 Nodecode 的出发点。
反转（一个 eval，自己长出能力）
据项目文档，Nodecode 是这样工作的：
- 模型唯一的工具是 eval，它在一个正在运行的 SBCL（Common Lisp）进程里执行代码
- 缺什么能力，比如读 PDF、接 MCP 连接器、加一个技能，就让模型自己定义
- 定义完立刻生效，同时存成 .lisp 文件放进 git
- 下次重启，自动加载
为了不让模型从零开始，eval 里预置了几个辅助函数：
(sh "cmd")跑 shell 命令(edit path old new)改文件(write-file path text)写文件(fork ...)分出子任务
用一个假设的场景来想象一下。
假设你让它总结一份 PDF 报告。它发现自己不会读 PDF，于是先在 eval 里写一个读 PDF 的函数，试一试，能用，存进 git，然后接着去做总结。
下一次你再丢给它一份 PDF，它不用再写了，直接调用上次那个。
说白了，它不是一个装满工具的工具箱，而是一个会自己打工具的铁匠铺。
这里选 Lisp，也不是怀旧。Lisp 的传统就是程序可以在运行时修改自己，定义一个新函数，马上就能用，不用停机、不用重新编译。对一个要“边干活边长能力”的 Agent 来说，这个特性刚好对得上。
一个容易被忽略的细节（git 就是它的记忆）
还有一点，我觉得比“只给一个工具”更有意思。
模型自己写出来的每一个新能力，都会存成 .lisp 文件，放进 git。
这意味着什么？
意味着它“长出来”的东西，不是藏在某个看不见的向量库或者对话记录里，而是一份份你能打开、能读、能比对的源代码。
In other words，它的成长是有账本的。
它昨天学会了什么，今天改了哪一行，你都能翻出来看。哪一次改坏了，按 git 的常规做法，你也能退回去。
这是我的理解，不是项目方的宣传语，但我认为这才是“自我改写”能被认真对待的前提。一个会改自己的系统，如果连改了什么都说不清，那就不是成长，是失控。
模块（一个进程，所有入口）
第二个值得看的设计，是它的入口。
据文档，Nodecode 是单进程的。终端、浏览器里的 nodecode web、手机（用 /link on 连上）、Discord、Telegram、Slack 机器人，全都接到同一个 gateway 上。
结果是：你在一个客户端里让它写出来的工具，在其他客户端里立刻就能用。
假设你在电脑终端里让它学会了某个新本事，出门以后在手机上找它，它还记得。
这是一个很简单的想法，但大多数 Agent 没做到。它们的能力散落在不同的会话、不同的应用里，每换一个地方，就像换了一个人。
平台方面，文档列出的支持范围是 Linux x86_64（文档写 glibc 2.38+，仓库 README 写 2.34+，以文档为准）、Apple Silicon 上的 macOS 15+、Windows x86_64（README 注明 Windows 上没有后台 gateway）。
代价（自由和风险是同一件事）
到这里，你可能已经意识到问题了。
一个能自己写代码、自己执行、自己修改自己的 Agent，同样能做你不想让它做的事。
Nodecode 的文档对此很直接：
- 没有沙箱
- eval 拥有宿主机的全部权限
- 它自带的防护（guard）不是安全边界
- 官方建议，无人值守时，放在容器或虚拟机里跑
请认真对待最后一条。
能力的边界被拿掉了，安全的边界也一起被拿掉了。这不是 bug，是这个设计的另一面。
换个角度说，传统 Agent 的工具清单，除了限制能力，其实也顺手充当了一道护栏。清单上没有“删除整个目录”，它就不太容易去删。Nodecode 把清单拿掉，护栏也就跟着没了，这道护栏得由你自己在外面重新搭起来。
如果你要试，就照文档说的，先把它关进容器或虚拟机里，再放手让它干活。
数字（先看是谁说的）
项目方给了一组很亮眼的数字。
但看数字之前，先看出处。
这些数字来自 Foresight Labs 的 FL-2026-006 报告，项目 README 把它挂在自己的 Research 栏目下，可以看作项目方的自测。README 交代了基本口径：所有 harness 都用 xhigh 推理强度，价格按 2026-10-11 计，同一个游戏跑过多次的取最好一次（各家一视同仁），GPT-6.1 Sol 的几轮是经 LiteLLM 网关和第三方 API 中转跑的，Codex CLI 用的是 Prime Intellect 公开的游戏适配器。但目前还没有独立复现。
在这个前提下，报告自报的结果是：在 ARC-AGI-3（25 个公开游戏、183 关）上，
- 配 Claude Opus 5.5，按 ARC-AGI-3 官方计分规则，Nodecode 和 Claude Code 都是 100 分；Nodecode 用了 1.81 亿 token（124 美元），Claude Code 是 3.93 亿（210 美元），也就是 token 少 54%，成本低 41%
- 配 GPT-6.1 Sol，两边都赢下全部 25 局，Codex CLI 99.9 分，Nodecode 99.5 分（Codex CLI 用的步数更少）；Nodecode 用了 5,800 万 token（33 美元），Codex CLI 是 1.72 亿（43 美元），token 少 66%，成本低 24%
注意，两组的分数几乎一样，第二组 Codex CLI 还略高一点。所以这份报告说的不是“更会做”，而是“做到差不多的程度，花得更少”。少用了多少 token 是一回事，同样的活干成了没有，是另一回事。两者要一起看，而且得等别人复现。
所以，我对这组数字的态度是：方向值得关注，结论还要等。
写在最后
Nodecode 不一定是未来 Agent 的样子。
它更像一个提醒。
我们习惯了用“加法”去提升 AI，加工具、加连接器、加功能。
Nodecode 试的是“减法”，把一切减到只剩一个 eval，然后看模型能自己长出什么。
减法的好处，是边界由模型的能力决定，而不是由清单决定。
减法的代价，是你得自己守住安全的那条线。
两者都是真的。
想清楚你愿意承担哪一个，再决定要不要用它。
说到底，挑 Agent 和挑任何工具一样，真正稀缺的不是功能清单，而是判断力。
知道自己要什么，知道自己能扛什么，剩下的，交给时间去验证。
来源：Show HN 帖子；GitHub 仓库（MIT）；官方文档；安全说明。ARC-AGI-3 成绩与 token、成本数字出自项目 README 所列 Foresight Labs FL-2026-006 报告，属项目方自测，未见独立复现；“没有沙箱、eval 拥有宿主全部权限”据官方安全说明，本文不提供安装或操作步骤；glibc 版本要求文档与 README 不一致；“git 就是它的记忆”等为作者看法。