subagent-split-check 是一份用于多代理系统设计的决策清单，核心用途是回答一个问题：某项工作应该交给子代理处理，还是留在主代理循环中继续执行。
该技能的核心立场是：子代理是管理上下文的工具，而不是划分职责范围的手段。默认做法是使用一个主循环，并按需加载技能；只有当下列条件之一明确满足时才考虑拆分。
一、是否存在上下文层面的拆分理由 只有当至少一项为真时才值得考虑拆分：一是可测量的退化，即单一循环因上下文增长而明显变差，且“可测量”指评估结果而非感觉；二是可并行且可丢弃的工作，即多块工作可并行运行、各自需要干净上下文、完成后即可丢弃（例如独立研究线程）；三是工具或指令冲突，即主代理反复选错工具，或其指令之间相互冲突。随后还需回答一个针对具体步骤的决定性问题：后续是否需要原始的中间输出，还是只需要一个结论？只有“仅需结论”的工作才适合交给子代理。如果拆分理由是“这属于另一个团队”或“这是另一类问题”，则不应拆分，因为那会导致代理之间有损的交接。
二、若拆分，应沿上下文边界切割 子任务应几乎不依赖系统其余部分，并返回紧凑结果（一个判定、一个列表、一个小型结构化对象）。好的例子包括：独立研究线程、具有清晰接口的组件、黑盒验证步骤。应把子代理以工具的形式暴露给主代理，让主代理保持与用户的对话；只有当子代理确实需要直接与用户交流时，才移交整个对话。
三、拆分前先检查更廉价的修复方式 工具太多时，可按用户意图合并工具，并将少用工具置于工具搜索之后（参见 tool-budget-audit）。提示词太大时，可将流程与规则转为技能、将动作与实时数据转为工具、将参考资料转为按需加载的内容。担心丢失状态时，可将计划、决策与评审结论写入设计或进度文档（参见 handoff-doc）；状态一旦落到文件，会话便可安全清空，“为保护上下文而拆分”的冲动大多会消失。
四、将已有子代理合并回来 若系统已有大量子代理：先构建一个小型端到端评估，少量黄金样例即可起步；优先合并最常用、耦合最紧的子代理（背靠背调用、读写同一数据或互为输入输出）；过渡期间将剩余子代理包装为主代理的工具，同时获得基线；逐个合并，其提示词转为技能、API 调用转为工具；对比前后效果，关注哪些任务发生翻转而不仅是总分，并对每个任务多次运行；只有当合并版本可测量地变差时才保留该子代理。测量纪律可参考 harness-experiment。
输出要求：回答应包含拆分还是保留在主循环、支撑该决定的条件（或“无满足条件”）、若拆分则边界在哪里，以及会用何种测量来确认。
该技能的适用场景为多代理系统设计、子代理创建前的决策以及既有子代理架构的简化评估。限制方面：资料未提供具体实现代码、安装方式或平台依赖；其效果依赖评估数据与测量纪律，资料未提供量化基准或价格信息。