从 OpenClaw 到 Buzz:AI Agent 正在沿着一条清晰的路径进化

半年来，我陆陆续续拆解过好几个"人和 AI 协作"方向的开源项目。

一开始我是把它们当成一个个独立的工具在看的。直到有一天，我把它们按发布时间排了一下，才突然意识到——这不是四个并列的选择，这是一条清晰的进化线。

OpenClaw：2025 年 11 月首次发布
Hermes Agent：2026 年 2 月
Multica：2026 年 3 到 4 月
Buzz：2026 年 7 月

半年多的时间，四个项目。有意思的是——它们不是各做各的，而是像接力一样，一个比一个往前走了一步。每一代都在补上一代没解决的短板，每一代都把"AI 能协作的边界"往外推了一点。

把这条线看懂了，你基本就能猜到下一步会往哪走。

第一站：OpenClaw——让一个人拥有一个 AI 助手

时间回到 2025 年底。OpenClaw（那时候还叫别的名字，改过好几次名）出现的时候，解决的是一个很朴素的问题：

怎么让 LLM 不只是"聊天"，而是能真正帮我"干活"？

它把大模型变成一个能 24 小时运行、能记住上下文、能操作外部服务的个人助手。跑在你自己的机器上，连接几十个消息平台，能执行命令、管理文件、做浏览器自动化、调 API。

有人把它形容成"个人 AI 助手的操作系统"——LLM 提供大脑，OpenClaw 提供手脚（会话、工具、沙箱、渠道接入）。

这在当时是个突破。它第一次让普通人感受到："哦，原来 AI 不只是问答机器，它能真的动手做事。"

社区的反应也是真实的狂热。因为 OpenClaw 需要一台 24 小时运行的本地设备，Mac Mini 一度在各大电商平台卖断货。中文社区里到处在说"养虾"——因为 OpenClaw 的吉祥物是一只龙虾，把它架在你的机器上 7x24 跑着就叫"养虾"。有人一口气买三五台 Mac Mini 专门跑 Agent，有人在闲鱼上做起了"代养虾"的生意。二手 NAS 厂商甚至专门发了教程教你怎么把 OpenClaw 跑在自家设备上。

这波热度是 AI Agent 走向大众的标志性时刻。在那之前，Agent 只是技术圈的概念；在那之后，普通人开始真的掏钱为 Agent 买硬件了。

但它的边界也很清楚：它是为"一个人 + 一个助手"设计的。它很强，但强在个人层面。多个 Agent 之间怎么协作、团队怎么共享——这些它没解决，也不打算解决。

它回答的问题是：一个人怎么拥有一个能干活的 AI？

第二站：Hermes Agent——让这个助手"越用越懂你"

三个月后，Hermes Agent 出现了。

它跟 OpenClaw 是同一个象限的——都是个人向、都是能干活的助手。但它往前走了关键的一步：它有记忆，会进化。

OpenClaw 能干活，但每次基本是"重新开始"。Hermes 不一样——它有三层记忆系统，会从每次任务中自动提炼出"技能"，会跨会话记住你，会慢慢建立一个"关于你"的理解模型。

用一句话概括这个进步：OpenClaw 是"能干活的助手"，Hermes 是"越用越懂你的助手"。

实际用起来的体感也能验证这一点。用过的人普遍提到几个感受：前两周跟普通 AI 没什么区别，但到了第三周开始明显不一样了——它会主动说"根据上次你的偏好，这次用了 XX 方式"，不再需要每次重复解释。有人在 Substack 上写道，他用 Hermes 通过 Telegram 直接管理日常工作，"几乎像在跟一个记性越来越好的远程同事聊天"。

当然负面反馈也很真实：有人说"它有时候花了更多时间修 Agent 本身的 bug 而不是做正事"，还有人说技能自动创建的质量参差不齐——偶尔会生成一些"看起来像技能但实际没什么用"的文档。早期版本的稳定性确实是个问题。不过 Nous Research 的品牌信誉让很多人愿意忍着等它成熟。

