[增强] 支持专用代理程序并行执行,并改进模式之间的上下文转移

问题(一两句)

Roo Code目前的多代理系统以Orchestrator模式为中心,主要支持在专业模式之间按顺序分配任务. 这限制了并行运行独立子任务的能力,并使得代理商之间的上下文交接有时不明确或不完整,迫使用户手动管理协调以进行更高级的情景.

• 背景(谁和何时受影响)

这影响到那些希望充分利用Roo Code作为复杂项目“备用团队”的用户,例如,拥有一个代理研究文件并探索各种选择,而另一个同时进行实施工作,或者使用分级授权,即高级代理将工作分解为多个专业次级代理。 在较大的地物,建筑变化,或试图通过同时对一项任务的独立部分进行工作来加快开发时,这种限制感最多.

理想行为(概念性,而非技术性)

用户应能够指示系统在不同专门代理人之间并行执行任务的独立部分,并在工作从一个代理人转移到另一个代理人时,有明确、可控和明显的上下文交接。 该系统应帮助用户了解代理人之间传递的信息,并使他们相信在过渡期间不会失去任何重要信息。

限制/优惠(可选)

任何平行执行功能都应在用户控制之下(例如,并行工作需要明确批准),并且必须与现有模式和目前的 " switch mode " / " new task " 工具保持一致。 解决方案不应该强制用户采取平行行为,他们更喜欢简单的相继工作流程.

请求核对表

• 我搜索过现有的问题和讨论 重复
• 这描述了具有明确背景和影响的具体问题。

& #% Roo 代码任务链接( 可选)

#6298 与自定义代理团队执行混合和分级工作流程 #11894 IDE管弦乐的多剂协调层

• 接受标准(可选)

• 用户可通过Orchestrator或新的协调机制要求并行执行独立的子任务。
• 不同模式之间的上下文交接更加明显,包括明确的摘要。
• 并行工作仍在用户控制之下,并有批准步骤。
• 特性与现有模式相容,不中断当前相继工作流程。
• 在聊天或协调观点中可以看到平行任务和交接的基本可见度。

拟议办法(可选)

扩展 Orchestrator 的能力(或引入轻量级协调逻辑),使其可以产出并监控多个可以平行运行的独立子任务. 改进交接经验,提供更清楚地概述正在转移的背景、聊天中代理人与代理人之间通信的可见记录,并可能提供 . . . . . . .