跳到主要內容
NTPU AI Learn

AI 301 · 模組 5

Shared Context、Memory 與 Coordination

多個 Agent 應該共享所有資訊，還是每個 Agent 只看自己需要的 Context？

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

資訊

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

學習目標

  • 說明 Shared Context 與 Private Context 的差異，以及 Agent 團隊為什麼兩者都需要
  • 從概念上說明 Shared Memory、Local Memory、Shared Knowledge 與 Source of Truth
  • 運用擁有者、Access Control 與五類資訊來設定 Information Boundary
  • 辨識過時的 Shared Context，並說明 Context Freshness、Version Awareness 與 Synchronization
  • 說明 Coordination State 與 Consensus 概念，完成活動 5，並產出 Shared Context Map

Shared 與 Private Context

9 分鐘

全部共享，還是只共享需要的？

在單元 4，Agent 學會了互相傳訊息。現在出現更難的問題：Agent 之間應該共同持有哪些資訊？什麼都不共享的團隊無法合作；什麼都共享的團隊則會浪費力氣、洩漏資訊，也讓每個 Agent 淹沒在雜訊裡。

核心問題

多個 Agent 應該共享所有資訊，還是每個 Agent 只看自己需要的 Context？

關鍵詞彙
詞彙白話意思
Shared Context團隊中每個 Agent 都應該看得到的資訊，例如目標與已確認的事實
Private Context只屬於某一個 Agent 的資訊，因為只有它的角色需要
Information Boundary刻意畫出的界線，規定哪些資訊可以在 Agent 之間或傳給人類
Context Ownership負責維持某項資訊正確的那一個角色
模擬範例

一個模擬的客戶意見團隊有 Research Agent、Analysis Agent 與 Reporting Agent。三者都需要共同目標與已核准的來源清單。只有 Analysis Agent 需要它的原始工作筆記。只有人類審核者應該看到提到未解決客訴的草稿。

資訊

本單元維持在概念層次。我們設計什麼要共享、什麼要保持私有，但不建置儲存、Checkpoint 或 Recovery 系統，那些屬於 AI 302。

重點: Multi-Agent 團隊需要對「哪些共享、哪些私有」做出刻意的設計，而不是預設全部共享。

9 分鐘

Context 架構：共享、私有與界線

Context 架構從一個 Shared Goal 開始。其下有一份作為 Source of Truth 的 Shared Context。每個 Agent 則在旁邊保有自己的 Private Context。

Context 架構
  1. Shared Goal：每個 Agent 共同朝向的目的
  2. Shared Context / Source of Truth：已確認的事實、任務狀態與已核准的決定
  3. Agent A Private Context：只有 Agent A 的角色所需的內容
  4. Agent B Private Context：只有 Agent B 的角色所需的內容
  5. Agent C Private Context：只有 Agent C 的角色所需的內容

資訊

圖示的文字版：最上方是 Shared Goal。其下是一份作為 Source of Truth 的 Shared Context。從這份 Shared Context 分出三條線，分別通往 Agent A、Agent B 與 Agent C。三個 Agent 各自有自己的 Private Context，其他 Agent 預設看不到。
五類資訊
類別意思範例（模擬）
Shared Context團隊中每個 Agent 都可以看到並依賴目標、已核准的來源清單、報告大綱
Private Agent Context只有一個 Agent 看得到，因為只有它的角色需要Analysis Agent 的暫存計算
Shared Knowledge Source許多 Agent 讀取、但沒有誰把它當作工作狀態的參考資料政策手冊或產品常見問答
Human-only保留給人類查看與決定點名未解決客訴的草稿
Restricted未經明確核准，不得傳給任何 Agent個資、憑證、機密數字
自我檢測

某個 Agent 的粗略工作筆記只對它自己的步驟有用。它們應該放在哪裡？

某個 Agent 的粗略工作筆記只對它自己的步驟有用。它們應該放在哪裡？

重點: 共享目標與已確認的事實，讓角色專屬的工作內容保持私有，並替每項資訊分類。

Memory、Freshness 與 Synchronization

9 分鐘

Shared Memory、Source of Truth 與擁有者

Multi-Agent 團隊的 Memory 在概念上有兩種。Shared Memory 存放團隊共同同意或共同產出的內容。Local Memory 存放單一 Agent 為自己工作而想記住的內容。Shared Knowledge 又不一樣：它是許多 Agent 讀取的參考資料。

Memory 與 Knowledge 概念
概念誰使用設計問題
Shared Memory整個團隊團隊同意了什麼？誰可以修改？
Local Memory單一 Agent這個 Agent 需要記住哪些其他人不需要的事？
Shared Knowledge許多 Agent，唯讀哪些參考來源已核准給所有人使用？
Source of Truth整個團隊兩個 Agent 對事實看法不同時，以哪一份紀錄為準？
擁有者與 Access Control
問題設計規則
這項資訊誰擁有？恰好由一個角色擁有並維持正確
誰可以讀取？只有任務需要的角色
誰可以寫入或修改？通常是擁有者，或擁有者核准的角色
誰審核重要事實的變更？一個指定的角色；高影響事實則由人類審核

注意

