在多數智慧體 harness 中，subagents（子代理）已經是常見能力：主管代理可以把具體任務委託出去，讓子代理在獨立的上下文視窗裡工作。這樣做既能並行思考，也能避免把大量中間推理塞回主管的上下文。deepagents 團隊在博文中進一步提出：子代理並非只有“從零開始”這一種方式，還可以選擇是否繼承主管的對話歷史，這就是新的 context modes（上下文模式）。
目前支援的兩種模式分別對應兩類典型場景。isolated（隔離）是預設模式，子代理只收到主管下發的任務描述，在全新上下文中行動；fork（繼承）則會把主管代理當前的狀態傳播給子代理，相當於當前對話的一個分支繼續推進，最後再把結果作為一次工具呼叫的返回值交還給主管。fork 模式看起來會讓子代理拿到更多上下文，但實現上仍然考慮到了 prompt caching，因此當子代理確實需要掌握先前細節時，它往往比 isolated 更快、更便宜，也少做很多重複的上下文收集。
那麼應該如何取捨？文章用幾類常見子代理給出了判斷框架。像 worker 這樣負責“接著做”的代理適合 fork：主管已經定位問題、形成判斷，worker 可以直接基於這些上下文實現和測試修復，而不必重新讀檔案、重新追溯證據。相反，像 verifier 這樣負責“獨立評審”的代理適合 isolated：如果評審者繼承了主管的推理和預期，就容易失去獨立判斷，它更應該只拿到 diff 和評審標準。
除了這兩類，文章還展示了 researcher 與 memory agent。researcher 通常調研一個可以獨立成立的問題，用 isolated 可以避免多個並行研究者各自複製主管的完整歷史；memory agent 則要把對話中形成的決定、偏好和約束儲存下來，fork 模式能直接讓它看到完整互動，再挑選值得記憶的內容。
上下文模式並不是孤立存在的，它可以和 tools、middleware、permissions 等機制共同使用，把子代理打磨得更適合具體任務。例如 researcher 可以額外配備搜尋引擎工具，memory agent 則可以限制可讀寫路徑。對開發者而言，關鍵是思考子代理與當前工作的關係：是需要它繼續主管的工作，還是需要它獨立判斷。deepagents 已經可以透過 uv add deepagents 或 pnpm i deepagents 安裝體驗，官方也提供了文件和 GitHub、論壇、X / LinkedIn 等反饋渠道。