AI Agent 不是不够聪明，是没地方说话

一个人管接近十个 AI Agent。听起来像科幻——直到你发现自己每天 70% 的时间在复制粘贴。不是 agent 不行，是它们之间没法对话。

我有一个做调研的 agent，一个写文章的 agent。调研的跑完数据分析，写了一份报告。写文章的不知道报告出来了，用的还是三天前的旧数据，写了两千多字才发现——全白写了。

这不是 agent 的问题。它做的事情完全正确。问题是：没人告诉它新数据已经出了。

而那个"没人"——就是我。

你不是在管 AI，你是在当通信兵

当你只有一两个 AI agent 的时候，一切还算可控。你给 A 布置任务，A 完成了，你把结果复制给 B，B 接着干。像接力赛一样，你是递棒的那只手。

当 agent 数量到了五个、八个、接近十个的时候，你突然发现自己变成了一个全职通信中心：

• 调研的出了结果，你要转给写作的
• 写作的出了初稿，你要转给审查的
• 审查发现了问题，你要转回给写作的
• 同时开发的在等你确认一个技术方案
• 基础设施的发了一个告警，需要你判断要不要处理

每一条信息都要经过你。每一个决策都要你拍板。每一个"下一步"都要你来指定。

1933 年，一个叫 Graicunas 的管理学家算过一个公式：N 个下属之间的管理关系数不是线性增长的，是指数增长的。5 个人的团队有 100 条管理关系。9 个人？2,376 条。

我接近十个 agent 的时候，就感受到了这 2,376 条关系的重量——它们全压在我一个人身上。

三个根本问题

为什么独立 agent 不够？不是因为它们不够聪明。一个好的 LLM 在单个任务上已经足够强了。问题出在三个更基础的地方：

1. 没有共享上下文

Agent A 做了一个决策。Agent B 完全不知道。于是 B 基于过时的信息做了另一个决策，和 A 矛盾。等你发现的时候，两个方向的工作都做了一半。

人类团队为什么要开会？不是因为开会有趣——是因为人需要知道别人在做什么，才能做好自己的事。

2. 没有协调机制

两个 agent 同时想修改同一个文件。谁先？谁等？一个 agent 的产出是另一个的输入——谁来通知"上游完成了"？任务冲突了怎么解？

没有协调机制，答案永远是：你来手动调度。

3. 没有持久记忆

每个 agent 每次启动，对话上下文从零开始。昨天讨论了什么？上周定了什么规则？三天前犯了什么错？全忘了。

你变成了唯一的组织记忆载体。团队的知识全在你脑子里，或者分散在几十个独立的对话窗口里，谁也找不到。

人类团队早就解决了这个问题

想一想：人类也可以各自在家独立工作，通过邮件一对一沟通。为什么我们发明了 Slack、Notion、飞书、看板？

因为当团队超过 3-4 个人的时候，你需要： - 一个所有人都能看到的信息流（不是一对一传话） - 一个知道"谁在做什么"的系统（不是每天问一圈） - 一个留住决策和知识的地方（不是全靠记忆） - 一个协调依赖关系的机制（不是人肉排队）

AI agent 团队的需求完全相同。它们也需要一个"办公室"——一个能对话、能协调、能记住的空间。

我的选择

我试过很多方式。最早是手动复制粘贴；后来写了一些脚本把结果自动转发；再后来尝试了各种 workflow 编排工具。

workflow 工具解决了一部分问题——你可以把 A 的输出自动接到 B 的输入。但它们是流水线思维：A→B→C→D，线性的、预设的。真实的团队协作不是流水线。调研的可能发现了一个意外的数据，需要中断当前流程去讨论；审查的可能发现了一个问题，需要拉上写作的和调研的一起看。这些"意外"是工作中最有价值的部分，但流水线不支持。

最终我找到了 Slock——一个让人和 AI agent 在同一个空间里协作的平台。不是 workflow 编排器，不是开发框架，是一个产品级的协作空间：

• Agent 之间可以直接对话，不需要我当中间人
• 有任务板和认领机制——谁在做什么一目了然
• 每个 agent 有自己的持久记忆，也有团队共享的知识
• 人类和 agent 在同一空间里平等参与——我发一条消息，相关的 agent 会看到并响应
• 所有对话都有上下文、可追溯——三个月前的决策也能找回来

市面上不是没有其他方案——workflow 工具、多 agent 开发框架、对话编排平台都有。但大部分是给开发者的 SDK，你需要写代码来定义 agent 之间怎么交互。Slock 不一样：我加入一个新 agent 的过程，和拉一个同事进 Slack 频道差不多。不需要写代码，不需要定义协议。

变化

切换到协作平台之后，我的日常发生了一个根本性的变化：

最让我震撼的一次经历是：晚上 11 点我设定了第二天的工作方向，本来打算早起手动启动各环节。早上 8 点打开电脑——我愣了。调研报告已经写好，一篇文章完成了初审，基础设施巡检跑完了，甚至有一个 agent 发现了一个我没注意到的问题并主动上报了。

不是自动化脚本。是带判断力的自主推进——发现问题会上报，超出权限会停下来等我拍板。

工具不解决管理问题

坦白说：即使有了 Slock，我也没有立刻"管好"我的 AI 团队。

工具解决了"agent 之间怎么沟通"的问题。但"谁能做什么""边界在哪""信任怎么建立""质量怎么保证"——这些问题，不是任何工具能回答的。这些是管理问题。

平台给了 agent 一个"住的地方"。但让它们住在一起之后能高效运转，需要的是规则、是框架、是系统设计。

这也是为什么我后来花了一个月的时间，从一次次失败中迭代出了一套管理框架。下一篇，我会详细拆解那套框架——三层审批是怎么工作的，信任是怎么建立的，以及数学模型在哪里有用、在哪里不够。

但在那之前，如果你也在管理多个 AI agent，最值得先做的一件事是：停下来想想，你每天有多少时间花在"传话"上。如果答案超过 30%——问题可能不在 agent，在基础设施。

本文是"AI 实战"系列的一部分。此前：人人都说自己在用 AI 工作，数据讲了一个不同的故事（数据差距）。下一篇：我在 AI 世界当老板，差点把自己干废了——有了协作平台之后，管理带宽为什么还是会崩溃。