对，主要是 API 的甲。因为我发现不管我是用这个 opencode go渠道，还是去接官渠的 API，它现在做逆向工程，时不时的就会断。如果只是 harness 的甲的话就好了，但是主要是好像不是 harness 的，因为 harness 的我已经去了。而且破甲了之后，我也一直没更新。所以说应该不是 harness 的问题。

我给 DSH 和 CodeX 都破甲了，我的 system prompt 可能因为注入了写逆向工程的内容，导致上游拒绝返回。 我破甲用的这个佬帖子里的内容。

主要是这个，它一开始宣传的就是能够越来越懂你的语音输入的 Agent，而不是一款单纯的语音输入。然后就让我误解成了，它是能够根据我输入的这个全面回忆，然后能够越来越了解我。但实际上，真正的还是需要自己去设置风格，自己去设置 memory，然后自己去沉淀词典。我之前以为这些都是能够自动化的，因为它打的是 Agent 的那个宣传。

也是，我觉得 memory 可能不会越来越多，memory 就是要更精细化。但我觉得更多的是平时在日常使用中，一段时间可能在做一个项目，那这个项目的语音输入过程中应该会有很多关键词，是可以不用了的。 那在我们一开始进行语音输入的时候，还有可能会语音输入错误，这时候就会识别到。像这种如果能接入的话，我想它更多是会沉淀，一个项目沉淀出对应的词典，一个工作流会有一个对应的词典。 像现在目前他这个全面回忆

这个好像，如果是微信的话，感觉可以做到吧。 就是获取微信联系人的信息，然后导入到这个语音输入软件里面，再强制一点，加上文本正则化，基本上就不会出问题了。

对，就是我发现如果用 dsh，我如果使用这个 V4 Flash，它就能很好地了解我的 prompt，然后分发子代理。但是感觉这个，因为我要做这个切片任务，它直接去分发的话，我感觉直接用原生的多模态可能会更好。 所以我就想着换成这个 Gemini 3.7 Flash。但是的确，本来 dsh 就是比较轻量的 harness，再加上 3.7 Flash 这个模型，它的偏向就是经常会——即使我输入了 pr

严肃品尝，非常喜欢 Gemini Flash 系列，吐得够快，虽然有时候非常非常弱智，但是它真的是又快又快。

感谢佬友！如果输入全是现成的图片，直接跑多线程脚本调 API 确实是最优解。 不过我这边的情况是一整本大 PDF，真正的难点在于前面的【任务规划与切片】环节：需要先分工定位题目的页面与视觉坐标，裁剪出独立题图，最后才到识图。 如果纯靠代码，很难精准感知复杂的排版边界；但要是直接交给子 agent，又很容易出现上面提到的“分工失控、抢着做全局任务”的问题。 所以核心是缺了一个前置的任务规划与调度机制

这样吗，我之前觉得chrome-mcp太重了就转playwright了，谢谢佬友，我去看看 ^-^