跳到主要內容
NTPU AI Learn

AI 301 · 模組 4

Agent Communication 與 Message Contracts

Agent 之間應該交換什麼資訊？如何避免「聊天很多但協作很差」？

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

資訊

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

學習目標

  • 說明為什麼 Agent 需要 Structured Message，而不是自由聊天
  • 區分 Directed Message 與 Broadcast，並設定 Communication Boundaries
  • 說明八種概念性的訊息類型：task request、task result、status update、evidence、question、error、escalation 與 handoff
  • 寫出包含 Sender、Receiver、Type、Task、Context、Constraints、Evidence、Expected Response、Status 與 Version 的 Message Contract
  • 說明 Acknowledgement、Error 與 Escalation 訊息，以及各自的使用時機
  • 設計兩個 Agent 之間的 Agent Communication Contract

問題與需求

8 分鐘

聊天很多，協作很差

在單元 3 你設計了工作如何交接。交接本身仍然要以訊息的形式傳遞。本單元的核心問題是：Agent 之間應該交換什麼資訊？如何避免「聊天很多但協作很差」？

工作情境（模擬）

兩個 Agent 協助系辦規劃一場工作坊。Scheduling Agent 寫道：「星期四好像可以？」Venue Agent 回覆：「也許吧，看情況。」十二則訊息之後，雙方都沒有說明是哪間教室、哪個日期範圍、由誰決定。人來看紀錄，無法判斷是否有達成共識，也找不到誤會是從哪裡開始的。

  • 自由格式的訊息隱藏了「要求什麼」以及「期待收到什麼」
  • 交換很長，不等於有進展
  • 沒有共同格式，審查者無法稽核 Agent 彼此說了什麼
  • Message Contract 讓每則訊息只做一件清楚的事

注意

訊息越多，不代表協作越好。人應該能讀懂 Agent 之間的訊息，看出誰要求了什麼、提供了什麼 Evidence、決定了什麼。

重點: 好的協作來自目的明確的訊息，而不是更多的訊息。

核心概念

9 分鐘

Message、結構化與 Communication Boundaries

Message 是從一個 Agent 送到另一個 Agent 的一個資訊單位。Agent-to-Agent 溝通在訊息是 Structured 時效果最好，也就是有固定的欄位，而不是一大段開放文字。

自由格式訊息

  • 「你可以看一下再告訴我嗎？」
  • 目的、Context 與期待的回覆都是暗示的
  • 很難審查，也容易誤讀

Structured Message

  • 有 type、task、context 與 expected response 等具名欄位
  • 接收者確切知道要做什麼
  • 審查者可以追蹤整段交換
Directed Message 或 Broadcast（模擬）
方式是什麼適用時機風險
Directed Message送給一位指定的接收者針對某個 Agent 的特定 Task 或問題送出者必須選對接收者
Broadcast同時送給多個 Agent大家都需要知道的通知，例如共同 Goal 有變動雜訊多，且不清楚該由誰行動

Communication Boundaries 規定誰可以對誰傳訊息、內容是什麼、可以帶什麼資訊。Agent 不應把接收者不需要知道的資訊傳出去，也不應接受不被允許下指令的送出者所發出的指令。

自我檢測

某個 Agent 需要一位專責 Agent 提供一個具體答案。哪種方式最合適？

某個 Agent 需要一位專責 Agent 提供一個具體答案。哪種方式最合適？

重點: 優先使用 Structured、Directed 的訊息，Broadcast 少用，並為誰可以對誰傳訊息設定邊界。

10 分鐘

概念性的 Message Types

大部分 Agent 之間的往來，可以用一小組訊息類型來描述。以下名稱是設計用的概念標籤，不是標準，也不是傳輸格式。

建議的概念性 Message Types（模擬範例）
Message Type用途範例
TASK_REQUEST請另一個 Agent 做某件事確認活動 X 的逾期報名規定
TASK_RESULT回傳 Task 的結果逾期報名可到週五；請見附上的段落
STATUS_UPDATE回報進度但尚未完成規定確認已開始；等待最新的規定文件
EVIDENCE為主張或結果提供依據答案所依據的規定段落
QUESTION詢問缺少的資訊這個問題指的是哪一個活動？
ERROR回報某件事失敗或無法完成無法讀取規定文件；沒有存取權限
ESCALATION把問題送交給人或更高權責者規定不明確，例外需要有人決定
HANDOFF把 Task 與 Ownership 交給另一個 AgentIntake 連同完整的 Handoff Contract 把 Task 交給 Policy
典型的一次交換
  1. TASK_REQUEST：送出者提出具體的 Task
  2. Acknowledgement：接收者確認已理解並接受
  3. STATUS_UPDATE 或 QUESTION：接收者回報進度，或詢問缺少的資訊
  4. EVIDENCE + TASK_RESULT：接收者連同依據回傳結果
  5. ERROR 或 ESCALATION：Task 無法完成或需要人時，改用這兩種

文字版說明：一次交換從 Request 與 Acknowledgement 開始。工作過程中，接收者可能送出 Status Update 或 Question。最後以結果與其 Evidence 收尾。若 Task 無法完成，就以 Error 或 Escalation 取代結果。

自我檢測

接收者無法開啟被要求檢查的來源文件。它應該送出哪種訊息？

