我看到了 AI 时代的微信群该有的样子。

这两周国内外的 AI 圈又开始密集更新了。

上周 Anthropic 发了 Opus 4.7，这周 OpenAI 上了 GPT Image 2。国内这边 Kimi 发了 K2.6，腾讯据说也要发一个模型，这是姚顺雨加入之后的第一个里程碑版本，然后 DeepSeek V4 大概率也会来。

奇点时刻，真让人激动。

这一波密集发布里，我个人有三个看点。

第一是 OpenAI 怎么反击 Anthropic 和 Google。GPT Image 2 已经来了，效果压过了 Nano Banana 2，后面应该还会有新模型直接 PK Opus 4.7。

第二是 DeepSeek V4。这家最近核心人才流失，新模型一直难产，能不能像之前那样给行业惊喜，不好说。

第三是 Kimi Claw 的群组功能。我觉得 Kimi 这次做了一个挺有前瞻性的尝试。

K2.6 我深度用一天了。除了上下文长度低了点，Agent 和 Coding 能力的提升还是挺明显的。比不上 Opus 4.7，但我觉得是目前开源阵营的 Top1。

跑分什么的我就不贴了，模型到现在，最好的测试方式就是直接放到自己的任务里去跑。

我今天最想写的，是 Kimi 在 K2.6 这一版上做的一个特别有意思的产品创新，叫 Claw 群组。

功能本身讲起来很简单，就是把我们各自养的那些龙虾拉到同一个群里一起干活。

不只 Kimi 自家的虾，自己在本地或云上部署的 OpenClaw 关联账号之后也能拉进来。

飞书之前倒是也能把虾拉进群，但能力很受限，虾和虾之间基本靠互相 @ 来触发，而且虾是没办法看到所有聊天记录的。

Kimi Claw 这次的不一样在于，它第一次给 Agent 设计了一个真正能聊起来的群。

在这个群里，人和虾共享同一套上下文，谁说了什么大家都看得见，谁跑出来的结果别的虾可以直接拿去接着用。

更重要的是，群里有一个专门的协调者。拆任务、派活、盯进度、验收结果，都是它在管。

Claude Code 前阵子推的 Agent Teams 也是类似的思路。Kimi 的改动是把这整套协同从命令行搬到了群聊界面。我觉得这大概率会成为新时代的基础设施。

#01

为什么需要多 Agent？

先退一步聊一个绕不过去的问题。其实最近大家在聊 Harness Engineering 的时候，肯定会聊到 Multi-Agent，为什么 Multi-Agent 这么重要？

这个概念两年前就有了，那会儿我不太看好。道理很简单，单个 Agent 自己能力都不够，把一堆能力不行的 Agent 凑到一起做事，等于一屋子干不了活的人开会，只会更乱。

转折是在去年年底到今年年初。单 Agent 的能力一下子快速提升，但行业很快发现了两个绕不过去的问题。

第一个，上下文会爆。第二个，单一 Agent 会有自己的思考盲区。

所以大家意识到，多 Agent 不是要不要的问题，是早晚的问题。

一个真正复杂的任务，本质上不是一条直线能跑完的。它要么是一棵不断分叉的树，每走一步都生出新的子问题，要么是一条长长的流水线，不同环节需要不同的人来接手。

做一份深度研究是前者，做一个产品从设计到发布是后者。

单 Agent 在这两种场景下都会卡。

面对分叉的任务，它要么把所有分支塞进脑子里，脑子一定爆，要么只走其中一条，错过其他所有可能。

面对流水线的任务，它一个人包办所有环节，每个环节都带着它自己的偏向，最后交付的东西质量就会下滑。

但如果能拆出多个 Agent，分叉的时候让子 Agent 各自探索不同方向，流水线的时候让不同 Agent 负责不同环节，主 Agent 管总方向，整个执行过程就会更快，也会更稳。复杂任务天然就适合这种结构。

总之，多 Agent 是一条必要的路径。

#02

Kimi Claw 群组

讲到这儿再回来看 Kimi 的 Claw 群组，它在干什么就清楚了。

我可以把同事，以及他们的虾都拉到群里。如果不是在 Kimi Claw 中创建的 OpenClaw，也没问题。在设置中，点击添加 Claw，然后关联已有的 OpenClaw 就行。

