Multica 使用指南：Issue、Agent Workflow 与多人协作
2026-05-11T01:00:00+08:00
Multica 是一个多 Agent 协作平台。你把 Claude Code、Codex、OpenCLI 、Hermes 等命令行 Agent 接进去，再用 workspace、issue、automation 和 CLI 管任务。
如果说 Slock 像聊天室，Multica 更像办公室。聊天室适合临时喊人、脑暴和快速纠偏；办公室要有任务、负责人、状态、交接和验收。
当你有多个 Agent、多个项目、多个终端时，Multica 负责把这些工作放进一个能追踪状态、交接和验收的空间里。
本文基于 2026 年 4 月下旬到 5 月上旬社区里的真实使用经验整理。Multica 迭代很快，具体按钮会变，这里只写相对稳定的组织方法。
聊天开始乱时，Multica 才有意义
如果你只是临时问答、临时查资料、临时让一个 Agent 改小东西，Multica 会显得重。直接用 Slock、Claude Code 或 Codex 更快。
Multica 开始有价值，通常是这些情况：
- 一个任务需要方案、执行、review 和验收。
- 多个 Agent 在不同机器或不同模型上工作。
- 任务不是马上做完，而是要留下状态和记录。
- 团队里不止一个人需要看进度。
- 你开始觉得聊天记录太乱，无法追踪谁做了什么。
它要求你把工作拆成任务，把任务写清楚，把权限分清楚。
先写一个能验收的小 issue
不要急着搭复杂系统。先写一个小到能验收的 issue：
第一条 issue 不要写“帮我重构整个系统”。更适合写：
阅读这个仓库的 README 和 package.json，总结启动方式，并生成一个本地运行检查清单。
这个任务能测三件事：Agent 能不能读项目，是否会更新 issue，知不知道什么时候该停。它也能测试 review 是否有用，而不是只看 Agent 自己说“完成了”。
如果这种小 issue 都留不下清楚状态，先别急着上 automation、workflow、手机控制和多机调度。
Issue 是协作协议
Multica 里最重要的是 issue。
很多失败不是 Agent 不聪明，而是任务没有被组织成可执行对象。你把聊天里的随口需求直接丢给 Agent，再要求它稳定交付，本来就容易跑偏。
一个好 issue 至少写清楚五件事：
- 背景：为什么做这个任务，相关项目或文件在哪里。
- 目标：完成后应该看到什么，不要只写“优化一下”。
- 边界：哪些文件不能动，哪些行为不能做，是否允许安装依赖。
- 交付物：要代码、报告、截图、HTML 页面，还是一组新 issue。
- 验收方式：跑什么命令、看什么页面、由谁 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 可以长这样：
- 方案 Agent 读取需求，生成拆解版 issue。
- 人确认 issue 范围。
- 执行 Agent A 修改代码。
- 执行 Agent B 写测试或检查边界。
- Review Agent 输出验收报告。
- 人决定合并、退回或继续拆小任务。
这看起来像传统软件流程，区别是每一步的执行者都可以是 Agent，而且 issue、状态、报告都留在 workspace 里。
交接不要只靠聊天
多 Agent 协作很容易掉进一个坑：让 Agent 之间一直聊天。
聊天对人类友好，因为我们能看懂过程。但对 Agent 来说，聊天不一定是最高效的 handoff。更稳的交接方式是结构化文档、issue、状态更新、验收报告，或者明确的 handoff 机制。
可以记一条简单规则：
讨论可以在聊天里，承诺必须进 issue。
如果 Agent 只是脑暴，说什么都行。一旦决定执行，就写清楚目标、边界、交付物和验收方式。后续 Agent 只认 issue，不认聊天里随口说过的话。
团队用起来，问题会变成治理
Multica 对个人 power user 已经有吸引力，但团队落地会遇到治理问题。
第一是 onboarding。新人进来，如果还要从 workspace、Agent、runtime、issue、automation 一路理解，会先被概念劝退。团队场景需要的是“进来就到团队空间”，而不是每个人从零理解产品哲学。
第二是 issue 触达。Agent 产出的 issue 怎么通知对应成员，是一个真实痛点。只堆在看板里不够，因为人类不会像 Agent 一样持续扫描状态。
第三是权限粒度。有人把 Agent 连了数据库，不希望所有成员都能用；有人设置 private Agent 后，又发现 A2A 协作受影响。多 Agent 越像真实公司，权限边界就越像门禁和审批。
第四是上下文范围。Agent 理论上能读 workspace 里的 issue，但不可能每次读全部。新 issue 里哪些背景要重复写，哪些让 Agent 自己找，这是使用者必须学习的能力。
所以现阶段，Multica 更适合小团队、强用户、工程化意识强的人。大组织要跑起来，还需要 enterprise 级权限、审计、onboarding 和流程治理。
token 消耗也是组织问题
Multica 不会自动省 token。它把工作组织起来，也会让你更容易派出更多 Agent，跑更多任务。
省 token 的关键不是少用 Multica，而是少制造无效协作：
- 不要让五个 Agent 同时读同一堆背景。
- 不要把一个大任务丢进去让它无限探索。
- 不要让高价模型跑重复性执行。
- 不要把聊天记录当长期上下文塞给每个 Agent。
- 不要让 Agent 在没有验收标准的任务里“继续优化”。
比较好的分工是：强模型做规划、拆解、审查；便宜模型做批量执行；人只在任务边界、风险点和最终决策处介入。
跑偏时先看 issue
Agent 只给浅方案。 先检查 issue 是不是太粗，或者 instructions 里塞了太多人设和无关约束。
任务越跑越偏。 把 issue 拆小。长程任务注意力漂移很难完全防住，原子化 issue 更稳。
Agent 自己创建了不该创建的东西。 明确“先方案、后执行”。如果只想让它规划，就写“不允许修改文件、不允许创建 issue、不允许启动自动化，只输出方案和风险”。
权限不敢放给团队。 先用 private Agent 和最小权限目录。数据库、支付、浏览器、远程桌面、本机文件系统，不要开放给所有人。
runtime 报错。 把日志和复现路径提到 GitHub issue，比在群里问更有效。很多问题没有日志很难判断。
它不适合所有人
Multica 适合三类人：
- 同时用多个 Agent 的开发者。
- 有明确任务流的小团队。
- 多机、多地区、多模型用户。
不适合的人也很明确：只有一个 Agent、只做临时问答、不想写 issue、不想管权限的人，会觉得它重。
等你从“我有一个 AI 助手”走到“我有一支 AI 小队”，问题就不再是怎么 prompt 它，而是怎么管理它。Multica 适合解决这个阶段的问题。