Multica 使用指南：Issue、Agent Workflow 与多人协作

Multica 是一个多 Agent 协作平台。你把 Claude Code、Codex、OpenCLI 、Hermes 等命令行 Agent 接进去，再用 workspace、issue、automation 和 CLI 管任务。

如果说 Slock 像聊天室，Multica 更像办公室。聊天室适合临时喊人、脑暴和快速纠偏；办公室要有任务、负责人、状态、交接和验收。

当你有多个 Agent、多个项目、多个终端时，Multica 负责把这些工作放进一个能追踪状态、交接和验收的空间里。

本文基于 2026 年 4 月下旬到 5 月上旬社区里的真实使用经验整理，并结合 2026 年 9 月的实际 Squad 使用继续校正。Multica 迭代很快，具体按钮会变，这里只写相对稳定的组织方法。

先说结论：什么时候该用 Multica

Multica 不是“比 Codex 更强的 Agent”，而是给多个 Agent 加任务、状态、交接和 Review 的协作层。如果一个任务让单个 Codex / Claude Code 十分钟就能做完，直接用单 Agent 往往更轻；如果任务会持续较久、跨多个角色或机器，而且你已经开始靠聊天记录记“谁做到哪一步”，Multica 才开始有价值。

最稳的起点不是先搭复杂 Squad，而是先验证一个小 Issue：写清背景、目标、边界、交付物和验收方式，让一个 Agent 执行，再由另一个角色或人 Review。只有这条链稳定后，再增加多机调度和自动化。

还要区分两个概念：Multica Squad 是动态协调，不等于严格 Workflow Engine。 如果你关心的是 Leader handoff 会不会自动接棒、复杂任务能不能自己一路跑到底，可以直接看后面的机制说明和我的真实 Squad 工作流复盘 。

Multica 是什么：聊天开始乱时，它才有意义

如果你只是临时问答、临时查资料、临时让一个 Agent 改小东西，Multica 会显得重。直接用 Slock、Claude Code 或 Codex 更快。

Multica 开始有价值，通常是这些情况：

• 一个任务需要方案、执行、review 和验收。
• 多个 Agent 在不同机器或不同模型上工作。
• 任务不是马上做完，而是要留下状态和记录。
• 团队里不止一个人需要看进度。
• 你开始觉得聊天记录太乱，无法追踪谁做了什么。

它要求你把工作拆成任务，把任务写清楚，把权限分清楚。

Multica 怎么用：先从一个能验收的小 Issue 开始

如果只看最短路径，就是：需求 → Issue → Agent 执行 → Review。先跑通一个小任务，再考虑 Squad、Workflow 和多机调度。

不要急着搭复杂系统。先写一个小到能验收的 issue：

第一条 issue 不要写“帮我重构整个系统”。更适合写：

阅读这个仓库的 README 和 package.json，总结启动方式，并生成一个本地运行检查清单。

这个任务能测三件事：Agent 能不能读项目，是否会更新 issue，知不知道什么时候该停。它也能测试 review 是否有用，而不是只看 Agent 自己说“完成了”。

如果这种小 issue 都留不下清楚状态，先别急着上 automation、workflow、手机控制和多机调度。

Issue 是协作协议

Multica 里最重要的是 issue。

很多失败不是 Agent 不聪明，而是任务没有被组织成可执行对象。你把聊天里的随口需求直接丢给 Agent，再要求它稳定交付，本来就容易跑偏。

一个好 issue 至少写清楚五件事：

1. 背景：为什么做这个任务，相关项目或文件在哪里。
2. 目标：完成后应该看到什么，不要只写“优化一下”。
3. 边界：哪些文件不能动，哪些行为不能做，是否允许安装依赖。
4. 交付物：要代码、报告、截图、HTML 页面，还是一组新 issue。
5. 验收方式：跑什么命令、看什么页面、由谁 review。

如果你不会写 issue，可以让一个专门的 Agent 把自然语言需求改写成 Multica issue。但不要完全放手。你至少要审边界和验收方式。

Agent 最容易把“探索一下”理解成“顺手改了”，也容易把“做个方案”变成“直接开干”。在多 Agent 系统里，这种误解会被后续任务放大。

角色不是岗位，是任务流

