我给自己搭了一个会自己改自己的智能体蜂巢

我大概是从某个很具体的挫败感里开始做这件事的：每次让 AI 帮我干一件稍微大一点的事，我都得从零开始交代一遍背景。上次聊到哪、为什么选了这个方案、哪条路已经试过并且走死了——这些东西全在上一个对话窗口里，而那个窗口关掉就没了。我不是在推进一件事，我是在反复重新开始一件事。

于是我做了一个东西，暂且叫它蜂巢。它接住我随手扔进去的一句话，自己判断该往哪儿放、该拆成几份、该交给谁干、干完了该不该放行。这篇不讲它怎么实现，只讲几个当时想清楚了、现在看依然成立的判断，以及为此付出的代价。

单位是「项目」，不是「会话」

第一个决定是最要紧的：这个系统里最基本的容器是项目，不是对话。

聊天窗口这个隐喻其实很误导人。它让人以为工作是一段段谈话，谈完就结束了。但真实的工作从来不是这样，它是一条会持续好几天、拐来拐去、时不时被搁下又捡起来的线。一件事的价值，恰恰藏在那些历史里——试错过什么、当时为什么否掉了某个方向。会话把这些东西装在一个一关就消失的盒子里，等于系统性地丢掉了最贵的部分。

所以我让每句新的请求先经过一道判断：这是一件新的事，还是我早就在推进的某件事又往前走了一步？如果是后者，它就落进已有的项目，带着那件事的全部来历继续跑。

这带来一个我一开始没料到的效果：我说话可以变得很懒。「那个地方再紧一点」——放在一个空白对话里这句话毫无意义，但放在一个已经跑了两天的项目里，它是完全清楚的。上下文的重量，本该由系统扛，而不是由我每次现场背一遍。

代价当然有：路由会判断错。它偶尔会把一件新事塞进一个不相干的旧项目里。但我宁愿要一个偶尔归错档的档案柜，也不要一地散落的纸片。

拆开、并行，然后要有人说「不行」

第二个判断是关于流程形状的。一句请求进来，先被复述一遍，再被拆成几份并行去做，做完汇总到一道关卡，那道关卡有权把活退回去重做，最后才轮到整理成给我看的东西。

复述这一步看着像多余的礼貌，其实是最省事的一环。我提的要求经常是含混的，一个含混的要求会在后面每一个环节被放大成不同方向的偏差。先把「我理解你要的是这个」摊开来，偏差就死在最便宜的地方。

拆分和并行的理由更实在：几个各管一摊的执行者，各自的注意力都是干净的，不会互相污染。但真正让这套东西可用的是那道关卡。没有它，你得到的是几份看起来都很像回事、拼起来却互相矛盾的东西——而这种失败方式最难发现，因为每一份单看都通顺。

所以我给这道关卡的权力是实的：它可以点名把某一份退回去，附上退回的理由，只让那一个重做，其余保持不动。这里的关键是「点名」和「附理由」。全部推倒重来是浪费，退回却不说为什么是循环。同时它的轮次是有上限的——不能无限地追求完美，到了次数就把当下最好的结果交出来，然后告诉我它不太满意。一个永远不肯交付的系统，和一个交付垃圾的系统同样没用。

让它改自己，前提是有一根拉绳

第三件事听起来比它实际上更危险：这个系统能改自己的代码。我在它自己的界面里提一个功能需求，它去改自己，然后重新上线。

为什么要这样？因为这是唯一能让改进真正持续的形状。所有需要我切换到另一个地方、另一套工具、另一种心情才能做的改进，最终都不会被做。而对一个每天在用的工具来说，「用着不顺」和「把它改顺」之间的距离，应该越短越好。

但一个能改自己的东西也能把自己改坏，坏到你连进去修它的入口都没有了。所以整件事真正的地基不是那些聪明的部分，而是一道很笨的检查：任何自我修改，必须先通过一整套对自己的自动化验证，才允许上线。没通过就当没发生过。上线之后还要能自己确认「我现在活着」——不活着就自动退回上一个被亲眼确认过健康的版本。

我给自己立了一条不许破的规矩：不许为了让某次修改通过而放宽那道检查。这听着像废话，但它是最容易被违反的一条，因为放宽它永远是眼前成本最低的选择。而一旦放宽，整个自我迭代的设计就从「安全」变成了「赌」。这套东西敢让我放着不管，靠的不是它有多聪明，而是它的退路是死的。

每一步都必须看得见

最后一条，也是我现在觉得最被低估的一条：状态变化必须全部可见。

一个多智能体系统在跑的时候，最难受的不是它出错，而是它沉默。你不知道它是在想、在等、在卡着，还是已经悄悄失败了。而这种不确定会直接毁掉信任——一旦我不确定它是不是在干活，我就会去看，去插手，那它对我就没有省下任何东西。

所以我的要求是：每一次状态变化都得留下痕迹，并且实时推到我眼前。谁被派了什么活、现在跑到哪一步、谁被退回重做以及为什么、谁彻底失败了。这不是为了做个好看的仪表盘，而是因为可观测性就是委托的前提。你只会把事情交给一个你能看见的东西。

这里有个反直觉的地方：一个进度全程可见但偶尔失败的系统，比一个成功率更高却全程沉默的系统更好用。因为前者的失败你能立刻发现并接手，而后者的失败你要等到很久以后、在一个更糟的时刻才撞见。

一个刻意的取舍

还有一个决定值得单独说：这东西只跑在我自己的电脑上，没打算上云。

它的每个执行者都是一个真实的本地进程，带着我本机的凭据和文件权限。这意味着它能真的动我的东西——这正是它有用的原因，也正是它不该被随便放到公网上的原因。能力和信任边界是一回事：一个能改自己代码、能读写我全部工程文件的东西，就应该活在一个只有我能碰到的地方。

我很清楚这限制了它的想象空间。但我更愿意要一个权限很大、边界很小的工具，而不是反过来。

回头看，这些判断没有一条是关于模型有多聪明的。它们全都是关于结构：把上下文放在哪儿、谁有权说不行、坏掉之后怎么回来、以及我能看见多少。模型的能力这两年在飞快地涨，但涨上来的能力最后能不能变成我手里真正省下的时间，取决于我给它搭了一个什么形状的东西。

这个蜂巢还很粗糙，也还在被它自己改着。但我已经不太愿意回到那种每次都要从零交代一遍的日子了。

本文由 AI 辅助完成：我口述这套系统的设计取舍与思路，AI 整理，人工全文校对润色。