Problem / 问题
现状（依据 0.16.1 源码与 ADR）：
用户子智能体只存在于全局目录 ~/.agents/subagents/*.md，ADR 0112 明确 "There is no project-level subagent directory"；定义进入会话委派目录后，父智能体按名字+描述选择，可见性控制只有全局启用开关与按项目禁用覆盖（ADR 0270/0112）。
对比之下，skills / MCP / 插件自 ADR 0056（D192）起就有“全局或限定项目”的激活作用域——唯独子智能体没有等价机制。
模型侧有 availableForSubagents opt-in（subagent-model-opt-in ADR），但它管的是模型授权，不是智能体可见性，解决不了这个问题。
痛点：专职型子智能体会泄漏到所有会话的委派目录。实际用例：我在做一个多智能体审议类插件（cabinet），为它配了 5 个专职辩手子智能体——不同 provider 家族钉扎（对冲同源趋同）、辩论人格、只读工具面。它们只应在插件驱动的议事流程中被委派；目前唯一手段是在 description 里写负向排除句（“仅限 xx 流程，其他任务请选用其他智能体”），这是软隔离——父模型多数时候会绕开，但没有硬保证；按项目禁用是逐项目手动 kill-switch，项目多了不可维护，而且方向反了（我需要的是“仅在 X 可见”，不是“在 Y/Z/…逐个禁用”）。
Proposed change / 期望改动
主诉求：给用户子智能体增加激活作用域，对齐 D192 对 skills/MCP 的先例。 形态建议（择一或组合）：
frontmatter 字段：scope: global | projects: [...]，进一步可支持 activation: plugin:（仅当指定插件启用时进入委派目录）；
或设置 UI 中的 per-agent visibility（与现有按项目启停覆盖合并为一张作用域表）。
兼容性：缺省 scope: global，现有文档行为完全不变。
关联方向（可选、可拆另开 issue）：manifest 增加 contributes.subagents 贡献点，让插件随包分发子智能体定义。已知难点需项目先定：模型钉扎引用用户凭据——可选解法是贡献的定义不带 pin、由用户在启用时绑定，或定义仅在插件获相应权限时进入目录。
Alternatives / 其他方案
description 负向排除句（当前采用）：零成本软隔离，实测有效但无硬保证，且防不住“无更优匹配时被兜底选中”；
按项目禁用覆盖：硬但反向，逐项目手动，数量增长后不可维护；
命名前缀约定（如 cabinet-*）：只降低匹配概率，同样是软的。
Additional context / 补充信息
用例背景：cabinet 内阁议事插件（本地开发中）——父智能体统筹 4–6 个异质立场子智能体辩论、交叉质询、合议；专职班子含攻击手/证据官/落地官/长期席/读者代理五气质，钉扎不同 provider 家族。两场真实运行（standard→advanced 5 席×2 轮）验证了“混编经智能体默认模型实现”是实际起作用的机制，也是这批专职定义存在的原因。
相关 ADR：0056（extension activation scope / D192）、0112（capability roots；"no project-level subagent directory"）、0270（builtin subagents can be disabled）、subagent-model-opt-in（模型授权 ≠ 智能体可见性）。
若维护者认为两个诉求应拆分：activation scope 为本 issue 主诉求，contributes.subagents 可另开。
Problem / 问题
现状（依据 0.16.1 源码与 ADR）：
用户子智能体只存在于全局目录 ~/.agents/subagents/*.md，ADR 0112 明确 "There is no project-level subagent directory"；定义进入会话委派目录后，父智能体按名字+描述选择，可见性控制只有全局启用开关与按项目禁用覆盖（ADR 0270/0112）。
对比之下，skills / MCP / 插件自 ADR 0056（D192）起就有“全局或限定项目”的激活作用域——唯独子智能体没有等价机制。
模型侧有 availableForSubagents opt-in（subagent-model-opt-in ADR），但它管的是模型授权，不是智能体可见性，解决不了这个问题。
痛点：专职型子智能体会泄漏到所有会话的委派目录。实际用例：我在做一个多智能体审议类插件（cabinet），为它配了 5 个专职辩手子智能体——不同 provider 家族钉扎（对冲同源趋同）、辩论人格、只读工具面。它们只应在插件驱动的议事流程中被委派；目前唯一手段是在 description 里写负向排除句（“仅限 xx 流程，其他任务请选用其他智能体”），这是软隔离——父模型多数时候会绕开，但没有硬保证；按项目禁用是逐项目手动 kill-switch，项目多了不可维护，而且方向反了（我需要的是“仅在 X 可见”，不是“在 Y/Z/…逐个禁用”）。
Proposed change / 期望改动
主诉求：给用户子智能体增加激活作用域，对齐 D192 对 skills/MCP 的先例。 形态建议（择一或组合）：
frontmatter 字段：scope: global | projects: [...]，进一步可支持 activation: plugin:（仅当指定插件启用时进入委派目录）；
或设置 UI 中的 per-agent visibility（与现有按项目启停覆盖合并为一张作用域表）。
兼容性：缺省 scope: global，现有文档行为完全不变。
关联方向（可选、可拆另开 issue）：manifest 增加 contributes.subagents 贡献点，让插件随包分发子智能体定义。已知难点需项目先定：模型钉扎引用用户凭据——可选解法是贡献的定义不带 pin、由用户在启用时绑定，或定义仅在插件获相应权限时进入目录。
Alternatives / 其他方案
description 负向排除句（当前采用）：零成本软隔离，实测有效但无硬保证，且防不住“无更优匹配时被兜底选中”；
按项目禁用覆盖：硬但反向，逐项目手动，数量增长后不可维护；
命名前缀约定（如 cabinet-*）：只降低匹配概率，同样是软的。
Additional context / 补充信息
用例背景：cabinet 内阁议事插件（本地开发中）——父智能体统筹 4–6 个异质立场子智能体辩论、交叉质询、合议；专职班子含攻击手/证据官/落地官/长期席/读者代理五气质，钉扎不同 provider 家族。两场真实运行（standard→advanced 5 席×2 轮）验证了“混编经智能体默认模型实现”是实际起作用的机制，也是这批专职定义存在的原因。
相关 ADR：0056（extension activation scope / D192）、0112（capability roots；"no project-level subagent directory"）、0270（builtin subagents can be disabled）、subagent-model-opt-in（模型授权 ≠ 智能体可见性）。
若维护者认为两个诉求应拆分：activation scope 为本 issue 主诉求，contributes.subagents 可另开。