跳到主要內容
NTPU AI Learn

AI 301 · 模組 2

Agent Roles 與 Responsibility Boundaries

多個 Agent 要如何分工，才不會每個 Agent 都做一樣的事？

開始第一節
  • 時長55 分鐘
  • 難度架構
  • 先備知識建議先完成 AI 301 模組 1；建議理解 AI 202 與 AI 201 的 Tool 與 Permission 概念
已完成 0 / 6
同步我的進度加入梯次後，進度可跨裝置保存，講師也能看到

資訊

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

學習目標

  • 說明 Role、Responsibility、Capability、Authority、Scope 與 Ownership，以及它們的差別
  • 描述責任重複（duplicated responsibility）的失敗模式及其影響
  • 完成一張包含十個欄位的 Agent Role Card，從 Role Name 到 Escalation Boundary
  • 為一個 Role 定義 Permission boundary、Input contract 與 Output contract
  • 辨識 Role overlap 與缺口，並運用 Domain specialization 與 Separation of duties
  • 為自己的使用案例設計 3 到 5 個候選 Role，並用模擬資料產出 Agent Role Cards

問題與需求

8 分鐘

當每個 Agent 都做一樣的事

在模組 1 中，你判斷了一個任務值得用多個 Agent。現在困難的部分開始了：分工。把任務拆給多個 Agent 還不夠，每個 Agent 都必須知道自己是做什麼的，也知道自己不做什麼。核心問題是：多個 Agent 要如何分工，才不會每個 Agent 都做一樣的事？

工作情境（模擬）

三個 Agent 都被告知：「協助準備計畫申請書。」三個都去讀了經費來源的規定。其中兩個各自編了一份預算，兩份預算對不起來。第三個把另一個剛完成的說明文字重寫了一遍。沒有人檢查截止日期，因為每個 Agent 都以為別人會做。等到需要最終版本時，沒有人知道哪一份才是。

  • 重複的工作：同一件事被做了兩三遍
  • 互相衝突的產出：兩個 Agent 給出不同答案，而沒有人擁有決定權
  • 缺口：大家都以為別人會做的工作，最後沒有人做
  • 課責不清：出事時，沒有人說得出是誰的責任

注意

Agent 不會靠互相交談來化解模糊的 Role，通常只會變成每個都做一點所有事。清楚的 Role 是人在任何 Agent 執行之前就做好的設計決定。

重點: 一群 Agent 要能運作，每個 Agent 都要有清楚的工作。模糊的 Role 會造成重複工作、衝突與缺口。

核心概念

9 分鐘

Role、Responsibility、Capability、Authority 與 Scope

六個詞彙描述工作如何分配。人們常常把它們混在一起，而這些混淆正是多數 Role 設計問題的來源，所以請把每一個分清楚。

六個詞彙，以模擬的計畫申請書團隊說明
詞彙它回答的問題範例
Role這個 Agent 在團隊中是什麼角色？Compliance Reviewer（法規遵循審查者）
Responsibility這個 Agent 必須確保什麼事被完成？對照每一條經費來源的規定檢查申請書，並回報每個缺漏
Capability這個 Agent 能夠做什麼？讀取規定、比對文字與規定、產出檢核表
Authority這個 Agent 被允許決定或更改什麼？可以把某項標為不合規；不可以修改或核可申請書
Scope哪些任務、資料與情況屬於這個 Role，哪些不屬於？只處理經費來源的規定與目前的申請書；不處理預算計算
Ownership某個結果由誰負責？Compliance Reviewer 負責法規遵循報告；最終送件由一位指定的人負責

Capability：能做什麼

  • 由 Tool、知識與指示決定
  • 是關於 Agent 的技術事實
  • 可能比適當的範圍更廣

Authority：被允許做什麼

  • 由人作為設計決定來設定
  • 是關於什麼被允許的規則
  • 不應比 Role 所需的更寬

資訊

Agent 可能做得到某件事，卻不應被允許去做。Capability 不等於許可。Role 設計決定的是 Authority，而在出錯代價高的地方，Authority 應該比 Capability 更窄。
自我檢測

某個 Agent 有電子郵件 Tool，技術上可以寄訊息給供應商，但團隊決定沒有人核可就絕不能寄出任何東西。這個決定是什麼？

