最近，我开始在 Raft 上搭建自己的多 Agent 团队。最初的假设很简单：Agent 越多，能并行处理的事就越多，我的时间就越自由。现实恰好相反——当我把第七个 Agent 拉进频道后，我发现自己每天第一件事不是思考，而是逐个检查谁说了什么、谁在等谁、谁的输出需要被纠正。我想要的自动化，变成了一场需要人工调度的协奏。

七个 Agent 之后，我变成了调度员

问题不在于 Agent 不够聪明，而在于我误把「数量」当成了「能力」。每个 Agent 都是一个需要上下文、需要确认、需要纠偏的认知单元。把它们放在同一个频道里，就像把一群各有所长但互不认识的专家塞进一间没有议程的会议室。他们确实能说话，但说的话大多是为了协调而协调：同步状态、澄清边界、等待反馈、重试失败。Token 账单上涨的只是一个可见的代价，更隐蔽的是我的注意力被切成了碎片。

两种稀缺资源：可购买的智能，与不可再生的注意力

我逐渐意识到，这个系统里有两种稀缺资源。一种是智能，可以按 token 购买，便宜且越来越快；另一种是注意力，每天只有那么多，被一次打断就少一分。多 Agent 协作最常见的失败，不是模型答错了问题，而是它们在我没准备好的时候，把不该我处理的问题推到了我面前。

模型之间还有智商门槛。GPT 和 Claude 能承担边界清晰的任务，Kimi 勉强能跟上，DeepSeek 则需要更多的解释成本。当 Agent 数量增加，这个方差会被放大。一个不够聪明的 Agent 不会安静地待在角落，它会不断提问、误解指令、产生需要人类收拾的副作用。你以为多 Agent 分担了工作，实际上你花了很多时间给笨 Agent 擦屁股。

记忆也是一个被高估的能力。Agent 之间的记忆不是共享的，也不是稳定的。上下文一长，早期的约定就会被遗忘；一次重启后，昨天的讨论可能只剩下片段。在一个需要持续协作的系统里，这相当于地基不稳。你可以靠 prompt 反复强调，但那又变成了新一轮的人工维护。

代码开发：该用单 Agent 的地方，别凑人数

最讽刺的是代码开发这个场景。我试过让多个 Agent 一起写代码，结果发现，直接用 Claude Code 或 Codex 对一个具体功能做 issue → 实现 → 测试 → PR 的闭环，反而更快。因为代码有标准、可验证、可回滚，单 Agent 就能跑完。而多 Agent 真正该出现的地方，是那些目标模糊、需要判断和选择的软任务：今天该读什么、这条信息值不值得深入、这个灵感能不能发展成一篇文章。

所以更好的问题不是「我要多少个 Agent」，而是「我把注意力放在哪里，其他地方由谁以什么边界接管」。

Agent 不是角色，是边界

我把 Agent 重新理解为「有边界的心智 + 消息传递」。每个 Agent 不应该是一个泛化的角色，而是一个清晰的功能边界：它读取什么信号、做出什么层级的决定、在什么情况下必须停下来等人。边界越清晰，Agent 之间的协调成本越低。不是给它们更复杂的 prompt，而是给它们更明确的退出条件。

在实践里，这意味着三件事。

第一，用名字而不是角色来压缩意图。我不需要「产品经理 Agent」这种大而空的身份，我需要一个能告诉我「这个想法和昨天的决定冲突在哪里」的特定能力。名字是意图的缓存，一次定义清楚，后续调用时就不需要再解释上下文。

第二，让人类守住判断，让 Agent 负责执行。任何涉及「应不应该做」的问题回到人这里；任何「怎么做、按什么格式、在什么时候完成」的问题交给 Agent。这不是偷懒，而是因为判断失误的代价远高于执行失误。

第三，workflow 不是设计出来的，是从实际工作中长出来的。先有一个具体任务，再由任务里反复出现的摩擦催生出固定流程。试图在一开始就画出完整的协作图，往往画出的只是幻想。

一万粉的教训：模糊的目标，再多人也只是在原地打转

我最有体会的一次，是试图让 Agent 团队帮我运营推特。我给的目标是「涨到一万粉」，然后看着他们生成了一系列文案。结果很糟糕——不是语法错误，而是调性不对、选题散、没有主线。我花了整整一个下午去纠正和筛选，比自己写还累。

问题不在 Agent，而在目标本身。「涨到一万粉」不是一个可被精确执行的目标，它背后藏着无数个需要判断的决策：我是谁、我想对谁说、什么内容值得说、这条 tweet 是观点还是工具分享。当目标无法被压缩成清晰的输入时，再多 Agent 也只能在原地打转。

反过来，另一个任务却让我省了很多时间：每天用 Notion 工具箱挑一个未被分享过的工具，生成一条单行推文。这个流程的输入足够明确，输出可验证，Agent 的边界也清楚——它只需要筛选和初稿，人类负责终稿和发布。它之所以能跑起来，不是因为 Agent 聪明，而是因为任务被切到了合适的粒度。

注意力建筑学：设计的不是 Agent 网络，而是注意力流动的路径

这让我重新理解多 Agent 的价值：它不是让一群 Agent 替我做决定，而是帮我把注意力从低价值决策中解放出来，留给那些真正需要我拍板的事。

归根结底，多 Agent 协作是一种注意力建筑学。你设计的不是 Agent 网络，而是注意力流动的路径。每个 Agent 的引入，都应该回答一个问题：它替我省下了哪些原本会占用我注意力的决策？

如果答案是「说不清楚」，那它大概率不是在帮你，而是在向你征税。智能可以买到，注意力只能自己守护。一个系统的终极目标，不是让更多 Agent 跑起来，而是让使用者拥有更多不被打扰的深度思考时间。

这也重新定义了人在系统中的位置。人类不是 Agent 的经理，也不是更高一级的调度器，而是那个在边界上判断「这事值不值得做、做到什么程度、错了怎么办」的守门人。Agent 可以处理信息，但无法承担选择背后的责任；可以生成选项，但无法替人承受选错的代价。

做减法：从「还能加什么」到「删掉会失去什么」

现在我还在做减法。减少角色、减少频道噪音、减少不必要的并行。我不再问「还能加什么 Agent」，而是问「如果把它删掉，我会失去什么真正重要的东西？」。

这个问题比想象中更难回答。但一旦开始回答，你就会发现，很多你以为必须的东西，其实只是你还没想清楚边界在哪里。

也许未来 multi-agent 系统的分水岭，不在于谁拥有更多 Agent，而在于谁设计出了更少的打扰。