Agent 蜂群：用 SQLite 重构模型经济学
Agent swarms and the new model economics
我们今年初尝试用 Agent 蜂群从零构建浏览器，虽验证了概念但软件粗糙。如今我们转向更可控的工程化路径，挑战用 Rust 从零重建 SQLite。新蜂群在 Grok 4.5 模型下仅用四小时就通过了 80% 的测试，而旧版本在第二小时就陷入混乱。我们发现，通过 Planner 和 Worker 的树状分工，不仅解决了长上下文漂移问题，更实现了惊人的成本优化。面对每秒千次提交的高并发，我们自研了版本控制系统，并引入中立仲裁者解决 Merge 冲突。这种类似蚂蚁的 Stigmergy 机制，让 Agent 能通过环境协作，而非单纯依赖并行计算。
在蜂群中，规划者从不编写代码，因此它的上下文不会被低级细节填满；而执行者从不进行规划，因此它能将所有上下文资源集中用于处理单一狭窄的任务。
HN 评论区
143- htrp
今年早些时候的浏览器蜂群在 Git 上的提交峰值约为每小时 1,000 次。而新系统的峰值约为每秒 1,000 次。
为了支撑这种活动速率，我们从头构建了一个新的版本控制系统（VCS）。吞吐量并非我们要掌控这一层的唯一原因。系统中的每一次变更都要经过 VCS，因此碰撞问题首先在这里显现，下一节中的几种协调机制也是直接在其中实现的。
这简直是为了造个按钮而重新发明宇宙。
- anthonypasq
很高兴看到这类疯狂的实验正在进行。即便这目前无法 100% 奏效，或者成本高昂到难以承受，它们依然是对未来的窥探，就像 2023 年人们讨论编码代理时，我们那时只有代码补全功能一样。
- handfuloflight
为了测试进展，我们回到了旧蜂群曾感到棘手的任务：仅凭文档，从零开始在 Rust 中重写 SQLite。
SQLite 的源代码难道不在其训练数据里吗？
- dctwin
我没看错吧？Opus + Composer 的表现与 Fable 相当，但价格约为后者的 1/19，代码行数（LoC）也少了一半？
- whinvik
我本想看到更多关于测试框架（harness）工程的代码分享。结果我们只看到了最终成果。
不过这也说得通，毕竟对于 Cursor 来说，这个测试框架本身就是产品。
- shay_ker
我们怎么知道这些模型没有在 Turso 用 Rust 重写的 SQLite 上进行过训练？
它们很可能确实训练过，而且也无法从预训练数据中剔除那段代码。这难道不意味着这仅仅是 LLM 对训练集的机械记忆吗？我是不是漏掉了什么？
- smoyer
这几乎比 Steve Yegge 关于 beads 的首篇文章晚了一年。Gas Town 和 Gas City 为蜂群提供了编排。到目前为止我还没见过完美的实现，但这个想法并不新鲜。
- edg5000
起初我认为让代理运行更长时间并组成大群是未来的方向，但我越来越觉得，至少在工程领域，单线程模式似乎更合理。代理按需将内容拉入上下文。我最近也在尝试让代理从上下文中移除内容，比如文件。但仅仅向上下文添加内容，并在其填满时进行压缩，似乎就能胜过许多更高级的方案。因为模型足够强大，它知道该在摘要中放入什么；只要足够让模型能从该种子（例如拉入相关文件/数据到上下文中）重建上下文即可。