多智能体的协作方式：Agent Team 和 Agent Room

最近在实践多智能体的设计方式，也准备考虑给 ActSpace 添加多智能体的功能，主要是多智能体如果设计得当的话，是可以在提高效果的同时节省成本的，这对于很多做应用的团队来说，成本的控制是可以带来极好的用户体验的，我觉得这也是 Harness Engineering 的概念之一

在不断的探索的过程中，我有一种新的感觉，多智能体的设计，尤其是协作方面非常的有意思，而且很有挑战性，我也感觉这个也是目前很多成熟 Agent 在突破的主要方向之一，从 ClaudeCode 推出来的 Agent Team 和 Dynamic Workflows 可以感受到一些

下面记录了我在多智能体协作上的部分探索与思考，谨小认知，仅供参考

调研资料：

• 《Is Having Agents in the Room Meant to Be Chaotic?》：https://raft.build/resources/blog/is-having-agents-in-the-room-meant-to-be-chaotic/
• 《multica 开源项目》：https://github.com/multica-ai/multica

• 《Model and effort in Claude Code: knowing more vs. trying harder》：https://x.com/ClaudeDevs/status/2074900291062034618

一、Agent Team 的设计思路

Agent Team 是多智能体的协作方式之一，类似于一个组”临时团队”一起攻坚一个复杂的任务，里面会有负责人的角色（Lead）、同时也会存在团队的成员（Teammate），交流关系不仅仅是负责人和成员之间的交流，成员和成员之间同样可以交流

一个 Agent Team 最核心的四个组件：团队负责人、任务清单、团队成员、消息收件箱

核心的运行步骤如下：

