【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 的所有信息（包括描述和下面已有的评论），开始干活。

接下来说重点，如何让 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……

推荐订阅源

慕雪的寒舍

简介

几点注意事项

欢迎交流