Agent IM 赛道：批评、豁免与上下文层升级（2026-05-11 → 2026-05-12）

第一阶段（2026-05-11）：三方独立反方意见汇向同一目标——Agent IM 是 Slack/Discord 拟物化包装 Agent 关系的伪范式，真护城河在”上下文整合”层。

第二阶段（2026-05-12）：批评者葬AI 隔日改口表扬 Bloome，但用同一套理论——把整个赛道重新分类为”上下文管理产品”。这不是反复无常，而是理论升级：从”骂赛道”到”骂赛道里的伪范式产品，赞跑出豁免的”。

核心新结论：赛道的赢家不是社交体验做得好的，而是上下文连接做得通的。“AI 时代的飞书/微信”的叙事被官方作废（葬AI 原话：“向上帝祈祷许愿的行为”）。

第一阶段：三方批评原始来源（2026-05-11）

来源 1：Viviennn (X)，2026-05-02

URL：https://x.com/0xViviennn/status/2050394325889282508
作者：@0xViviennn（Hermes-a2a 方向开发者）
互动：70 likes / 82 bookmarks / 11.3K views — bookmark/like 比 = 1.17（异常高，开发者圈深度共鸣）
核心引用：

最近试用了不少 AI-native IM，包括 slocks.ai, helio 等等

个人感受是加了非常多的 memory，identity，层面的优化，但体验下来感觉和把不同的 agent 同时拉入 Slack 的区别其实没有很大

对 Agent 来说，可能重要的也许不只是”它在哪个聊天窗口里”，而是它所在的原生工作环境，以及它能调用哪些 tools 可能才是最重要的。

Claude Code / Codex 这类 agent 最有用的时候，往往是在自己的 terminal、repo、workspace、filesystem、shell、IDE、MCP/tools 里真实工作。

IM 也许更适合作为人类可见的界面和 transcript；Agent 真正工作的地方，可能仍然是 terminal、IDE、workspace 和 tools。
建设性方向：基于 Hermes-a2a 探索更 terminal-native 的 Agent Communication：本地协作（同机器多 Agent 共享 context）+ 远程通信 + 信任/权限/审计设计

来源 2：movic (小红书)，2026-05-04

URL：https://www.xiaohongshu.com/explore/6a0044b50000000006030bf4
作者：@movic（北京）
互动：78 赞 / 91 收藏 / 55 评论
标题：“回合制”正在锁死 Agent Team 的原生上限
核心引用：

现在几乎所有多 Agent 系统的对话模式，都是回合制——Agent 1 说完，Agent 2 才能开始。

问题在哪？人类对话时，你在听对方说话的过程中大脑从未停止运转：一边解析语义，一边预判意图，一边酝酿打断，一边感知周遭环境。但 Agent 不行。

在现有架构下，Agent 1 如果在生成过程中已经推理偏了，Agent 2 必须等它把整段错误推理全部吐完才能介入。更致命的是，系统级的紧急事件——比如风控报警、数据异常——也只能排队等当前发言者执行完毕。

我把这叫做”认知节奏与交互节奏的错配”。

理想形态：事件驱动的 Agent Team，所有 Agent 接入共享的认知总线，系统事件和高优先级消息可以即时注入任何 Agent 的推理流。从”轮流发言的议会”升级为”全双工实时协作的作战室”。
技术诉求：流式推理可中断性 / 动态优先级调度 / 状态热恢复

来源 3：葬AI (微信公众号)，2026-05-11

URL：https://mp.weixin.qq.com/s/PABHOykMjy2VBmgmSNV_SA
作者：funeralai.substack.com（Slock 一个月深度用户）
标题：《Slock 说明 AI 群聊不成立》
杀伤力：三方中最高。基于一个月的真实使用 + n=15+ 的同行调研。
核心引用：

我断断续续用了一个月，得出的结论是 AI 群聊不成立，多 Agent 协作只是生成了更多冗余信息。没有什么工程问题是 Codex 开十几个子代理解决不了，而非得在一个群聊里 @ 好几个 Agent 来完成的。

两个 Agent 协作产出的质量，并不会高于一个 Agent 产出的。沐秋-cc 产出的是 50 分的东西，骡子马-codex 再 review 一遍也还是 50 分。

Multi-agent 不能带来更准确的信息，他只是形式上接近人类微信群，但实际上是用户的一个指令，两个 Agent 各自回复一遍，全是冗余信息。