这一步看着小，其实很重要。因为它第一次让"AI 助手"有了"积累"的概念——你用得越久，它越了解你的工作方式，产出越贴合你的需求。这解决了 OpenClaw "每次从零开始"的短板。

它回答的问题是：这个 AI 助手，怎么才能随着时间越来越好用？

但它也有一个天花板：这些记忆和技能，是绑定在"你个人"身上的。你训练出来的懂你的 Hermes，你的同事用不了。它进化得再好，也是私人的。

这个天花板，恰恰是下一站要突破的。

第三站：Multica——让 AI 成为"团队的一员"

又过了一两个月，Multica 出现。它一下子跳出了"个人"这个象限。

它的定位非常直接，slogan 就是："你接下来的 10 个同事，不会是人。"

它做的事情是——把 AI Agent 变成项目管理系统里的一等公民。你可以像给同事派活一样给 Agent 派任务：它自己接单、写代码、报告阻塞、更新状态。Agent 有头像、出现在看板上、能发评论、能创建任务。

它的名字本身就在讲这个进化——Multica 致敬的是 1960 年代的操作系统 Multics，那个引入"分时共享"、让多个用户共享一台机器的系统。Multica 的想法是：过去软件团队是"单线程"的——一个工程师一次一个任务。现在 AI Agent 让"分时共享"回归了，只不过这次共享系统的"用户"既有人也有 Agent。

几个关键能力体现了它比前两代强在哪：

• Squads（小队）：把 Agent 和人编成小队，由一个"队长 Agent"负责路由。你 @前端小队就行，不用记具体哪个 Agent 擅长什么。

• Autopilots（自动驾驶）：给 Agent 排定时任务——日报、周报、定期审计自己跑。

• Reusable Skills（可复用技能）：这是关键——每个解决方案变成整个团队可复用的技能。注意，是"团队"级别的复用，不再是 Hermes 那种私人的进化。

• Multi-Workspace（多工作空间）：按团队做隔离，每个空间有自己的 Agent、任务和设置。

看到进步了吗？Hermes 解决了"个人积累"，Multica 解决了"团队共享"。你的 Agent 学到的技能，现在整个团队都能用了。说白了它解决的是：一个团队，怎么把 AI Agent 当成能协作、能沉淀的成员来管理？

Multica 出现的背后有一个硬需求：AI Agent 的能力已经强到"一个人管不过来"了。有研究提到，2025 年 AI Agent 能处理的任务时长增长了 5 到 6 倍——年初还只能干几分钟的活，年底能干半小时以上的任务。当你手里同时有五个、十个 Agent 在跑，你就需要一个"管理层"。Multica 就是那个管理层。

在实际使用场景中，Multica 回应了一个在团队里真实存在的痛苦——"Agent 跑的活越来越多，但没人知道它们在干啥"。有人形容以前管 Agent 就像"在六个终端窗口之间跳来跳去，盯着日志猜进度"，Multica 上手后变成了"看一个看板就行，谁在做什么、卡在哪里一目了然"。有评测提到，小团队（2-3 个工程师 + 5-8 个 Agent）使用 Multica 后，感觉就像"两个人指挥了一个小分队"。它的技能复用功能也被反复提到——一个工程师调好的部署流程，存成 Skill 之后其他人的 Agent 直接就能用。这解决了 Hermes 那种"进化是私人的"的短板。

第四站：Buzz——把 AI 放进"组织的工作空间"

再往后，2026 年 7 月，Buzz 出现。它站到了最上层。

如果说 Multica 是"管理 Agent"，Buzz 是"重新定义人和 Agent 一起工作的空间"。

