2. Linux.do
  3. 关于agent并行执行任务提高效率

关于agent并行执行任务提高效率

Mel0ny 2026-08-29 17:52 1

一直想并行开发提高代码效率，已经进行过如下的尝试（时间顺序）：




  • 1.claude code + superpowers + mimo v2.5 pro/deepseek v4 pro预览版/minimax m3/kimi k2.5：先提提需求，自动触发superpowers进行方案询问之类的，再写计划，再选用subagent进行干活，但是实际效果并不好：

    -（1）subagent一轮执行任务往往不能直接完成，需要主agent进行纠错之类的，这样主agent和subagent都混着一大堆错误的信息，很容易超过1m上下文的20%。

    -（2）subagent模式是每次派出一个去完成任务，实际效率也不是很高，加上还要纠错。




  • 2.claude code的agent team模式 + 同上模型：token消耗过高，而且每个teammate直接交流这个场景我感觉放在写代码上不太合适，而且有些交流完全是浪费上下文。




  • 3.opencode + oh-my-opencode-slim(omo-slim) + deepseek v4 pro/glm5.2：主agent遇到特定的问题时候通常不会主动委派agent，需要我写很详细的AGENTS.md才能主动去委派解决问题，但是实际上协调每个委派的agent也会占用比较多的上下文，解决问题和写代码的效率也不算高。




  • 4.opencode + oh-my-opencode(omo) + gpt 5.6 sol,terra,luna/kimi k3：一开始先用omo-slim是感觉omo太重了，后来遇到的各种问题我想着是不是我管的太多了，我就想着让agent自己发挥，ulw直接完事，实际上也是灾难，过度委派，token消耗过快，上下文被各种协调信息堆满，很快酱汁。




  • 5.codex + matt的skill + gpt 5.6 sol,terra（现在正在使用）：先grill-with-docs，to-spec，to-ticket，最后handoff再开新的对话针对issue去implement。这套方案是我目前用得最舒服的，代码质量也比较高。但是各个ticket之间我想要并行就只能开worktree然后提pr再用resolving-merge-conflicts去解决矛盾，维护也有些麻烦。




各位大佬有什么好的主意呢，还是说我的方法/模型/实用技巧有问题呢。

最新回复 (10)
  • Xu 08-29 17:57
    1楼

    同感，理论上来讲多agent系统可以减少主agent的上下文污染，也可以加快执行效率，但是实操起来总是不尽人意。

  • ezirmusitua 08-29 18:04
    2楼

    我目前走的也是 5 吧，不过我不会开新的对话，基本上在 grill + spec + tickets 共用上下文，然后在 spec/tickets 里面存约束、关联文件，后面 compact 再推到开发流程。worktree merge conflicts 感觉没遇到过，这个主要是 tickets 拆分的时候作用域重叠或者说没按 DAG 分配任务导致的吧。

  • 看海的鱼 08-29 18:07
    3楼


    • 最后handoff再开新的对话针对issue去implement



    请问一下佬，你这句话的意思是在implement的时候，还要加一步承接前面讨论的handoff吗？请问这样有哪些好处呢？我一般都是开新的context，直接implement

  • nanero 08-29 18:10
    4楼

    不要用多子代理,用同时继承上下文多开输入框，设置陷阱词，你让它自动很慢的，用刚出的那个dsh很好实现。

  • Lgnacio 08-29 18:14
    5楼

    如何让CODEX多开点子智能体 - #2，来自 Lgnacio 反正我是这样做的，agent都是 gpt的 也许可以再和 gpt讨论下 怎么接入其他模型。

  • Mel0ny 楼主 08-29 18:47
    6楼

    直接implement他缺少上下文，agent每次都要去找文件读，各种cat find，这点很多人都提到过。handoff保留的是当前的项目状态，要做什么以及下一步该做什么，防止他到处找。matt本人正在准备做一个新的implement-spec skill来解决这个问题

  • 看海的鱼 08-29 21:26
    7楼

    多谢佬友，又学到了，确实现在即使是grillme这样的技能集也很费token了，这么一想，/handoff确实能够很好解决实现需要冷启动的问题。原来这个 /implement-spec就是在做这个用的，再次感谢

  • tianyunlinger 08-29 22:33
    8楼

    claude+trellis，使用极其舒服，自动合理的开subagent，而且划分探索，实现，检查等多宗subagent，但还是尽量让subagent只进行实现和探索类任务，主agent进行总结和审计即可，因为我用的是gpt-sol-5.6，好喜欢审计。至于如果你有什么个性化需求你可以自己简单写个skill，hook之类即可，claude的整个生态还是太生产级了，其他东西真的就像是小作坊搓出来的，极其不稳定。

  • Mel0ny 楼主 08-29 22:46
    9楼

    我看到linuxdo内挺多佬也用trellis，但是还没试过，我不太明白为啥做文档还要转门下载一个程序来用

  • xsxdot 08-29 22:48
    10楼

    我现在在尝试一种先拆契约的方式，算是DDD吧，把一个项目拆成多个子系统/领域，有一个节点专门定领域之间的契约，也就是这个领域对外开放哪些契约和接口，是通过client还是消息队列等方式，领域与领域之间只调接口，然后涉及到的领域并行开发。我用的是我自己开发的handoff cli，把任务派发给其他agent来做，比如opencode、codex、grok这些。主会话拆完之后就派发，然后对这些子agent挂监听，回答问题或者批权限，结束一个派一个子agent审阅一个，不通过打回继续修改，通过的等最后合并。

* 帖子来源Linux.do
附近帖子
返回
飞读
随机推荐