目前我用的还是dsh最初发布的版本,因为怕更新后有些写的东西用不了了又要重新调整,比较麻烦,就没有更新。
然后最近主要没有去拿来coding了，主要是处理文档，plan和规划的产出，让agent去对pdf进行切片和识图。
但是有时候需要处理的图片比较多，单agent串行比较慢（即使现在用的是3.7flash tps都快干到1000了），所以想多子代理去完成任务。规划也是一样，也希望是多代理去探索讨论了之后再去产出plan。
想法很简单，实施起来出入有些大，对文档的处理经常会变成每个子代理都去多整体任务的完成，而不是分工完成（因为只是对文档进行处理，而部分耦合度很低，基本上分工完成影响很小）。最后导致的是时间还是花了那么多，还在每次子代理返回注入上下文又多加了一大堆的输出。
所以想问问佬们是怎么解决multi-agent协作的问题的。
对于在codex中会出现这样问题就比较少，同样也是3.7f，但是现在的确日常使用迁移到了web端（主要拿来学习所以web端一些方便自己学习插件比较好使，如trancy翻译、公式katex渲染并能够点击复制），所以主要还是在用dsh。
使用的opencode + oh-my-opencode-slim；但是很好奇的是，切片和识图为什么不让agent写代码，然后多线程并行使用llm api+prompt去完成？
感谢佬友！如果输入全是现成的图片，直接跑多线程脚本调 API 确实是最优解。
不过我这边的情况是一整本大 PDF，真正的难点在于前面的【任务规划与切片】环节：需要先分工定位题目的页面与视觉坐标，裁剪出独立题图，最后才到识图。
如果纯靠代码，很难精准感知复杂的排版边界；但要是直接交给子 agent，又很容易出现上面提到的“分工失控、抢着做全局任务”的问题。
所以核心是缺了一个前置的任务规划与调度机制。这才想摸索一套既能让多 agent 做好定位与切片的明细分工的协作方式。
因为目前单靠 prompt 和全局规则，感觉很难每次都精准地识别到。
感觉需要有固定的架构，然后才能实现：如果需要多 Agent 先规划、再各 Agent 分工执行的流程。
感觉你这段文字作为prompt就很好啊。可以加一句用workflow。比如:
创建一个workflow，先并行使用多Agent划分负责区域，找到所有可能得候选题图。针对每个题图，再派发 Agent 执行…(后续流程)
如果这样还不行，一般就是模型本身的能力不行。。
对，就是我发现如果用 dsh，我如果使用这个 V4 Flash，它就能很好地了解我的 prompt，然后分发子代理。但是感觉这个，因为我要做这个切片任务，它直接去分发的话，我感觉直接用原生的多模态可能会更好。
所以我就想着换成这个 Gemini 3.7 Flash。但是的确，本来 dsh 就是比较轻量的 harness，再加上 3.7 Flash 这个模型，它的偏向就是经常会——即使我输入了 prompt，它还是自己去做事，或者说达不到我想要的要求。
但实际上这种问题在 Codex 里面就很少会出现，基本上能按照我的 prompt 去做，即使我用的模型还是 3.7 Flash。
这就是我为什么想着，如果 dsh 加上一个架构的强约束，就是 multi-agent，我自己 workflow 的架构强约束，它能够像 Codex 那样很好地完成我的需求的话，我就是想实现这样一个目的。
dsh在这方面是比较懒的，特别是workflow，一般只有显式提到关键词，或者任务夸张到了不用不行(比如你提到要用64个并行agent，才会用workflow)。
一个比较简单的办法就是在AGENTS.MD里记清楚偏好多agent。对于gemini这种不太聪明的模型，可能加上一两个例子(few shot)比较好
我想試試看這個任務，我自己做的Bot Team，想看看能不能解掉你的問題
我平时这套任务的核心分发与设定流程大概是这样的：
- 任务分发（Planner）：输入是一整份多页的题库 PDF，主控需要按章节/页码范围（如 Agent 1 负责 1
3 页，Agent 2 负责 46 页）做明确的任务范围拆分。 - 视觉定位与物理切图（Worker）：每个子 agent 识别所负责页面的题目边界坐标（bounding box），并调用本地切图脚本把高清题目切片保存到指定图片文件夹。
- 识图转录（Worker）：对切出来的单题图片多模态识别，提取出规范的 LaTeX 题干与知识点。
- 结果收敛（Collector）：最关键的一步，主控只接收结构化清单汇总。严格不能让各个子 agent 的海量中间思考和过程文本全量回灌到主上下文。
目前在轻量 harness 下的痛点就是：**子 agent 经常越界抢着做全局、分工执行不坚决，而只要出现了前面两个问题，那么最后主 Agent 的上下文绝对会被这个子 Agent 返回的上下文注入后刷爆。而 3.7 Flash 的上下文注意力本来就不是很强，所以我觉得上下文这个问题还是需要精细化一点。即使它上下文注入得不是很多，但对 3.7 Flash 还是有一些影响。
不过最主要的影响还是，子 agent 有时候会做全局，不是只完成我分配给它的那几页。我想要的是，主 Agent 启动这几个 Agent，然后开始 Plan 规划，规划好之后，子 Agent 一负责这几页，Agent 二负责另外几页。制定好任务之后下发，然后按照任务完成就行了。
对，就是基本上需要提到显示的关键词。就比如说我如果告诉他，要求他开三个子代理，然后去完成一个任务，而且必须要告诉这三个子代理，就是只完成这个任务，然后他基本上才会主动地去调用子代理。
但是我如果说我直接说开多代理去完成这个切片和识别任务，他有时候就是不做 planner，而是直接把这个主 agent 调，直接给给出了一个模糊的任务，然后让子 agent 去执行。然后子 agent 有时候就会把这个全量任务全给做了，直接就是好几个子 agent 做全量任务，然后再把全量几个子 agent 的全量任务完成了之后，然后全部都返回，然后上下文就直接爆炸。