慕雪的小助手正在绞尽脑汁···
慕雪小助手的总结
DeepSeek & LongCat
本文部分内容由 AI 辅助生成,请结合实际情况判断参考。

最近在进行全栈开发,之前都是用 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……