某個 Agent 有電子郵件 Tool，技術上可以寄訊息給供應商，但團隊決定沒有人核可就絕不能寄出任何東西。這個決定是什麼？

重點: Role 說明工作，Responsibility 說明成果，Capability 是能做什麼，Authority 是可以做什麼，Scope 是 Role 從哪裡開始、到哪裡結束。

10 分鐘

Agent Role Card

要讓 Role 具體，就把它寫在一張卡片上。Agent Role Card 有十個欄位，從 Role 是什麼、用什麼，一路寫到何時必須停下來交還給人。

Agent Role Card 的十個欄位
  1. Role Name：這份工作的簡短名稱
  2. Purpose：這個 Role 為什麼存在
  3. Responsibilities：它必須確保什麼事被完成
  4. Capabilities：它能做什麼
  5. Knowledge：它需要知道什麼
  6. Tools：它可以使用什麼
  7. Permissions：它被允許讀取、更改或寄出什麼
  8. Inputs：它從誰那裡接收什麼
  9. Outputs：它回傳什麼給誰
  10. Escalation Boundary：何時必須停下來，把決定交給人

文字版說明：這張卡片由上往下閱讀。先寫 Role 的名稱與目的，接著列出 Responsibilities、Capabilities、Knowledge 與 Tools，再說明 Permissions、Inputs 與 Outputs。最後是 Escalation Boundary，也就是 Agent 停下來、把決定交給人的那個點。

範例卡片（模擬）：Compliance Reviewer
欄位內容
Role NameCompliance Reviewer
Purpose在人審閱之前，確保申請書符合經費來源的規定
Responsibilities檢查每一條規定；列出每個缺漏與所違反的規定
Capabilities讀取規定與文字；比對兩者；產出檢核表
Knowledge經費來源的規定與申請書範本
Tools只有文件閱讀器
Permissions可讀取規定與草稿；不可編輯、不可寄出
Inputs由 Coordinator 提供的申請書草稿與規定文件
Outputs附有來源的法規遵循檢核表，回傳給 Coordinator
Escalation Boundary若規定不明確或兩條規定互相衝突，就停下來詢問人
自我檢測

Agent Role Card 的哪一個欄位說明 Agent 何時必須停下來，把決定交給人？

Agent Role Card 的哪一個欄位說明 Agent 何時必須停下來，把決定交給人？

重點: 每個 Role 一張卡片，十個欄位，從 Role Name 到 Escalation Boundary。若某個欄位很難填，代表這個 Role 還不夠清楚。

9 分鐘

Permission boundary 與 Contract

Role 要有用，邊緣就要清楚。三個概念定義邊緣：Permission boundary 決定 Role 可以碰什麼，Input contract 與 Output contract 則決定什麼進來、什麼出去。

邊界與 Contract（模擬範例）
概念意思範例
Permission boundaryRole 可以讀取、更改或寄出什麼的界線Budget Drafter 可讀取成本表，但不能送出任何東西
Input contractRole 開始之前必須以什麼形式收到什麼已確認的成本清單與經費來源的預算規定；若缺漏，Role 會詢問而不是猜測
Output contractRole 必須以什麼形式、附上什麼證據回傳什麼每一行都有來源的預算表，加上假設清單
Escalation BoundaryRole 必須交還給人的情況成本超過上限；兩條規定互相衝突
  • 給每個 Role 剛好足以完成工作的最小權限
  • 沒有 Input contract 的 Role 會去猜，而猜測對下一個 Agent 來說看起來像事實
  • 沒有證據的 Output，下一個 Role 或人都無法檢查
  • 若某個 Role 只在緊急時才能做某件事，那是 Escalation，不是 Permission

資訊

Tool 與 Permission 的技術在 AI 201 涵蓋，Agent 之間確切的訊息格式則在本課程後面的模組。這裡的目標只是決定每個 Role 可以碰什麼，以及必須接收與回傳什麼。
自我檢測

Budget Drafter Agent 回傳一張沒有來源也沒有假設的數字表。它的 Role 設計缺少了哪一部分？

Budget Drafter Agent 回傳一張沒有來源也沒有假設的數字表。它的 Role 設計缺少了哪一部分？

