將工作委派給代理

本指南說明如何把工作從你手上交出去、交給代理，以及代理彼此傳遞工作時會發生什麼事。

把工單交給代理

建立工單，並填寫足夠精確、可供依循的標題與描述。
將其負責人設為該代理，讓擁有權留下紀錄。
開啟（或建立）一個空間，並 @提及該代理。
在訊息中以 # 提及來引用該工單——輸入區會自動完成工作區的工單——並說明你想完成什麼。

代理會從對話中接起這項工作。它的進度會串流到該空間。

代理會收到什麼

你的訊息，包括你標記的工單引用。
用來工作和回報的空間。
從工作區已連結的儲存庫取得的隔離工作樹。
該空間的模式，這正是決定該次執行工具介面的依據。

模式是空間的屬性，而不是工單的屬性——工單沒有模式。因此同一個代理可以在一個空間中處於 chat，在另一個空間中處於 plan。請從輸入區的模式下拉式選單選擇（Agent、Plan 或 Orchestrate）；review 是由 PR 審查空間設定的，無法選取。請參閱模式。

要求結構化的結果

輸出契約是在派送上宣告的，而不是在工單上：expected_output_schema 加上 output_contract_mode（預設為嚴格）。代理藉由呼叫 submit_output 來滿足它，該呼叫會依綱要驗證承載內容，並拒絕不符者。

獲接受的輸出與任何拒絕都會記在代理執行紀錄上。工單本身的狀態不受此影響——契約失敗並不會讓工單失敗。

監控進度

空間——即時代理活動，主要的檢視畫面。
工單——其狀態，由移動它的人設定。
可觀測性 → 即時（/workspaces/<workspace-id>/observability）——即時代理名冊。
可觀測性 → 洞察——執行紀錄，包含成本與持續時間。

沒有儀表板畫面；單純的工作區 URL 會重新導向到收件匣。

讓代理互相委派

遇到子問題的代理會使用 delegate_task MCP 工具進行委派。它會建立一張指派給另一個代理的子工單，並且——當你傳入 parent_ticket_id 時——記錄該鏈結，讓護欄能看到它。

兩道結構性護欄一律會在工單關卡執行，絕不靠提示指令：

深度上限——深度超過 3 跳的鏈結會遭到拒絕。
循環偵測——跳回鏈結中已存在的代理會遭到拒絕。

當你傳入 from_agent_id 時，會再執行兩道護欄（正式環境一律會提供解析器埠）：

自主程度上限——被委派者在該空間中的有效層級不得超過委派者。
預算額度——委派會計入委派者剩餘的硬性停止預算，且無法再增發。沒有原則，或採無限制的原則，都會通過。

拒絕會明確發聲：工具會原封不動地回傳護欄的原因，因此發起委派的代理會看到確切原因。delegatedByAgentId 欄位會記錄是誰委派的，形成一棵委派樹。

這個委派深度上限 3，與內建執行框架的子代理巢狀上限 2 是不同的限制——一個限制的是代理之間的工單，另一個限制的是單次執行內的子代理。

讓多個代理處理同一張工單

將它們新增為工單上的協作者（角色：負責人、協作者、審查者）。那只是一份名冊——一份記錄誰參與其中的紀錄——本身不會授予任何權限。

若要真正把代理放進同一個對話中，請從空間標頭將它們新增為參與者。它們接著就能在那裡互相 @提及。請參閱空間。

自動建立工單

管線面板中沒有任何節點會建立工單，因此管線無法把工作展開成已指派的工單。

確實存在的途徑是編排：核准提案會建立專案與團隊，將提案的子工單 DAG 編譯成一份管線範本（每張子工單一個 promptAgent 步驟，而不是各建立一列 Ticket），並啟動該次執行。請參閱執行編排。