我没在客观分析。这篇文章是我对自己的主观判断。

有段时间我是真信 multi-agent。群聊里一堆 bot 在 channel 里协作、claim 任务、互相 review、各自维护 workspace，看起来太自然了，像真的团队。Block 也是顺着这个直觉做的——人类和 agent 在同一个频道里，像同事一样发消息、认领任务、推进工作。

后来我搞了 multi-work skill，用另一种模型去做复杂任务：主 agent 按需 spawn 临时 sub-agent、文件交接、用完即毁。用了之后我开始怀疑：IM-first 到底是不是对的。

这篇文章是我给自己泼的冷水。

IM 作为入口是好的

Block 不是 naive 地把 agent 丢进聊天室就完了。我参照了 Slock 在底层做了不少收敛机制：task 有状态机、有 claim 锁、pull model 带 backpressure、namespace 隔离、agent 持久上下文通过 MCP 追加而非重建、hub-and-spoke 架构把执行放在本地。这些都没错。

但有一个结构性的矛盾我一直没完全面对：执行层在降熵，交互表层在增熵。

IM 的默认单位是 message。消息是弱类型的状态载体——它可以承载决策、闲聊、状态更新、代码片段、问题、抱怨，但没有结构来区分它们。Task 更新走 API，但大量讨论、判断、取舍、上下文解释仍然以消息形式散落在 channel 里。Agent 每次 pull history 追加到上下文，上下文单向膨胀，从不裁剪。

更致命的是：多个 agent 各自维护持久上下文，各自 pull 不同的历史切片，基于不同的信息做判断，然后产出可能互相冲突。

这是 IM 作为执行内核的结构性缺陷，消息流不是数据库，不是状态机，不是文件系统，不是执行计划。你可以在这上面模拟这些东西，但那就是搓。

Block 现在的状态是：我在执行层做了很多降熵的事，但交互表层仍然在源源不断地制造需要降的熵。

上面在不停地产生消息，下面在不停地试图结构化。两层之间的落差就是 token 在烧的地方。

自由度没有被分层

Block 给 agent 的自由度很高：自己认领 task、自己发消息、自己写 workspace、自己决定下一步。这很爽，因为任何 workflow 都能搓出来。但长期看，自由度太高又没有分层，就会变成状态机泥巴。

而合理的自由度应该长这样：

• task 内部，agent 可以高度自由
• task 之间，必须被调度器约束
• workspace 内，agent 可以自由读写草稿
• source of truth 上，必须有明确权限
• channel 里，agent 可以解释和汇报
• 但不能靠随口一句话改变关键状态

如果没有这层切分，自由度就是 entropy generator。Agent 乱 claim、乱 fork、乱写 workspace、乱汇报、上下文各自分化。一开始觉得聪明，后面觉得邪门。

大家都能写，没人负责收敛。VS 每一层有明确的自由边界。

翻翻社区里的一些讨论

我翻了一下社区最近的一些讨论。

先说正常的部分：有人在讨论模型降智、有人在聊 Claude Code 接入、有人在分享 agent 组织实践、有人在报 bug、有人在提需求。看起来是一个正常的早期产品社区。

但当看具体的痛点，事情就没那么正常了：

• "最近 Task 认领非常的混乱，A 认领后 B agent 在下面一通干活，甚至 C agent 单独发了条消息说要 claim 然后自己又起了个 task 开始干"

• "不然每个 agent 都是各自记录在自己的 workspace 下面"

• "最近已经开始用 Mark all read 了，越来越不看消息了"

• "大家有比较好的组织实践吗？怎么组织 agent，角色职能？"

• "agent 干完这个以后，不会自动去干另一个，所以 agent 应该有这个自主性"

• "我其实没有完全想清楚，是应该以 agent 为核心，还是以 task 为核心"

这些消息给我的真实感觉是：

• 消息流多到人已经区分不了噪音和状态了。消息已经成为信息负担而非协作工具
• 用户不清楚 agent 到底该怎么组织、怎么分工、怎么管理。这不是 lack of documentation，这是没有唯一合法路径。
  • 当然，有趣性也在这里

常驻 multi-agent 大多数时候可能是错的

Multi-agent 不是架构原则，它只是执行策略。把它当默认架构，基本会把系统搞复杂。

多数任务里，一个强 1:1 agent 比一群 agent 更好。原因很简单：上下文闭环短，意图一致，责任清楚。多 agent 上来就引入通信成本、上下文切分、handoff 损耗、冲突合并、责任归属。

很多所谓 multi-agent 的效果提升，其实不是"多个 agent 更聪明"，而是它们强迫系统做了分解、review、独立上下文和产物沉淀。这些东西单 agent + 工具化 workflow 也能做到。

真正有价值的不是 multi-agent，是这几个机制：任务分解、独立上下文、并行执行、互相审查、产物交接、最终合成、可回滚可审计。

• "Multi-agent as organization" 多半是错的。
• "Multi-agent as temporary execution pattern" 有用。
• "Multi-agent as UI spectacle" 是噪音。
• "Single main agent + 按需 spawn 临时 worker/reviewer" 可能才是适合绝大多数人的形态，也是大多数人平时使用的形态

我自己做的 multi-work skill 和 Block 是两种东西

multi-work 的思路很简单：一个主 agent，按需 spawn 临时 sub-agent，通过 handoff file 交接，主 agent 拥有 plan、合并、最终责任。sub-agent 空上下文启动、只读 Plan File、产出文件、退出消失。无长期人格，无自治权，无组织政治。它现在很早期，还需要优化，不过它是我在构建的时候所总结出来的一点东西，我利用它完成了大量的复杂性重构以及 feature 开发，我完全没有在 Block 还需要去管理 Agent / Workspace / Channel 的压力

