list
像看值班表：现在有几个小工在干活，编号分别是多少。
Tools 导读
Sub-Agents：让主 Agent 派后台分身干活，结果自动回传
Sub-agent 是从当前 agent run 派生的后台 run，独立 session，跑完后自动把结果 announce 回请求者的聊天频道。最该先看 `/subagents spawn` 命令和 `sessions_spawn` 工具的参数，尤其是 `mode`、`thread`、`cleanup` 的默认行为——`mode: "run"` 是一次性任务，`thread: true` 且 `mode` 省略时默认变成 `session`。注意 sub-agent 默认不继承 session tools，且每个 sub-agent 独立计费，建议给子任务配更便宜的模型。
先讲这一页到底在解决什么
Sub-Agents：让主 Agent 派后台分身干活，结果自动回传
Sub-agent 是从当前 agent run 派生的后台 run，独立 session，跑完后自动把结果 announce 回请求者的聊天频道。最该先看 `/subagents spawn` 命令和 `sessions_spawn` 工具的参数，尤其是 `mode`、`thread`、`cleanup` 的默认行为——`mode: "run"` 是一次性任务，`thread: true` 且 `mode` 省略时默认变成 `session`。注意 sub-agent 默认不继承 session tools，且每个 sub-agent 独立计费，建议给子任务配更便宜的模型。
第一站
🏗 先想画面：总工头把活拆出去，小工做完再回来汇报
官方开头那句最重要：sub-agent 是从现有 agent run 里“生出来”的后台 run。它有自己的 session，结束后会回到请求它的聊天里报一声。
🧑 主代理
像坐在前台接需求的总工头，负责和用户对话、决定要不要拆活。
🏃 子代理
像被派出去单独干活的小工。它拿着自己的任务单去忙，不会一直堵在主工头手边。
📣 announce
像小工干完后回前台交差，告诉总工头：我做完了、结果在这儿、花了多久、用了多少料。
⭐ 先记一句
Sub-agent 的重点不是“多一个回复框”，而是“把活拆到后台并行去做”。
第二站
🚀 /subagents spawn 其实就是“立刻派出去一个小工”
这页里最重要的命令就是 /subagents spawn。它的本质不复杂，复杂的是它后面那堆选项。
/subagents spawn <agentId> <task>像工头喊：“你，去干这件事。”命令一发出去，不会等小工当场干完，而是先立刻给你一个 run id。
为什么它是 non-blocking
因为主代理不能为了等一个慢任务，把前台窗口一直堵住。它先把小工派走，自己该接别的活还可以继续接。
--model / --thinking像给这个小工单独换一套脑子和思考档位。主工头用贵一点的大脑，小工可以换成便宜点的，也很正常。
📌 完成后会发生什么
小工不会默默消失。它会回来发一条“我干完了”的总结消息，告诉原来的聊天线程结果如何。
第三站
🛠 那一排命令，都可以翻成“工头怎么管小工”
官方给了很多 /subagents ... 子命令。别硬背，按动作来记就很顺。
log
像翻这个小工的施工日志，看看它一路上做了什么。
info
像看它的工牌详情：状态、开始时间、会话 id、清理策略都在上面。
send / steer
像工头又补了一句新指令。steer 更像“立刻调头，按我现在说的走”。
第四站
🧵 thread-bound sessions 在讲“能不能把一整个聊天线程绑给某个小工”
这段最容易写得像术语堆。翻成人话，就是：有些平台上，你可以把一个聊天线程长期交给某个子代理接手。
thread: true像不是只派小工出去做一次活，而是顺手给它分了一间固定小办公室，后面这个线程里的消息都继续送到它手上。
/focus像把当前线程和某个小工手里的办公室门牌绑起来。以后你在这个线程继续说话，就会继续叫到它。
/unfocus像把这根线剪开，让这个线程不再固定跟着某个子代理走。
📌 目前谁支持
官方这版写得很清楚：现在真正支持持久线程绑定的，主要就是 Discord。
第五站
🧠 子代理为什么会单独花钱、单独吃上下文
这是很多人第一次用 sub-agents 最容易忽视的点。官方特地提醒，是因为它真的会影响成本和设计。
💸 单独账单
每个子代理都像单独开了一台小脑子。它有自己的 token 使用量，所以“多叫几个小工”不是白来的。
📚 单独上下文
它不是直接共享主代理脑袋里所有细节，而是带着自己的会话去干活。所以有时需要你把任务描述得更明确。
💡 为什么建议给小工换便宜模型
因为重复调研、慢工具探路这类活，常常不用最贵那颗脑。让主工头保留高质量模型，小工用便宜点的，很合理。
🎈 一句话
子代理能并行提速，但也会单独消耗脑力预算。
第六站
🌲 Nested sub-agents 不是炫技，它是在讲“工头下面还能不能再有小工头”
默认情况下，小工不能继续再招人。官方把默认值设成 maxSpawnDepth: 1，就是为了别让整个工地自己长疯。
maxSpawnDepth: 1像只有总工头能派工，小工自己不能再招人。这是默认最稳的状态。
maxSpawnDepth: 2像你允许一级小工再当一次小工头，下面再拆给更细的小工。这就是官方说的 orchestrator pattern。
📉 为什么还要限并发和孩子数量
因为不设上限，小工头一兴奋，可能一下子放出一大群小工，把整台机器挤满。
🧵 结果怎么往回传
深层小工先把结果交给上一层小工头，再一层层往上报，最后才回到最前台。它像工地逐级汇报，不是所有人一起冲到老板脸上说。
第七站
🛑 stop、kill、cleanup 都是在管“活停了以后，现场怎么收”
官方后面这部分很实用，因为真实世界里任务经常要被取消，或者做完后得收尾。
/stop像前台喊全场暂停。它不只停主代理，也会把它派出去、还在跑的子代理一起叫停。
/subagents kill <id>像精准停掉某一个小工，如果它下面还有自己的小工，也会跟着一起停。
cleanup: \"delete\"像这个小工回来交差后，立刻收工位、关办公室。但官方也提醒，记录不会完全消失，而是被改名归档。
⏰ auto-archive
像小工下班太久后，系统会自动把这张工位卡收起来。只是如果网关重启，正在等下班计时的闹钟可能会丢。
第八站
🔐 Tool policy 那段的核心，是“别让小工天生就能碰所有后台总开关”
官方默认不给子代理 session tools 和 system tools，这个设计其实很有味道。
🧰 默认不给的工具
像 sessions_spawn、sessions_send 这些“能改调度秩序”的工具，默认不会发给普通子代理。因为小工的职责是干活，不是改工地规则。
🏖 sandbox
如果主会话本来就在沙箱里，官方还会防止你把活拆给一个没有围栏的小工，避免安全级别悄悄变低。
🚦 dedicated lane
Sub-agents 还有自己的并发车道 subagent。像工地专门给小工开了一条施工通道，避免把前台也堵死。
🎈 最后一收
Sub-agents 这页的主线其实很简单：主代理派小工分头干活，小工各自独立、各自记账、做完回来汇报；而所有那些配置项，都是在回答“最多派几个、能派多深、谁能停、停后怎么收”。