兩個擁有者等於沒有擁有者。如果兩個 Agent 都能改寫同一個事實，最終一定會互相矛盾。每個共享事實要有一位擁有者與一份 Source of Truth。
自我檢測

為什麼每個共享事實都應該只有一位擁有者？

為什麼每個共享事實都應該只有一位擁有者？

重點: 區分 Shared Memory、Local Memory 與 Shared Knowledge，並讓每個共享事實只有一位擁有者與一份 Source of Truth。

9 分鐘

過時的 Context、Freshness 與 Synchronization

Shared Context 會隨時間改變。當一個 Agent 更新了某個事實，另一個 Agent 卻還在用舊版本，團隊就在依據過時的 Shared Context 工作。結果可能看起來很有把握，卻是錯的。

模擬範例

Research Agent 更新了已核准的來源清單，移除一個後來發現已過時的來源。Reporting Agent 仍持有較早的清單，在草稿中引用了那個來源。沒有哪個 Agent 單獨犯錯，只是兩者沒有同步。

降低過時 Context 的方法（僅概念）
想法白話意思
Context Freshness某項共享資訊有多新，以及它能被信任多久
Version Awareness每個共享事實帶有版本或時間，讓 Agent 能判斷自己持有的是否為舊副本
Context Synchronization事先規劃的時間點，讓 Agent 重新整理對 Shared Context 的認知
Change Notice用單元 4 的 Message Contract 發出的訊息，通知其他人某個共享事實已改變

資訊

這個想法的文字版：讀取 Shared Context 的 Agent 應該知道它有多舊。更改 Shared Context 的 Agent 應該通知其他人。在重要步驟之前設一個更新點，讓 Agent 把自己的版本與 Source of Truth 比對。

注意

邊界：這裡談的是為 Freshness 而設計。要建置儲存、Checkpoint 或 Recovery 機制來保證它，屬於 AI 302 的後續主題。
自我檢測

哪一種做法最能幫助 Agent 發覺自己用了過時的事實？

哪一種做法最能幫助 Agent 發覺自己用了過時的事實？

重點: 替共享事實附上版本或時間，事實改變時通知他人，並在重要步驟前更新。

Coordination、實作與成果

10 分鐘

Coordination State 與 Consensus 概念

除了事實之外，團隊還需要知道工作進行到哪裡。Coordination State 是共同的全貌：誰在做什麼、哪些步驟完成、哪些在等待。在這裡它是一種設計想法，不是資料庫結構。

Coordination State 可能呈現的內容（概念性）
項目回答的問題
Task Status哪些任務未開始、進行中或已完成？
Assignment現在每個任務由哪個角色負責？
Waiting On哪個任務或人類決定卡住了進度？
Decisions Made團隊已定案哪些選擇？由誰定案？
Open Questions哪些問題還沒決定？

有時各 Agent 的看法不同，團隊需要一個答案。Consensus 作為概念，是取得共同決定的規則。規則可以很簡單：擁有者決定、Supervisor 決定、多數審核者同意，或由人類決定。

Consensus 概念比較
做法優點注意事項
擁有者決定快速，責任明確單一 Agent 的盲點會變成整個團隊的盲點
多數審核者一個答案有多重檢查以相同方式建立的 Agent 可能重複同樣的錯誤
人類決定判斷與責任留在人身上較慢，因此保留給高影響的事項

注意

Agent 之間意見一致並不代表正確。對於高影響決定，人類仍然要審核並負起責任。
自我檢測

三個 Agent 對一個會影響客戶合約的答案意見一致。最安全的結論是什麼？

三個 Agent 對一個會影響客戶合約的答案意見一致。最安全的結論是什麼？

重點: Coordination State 呈現工作進度，Consensus 是取得單一答案的規則，高影響決定由人類負責。

9 分鐘

活動 5：Shared or Private? 與 Shared Context Map

拿一個模擬的 Multi-Agent 團隊，或你在單元 2 至 4 設計的團隊。把它的資訊分到五個類別，並決定每一項由誰擁有、誰可以看。

  1. 列出資訊
    寫下團隊使用或產出的 8 至 12 項資訊。
  2. 替每一項分類
    選一個：Shared Context、Private Agent Context、Shared Knowledge Source、Human-only 或 Restricted。
  3. 指定擁有者
    為每個共享項目寫下負責維持其正確的唯一角色。
  4. 設定存取與界線
    註記哪些角色可以讀取、哪些可以修改。
  5. 規劃 Freshness
    對每個共享項目，註記 Agent 如何得知它已改變，以及何時更新。

注意

隱私提醒：請使用模擬或已公開的資訊。請勿輸入公司機密、客戶個資或未經授權的敏感資訊。

資訊

成果：Shared Context Map。內容包括每項資訊的類別、擁有者、誰可讀取、誰可修改、Freshness 計畫，以及團隊追蹤的 Coordination State。請保留，稍後放進你的 Multi-Agent Architecture Canvas。
自我檢測

你的清單中有客戶的個人資料。它屬於哪一類？你該怎麼做？

你的清單中有客戶的個人資料。它屬於哪一類？你該怎麼做？

重點: 替每項資訊分類、指定擁有者、設定界線並規劃 Freshness，再記進你的 Shared Context Map。

另存 PDF

接下來做什麼？