最近在实践多智能体的设计方式，也准备考虑给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时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
 agent和组件)