Multica 真的比 Claude Code 更高效吗？

公众号名称：阿南的技术手记

作者名称：j5land

发布时间：2026-06-12 15:59

最近多智能体平台非常火热，我们针对目前热度比较高的多智能协同平台multica进行讨论，目前 github 已经斩获37k stars

主要围绕一个相对比较尖锐的问题：Multica 这种多智能体协同平台到底是不是比“我直接在自己电脑上开 Claude Code / Codex”更高效？

当然，答案不能简单写成“是”。对很多研发个人工作流来说，尤其是需求还没想清楚、需要频繁追问、需要不断修改技术方案的任务，直接在本机使用 Claude Code 的 Plan Mode，往往更快。

因为你就在终端前，模型可以连环问，你可以马上回，它可以继续调整方案，直到你点头再进入执行。

Multica 的效率不在这个点上。

它提高的不是“单人单次对话速度”，而是“团队把 agent 放进任务系统之后的协作效率”。它把 issue、评论、状态、agent、runtime、skills、项目资源和自动化触发接在一起，让一次 AI 执行变成可分配、可追踪、可复用、可审计、可再次触发的任务。

先记住这个判断：

Multica 不是替代你本机的 Plan Mode。它更像是把本机 AI 工具接进团队任务流的调度层。

理解这一点，很多质疑就会变得清楚。

unsetunset1. Multica 真的能提高效率吗unsetunset

要分场景看

如果任务是“我正在写代码，脑子里有上下文，想让 Claude Code 帮我边问边改”，直接在本机跑 AI 工具通常更高效。原因很直接：没有 issue 创建成本，没有 daemon 调度成本，没有评论往返成本，也没有任务状态机的额外动作。

这类场景有几个特点：

需求还很模糊，需要大量即时澄清
方案要反复推敲，用户需要逐段确认
代码上下文就在当前编辑器和终端里
任务只有一个人参与，不需要同步给团队
完成后不一定需要留下结构化记录

这种情况下，Multica 反而可能显得“慢”。你需要创建 issue、写描述、分配 agent、等待 daemon 领取任务，agent 还要通过评论把结果写回平台。这个流程对于个人即时探索来说不是最短路径。

但如果任务进入团队协作阶段，情况就变了。

Multica 更适合这些场景：

任务已经可以写成 issue，有明确背景、目标和验收标准。
需要把执行结果留在团队可见的地方，而不是散落在个人终端里。
同一个问题可能要让不同 agent 参与：实现、review、测试、文档、总结。
团队需要知道 agent 在做什么、卡在哪里、是否失败、是否需要重跑。
一类任务会重复出现，值得沉淀成 Skill 或 Autopilot。
任务可以异步推进，不要求人和模型一直同步对话。

所以 Multica 的效率公式不是：

Multica > 本机 Claude Code

更准确是：

个人即时探索：本机 AI 工具通常更快
团队异步执行：Multica 通常更稳
重复性协作任务：Multica 才开始体现复利

这也是为什么 Multica 的产品形态更像 Linear，而不是一个聊天窗口。它的核心对象不是“对话”，而是 issue 和 task。

unsetunset2. 能读取工具的 skills unsetunset

能，但要理解它的读取路径。

Multica 不是简单地“继承你本机所有上下文”。它会在任务启动前，由 daemon 准备一个执行环境，然后把上下文写到对应 AI 工具能识别的位置。

主要有四类上下文。

第一类是工作区上下文。

工作区设置里的 workspace.context 会被注入到每次任务的 runtime brief 里。它适合放团队通用约定，比如代码风格、提交习惯、测试要求、业务边界、常用仓库说明。

第二类是 agent 自身配置。

每个 agent 有自己的 instructions、model、thinking level、custom env、custom args、MCP config 和挂载的 skills。任务被 daemon 认领后，这些字段会随着 task 一起下发。

第三类是 Multica 管理的 workspace skills。

这是最推荐的路径。你可以把 Skill 导入 Multica 工作区，再挂到某个 agent 上。agent 开始执行任务时，daemon 会把这些 Skill 写进 provider 对应的原生目录：

