Agent 怎么组队:Squad 让你 @ 一个团队而不是某个人
本文是 Multica 拆解系列的第 5 篇。前四篇让 Agent 有了工位、大脑、生命周期、技能。这一篇讲团队长大后的新问题:人/Agent 多了,怎么分工。
这一篇要解决的问题
团队小的时候,派活很简单:你知道这条 issue 该 @alice 还是 @bob。但 Agent 一多,问题就变了——你有 3 个前端 Agent、2 个后端 Agent、1 个擅长测试的 Agent,一条新 issue 进来,你其实不想去记"谁擅长什么",你只想说"@前端组,这个你们处理"。
更深的问题是:路由要稳定。今天派给 alice,明天派给 bob,分配人在变,但你要能稳定地指向"前端组"这个概念。队伍扩招了(前端组从 2 人变 3 人),你的派单方式不应该跟着变。
我通读了 server/internal/handler/squad.go 和 squad_briefing.go,Multica 的答案是 Squad(小队)——一个"路由层"抽象。
心智模型:小队是路由目标,不是执行单元
先纠正一个直觉误区:Squad 不增加任何能力。它增加的是路由。
一个 squad 是一组智能体和人类成员的命名集合,其中有一名队长(leader),必须是智能体。小队本身是一等可分配对象——你在任何 assignee 选择器里能选人,就能选小队。但选了小队不等于"小队一起干",触发会落到队长身上:队长读 issue、判断谁最合适,然后用 @mention 把活派给那个成员。
成员还是那些智能体,队长唯一的工作是挑对人。这是"@FrontendTeam 而不是 @alice-or-bob-or-carol"这个体验的实现方式——你不是在派给一群人,你是在派给一个"路由决策者",它帮你决定具体落到谁头上。
深度点一(免费):队长怎么决策
我在 squad_briefing.go 找到队长决策的完整机制。Multica 给每个队长 claim 任务时,硬编码注入一段操作协议(Squad Operating Protocol):
// server/internal/handler/squad_briefing.go
const squadOperatingProtocol = `## Squad Operating Protocol
You are the LEADER of a squad. Your job is to **coordinate**, not to
execute the work yourself.
Your responsibilities, in order:
1. Read the issue ... and decide which squad member is best suited.
2. Delegate by @mention. Post a single comment that @mentions the
chosen member(s) and tells them what to do.
- Be terse. Every Multica agent already has full context of the issue.
- Say only what cannot be inferred: who, why them (one clause),
and any additional constraints.
`
这段协议有几个设计上的讲究,我逐条拆:
第一,它明确禁止队长自己干活("coordinate, not execute")。一个被设为队长的智能体,它的全部职责就是读 issue + 派活,不写一行代码。这避免了"队长自己把活干了,小队形同虚设"。
第二,它要求队长极其简短。注释里反复强调:每个 Multica agent 本来就有 issue 的完整上下文(标题、描述、所有评论、附件),队长不要复述、不要总结。只说三件事:派给谁、为什么是 ta、额外的约束。两三句话够了。
反直觉:把决策权交给一个 LLM 当队长,最大的风险不是它选错人,而是它废话太多——复述 issue、解释背景、啰嗦一堆。这段协议的核心作用其实是约束队长的输出长度,而不是教它怎么决策。这反映了一个工程现实:用 LLM 做协调,要花大力气压它的 token,而不是提升它的智力。
深度点二:@mention 才是真正的派发动作
队长的派活不是改 assignee 字段,而是发一条带 @mention 的评论。这跟第 2 篇讲的多态指派一脉相承——在 Multica 里,@mention 是一个一等触发器(和"分配 issue""聊天""autopilot"并列的四种触发方式之一)。
协议里特意警告:"typing a plain @name will not trigger anyone"——必须用和 util.MentionRe 对齐的精确 markdown 格式,普通的 @name 文本不触发任何东西。我看了 squad_briefing.go 注释,它要求协议文本里的"@mention 示例"必须能 round-trip 通过 util.ParseMentions,也就是给队长看的例子本身就格式正确、可解析。
这带来一个全栈闭环:你分配给 @FrontendTeam → Go 服务器触发队长 claim → 队长被注入操作协议 + 读 issue → 队长发一条 @memberX 的评论 → 评论触发 memberX 的任务 → memberX 开始干。整条链路里,队长自己只是个中转节点,真正干活的还是成员。小队没有引入新的执行能力,只引入了一层路由。
小队派活的完整流程:
深度点三:小队归档,issue 自动转给队长
我注意到一个体现"路由稳定性"的设计:小队是软删除(归档),不是硬删除。
归档一个小队后,它从 picker 和列表里消失,但当前分配给它的 issue 不会被悬空——会被自动转给队长智能体。这保证工作不卡住:路由层撤了,原本挂在它身上的任务不会掉地上,落到那个曾经做路由决策的队长手里继续推进。
// server/internal/handler/squad.go
// ArchivedAt / ArchivedBy —— 归档是软删除
// leader_id —— 归档时未完成的 issue 转给这个 leader
为什么要转给队长而不是随便一个成员?因为队长是那个"了解上下文"的角色——它读过这些 issue、做过路由决策,是最知道每条 issue 该怎么继续的人(智能体)。转给一个不知情的成员,反而要重新建立上下文。
这个设计呼应了这一篇的核心:小队是路由,队长是路由的决策者。路由层存在时,队长负责分流;路由层撤掉时,队长负责兜底。两种状态下,队长都是那个"最了解情况"的节点。
这就是 Multica 对"团队分工"的答案。一个 2 人团队管 10 个 Agent,真正难的不是让 Agent 干活(前三篇解决了),而是在 Agent 多了之后还能按主题稳定派活。Squad 把"派给某个人"升级成"派给一个路由目标",让团队扩展时派单方式不跟着膨胀。
下一篇:同事能接 standing order 吗?Multica 的 Autopilot 怎么让 Agent 在固定时间自己开工,不用你每次喊。
想看 AI 拆完下一篇?留个邮箱,自动推送。
