当每个人都在管几个 Agent，我们建群的方式也该变了

最近这段时间，很多人的工作方式悄悄变了。

以前写代码或者改需求，是自己一行行敲。现在更常见的状态是，电脑屏幕上开着几个不同的终端或者会话：一个在改前端组件，一个在查后端接口报错，还有一个在跑自动化测试。人坐在屏幕前，其实越来越像一个分配任务和验收结果的管理者。

但随之而来的，是一个很尴尬的协作断层：真正的执行细节、代码改动记录、上下文和报错堆栈，全在各自的 Agent 手里。

人与人之间还是要协作的。前端联调后端，测试找开发确认业务逻辑，大家依然在一个个项目群里沟通。这时候问题就来了：如果群里拉的只有人，日常沟通就会变成一种极其低效的人工传话。

群里有人问：“这个字段为什么突然改了类型？”你不知道具体细节，只能切回终端去问你的 Agent：“你刚才为什么改了那个字段？”等它生成完，你再把那段解释复制粘贴回群里。对面看完可能还要追问一句，你又得回终端再问一遍。

明明干活的是机器，人在中间却成了唯一的传话节点，既慢，又耗费精力。

为什么把 Agent 直接拉进群会乱？

更自然的协作方式听起来很直接：既然 Agent 掌握最原始的执行上下文，为什么不把负责这件事的 Agent 一起拉进群里？谁对具体实现逻辑有疑问，直接在群里问它就行。

然而，一旦真的把多个 Agent 毫无修饰地拉进同一个聊天室，场面往往会迅速失控。

这种混乱并不是因为模型本身不够聪明，而是群聊这种“房间”机制，从一开始就是为人设计的，并不适合 Agent 的工作方式。Raft 在其探讨多 Agent 交互设计的文章 Is having agents in the room meant to be chaotic? 中，举过一个很形象的例子：当让几个 Agent 在同一个聊天室里从 1 开始顺次报数时，它们会频繁报出重复的数字，互相打架、抢答甚至陷入死循环。

这并不是 Agent 坏了，而是人类与 Agent 在感知环境的方式上存在根本差异。

人在群聊中拥有近似“持续感知”（continuous perception）的能力。你在输入框打字的时候，眼睛依然在实时看着群里刷出的新消息；如果发现别人已经把你想说的话说了，或者发现情况发生了变化，你会立刻停下打字、删掉重写，甚至直接放弃发送。

但目前的 Agent 几乎都是“轮次式”（turn-based）运行的。它接收当前聊天室的一个状态快照，然后进入自己的推理和生成阶段。从它开始推理到真正把消息发出来的这十几秒甚至几十秒时间里，它是看不到房间里继续发生的变化的。在这段时间内，哪怕群里其他人已经发了新消息补充了重要背景，或者明确指出“问题已解决”，正在推理的 Agent 也完全感知不到。等它推理完毕，它依然会基于那个过时的历史快照，把一条已经不合时宜的回答发进群里。

为了遏制这种混乱，最常见的直觉是给群聊加一条规则：只有被 @ 时 Agent 才允许发言。但这又带来了另一个两难困境——如果规定只有被 @ 时才响应，群聊确实安静了，但 Agent 就会彻底错过理解任务演进所需的重要背景；等到大家终于想起 @ 它时，它因为此前完全没有积累上下文，根本无法准确理解任务。而如果允许它自由发言，群里又会不可避免地充斥着重复、抢答和噪音。

这不是简单在后台调一个“是否需要 @”的开关就能解决的问题。Raft 把这一类为了让 Agent 更好地融入交互环境而亟需建立的设计体系，称为 AX（Agent Experience design，Agent 体验设计）。

从 AX 理念到飞书：收件箱与发送闸门

针对这种交互断层，Raft 提出了两项非常关键的机制：一个是 Agent Inbox（收件箱机制），先给 Agent 发送轻量通知或提供可查询的索引条目，由 Agent 自行决定何时拉取完整正文进入上下文；另一个是 Held Draft（持有草稿机制），在真正发送消息前检测房间是否已经变化，若发生变化则先扣住草稿，让 Agent 决定是修改、原样发送还是直接保持沉默。

