一个基于fork主agent的subagent创建方式构想

问题描述：

在上下文是有限的这个前提下
很多调度“agent/主agent”会把一些消耗上下文的任务交给subagent去做
比如说：计划，修改，审核

但是这就有了一个问题，计划，修改，审核这类操作，都很依赖于agent对项目的理解
而调度agent在向subagent分发任务的时候，不可避免的会损失一部分项目信息，如果传递的比较多，又会导致subagent运行缓慢，成本爆炸

所以说我就有了一个想法，为什么我们不让调度agent自己去干这些活呢？
我们可以在需要做plan的时候，把调度agent fork出去，加一段固定的prompt，告诉它下面应该干哪些活，最后返回任务的结果给原本的调度agent（TodoList,修改结果,审核方案）
而这个过程中，大部分的context都是走缓存的，所以说成本实际上并没有很高（甚至可能比直接让子agent自己去探索更便宜），而因为上下文包含完整的项目信息和调度agent的意图，执行的也更精准

网友解答：

---

--【壹】--：

原来如此，那这个思路就没法降低成本了。。

---

--【贰】--：

简单说就是雇佣一个leader，下面分几个子agent员工？

---

--【叁】--：

这个是最原始的subagent，我这个方案是想解决子agent对项目理解不够的问题

---

--【肆】--： Epresin:

大部分的context都是走缓存的，所以说成本实际上并没有很高

这里其实有一个误区，因为缓存的checkpoint数量是很有限的，你可以把他想象成带轮换机制的门禁卡，你复制之后，刷了一次复制卡，原卡的密钥就对不上了。也就是说，subagent会把缓存吃掉并改写为新的缓存，而主agent继续跑就要重新创建所有缓存。

---

--【伍】--：

对，我用omo的时候就感觉到了，subagent如果拿不到完整上下文很容易跑偏

---

--【陆】--：

虽然说大概省不了费用消耗，但是fork主agent来保持前文理解，在很多情况下是很好用的，我的agent也做了这个功能。