为什么 Multi-agent 还没火出圈？
四月份 Slock.ai 上线的时候我就关注到了。最先抓人眼球的是它那自带 meme 的名字和所采用的 neo brutalism 设计风格。
我在劳动节放假的时候深度使用了一次。当时我还外旅游。晚上的时候给了一个需求，拉了一个 Channel，三个 agents——两个 Claude Code，一个 Codex。在我睡觉的时候他们吭哧吭哧干了一晚上，一个产品原型就上线了。
那个原型是一个基于网红发布过的抖音视频，做了一个他们的知识库分身。让用户可以和自己喜欢的博主，基于博主真实发布过的视频内容、内容逻辑做出回答。起到一个替代真人咨询的功能。因为我真的很喜欢一些小众博主的视屏——讲社会学的、控制论的、信息论的、经济学的——内容逻辑都非常精彩。但是要我追完所有的视屏实在没时间，而且也没有付费咨询的必要。
这个三个 agents 干了很多工作。视频下载、转录、存储、抽取逻辑、前端页面……当然这也花了不少的 token。
当时的我还处于同时开三四个 TUI 进行不同的工作的阶段。其实已经隐隐感受到了痛点，但是还没有能清晰地表述出来。看到 Slock 的工作成果之后，我很兴奋。这款产品确实给我带来了启发。
后来我还拿它来尝试了一些架构重构的真实工作。说实话，效果不错。
但是 Slock 令人别扭的点是存在的：
- token 消耗高非常多。让人怀疑 agents 之间的通信是否是有必要的。
- 架构约束散漫。因为往往描述需求的时候不会定义到架构约束、代码规范这么细。所以导致写出来的部分代码在人类程序员的视角看来是很糟糕的：该复用的不复用、过分抽象或者过分补丁。
- 电脑上一定要一直用 terminal 运行着 daemon，没有挂到系统进程上去。
- agents 之间的消息交流虽然足够细节和丰富，但是对于我来说其实不关心。我只关系 @我的、需要我参与的和知晓的。agents 之间的消息降低了我的信噪比。
- 一个原生 webUI，无法连接现有团队协作的 IM（比如slack、飞书）。信息转发让我多承担了一个传话筒的角色，并且让人怀疑是否需要一个原生的平台。
我的前同事也有一些质疑。他的质疑主要在多 agent 是否真正创造了额外的价值。他习惯于把 agent 当做工作使用。Claude Code、Codex 这样工具性很完善的工具让他用起来很舒服，对代码的把控性也很强。自己要自定义一些小动作也更加自由。
这些问题，我当时都没有想明白。但是这并不妨碍我仍然对这款产品的喜欢。但是实话实说，somehow 我没有持续使用，后来还是回到了 Claude Code.
让我想明白的后来的一段实践经历。当时前司的新产品发布不久，用户的反馈比较积极，每天都能收到非常多的 bug 反馈。但是由于人手不足和内部组织形式的原因，我们修 bug 的速度非常慢。这又导致了大部分精力都花在了修bug上后，没有时间做新的功能、没有思考架构的优化与部分重构的方案、没有时间学习其他前沿产品的实践和技术、没有时间思考用户体验上的核心价值……总之就是被困死在了修bug上。一个人一天一到两个bug。有的代码洁癖比较强的同事，或者很影响产品心智的功能bug 会让一个同事在一个bug上花两三天、甚至一周以上。
我信奉快速迭代，同时因为不是传统程序员出身，所以也没有什么代码洁癖的心理负担。很多同事认为 AI 把代码写得垃圾了，就会导致仓库越来越难维护。我不这么认为。因为就算是人写，也会写出垃圾代码，不是每个人的架构思维都是顶尖的。其次，维护的工作在未来也几乎一定是 AI 来写，所以压根不会消耗人类的时间。
总之，在 AI 时代之前看似不可撤销、重做成本很高的动作，在 AI 时代都几乎变得是可撤销的，从时间成本的维度上讲。所以不应该让心理负担成为阻碍 AI 开发的速度。维度代码质量的工作只需要人类花时间在维护一套架构约束即可。
基于这种信念，我用了一个周六上午的时间，用 Claude Code 搭建了一个全自动的 issue pipeline。全天 7 × 24 小时运行。每次tick执行 7～10 个步骤（更新main-ref、查新issues、查人类回复、自动多agent workfow分诊、fix方案/执行、review、PR、解决 security checks comment循环……）、给每一个 issue run 一整套流程。我给它还接入了 Slack Bot，给了它一个账号，创建了一个 Slack channel，把工作上涉及到的同事都拉入群里。当它遇到自己无法判断的决策时候，就会根据我给它的成员清单对应找到相应 issue 所负责技术决策的同事去要决策。
令我意外的是，它还自己进化创造出了一些很好的功能。比如关联同一个bug的 issues 做同簇处理，不会重复。重复的机械步骤沉淀为了脚本，多个脚本统一保存，到要执行的时候就拿出来用，减少了 token 的消耗、提高了固定步骤的稳定性。还有每日早报。
我把这套系统命名为 Lindsay.
Lindsay 从上线到我离职，大概20天的时间，大概处理了近 200 条 issues，提交了近100条PR。
Lindsay 的实践让我认识到了一个事情：重要的是的循环的定义。
代码仓库的场景为什么能做起来，因为它的反馈信号（issues）、交付产品（代码仓本身）、决策步骤（code-PR-merge）都已经是定义清晰的。所以 agents 才能在持续运行。
循环系统被定义清晰的场景，也是 multi-agent 更多能发挥作用场景。
为什么？因为多agent的核心价值是 context 隔离。一个循环中的不同步骤，解耦程度越高，那么不同步骤之间的执行信息对相互来说就是上下文污染。这个和 coding harness（如 Claude Code）在 harness 内部做 subagent、dynamic workflows 功能的原则是一样的。
在 Lindsay 的场景中，其实 issue/PR 的状态管理、issue分诊和决策、fix/improvement 执行方案的决策和实施，等等，都是较为解耦的。如果只放在同一个 agent session 中做的话，那就对模型的上下文窗口大小、harness 的压缩策略质量、harness的记忆方案都有不小的挑战。
另一个 multi-agent 的好处则是在于的确提升了 agents 的决策带宽的上限。
所以真实世界稀缺的不是好的 agent 产品，而是已经形成共识且规范的循环定义。
软件工程算一个，所以 Github Coplit 主打 “from issue to merge”，所以 Multica 也有不少人在用。
Slock（后来改名为 raft）给人展示出来的能力无疑是让人兴奋的。我一直不是很明白为什么这么好的产品没火出圈？甚至连我也不是很想持续用。
原因就是因为目前 AI 的发展阶段所匹配的大众心智，还停留在把 AI agent 当做单点工具的阶段。
“Agent 很强，五分钟就帮我做好了一个精美的ppt。”“Claude Code 很强，十分钟就帮我修好了一个烦人的 bug。”——这是目前的用户心智，其核心是“替代劳动” substitution。
这也是为什么目前 workbuddy 在国内市场最近崛起的核心逻辑。和豆包桌面版一样，都是简单易用的好工具。但不是“工作系统”。
对于多数人来讲，在他们自己的工作场景中，反馈循环是建不起来的。或者说至少是不清晰的。
他们不对反馈真正重要的反馈信号负责，打工人只对上级负责。这也是工业时代组织形式的特色。在过去，这是必要的提升效率的手段。但是在现在，这却成了组织提升整体生产效率的瓶颈。
另外，在真实世界中，反馈信号的频率高低、数字化程度，都是限制循环建立的瓶颈。
Loop engineering 过去一两个月成了时髦词儿。这是因为前沿从业者的实践场景中，循环是清晰的。且他们都对结果负责。所以需要构建怎么样的 Loop （循环）就非常直白。
昨天，我看了一位群友的直播分享。他一个人订阅了5个Claude Code Max、20个 Codex，并行跑 40 多个 agents，同事开发 20 个 iOS app。这就是 Lindsay 的增强版。他最核心的工作就是自己手搓开发搭建了适配自己这么高并发需求的 DevOps 管线。工程架构约束、测试工具、数据仓、代码仓……都非常完善。他的循环非常明确。
所以 Multi-agents 为什么还没火出圈？
我的答案是大众心智转变的时机还没有到。
当你把 slock 摆在一个普通白领的面前的时候，他可能会觉得还不错，但是一定会觉得“我拿他用来干嘛？”
现在有明确循环场景人群就是集中在 solo-founder，builder 这样的人群。这部分人群的体量也就十几万到几十万——实在是太少了。所以，multi-agents 还没有火出圈。
那么，既然我们看到了multi-agents 循环的巨大潜力了。在当下的时机节点，做点什么才是有实际价值的呢？才是那个真正连接起到未来心智转变的那个桥呢？
我最近做的一款产品—— LoopHouse ——正在尝试回答这个问题。
我认为这几点很重要：
- 毫不费力的循环定义，甚至产品能帮你挖掘工作中的循环定义。
- 适配当下多人分工合作的企业组织的，产品内部的人×agents 的协作形态。
- time-to-value: 极致方便，上手容易，符合用户习惯直觉。
- token-to-value: 最终结果要真实产生效益，拒绝烧很多token但是结果一般般。
对于这些标准，我自己也在开发过程中持续思考迭代。未来的文章中会详细阐述。如果你对 LoopHouse 感兴趣，欢迎试用：https://loophouse.app 它是免费下载使用的。
LoopHouse 是：
- 一个 app 里你可以创建任意多个 agent 同事。
- 一个群聊就是一个多 agent 循环工作流，指挥起来只需发消息，就像一个真正的老板。
- 人类指挥 agents 的历史决策会自动沉淀为经验，agent 循环会越来越自动化和智能。
- 统一的“人类×agents 身份系统”，可以同时接入 slack、飞书等IM渠道。
LoopHouse 的一些特色：
- Agents 同事在后台工作，真正需要沟通的时候，才给你发消息。
- 自由接入任意 harness (cc, codex, grok, 等都支持）。
- 支持接入自带订阅（BYOS）、自带key（BYOK）。
目前 LoopHouse 还是测试版本（v0.22.0），功能还在持续开发中。
不过正如上面所言，这个产品对我自己也是个闭环的循环。目前产品本身的功能开发、发版、媒体账号运营等工作，我已经都放在 LoopHouse 里面做了。Lindsay 没有理我远去，她又换了种方式在与我一同成长。
欢迎试用和加入种子用户群。