（447期）respond-first – 多代理智能任务调度中枢

多代理智能任务调度中枢 开源多代理调度中枢，通过5个固定子代理实现任务负载均衡，将用户交互与执行层彻底解耦，提升复杂任务处理效率与系统安全性。 使用说明 核心用法 respond-first 是一个纯调度型多代理协调技能，主代理仅负责与用户对话，所有实际工作通过 sessions_spawn 委托给 5 个固定子代理（alpha/bravo/charlie/delta/echo）执行。采用轮询调度策略，任务按顺序分配给不同角色的子代理：alpha 处理复杂重任务、bravo 负责代码分析、charlie 专注规划设计、delta 执行修复工作、echo 承担搜索研究。 使用时必须遵守两条铁律：一是"先说话再派生"——必须先用文本回复用户告知任务分配，再调用 sessions_spawn；二是"必须传递 sessionKey"——每次派生必须指定五个固定键之一。任务描述需完整自包含，子代理无上下文继承，超时统一设为 300 秒。 显著优点 架构隔离性强：主代理零权限设计，不接触任何执行工具，从根本上杜绝主代理层面的误操作或恶意操作风险。负载均衡清晰：五角色分工明确，轮询机制简单可靠，适合多任务并发场景。用户体验友好：强制先回复的机制确保用户始终感知系统响应，避免"静默执行"带来的焦虑。文档规范完善：SKILL.md 结构严谨，示例丰富，禁止清单明确，降低了误用概率。 潜在缺点与局限性 故障恢复缺失：子代理若崩溃或超时，无自动重试或降级机制，需人工介入。状态管理薄弱：固定 sessionKey 若未正确清理，可能导致会话残留或状态污染。粒度控制不足：主代理无法干预子代理内部执行细节，对需要精细控制的场景力不从心。依赖外部配置：安全性高度依赖子代理自身的权限配置，若子代理被授予过高权限，风险将间接传导。原子性保障缺位：复杂任务无法保证事务一致性，子代理失败可能导致部分完成状态。 适合的目标群体 适合需要高并发任务处理且任务类型多样的开发团队，尤其是已将工作流拆分为搜索、分析、编码、修复、规划等多环节的场景。也适合希望隔离用户交互与执行层、降低主代理攻击面的安全敏感型应用。不适合需要主代理直接操作文件、或要求单任务原子性保障的场景。 使用风险 间接执行风险：子代理可能具备文件操作、代码执行等权限，需严格遵循最小权限原则配置。会话泄露风险：固定 sessionKey 长期复用，若平台未妥善隔离会话状态，可能导致数据交叉污染。调度盲区风险：子代理忙时自动跳过，极端情况下可能所有子代理均不可用，导致任务无限期挂起。版本兼容风险：子代理实现变更可能影响整体功能，缺乏版本协商机制。 原始说明 Multi-agent dispatcher skill. Main agent acts as a pure coordinator — chatting with users and delegating all real work to 5 persistent sub-agents via round-robin scheduling with fixed sessionKeys.