接收者無法開啟被要求檢查的來源文件。它應該送出哪種訊息？

重點: 八種概念性類型涵蓋大多數交換：request、result、status、evidence、question、error、escalation 與 handoff。

10 分鐘

Message Contract

Message Contract 是關於訊息帶哪些欄位、每個欄位代表什麼的約定，讓任何接收者都能據此行動，任何審查者都能稽核。它是 Agent 之間的設計約定，不是技術 Protocol。

Message Contract 欄位
欄位內容範例（模擬）
Sender誰送出Intake Agent
Receiver誰該行動Policy Agent
Message Type概念性類型之一TASK_REQUEST
Task / Goal要求什麼、為什麼確認活動 X 是否允許逾期報名
Context接收者需要知道什麼截止日是上週五；學生要求延一天
Constraints接收者不可以做什麼不直接聯絡學生；不承諾例外
Evidence支持這則訊息的依據活動規定章節的連結
Expected Response期待什麼形式的回覆TASK_RESULT，回答是或否，並附規定段落
StatusTask 目前進度未結案
Timestamp / Version何時、哪個版本（適用時）第 1 版的請求

資訊

Timestamp 與 Version 只有在有幫助時才需要，例如訊息取代較早的版本，或審查者必須知道當時的資訊是哪一版。不要加上沒有人使用的欄位。
自我檢測

為什麼 Message Contract 要有 Expected Response 欄位？

為什麼 Message Contract 要有 Expected Response 欄位？

重點: Message Contract 指明 Sender、Receiver、Type、Task、Context、Constraints、Evidence、Expected Response、Status，以及需要時的 Version。

邊界與常見陷阱

8 分鐘

常見陷阱與不在範圍內的部分

Contract 可以預防幾種常見的溝通問題。它在本課程中的範圍也很明確。

溝通陷阱與防範（模擬）
陷阱發生什麼事防範
模糊的 Request接收者猜測要什麼填寫 Task / Goal 與 Expected Response
缺少 Acknowledgement送出者不知道請求是否送達要求接收者確認已接受
Silent Failure接收者失敗了卻沒說送出 ERROR 訊息，必要時再 Escalate
缺乏依據的主張結果背後沒有任何依據要求結果附上 Evidence
Oversharing訊息包含接收者不需要的資訊把 Context 限縮在 Task 需要的範圍
聊天迴圈Agent 一直回覆卻沒有進展定義交換何時結束、何時 Escalate

資訊

範圍說明：本單元教的是 Agent 之間該說什麼的概念性設計，不教 Protocol 實作、訊息格式或傳輸方式。長時間訊息處理的可靠性與復原屬於另一門課（AI 302）。

注意

Agent 之間的訊息可能帶有敏感資訊。只分享接收者需要的內容，並讓人隨時能審查這些交換。
自我檢測

團隊被要求設計 Agent 之間傳送訊息所用的精確位元組格式。對本課程而言，適當的回應是什麼？

團隊被要求設計 Agent 之間傳送訊息所用的精確位元組格式。對本課程而言，適當的回應是什麼？

重點: Contract 預防模糊的 Request、Silent Failure 與缺乏依據的主張。設計保持在概念層，並限制分享的內容。

實作與應用

10 分鐘

實作：設計 Agent Communication Contract

活動 4 請你為兩個 Agent 建立一份溝通 Contract。請先看範例，再針對你自己的 Use Case 練習。請不要在這個練習中輸入真實的公司機密、客戶個人資料或任何未經授權的敏感資訊。

範例（模擬）。Intake Agent 與 Policy Agent
欄位內容
Sender / ReceiverIntake Agent 對 Policy Agent
使用的 Message TypesTASK_REQUEST、STATUS_UPDATE、QUESTION、TASK_RESULT、ERROR、ESCALATION
Task / Goal確認指定活動是否允許逾期報名
分享的 Context活動名稱、截止日、學生的問題（不含個人身分）
Constraints不直接聯絡學生；不承諾例外
需要的 Evidence所用的規定段落
Expected ResponseTASK_RESULT，回答是、否或不明確，並附 Evidence
交換結束 / Escalation以結果結束。若不明確或持續發生錯誤，就 ESCALATION 給人
  1. 挑選兩個 Agent
    從你的 Use Case 選出兩個需要交換資訊的 Agent。
  2. 選擇 Message Types
    列出他們會使用八種概念性類型中的哪些，以及各由誰送出。
  3. 填寫 Contract 欄位
    寫下 Sender、Receiver、Task、Context、Constraints、Evidence、Expected Response 與 Status，只有在有幫助時才加上 Version。
  4. 設定邊界
    寫明哪些內容不可以分享、交換何時結束，以及何時送出 ERROR 或 ESCALATION。

資訊

成果：Agent Communication Contract，內容包括兩個 Agent、他們使用的 Message Types、Contract 欄位、Communication Boundaries，以及結束與 Escalation 條件。它會成為你 Multi-Agent Architecture Canvas 的一部分。
自我檢測

哪一項屬於訊息的 Constraints 欄位？

哪一項屬於訊息的 Constraints 欄位？

重點: Human-AI-Human：由人定義 Agent 可以說什麼、分享什麼，Agent 交換清楚的 Structured Message，人能審查這些交換並負責。

另存 PDF

接下來做什麼？