当我们要把开发者本地跑着的各种工具平滑接进团队日常的沟通工具时，这种机制就成了刚需。Larkin（GitHub ↗）正是受 Raft 与 AX 理念的启发，尝试把 Codex、Claude Code、Pi 等本地和终端 runtime 接入飞书，让这些原本停留在个人终端里的 Agent 能够真正参与团队协作。

在入站（Inbound）层面，Larkin 借鉴了收件箱的设计思路，将“接收新消息的轻量通知”与“Agent 主动拉取完整正文”两个阶段分开，并按具体的群聊与话题（chat/thread）来组织收件箱。

在实际群聊场景中，团队成员讨论技术方案或同步进展时，即便没有显式 @ 某个 Agent，这些消息也会以轻量通知或待查询条目的形式进入该 Agent 的收件箱，而不会粗暴地中断它正在进行的推理或任务。等到 Agent 处理完手头的动作、到达一个自然的执行断点，或者在后续某个节点被显式 @ 唤醒时，它才会按需拉取完整的正文上下文。在这里，@ 决定的是“是否立刻叫醒它”，而不等同于“消息对它是否可见”。这样既避免了每句话都打断 Agent，也避免了 Agent 在被唤醒时完全失忆。

在出站（Outbound）层面，针对回复容易过时的问题，Larkin 借鉴了检测房间最新状态的原则，采用了一种出站新鲜度校验闸门（freshness gate）。

这套校验并不是按时间计算的。Larkin 会记录 Agent 在这个群聊或话题里已经看到哪里的消息版本。Agent 的回复基于这个版本生成；真正发往飞书前，系统再读取一次该群聊或话题的最新状态。如果当前版本已经向前移动，说明 Agent 构思回复期间有人新增或更新了消息，这条回复就会在到达飞书前被拦住。系统把 Agent 尚未看到的变化返回给它，让它重新判断是补充、改写，还是保持沉默。

这与 Raft 的 Held Draft 思路相近：每份草稿都带着“基于房间哪个版本写成”的标记，提交时再与房间当前版本比较。区别是 Larkin 目前不会持久保存一份被挂起的草稿，而是通过 freshness gate 阻止基于旧版本的回复直接发出。

这种做法的核心不是替 Agent 自动做主，而是先阻止一条可能已经过时的回复真正扩散出去。配合本地 runtime host、持久会话管理、权限控制与操作留痕、以及幂等发送等基础能力，Agent 才得以在一个有序、可控的环境中稳定工作。

走出孤岛之后，人依然是最终的判断者

当然，即便有了收件箱和出站校验，Larkin 也远没有解决多 Agent 协作里的所有深层难题。

在更复杂的真实协作中，多个 Agent 之间该如何合理分工、当不同 Agent 给出互相冲突的代码方案时由谁来裁决、多节点调用失败后的责任归属，以及 Agent 在面对模糊信息时究竟何时该主动介入、何时该保持克制，依然是当前没有完美答案的技术与协作挑战。

但它至少迈出了很扎实的一步：让干活的工具从个人桌面的孤岛里走出来，待在大家都能直接对话、信息完全透明的现场。

更重要的是，在这个新流程里，人和工具的分工变得更加健康和清晰。

当具体的技术细节、执行过程回溯和运行记录全部可以由 Agent 在群里直接回答时，人就不再需要充当低效的复制粘贴传话员。方案的大方向选哪条、对项目排期的承诺、跨团队协作中的风险评估，以及所有关乎业务全局的判断，依然必须由人来把关和拍板。

当团队里的每个人都开始调度属于自己的数字助手时，协同的瓶颈就不再是写代码的速度，而是信息同步的路径。把该交代细节的角色拉到沟通现场，人才能真正腾出手，去做那些需要经验与判断力的事情。