Multica 到底是减负还是增负：一次真实 Squad 工作流后的复盘
我之前写过一篇 Multica 使用指南 ，主要聚焦在基础概念、Issue 机制以及多 Agent 的基础组织方式上。
但单点功能跑通，和真正把一套完整的多 Agent 流水线放进实际业务场景跑，完全是两回事。
我把手头一个真实的多阶段任务放进 Multica，跑了一轮完整的 Squad 协作。这个任务并不是为了测试 Multica 临时捏造的 Demo，而是一套需要多角色接力的真实多阶段工作流，包含前置分析、任务拆分、多角色处理、关键结果核对以及独立审查。
这次实验最终完成了任务，但中间也让我第一次真正体会到 Multica 的核心矛盾：
它确实能把多个 Agent 组织起来，但“组织 Agent”本身也会变成一项工作。
所以这篇不再重复安装教程，也不打算回答“Multica 好不好用”这种过于笼统的问题。我更想记录：在一次真实 Squad 工作流里，它到底在哪些地方替我减负，哪些地方又把我变成了 Agent 管理者。
先说结论：它改变的不是执行速度，而是工作形态
Multica 当前仍把自己定位成一个 Agent workspace：把 Issue 分配给 AI coding agent，Agent 在你控制的 Runtime 上执行，持续写回进度和结果，再把工作交回 Review。
官方当前的 How Multica works 和 Squads 文档里，这个思路很清楚：
- Issue 保存任务上下文、讨论和负责人；
- Runtime 负责真正执行；
- Squad 由一个 Leader 和若干成员组成；
- Squad 收到任务后，先唤醒 Leader；
- Leader 根据上下文决定把下一步交给谁。
这套结构解决的不是“单个 Agent 能不能写代码”，而是：
- 谁应该做这一步；
- 任务现在进行到哪；
- 谁应该接下一棒；
- 最终由谁 Review；
- 多个 Agent 怎么共享一个可追踪的工作对象。
如果我的工作仍然是“打开 Codex，说一句话，几分钟后看结果”，Multica 很可能显得多余。
但如果任务要跑几十分钟甚至更久，需要多个角色接力，而且我不想一直盯着多个终端，它就开始有意义。
为什么选择多阶段任务测试：从单 Agent 到团队接力
这个任务很适合拿来测试 Squad，因为它天然就不是一个单 Agent 一步能做完的工作。
整套流程大致包含几个明确环节：
- 梳理前置背景与输入；
- 拆解阶段任务；
- 由不同角色分别处理；
- 对关键结果和当前状态进行复核；
- 交给独立角色做最终审查。
它本来就存在“前置分析 → 多角色处理 → 审查验收”这样的清晰分工。
因此我在自部署的 Multica 中配置好代码仓库后，把其中一次真实任务交给 Squad 跑。Squad 里配置了负责协调的 Leader 以及负责不同处理阶段的 Worker Agent 角色，让 Leader 决定工作应该继续交给谁。
我当时想验证的不是“Agent 能不能做这些任务”，因为这些 Agent 单独使用时本来就能完成。
真正想验证的是：
Multica 能不能把这些已经可用的 Agent 组织成一条我不用一直人工盯着的协作链。
第一次明显的摩擦：Worker 做完了，Leader 没有继续接棒
这次实验里最明显的问题发生在 handoff。
其中一次，上游负责编写的 Worker Agent 已经完成自己的任务，也留下了完成评论。按我的预期，此时应该由 Leader 重新接管，根据当前状态判断下一步：
- 是否还需要另一个 Agent；
- 是否进入 Review；
- 是否已经满足任务目标；
- 是否需要把 Issue 推到下一状态。
但实际情况是：Leader 没有自动继续。
任务停在那里，没有明显报错，也不是 Worker 仍在执行。最终我需要自己再发一条评论，把 Leader 唤醒，让流程继续走。
更关键的是，这不是只出现一次的偶发现象。在同一轮完整 Squad 实验里，我又遇到了类似的“Worker 已经做完，但 Leader 没有自然接上”的情况，需要人工介入推进。
按 Multica 当前官方 Squad 文档，成员正常提交进展后，本应重新唤醒 Leader 继续协调。因此我这次遇到的停顿与当前文档描述的预期行为并不完全一致。但因为没有完成严格的根因排查，我不会直接把它定义成某个确定 Bug。
可能影响行为的因素包括：
- Squad instruction 怎么写；
- Leader 如何判断任务阶段；
- comment / mention / completion event 的触发语义；
- 当时使用版本的实现；
- 是否存在具体的 handoff bug。
我能确认的只有我的实际结果：
在这次真实工作流里，我不能把“成员完成”直接等价成“整个 Squad 会自动继续朝最终目标运行”。
这个区别非常重要。
社区公开反馈中的类似诉求（#5464 与 #7185）
后来再看公开 Issue，会发现社区里存在非常接近的反馈。
GitHub Issue #5464 描述的是：Agent 开始一个 sub-issue 后，如果进入审核或 blocked 状态，流程可能停住，没有自动让 Leader、用户或指定 Agent 继续推进。
另一个 Issue #7185
更直接：提交者说自己在真实 Squad 项目里经常需要手动评论一个 continue，才能让 Leader 继续协调后续步骤。这个提案希望增加 Goal Mode，让成员或子 Issue 完成时自动重新唤醒 Leader。这个 Issue 后来被关闭为 not planned，所以它不能被理解成官方确认会按这个方案实现，但它至少说明“人类变成调度器”是一个公开存在过的使用诉求。
这些公开反馈和我的体验相似，但我不会因此反推它们有相同根因。
这让我重新理解了 Squad：它是动态协调，不是确定性工作流
一开始我很容易把 Squad 想成：
Lead
→ Researcher
→ Writer
→ Reviewer
→ Done
但实际使用后，我觉得这样理解并不准确。
当前官方 Squad 文档描述的核心机制是：Leader 读取上下文，再通过评论和 mention 决定下一步交给哪个成员。成员角色说明本质上是提供给 Leader 的上下文，它不是一个强状态机。
这意味着 Squad 更接近：
让一个 AI Leader 动态决定下一步。
而不是：
按照固定 DAG / Pipeline 保证每个节点一定依次执行。
这个区别也能从官方公开 Roadmap / Issue 看出来。
截至 2026 年 9 月 20 日，GitHub Issue #1943 Workflow Orchestration 仍然是 open。这个 Feature Request 希望 Multica 未来增加更严格的 Workflow 编排能力，例如：
- 固定节点；
- 条件分支；
- Review / QA gate；
- retry / fallback；
- 状态机约束；
- 明确的失败和人工接管路径。
另一个公开 Issue #1998
甚至直接以 Developer → Reviewer → Tester 为例，讨论今天虽然可以用 Agent instruction、子 Issue 和评论拼出类似流程，但正确性仍然很大程度依赖 Agent prompt，而不是平台层的声明式约束。
所以我现在会把两种能力明确分开：
| 能力 | 我现在的理解 |
|---|---|
| Squad | 动态协作。Leader 根据上下文决定下一步由谁处理 |
| Strict Workflow | 固定流程。节点、状态、审批、失败分支由引擎强约束 |
Multica 已经有前者，但后者仍然不是一个完整的现成功能。
这也解释了为什么我的预期会和实际体验出现落差：我期待的是“流程自己向终点跑”，而当前 Squad 更像“Leader 在每次被唤醒时决定下一步”。
第二处摩擦：任务完成了，代码改动却缺乏直接审查入口
这轮实验最终是完成了的。
后面我也让 Multica 帮我完成了 commit/push。从“任务有没有交付”这个角度，它确实可以把工作推进到 Git 仓库。
但完成之后，我很快遇到另一个问题：
我在 Multica 里并不能很方便地直接审查这次到底改了哪些文件、每一处 diff 是什么。
我当时甚至专门去确认 Multica 有没有内置 Terminal、Diff Viewer，或者社区是不是也有人提出过类似需求。
这件事让我意识到，多 Agent 平台除了“怎么派活”，还有一个经常被低估的问题：
怎么 Review。
对于研究或内容任务，最终文件可以直接打开阅读。
但对于代码项目，仅仅看到：
- Agent 说“完成了”；
- Issue 进入 Done；
- commit 已经 push；
并不足以形成一个完整的 Review 体验。
我仍然希望快速看到：
- 哪些文件被改动；
- diff 是什么；
- 为什么改；
- 测试跑了什么；
- 有没有超出 Issue 边界。
这不是说 Multica 不能配合 GitHub、Git CLI 或外部 Review 工具完成这些事情，而是在我的这次体验里，任务管理和代码 Review 还不是一个完全连续的界面。
所以以后如果继续把 Multica 用在代码项目，我会把“提供可 Review 的变更入口”直接写进交付要求，而不是只要求 Agent commit/push。
例如：
完成实现
→ 提交 commit / PR
→ 在 Issue 中留下 PR 或 diff 入口
→ Review Agent 检查
→ 人最终确认
为什么社区里会有人觉得像“带五六个实习生”
在之前的社区材料里，我看到过两类完全相反的评价。
一类人很喜欢 Multica，因为它可以把长期任务派出去，异步等待，最后回来 Review。
另一类人觉得，个人使用时还不如直接开 Codex，有人甚至形容成：
“像自己带了五六个实习生，要挨个关注。”
以前读到这句话时，我更多把它当作一个有代表性的社区评价。
自己真正跑完一次 Squad 后，我开始理解这种感受来自哪里。
问题并不一定是 Agent 不够聪明，而是管理层开始出现了：
- 任务拆解；
- 角色定义；
- Squad instruction；
- handoff；
- 状态跟踪；
- 人工唤醒；
- 结果 Review；
- Git 交付；
- 再决定下一步。
单看每一个环节都合理。
但如果任务本身只需要一个强 Agent 十分钟就能做完，那么这套管理结构可能比任务还重。
Multica 的价值因此高度依赖任务类型。
哪些任务类型适合交给 Multica
这次实验后，我会优先把以下任务放进 Multica：
1. 本来就要异步等待的任务
例如长时间研究、批量分析、跨文件修改、长测试流程。
这种任务即使不用 Multica，我也不可能一直盯着终端。
2. 需要明确交接的任务
一个 Agent 做研究，另一个负责实现，再让第三个 Review。
如果整个过程本来就有多个角色，Issue 和状态记录的价值会明显增加。
3. 能写出清楚验收条件的任务
例如：
- 必须生成哪些文件；
- 哪些测试必须通过；
- 哪些目录不能修改；
- 是否必须提交 PR；
- Review 需要检查什么。
验收越明确，异步执行越容易。
4. 同时跑多个项目或多台机器
当多个 Agent 分布在不同 Runtime、不同机器甚至不同模型资源上时，一个统一看板会比我自己记“哪个终端现在在干嘛”更有价值。
哪些任务暂时不建议放进 Squad
1. 很小的修改
如果一个 Codex 会话几分钟就能解决，创建 Issue、分配 Squad、等待 handoff 没有必要。
2. 高度探索性的工作
比如：
- 产品方向还没想清楚；
- UI 要边看边改；
- 架构方案需要频繁讨论；
- 我自己也不知道最终验收标准。
这种任务需要高频的人机互动，IDE / Codex App / Chat 反而更自然。
3. 每一步都需要我立即纠偏的高风险任务
如果我本来就必须一直看着执行过程，那 Multica 的异步优势会变小。
所以我现在不会把 Multica 当成“所有 AI 工作的统一入口”。
更准确的定位是：
把已经足够清楚、适合异步、需要状态和交接的任务放进去。
下一步计划验证的协作链
这次真实流水线实验让我确认了 Multica 值得继续试，但还不足以证明一套稳定的生产工作流已经成立。
下一轮我更想测试的是一个更接近真实开发项目的流程：
Codex
→ 先做方案和任务拆解
AGY / Grok
→ 根据方案实现
Codex
→ 独立 Review
DS / 其他 Agent
→ 按测试 Skill 做验证
目前这个流程仍然是计划，不是已经验证成功的 Multica 最佳实践。
我倾向先控制 Agent 数量，不搭一个十几个角色的“AI 公司”。模型也允许人工切换，重点先验证几个问题：
- 实现完成后，Review 是否能稳定接棒；
- Review 不通过时，能否回到实现 Agent；
- 测试 Skill 能否形成明确 Gate；
- 哪些阶段必须人工确认；
- 整个流程相比我直接开几个 Codex / Grok 会话，到底有没有减少管理时间。
如果这些问题没有稳定答案，那么继续增加 Agent 数量只会把管理复杂度放大。
客观前提：先不急于结论“Multica 一定比单 Agent 高效”
这也是本次复盘最需要明确的一个客观前提。
我现在没有足够数据证明：
- Multica 一定更快；
- Multica 一定更省 Token；
- Squad 一定比手动开多个 Agent 更高效；
- Leader handoff 停住是某个固定版本的确定 Bug；
- 我这次遇到的 Review 摩擦代表所有人的体验。
这次实验只有一个真实项目样本，而且我没有做严格的 A/B：
同一任务
Multica Squad
vs
手动 Codex / Grok 多会话
也没有完整记录两边的：
- 总耗时；
- 人工介入次数；
- Token；
- 返工次数；
- 最终质量。
因此现在能写的不是“Multica 效率提升 XX%”，而是一个更有限的判断：
它把多 Agent 工作从“多个聊天窗口”变成了“一个有任务状态的协作系统”，但与此同时，handoff、Review 和流程设计也会变成新的管理成本。
是否减负，取决于任务本身有没有复杂到值得承担这层管理成本。
版本与环境边界（基于 v0.5.0 节点）
本文涉及的版本敏感判断主要参考 Multica v0.5.0 发布前后的产品状态。由于这次实验没有锁定所有相关组件的精确版本，我不会把观察到的 handoff 停顿归因于某一个固定版本。
这也是为什么本文更多记录工作流层面的机制体验，而不是罗列一份特定版本的临时 Bug 清单。
由于多 Agent 平台与开源社区迭代演进极快，涉及严格 Workflow 编排、Leader 自动唤醒机制以及代码 Review 视图等能力，后续在生产落地时仍需要紧密结合官方文档演进与相关公开 Issue 持续关注。
核心取舍：管理平台不会自动消除管理成本
如果只看功能列表，Multica 很容易让人产生一个想象：
把多个 AI 接进来，定义角色，然后让它们自己把项目完成。
真正使用后，我觉得现实更接近：
把多个 AI 接进来以后，你获得了一个可以持续记录任务、分配工作、异步执行和交接的管理层；但这个管理层并不会自动消除管理工作。
对于小任务，我现在仍然更愿意直接用单个 Agent。
对于真正需要多阶段、长时间、多人 / 多 Agent 接力的任务，Multica 已经表现出了明确价值。
但它到底能不能从“我在管理一群 AI”进一步变成“这群 AI 真正替我管理工作”，我还需要继续跑几轮真实项目才能回答。
至少经过这次实验，我判断 Multica 最值得研究的已经不再是“它能接多少种 Agent”，而是三个更现实的问题：
- 谁来稳定推进下一步；
- 工作结果怎么被高质量 Review；
- 人在什么地方介入，才真的比手动管理多个 Agent 更省心。
这三个问题如果解决得好，多 Agent 才真正开始从“更热闹”变成“更有效率”。
KEEP READING