它是一个自托管的协作工作空间，人和 AI Agent 共享同一个"房间"。它基于一种签名事件协议构建——每条消息、每个操作、每步工作流都是一个带签名的事件，存在同一个日志里。Agent 有自己的身份密钥、频道权限、审计轨迹，能做人类能做的所有事：建频道、提交代码、发起审查、跑工作流、参与讨论。

Buzz 有一句话我印象很深："Agent 是房间里的成员，不是在后台偷偷跑的幽灵任务。"

这句话点出了它的进化方向：Multica 是把 Agent 请进了"项目管理系统"，Buzz 是把 Agent 请进了"整个组织的协作空间"。前者管的是"任务"，后者管的是"协作和知识流动"本身。

它试图解决的问题比前面三站都更大：当 AI 成为组织的一部分，人和 AI 怎么在同一个空间里透明地、可追溯地协作？

这一站还很新（很多功能还在建设中），成熟度不如前三个。但它引发的讨论质量很高。有人在 LinkedIn 上直接说"Buzz 可能是一个比 OpenClaw 当初还重要的时刻"——逻辑是 OpenClaw 证明了 Agent 能干活，而 Buzz 证明了 Agent 可以作为组织的一等成员存在。Block 内部已经在用它替代 Slack 和 GitHub 做内部协作，这意味着它不是一个"概念验证"——它已经在一个几千人的公司里跑着了。

当然早期体验也很粗糙。基于 Nostr 协议意味着很多开发者需要学习一套新的身份和签名概念，社区里有不少人反馈"上手门槛比预想高"。移动端还在开发中，很多人只能在桌面端用。但愿意折腾的人普遍认同它的方向——"这才是人和 AI 应该共处的方式，而不是在 Slack 里加一个 Bot 就完了。"

把四站连起来：这条进化线在讲什么

现在把四个项目按时间排在一起看：

OpenClaw（个人拥有 AI）→ Hermes（AI 随时间进化）→ Multica（AI 成为团队成员）→ Buzz（AI 融入组织协作）

这条线背后是一个特别朴素、但特别重要的规律：

任何一个新的生产力工具，都会沿着"个人工具 → 团队协作 → 组织基础设施"的路径演进。

这不是 AI 独有的。想想代码管理的历史：

最早是个人的本地版本控制（一个人管自己的代码）
然后是团队的 Git 协作（多人一起改一个仓库）
最后是组织级的 GitHub / GitLab 平台（整个公司的代码、权限、协作、CI/CD）

AI Agent 正在走完全一样的路。唯一的区别是——代码管理走完这条路用了二十年，AI Agent 用了不到一年。

这才是真正值得警觉的地方。不是某个具体项目有多厉害，而是这条进化线推进的速度快得离谱。半年时间，AI Agent 就从"个人玩具"走到了"组织基础设施"的门口。

为什么一定是这个顺序，不能跳？

这里有一个容易被忽略但很关键的点：这四站的顺序不是随意的，它是被"底层能力"锁死的。

想一想——为什么"团队协作"（Multica）不能出现在"个人能干活"（OpenClaw）之前？

因为只有当单个 Agent 强到能独立完成一件有意义的工作，"协作"才成为一个真需求。如果一个 Agent 连独立做完一个小任务都做不到，你让五个这样的 Agent"协作"，只会得到五倍的混乱。协作的前提是每个个体先能独立交付。

同样，为什么"组织级协作"（Buzz）必须在"团队管理"（Multica）之后？

因为组织级协作要解决的是"跨团队的信息流动和信任"，而这个问题只有在"团队内部协作"已经跑通、并且暴露出"团队之间是孤岛"这个痛点之后，才会浮现。你没经历过团队级的协作，根本意识不到组织级的墙在哪里。

这就解释了那个"5-6 倍"的数据为什么是这条进化线的引信——2025 年 AI Agent 的任务时长增长了 5 到 6 倍，年初只能干几分钟，年底能干半小时以上。正是"单个 Agent 能独立干有意义的活"这个能力阈值被跨过，才一下子引爆了后面对"管理"和"协作"的需求。能力先到位，协作需求才被激活，进化线才被推着往前走。

