2. Linux.do
  3. 现在dsh还有佬在用吗,想询问multi-agent使用技巧

现在dsh还有佬在用吗,想询问multi-agent使用技巧

Ayuan 2026-09-02 15:05 1

目前我用的还是dsh最初发布的版本,因为怕更新后有些写的东西用不了了又要重新调整,比较麻烦,就没有更新。

然后最近主要没有去拿来coding了，主要是处理文档，plan和规划的产出，让agent去对pdf进行切片和识图。

但是有时候需要处理的图片比较多，单agent串行比较慢（即使现在用的是3.7flash tps都快干到1000了），所以想多子代理去完成任务。规划也是一样，也希望是多代理去探索讨论了之后再去产出plan。

想法很简单，实施起来出入有些大，对文档的处理经常会变成每个子代理都去多整体任务的完成，而不是分工完成（因为只是对文档进行处理，而部分耦合度很低，基本上分工完成影响很小）。最后导致的是时间还是花了那么多，还在每次子代理返回注入上下文又多加了一大堆的输出。

所以想问问佬们是怎么解决multi-agent协作的问题的。

对于在codex中会出现这样问题就比较少，同样也是3.7f，但是现在的确日常使用迁移到了web端（主要拿来学习所以web端一些方便自己学习插件比较好使，如trancy翻译、公式katex渲染并能够点击复制），所以主要还是在用dsh。

最新回复 (5)
  • VibeKoder 09-02 16:26
    1楼

    使用的opencode + oh-my-opencode-slim；但是很好奇的是，切片和识图为什么不让agent写代码，然后多线程并行使用llm api+prompt去完成？

  • Ayuan 楼主 09-02 22:05
    2楼

    感谢佬友！如果输入全是现成的图片，直接跑多线程脚本调 API 确实是最优解。


    不过我这边的情况是一整本大 PDF，真正的难点在于前面的【任务规划与切片】环节：需要先分工定位题目的页面与视觉坐标，裁剪出独立题图，最后才到识图。


    如果纯靠代码，很难精准感知复杂的排版边界；但要是直接交给子 agent，又很容易出现上面提到的“分工失控、抢着做全局任务”的问题。


    所以核心是缺了一个前置的任务规划与调度机制。这才想摸索一套既能让多 agent 做好定位与切片的明细分工的协作方式。


    因为目前单靠 prompt 和全局规则，感觉很难每次都精准地识别到。


    感觉需要有固定的架构，然后才能实现：如果需要多 Agent 先规划、再各 Agent 分工执行的流程。

  • kou 09-02 23:13
    3楼

    感觉你这段文字作为prompt就很好啊。可以加一句用workflow。比如:


    创建一个workflow，先并行使用多Agent划分负责区域，找到所有可能得候选题图。针对每个题图，再派发 Agent 执行…(后续流程)


    如果这样还不行，一般就是模型本身的能力不行。。

  • Ayuan 楼主 09-02 23:16
    4楼

    对，就是我发现如果用 dsh，我如果使用这个 V4 Flash，它就能很好地了解我的 prompt，然后分发子代理。但是感觉这个，因为我要做这个切片任务，它直接去分发的话，我感觉直接用原生的多模态可能会更好。


    所以我就想着换成这个 Gemini 3.7 Flash。但是的确，本来 dsh 就是比较轻量的 harness，再加上 3.7 Flash 这个模型，它的偏向就是经常会——即使我输入了 prompt，它还是自己去做事，或者说达不到我想要的要求。


    但实际上这种问题在 Codex 里面就很少会出现，基本上能按照我的 prompt 去做，即使我用的模型还是 3.7 Flash。


    这就是我为什么想着，如果 dsh 加上一个架构的强约束，就是 multi-agent，我自己 workflow 的架构强约束，它能够像 Codex 那样很好地完成我的需求的话，我就是想实现这样一个目的。

  • kou 09-02 23:22
    5楼

    dsh在这方面是比较懒的，特别是workflow，一般只有显式提到关键词，或者任务夸张到了不用不行(比如你提到要用64个并行agent，才会用workflow)。


    一个比较简单的办法就是在AGENTS.MD里记清楚偏好多agent。对于gemini这种不太聪明的模型，可能加上一两个例子(few shot)比较好

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