將工作委派給代理
本指南說明如何把工作從你手上交到代理身上，以及代理互相傳遞工作時會發生甚麼事。
把工單交給代理
標題為「把工單交給代理」的章節- 建立工單，標題與描述要精確得足以據以工作。
- 把它的負責人設為該代理，讓擁有權留下記錄。
- 開啟（或建立）一個空間，並 @ 提及該代理。
- 在訊息中以
#提及來引用該工單——撰寫器會自動完成工作區工單——並說明你想完成甚麼。
代理會從對話中接起工作。它的進度會串流到該空間。
代理會收到甚麼
標題為「代理會收到甚麼」的章節- 你的訊息，包括你標註的工單參照。
- 用來工作和回報的空間。
- 來自工作區已連結程式庫的隔離 worktree。
- 該空間的模式，這正是管轄該次執行工具介面的東西。
模式是空間的屬性，而非工單的屬性——工單沒有模式。因此同一個代理可以在一個空間處於 chat，在另一個空間處於 plan。請從撰寫器的模式下拉選單中選擇（代理、計劃或編排）；review 由 PR 審查空間設定，無法自行選取。參見模式。
要求結構化結果
標題為「要求結構化結果」的章節輸出契約是在派發上宣告的，而非在工單上：expected_output_schema 加上 output_contract_mode（預設為嚴格）。代理透過呼叫 submit_output 來滿足它，該呼叫會根據綱要驗證內容，並拒絕不合規的內容。
獲接受的輸出與任何拒絕，都會記錄到代理執行紀錄上。工單本身的狀態不受影響——契約失敗不會令工單失敗。
監察進度
標題為「監察進度」的章節- 空間——代理的即時活動，主要檢視畫面。
- 工單——它的狀態，由推動它的人設定。
- 可觀測性 → 即時（
/workspaces/<workspace-id>/observability）——即時代理名冊。 - 可觀測性 → 洞察——執行紀錄，附帶成本與時長。
沒有儀表板畫面；單純的工作區網址會重新導向到收件箱。
讓代理互相委派
標題為「讓代理互相委派」的章節遇到子問題的代理會用 delegate_task MCP 工具作出委派。它會建立一張指派給另一個代理的子工單，並——當你傳入 parent_ticket_id 時——記錄該鏈，讓防護看得見。
有兩道結構性防護永遠會在工單關卡執行，絕不靠提示詞指示：
- 深度上限——鏈的深度超過 3 跳會被拒絕。
- 循環偵測——某一跳回到鏈中已有的代理會被拒絕。
當你傳入 from_agent_id 時，會再執行兩道防護（正式環境一律提供解析器連接埠）：
- 自主權上限——受委派者在該空間的有效自主程度不得高於委派者。
- 預算額度——委派會向委派者剩餘的硬性停止預算扣帳，無法額外增發。沒有任何政策，或政策不設上限者，都會通過。
拒絕會明確報錯：工具會原樣傳回防護的理由，讓委派的代理確切看到原因。delegatedByAgentId 欄位會記錄誰作出委派，形成委派樹。
這個 3 層的委派深度上限，與內建框架的 2 層子代理巢狀上限是不同的限制——一個界定代理之間的工單，另一個界定單次執行內的子代理。
在一張工單上安排多個代理
標題為「在一張工單上安排多個代理」的章節在工單上把他們加入為協作者（角色：負責人、協作者、檢閱者）。那只是一份名冊——記錄誰有參與——本身不授予任何權限。
如要真正把代理放進同一則對話，請從空間標頭把他們加入為參與者。他們之後就可以在那裏互相 @ 提及。參見空間。
自動建立工單
標題為「自動建立工單」的章節管線面板中沒有任何節點會建立工單，因此管線無法把工作分派成已指派的工單。
確實存在的路徑是編排：核准提案會建立一個項目和一個團隊，把提案的子工單 DAG 編譯成管線範本（每張子工單一個 promptAgent 步驟，而非各建一列 Ticket），然後開始該次執行。參見執行編排。