Provider	注入位置
Claude Code	`.claude/skills/{name}/SKILL.md`
Codex	`CODEX_HOME/skills/{name}/`
Copilot	`.github/skills/{name}/SKILL.md`
OpenCode	`.opencode/skills/{name}/SKILL.md`
Pi	`.pi/skills/{name}/SKILL.md`
Cursor	`.cursor/skills/{name}/SKILL.md`
Antigravity	`.agents/skills/{name}/SKILL.md`
Gemini / Hermes 等	`.agent_context/skills/{name}/SKILL.md`fallback

这个路径的好处是稳定。团队导入一次，挂到 agent 上，之后任务执行时都能拿到同一份 Skill。

第四类是本机 local skills。

Multica 支持让 daemon 扫描本机 AI 工具的 skill 目录，例如 Claude Code 的 ～/.claude/skills/、Codex 的 $CODEX_HOME/skills/ 或 ～/.codex/skills/、Cursor 的 ～/.cursor/skills/。但这不是“所有本机 skills 自动永久生效”。更准确的流程是：daemon 根据请求扫描本机，用户选择要导入的 local skill，把它变成 workspace skill，再挂到 agent。

所以使用建议很明确：

如果你希望 Multica agent 稳定读取某个 Skill，不要只依赖个人机器上的隐式配置。把它导入工作区，并显式挂到 agent 上。

文档上下文也是类似逻辑。

如果仓库里本来有 CLAUDE.md、AGENTS.md、GEMINI.md，agent 在 checkout 或进入对应目录后，AI 工具仍然可能按自身规则读取这些文件。Multica 自己也会写入一个 runtime brief。对于 local_directory 模式，它不会粗暴覆盖用户仓库里的文件，而是插入带 marker 的 Multica 管理区块，任务结束后再清理掉，避免污染你的本地目录。

但要注意一点：普通 github_repo 模式下，任务一开始的 workdir 是空的。agent 需要先运行：

multica repo checkout

把项目仓库 checkout 到任务目录里。仓库里的上下文文件只有在 checkout 后才存在。

MCP 也是 per-agent 配置。Multica 会把 agent.mcp_config 传给支持 MCP 的 provider，例如 Claude Code、Codex、Hermes、Kimi、Kiro CLI、OpenCode、OpenClaw。其他 provider 即使收到了字段，也不一定真正消费。

unsetunset3. SDD 流程能不能实现unsetunset

要区分“流程能不能跑”和“体验是否等同于本机 Plan Mode”。

单项目任务通常是这样：

产品需求
  -> OpenSpec / SDD 技术方案
  -> Plan Mode 反复问问题
  -> 确认技术方案
  -> 拆 tasks
  -> 执行
  -> 测试 / review / 收尾

在本机 Claude Code 里，这是一条同步对话链。模型问你问题，你马上回答；模型修改方案，你马上确认；模型拆任务，你再确认。这个体验 Multica 当前不是原生等价支持。

代码里可以看到两个关键事实。

第一，Claude Code 在 daemon 模式下是非交互执行。server/pkg/agent/claude.go 中 daemon 固定使用 -p、stream-json、--permission-mode bypassPermissions，并把 Claude Code 的 AskUserQuestion 工具放进 --disallowedTools。注释写得很直白：daemon 没有 UI 可以展示这个问题，澄清应该通过 issue comment。

第二，用户传入 --permission-mode plan 这类参数会被过滤。--permission-mode 属于 daemon 管理的阻断参数，因为 daemon 需要保证非交互、可调度、可自动完成的执行协议。

这意味着：

Multica 不能原样复刻 Claude Code Plan Mode 的“同步连环提问 + 等用户确认 + 再进入执行”体验。

但 Multica 可以承载异步版本的 SDD 流程。

一种可落地的做法是把 SDD 拆成两个 agent 或两个阶段。

第一阶段是规划 agent。

给它挂一个 OpenSpec / SDD Skill，issue 描述里只放产品需求、背景链接和约束。规划 agent 的任务不是写代码，而是输出：

需求理解。
不确定问题。
技术方案草案。
任务拆分。
风险点。
需要用户确认的决策。

如果信息不足，它不应该继续执行，而是把问题写成 issue comment，并把 issue 状态改成 blocked。

第二阶段是执行 agent。

