首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >Karpathy说这是LLM的第三次交互革命——Agent群聊模式,新范式还是新叙事?

Karpathy说这是LLM的第三次交互革命——Agent群聊模式,新范式还是新叙事?

作者头像
老周聊架构
发布2026-07-08 14:16:43
发布2026-07-08 14:16:43
30
举报
2026年6月,AI行业几乎同时出现了两个"群聊"形态的产品:
  • Claude Agent Teams(2月发布):多个Claude实例组成团队,互相发消息、共享任务列表、点对点协作——Agent之间的群聊
  • Claude Tag(6月23日发布):Claude以"同事"身份常驻Slack频道,主动参与讨论、自主接任务、异步交付——Agent和人类的群聊

Andrej Karpathy(对,从OpenAI跳到Anthropic的那位)直接发推说:这是LLM交互方式的第三次重大革命。

第一次:用户去大模型的网页(ChatGPT网站)

第二次:大模型变成你下载的App(桌面端、手机端)

第三次:大模型变成一个"组织级实体"——有工具、有记忆、有上下文,跟人类团队并肩工作

这话说得确实让人兴奋。但作为一个老架构师,我的第一反应是:等等,让我先看看架构和成本数据。

今天这篇文章,不吹不黑,从架构层面拆解群聊模式——它到底解决了什么问题、创造了什么新问题、以及值不值得你现在就跟进。


一、先搞清楚:Agent Teams和Claude Tag到底是什么?

这两个产品名字容易混淆,但它们解决的是完全不同的问题。

1.1 Agent Teams:Agent之间的群聊

Agent Teams是Claude Code的多Agent编排能力。你在一个Claude Code会话里说"组建团队",它就会启动多个独立的Claude实例,每个实例像一个团队成员一样工作。

关键架构:

代码语言:javascript
复制
Team Lead(主Claude会话)
    ├── Teammate A(独立Claude实例)→ 写前端代码
    ├── Teammate B(独立Claude实例)→ 写后端API
    └── Teammate C(独立Claude实例)→ 写测试
        ↕ 点对点消息(Mailbox系统)
        ↕ 共享任务列表(Task Board)

核心创新:点对点通信(P2P)。 之前的subagent模式是"Hub-and-Spoke"——所有子Agent只能跟主Agent汇报,彼此之间无法直接沟通。用人话说:以前是所有人只能跟领导说话,现在同事之间可以直接拉群。

1.2 Claude Tag:Agent和人类的群聊

Claude Tag是Anthropic在Slack里推出的新产品。Claude以一个"同事"的身份加入你的Slack频道,你可以@Claude给它分派任务,它会在子线程里自主完成并汇报。

关键特性:

能力

说明

多人共享

整个频道共用一个Claude,所有人都能@它

上下文记忆

它会"听"频道里的对话,逐渐理解团队上下文

主动参与

开启Ambient Mode后,它会主动插话——提醒遗漏、同步信息

异步执行

给它派任务后可以去干别的,它自己做完在子线程汇报

自主调度

它可以给自己安排未来的任务,自主推进项目

底层模型:Claude Opus 4.8。 对,用的是最新最强的模型。

1.3 一句话总结区别

Agent Teams = 多个AI之间的协作(面向开发者/工程场景)

Claude Tag = AI和人类团队的协作(面向企业/团队场景)

前者是"AI自己开会",后者是"AI参加人类的会"


二、群聊模式到底解决了什么真实问题?

在分析"是不是新范式"之前,先看它解决了什么问题。

2.1 Agent Teams解决的问题:Agent之间不能说话

以前的subagent模式是这样的:

代码语言:javascript
复制
主Agent
    ├── 子Agent A(写前端)→ 只能向主Agent汇报
    ├── 子Agent B(写后端)→ 只能向主Agent汇报
    └── 子Agent C(写测试)→ 只能向主Agent汇报

问题在哪?子Agent A发现了一个API接口变更,需要告诉子Agent C调整测试用例。但A不能直接告诉C——它必须先告诉主Agent,主Agent再转告C。

用人话说:你和同事坐在同一个办公室,但你们不能直接说话,所有沟通都得通过领导转达。 效率低不说,领导还会成为瓶颈。

Agent Teams的P2P通信解决了这个问题:

代码语言:javascript
复制
Teammate A ←→ Teammate B(直接发消息)
Teammate B ←→ Teammate C(直接发消息)
Teammate A ←→ Teammate C(直接发消息)

2.2 Claude Tag解决的问题:AI不在工作流里

以前用AI的方式:

代码语言:javascript
复制
你在工作 → 遇到问题 → 打开ChatGPT/Claude网页 →
复制粘贴上下文 → 等结果 → 复制回来 → 继续工作

每次都要"切换上下文"——从工作环境切到AI环境,再切回来。 这个切换成本看似很小,但一天切几十次就很痛了。

Claude Tag的解法:AI直接待在你工作的地方(Slack),不用切换。

代码语言:javascript
复制
你在Slack频道讨论 → @Claude "帮我查一下这个数据" →
继续讨论其他事情 → Claude在子线程回复结果 → 你扫一眼就行

更进一步的是Ambient Mode:你甚至不需要@它,它自己会在合适的时候插话。 比如它发现某个讨论涉及到上周它处理过的问题,会主动提醒"这个事情上周讨论过,结论是xxx"。


三、架构拆解:三种多Agent编排模式

群聊模式不是凭空出现的。它是多Agent架构从v1到v3的自然演进。

3.1 v1:Hub-and-Spoke(中心辐射型)

代码语言:javascript
复制
        主Agent
       /   |   \
      A    B    C

代表: Subagent模式、早期的LangChain Agent

特点: 主Agent控制一切,子Agent只能向上汇报

问题: 主Agent是瓶颈,子Agent之间无法协作

3.2 v2:GroupChat(群聊型)

代码语言:javascript
复制
    A ← → B
    ↑  ×  ↓
    D ← → C
    [Selector决定谁发言]

代表: AutoGen GroupChat、CrewAI

特点: 所有Agent共享一个对话线程,由Selector决定谁下一个发言

问题: 对话线程会爆炸式膨胀,5个Agent的群聊,Token消耗是单Agent的5-10倍

3.3 v3:Peer-to-Peer + Shared State(点对点+共享状态)

代码语言:javascript
复制
    A ←→ B       Shared Task Board
    ↑    ↓       ┌─────────────┐
    D ←→ C       │ Task 1: ✅  │
    [直接通信]    │ Task 2: 🔄   │
                 │ Task 3: ⏳  │
                 └─────────────┘

代表: Claude Agent Teams

特点: Agent之间P2P直接通信 + 共享任务列表做协调

创新点: 不用所有人都"听"所有对话,只需要点对点通信——大幅减少Token浪费

3.4 三种模式对比

维度

Hub-and-Spoke

GroupChat

P2P + Shared State

通信方式

只能跟主Agent说

全体广播

点对点+广播

瓶颈

主Agent

对话线程膨胀

任务列表竞争

Token效率

中等

最差(5-10x)

较好

适用规模

2-3个Agent

3-5个Agent

3-5个Agent

协作质量

中(有对话噪声)

代表产品

早期LangChain

AutoGen

Claude Agent Teams


四、实战数据:群聊模式有多好用?有多贵?

4.1 Claude Agent Teams的战果

Anthropic自己用Agent Teams做了一件很疯狂的事:用16个Agent协作,从零开始用Rust写了一个C编译器,能编译Linux 6.9内核。

指标

数据

Agent数量

16个

产出代码

10万行Rust

编译目标

Linux 6.9内核

API成本

约$20,000

这证明了一件事:Agent群聊协作在复杂工程任务上确实能产出高质量结果。

4.2 Claude Tag的内部数据

Anthropic内部团队使用Claude Tag一年后的数据:

"65%的产品团队代码是由Claude Tag创建或合并的。"

而且更有意思的是:Claude Tag本身就是用Claude Tag构建的。 套娃了属于是。

4.3 但是——成本问题

这里要泼一盆冷水了。

根据多个独立测评和框架文档的数据:

场景

Token开销倍数(相比单Agent)

独立多Agent

~1.6x

中心化多Agent(Hub-and-Spoke)

~2.9x

群聊多Agent(GroupChat)

5-10x

Agent vs 普通Chat

~4x

多Agent研究系统

~15x