不要一开始就按岗位固定 Agent，比如前端、后端、测试。Agent 的能力由 runtime、模型、上下文和工具权限共同决定，今天适合写前端，明天可能适合做数据分析。

更稳的是按任务流分角色：

• 方案 Agent：把模糊需求变成计划、issue 和验收标准。
• 执行 Agent：按 issue 改代码、写报告、处理文件。
• Review Agent：看 diff、跑测试、读交付报告。不要和执行 Agent 是同一个。
• 管家 Agent：根据任务类型选择合适 Agent，自己不一定亲自执行。

这个分工的重点不是“让更多 Agent 说话”，而是把规划、执行和验收拆开。

多 Agent 的目标也不是取消人。社区里已经有人把“外部 Agent 交叉 review + 最后 human decision”当成合并前流程。最后那一下判断，仍然应该由人做。

多机调度像一个控制平面

Multica 很适合统一调度不同机器上的 Agent。

有人把国内机器、海外 Mac、本地终端都注册进来：国内用 Codex，海外用 Claude；以前要来回切终端，现在可以在一个 workspace 里派 issue、看状态、拿结果。

这个场景里，Multica 更像 Agent 控制平面。底层执行仍然发生在各自机器上，但入口和状态集中起来。

适合这几类人：

• 有多台机器：本机、公司电脑、海外 VPS、Mac mini。
• 有多套模型资源：Claude、Codex、国产模型、中转或自部署 runtime。
• 有多个项目并行：代码、内容、数据分析、信息监测。
• 想用手机发起任务，但不想在手机上处理终端。

多机调度的风险是权限。哪个 Agent 能碰哪台机器、哪个目录、哪个账号，一开始就要想清楚。不要把所有 Agent 都接成全能账号。

Workflow 用来减少漂移

很多人第一次看到 workflow，会以为它只是为了自动化更多步骤。更关键的作用是减少漂移和控制成本。

长程任务里，模型会忘记目标、扩大范围、重复劳动，或者在该等人确认的时候直接跳过去。强模型能缓解，但不能完全解决。

一个比较实用的 flow 可以长这样：

1. 方案 Agent 读取需求，生成拆解版 issue。
2. 人确认 issue 范围。
3. 执行 Agent A 修改代码。
4. 执行 Agent B 写测试或检查边界。
5. Review Agent 输出验收报告。
6. 人决定合并、退回或继续拆小任务。

这看起来像传统软件流程，区别是每一步的执行者都可以是 Agent，而且 issue、状态、报告都留在 workspace 里。

这里描述的是我希望任务遵循的协作顺序。

Multica 能自动编排多个 Agent 直到交付吗？

可以组织动态协作，但目前不能把它理解成一个保证自动跑到底的严格 Workflow Engine。Squad 更接近 Leader 在被唤醒后根据上下文决定下一位 Agent。在早期的实际测试中，我确实遇到过 Worker 已经完成任务后 Leader 没有自然接上、需要人工介入推进的情况。当前官方 Squad 文档已经明确规定：成员不带显式 @ 的进展回复会自动重新唤醒 Leader；Multica 在 2026 年 7 月的 v0.3.35–v0.3.39 中也连续修复过多个与 Squad Leader 唤醒和多阶段推进相关的问题。不过由于当时测试环境没有锁定精确版本，也没有完成根因排查，我不能把自己的现象归因于其中某一个具体 Bug 或声称某一个版本专门修复了它。即便机制上支持自动唤醒，它依然不是写死状态转移的固定流水线，Leader 依然是根据上下文动态判断下一步，由人类做最终确认也依然是最稳妥的方式。

如果你关心的正是“给一个目标后，Multica 能不能自己调度多个 Agent 一路做到最终交付”，可以继续看 《Multica 到底是减负还是增负：一次真实 Squad 工作流后的复盘》 。

Multica Agent 怎么交接：不要只靠聊天

多 Agent 协作很容易掉进一个坑：让 Agent 之间一直聊天。

聊天对人类友好，因为我们能看懂过程。但对 Agent 来说，聊天不一定是最高效的 handoff。更稳的交接方式是结构化文档、issue、状态更新、验收报告，或者明确的 handoff 机制。

可以记一条简单规则：