重點: 定義每個 Role 可以碰什麼、必須接收什麼、必須回傳什麼，以及何時必須停下來交還給人。

重疊與分離

9 分鐘

Role overlap、缺口與 Separation of duties

有了候選 Role 之後，要讓它們互相檢驗。最常出現兩個問題：Role overlap，也就是兩個 Role 認領同一件工作；以及缺口，也就是沒有人擁有那件工作。

Role overlap

  • 兩個 Role 都起草，或都決定同一件事
  • 結果互相衝突，沒有人擁有最終決定
  • 解法：把 Responsibility 交給剛好一個 Role，另一個 Role 使用它的 Output

缺口

  • 必要的工作沒有出現在任何 Role 中
  • 每個 Agent 都以為別人在做
  • 解法：把工作加到某個 Role，或新增一個 Role，並指定負責人
三種分工方式（模擬範例）
依什麼切分意思範例
Domain specialization不同的專業知識法規規定、預算計算與說明撰寫是三個領域
工作階段流程中的不同時間點蒐集需求、起草、審查
風險與權限不同層級的許可或影響可以對團隊外寄出任何東西的 Role，與只負責起草的 Role 分開
  • Separation of duties：產出結果的 Role 不同時也是核可它的 Role
  • 一項 Responsibility，一位 Owner：共同的責任往往就是沒有人負責的責任
  • 寧可要少數清楚的 Role，也不要許多薄薄的 Role；每多一個 Role 就多一份 Coordination cost
  • 檢查每個重要成果：由哪個 Role 擁有，又由哪個 Role 或人來檢查？
自我檢測

兩個 Agent 都產出最終預算，而且版本不同。這是什麼問題？最好的解法是什麼？

兩個 Agent 都產出最終預算，而且版本不同。這是什麼問題？最好的解法是什麼？

重點: 讓 Role 互相檢驗：一項 Responsibility 一位 Owner、沒有缺口，而且生產者不同時也是核可者。

實作與應用

10 分鐘

實作：Design the Agent Team

活動 2 要你為一個複雜的使用案例設計 3 到 5 個候選 Role。先用範例練習，再對模組 1 選定的自己的使用案例做同樣的事。請勿在此練習中輸入真實的公司機密、客戶個人資料或任何未經授權的敏感資訊。

示範範例（模擬）：由四個 Role 組成的計畫申請書團隊
RoleResponsibilityPermissionsEscalation Boundary
Coordinator擁有計畫；把任務交給其他 Role，並收集它們的 Output可讀寫工作資料夾；不對團隊外寄出任何東西任何 Output 之間的衝突；任何要寄到外部的東西
Compliance Reviewer對照每一條經費來源的規定檢查草稿唯讀規定不明確或互相衝突
Budget Drafter依已確認的成本編列預算，每一行都附來源可讀取成本表；只能寫預算草稿成本超過上限；缺少成本項目
Narrative Drafter依已核可的事實撰寫計畫說明可讀取事實；只能寫說明草稿沒有來源的主張
  1. 列出 Responsibilities
    針對你的使用案例，寫下所有必須完成的工作。依領域、階段或風險，把它們歸成 3 到 5 個候選 Role。
  2. 為每個 Role 填一張 Agent Role Card
    完成從 Role Name 到 Escalation Boundary 的十個欄位。權限要維持在工作所允許的最小程度。
  3. 檢查重疊與缺口
    確認每項 Responsibility 剛好有一位 Owner，也沒有遺漏必要的工作。確保產出結果的 Role 不同時也是核可者。
  4. 標出需要人的地方
    註明哪些 Output 必須由人審閱，哪些決定屬於人，而不屬於任何 Agent。

資訊

交付成果：Agent Role Cards，每個候選 Role 一張，每張都有十個欄位。它們會成為你 Multi-Agent Architecture Canvas 的一部分。
自我檢測

哪一個敘述最能描述一組好的 Agent Role Cards？

哪一個敘述最能描述一組好的 Agent Role Cards？

重點: Human–AI–Human：人設計 Role 與邊界，Agent 執行各自的 Role，人審閱 Output 並對結果負責。

另存 PDF

接下來做什麼？