用人话说:5个Agent开群聊,聊一次的钱够1个Agent聊10次的。

这是群聊模式最大的争议点。效果确实更好,但成本也确实更高。 如果你的场景不是"复杂到必须多Agent协作",单Agent可能是更明智的选择。

4.4 2026年的行业共识

"先做单Agent版本,跑通评测集,然后每增加一个Agent都要证明它能提升评测分。"

这句话是2026年多Agent领域最"不性感"但最正确的工程准则。

用人话说:不要因为"群聊模式很酷"就上多Agent。要因为"单Agent真的搞不定"才上多Agent。


五、Karpathy的"第三次革命"论,对不对?

Karpathy把LLM的交互方式分为三个时代:

阶段

形态

类比

第一代

用户去网页(ChatGPT.com)

你去银行柜台办事

第二代

下载App(桌面端/手机端)

你用手机银行App

第三代

组织级实体(Claude Tag)

银行职员直接坐在你办公室

他说Claude Tag是第三代的代表——AI不再是你"去找"的工具,而是"一直在你身边"的同事

5.1 支持方的论点

这个框架确实抓住了一个真实的趋势:AI从"工具"变成"角色"。

工具的特点是:你需要的时候拿起来,不需要的时候放下。

角色的特点是:它一直在场,有上下文,有记忆,能主动行动。

Claude Tag的Ambient Mode就是这个转变的极致体现——你不需要@它,它自己就会在合适的时候说话。 这已经不是"工具"了,这更接近"同事"。

5.2 反对方的质疑

但批评也很尖锐。

质疑一:"这不就是个高级聊天机器人吗?"

有人认为Claude Tag本质上还是"对话式AI",只是把对话窗口从网页搬到了Slack。交互形态变了,但底层能力没有质变。

质疑二:记忆边界问题

Anthropic的Joanne Jang提出了一个精辟的类比:"#gtm频道的圣灵不知道#general频道里的组织架构调整。"

意思是:Claude Tag在不同频道之间记忆不互通。它在A频道学到的上下文,不会自动带到B频道。这对于号称是"组织级实体"的产品来说,是一个根本性的限制。

质疑三:Karpathy现在是Anthropic员工

有人指出Karpathy从OpenAI跳到Anthropic之后,他的"范式革命"言论多少带着些"为自家产品站台"的嫌疑。球员当裁判,这公信力你品品。

质疑四:Slack真的是正确的载体吗?

一些批评者认为,让AI"常驻"在协作工具里,可能把Slack从"团队协作工具"变成"AI编排噪声"。想象一下:你打开Slack,发现一半消息是AI发的——这还是协作工具吗?


六、新范式还是新叙事?我的判断

说了这么多,回到最初的问题:群聊模式到底是新范式还是新叙事?

我的答案是:底层技术是真实的进步,但"第三次革命"的叙事过度了。

6.1 哪些是真实的范式进步

P2P通信是真正的架构创新。 从Hub-and-Spoke到Peer-to-Peer,这解决了多Agent协作中信息传递的根本瓶颈。就像分布式系统从主从模式到对等网络的演进一样——这是实打实的架构升级。

Ambient Mode是真正的交互创新。 AI从"被动应答"到"主动参与",这确实改变了人机协作的方式。不再是"你问我答",而是"我一直在旁边看着,有用的时候我会说话"。

共享任务列表是正确的协调机制。 比起让Agent们在对话里自己协调(AutoGen GroupChat的做法),用结构化的任务列表做协调更清晰、Token效率更高。

6.2 哪些是过度叙事

"第三次革命"言过其实。 网页→App→组织级实体,这个框架听起来很工整,但Claude Tag目前的实际能力——Slack里的异步任务执行——跟"组织级实体"还差着一个量级。它更像是"一个比较聪明的Slack Bot",而不是"一个数字同事"。

多Agent ≠ 更好。 行业数据明确显示:多Agent的成本是单Agent的5-15倍,但效果提升远没有那么线性。绝大多数场景下,一个优化得好的单Agent比五个互相聊天的Agent更实用。

"群聊"这个比喻有误导性。 人类群聊之所以有效,是因为每个人有独立的世界模型、独立的动机、独立的信息源。AI Agent的"群聊"本质上还是同一个模型的多个实例在互相说话——它们共享相同的知识、相同的偏见、相同的能力边界。这更像是一个人跟自己的多个分身开会,而不是一群不同背景的同事在协作。