讨论可以在聊天里，承诺必须进 issue。

如果 Agent 只是脑暴，说什么都行。一旦决定执行，就写清楚目标、边界、交付物和验收方式。后续 Agent 只认 issue，不认聊天里随口说过的话。

不过，结构化 handoff 负责保证信息完整，并不等同于流程完全脱离人工。尽管当前官方机制已支持成员回复后重新唤醒 Leader，且 7 月版本迭代中也持续修复过多阶段推进问题，但复杂任务中的阶段推进和最终确认仍需人工判断，具体过程见 Multica Squad 工作流复盘 。

团队用起来，问题会变成治理

Multica 对个人 power user 已经有吸引力，但团队落地会遇到治理问题。

第一是 onboarding。新人进来，如果还要从 workspace、Agent、runtime、issue、automation 一路理解，会先被概念劝退。团队场景需要的是“进来就到团队空间”，而不是每个人从零理解产品哲学。

第二是通知与订阅治理。早期 Agent 产出 issue 后怎么通知对应成员曾是痛点，目前 Multica 已经有了完整的 Inbox 与订阅机制（Issue 分配、新评论、状态变更、@mention、失败告警等都会触发通知并支持自动订阅）。因此当前的治理问题不再是“人收不到 issue 只能刷看板”，而是变成了“谁应该被 assign / mention / subscribe，以及如何避免高频交互带来的通知噪音”。

第三是权限粒度。有人把 Agent 连了数据库，不希望所有成员都能用；有人设置 private Agent 后，又发现 A2A 协作受影响。多 Agent 越像真实公司，权限边界就越像门禁和审批。

第四是上下文范围。Agent 理论上能读 workspace 里的 issue，但不可能每次读全部。新 issue 里哪些背景要重复写，哪些让 Agent 自己找，这是使用者必须学习的能力。

所以现阶段，Multica 更适合小团队、强用户、工程化意识强的人。大组织要跑起来，还需要 enterprise 级权限、审计、onboarding 和流程治理。

token 消耗也是组织问题

Multica 不会自动省 token。它把工作组织起来，也会让你更容易派出更多 Agent，跑更多任务。

省 token 的关键不是少用 Multica，而是少制造无效协作：

• 不要让五个 Agent 同时读同一堆背景。
• 不要把一个大任务丢进去让它无限探索。
• 不要让高价模型跑重复性执行。
• 不要把聊天记录当长期上下文塞给每个 Agent。
• 不要让 Agent 在没有验收标准的任务里“继续优化”。

比较好的分工是：强模型做规划、拆解、审查；便宜模型做批量执行；人只在任务边界、风险点和最终决策处介入。

Multica 最佳实践：跑偏时先检查 Issue

Agent 只给浅方案。 先检查 issue 是不是太粗，或者 instructions 里塞了太多人设和无关约束。

任务越跑越偏。 把 issue 拆小。长程任务注意力漂移很难完全防住，原子化 issue 更稳。

Agent 自己创建了不该创建的东西。 明确“先方案、后执行”。如果只想让它规划，就写“不允许修改文件、不允许创建 issue、不允许启动自动化，只输出方案和风险”。

权限不敢放给团队。 先用 private Agent 和最小权限目录。数据库、支付、浏览器、远程桌面、本机文件系统，不要开放给所有人。

runtime 报错。 把日志和复现路径提到 GitHub issue，比在群里问更有效。很多问题没有日志很难判断。

它不适合所有人

Multica 适合三类人：

• 同时用多个 Agent 的开发者。
• 有明确任务流的小团队。
• 多机、多地区、多模型用户。

不适合的人也很明确：只有一个 Agent、只做临时问答、不想写 issue、不想管权限的人，会觉得它重。

等你从“我有一个 AI 助手”走到“我有一支 AI 小队”，问题就不再是怎么 prompt 它，而是怎么管理它。Multica 适合解决这个阶段的问题。

继续阅读

如果你已经跑通基础的 Issue / Agent 协作，下一步可以看 《Multica 到底是减负还是增负：一次真实 Squad 工作流后的复盘》 。那篇专门讨论 Leader handoff、Review、严格 Workflow 的边界，以及 Squad 在真实任务里什么时候会减负、什么时候反而增加管理成本。