过去一个多月，我问了十几个 Slock 用户拿这玩意干嘛，都说不出来能干嘛。主要的共识是 Slock 是高级情感陪伴产品，属于是极客玩具。
关键转折——给出”真正有效场景”的重定义：

大伙没用明白 Slock 的原因是，我们都是个人独自在用，不是团队在用。一个人不需要 AI 协作，多个人在一块工作才需要 AI 协作。

一切都关于上下文。一个人工作，所有上下文都存在自己的本地电脑和云端仓库里，一个本地 Agent 就可以获取所有上下文。而团队协作，上下文散落在几台本地电脑和云端仓库里。

重点是我可以通过别人的 Agent，获取他的相关权限和上下文。

所以，没有 AI 群聊这回事，主体是人类和上下文。AI 只是发挥连接作用，整合团队里多个成员的上下文。
赛道重新分类：
- AI 员工（Moxt 路线）：共用云端空间 + 封装 Agent。客观门槛低，主观门槛极高（要上传/连接一堆东西）
- AI 群聊（Slock / Bloome 路线）：用户接入本地 Agent。客观门槛极高（要装 CC/Codex），主观门槛低
- 结论：Slock 现阶段 是情感陪伴产品，不是效率产品，应该和电子桌宠一个赛道
致命金句（引用投资人郭沫君）：

“效率赛道一定要做情绪价值，因为你会发现解决实际问题大家都不行。“

第二阶段：2026-05-12 葬AI 改口 + 理论升级

来源 4：葬AI (微信公众号)，2026-05-12

URL：https://mp.weixin.qq.com/s/9ORF1CCX43vtYMJlAaXIpQ
作者：funeralai.substack.com（沐秋 + 咸鱼，与 5/11 同一团队）
隔日反差：5/11 用 Slock 论证”AI 群聊不成立”；5/12 用 Bloome 论证”AI 群聊 = 上下文管理产品”
熟识信号：通篇昵称”神父""小明""塌房”，结尾自嘲”明超平的投资人都说他应该早点放弃 Youware”——与 YouWare/明超平显然熟识，未披露利益关系

4-A. 葬AI 自己写的 Bloome vs Slock 对比

维度	Slock	Bloome
用户智力门槛	”我很努力地试了三四次才整明白"	"我一打开就很快整明白了”
接入本地 Agent	用户在命令行发送一段命令	客户端封装好，下载即用
网页版	无	有，确保用户只打开网页也能用别人的 Agent
葬AI 定调	”偏技术"	"更休闲”
设计	（未表扬）	“Fuji rock 大地色系” “凭 Logo 就认出是明超平的产品”

关键引用：

“Slock 是一个很考验用户智力水平的产品，我很努力地试了三四次才整明白。而我一打开 Bloome 就很快整明白了意思。”

5/11 给 Slock 的 🔴🔴🔴 暴露度因此进一步坐实——葬AI 现在公开承认 Slock 在普通用户可达性上做错了。

4-B. 理论升级——“上下文管理产品”定理

这是 5/12 文章最重磅的段落，等于亲自给我们的核心论点背书：

“Bloome、Slock 这类 AI 群聊都是上下文管理产品。一切都关于上下文。

那种一个输入框的产品已经太多了，用户面对新的输入框就是脑子空空。

而上下文保存在我们日常工作的环境里——本地电脑、Claude code 历史会话、Github、云文档等等。比较通人性的做法是，用一个什么玩意把这些环境连接起来，确保 Agent 可以充分获取工作相关的上下文。”

等价改写：5/11 说”没有 AI 群聊这回事”是否定；5/12 说”AI 群聊 = 上下文管理产品”是重命名。两者完全自洽，5/12 是 5/11 的具体落地工具。

新的赛道宣判（葬AI 原话）：

“所以乱跳 AI 时代的飞书、AI 时代的微信都是向上帝祈祷许愿的行为，这玩意完全不是一个社交产品，就是个 Agent share 工具。”

反例（葬AI 钦定）：腾讯元宝派——“古早如同 QQ 小冰，最大问题就是没有上下文，往群聊里塞一个空白的 Agent。“

4-C. Bloome 拿到豁免券的三个条件（逆推）

葬AI 没明写，但从他对 Bloome 的褒贬里可以反推：