6.3 一张表做个总结

维度

判断

理由

P2P通信架构

✅ 真正的范式进步

解决了多Agent信息瓶颈的根本问题

Ambient主动参与

✅ 有意义的交互创新

从被动应答到主动协作

共享任务列表

✅ 正确的工程决策

比对话协调更高效

"第三次革命"

⚠️ 叙事过度

实际能力离"组织级实体"还很远

多Agent默认更好

❌ 误导

5-15x成本,效果提升非线性

群聊=团队协作

❌ 类比有误

同一模型多实例≠不同背景的人类团队


七、给不同角色的实操建议

7.1 如果你是技术Leader

现在就可以试Agent Teams,但要用在真正适合的场景——多模块并行开发、大规模代码重构、跨仓库迁移。不要用在单文件Bug修复上,那是大炮打蚊子。

评估公式:如果任务可以自然拆分成3-5个独立但有交互的子任务,且单Agent搞定需要超过2小时,那Agent Teams值得一试。

7.2 如果你是团队管理者

Claude Tag值得关注但不用急着上。 它目前还在Beta,且仅限Enterprise和Team计划。等几个月看看early adopter的反馈再说。

重点关注这几个问题:

  • 记忆边界:它在不同频道之间能不能共享上下文?
  • 成本控制:Token消耗有没有组织级的预算上限?
  • 安全审计:它访问了哪些数据,有没有完整的日志?

7.3 如果你是AI应用开发者

不要急着跟风做"群聊模式"。 2026年的行业共识很明确:

先把单Agent做到极致,单Agent真的不够用了,再加第二个。每加一个Agent,都要能用评测数据证明它的价值。

多Agent是能力的上限,不是默认配置。


写在最后

Agent群聊模式的出现,本质上反映了一个更深层的趋势:AI正在从"问答工具"向"协作角色"演进。

这个方向是对的。但具体的实现方式——无论是Agent Teams的P2P通信,还是Claude Tag的Slack常驻——都还处于非常早期的阶段。

真正的范式转移不是某个产品发布的那一天,而是这个产品变成所有人默认工作方式的那一天。 从这个标准来看,群聊模式还差得远。

但也不要因此忽视它。P2P通信解决了多Agent协作的根本瓶颈,Ambient Mode开创了人机协作的新交互方式。 这些是实打实的技术进步,值得持续关注。

一句话总结:群聊模式是一个正确方向上的早期实验——架构创新是真的,范式革命是吹的,但两年后回头看,我们可能会发现它就是起点。

— 完 —

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-07-06,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 老周聊架构 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、先搞清楚:Agent Teams和Claude Tag到底是什么?
    • 1.1 Agent Teams:Agent之间的群聊
    • 1.2 Claude Tag:Agent和人类的群聊
    • 1.3 一句话总结区别
  • 二、群聊模式到底解决了什么真实问题?
    • 2.1 Agent Teams解决的问题:Agent之间不能说话
    • 2.2 Claude Tag解决的问题:AI不在工作流里
  • 三、架构拆解:三种多Agent编排模式
    • 3.1 v1:Hub-and-Spoke(中心辐射型)
    • 3.2 v2:GroupChat(群聊型)
    • 3.3 v3:Peer-to-Peer + Shared State(点对点+共享状态)
    • 3.4 三种模式对比
  • 四、实战数据:群聊模式有多好用?有多贵?
    • 4.1 Claude Agent Teams的战果
    • 4.2 Claude Tag的内部数据
    • 4.3 但是——成本问题
    • 4.4 2026年的行业共识
  • 五、Karpathy的"第三次革命"论,对不对?
    • 5.1 支持方的论点
    • 5.2 反对方的质疑
  • 六、新范式还是新叙事?我的判断
    • 6.1 哪些是真实的范式进步
    • 6.2 哪些是过度叙事
    • 6.3 一张表做个总结
  • 七、给不同角色的实操建议
    • 7.1 如果你是技术Leader
    • 7.2 如果你是团队管理者
    • 7.3 如果你是AI应用开发者
  • 写在最后
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档