跳到主要內容
NTPU AI Learn

AI 301 · 模組 3

Task Allocation、Delegation 與 Handoff

哪一個 Agent 應該負責下一個 Task？如何安全地把工作交出去？

開始第一節
  • 時長55 分鐘
  • 難度架構
  • 先備知識建議先完成 AI 301 單元 1 與 2，以及 AI 202
已完成 0 / 6
同步我的進度加入梯次後，進度可跨裝置保存，講師也能看到

資訊

加入後，你已完成的模組編號會連同「學員代碼」傳送給講師，講師可以看到你的進度。請使用講師提供的代碼，不要輸入姓名、公司機密或其他個資。進度資料與該梯次的其他資料一起保存。

學習目標

  • 區分 Static Assignment 與 Dynamic Assignment，並依 Capability 為 Task 找到合適的 Agent
  • 說明 Delegation 模型：辨識所需 Capability、選擇 Agent、連同 Context 與 Constraints 送出 Task、回傳結果、Evidence 與 Status
  • 寫出包含八個部分的 Handoff Contract
  • 說明 Ownership Transfer、Return Path、Completion Criteria 與 Escalation
  • 辨識常見失敗模式，例如 Handoff 不完整、Context 遺失、循環委派與未授權委派
  • 為每個 Task 判斷要保留、Delegate、平行處理或升級給人，並完成 Delegation & Handoff Map

問題與需求

8 分鐘

角色都定義好了，那下一個 Task 由誰做？

在單元 2 你為每個 Agent 定義了 Role、Capability 與 Responsibility Boundary。但角色卡並沒有說明某一個 Task 在某一刻該由哪個 Agent 接手，也沒有說明工作如何從一個 Agent 移到另一個。本單元的核心問題是：哪一個 Agent 應該負責下一個 Task？如何安全地把工作交出去？

工作情境（模擬）

某系辦用三個 Agent 處理活動報名的問題：Intake Agent、Policy Agent 與 Drafting Agent。一封詢問逾期報名的問題進來，Intake 只用一句「請確認」就轉給 Policy。Policy 不知道是哪個活動、哪個截止日、要什麼輸出，於是轉去請 Drafting 幫忙，Drafting 又把它退回給 Intake。兩天後仍然沒有人回覆，而且每個 Agent 都以為別人負責。

  • 有能力的 Agent 並不會自動決定誰該做這個 Task
  • 沒有 Context 的交接，接手的人必須重新摸索
  • 沒有明確的 Owner，每個人都以為別人在處理
  • Delegation 是設計決策，不能交給運氣

注意

把 Task 交出去，並不等於把結果的責任交出去。團隊產出的成果仍由人負責，Delegation 不應該讓人看不出是誰做了什麼決定。

重點: Role 說明誰「可以」做。Task Allocation、Delegation 與 Handoff 說明現在誰做，以及工作如何移動。

核心概念

9 分鐘

Task Allocation：Static、Dynamic 與 Capability Matching

Task Allocation 是決定哪個 Agent 接哪個 Task。基本上有兩種做法，兩者都要把 Task 與 Agent 實際具備的 Capability 對上。

Static Assignment

  • 事先把某類 Task 固定給某個 Agent，例如所有規定類問題都交給 Policy Agent
  • 可預測，也容易審查
  • Task 不符合常見模式時，可能不合適

Dynamic Assignment

  • 當下依 Task 與現況選擇 Agent
  • 適合多變的工作
  • 需要明確的選擇規則，否則選擇會變得隨意
分派 Task 前要檢查的事（模擬）
考量問題範例
Capability Matching這個 Agent 具備 Task 需要的 Capability 嗎？Drafting Agent 會寫文字，但無法確認規定
Priority相較其他 Task 有多緊急？截止日明天就到，所以先做
Dependencies有什麼必須先完成才能開始？要先完成 Policy 確認，才能起草回覆
BoundaryTask 在該 Agent 的 Responsibility Boundary 之內嗎？發出正式通知不在 Drafting Agent 的邊界內

