把大問題切給一個新開的 agent

父 agent 的困境

想像你讓 Claude Code「去理解這個 10 萬行的 Rust 倉庫是怎麼處理並發的」。直覺做法：它自己 ls、cat、grep，在主 context 搜尋。

問題：這一圈探索會往 messages[] 裡堆 30 條 tool_result，每條幾千 token。等它真的開始寫答案時，上下文已經被探索過程塞滿——後面再做幾步就觸發上限，答得還亂。

s04 的解法：把探索任務丟給一個新 agent。新 agent 從 messages=[] 啟動，自己探自己的，最後只把 summary 回傳給父 agent。父的 context 只多了一條「調了一次 task 工具，結果是 XXX」，清爽。

def run_subagent(prompt: str) -> str:
    sub_messages = [{"role":"user", "content": prompt}]  # 全新 context
    for _ in range(30):  # 安全上限，防失控
        response = client.messages.create(..., messages=sub_messages, tools=CHILD_TOOLS, ...)
        ...
    # 只返回最后的文字，中间推理全部丢弃
    return "".join(b.text for b in response.content if hasattr(b, "text"))

父子 context 對比

這個 widget 模擬一個真實任務：「把這個倉庫裡所有呼叫 deprecated API 的地方列出來」。你可以用兩種策略跑：(A) 父 agent 自己做；(B) spawn 一個 subagent。左右比較最後兩個 context 的大小。

CHILD_TOOLS：子 agent 能拿到什麼工具

s04 的實作裡有個細節容易錯過：子 agent 拿不到 task 工具。

# 子 agent 只能用基础工具，不能再 spawn 孙子
CHILD_TOOLS = [bash, read_file, write_file, edit_file]

# 父 agent 多一个 task 工具
PARENT_TOOLS = CHILD_TOOLS + [task]

為什麼？避免遞歸派發變成樹狀爆炸。一個 subagent 再次 spawn 4 個 subsubagent，幾輪就幾十個並發調用，token 和 API 限速都扛不住。 s04 的約定：spawn 是扁平的，父→子一層就是一層。 Claude Code 真實實作裡也這樣－Task tool 裡禁止再調 Task tool。

看得到和看不到

權責整理一下：下面幾個問題，你覺得哪些 T、哪些 F？