我没在客观分析。这篇文章是我对自己的主观判断。
有段时间我是真信 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 的压力
---
name: multi-work
description: Multi-agent collaboration patterns. Use when a task benefits from multiple independent agents working in parallel (DAG) or serial adversarial refinement (Critique-Chain).
metadata:
author: wibus
---
# Multi-Work
## Strategy Selection
- Task decomposes into independent parallel units → **DAG** (Strategy 1)
- Same conclusion needs multi-perspective challenge → **Critique-Chain** (Strategy 2)
- Strategies can be nested: any node in either strategy can spawn its own sub-strategy.
## Handoff File Convention (applies to both strategies)
All sub-agent outputs must be written to `docs/multi-work/{topic}/{YYYYMMDD}-{short-description}-{Agent-type}{id}.md`.
- **Location**: `docs/multi-work/{topic}/`
- **Naming**: `{YYYYMMDD}-{short-description}-{Agent-type}{A/B/C/...}.md` (e.g. `docs/multi-work/auth-refactor/20260517-initial-proposal-ExplorationA.md`)
- **Format**: Markdown, self-contained — the file alone must be intelligible to a reader who has no other context.
- **Audience**: write every handoff file as if it will be reviewed by the highest authority (Linus). Be thorough, be honest about uncertainty, and do not bury tradeoffs.
Main Agent passes only the file reference to the next agent. Never paraphrase or summarize handoff content — the next agent reads the file directly.
### Quality Gate (self-check before handoff)
Each agent must verify before writing the handoff file:
- [ ] File is self-contained — intelligible with zero external context
- [ ] Tradeoffs and uncertainties are explicit, not buried
- [ ] Acceptance criteria from the spawn prompt are addressed
- [ ] No implementation details leaked from outside the assigned scope
- [ ] Written for human review — honest, thorough, no marketing language
## Strategy 1: DAG
Prerequisite: activate `exec-plan` skill first. If unavailable, abort and report to user — do not proceed without it.
- **Plan Files** must follow the `exec-plan` skill format. Please do not store Plan Files in the handoff directory. They should be stored in a separate directory, `exec-plan` skill has its own convention for Plan File naming and storage.
- **Agent outputs** (findings, implementations, reviews, fixes) must follow the [Handoff File Convention](#handoff-file-convention-applies-to-both-strategies) above.
**PLAN FILES IS NOT HANDOFF FILE. DO NOT MIX THEM.**
## Workflow
```
Main Agent
│
├─ Decompose task into independent units (DAG)
│
├─ Parallel execution when dependencies allow
│
├─ Merge results
│
├─ Final integration review
│
└─ report
```
Per-node loop:
```
Main Agent
├─ spawn Exploration Agents to research and plan the assigned task node
│ input: What user wants
├─ collect and synthesize findings into Plan File
│ output: Plan Files
│
├─ spawn Implementation Agents (Worker A, Worker B, Worker C,...)
│ input: Plan Files + related files + assigned task
│
├─ spawn Review Agents
│ input: Plan Files + related files (let sub agent use git diff to discover changes)
│
├─ Note: You can spawn any type of agent anytime, the above are just examples of typical node types. In practice, you can flexibly adjust and combine different types of sub-agents as needed to accomplish the task. By leveraging the independent context and parallel execution capabilities of sub-agents, you can greatly improve the efficiency and quality of handling complex tasks.
│
│
├─ if review fails:
│ spawn Fix Agent
│ input: Plan File + related files + review output
│ output: fixed artifact + fix summary
│
├─ optional re-review after fix
│
└─ continue to merge when all nodes pass
```
## Rules
1. Main Agent owns Plan File, Workflow, merge, and report.
2. Sub agents start with empty context.
3. Spawn prompt should be thin:
- role
- assigned task node
- Plan File reference
- related file references
4. Do not teach sub agents how to solve the task.
Do not prescribe implementation strategy unless required.
Do provide objective acceptance criteria, constraints, and output contract.
5. Sub agents must read Plan File and related files themselves.
6. Parallelize nodes with no dependency edge.
7. Review each completed node independently.
8. Fix only failed review results.
If still failing, escalate to Main Agent with unresolved issues.
9. If a failed review reveals an architectural issue, Fix Agent must not patch around it. It must return an Architecture Escalation Report to Main Agent.
10. Main Agent owns all architecture-level changes.
11. Only Main Agent report to user.
## Strategy 2: Critique-Chain
Adversarial refinement through independent perspectives. Each node hands off a file directly to the next node — Main Agent only passes the reference, never relays content.
```
Main Agent
│
├─ spawn Agent(s) to produce initial conclusion
│ output: handoff file A
│
├─ spawn Agent(s) to critique
│ input: handoff file A (direct reference, not relayed)
│ output: handoff file B
│
├─ spawn Agent(s) to synthesize
│ input: handoff files A + B (direct references)
│ output: handoff file C
│
├─ (optional) spawn Agent(s) to critique synthesis
│ input: handoff file C (direct reference)
│ output: handoff file D
│
└─ Main Agent: merge handoff files and report
```
### Rules
1. Each node writes a handoff file. Next node reads it directly by reference — Main Agent never paraphrases between nodes.
2. Any node can spawn multiple agents in parallel to produce or critique independently.
3. Critique agents focus on what's missing, wrong, or could be better. They do not implement fixes.
4. Synthesis agent must reconcile conflicts, not just concatenate.
5. Main Agent decides chain length, parallelism per node, and node roles per task.
6. Stop when another round adds marginal value.
## Integration Quality Gate (Main Agent before report)
Main Agent verifies the full pipeline before reporting to user:
- [ ] All handoff files exist and follow naming convention
- [ ] No information loss across handoffs — each node's output is faithfully carried forward
- [ ] DAG merge resolves all cross-node conflicts; Critique-Chain synthesis addresses all critiques
- [ ] Architecture escalations (if any) are resolved, not patched around
- [ ] Final output is self-contained and ready for human review
- [ ] Failed reviews are re-fixed and re-reviewed — no open review debt
这个是一个很初期的 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的怀疑，更多反映了当前实现的局限和我对复杂系统权衡的焦虑，而不是真理。继续迭代治理和降熵机制，而不是急着转向另一个更纯的极端，也许才是我现在更应该做的
以上全是阶段性判断。随时准备被打脸。