这几天研究DSH发现几个问题大家一起讨论一下（正在做一个专门给gpt优化的定制agent）

你说的问题目前我也正在研究

主agent通过下发一个探索任务给explorer subagent，subagent会通篇查找所有代码，回到主agent虽然可以减少代码量，但是对于sol来说他会不断调用，也就是说一个代码库会浪费很多token是存在的。

这样做唯一好处是，净化主agent的上下文。（把很多和任务相关性低的工具调用交给subagent了）

目前我和gpt讨论的方案是做一个workspace notebook，所有agent都往上面填写他接触到的知识，然后支持rag探索。不过我还没实现。。。。

虽然但是Subagent不是fable和sol的标志性能力么

想解决慢的问题，gpt放到DSH中运行起来就是慢死了，尤其是开启subagent后

Gpt在claude里也有类似的问题。可以找找有没有类似的解决方案

我也尝试过类似你这种工作方式，一个主agent负责提供任务所需的知识库，一份用于报告任务进度和记录已知信息的交接文档，手动开新的agent后，要求先阅读交接文档，并且加入到claude.md后，再开始工作。当时是在移植ubuntu驱动，一个主agent+4-5个处理不同模块的，但是后面发现个agent内容交叉的部分需要让手动使用提示词让他们之间互相了解并发现，后面就没这么弄了，但是一开始确实很神奇，就像组成了一个agent team。

我觉得子agent的主要作用不一定是处理具体的子任务（比如写个函数、写个类）

首先多agent的优势在于并行完成一项工作，其次是子agent的上下文比较干净，如果注入内容过多，对主agent是负担，如果过少，对子agent是负担。

所以我觉得子agent的作用应该是审核、头脑风暴、可以隔离的多模块开发（比如设计好模块边界，多子agent按照接口开发调试）等。这样既能减少主agent的负担、也能发挥并行的优势，主子agent也能保持较少的上下文内容。

subagent效率偏低，尤其是上下文复用效率偏低，每个subagent都要重建上下文，都会有信息损失，所以实际上这个已经不是实践主流。更重要的是，浪费token和缓存。