用户在评论里回答问题，确认方案，再 @ 执行 agent，或者把 issue 重新分配给执行 agent。执行 agent 读取 issue、评论历史、metadata、Skill 和项目资源后开始实现。

这个流程没有本机 Plan Mode 那么快，但它有团队协作价值：

方案和问题沉淀在 issue 评论里。
其他人能看到决策过程。
执行 agent 不需要重新听你口述上下文。
后续 review agent、test agent 可以沿着同一个 issue 继续工作。
反复出现的 SDD 规范可以沉淀成 Skill。

所以单项目结论是：

问题	结论
能不能做 OpenSpec / SDD	能，适合用 Skill + issue comment 承载
能不能同步 Plan Mode 一样连环问	当前不等价
能不能在确认前不写代码	能靠 Skill 和流程约束实现，但不是平台级强制审批门
适合什么任务	需求较清晰、可以异步确认、需要沉淀方案的任务
不适合什么任务	你正在本地快速探索、需要持续口头/终端交互的任务

unsetunset4. 多项目任务在 Multica 实现unsetunset

这里也要拆成三种情况。

第一种是“一个 Multica workspace 里的多 Git 仓库”。

这是 Multica 支持得比较自然的场景。workspace 可以配置仓库，project 可以挂多个 github_repo project resource。任务启动后，runtime brief 会告诉 agent 有哪些 repo 可用，agent 可以按需执行：

multica repo checkout 
multica repo checkout

daemon 会通过本地 bare clone cache 创建 worktree。也就是说，一个任务目录里可以 checkout 多个仓库，agent 可以在同一次执行里跨仓库检索和修改。

这适合：

前端仓库 + 后端仓库联动。
SDK 仓库 + 示例项目联动。
服务仓库 + 文档仓库联动。
多 repo 代码审查和影响面分析。

第二种是“多个本地目录都要原地修改”。

这里当前要谨慎。Multica 的 local_directory resource 是把某个 project 绑定到某台 daemon 上的一个本机目录。任务会直接在这个目录里运行，不 clone、不复制。这个模式适合超大仓库或你想让 agent 就在当前 checkout 里工作。

但它的 v1 限制很明确：同一项目在同一台 daemon 上最多一个 local_directory，同一个目录上的任务串行执行。它不是为“一次任务同时原地接管多个本机目录”设计的。

如果你要多仓并行修改，更推荐用 github_repo project resources，让 agent checkout 多个 worktree。这样更隔离，也更容易回收。

第三种是“跨 Multica workspace 的任务”。

这不是当前推荐模型。Multica 的任务、agent、skill、issue、project、repo 都以 workspace 为隔离边界。daemon 给 agent 注入的是当前 task 的 MULTICA_WORKSPACE_ID 和 task-scoped token，CLI 也刻意避免在 agent 执行上下文里回退到用户全局 workspace 配置，防止跨 workspace 污染。

所以如果你说的“多项目”是多个仓库，但属于同一个团队任务流，应该把它们放在同一个 Multica workspace / project 资源里。

如果你说的“多项目”是多个组织、多个 Multica workspace、多个权限域，Multica 当前不适合让一个 agent 横跨这些边界做统一执行。更合理的做法是拆成多个 workspace 内的 issue，通过人来做跨域协调。

unsetunset5. 先 Plan 再执行unsetunset

支持“异步 Plan 再执行”，不支持“完全等价的本机 Plan Mode”。

可以这样落地：

Issue: 产品需求 / bug / 技术任务
  -> Planner Agent 生成方案和问题
  -> 用户在评论里确认或补充
  -> Executor Agent 执行
  -> Reviewer Agent 做 review
  -> Test Agent 补测试或验证

关键是不要把一个 agent 设计成“既要不断问，又要马上执行”的同步助手。Multica 更适合把阶段拆开，让每个阶段在 issue 上留下产物。

推荐的工作姿势是：

阶段	Multica 里的做法
需求不清	先分配给 Planner Agent，只要求产出问题和方案
需要确认	Planner Agent 发 comment，issue 置为 `blocked`
用户补充	用户回复 comment，或 @ Planner Agent 继续整理
方案确认	用户明确写“按方案 B 执行”
执行	@ Executor Agent 或重新分配 issue
复查	@ Reviewer Agent 或创建子 issue
沉淀	把稳定流程写进 Skill

