Appearance
第一次用 Multica，不建议上来就建一堆 agent、同时派很多任务。更稳的方式是先建一个 workspace，接一个本地 daemon，只挂一个你已经熟悉的 AI 编程工具，然后派一个很小、能验证的 issue。Multica 的价值在任务调度，前提是任务本身足够清楚。
Multica 怎么用：第一次试用别急着派一堆任务
第一次打开 Multica，我建议只建一个 workspace。
别急着把 Claude Code、Codex、OpenCode、Cursor Agent 全都接进去。工具一多，页面会显得很厉害，人也容易开始手痒：这个任务给 Claude，那个任务给 Codex，再开一个让 OpenCode 试试。
然后你会得到一堆输出。
是不是有用，另说。
Multica 这种东西，第一次试用最怕的不是跑不起来，是跑起来以后你不知道它到底帮了什么忙。
先理解它的几个东西
Multica 里最容易混的有几个词。
Workspace 是工作空间。你可以把它理解成一个项目或一组项目的协作区。
Agent 是你创建出来的 AI 队友。它有名字，有说明，也可以挂 skills。
Daemon 跑在你自己的机器上。它负责连接 Multica server，也负责启动本机的 AI 编程工具。
Runtime 是 daemon 和 provider 组合出来的可执行环境。比如同一台机器上，Claude Code 可用，Codex 也可用，那就会有不同 runtime。
Issue 是任务入口。你把任务分给某个 agent，Multica 再把它变成 task 派发出去。
听起来多。真用的时候，先记一句就行：网页负责派活，本地 daemon 负责干活。
第一次试用怎么安排
我会这样试。
先准备一个不重要的小仓库。不要拿正在上线的项目练手。哪怕 Multica 本身做了执行环境隔离，你也应该先用一个能随便回滚的项目。
然后只接一个 provider。
如果你平时最熟 Claude Code，就先用 Claude Code。别为了测试平台能力，把一堆自己都不熟的工具接上来。Multica 调度的是工具，工具本身你不会用，问题会混在一起。
任务也要小。
比如让 agent 做一件明确的事：修一个 README 里的命令错误，补一个缺失的配置说明，或者给一个小函数加测试。不要第一次就丢一句“帮我优化这个项目”。
这句话看着省事，后面通常更费事。
任务要怎么写
Multica 的 issue 不是魔法纸条。
你写得含糊，agent 只能猜。它可能会猜对，也可能绕一大圈。平台只能记录它跑到了哪一步，不能保证它理解了你脑子里的真实需求。
一个适合试用的 issue，大概应该有这些东西：
- 要改哪里
- 期望结果是什么
- 完成后怎么验证
- 哪些地方不要碰
这里不是让你写长文。写清楚就行。
比如：
把 README 里的安装命令从 npm 改成 bun。只改安装相关段落，不要改项目介绍。完成后检查 Markdown 链接没有变坏。
这个任务很小，但适合验证 Multica 的链路：issue 能不能派发，daemon 能不能启动 agent，agent 能不能改文件，结果能不能回到任务页面。
第一次不要测并发
Multica 的卖点里肯定会有多 agent、多任务、统一调度。
我不建议第一次就测这个。
并发任务最容易把问题搅在一起。一个任务失败了，你要分辨是 daemon 配置错了、provider 没登录、agent 没理解、仓库 checkout 有问题，还是任务之间改了同一块代码。
第一次只跑单任务。
单任务跑顺了，再试第二个。等你知道每个环节正常，再去看多任务有没有价值。
看结果时别只看“完成”
任务状态变成 completed，不代表它做对了。
这话放在所有 AI 编程工具上都成立，Multica 也一样。
你要看 diff。要看它有没有改错范围。还要看它有没有留下没跑完的说明。最好自己再跑一次最小验证。
如果只是内容文件，可以本地预览。改代码就跑相关测试。改配置就看实际启动。
平台帮你管理过程，不替你承担判断。
第一次试完怎么看值不值
我会看三个结果。
第一个，任务有没有比我直接打开 Claude Code 更省心。
第二个，任务状态、日志、输出有没有让我更容易回看。
第三个，我会不会愿意把下一件同类小任务继续交给它。
如果这三个都没有，Multica 对你来说可能还太重。不是它没用，是你现在的工作方式还不需要这层调度。
一个人写项目，经常是边想边改。Multica 更适合任务已经能写成 issue 的场景。
这也是我觉得第一次试用要小心的地方。它的界面会让人产生一种错觉，好像把任务派出去，工作就进入自动化流水线了。可需求没定住的时候，自动化跑得越快，返工也可能越快。