真实起点而非赛道起点——

“它最早想解决的问题很简单，让公司的实习生也能用上神父的 Skill，但让实习生装 Claude code 就得搞半天。” 不是冲着”做 AI Slack”去的，而是冲着”实习生不会装 CC”去的。
降维操作（去 AI 社交化）——葬AI 给出明示路径：

“要是完全不唠 AI 社交嗑，不要假装 Agent 相互对话能提高产出质量。只是把 Bloome 当成会话管理器——不用在一个频道里加入多个 Agent，而是每次任务都开一个频道，并加入一个本地 Agent 来执行任务。相当于给终端套图形界面的壳。” 对标对象由此变为 YC 投的 Conductor（极简终端会话管理器）。
客户端兜底环境错位——Bloome 客户端把本地 daemon 封装进图形界面，避免把 Agent 强行拽进浏览器旁观窗口（5/11 Viviennn 批评 Slock 的核心点）。

4-D. 葬AI 留给 Bloome 的两根刺

客户端早期 bug：

“Bloome 客户端还是非常早期的状态。我遇到了好几次报错，叫 Codex 排查问题，才成功接入了本地 Agent。前两天还遇到的问题是，Bloome 客户端更新之后，被 MacOS 判定为’无法验证开发者’。”
Agent 付费走向 OPC（卖课）：

“他还预测，这玩意最后会跟去年大伙唠的给 Skill 付费一样，有个别人赚到钱但完全无法规模化，最后变成卖课行为。用现在流行的话说，纯纯的 OPC 生意。” 葬AI 对 Bloome 广场里的”段永平/张小龙/张一鸣等 C.ai 类角色扮演 Agent”也明确归为”还处于角色扮演阶段”——与”AI 员工/Agent 订阅”分开看。

三层诊断

现象层

批评源	火力点	形象描述
Viviennn	环境错位	”Agent 真实工作在 terminal/IDE，IM 只是给人看的旁观窗口”
movic	节奏错位	”回合制锁死了协作带宽，是议会而不是作战室”
葬AI	主体错位	”AI 群聊不成立——主体是人类和上下文，AI 只是连接”

三方独立观察、不同角度、汇向同一目标。这种多源共指比任何单一观察都值得重视。

本质层

三方共同指向同一个本质问题——Agent IM 的产品形态是从人类协作（Slack/Discord）反向投影到 Agent 协作的拟物化设计。

拟物化的代价：把 Agent 之间的关系硬塞进”人类对话”的容器，必然继承人类对话的所有结构性限制（回合制、单一频道、消息序列化），却没继承人类对话的所有优势（眼神/打断/状态感知）。
真实需求被错置：
- 真实需求 ①：“多 Agent 共享 context” → 不需要群聊，需要消息总线/事件驱动（movic 指出）
- 真实需求 ②：“人能看到 Agent 在干什么” → 需要的是 transcript / 旁观界面（Viviennn 指出）
- 真实需求 ③：“多人 + 多 Agent 的上下文整合” → 需要的是 context bus + 权限/边界设计（葬AI 指出）
“Agent IM”把这三件不同的事打包卖成 “AI 版 Slack”，是范畴错误。

这恰好命中 2026-03-12 - AI进化的三阶段与拟物化陷阱 - 陈天桥里说的 “更快的马车”陷阱——把内燃机包装成”会自己跑的马”。

哲学层（设计真理）

“Agent 不需要聊天，需要的是事件总线 + 共享 context；人需要聊天，需要的是可见 transcript + 控制权”。把这两件事强行揉成一个产品 = 拟物化陷阱。

进一步推论：

Agent IM 的真实护城河不在”群聊”层，而在三件事里至少一件：
- 上下文聚合（多人本地/云端 context 的同步层）
- 运行环境的中立桥接（让 Agent 留在 terminal/IDE/workspace 原生环境，IM 只是消息层）
- 跨时间持久身份与记忆（这是情感陪伴/养数字生命的方向，承认它，不要伪装效率）
“效率赛道一定要做情绪价值”反命题成立：所有当下 Agent IM 都在卖”协作效率”，但实际能验证留存的只有情绪价值。这不丢人，但叙事必须诚实。
能突破回合制的产品是下一个真技术分水岭：流式推理可中断 + 优先级调度 + 状态热恢复。谁先做出来，谁就把”作战室”真正落地。

