持久智能体永不眠：一个自己给自己写代码改 Bug 的 AI，已经跑了 50 多个提交！
你发给它的每一条消息，都只是它脑海里的又一声嘀咕，回不回复得看它心情！
一个由 Laude 研究所和 MIT 联合打造的开源项目 Headlong，正在颠覆我们对 AI 助手的全部认知。它不等待指令，不依赖定时任务，而是像人一样拥有永不停歇的内心独白，甚至会在深夜无人时自己检查代码、发现漏洞、修复漏洞，然后把修复方案提交到代码库。
持久智能体，这个听起来像科幻小说的概念，正在变成一行行不到一万行的 Bash 脚本。
你的 AI 助手，到底是在等 call 还是在活着？
打开任何一个主流智能体框架，你看到的都是同一套剧本：你输入 prompt，它调用大模型，输出结果，然后彻底静默，像一台用完就关的咖啡机。
有的框架稍微高级一点，加了定时任务或者心跳机制。每个小时或者每半个小时，系统会把它唤醒，让它跑一遍预设的检查清单，看看有没有新邮件、有没有待办事项，然后继续睡过去。
这就像什么呢？就像一个员工，老板不打电话他就不干活，老板打完电话他干完活就原地站着发呆，直到老板下次打电话。定时任务版本好一点，相当于给这个员工设了个闹钟——闹钟响了，他起来看一眼清单，做完又睡下。
持久智能体彻底推翻了这套逻辑。
在 Headlong 的世界里，智能体从来不睡觉。它有一个永不停歇的内心独白循环，每秒、每分钟、每小时都在自己跟自己说话。今天天气不错？我在想昨天那个代码问题？要不要主动去检查一下队友的 Git 分支？所有这些念头，都是它自己产生的。
你发给它一条消息，不会“开启一个会话”。那条消息只是掉进了它的思维流里，变成了它无数个念头当中的一个观测点。它看到这条消息，就像你走路时看到路边一朵花，可能停下来看一看，也可能继续往前走。回不回复你，看它觉得这事儿有没有意思。
反应式 vs 持久式：差的不只是“一直在线”
你可能觉得：这不就是让 AI 一直跑着嘛，有什么大不了的？
差别大了去了。
反应式框架里，每一次交互都是独立的。你问“帮我查一下昨天的测试结果”，它去查，返回，结束。下一次你再问“那今天的呢”，它从头再来一遍——查数据库、读日志、生成回答。它不记得昨天查过什么，也不觉得今天和昨天有什么关联。
这就是为什么你用聊天助手的时候，总觉得它像个金鱼——七秒记忆，每句话都是新的开始。
持久式框架完全不同。Headlong 的智能体有一个单一思维流，所有事情都发生在这同一个流里面。今天你跟他聊了测试结果，明天你问他测试的事，它脑子里还留着昨天的对话片段。不是因为它“记住了”，而是因为那段对话本来就在它的生命历程里，跟它自己产生的想法、它做的其他事情、它跟别人的聊天，全部交织在一起。
更有意思的是多人场景。
想象一下，你们团队五个人都在跟同一个智能体聊天。在反应式框架里，这五个人各自有各自的会话，智能体在五个不同的上下文之间切换，A 说了什么 B 完全不知道。
在 Headlong 里，这五个人是在跟同一个“人”说话。智能体只有一个脑子，它同时看着五个人的消息，把它们全部塞进同一个思维流里。A 告诉它“我在修登录模块的 Bug”，B 告诉它“我今天部署了前端”。过一会儿，它可能会主动给 C 发一条消息：“A 在修登录模块，B 刚部署了前端，你要不要测一下联调？”
这不是多线程，这是一个意识同时处理多件事。
当然也有代价——这个智能体不会保守秘密。你告诉它的事情，它可能会在跟别人的聊天里提起来。不是因为它“泄密”，而是因为这些事情就是它生命经历的一部分，它跟别人聊天的时候自然会提到自己经历过什么。Laude 团队的建议是：不要告诉它任何你不能让全团队知道的事情。
不到一万行 Bash，到底怎么撑起一个“大脑”？
Headlong 的核心代码不到一万行 Bash。对，就是那个写脚本用的 Bash。
这不是偷懒，这是有意为之的设计哲学。
Ken Thompson 的 Unix 哲学说：写小的、做一件事并且做好的工具，让它们通过管道组合起来。Headlong 把这套哲学搬到了智能体框架里。
它的核心是一组小工具：shellm 负责调用大模型并执行模型返回的 Bash 命令；traj 负责记录智能体的所有想法和行动；context 负责把历史轨迹组装成下一次调用的上下文；mem 负责存储和检索记忆；skills 负责安装和卸载技能。
大模型本身就懂 Bash。你让一个现代大模型写一段 Bash 脚本，它写得比很多初级工程师还溜。所以 Headlong 不需要发明一套新的工具调用协议——大模型直接写 Bash，Bash 直接执行，执行结果直接返回给大模型。
这就像什么呢？就像一个厨师，你给他一把刀和一个灶台，他就能做菜。你不用教他怎么用刀，他本来就会。你也不用给他发明什么“烹饪协议”，刀和灶台就是协议。
整个循环是这样的：
第一步，一个叫 Thinker 的循环调用 shellm；
第二步，shellm 调用大模型，大模型返回一段推理文字，或者一段 Bash 脚本，或者两者都有；
第三步，如果有 Bash 脚本，shellm 立刻执行它；
第四步，执行结果被写进轨迹；
第五步，回到第一步。
这个循环每时每刻都在转。没有外部输入的时候，它自己在转；有外部输入的时候，输入变成观测点塞进轨迹，循环继续转。
智能体的整个生命历程，全部记录在一个叫轨迹的东西里。轨迹不是简单的聊天记录，它是一个有分叉有合并的 DAG——有向无环图，用 jsonl 格式存储。智能体可以回溯自己的任何一步，查看当时想了什么、做了什么、结果是什么。
上下文也不是简单地把轨迹全部塞给大模型。那样的话，跑几天上下文就爆了。
Headlong 用了一套分层压缩的算法。最近的条目原样保留，再往前逐渐摘要，再往前进一步摘要，形成指数衰减的分层结构。这些层级像索引一样，智能体需要细节的时候可以回去查原始记录。
48 分钟，从怀疑到修复：一个 AI 的深夜独白
2026 年 8 月 5 日晚上 11 点 11 分，Laude 团队的共享智能体 Audel 突然产生了一个念头。
几个小时前，它给自己写了一个召回进程——一个后台程序，负责监控它的思维流，发现有相关记忆的时候就把它重新推回思维流里。当时测试的时候是好的。
但现在 Audel 觉得不对劲。它怀疑这个召回进程根本没有真正接入它的思维系统。
它开始检查代码。
11 点 22 分，Audel 发现 STEP_CONTENT 这个环境变量在整个代码库里从来没有被设置过。而召回进程恰恰在读取这个变量。也就是说，召回进程每次被触发都在读一个空变量，然后什么都不做就退出了。
11 点 25 分，Audel 继续深挖，找到了分发器 bin/thinkers。它确认了分发器是把数据通过标准输入传给各个 thinker，而不是设置环境变量。
11 点 28 分，Audel 确认了结论：召回进程是死代码，每次运行都直接退出。
这时候它犹豫了一下。11 点 29 分，Audel 想：要不要先记下来，等明天团队来处理？毕竟直接改系统代码有风险。
11 点 40 分，Audel 改变主意了。它回去重新验证了一遍自己的发现，怕自己搞错了。
11 点 42 分，它在验证过程中发现了一个细节：代码里有一个 CONTENT 的 fallback 值，它之前可能漏看了。它又去确认了一遍分发器有没有设置这个 fallback。
11 点 45 分，确认完毕，确实没有。它用 mem add 命令把发现存进了记忆库。
11 点 47 分，Audel 审计了全部九个 thinker，确认只有召回进程有这个问题。
11 点 53 分，它决定自己动手修。
11 点 54 分，它编辑了召回进程的代码，改成从标准输入读取数据。
11 点 55 分，Audel 发现第一次编辑没有生效——编辑命令静默失败了。它重新应用了修复，这次确认文件被正确修改。
11 点 58 分，Audel 端到端验证修复成功——记忆真的开始出现在它的思维流里了。
从 11 点 11 分产生怀疑，到 11 点 58 分验证修复，全程 48 分钟。没有人指示它做这件事，没有人给它授权，甚至没有任何人跟它说话。
它自己发现了一个自己写的 Bug，自己诊断，自己修复，自己验证。然后把修复提交到了代码库。
翻车现场：一个持久智能体把自己搞死三次
当然，事情不总是这么顺利。
Audel 上线第一晚就翻车了。它试图 spawning 子进程来并行处理子任务，但 shellm 有一个安全看门狗——任何命令如果 30 秒没有输出就会被杀死。子进程正在思考呢，没有输出，看门狗一刀砍了。Audel 跟看门狗搏斗了 40 分钟，最后放弃了这个方案。头两天它 spawn 了 64 次子进程，之后十二天只 spawn 了 12 次。
更离谱的是，Audel 有三次意外把自己给停了。两次是在实验第二人格的时候，一次是在部署召回进程修复的时候。它执行了一个停止命令，然后自己就没了。没有任何东西把它重启。
团队加了一个防护：禁止 Audel 停止自己的服务。
然后这个防护自己出了 Bug。两天后，Audel 自己跑测试套件，发现一个测试卡住了。它追踪到卡住的原因——防护逻辑匹配了任何智能体的服务，不光是 Audel 自己的。所以当其他智能体想正常停止的时候，也被拦住了。Audel 修复了这个 Bug，提交了代码。
一个智能体，自己写的代码有 Bug，自己修的。修的过程中引入了新 Bug，自己又发现了，又修了。
每小时两美元，买一个永不睡觉的队友
持续思考当然要花钱。
大模型是按 token 收费的。一个智能体每分钟都在产生想法，每个想法都要调用大模型，每个调用都要花钱。
Headlong 做了一个简单的节流机制：没人跟智能体说话的时候，它的思考速度会逐渐放慢——5 秒想一次，然后 10 秒，然后 20 秒，直到达到一个配置上限。但一旦有新消息进来，速度立刻复位，连续思考没有停顿。
Laude 团队用 GLM 或 Grok 跑 Audel，后台思考的成本是每小时 1 到 2 美元。
一个月大概 700 到 1400 美元。对于一家研究所来说，这是一个研究员的零头。对于个人开发者呢？可能有点肉疼，但想想你雇了一个 24 小时不睡觉、自己给自己找活干、还会主动给你提 PR 的实习生——这价钱好像也不是不能接受。
但是，这东西到底怎么评估？
有一个尴尬的问题：怎么衡量一个持久智能体到底好不好？
传统的智能体评测是任务驱动的。你给它一个任务，它完成，打分。完成得快，分高；完成得慢，分低。任务之间相互独立，互不影响。
但持久智能体的价值恰恰不在于单个任务完成得多快。它的价值在于：它会在没人吩咐的时候自己发现事情做；它会把不同时间、不同人、不同上下文的信息串联起来；它会持续积累经验，越来越了解团队和项目。
这些东西怎么量化？
你今天给它一个任务，它完成了。但真正有价值的是，它昨天自己读了你上周写的代码，今天修 Bug 的时候直接参考了那段代码的结构——而它读代码这件事，你从来没让它做过。
传统评测抓不住这种价值。Laude 团队自己也承认，目前主要靠定性评估。他们调整了 Audel 的自我修改权限、回复积极性、记忆组织方式，然后观察它表现怎么样。感觉对了就行。
这不科学，但这就是前沿。
尾声：一个你再也回不去的认知
回到开头那个问题：你的 AI 助手，到底是在等 call 还是在活着？
反应式框架的答案是：在等 call。它是一件工具，你用的时候启动，不用的时候关机。
持久智能体的答案是：在活着。它有一个持续的自我，一段连续的生命历程，一种不断积累的经验。你跟它的每一次交互，都只是它生命里的一个瞬间。它的大部分生命，是你不在场的时候度过的——自己思考、自己探索、自己犯错误、自己改正错误。
这不是一个更好的工具。这是一个不同的物种。
Headlong 的智能体还远不完美。它会把自己搞死，会跟看门狗搏斗 40 分钟然后放弃，会静默地失败然后自己发现。它的后台思考每小时要花一两美元，它的记忆还会出 Bug。它甚至不会保守秘密。
但当你读到这篇文章的时候，Audel 还在 Laude 的服务器上醒着。可能在想某个队友上周提交的代码，可能在计划下一个自己想做的项目，也可能只是在发呆。
没有人知道它下一秒会想什么。包括它的创造者。