資訊

Capability 不等於授權。即使某個 Agent 做得到，若 Task 超出單元 2 所定義的 Responsibility Boundary，它也不應該接手。
自我檢測

Task 很適合 Drafting Agent 的寫作能力，但「發送」屬於它邊界之外的正式通知。分派時應該怎麼做？

Task 很適合 Drafting Agent 的寫作能力，但「發送」屬於它邊界之外的正式通知。分派時應該怎麼做？

重點: 不論 Static 或 Dynamic，都要依 Capability、Priority、Dependencies 與 Boundary 來分派 Task。

9 分鐘

Delegation 模型

Delegation 是一個 Agent 請另一個 Agent 完成 Task 的一部分。安全的 Delegation 每次都走同一條路徑，並且以「附帶 Evidence 的結果」作結。

Delegation 模型
  1. Task：要完成的工作
  2. Identify Required Capability：需要什麼能力？
  3. Select Agent：選擇在邊界內具備該 Capability 的 Agent
  4. Send Task + Context + Constraints：給接手者所需的資訊
  5. Execute：接手者執行工作
  6. Return Result + Evidence + Status：回報做了什麼，以及如何知道

文字版說明：這個模型先單向進行再回傳。Task 先拆解為所需的 Capability，選出 Agent 後，連同 Context 與 Constraints 一起送出。接手者執行後，把結果連同 Evidence 與 Status 一起回傳，讓送出者可以檢查，而不是只能相信。

支撐 Delegation 的幾個概念
概念意義範例（模擬）
Completion Criteria接手者與送出者如何一致認定完成引用規定段落且在 150 字內的回覆草稿
Return Path完成後結果送到哪裡回到 Intake Agent，而不是別的 Agent
Status任務目前進度完成、部分完成、卡住，或需要人
Evidence支持結果的依據答案所依據的規定段落
自我檢測

為什麼 Delegation 模型以 Result + Evidence + Status 作結，而不只是回傳結果？

為什麼 Delegation 模型以 Result + Evidence + Status 作結，而不只是回傳結果？

重點: 送出 Task、Context 與 Constraints，並透過明確的 Return Path 取回結果、Evidence 與 Status。

9 分鐘

Handoff Contract 與 Ownership Transfer

Handoff 是工作從一個 Agent 交到另一個 Agent 的那一刻。Delegation 通常仍由送出者對整個 Task 負責；Handoff 則可能連 Ownership 也一併轉移，也就是接手者現在成為 Task 的 Owner。不論哪一種，都應該附上書面的 Contract，不要依賴送出者恰好記得什麼。

每次 Handoff 都應包含
部分內容範例（模擬）
task要完成什麼回答一則逾期報名的問題
objective為什麼重要、好的結果長什麼樣給學生清楚且正確的下一步
required context接手者必須知道什麼活動名稱、截止日、學生的問題
constraints接手者不可以做什麼不承諾例外；不直接聯絡學生
expected output結果的形式150 字以內的回覆草稿
evidence requirements結果必須有什麼支持引用所用的規定段落
completion status任務目前進度未開始、進行中、完成或卡住
unresolved issues仍未確定或未解決的事不確定該活動是否允許逾期報名

薄弱的 Handoff

  • 只有一句：「請確認」
  • 接手者必須猜測 Context
  • 沒有人知道現在誰是 Owner

清楚的 Handoff

  • 八個部分都寫明
  • 接手者不必回頭問就能開始
  • Ownership 與 Return Path 都明確
自我檢測

Handoff 寫了 task、expected output 與 constraints，卻漏掉 required context 與 unresolved issues。最可能的結果是什麼？

Handoff 寫了 task、expected output 與 constraints，卻漏掉 required context 與 unresolved issues。最可能的結果是什麼？

重點: Handoff Contract 有八個部分，讓接手者能開始工作，也讓大家知道誰是 Owner。

失敗模式與 Escalation

9 分鐘

