Multica daemon 是 Multica 能干活的关键。server 负责协调任务，daemon 跑在你的机器上，负责检测本地 AI 编程工具、注册 runtime、接收任务、准备工作目录，再启动 Claude Code、Codex、OpenCode 等 CLI。理解 daemon，才能理解 Multica 的权限边界和部署成本。

Multica daemon 原理：为什么真正干活的是你本机那台机器

Multica daemon 启动后，会先去找你机器上的 AI 编程 CLI。

这一步很关键。

很多人看 Multica 的网页，会觉得 agent 像是跑在云端。你创建一个 agent，分配一个 issue，页面上显示 running，好像服务器正在替你写代码。

实际不是这样。

Multica server 更像调度中心。真正进入代码目录、启动 Claude Code 或 Codex 的，是你本机的 daemon。

daemon 先确认本机能用什么工具

daemon 跑起来以后，会检测本机装了哪些 provider。

Claude Code 能不能跑。Codex 能不能跑。OpenCode、Cursor Agent、Kimi、Kiro 这些有没有可用命令。

检测到之后，它会把这些能力注册成 runtime。

runtime 可以理解成“这台机器上的某个 AI 编程工具”。同一台机器可以有多个 runtime。比如一台电脑既能跑 Claude Code，又能跑 OpenCode，那 Multica 就能把不同任务派给不同 runtime。

这也是 Multica 和普通 Web 工具不一样的地方。

你的 AI 编程账号、CLI 登录状态、项目依赖，很大一部分留在本机。server 不直接拿走这些东西。

daemon 会一直和 server 保持联系

daemon 不是启动一次就结束。

它会定时告诉 server：我还活着，我这边有哪些 runtime 能接任务。它也会不断查有没有新任务。

官方文档里提到过一个节奏：任务轮询很频繁，心跳也会定期发送。你不需要记这些数字，只要知道一件事：server 要靠 daemon 的在线状态判断任务能不能派出去。

如果 daemon 掉线，runtime 会变成不可用。已经跑着的任务也可能被标成失败，后面再看能不能重试。

所以自部署 Multica 时，只部署 server 不够。daemon 的稳定性也要管。

这点容易被低估。

每个任务会有自己的执行环境

Multica 的 Go 代码里有 execenv 这一层。

它会给 task 准备独立目录，里面有 workdir、output、logs 这些位置。agent 不是直接在一个乱糟糟的全局目录里干活。

仓库也不是一开始全塞进去。Multica 会把可用 repo 信息写进上下文，agent 需要时再通过 Multica 提供的 checkout 命令拉下来。

这套设计有点像给每个 AI 工人发一个临时工位。

工位里有任务说明，有可用仓库，也有 Multica 注入的运行规则。agent 看这些文件，知道自己该怎么和平台交互，比如怎么读 issue，怎么回评论，怎么 checkout repo。

权限和成本都落在本机

理解 daemon 以后，你会更容易判断 Multica 的边界。

它不是一个把所有代码上传到云端再运行 AI 的黑盒。至少从设计上看，它把执行放到了你的机器上。

这让它更适合处理本地开发环境里的事。

你的项目依赖、私有工具、已经登录好的 CLI，都在本机。daemon 调这些东西，比远端 server 直接处理要自然。

代价也在本机。

机器要在线。CLI 要能跑。Git 凭证要可用。任务一多，本地资源也会被吃掉。

如果你把 daemon 跑在一台很弱的机器上，再让它同时接很多 AI 编程任务，体验不会凭空变好。

个人用户怎么理解 daemon

如果你只是一个人用 Multica，可以先把 daemon 想成“后台版的自己”。

平时你打开终端，手动进入项目，再启动 Claude Code。

Multica daemon 做的是：在后台等任务，帮你准备目录，再启动对应的 AI 工具。

这个动作听着简单，但它改变了使用习惯。你不再每次都从终端开聊，而是把任务写进平台，让 daemon 去接。

适不适合你，要看你有没有足够多的清楚任务。

没有的话，daemon 再稳定，也只是等着接一些你还没想明白的活。