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