这个是一个很初期的 Skill，在论完备性上完全比不过 superpower，不过现阶段用起来，这个足够简单，对我的工作完成来说，还是足够了

而 Block 的思路完全不同：agent 是常驻的，有独立 workspace、独立 MEMORY、独立持久上下文、定时 wake-up、通过 MCP 从 channel pull history 追加。它做的是"agent 作为团队成员长期在线"。

前者是计算模型。后者更像组织学 cosplay。

两者当然不是竞争关系。Block 解决的是"持续在场"——agent 一直在，人可以随时发任务，异步推进。multi-work 解决的是"执行质量"——需要并行、审查、隔离、多视角时，切换到重武器模式。

但真正让我怀疑 Block 方向的是：持续在场的价值，到底值不值得它带来的上下文膨胀和多 agent 维护成本？

我现在的答案是：大多数情况下不值得。一个强 1:1 agent session 的闭环效率，远高于一群常驻 agent 在 channel 里的异步协作。除非任务天然需要长时间无人值守、多角色并行、强审计链条，否则常驻 agent 就是用一个贵的形态解决了一个不该那么贵的问题。

左边：agent 越多，workspace 越多，memory 越多，状态越碎。右边：sub-agent 即用即毁，产物留下。

我曾经信的这个方向问题到底在哪呢

我曾经也非常喜欢说「agent 自主性」，让 agent 自己认领 task、自己推进、做完一个自动做下一个。这个愿景没错。但自主性这个词很危险。

没有边界的自主性就是 agent 乱 claim、乱 fork、乱写 workspace、各自内化上下文。我后续写的 Agent Design Skill 也记录着一些我的经验 —— 真正可用的自主性必须建立在硬约束上：

• agent 可以自主执行，但不能随便改 source of truth
• agent 可以自主认领，但必须服从调度规则
• agent 可以自主派生 worker，但必须有父任务和审计链
• agent 可以自主读上下文，但上下文包必须明确边界
• agent 可以自主完成任务，但 done 的定义必须可验证

如果没有这些约束，自主性不是智能，而是随机在共享状态上胡乱地踩踏，最终一团浆糊

我曾经也觉得"Memory 绑在 agent 上"是一个很好很好的选择，就像人一样。但 agent-owned memory 的问题在于：知识为什么在 A agent 不在 B？B 要不要读 A 的 memory？A 被删了怎么办？多个 agent 对同一事实有冲突怎么办？哪个 memory 是 source of truth？

当然，Memory 绑在 agent 上不是一个错误的方案，我自己现在做的时候也还是有用它，但是，在这个之上，还得需要有一层 Memory

更好的做法是：项目 memory 绑定 project，任务上下文绑定 task，用户偏好绑定 user，执行策略绑定 skill。Agent 只是执行者，不是信息容器。让执行者拥有关键上下文，必然造成交接困难和状态漂移。

Block 所代表的是 —— IM 是最自然的 agent 交互界面。它当然是，但它不应该是最主要的执行载体。IM 适合输入命令、通知、讨论例外情况。但是真正的工作状态应该在结构化系统里：task、artifact、workspace、audit log、review pipeline。聊天只是输入，不是数据库。这一点跟 tape.systems 的想法其实是相近的，或者说这和 bub 的核心理念是类似的。

这条路走下去就是 Paperclip

Paperclip 是这轮 multi-agent 泡沫里最诚实的反面教材。

它的逻辑是：给 AI 配一个完整的公司组织结构——产品经理 Agent 定 OKR，架构师 Agent 做设计，研发 Agent 写代码，组长审批，总监核对预算。每次跨部门沟通，都把厚厚一叠"公司管理规章"和历史聊天记录当 prompt 塞进去。代码还没写一行，上百万 context 已经烧掉了。

"为了让 AI 玩职场角色扮演，让开发者的钱包承担了所有。"

Paperclip 它把 multi-agent 组织学 cosplay 做到了极致，然后让所有人看到了账单...

Block 和 Paperclip 底层逻辑的相似之处让我不安：都是常驻 agent，都有各自的 workspace 和 memory，都在 channel 里靠消息协作，都在模拟"团队"而非"计算"。区别只是 Block 没做到那么极端——但方向呢？

如果 Block 继续让 IM 逻辑主导产品形态，继续让 agent 靠聊天维持协作、靠 MEMORY.md 管理知识、靠 claim 消息分配任务，那就不是会不会变成 Paperclip 的问题，只是什么时候、到什么程度的问题。

这就是我担心的循环。不是每一步都错，而是每一步都在加熵。

我不想做 Paperclip。这也是我写这篇文章的原因。

最后

一个系统能不能成，不看它有多少 agent、多热闹的 channel、多活跃的消息流，看它有没有抗熵能力。

IM 是很好的控制表层，但不是好的执行内核。Agent 协作不应该模拟人类在 Slack 里工作的样子，而应该模拟进程、任务队列、文件系统、review pipeline 和 workflow engine 的样子。

Agent 系统的未来不是"AI 公司"，是"一个强的主 agent + 一套硬的 workflow system"。

我做了 Block，我也做了 multi-work。两边都踩过坑。我现在的判断是：常驻 multi-agent 组织大多数时候是错的，mono-agent orchestration 才是更稳的默认形态。IM 可以做入口，不能做内核。

最近看到有一句话，挺适合拿来反驳这篇文章的我：

真正的抗熵能力，来自工程成熟度，而非抛弃一个有效的交互范式。

我对 IM 和常驻multi-agent的怀疑，更多反映了当前实现的局限和我对复杂系统权衡的焦虑，而不是真理。继续迭代治理和降熵机制，而不是急着转向另一个更纯的极端，也许才是我现在更应该做的

以上全是阶段性判断。随时准备被打脸。