子代理

在單一輪次中，Perch 可以將一部分工作交給子代理：一個目標範圍有限、擁有自己上下文與有限工具組的輔助代理。輔助代理會完成工作並傳回結論。Perch 則維持脈絡、做出決定並撰寫回答。

這是更大型模式的底層基本單元。一個子代理就是一個輔助代理。將它們規劃成團隊，分階段執行並互相檢查，就是 Flock。

為什麼要交出工作

最明顯的原因是速度，但它是最不重要的原因。真正的原因是上下文。

閱讀四十張發票會產生四十份工具結果。如果由 Perch 自己讀取，四十份結果都會進入對話，擠壓所有其他內容，包括你的原始問題。如果由子代理讀取，傳回的就只有它的發現。原始資料留在輔助代理的上下文中，主要對話則保持足夠清楚，可以對發現進行推理。

另有兩個重要原因：

• 獨立判斷。 根據來源審查草稿的檢查者，沒有花剛才十分鐘撰寫那份草稿。如果你不是設法繞過缺漏而寫出草稿的人，就更容易抓到缺少的引用。
• 真正的平行執行。 十二個供應商、十二個獨立問題，彼此不互相干擾。這些工作會同時執行，而不是一個接一個。

Perch 何時使用子代理

Perch 的判斷很簡單：這一部分能獨立處理，而且我只需要它的結論嗎？ 兩者都是，就交出去。任何一個不是，就留在主要循環中。

實際上包括：

• 跨多個檔案蒐集證據。 掃描資料夾、從一疊報表中擷取數字、梳理大型程式碼庫。
• 精確運算。 核對與總額計算，以沙箱中的實際分析執行，而不是用文字估算。
• 檢查已完成的工作。 根據草稿引用的來源重新閱讀，並回報哪些內容站不住腳。
• 獨立區塊。 對多個不同事物提出同一個問題。

它刻意不會交出以下工作：

• 任何需要對話的工作。 子代理看不到你的對話，也無法向你提問。如果工作需要其中任何一項，就留在主要循環中。
• 小型工作。 讀取單一檔案或快速編輯，交出去的成本比直接做更高。
• 交付與現實世界行動。 寄出電子郵件、建立文件、預約行事曆活動。草稿由 Perch 撰寫，因此也由 Perch 交付，並保留對先前每個步驟的了解。

選擇子代理使用的模型

在 Perch Desktop 上，輸入區的模型選單有一列 Sub-agents：Agents run on。保留 Inherit，輔助代理就會使用當輪的模型。選擇一個模型，Perch 建立的每個輔助代理就都會使用該模型，包括背景委派代理。

提供的模型與你可自行指定的模型相同，因此方案允許指定的模型，在這裡也都包含。使用指定名稱模型的代理，與其他手動指定的模型一樣計費；Inherit 則維持 Roost 路由。

有理由時，Perch 也可以在單一任務中為每個輔助代理分別選擇模型，因此有一種做法值得了解：讓不同模型檢查工作。 由撰寫草稿的模型審查自己的草稿，往往會同意自己。換另一個模型審查，就會顯現分歧。直接提出要求：

draft the summary, then have a different model verify it against the sources

如果你指定方案未包含的模型，Perch 會說明並停止，而不是悄悄使用另一個模型。

推理投入程度控制列決定它有多願意分工

輸入區的推理投入程度控制列，設定 Perch 在當輪投入多少心力，也包括它有多容易展開分工。

超出當輪的工作

子代理會在你等待的當輪中執行。如果工作長到你不想等待，/delegate 就會改將它交給背景代理，讓你能繼續輸入，完成後再將結果交給你審查。請見斜線指令。

上限

• 不允許遞迴。 子代理不能建立自己的子代理。每個輔助代理都會移除協調工具。
• 執行範圍明確。 每個輔助代理的步驟與工具呼叫次數都有上限，由 Perch 強制執行，而不是要求模型遵守。
• 如實回報結果。 無法讀取檔案的輔助代理，會將它回報為未讀取。部分結果會以部分結果傳回。
• 僅限 Perch Terminal。 子代理需要桌面應用程式與 CLI 才有的本機檔案存取權。網頁聊天以單次處理回答。

子代理所處的循環請見操作代理與代理。整個團隊如何規劃與驗證，請見 Flock。