自定义 Subagent 并非越多越好。它的价值在于通过固化特定的角色、规则与权限边界，来处理那些高频出现且需要并行协作的专项任务。

判断准则：是否值得自定义？

仅当以下条件满足两条以上时，建议考虑自定义：

  1. 高频重复：该角色在每周的任务流中都会被多次调度。

    2. 2. 职责单一且稳定：该角色有非常明确的审查或分析清单。

    3. 特定运行环境：需要独立于主会话的模型配置、推理强度或沙盒边界。

    4. 输出格式固定：需要长期保持一致的结构化汇报结果。

    推荐自定义的场景示例

    1. 风险审查员 (risk-reviewer)

    • 价值：每次 PR 或大改后都需要审查范围失控、回归风险与交付说明。
    • 特点：严格只读，专注于质量把关。

    2. 测试缺口分析员 (test-gap-reviewer)

    • 价值：确保新增功能均有对应的测试覆盖。
    • 特点：并行扫描业务代码与测试文件的对应关系。

    3. 安全合规专家 (security-expert)

    • 价值：查找潜在的密钥泄露、注入风险及越权漏洞。
    • 特点：拥有特定的安全扫描规则集，不干扰主业务逻辑。

    不建议自定义的场景

    • 一次性探索：偶尔需要分析一下项目结构，直接用普通提示词拆分任务即可。
    • 模糊的全能角色：创建一个“资深工程师”代理，由于边界不清，往往会与主会话产生职责重叠。
    • 并行写代码：在未解决冲突控制前，禁止自定义代理自动并行修改文件。

    与其他能力的区别

    • VS Skill：Skill 是“任务说明书”，教 Codex 怎么做；Subagent 是“固定岗位”，负责分头去做。
    • VS AGENTS.md：AGENTS.md 是项目全员准则；Subagent 是特定并行角色的个人守则。

    总结

    自定义 Subagent 应被视为一种“工程化沉淀”。先用普通提示词跑通流程，总结出稳定的角色行为后，再通过 TOML 配置文件将其固化为项目的一项基础能力。