Multica 最佳实践：多 Agent 派活技巧与常见坑

已经装好 Multica 的读者，真正的问题从来不是它能做什么，而是怎么把活派得又稳又省。这篇不重复基础介绍，只讲实战：派活的写法、拆任务的分寸、并发与队列的真实上限、Squad 和 Skill 的正确用法，以及官方 Troubleshooting 文档里那些被误判成「卡住」的报错。

先对齐：派活模式的四个默认规则

Multica 的看板和 Jira 长得像，规则却完全不同，派活前先记住这四条（核对自官方 GitHub README 与文档，2026 年 9 月）：

1. 智能体被指派 issue 后会自己认领、在你控制的 runtime 上执行、边干边发评论。
2. 每次工具调用、命令和报错都有时间戳记录，随时回放。
3. 产出进入 review 状态而不是直接进主线，合入由人决定。
4. 每次执行记录 token 消耗，按智能体和按 issue 都能查。

理解这四条，后面的技巧都顺理成章。官方对这套模式的定位是：它不提供模型，而是驱动你本机已经安装并登录的 agent CLI，所以换供应商是一个下拉框，不是一次迁移。

派活第一步：把 issue 写成智能体能接的活

智能体接不住的活，多数败在 issue 写得太像给人看的标题党。可执行的 issue 至少包含三样：目标（做成什么样）、范围（动哪些仓库和目录）、验收标准（怎么算完成）。

两个立刻能用的做法：

1. 用 Projects 把相关仓库和文档挂到项目上，智能体开工时自带上下文，不用每次现场解释。
2. 在仓库里放好 AGENTS.md，把构建命令、目录约定、测试要求写清楚，让 26 种 CLI 按同一套规矩干活。写法参考站内的 AGENTS.md 完全指南。

反例是「优化一下登录模块」这种派法：没有验收标准，智能体只能猜，产出必然返工。

任务拆分：Chat、单智能体还是 Squad

三种入口对应三种粒度，别混着用：

1. Chat：不想建 issue 的小活，直接在对话里起任务，适合问答和一次性脚本。
2. 单智能体指派：有一个明确交付物的任务，建 issue 指派给某个 agent。
3. Squads：一组人和智能体编成一个队，由 leader 路由工作，适合多条任务并行的项目。

拆任务的三条原则：一次只给一个可验证的交付物；依赖关系写进 issue 而不是靠智能体自己发现；大重构拆成多个可独立合入的小 issue，每个都走完整审查流程。一次派十个模糊大任务，不如派十个清晰小任务。

并发与队列：先知道上限，再谈优化

这是最容易把「排队」误判成「卡住」的地方。官方文档给出的默认上限是：

几个连带结论：

1. 想让多个任务真并行，靠加智能体或加机器，而不是把一个 agent 的并发数往上顶。
2. runtime 离线时新任务会继续排队，只有该 runtime 超过心跳宽限期仍未恢复、且 run 本身也等了同样久，run 才会失败。也就是说「机器关了但任务还在队列里」是正常现象，先把机器拉回来即可。
3. 队列不会因为等太久而被判过期，不用担心排队把任务等死。

把重复流程沉淀成 Skill

同一个坑修过一次，就该变成 Skill。Multica 的 Skill 是把解决过的问题沉淀成 playbook，全队每个智能体都能复用，比如「写数据库迁移」「部署到测试环境」「跑 lint 并修复」。

落地节奏建议：头两周先人工派活，把重复出现三次以上的流程记下来，第三周开始逐个转成 Skill。上来就想规划十几个 Skill 往往坚持不下去，从最疼的那一个开始。

用 Autopilots 做定时任务

Autopilots 支持 cron 式定时执行，官方典型场景是每日 standup 汇总、代码审计和例行报告。适合交给它的活有共同特征：输入固定、输出标准化、不需要人中途决策。比如每天早上让智能体扫一遍昨天的报错日志并汇总成 issue，比人肉巡检省心得多。

注意别把需要判断力的活也自动化进去，审计类任务建议 Autopilot 只负责发现和汇总，修复仍然走人工指派。

Review Gate 与 Inbox：别把人工环节关掉

多智能体跑起来后，最大的诱惑是嫌审查烦，想让产出直接合入。别这么做，review 环节是这套体系的安全垫：智能体的 diff 都落在审查区，你决定什么能进主线。

配套的 Inbox 设计也值得用起来：它只在智能体需要人介入时提醒你，而不是每一步都推送。把通知噪音交给 Inbox，把注意力留给 review。

常见坑与排查

遇到解释不了的行为，官方的 Troubleshooting 文档和 Task 回放记录是最快的排查组合。

边界与前提：自建部署前先知道的几件事

1. 自建要 Docker。官方提供 Docker Compose 与 Helm 两套方案，安装脚本会拉 GHCR 镜像，如果选中的 tag 还没发布，需要改用 make selfhost-build 本地构建。
2. 端口和依赖比想象的多。本地默认 API 在 8080、Web 在 3000，另有 daemon 健康检查端口；数据库是 PostgreSQL 17，容器只在创建时读 .env，改完要重建容器。
3. 邮箱验证码在 DEV 模式下不发送。自建时如果没配 SMTP 或 Resend，验证码与邀请链接只写在后端日志里，生产环境不要用这种方式，也不要开固定测试码。
4. 移动端与渠道有差异。iOS 目前只支持自行从源码构建，未上架 App Store；DingTalk、WeCom、Telegram 属于社区维护，稳定性与官方渠道不同。
5. 开源协议不是纯 Apache 2.0。Multica License 保留 Apache 2.0 全文并附加了托管服务、商业嵌入与品牌相关条件，做二次分发前先把 LICENSE 读完。
6. 目录锁在内存里，重启即释放。本地目录互斥不写锁文件，怀疑有残留锁时重启 daemon 即可，不用去找文件删。