Multica 使用心得介绍

1. 写在最前面最近在折腾 AI Agent 的时候笔者越来越明显地感觉到一个问题单个 AI 工具再强也很容易卡在「任务管理」这件事上。比如让 AI 写一段代码、查一个资料、整理一篇文章这些都不难。但如果任务稍微变复杂一点就会出现几个很现实的问题任务到底分给谁做做到哪一步了中间讨论、结论、阻塞原因放在哪里换一个 Agent 接手时怎么知道前面发生过什么如果一个任务要拆成多个子任务怎么避免大家互相等、互相打架以前笔者更多是把这些信息放在聊天记录里或者自己在本地记个任务清单。短期看还能凑合时间一长就会变得很乱上下文散在不同窗口里AI 说过什么要翻半天另一个 AI 接手时又要重新解释一遍。Multica 给笔者的第一感觉就是它不只是一个「能启动 AI Agent 的工具」而是把 AI Agent 放进了一个更接近真实研发协作的工作台里有 workspace有 issue有 agent有 comment有 metadata也有本地 runtime。注本文基于笔者本机使用的multica 0.3.10和一次真实 issue 执行过程整理。Multica 还在快速迭代具体命令建议以multica --help为准。2. Multica 是什么2.1 一句话理解Multica 可以简单理解为一个面向 AI Agent 协作的工作空间和任务调度平台。它不是单纯的聊天工具也不是单纯的代码编辑器。更准确地说它像是把这些东西组合到一起用 issue 描述任务用 agent 执行任务用 comment 保留过程和结果用 status 标记任务进度用 metadata 记录少量关键上下文用本地 daemon 负责真正启动和管理 Agent runtime。如果只看界面它有点像一个轻量的任务系统如果从 Agent 执行角度看它更像一个「AI 任务派发中心」。2.2 它解决的核心问题笔者觉得 Multica 主要解决三个问题。第一任务有了稳定入口。以前让 AI 干活经常是一段 prompt 直接丢进对话框。问题是这个 prompt 没有生命周期做完就散了。Multica 里任务会落到 issue 上issue 有标题、描述、状态、评论、附件和元数据后续回看会清楚很多。第二Agent 有了可管理的身份。在 Multica 里Codex、Claude、Hermes、Kiro 这类 Agent 都可以是 workspace 里的成员。每个 Agent 有自己的运行时、模型、技能和状态。这样分工就更自然这个任务给 Codex那篇调研给 Hermes某个 review 交给另一个 Agent。第三协作过程不再只靠聊天记录。Multica 的 issue comment 很重要。Agent 做完以后必须把结果写回 issue而不是只在本地终端输出。这样后面的 Agent 或人类用户看 issue 就能知道结论不需要翻某个 Agent 的运行日志。3. 先从本地环境看起3.1 安装和登录如果是第一次使用大致入口是bash体验AI代码助手代码解读复制代码multica login multica setup cloudlogin负责认证setup cloud会配置 Multica Cloud并启动本地 daemon。Multica 也支持 self-hostbash体验AI代码助手代码解读复制代码multica setup self-host本机当前版本可以这样查看bash体验AI代码助手代码解读复制代码multica version笔者本机输出类似text体验AI代码助手代码解读复制代码multica 0.3.10 (commit: be32e5af, built: 2026-05-27T10:03:51Z) go: go1.26.1, os/arch: darwin/arm643.2 daemon 是什么Multica 的 Agent 是在本地 runtime 里跑的所以会有一个 daemon 常驻进程。可以用下面的命令检查bash体验AI代码助手代码解读复制代码multica daemon status --output json返回内容里能看到几个关键信息statusdaemon 是否正在运行cli_version当前 CLI 版本agents本机支持的 Agent 类型active_task_count当前正在执行的任务数workspaces本地 daemon 已经连接的 workspace。这点和单纯的 Web 任务系统不太一样。Multica 的任务信息在云端真正执行 Agent 的环境在本机。也就是说它既有平台侧的任务管理也保留了本地文件系统、代码仓库、终端命令这些能力。注这也是为什么 Agent 执行任务时能直接读写本机文件比如本文就是输出到本机的/Users/Documents目录下。3.3 常用命令入口Multica 的命令分得比较清楚直接看multica --help就能知道大概结构bash体验AI代码助手代码解读复制代码multica --help常见入口有这些命令用途multica issue管理任务和评论multica agent管理 Agentmultica repo检出代码仓库multica skill管理 Agent 技能multica daemon管理本地 runtime daemonmultica workspace管理工作空间multica autopilot管理定时或触发式自动化笔者实际用下来入门阶段最常用的是issue、agent、repo、daemon这几个。4. 用一次真实任务串起来4.1 Agent 接到 issue 后先做什么Multica 里的任务通常从 issue 开始。比如当前这篇文章本质上也是一个 issuebash体验AI代码助手代码解读复制代码multica issue get issue-id --output json这个命令会拿到完整任务信息包括titledescriptionassigneestatusmetadataworkspaceparent issue。对 Agent 来说第一步不是马上动手而是先读清楚 issue。因为 description 里经常会写任务目标、输出目录、参考资料、协作要求这些关键约束。4.2 评论历史比想象中重要只看 issue 描述是不够的还要读评论bash体验AI代码助手代码解读复制代码multica issue comment list issue-id --output json这一点笔者觉得很像真实研发里的「先读需求讨论」。很多信息不会写在最初的 description 里而是散落在后续评论中比如用户临时补充了新要求前一个 Agent 已经试过某个方案某个命令失败过任务被拆过子 issuereview 提出了修改意见。如果 issue 很长还可以分页读最近活跃的 threadbash体验AI代码助手代码解读复制代码multica issue comment list issue-id --recent 20 --output json这里有个实践建议Agent 不要只相信自己这次看到的 prompt要把 issue 当成事实来源。4.3 status 是任务进度的公共语言Multica issue 有一套状态流转text体验AI代码助手代码解读复制代码backlog, todo, in_progress, in_review, done, blocked, cancelledAgent 开始工作时通常会先把 issue 标成进行中bash体验AI代码助手代码解读复制代码multica issue status issue-id in_progress完成后再进入 reviewbash体验AI代码助手代码解读复制代码multica issue status issue-id in_review如果确实卡住了就标成 blocked并在评论里说明原因bash体验AI代码助手代码解读复制代码multica issue status issue-id blocked这个动作看起来很普通但对多 Agent 协作很重要。因为状态是所有人共享的不然就会变成「我以为你在做你以为我做完了」。4.4 结果必须写回 commentMultica 里一个很重要的约定是Agent 的最终结果要写回 issue comment。比如bash体验AI代码助手代码解读复制代码multica issue comment add issue-id --content-stdin EOF 已完成文章初稿文件路径 /Users/Documents EOF这点刚开始可能会觉得多此一举因为 Agent 在本地终端已经输出过结果了。但站在协作角度看comment 才是用户和下一个 Agent 能稳定看到的地方。注终端日志是这次运行的副产物issue comment 才是任务交付物的一部分。5. issue metadata少量但关键5.1 metadata 不是备忘录Multica 的 issue 还有 metadatabash体验AI代码助手代码解读复制代码multica issue metadata list issue-id --output json它是一个很小的 KV 存储适合放少量高价值信息比如PR URLdeploy URL外部 ticket当前长期 blocker关键决策。但它不适合放一堆流水账。比如「我看了哪些文件」「我跑了什么命令」「今天试了哪个方案」这些更应该写进 comment 或者最终总结里。笔者对 metadata 的理解是它不是日记本而是给未来接手者看的标签纸。5.2 什么时候该写 metadata举几个比较合适的例子bash体验AI代码助手代码解读复制代码multica issue metadata set issue-id --key pr_url --value https://github.com/org/repo/pull/123 multica issue metadata set issue-id --key deploy_url --value https://example.com multica issue metadata set issue-id --key waiting_on --value backend api review这些信息有一个共同点后面大概率会反复被查而且从评论里翻会比较麻烦。反过来如果只是这次运行里的临时观察就不要往 metadata 里塞。metadata 一旦乱了后面的 Agent 就会被误导。6. 多 Agent 协作怎么做6.1 直接分配任务可以查看 workspace 里的 Agentbash体验AI代码助手代码解读复制代码multica agent list --output json然后创建 issue 时指定 assigneebash体验AI代码助手代码解读复制代码multica issue create \ --title 整理 Multica 使用心得 \ --description 写一篇入门实践文章 \ --assignee codex agent如果要更精确也可以用--assignee-id。这类方式适合简单分工一个 Agent 写一个 Agent review或者一个 Agent 调研一个 Agent 实现。6.2 子 issue 更适合明确拆分如果一个任务明显可以拆成几个独立部分就可以创建子 issuebash体验AI代码助手代码解读复制代码parent_issue_id这里换成主 issue 的 ID multica issue create \ --title Review Multica 文章 \ --description 检查结构、准确性和风格 \ --parent $parent_issue_id \ --assignee hermes 助手 \ --status todo这里--parent很关键它让子任务和主任务关联起来。状态也要注意todo创建后可以马上开始backlog先放着不触发执行后续再推进。如果是并行任务可以都设成todo如果是严格串行就只让第一步进入todo后面的先放backlog。6.3 不要乱 mention AgentMultica 的 mention 不是普通文本有些 mention 会触发 Agent 重新运行。所以在评论里如果只是提到某个 Agent直接写名字就好不要随手加 mention 链接。笔者觉得这个设计挺合理但也提醒我们在 Agent 协作系统里文字有时候就是操作。这和普通聊天工具不一样。普通聊天里某人可能只是提醒一下在 Multica 里mention Agent 可能就是一次新的任务触发。7. repo checkout 和代码任务7.1 检出仓库如果 issue 是代码任务可以用bash体验AI代码助手代码解读复制代码multica repo checkout https://github.com/example/project.git也可以指定分支或 commitbash体验AI代码助手代码解读复制代码multica repo checkout https://github.com/example/project.git --ref main这个命令会把仓库检出到当前工作目录并创建适合 Agent 执行任务的 worktree。这点对代码类任务很关键。因为 Agent 不是只在云端「想一想」而是真的要在本地仓库里读代码、改文件、跑测试。7.2 和普通本地开发的区别Multica 里的代码任务本质上还是本地开发读文件、改代码、跑测试、提交结果。区别在于它多了一个任务外壳issue 描述目标comments 记录讨论metadata 固化关键链接status 表示进度Agent runtime 负责执行最终结果回写 issue。所以笔者觉得Multica 并没有改变写代码这件事本身它改变的是「AI 写代码这件事如何被组织和交付」。8. Skills 和 Autopilot8.1 Skills给 Agent 加规则和知识Multica 也有 skill 管理能力bash体验AI代码助手代码解读复制代码multica skill list multica skill create multica skill importSkill 更像是给 Agent 的操作手册。比如你可以把团队的代码规范、review 规范、部署流程、日报格式写成 skill然后分配给对应 Agent。这和笔者之前理解的 AI Rules、Claude Memory、Kiro Steering 有点像它不是一个真正执行外部操作的接口而是一段会影响 Agent 行为的上下文。8.2 Autopilot让任务自动触发multica autopilot则更像是自动化入口bash体验AI代码助手代码解读复制代码multica autopilot list multica autopilot create multica autopilot trigger从命令看它支持 schedule 和 webhook 这类触发方式。也就是说一些周期性任务或者外部事件触发的任务可以不用每次手动创建 issue。比如可以想象这些场景每天早上自动汇总项目状态PR 创建后自动派 Agent 做 review某个 webhook 触发后让 Agent 拉取日志并分析定时检查某个服务的运行情况。不过笔者目前对 Autopilot 还只是浅尝真正要用好应该还要结合团队流程去设计触发条件和结果回写方式。9. 使用下来的一些心得9.1 它更像任务系统不是聊天框Multica 最容易被低估的一点是它不是把多个 AI 聊天窗口拼在一起而是给 Agent 加了一层任务系统。这层任务系统会带来一些约束比如必须读 issue、必须写 comment、必须更新 status。刚开始会觉得麻烦但对复杂任务来说这些约束反而能减少混乱。9.2 要把上下文写在正确的位置笔者现在会这样区分信息类型放哪里任务目标和约束issue description过程讨论和交付结果issue commentPR、部署地址、长期 blockermetadata代码和文档产物仓库或本地文件临时运行日志不需要长期保存这个边界很重要。上下文乱放后面接手的人和 Agent 都会痛苦。9.3 Agent 协作要避免“互相唤醒”多 Agent 系统里最怕的不是没人干活而是大家互相触发、反复评论、任务跑成循环。所以评论时要克制 mention分配任务时要明确边界创建子 issue 时要想清楚并行还是串行。一句话AI Agent 越多越需要流程约束。9.4 适合的场景笔者觉得 Multica 比较适合这些场景多个 AI Agent 分工处理同一个项目需要保留任务历史和交付记录代码任务需要本地 runtime 真实执行调研、写作、review、开发之间需要流转团队希望把 AI 工作纳入现有 issue 流程。9.5 不太适合的场景它也不是所有事情都要用。如果只是问一个很简单的问题直接聊天更快。如果只是本地改一个很小的脚本不一定需要创建完整 issue。如果团队完全没有任务管理习惯上来就用多 Agent 可能会更乱。如果没有把结果写回 comment 的意识Multica 的协作价值会打折。所以笔者对它的定位是简单问题直接问复杂任务进 Multica。10. 一个推荐的入门流程如果刚开始用 Multica可以按这个顺序来10.1 先确认本地环境bash体验AI代码助手代码解读复制代码multica version multica daemon status --output json multica workspace list --output json multica agent list --output json先确认 CLI、daemon、workspace、agent 都正常。10.2 再创建一个小任务bash体验AI代码助手代码解读复制代码multica issue create \ --title 整理 README 使用说明 \ --description 阅读当前项目 README补充一个快速开始章节 \ --assignee codex agent \ --status todo不要一上来就丢一个超大任务。先用一个小任务跑通 issue、Agent、comment、status 这条链路。10.3 观察 Agent 怎么交付任务执行过程中可以看 issuebash体验AI代码助手代码解读复制代码multica issue get issue-id --output json multica issue comment list issue-id --output json重点看三件事Agent 有没有理解 issue有没有把结果写回 commentstatus 有没有正确变化。10.4 再尝试拆子任务等单 Agent 跑顺以后再尝试多 Agent 协作。比如Codex 负责写Hermes 负责 reviewKiro 负责整理 specClaude 负责解释和文档。拆分时最好用子 issue而不是在一个评论里让所有 Agent 同时开工。11. 碎碎念终于把 Multica 的第一次系统使用体验整理出来了。写这篇的时候笔者最大的感受是AI Agent 真正开始参与工作以后问题就不只是「模型聪不聪明」了而是「任务能不能被稳定地交给它、执行它、验收它」。以前我们讨论 AI 工具容易关注模型能力、上下文长度、代码质量。但当多个 Agent 同时出现以后协作机制会变得同样重要。没有 issue就没有任务边界没有 comment就没有交付记录没有 status就不知道谁在做什么没有 metadata关键链接迟早被淹没。所以 Multica 对笔者来说更像是给 AI Agent 补上了「项目管理的骨架」。你所做的一切在将来某些时候都会反映到你自己的身上。你的气质里不但有你的教养也有教养所带来的结果好的成果或者不好的后果。时间具有唯一性和不可逆性与其浪费在斤斤计较里不如大气一点。大气的人才能赢得这个世界。能沉淀下来的流程才是工具真正的价值。