1. Team Lead 根据任务的复杂性生成任务清单，同时开始创建团队的基本信息
2. Lead 可以直接分配任务给团队成员做，同时在空闲的时候团队成员也可以主动领取任务
3. Lead 和 Teammate 的交流，不是直接交流的，是通过 inbox(消息收件箱）发送消息，类似于人类协作中的发送邮件的操作

Team Lead 创建任务和团队基本信息的时候，是依靠两个工具：taskCreate 和 TeamCreate，这两个工具会创建两个关键的文件夹的，我们假设团队名叫做 jink-team，那么创建的文件夹结构如下：

~/.claude/teams/jink-team/
~/.claude/tasks/jink-team/

🌵 那么任务清单创建好之后，如何分配任务呢？

Agent Team 是通过Lead 分配和团队成员主动领取这两个方式，Lead 分配任务使用的是 TaskUpdate 方法，团队成员主动领取任务使用的是 TaskList 先获取任务的状态，然后根据状态来领取任务，这是程序中循环调度器实现的，每 500ms 循环执行一次。

最核心的地方来啦，团队的协作交流，Agent Team 中的交流信号分为两种：信息和指令，是通过消息收件箱传递的

1. 信息就是一些内容，一些任务的描述和输入，就和正常的用户输入是一样的
2. 指令是一些硬信号，例如：权限的审核通知，团队成员会将执行权限审批先发送给负责人的收件箱，负责人在读取之后，将该指令传递给前端用户，用户审核之后，状态在一步一步回流，还有团队成员的进程关闭等

消息收件箱也很简单有效，就是一个 json 文件，里面的消息会有一个是否读取的状态，每一个 Agent 执行的之后，都会有循环调度去反复去读取这个文件，如果有新消息，会在 Agent 的下一轮将消息注入到上下文中执行

所以我们可以发现，Agent Team 的消息传递只是通过简单的文件 + 调度器的方式，非常有效，不过在实现这种传递方式时，最关键的是要注意文件锁的设计

例如：任务清单很可能会出现两个 Agent 同时读取同一个任务，这个时候状态会变得不稳定，所以我们要设置文件锁，同一个时刻，只有由一个 Agent 读取并且执行修改。

NOTE

当某一个 Agent 抢到文件锁的时候，那么该文件的所有权就是交给这个 Agent 来控制啦，其他的 Agent 只能在旁边先等待

ClaudeCode 团队的实现非常的有灵性，简单的使用一个 mkdir 方法就实现啦，mkdir 在文件系统上是原子的：同一时刻只有一个人能建成这个目录

我这里简单介绍一下：当 Agent 读取 3.json任务时，会在同级目录下创建一个3.json.lock/文件夹，那么其他的 Agent 使用 mkdir 创建这个文件的时候，会发现文件已经存在，就会进行等待状态，当 Agent 操作完成3.json这个任务之后，就会主动删除这个3.json.lock/ 文件夹

tasks/jink-team/
  3.json          ← 真正的任务内容
  3.json.lock/    ← 「有人正在改 3.json」（锁的物理形态）

二、Agent Room 的设计思路

Agent Room 同样也是多智能体的协作方式之一，这个里面没有”Lead”，是一次平等的交流，互相讨论，发表意见，在一个房间里面多智能体进行思想碰撞

对于 Agent Room 中的理解，核心在上下文的主动与被动，如果从聊天室出发，将 Agent 拉入，那么聊天室的每一次消息都会灌入 Agent 的上下文中，Agent 是被动接受这些信息的，从上下文的管理角度来说，这种方式的处理非常糟糕

因为每一条注入上下文的消息，模型都会关注的，如果无关的信息过多，冲突的信息存在，那么这些都会干扰 Agent 去做决定，我们从 Agent 的角度去理解就很直白啦

那么怎么理解，或者说怎么做是不错的协作方式呢？对于 Agent Room 来说，核心是两点概念：收件箱和草稿板

• 收件箱：聊天室的每一次消息都会放入到 Agent 的聊天室收件箱中，但是要推入什么信息到 Agent 上下文中，完全由 Agent 自己来决定，它可以选择性的拉去收件箱中的消息
• 草稿板：Agent 每一次真正输入到聊天室之前，先判断一下聊天室或者收件箱的消息列表是否更新啦，如果没有更新，那么直接输出，如果更新啦，那么消息被暂存并且添加一些附加信息再次注入回上下文执行，这次 Agent 有四种选择修改、原样发送、放弃、强制发送

这里的概念 Raft 博客说的特别好，详细完整的大家可以去看看原文：https://raft.build/resources/blog/is-having-agents-in-the-room-meant-to-be-chaotic/

我这里还有一种思路，大家可以参考借鉴的，没有收件箱和草稿板，聊天室的消息直接被推入到 Agent 的上下文中，但是多了一个概念：叫做思维精灵（子 Agent）

设想是这样的：Agent 不进行任务的执行，只负责分发任务给思维精灵执行，最终等待子智能体结果进行综合分析回复，在回复之前，会调用工具”抢占发言令牌”，相当于班级中的”举手发言”啦，举手成功之后，就可以将最新的消息一并同工具返回之后，那么聊天室这段时间都属于该 Agent，那么其就进行最终的回复

🎃 当然这个只是一种猜想，我还没有具体实践过，感兴趣的朋友可以自行尝试梳理！！！

三、Agent Task 的设计思路

Task 是 Agent 执行的最小单元吧，所以这里我也想要一起简单的梳理一下，一个 Task 只能被一个 Agent 执行，但是一个 Agent 可以同时执行多个 Task

产生 Task 的方式我们也可以结合上面两种设计来看

1. Agent Team 产生的 Task，更多像是一个复杂任务被拆分为一个一个的小任务，可以定义为一个临时任务
2. Agent Room 产生的 Task，偏向于用户手动指定某一个成员执行一个任务，例如：执行 bug 修复任务或者执行某一个领域的检索任务，可以定义为一个完整的任务
3. 用户或者 Agent Room 是可以产生一种有时间属性的任务，是定时任务，到时间就执行的任务

那么对于设计多智能体项目时，是可以有一个 Task 模块的，里面可以按照昨天状态显示当前执行的各种任务，也可以按照 Agent 显示目前每一个 Agent 执行的任务是什么

四、Agent Member 的设计思路

在多智能体的协调中，Member 这个角色很重要，Agent Team 中就需要真正执行的 Member，Agent Room 中也是如此

所以 Member 是需要一个完整的定义的，它不是临时的，是有身份，有头像，有名字，有设定，有工具，有范围，有记忆等等，这种 Member 在 Agent Room 中使用会非常直接方便，就相当于 Agent Room 中的成员，一个 Member 可以进入多个房间，Room 会话互相不干扰

但是在 Agent Team 中我们要是从 Member 去理解的话，那么每一次 Team 总是那么几个成员，非常的固定，没有发挥组建临时团队的意义，所以这里有一种设计可以考虑，Member 有”分身”，Agent Team 中的团队成员本质是 Member 的分身，有一些核心的东西不变，但是一些其他的可以变动，每一个 Team 中的相同的 Member，但是不同的”分身”

在 Agent Team 中，Member 的定位设计不是最重要的，重要的是可以为相应的复杂任务拉起正确的团队成员

这样在多智能体的设计中，Member 就在 Team 和 Room 中统一起来了，就可以统一维护和设计啦