launch-sub-agent

launch-sub-agent 技能概述

launch-sub-agent 技能可以帮你把某个具体任务分派给一个聚焦的子代理，而不是把一个聊天线程塞得过满。它最适合正在构建或运行 launch-sub-agent for Multi-Agent Systems 模式下多步骤工作流的用户：例如编码、研究、评审、设计或验证这类任务，这些任务都受益于隔离上下文和有意选择模型。

launch-sub-agent 擅长什么

launch-sub-agent 技能的核心价值在于编排：它会分析任务，选择合适的模型档位，必要时匹配专门的 agent，然后在内置校验的前提下启动工作。相比通用提示词，它在你希望减少上下文污染、让输出更有纪律时更有用。

适合谁安装

如果你经常把工作拆成子任务、监督其他 agent，或者需要一种可重复的方法按复杂度分流任务，就应该安装 launch-sub-agent。它尤其适合已经在使用 agentic 工作流的团队，因为真正的问题往往不是“模型能不能答”，而是“怎么把任务路由清楚并验证结果”。

什么时候适合用

当输入可以被明确为一个有边界的任务时，launch-sub-agent 技能就很合适：实现一个功能、调查一个问题、比较方案、写文档或评审代码。对于模糊的头脑风暴、高度互动的协作，或者必须保留完整对话历史才能推进的任务，它就没那么有价值。

如何使用 launch-sub-agent 技能

安装并检查 launch-sub-agent 技能

先通过你的 skill manager 使用已发布的安装路径安装该技能，然后优先打开 SKILL.md。在这个仓库里没有需要浏览的 support folders，所以真正的权威来源就是 skill 文件本身。一个实用的 launch-sub-agent 安装流程是：安装、阅读 SKILL.md，然后把命令和参数模式适配到你的环境中。

把粗略目标转成可执行任务

这个技能在任务足够具体、可以直接分派时效果最好。好的输入会说明目标、预期输出、约束条件，以及相关的 repo 或环境细节。比如，不要写“修复 auth”，而应该写：Implement password reset for the existing Express app, preserve current API shape, and output a patch summary to docs/reset-plan.md。

提示词里要提供什么

launch-sub-agent 的使用模式需要一个任务描述，以及可选的路由提示，比如 --model、--agent 和 --output。只有在它们能增加清晰度时才使用这些参数。如果你已经知道任务很复杂，就选更强的模型；如果你知道子代理应该是专门化的，就明确指定；如果你需要把交付物保存到某个位置，就提前写明输出路径。

先读这些文件

先从 SKILL.md 开始，因为它定义了编排顺序、任务分析方式和验证要求。然后再查看任何解释周边 agent 系统的仓库级文档，尤其是在你把 launch-sub-agent 接入现有多代理系统时。如果你正在改造这个技能，要特别留意你自己的工具链是在哪里处理模型选择和 agent 命名的。

launch-sub-agent 技能 FAQ

launch-sub-agent 只适用于多代理系统吗？

它在多代理系统里最有价值，但你也可以把它当作一个更有纪律的子任务启动器，用在更简单的架构中。核心收益是一样的：launch-sub-agent 技能通过把一个任务隔离到一条聚焦的执行路径里，减少上下文杂讯。

它和普通提示词有什么不同？

普通提示词是在要一个答案。launch-sub-agent 技能更像一层路由：它会评估任务、选择执行策略，并加入自我审查步骤，让结果在返回前更有可能先被检查。这使得它在质量取决于流程、而不只是生成本身的时候更有用。

它适合新手吗？

适合，只要你能把任务说清楚。使用 launch-sub-agent 不要求你掌握所有 agentic 概念，但你必须说明工作内容、边界和期望输出。任务框定得越好，分派效果通常越好。

什么情况下不该用它？

如果任务很小、纯聊天式，或者高度依赖与同一上下文的持续来回互动，就不要用 launch-sub-agent。在这些情况下，直接提示词通常比启动子代理更快，也更不容易出问题。

如何改进 launch-sub-agent 技能

把任务简报写得更好

launch-sub-agent 最强的结果通常来自包含范围、约束和成功标准的简报。比如：Review this checkout flow for accessibility issues, focus on keyboard navigation and error states, and return prioritized fixes with code pointers 就比单纯的 review this flow 更可执行。

让模型匹配工作内容

如果你知道任务需要复杂推理、跨文件分析，或者对架构很敏感，就应该倾向更强的模型，而不是把选择留空。如果任务只是常规且范围很窄，就把请求写简单一些，让技能可以高效路由。好的 launch-sub-agent 用法不是一味拉满，而是让 agent 配置与任务规模匹配。

要求便于验证的输出

因为这个技能包含强制性的自我审查验证，所以要提出可以检查的输出：diff summary、assumptions、risks、edge cases，或者测试思路。如果你希望子代理第一次就有用，就要求它明确指出自己不确定的地方，以及下一步还需要验证什么。

第一次运行后继续迭代

把第一次结果用来收紧下一轮提示词。如果子代理范围太大，就缩小任务并加上明确边界；如果它遗漏了上下文，就附上相关文件或片段；如果它过度贴合了错误的 agent，就覆盖路由提示。提升 launch-sub-agent 技能结果最快的方法，是把每次运行都当成一次校准，而不是一次性答案。