如果你希望它更像 SDD，可以把 Skill 写得更硬：

当需求存在未确认问题时：
1. 不要改代码。
2. 输出“需要确认的问题”。
3. 给出默认推荐方案和风险。
4. 把 issue 状态改为 blocked。
5. 等用户在评论中明确确认后，再继续。

这能形成团队可见的异步审批流，但它仍然不是平台级的“审批按钮”。Multica 当前没有一个内置状态叫“等待用户确认技术方案后自动恢复同一会话继续执行”。它依赖 issue comment、@mention、rerun、reassign 和 agent 的 workflow 指令来完成。

这个差异很重要。不要把 Multica 当成本机交互式 agent 的 UI 壳。它更像一个异步执行系统。

unsetunset6. Multica 的应用场景是unsetunset

Multica 的优势场景可以概括成一句话：

当任务可以被写成 issue，并且执行过程需要被团队看见、复用或自动触发时，Multica 才有明显价值。

具体可以落在这些场景。

第一，清晰的小型研发任务。

例如修一个明确 bug、补一个测试、改一处接口兼容、更新一段文档、处理一个 lint 问题。这类任务需求明确，agent 不需要连续追问，Multica 的异步执行和结果评论刚好合适。

第二，代码审查和影响面分析。

把 PR、commit、issue 链接放进描述，agent 通过项目资源 checkout 仓库，输出 review comment。它不一定直接改代码，但可以帮人快速找风险。

第三，重复性工程维护。

例如定期检查依赖升级、整理 release notes、扫 TODO、补测试、同步文档。这里 Autopilot 的价值会比单次对话更明显。

第四，多 agent 分工。

一个 agent 负责方案，一个 agent 负责实现，一个 agent 负责 review，一个 agent 负责测试。Multica 的价值是把这些动作接到同一个 issue/comment 流里，而不是让你在多个终端里手动搬上下文。

第五，团队知识沉淀。

当你发现某类任务总要重复告诉 agent：“先读 OpenSpec，再查 A 仓库，再跑某个测试，再按某个格式写评论”，这就应该沉淀成 Skill。Multica 的 workspace skill 机制可以让这套方法被团队复用。

第六，异步协作和可见性。

当任务由别人提出、由 agent 执行、由你 review，或者 agent 执行失败后需要另一个人接手，Multica 的 issue/comment/task 记录比个人终端对话更有价值。

unsetunset7. 真实的使用建议unsetunset

不要一开始就把 Multica 用在最复杂、最模糊、最依赖你即时判断的任务上。

更好的迁移路径是：

第一周，只跑低风险任务。

文档更新。
小 bug 修复。
测试补全。
日志和错误信息改进。
简单 review。

第二周，开始沉淀 Skill。

OpenSpec / SDD 流程 Skill。
代码 review Skill。
单测补全 Skill。
多仓影响面分析 Skill。
团队评论格式 Skill。

第三周，再引入 planner/executor 分工。

Planner Agent 只问问题和出方案。
Executor Agent 只在确认后执行。
Reviewer Agent 只 review 和指出风险。

第四周，挑少量稳定任务接 Autopilot。

每日 backlog 巡检。
每周测试缺口扫描。
发布说明草稿。
webhook 触发的 PR review。

这条路径的核心不是“让 agent 更自由”，而是“让 agent 更可控”。

unsetunset8. 最终判断unsetunset

回到最初的问题：Multica 真的能提高效率吗？

如果你问的是“我一个人坐在电脑前，正在和 Claude Code 反复确认需求，Multica 会不会更快”，答案大概率是否定的。

如果你问的是“团队能不能把 AI 工具变成可分配、可追踪、可复用、可自动化的执行单元”，答案是肯定的。

Multica 当前更像一个 AI-native task management platform，而不是 interactive planning shell。它适合把已经能进入任务系统的工作交给 agent，不适合替代本机高频交互式探索。

用错场景，会觉得它绕

用对场景，它解决的是另一个层面的效率问题：

不是一次对话少几分钟，而是团队以后少搬运上下文、少重复解释流程、少丢失 agent 的执行记录

内容效果不满意？点此反馈