Multica 中文教程：让 AI 编程 Agent 像队友一样接任务
Multica 是一个把 AI coding agent 放进团队工作流的开源工作区。你创建 issue、指定 Agent，Agent 在受控 runtime 中执行、回报进度和阻塞，最后把改动交给人评审。它解决的是“多个终端各自跑、没人知道做到哪一步”的协作问题。
1. 准备运行环境
先在要执行任务的机器上安装并登录至少一个受支持的 Agent CLI，例如 Claude Code、Codex、Cursor 等。使用测试仓库和非生产凭证，给 runtime 单独的工作目录。
2. 云端、桌面端和自托管
curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash -s -- --with-server && multica setup self-host
上面是官方 README 给出的 self-host 路径，依赖 Docker 和官方镜像或源码构建。桌面端适合少量本机 Agent；团队需要网络、审计和数据控制时再评估自托管。
3. 从 issue 开始
标题：给登录接口补过期 token 测试；验收：新增测试、npm test 通过、不要改生产配置；阻塞：遇到权限或缺失上下文时先留言
好的 issue 要写清范围、验收、不能改的目录和回滚方式。Agent 的“已完成”只代表它回传了结果，合并前仍要看 diff、测试输出和依赖变化。
4. 适用边界
重复的修复、测试补齐和文档任务适合先交给 Agent；生产发布、密钥轮换和数据迁移应保留人工审批。Multica 的 runtime 权限决定了 Agent 能碰到什么，连接 Slack、Lark 或 Telegram 时也要区分通知权限和代码权限。
这里仅补原教程没有展开的事实和边界。安装命令与操作步骤仍以前文为准。
原教程未展开的系统信息
核心功能
Issue 驱动的 Agent 交付
官方定位是给 Agent 分配工作，Agent 自己领取 issue、报告进度、阻塞并交回评审。
架构与数据流
Multica 工作区管理 issue 和状态，runtime 连接到运行机器并驱动已安装的 Agent CLI；Agent 不由 Multica 打包，代码和凭证权限由 runtime 所在机器决定。
官方与对比资料
以下链接用于核对版本、安装方式、功能边界和同类差异。
常见问题
Multica 和普通任务看板有什么区别？
它把 issue、Agent runtime、进度回报和结果回传放在同一条链路中；普通看板通常不会执行代码。
一个 runtime 能跑多个 Agent 吗？
官方支持多种 Agent CLI，但并行数量和资源隔离要按机器、账号和项目设置测试。
自托管一定更安全吗？
自托管增加控制权，也把补丁、密钥、网络和备份责任交给你。上线前要做权限和恢复演练。
怎么衡量是否值得用？
记录从分派到可合并结果的时间、阻塞次数、返工和评审时间，再和原来的终端流程比较。