• Ayuan

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

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

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

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

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

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

    主楼
  • VibeKoder

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

    #1
  • Ayuan

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

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

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

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

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

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

    #2
  • kou

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

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

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

    #3
  • Ayuan

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

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

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

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

    #4
  • kou

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

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

    #5

发表回复

登录后回复