【Agent】Multica使用心得
最近在进行全栈开发,之前都是用 git worktree 在本地用 codex 进行处理的,事情完成以后就只有一个对话链接在那里,不太方便后续查信息,而且指不定哪天就被删掉了。
之前就了解到了 multica 这个“Agent 看板”工具,于是就开始使用了一段时间。在这里分享几个简单的使用心得吧。截图就懒得截了,因为有私密信息,得打特别多的码。
简介
首先呢,简单介绍一下这玩意,这玩意就是一个看板,创建 todo 之后,可以指派给某个人,也可以指派给某个连上了 multica 的 agent。multica 本身没有 agent loop,他的 agent 是通过在你的电脑上安装的一个 deamon,和 multica 的 server 交互的,在 server 的看板上,这些 deamon 叫做“runtime”,一个 runtime 等价于一台链接上了 mutlica 的主机。在 runtime 之上,我们需要创建自己的 Agent,并给这些 Agent 绑定导入的 skills 和 system prompt,这样 Agent 就可以用你指定的工具,在你指定的电脑上执行任务了。
在这个机制下,multica 可以用任何你想用的 agent 工具,且复用你本地 codex/claude code 的个人订阅(配置第三方 endpoint 也能用的,和你本地人工启动 codex 和 cc 没区别),来完成工作。即便是在同一个 runtime 上,每个 Agent 也可以使用不同的工具,不同的模型,来在特定的场景 boost 模型的能力(比如 claude 擅长 plan,gpt 擅长干)
最基本的使用方式,就是创建一个任务,然后指派给一个你创建好的 agent,他就会收到这个任务(在 multica 上叫做 issue)的信息,在你本地 multica 创建出来的一个工作目录里面开始干活。
在 issue 下的评论区 @ 另外一个 Agent,另外一个 Agent 也能收到这个 issue 的所有信息(包括描述和下面已有的评论),开始干活。
agent 协作
接下来说重点,如何让 multica 上的 Agent 能够相互协作。
核心原理非常简单,让 Agent A 在需要另外一个 Agent B 协助的时候,在 issue 下面发布评论,并 mention 另外一个 Agent 即可!
mutlica 的 mention 工具对 Agent 的注入不够完善,有可能 Agent 不知道如何 @ 另外一个 Agent,需要在 Agent 的 prompt 里面写明确“使用mention工具交付任务给指定Agent:xxx”
以全栈开发为例,直接按研发的流程来创建 Agent 就行了,分为需求文档、技术方案、代码编写、代码review、测试、准出这几个流程。
- 用户创建需求,写好需求简述
- 需求文档编写 Agent 根据需求编写需求文档,并通过 issue 评论的方式交付需求文档
- 需求文档这一步可以加一个人工卡控流程,让人工确认 Agent 对需求的理解没有问题,避免需求理解歪了,后面做得再多也没有意义
- 需求确认后,技术方案编写 Agent 根据 PRD 和项目背景编写技术方案,再通过 issue 评论提交给研发评审
- 技术方案评审不通过就打回技术方案编写 Agent 修改,通过后再 mention 代码编写 Agent。不能直接拿 PRD 当 plan 开干
- 代码编写 Agent 搞定后,交付代码 CR Agent,先对问题进行AICR(code review)
- AICR 完毕后,再次 mention 实现 Agent,要求其根据CR结果修改问题
- 实现 Agent 根据问题修复完毕后,要求 CR Agent 对问题进行二次确认
- 为了避免两个 Agent 进入互怼死循环,请在代码编写 Agent 的 prompt 里面写清楚允许的交互轮次,建议只允许 1 轮交互,如果在第一次修复后还是被 CR Agent 指出了问题,代码编写 Agent需要中断流程要求人工介入。
- CR Agent 实现代码准出后,交付任务给测试 Agent,进行测试(注意这里的测试是系统测试,如果是单测让代码编写 Agent 自己干了,不然他写的代码肯定有问题)。这要看项目的可测性能力了,如果是前后端项目,可以直接用 codex 来干,codex 的浏览器自动化能力太超模了。如果是移动端、服务端项目,就麻烦很多,得自己看看如何让 Agent 进行测试。
- 测试验收失败,打回代码实现 Agent,修复问题。如果有 blocker 问题,建议测试验收失败 Agent 要求人工介入。
- 测试验收成功,直接交付发布 Agent 进行发布(一般是提交代码 PR)
- 同样的,测试打回也要加上上限,最好是第二次还被打回就直接要求人工介入
到这里,全流程结束,很流畅的搞定喽。
让 ai 给这个链路画了个流程图,方便理解。
flowchart TD
A["用户创建需求<br/>填写需求简述"] --> B["需求文档 Agent<br/>编写完整需求文档"]
B --> C["通过 Issue 评论<br/>交付需求文档"]
C --> D{"启用需求人工卡控?"}
D -- "启用" --> E{"需求理解正确?"}
E -- "否" --> B
E -- "是" --> F
D -- "不启用" --> F["技术方案 Agent<br/>根据 PRD 编写技术方案"]
F --> G["通过 Issue 评论<br/>提交研发评审"]
G --> H{"技术方案评审通过?"}
H -- "否" --> F
H -- "是" --> I["代码实现 Agent<br/>编码并完成单元测试"]
I --> J["Issue 评论<br/>交付 CR Agent"]
J --> K["CR Agent<br/>第一次 AI CR"]
K --> L{"代码准出?"}
L -- "是" --> Q
L -- "否" --> M["Issue 评论 mention 实现 Agent<br/>提交 CR 问题"]
M --> N["实现 Agent<br/>仅允许 1 次修复"]
N --> O["CR Agent<br/>二次确认"]
O --> P{"二次确认准出?"}
P -- "是" --> Q["测试 Agent<br/>执行系统测试"]
P -- "否" --> X["中断自动流程<br/>要求人工介入"]
Q --> R{"测试通过?"}
R -- "是" --> S["发布 Agent<br/>提交代码并创建 PR"]
S --> T["流程完成"]
R -- "否" --> U{"存在 Blocker?"}
U -- "是" --> X
U -- "否" --> V["实现 Agent<br/>修复测试问题"]
V --> Q
classDef human fill:#fff3cd,stroke:#b8860b,color:#222;
classDef agent fill:#e8f1ff,stroke:#4677b8,color:#222;
classDef decision fill:#f5e8ff,stroke:#8250a8,color:#222;
classDef stop fill:#ffe8e8,stroke:#b84545,color:#222;
classDef success fill:#e6f6ea,stroke:#38864b,color:#222;
class A,E,H human;
class B,F,G,I,J,K,M,N,O,Q,S,V agent;
class D,L,P,R,U decision;
class X stop;
class T success;
这里特意把技术方案和研发评审单独拎了出来。PRD 只说明要做什么,不能直接拿它当 plan 开干,技术方案评审通过了再让实现 Agent 动手。
几点注意事项
- 【重点】一定要给每个 Agent 都规定好 blocker 策略,避免 Agent 进入死循环。这个非常非常重要!特别是测试环节,如果在测试进行环境准备的时候遇到了无法解决的环境问题(比如 playwright 连不上 chrome 之类的问题),要求 Agent 重试 2 次就 abort,不然 Agent 可能会和测试工具的环境问题进行死磕到底……
- 如果是前后端项目,需要要求 Agent 每次启动的时候都要找一个不同的数据目录,不同的端口启动,避免并发任务的时候相互干扰。至于开发目录不用担心,mutlica 本身的 workspace 就是隔离的,除非 AI 犯病去看别的目录在干嘛,不然不会相互干扰。
- Agent 给定的背景信息很重要,对于一个项目而言,最好是给每个 Agent 都注入这个项目的特定知识,不然肯定是会乱搞的。
- 把 rm 命令,数据库 drop delete 权限都给 ai 下掉,不然给你拉坨大的……
注意确认全局的 claude 命令和 codex 命令指向的是不是 cli,因为 claude desktop 和 codex desktop 都会内嵌一个一模一样的命令,如果是 desktop 内嵌的那个命令是没法用的
欢迎交流
感觉这样的操作方式会比用 codex 里面写一个 skills 来编排流程更好。而且后续能有清晰的项目归档,方便回溯。流程定义也非常简单,直接在 Agent 的 prompt 的末尾告诉他,他的下家 Agent 的名字就行了。不需要在 skills 里面还维护一个状态图。
当然还有另外一个方案就是 codex 的 goal,对于前后端项目而言,一个大 goal 下去 sol 基本上啥都能给你写出来,顶多是前端样式很烂需要微调,功能不会有啥问题的。
有了 multica 之后越来越像老板了,只不过老板 @ 的是真人,我 @ 的是 AI……