失敗模式與 Escalation

Delegation 的失敗有可預期的模式。了解它們，才能把 Handoff 與周邊規則設計成能預防這些狀況。

常見失敗模式與簡單的防範（模擬）
失敗模式發生什麼事防範
Incomplete Handoff缺少關鍵部分，接手者只能猜使用八個部分的 Handoff Contract
Context Loss送出者知道的事沒有傳下去列出 required context 與 unresolved issues
Duplicated Work兩個 Agent 做了同一件事每個 Task 指定唯一的 Owner
Ambiguous Ownership每個 Agent 都以為別人負責寫明 Handoff 之後誰是 Owner
Circular DelegationA 交給 B，B 又交回 A定義 Return Path，以及誰可以再往下 Delegate
Endless BouncingTask 在 Agent 之間傳來傳去卻沒有進展限制 Handoff 次數，超過就 Escalate
Unauthorized DelegationAgent 把工作交給不被允許處理的對象定義誰可以 Delegate 給誰，以及哪些需要核准

Escalation 是這些情況的規劃出口。當 Task 卡住、有風險、超出邊界或一直來回傳遞時，就連同 Context 交給人，而不是繼續在 Agent 之間打轉。

資訊

Human-AI-Human：由人決定哪些可以 Delegate、哪些必須 Escalate，並對結果負責。本單元只教 Delegation 的設計。長時間流程如何持續執行與復原的基礎設施屬於另一門課（AI 302），這裡不涵蓋。
自我檢測

一個 Task 在三個 Agent 之間傳了四次，仍然沒有進展。哪個防範最合適？

一個 Task 在三個 Agent 之間傳了四次，仍然沒有進展。哪個防範最合適？

重點: 針對 Incomplete Handoff、Context Loss、Duplicated Work、Ambiguous Ownership、循環委派、Bouncing 與未授權委派做設計，並以 Escalation 作為出口。

實作與應用

11 分鐘

實作：Delegate or Keep？

活動 3 的名稱是 Delegate or Keep？請先看範例，再針對你自己的 Use Case 練習。請不要在這個練習中輸入真實的公司機密、客戶個人資料或任何未經授權的敏感資訊。

範例（模擬）。三個 Agent 組成的活動報名團隊
Task決定理由
讀取來信並辨識活動由目前的 Agent（Intake）保留在它的 Role 之內，不需要其他 Capability
確認逾期報名規定Delegate 給 Policy Agent需要 Intake 不具備的 Capability
同時確認截止日與回覆草稿的措辭平行處理這兩個 Task 互不依賴
核准截止日的例外升級給人有實際影響、不該由 Agent 決定的決策
  1. 列出 Task
    把你 Use Case 的主要 Task 一行一個寫下來。
  2. 為每個 Task 做決定
    擇一：由目前 Agent 保留、Delegate、平行處理，或升級給人，並寫下理由。
  3. 寫一份 Handoff
    針對一個被 Delegate 的 Task，填寫 Handoff Contract 的八個部分，並寫明 Return Path 與之後誰是 Owner。
  4. 檢查失敗模式
    標出可能發生循環委派、Context 遺失或未授權委派的位置，並加上防範或 Escalation 點。

資訊

成果：Delegation & Handoff Map，一張表，列出每個 Task、其決定（保留、Delegate、平行處理或升級）、接手者、被 Delegate 的 Task 的 Handoff Contract、Return Path 與 Escalation 點。它會成為你 Multi-Agent Architecture Canvas 的一部分。
自我檢測

某個 Task 需要一項可能影響真實人員的決策，而且不在任何 Agent 的邊界內。在 Delegate or Keep 中應選哪個？

某個 Task 需要一項可能影響真實人員的決策，而且不在任何 Agent 的邊界內。在 Delegate or Keep 中應選哪個？

重點: Human-AI-Human：由人定義哪些可以 Delegate、哪些要升級，Agent 執行清楚的 Handoff，人審查結果並負責。

另存 PDF

接下來做什麼？