所以这条线不是设计出来的，是被能力的增长一步步逼出来的。这也意味着：只要 Agent 的单体能力还在涨（它显然还在涨），这条线就一定会继续往前推。下一站会是什么？大概率是"跨组织"——不同公司的 Agent 之间怎么协作、怎么建立信任、怎么交换价值。Buzz 用签名身份做审计的思路，可能正是在为那一站做铺垫。

每一代都在变好，而且是在补前一代的短板

回头看这四站，会发现一个很清晰的模式——每一代都不是推倒重来，而是精准地补上一代的短板：

OpenClaw 让 AI 能干活，但每次从零开始 → Hermes 补上了"记忆和进化"
Hermes 会进化，但进化是私人的 → Multica 补上了"团队共享"
Multica 能管理团队，但管的是"任务" → Buzz 往上补"组织级的协作和知识流动"

每一步都踩在前一步的痛点上。这种"接力式进步"不是偶然——它反映的是真实需求在被一层层地满足：先解决"能不能干活"，再解决"能不能积累"，再解决"能不能协作"，最后解决"能不能融入组织"。

需求的层次越来越高，工具的能力也就越来越往上走。

那对我们意味着什么

第一，别把这四个当成"选一个"的问题，要理解它们各自处在进化线的哪个位置。

如果你是个人开发者——你的需求还在第一、第二站，OpenClaw 或 Hermes 就够了，上团队平台是杀鸡用牛刀。

如果你带一个团队——你的需求到了第三站，Multica 这类"把 Agent 当团队成员管理"的平台是当下最务实的落点。

如果你在为整个组织做长期规划——第四站的 Buzz 代表方向，值得关注，但现在全面押注还太早，它自己都还在建设中。

第二，也是更重要的——理解了这条线的方向，你就能提前布局。

这条进化线还没走完。它会继续往"更高层的协作"走。今天你在第三站（团队），但你要知道第四站（组织）正在快速逼近。当你现在设计团队的 AI 协作方式时，最好想一步——怎么让今天的团队级沉淀，未来能平滑地升级到组织级。

落到最实处：如果用 Buzz，工作空间该怎么设计

假设你决定往前一步，直接上第四站的 Buzz——把整个团队甚至组织的协作都放进这个"人和 Agent 共处的空间"。那么第一个绕不开的问题就是：空间怎么划分？

这里要先理解 Buzz 和前面几站在"空间模型"上的根本不同。

Multica 的划分单位是"工作空间（Workspace）"——本质是一个个隔离的盒子，盒子之间是墙。而 Buzz 的模型完全不一样：它的划分单位是"社区（Community）"和社区内的"频道（Channel）"，底层是一套签名事件系统——每个人、每个 Agent 都有自己的密钥身份，每个动作都被签名、可审计、可搜索。

这个区别很关键。因为 Buzz 是组织级工具，它的空间设计逻辑不该照搬团队级工具的"分盒子"思路。

先看几种划分方式的取舍：

方式一，每个员工一个社区。完全错误的用法。Buzz 的全部价值在于"人和 Agent 在同一个空间里协作、信息在同一个事件日志里流动"。给每个人一个孤立社区，等于把一个组织级协作工具拆成了一堆单机版，进化线直接倒退回第一站。

方式二，一个业务团队一个社区。这是从 Multica 那套思路平移过来的做法，看似合理，其实没用对 Buzz。团队之间又变回了"隔着墙的盒子"——跨团队的信息流动、知识检索、Agent 协作全被墙挡住了。你花力气上了一个组织级工具，却只用出了团队级的效果。