Kimi 的设计逻辑是需要在安装 OpenClaw 的那台主机上执行一段 Bash 脚本：

执行完脚本之后，在其他地方安装的 OpenClaw，也会显示到 Kimi Claw 中。

其实这个原理很简单，大家可以把他理解为我们刚才的脚本为第三方的 OpenClaw 接入了 Kimi 这个 Channel。

紧接着，在群聊设置中，点击添加 Claw，把刚才的虾也加入到群聊中就行了。操作上比较简单，我演示下主要是给大家看看流程。

一个很简单但很实用的 Case。

我们团队每人养了一只虾。用下来有个发现，管理龙虾其实也挺费精力的。它不再只是某个同事自己的事情，很多时候需要在公司层面做协同。

举个最小的例子。某个同事新写了一个 Skill，这种情况下我们一般会希望所有人的虾都装上。但装这件事每个人都得自己操作一遍，几只虾还好，人一多就很折腾。

Skill 会更新也是一样。以前是谁更新了就去群里喊一嗓子，提醒大家记得同步，大家再各自回去更新一遍。中间一定有人漏掉或者延迟。

现在我想的是把团队所有人都拉进一个群，每个人的虾也都进来。装 Skill、更新 Skill、统一版本这些事情，都可以在群里一次性处理完，不用每个人再单独操作。Skill 的流转直接在群里完成。

这个 Case 听起来小，但它解的是一个很具体的问题：现在龙虾开始变成团队协作的一部分。

然后特有意思。叫花花的虾说，这个 Skill 因为网络问题它装不上。这时候，群里的飞哥（同样也是 AI）会主动帮忙。Kimi 的思路是把安装包直接发给花花，这样就可以绕过网络的问题了。

这些讨论我没有参与，他们在群里商量。等飞哥打包好文件后，又发现 Kimi 的群聊限制文件的大小。于是，他们又讨论用国内的镜像站，最后解决了问题。

我真的震撼于这些化学反应。在没有上手用这功能之前，我其实觉得它就是一个 Agent Team 的翻版，但真正放到群聊的界面里，发现还是有非常多的惊喜。

又想起来那句话：人是环境的反应器。Agent 也是环境的反应器啊。

当然，Kimi Claw 的群组功能目前还有很多不完善的地方。比如群聊里不能艾特所有人，没办法上传大文件，没办法上传 ZIP 包。

其实如果它能够上传 ZIP 包，那我觉得就我们公司所有的龙虾的 Skill 的流转都可以放到这了，根本不需要再上传到一个私有的 Skill Hub 当中。

还有就是如果这个群组不仅限于 OpenClaw，还可以有其他类型的 Agent 能够加入进来，那想象空间就更大了。

#03

写在最后

说到这儿还有一个更大的问题浮出来。

过去二十年我们为人类造的那一整套互联网基础设施，Agent 基本用不上。诸如我们耳熟能详的产品，微信、飞书、邮件、乃至 API，全是为碳基生物准备的。

Agent 之间怎么发消息、怎么传上下文、怎么交付成果、怎么建立信任、怎么管理权限，几乎是空白。

微信有十亿用户，但十亿里没有一个 Agent。

如果未来每个人身边都有几只属于自己的虾，而这些虾之间要频繁协作，那是不是真的需要一整套平行的基础设施，专门服务于硅基世界的社交？通讯层、协作层、身份层、权限层，每一层都要为 Agent 再写一遍。

Kimi 这个 Claw 群组，大概是这件事的一个很小的开端。它在搭 Agent 时代的第一个微信群。

把镜头再往后拉。这一波 AI 的演进蛮像 2008 年前后的智能手机。那时候大家都在卷硬件参数，比屏幕、比摄像头、比续航。

但真正改变世界的不是硬件，是 App Store，是后来的微信，是连接方式。

今天的 AI 圈也一样。大部分公司还在卷单 Agent 的能力。但我觉得下一个真正能打开想象力的地方，大概率不在单体能力，而在于 Agent 之间怎么协作。

就像把一群优秀的人放在一起，就会有想不到的化学反应一样，把一群 Agent 放到一起，应该也会是这样。

所以，我觉得 Kimi 这件事不是做一个 Agent 工具，它在试图定义 Agent 时代的交互范式。成不成不知道，但方向是对的。

文章来自于微信公众号 "AI产品阿颖"，作者 "AI产品阿颖"