那么我们是否可以把任务拆分呢？像n8n、sim那样把项目需求拆解开然后让他逐个实现单个文件体系？然后呢最后在拼接起来？因为可能只需要读取首尾100行就大概知道这是啥项目了是不？那么有没有可能，可以把每个都拆分开？最终调用一个优秀的大模型来拼接组装起来呢？这里写转接器就好了，无需重构文件，不然太吃token了。
例如：
一个简单的任务，写个小程序外卖？把UI、逻辑、实现、控件点击、文档、主界面主文件（这个主文件是否能写成路由器呢？然后呢单独去完成每个文件功能的实现呢？接着我们在接回路由器）。这里说的有点绕，就是可以把软件、程序等像个积木一样一个一个搭起来。这对于目前的cli很有帮助。你必须拆分，必须空出上下文占用。让每个任务都进行一次新的单独完成，现阶段的cli我发现他会进行上下文的堆叠等等
这个实现是否能被采纳呢？
因为我不是大模型的内部人员，所以说我敢笃定大模型上下文肯定不是固定的，所以说那么我们是否可以根据任务程度来自动划分呢？然后如超出我们在递增到原有的，这样的好处就好像每次API请求都无需上下文，但是他又能保留主题中心呢？
然后对于大型架构的项目那么可以先借助列出的所有文件夹、文件子文件等等的文件名称来进行主题条件呢？这样他就不会迷路
比如任务清单可以一并从后续在发出，或者给已经构建好的文件进行出现总结等等，接着在把这个总结一并发送给下一个新的上下文，这样是不是特别好呢？对于不会写提示词的小白也能做出好的软件
我对这个问题的看法是，agent 需要社会化分工。
ai 要分成虚拟的 DevOps 团队成员，在你的例子里，可以每个模块分配一个负责人，个人记忆里维护模块知识，然后与人类交互方式上，是用一个任务文档开始一个主对话，分配专门的协调员/总指挥 agent，负责维护任务文档中的目标、约束、任务分解分配、各项进度信息，然后根据情况调用相应的负责人 agent，开启子对话，子对话也是以任务文档为中心，负责的 agent 在自己的知识、职责范围内调用工具，修改代码、文档，推进工作项进展，然后汇报回去。
不管是主对话还是子对话，提供工具让 agent 可以自主忘记对话历史，但当然要保留核心的任务文档在上下文中，再配合临时提醒项，让对话历史（主要是工具调用细节）清除前后的工作可以自然衔接起来，当然任务文档中的目标、约束、任务分解分配、各项进度信息由协调员更新，全团队共享。
现在流行的 skills，其实可以做成临时工 agent，这比人类个体去承载多种技能的方式来得还会更清爽可控，人会做的事情跨度大，自己切换起来也累也有 overhead，ai 就可以无成本养大量临时工，按需招来做事就行。 现行 skills 机制一般都没有自己的独立 agent （上下文），存在对单 agent 上下文的污染问题，临时工在自己的上下文里把知识运用到分项工作的完成上，做好以后只汇报结果，可以避免污染。
我的意思就是这样的，让AI有分身，每个分身都干自己专属的事情，接着呢就一个包工头去监督收集。跟考试一样，每个人的试卷都是不一样的，你只需要做你的试卷就好了
我的框架里还有 agent 之间，以及 agent 向人类提问，并获得回答的机制，鼓励 agent 向更权威主体对存疑项进行澄清，而不是自己猜最可能的情况去搞，这样整体上效率应该也有质的提高。
这些思路正在开发一个框架，好了打算开源发布。
主动提问roo code开源项目有，但是他会占用上下文，我不希望是那样
Roo Code 的 Orchestrater 是个很好的多 agent 上下文隔离设计，但它只能一次性返回结果，不能向父对话问澄清问题然后继续子对话工作。
Roo 向人类用户提问限于根对话，实现得也比较基本，不算很突出的特色功能。
你可以按照roo的思路去列表，首先你要解决提示词裂变分布给员工的这个问题，这个问题解决好了基本上没啥难度了