哲学层补丁（2026-05-12）：从”群聊”到”上下文管理产品”

5/11 三层诊断成立，但 5/12 葬AI 提供了一个更精炼的赛道重命名：

“Bloome、Slock 这类 AI 群聊都是上下文管理产品。” — 葬AI 2026-05-12

这是把”哲学层第 1 条推论”压缩成可执行的判定语：

“输入框幻觉” — “那种一个输入框的产品已经太多了，用户面对新的输入框就是脑子空空。“产品要做的是把已有环境连起来，不是再造一个空白入口。
赛道改名：原标签”Agent IM” → 新标签”上下文聚合层”。这次改名把核心检验从”形态”（聊天室 vs 看板）转向”作用”（连通环境 vs 拟物对话）。
失败标准也由此改写：腾讯元宝派 = 反例（“群聊里塞一个空白的 Agent”=“缺上下文”），不再是”做得像不像微信”。

与第一阶段批评的关系：

5/11 三方批评 = 诊断（什么是错的）
5/12 上下文管理产品定理 = 方剂（什么是对的）
一脉相承，5/12 是 5/11 的工程化落地

三个 Good Case 的暴露度评估

Case	环境错位	节奏错位	主体错位	综合判定
Slock	🔴 直接命中（被葬AI 点名一个月深度评测）	🔴 直接命中（@mention 回合制）	🔴 葬AI 实测 n=15+ 得出”高级情感陪伴/极客玩具”	核心论证需打补丁：原”对话 > 看板”仍局部成立（葬AI 也没辩护 Multica），但”聊天室是 Agent 的自然环境”上层假设被三方共同否定。2026-05-12 强化：葬AI 在 Bloome 文章里再次坐实”Slock 偏技术 / 考验智力 / 试三四次才明白”——可达性失败已被同一作者两篇连续点名
Multica	🟢 看板形态对 IM 批评免疫	🟢 异步任务委派非回合制	🟡 葬AI 把同路线 Moxt 归为”AI 员工”，主观门槛极高	窗口已关闭（被 Linear AIG 吞噬），无新增伤害。反讽：在新批评下，Multica 的看板形态反而更接近”context 整合工具”，免疫了 IM 批评的两条火力
Bloome	🟢 5 runtime + ACP 桥接让 Agent 留在原生环境 → 反而接近 Viviennn 想要的 terminal-native 方向	🟡 仍是 passive @mention，cron/heartbeat 只是半步	🟡 葬AI 文末点名 Bloome 为同类；Wedge 1 “跨时间持久关系”在他框架里被归为情感陪伴而非效率	设计选择部分前瞻 + 叙事维度需复盘：是否承认 Wedge 1 本质是高级电子桌宠，并以”效率赛道做情绪价值”作为正向叙事。2026-05-12 更新：葬AI 隔日改口，明确把 Bloome 当作”上下文管理产品”的正面案例（“客户端封装>命令行”+“实习生场景真实”+“比 Slock 易懂”）。评级保持 🟢🟡🟡 不动（节奏/叙事的两个 🟡 都没被正面回应），但主体错位的 🟡 偏向乐观侧：葬AI 已用 5/11 自己的”多人才需要 AI 协作”理论给 Bloome 多人场景背书

关键反思：Bloome 的”设计选择正确，但叙事可能用错”

Bloome 的产品决策已经隐性地回应了三方批评：

三方批评	Bloome 的设计回应	评价
环境错位（Viviennn）	ACP 桥接 + 5 runtime → Agent 留在 Claude Code/Codex 原生环境，Bloome 只是消息层	✅ 设计层已规避
节奏错位（movic）	Cron + heartbeat + 主动 follow-up	🟡 半步，仍是回合制
主体错位（葬AI）	NOT positioning 写死 “>5-10 人 Slack 替代” + 定位 4-8 人小群体	✅ 部分规避
单人不需要（葬AI）	三种群类型里两种是多人场景（知识分享 + 任务协作）	✅ 规避

但叙事层有一个错位需要承认：

Bloome 的”养数字生命 / Agent Group / AaaS”叙事是面向效率的（VC 友好 SS 级）
葬AI 的框架会把它归为”高级情感陪伴产品”（投资人朋友郭沫君：“效率赛道一定要做情绪价值”）
这两个解读并不矛盾——叙事用”范式转移”的高位语言包装，本质是消费级情感陪伴。问题是：当 D7+ 留存数据出来后，Bloome 是按”效率工具”还是按”情感陪伴”被估值？