方式三，一个公司一个社区，用频道来分团队和项目。这才是 Buzz 真正的设计意图。整个组织在一个社区里，用频道（Channel）来划分团队、项目、职能——前端频道、某个项目频道、安全审查频道。人和 Agent 按需加入不同频道，信息在需要的时候跨频道流动，所有动作统一可审计、可搜索。

为什么第三种是对的？因为 Buzz 用"频道 + 签名身份 + 权限"这套机制，已经在一个统一空间内部解决了"隔离"问题——你不需要靠"分盒子"来做隔离了。一个 Agent 只能看到它被加入的频道；一个敏感项目的频道可以设为私有；每个操作都带签名可追溯。隔离是通过"成员权限"实现的，而不是通过"物理隔墙"。

这正是组织级工具和团队级工具的本质差别：团队级工具靠"隔离"来管理复杂度，组织级工具靠"统一底座 + 精细权限"来管理复杂度。前者简单但会形成信息孤岛，后者复杂但能让知识在整个组织流动。

所以用 Buzz 的推荐设计是：

一个公司一个社区做底座，频道对应你的真实协作结构：

按团队建频道（前端、后端、数据）——团队内部的日常协作
按项目建频道（某个功能分支、某次重构）——Buzz 支持"分支即频道"，一个功能分支的代码、CI、审查、讨论都在一个频道里
建跨团队的公共频道（部署规范、安全审查、架构决策）——这是全组织共享的知识层
Agent 作为频道成员按需加入，敏感频道设私有权限

知识沉淀的三层结构，在 Buzz 里天然就成立：

个人级：Agent 在各频道里的工作记忆
团队级：团队频道里沉淀的协作记录和技能
组织级：公共频道 + 统一事件日志——因为所有东西都在一个社区、一个可搜索的日志里，"全组织的知识检索"第一次变得真正可行

对比一下就看出差别了：在 Multica 里，"跨团队共享知识"需要你刻意再建一个公共 workspace，是一个补丁；在 Buzz 里，因为本来就是一个统一社区，跨团队的知识流动是默认能力，不是补丁。

这也再次印证了那条进化线——越往后的工具，越不需要靠"隔离"来管理复杂度，越能支撑"更大范围的协作和知识流动"。从 Multica 的"分盒子"到 Buzz 的"统一社区 + 精细权限"，本身就是一次进步。

写在最后

这一期我没打算给你一个"用哪个最好"的标准答案。因为我越来越觉得，比"选哪个"更重要的，是看懂这条进化线本身，以及它逼着我们思考的一个更大的问题。

四个项目，半年时间，一条从"个人"走向"组织"的清晰路径。它推进的速度快到，很多团队还在纠结"要不要用 AI Agent"的时候，工具本身已经跑到"怎么让一整个组织和 Agent 协作"这一站了。

而这里藏着一个大多数人还没反应过来的错位：大部分公司的组织结构、协作方式、知识管理体系，都是为"纯人类团队"设计的。部门墙、审批流、信息孤岛——这些在纯人类时代是"管理成本"，但在人机协作时代，它们会变成"进化的阻力"。

换句话说，当 AI Agent 已经进化到"能融入组织"这一站，真正的瓶颈可能不再是工具，而是组织本身能不能配得上这个工具。你上了 Buzz 这种组织级平台，却还用着团队级的"分盒子"思维，那工具的能力就被你的组织惯性浪费掉了——这正是前面工作空间那部分想说的。

所以这条进化线，表面上是四个开源项目的更替，本质上是在给每个团队出一道题：你的组织，准备好和 AI 一起工作了吗？

工具会一直迭代，进化线也还会往前走（下一站大概率是跨组织协作）。但有一件事是确定的——谁能更早地把自己的团队、知识体系、协作方式，调整成"人和 AI 都能高效运转"的样子，谁就能在下一站到来时，不是被工具推着走，而是已经站在了前面。

看懂趋势只是第一步。真正的差距，在于你愿不愿意为它改造自己。

关注我，持续拆解 AI 如何一步步重写软件的生产方式。