多智能体的协作方式-Agent Team和Agent Room
最近在实践多智能体的设计方式,也准备考虑给ActSpace添加多智能体的功能,主要是多智能体如果设计得当的话,是可以在提高效果的同时节省成本的,这对于很多做应用的团队来说,成本的控制是可以带来极好的用户体验的,我觉得这也是Harness Enginneering的概念之一
一、Agent Team的设计思路
Agent Team是多智能体的协作方式之一,类似于一个组“临时团队”一起攻坚一个复杂的任务,里面会有负责人的角色(Lead)、同时也会存在团队的成员(Teammate),交流关系不仅仅是负责人和成员之间的交流,成员和成员之间同样可以交流
Agent-Team
一个Agent Team最核心的四个组件:团队负责人、任务清单、团队成员、消息收件箱
核心的运行步骤如下:
- Team Lead根据任务的复杂性生成任务清单,同时开始创建团队的基本信息
- Lead可以直接分配任务给团队成员做,同时在空闲的时候团队成员也可以主动领取任务
- Lead和Teammate的交流,不是直接交流的,是通过indox(消息收件箱)发送消息,类似于人类协作中的发送邮件的操作
Team Lead创建任务和团队基本信息的时候,是依靠两个工具:taskCreate和TeamCreate,这两个工具会创建两个关键的文件夹的,我们假设团队名叫做jink-team,那么创建的文件夹结构如下:
~/.claude/teams/jink-team/~/.claude/tasks/jink-team/🌵 那么任务清单创建好之后,如何分配任务呢?
Agent Team是通过Lead分配和团队成员主动领取这两个方式,Lead分配任务使用的是TaskUpdate方法,团队成员主动领取任务使用的是TaskList先获取任务的状态,然后根据状态来领取任务,这是程序中循环调度器实现的,每500ms循环执行一次。
最核心的地方来啦,团队的协作交流,Agent Team中的交流信号分为两种:信息和指令,是通过消息收件箱传递的
- 信息就是一些内容,一些任务的描述和输入,就和正常的用户输入是一样的
- 指令是一些硬信号,例如:权限的审核通知,团队成员会将执行权限审批先发送给负责人的收件箱,负责人在读取之后,将该指令传递给前端用户,用户审核之后,状态在一步一步回流,还有团队成员的进程关闭等
消息收件箱也很简单有效,就是一个json文件,里面的消息会有一个是否读取的状态,每一个Agent执行的之后,都会有循环调度去反复去读取这个文件,如果有新消息,会在Agent的下一轮将消息注入到上下文中执行
所以我们可以发现,Agent Team的消息传递只是通过简单的文件+调度器的方式,非常有效,不过在实现这种传递方式时,最关键的是要注意文件锁的设计
例如:任务清单很可能会出现两个Agent同时读取同一个任务,这个时候状态会变得不稳定,所以我们要设置文件锁,同一个时刻,只有由一个Agent读取并且执行修改。
当某一个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 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-Room-2
我这里还有一种思路,大家可以参考借鉴的,没有收件箱和草稿板,聊天室的消息直接被推入到Agent的上下文中,但是多了一个概念:叫做思维精灵(子Agent)
Agent-Room-3
设想是这样的:Agent不进行任务的执行,只负责分发任务给思维精灵执行,最终等待子智能体结果进行综合分析回复,在回复之前,会调用工具“抢占发言令牌”,相当于班级中的“举手发言”啦,举手成功之后,就可以将最新的消息一并同工具返回之后,那么聊天室这段时间都属于该Agent,那么其就进行最终的回复
🎃当然这个只是一种猜想,我还没有具体实践过,感兴趣的朋友可以自行尝试梳理!!!
三、Agent Task的设计思路
Task是Agent执行的最小单元吧,所以这里我也想要一起简单的梳理一下,一个Task只能被一个Agent执行,但是一个Agent可以同时执行多个Task
产生Task的方式我们也可以结合上面两种设计来看
- Agent Team产生的Task,更多像是一个复杂任务被拆分为一个一个的小任务,可以定义为一个临时任务
- Agent Room产生的Task,偏向于用户手动指定某一个成员执行一个任务,例如:执行bug修复任务或者执行某一个领域的检索任务,可以定义为一个完整的任务
- 用户或者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中统一起来了,就可以统一维护和设计啦
学AI大模型的正确顺序,千万不要搞错了
🤔2026年AI风口已来!各行各业的AI渗透肉眼可见,超多公司要么转型做AI相关产品,要么高薪挖AI技术人才,机遇直接摆在眼前!
有往AI方向发展,或者本身有后端编程基础的朋友,直接冲AI大模型应用开发转岗超合适!
就算暂时不打算转岗,了解大模型、RAG、Prompt、Agent这些热门概念,能上手做简单项目,也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料,手把手帮你快速入门!👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型(GPT、文心一言等)特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架(LangChain等)实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块,看似清晰好上手,实则每个部分都有扎实的核心内容需要吃透!
我把大模型的学习全流程已经整理📚好了!抓住AI时代风口,轻松解锁职业新可能,希望大家都能把握机遇,实现薪资/职业跃迁~
