Sub-Agent

Properties2
tags狀態/草稿
aliasesSub-Agent, Sub Agent, 子代理人, 子 agent

閱讀時間約 7 分鐘

Sub-Agent

一句話定義

主 Agent 透過 spawn 工具動態產生的「子代理人」——sub-agent 與同一個 LLM 互動完成 subtask、用 return 回傳結論給主 agent；對主 agent 的 context 而言，整段 sub-agent 對話會被「壓縮」成 return 那句話——所以 sub-agent 在 Context-Engineering 視角下其實是一種自主壓縮機制。

核心要點

Spawn / Return 兩動作骨架

主 agent 的 context  ──── spawn(subtask) ────┐
                                              │
                                              ▼
                              ┌──────────────────────┐
                              │  sub-agent 自己的 ctx │
                              │  ↕ 與 LLM 多輪對話   │
                              │  ↕ 呼叫工具 / 觀察    │
                              │  → return("結論")    │
                              └─────────┬────────────┘
                                        │
主 agent 的 context  ◄──── 整段被「壓縮」成 return 那句話

Context 的鋸齒狀曲線（直觀圖）

李宏毅 引用某 sub-agent paper 的具體任務（複雜論文搜尋）跟蹤 context length：

context length
   │
   │       ╱╲          ╱╲
   │      ╱  ╲        ╱  ╲
   │    ╱     ╲     ╱     ╲ ─ return 後 context 被砍回主幹
   │  ╱        ╲   ╱
   │╱           ╲ ╱
   └────────────────────────────► time
       ↑      ↑          ↑
       spawn  return     spawn
  • 每次 spawn → 累積 → return → 砍一刀。
  • 若不用 sub-agent：context 會線性累積，paper 中的具體任務最終會破 100K token 上限。

關鍵紀律：Sub-Agent 能力不是天生，需 RL 訓練

  • LLM 天生不喜歡壓縮自己的記憶（多次 paper 反覆驗證）→ 預設行為下不會主動 spawn。
  • 單純 prompt 教不會——同篇 paper 試過硬是 prompt 模型用 spawn 工具，模型仍不穩定。
  • 解法：用 reinforcement learning fine-tune 模型，加上額外的 reward shaping：
    • 正向 reward：主任務最終答對。
    • 負向 reward 1：主幹 context 過長（逼 agent 不得不 spawn 來控制長度）。
    • 負向 reward 2：sub-agent 越界（如果 sub-agent 把整個任務都自己解掉，主 agent 就失去意義；要懲罰）。
  • 現況：Claude-Code 接 Claude 模型已具備產生 sub-agent 的能力，但這不是模型原生能力，是模型廠商在訓練流程中加入此能力。

有效性紀律：主 / 副 context 一樣 = 毫無意義

2026-05-02-Agent神文沒告訴你的事 補入的紀律——sub-agent 不是「架構裝飾」，加上去就成立；要實際做到信息範圍不同：

「如果 sub-agent 和頂層規劃者看到的上下文是一樣的，那這樣的 sub-agent 就完全沒有意義」——sub-agent 的本質是自主壓縮 + 上下文隔離：

  • 自主壓縮（vault 既有視角）：整段 sub-agent 對話被壓縮成 return 那句話 → 主 agent context 不背負中間細節
  • 上下文隔離（Context-Engineering 視角）：執行者只看到自己需要的那一小撮必要信息（如 design sub-agent 只看設計相關 / code sub-agent 只看代碼相關）→ 不同任務的信息不會相互污染上下文

反面後果：若主 / 副 ctx 一樣 → sub-agent 沒有壓縮也沒有隔離 → 只是多了一層 spawn / return 的 token 開銷，本來就是該被砍掉的架構裝飾。

對位時機觸發點：屬於 Agent複雜度演化 階段 4 才該引入；之前的階段（API Call / Workflow / 加工具）都沒有 sub-agent 必要。

與 Workflow / Agent 自主程度光譜的對位

Agent > 自主程度光譜（從固定到完全自主） 既有 7 級分類（Routing / Parallelization / Prompt-Chaining / Evaluator-Optimizer / Orchestrator-Workers / Agent）：

  • Sub-Agent 機制 ≈ Orchestrator-Workers 的動態子任務拆解延伸：但 Orchestrator-Workers 仍是 workflow（合成策略固定、worker 池有限），而 Sub-Agent 在 Agent 層中是「主 agent 動態決定 subtask + 動態決定要不要新開 sub-agent」——更靠近完全自主端。
  • 與 Sub-Agent vs Orchestrator-Workers 的差異：O-W 的 worker 通常無自主性（主端決定 subtask、worker 純執行）；sub-agent 自身仍可動態決定流程。

與其他概念的關係

  • 父概念：Context-Engineering——本頁是 context engineering 中「自主壓縮」F 變體；同類兄弟：LLM summary / observation masking / log 外掛 / AgentFold（自主 fold 工具）。
  • 上層工程化載體：Harness-Engineering——sub-agent 是 harness 在「控制行為（工作流程）」手段下的具體 pattern。
  • 訓練機制：Verbalized-Feedback 視角——sub-agent 的 RL 訓練是「任務 reward + 結構性 reward」的混合學習，與 Verbalized-Feedback 純文字 feedback 軸有別但精神類似。
  • 比喻對位：Lifelong-AI-Agent 的 記憶 整理機制——兩者都是 agent 對自己的 context 做「主動瘦身」的動作。
  • 代表 host：Claude-Code / OpenCode 都已內建 sub-agent 能力。

相關來源

備註

建頁理由：vault 既有 Orchestrator-Workers / Agent > 自主程度光譜（從固定到完全自主） 涵蓋了 multi-agent 結構分類，但都不直接命名「Sub-Agent 作為 context engineering 自主壓縮機制」這條視角；本概念在 Context-Engineering / Harness-Engineering / Agent 三 hub 都有實質意義，獨立成頁讓未來 multi-agent / agent2agent 議題 ingest 時有共同錨點。

未來累積方向：(a) AI Agent 系列 2/3 中可能涉及的 multi-agent 互動細節；(b) sub-agent 與 Agent2Agent 協議的關係（兩者一個是「主 agent 內部」、一個是「跨 agent」）；(c) sub-agent 的具體 RL 訓練流程；(d) sub-agent 越界的具體案例。

反向連結