复杂任务动态编排领队

解决了什么问题

当你把一个跨模块的全栈改造或高风险迁移任务直接丢给单线程的对话模型时，常会遇到两类典型瓶颈。一方面，单个上下文窗口被前后端代码、测试报告和架构审查等不同认知负载的日志塞满后，模型表现会显著下降；另一方面，不同专业维度的需求——例如迁移的可回滚性与接口安全性——极易因为缺乏独立的验收门而出现隐蔽缺陷。

agent-leader 不试图在单一上下文中硬抗所有信息。它负责识别复杂任务中的独立专业分支，并为每个分支生成专属的执行契约，在统一的生命周期管理下推进，避免主上下文被冗长的过程数据污染。

它如何运作

核心机制在于动态任务分解与严格的释放门。它按照一套七阶段的 SOP 执行：

• 任务分析与 SOP 构建：首先提取输入要素，随后判定是否存在两个以上的独立分支。若不存在，则直接拒绝编排，退化为单路径处理。
• 角色动态定义：leader 会根据具体节点的 coverage_requirements 动态生成系统提示词，而非套用固定的专家名单。每个子 Agent 仅接收当前节点所需的最小输入，禁止携带无关的上下文负载。
• 并行调度与交接验证：只有在确认节点间无数据依赖时，才会将它们并行启动。所有节点完成时，必须输出结构化的 handoff，涵盖证据、风险与覆盖度指标。
• 生命周期与状态释放：在执行真实调度前，leader 必须先验证运行时的生命周期操作。只有当一个 Agent 完成验收并产生包含 destroyed 等状态的可验证回执时，节点状态才会由 completed 转为 released，下游节点方可消费其交接物。

适用边界与注意点

该技能明确拒绝“万物皆可编排”的倾向。对于单一问答、单文件小改或仅存在一种专业维度且无独立下游产物的任务，它会直接跳过复杂的流程图生成，避免不必要的调度开销。

此外，红线约束贯穿整个生命周期。如果部分覆盖度数据无法获取（partial 或 unavailable），必须将其显式标记为待确认或返工项。在没有真实遥测数据的情况下，严禁对 Token 消耗或时延成本进行估算。只有当所有验证门通过且生命周期回执真实有效时，整个工作流才算正式交付。