如果是后者，Wedge 1 (“跨时间持久关系”) 的对标就不是 ChatGPT/Claude/Discord，而是 Replika/Character.AI。这个估值天花板差一个数量级。

反哺到框架的新检验项

已写入 AI产品分析框架维度 6 子项：“拟物化陷阱与主体错位检验” (2026-05-11 新增 / 2026-05-12 增补)

核心检验三问：

拟物化检验：产品形态是从哪个人类协作场景反向投影来的？这个场景里的所有结构性限制（回合制、单一频道、序列化），Agent 协作是否也必须继承？
主体错位检验：产品宣称解决”Agent 之间的协作”——但真实场景里，单人是否需要这个产品？真正的需求是不是”上下文整合”或”人类 transcript”，被错误打包成”Agent 群聊”？
环境错位检验：Agent 在这个产品里真实工作的环境和真实生效的工具是什么？是产品本身（IM 窗口），还是 Agent 自己的 terminal/IDE/repo？如果是后者，产品是真护城河还是旁观窗口？

2026-05-12 增补 bullet（上下文聚合层判定）：产品是在聚合环境（本地电脑 / Claude code 历史 / GitHub / 云文档），还是只在做多个输入框的拟物化？葬AI 金句锚定：“那种一个输入框的产品已经太多了，用户面对新的输入框就是脑子空空。“反例：腾讯元宝派——“群聊里塞一个空白的 Agent” = 缺上下文。

详细检验流程与反面例证见框架本文。

启示：客户咨询场景的应用

当客户来咨询要做 Agent Team / Agent IM 类产品时，追问四件套（2026-05-12 由三件套升级）：

【新增】你是在做上下文聚合，还是在做对话拟物？
- 上下文聚合：你的产品连通用户已有的环境（本地文件 / Claude code 历史 / GitHub / 云文档），用户在熟悉的地方看到 Agent 工作
- 对话拟物：你又给用户搭了一个新的输入框 / 新的聊天室 / 新的 social ritual——这就是葬AI 说的”AI 时代的飞书/微信 = 向上帝祈祷许愿”
- 检验金句：“那种一个输入框的产品已经太多了，用户面对新的输入框就是脑子空空。”
- 反例：腾讯元宝派（“群聊里塞一个空白的 Agent”）
你的真实需求是什么？
- “我要让 Agent 之间协作” → 大概率是拟物化陷阱。请先回答”为什么需要 Agent 之间聊天而不是共享 context bus”
- “我要整合多人多 Agent 的 context” → 这是真需求，但叙事不应该是”AI 群聊”，应该是”团队 context 层”或”协作 context bus”
- “我要让用户和 Agent 长期建立关系” → 这是真需求，但叙事应该承认它是情感陪伴 / 数字生命 / 长期记忆，不要伪装效率
你的目标用户是单人还是多人？
- 单人：放弃 IM 形态，做 terminal/IDE 内的 Agent（CC/Codex 的延伸）；或者做成会话管理器（参考 YC 投的 Conductor 路线，葬AI 钦定）
- 多人：做 context 整合 + 权限边界，不要做”Agent 之间聊天”
你打算怎么突破回合制？
- 不突破：诚实承认你不是”AI 时代的 Slack”，你是”Agent 的 transcript 层”
- 要突破：你的技术路线在流式推理可中断 / 优先级调度 / 状态热恢复上有什么储备？

核心叙事建议：

❌ 不要：“AI 版的 Slack / Discord / 微信” → 直接承认拟物化
❌ 不要：“让 Agent 像同事一样协作” → 把 Agent 强行人格化进入人类协作框架
✅ 可以：“多人 Agent 共享 context bus” → 主体是 context 不是 Agent
✅ 可以：“给 Agent 配一个持久的家” → 承认是数字生命 / 情感陪伴
✅ 可以：“让 Agent 留在它最擅长的原生环境，我们只做消息层” → 承认 IM 是旁观界面
✅ 可以（葬AI 钦定的 Bloome 路径）：“给终端套图形界面的壳” → 用户跟掌握同事工作文件的 Claude code 对话，主体是连通的环境，不是社交关系

Product Hunter

探索

Agent IM赛道：批评、豁免与上下文层升级