跳到主要內容

AI 302 實作活動

七個簡短活動,培養設計好的 Agent Harness & Reliability Canvas 所需的判斷力

資訊

自我檢核(不計分、不儲存). 每個活動都會立即回饋並說明原因。答錯可以改選再試;全部答對即完成該活動。

Agent Logic 還是 Harness?

判斷每個模擬的設計元素由誰或什麼負責:Agent reasoning(決定要做什麼)、Workflow logic(事先定義的步驟順序)、Harness control(執行、追蹤、暫停、Resume 與限制執行)、Human control(由真人決定或核准),或 Tool responsibility(工具本身的職責)。

已答對 0 / 8 題

第 1 題

在兩組搜尋查詢中,選出比較可能找到缺少數字的那一組。

第 2 題

每完成一步就把執行 State 存到儲存空間,讓當機後可以 Resume。

第 3 題

事先固定的步驟順序:蒐集、擬稿、驗證、寄出。

第 4 題

由主管決定是否核准超過額度的模擬退款。

第 5 題

匯率服務因為缺少欄位而拒絕請求,並回傳錯誤碼。

第 6 題

執行滿 25 步或用完設定的預算(以先到者為準)就停止。

第 7 題

根據取得的事實,判斷目前的計畫需要換一種做法。

第 8 題

把執行暫停在核准狀態,直到指定的審閱者回應。

Build the State Model

一個模擬的文件處理 Agent 以 State Machine 運作。請將每個項目分類為 State(Run 目前所在位置)、Transition(讓它在 State 之間移動的條件)、Error state(失敗狀態),或 Human review state(等待真人的狀態)。

已答對 0 / 8 題

第 1 題

EXECUTING:Agent 正在執行目前的步驟。

第 2 題

檢查失敗且還有重試次數時,從 VERIFYING 到 EXECUTING。

第 3 題

FAILED:已達重試上限,Run 安全停止並記錄原因。

第 4 題

REVIEW:Run 正在等待審閱者核准草稿。

第 5 題

PLANNING:Agent 正在把目標拆成步驟。

第 6 題

信心低於門檻時,從 VERIFYING 到 REVIEW。

第 7 題

ESCALATED:無法恢復的工具錯誤已交給真人,Run 暫時擱置。

第 8 題

TOOL_ERROR:必要的資料來源無法使用,Run 無法照原計畫繼續。

Where Should We Checkpoint?

一個模擬的流程會讀取資料、擬定摘要、寄出電子郵件(外部動作),再更新一筆紀錄。請判斷每個時間點是適合的 Checkpoint、不適合或不安全設 Checkpoint 的位置(No checkpoint),或是 Duplicate execution risk:在這裡重播,若沒有先確認是否已完成,可能重複外部動作。

已答對 0 / 8 題

第 1 題

資料已讀取並儲存。下一步要擬定摘要。

第 2 題

寄信的 API 呼叫已經開始,但還沒有收到回應。

第 3 題

電子郵件已確認寄出(已儲存 Message ID)。紀錄更新還沒開始。

第 4 題

Agent 正在寫草稿的第三句話。

第 5 題

付款已送出,逾時觸發,結果不明。

第 6 題

草稿完成並已儲存,Run 即將進入核准狀態。

第 7 題

在一個只需一毫秒的運算中,剛指定了一個暫時變數。

第 8 題

刪除檔案的指令已送出,Harness 在記錄結果之前當機。

Automatic or Human Gate?

為每個模擬動作決定 Gate:Auto-continue(低風險,不需檢查)、Auto-verify(自動檢查後繼續)、Human review(真人先看過再繼續)、Human approval(無法復原或對外的動作必須先由真人核准),或 Prohibit(Agent 不得執行)。

已答對 0 / 8 題

第 1 題

重新整理只在 Run 內部使用的暫存表格式。

第 2 題

寫入下一步之前,剛擷取的發票資料。

第 3 題

一封回覆客訴的草稿,內容可能包含政策承諾。

第 4 題

把完成的報告寄給外部客戶。

第 5 題

在沒有指定核准人的情況下,送出超過核准額度的付款。

第 6 題

檢查產生的檔案是否符合要求的 JSON Schema。

第 7 題

變更特定員工的請假申請狀態。

第 8 題

寫一行 Log,記錄已完成的步驟。

Retry, Recover, Escalate or Stop?

針對每個模擬的失敗,選擇最合適的回應:Retry(在上限內再試同一件事)、Fallback(改用另一條路徑或工具)、Escalate(交給真人)或 Safe stop(停止並保留 State 與原因)。請記得:Retry 並不總是安全。

已答對 0 / 8 題

第 1 題

一個唯讀查詢逾時一次。這個服務平常很穩定。

第 2 題

主要資料來源整個小時都停擺,而且有核准的備援來源。

第 3 題

輸出連續三次未通過 Schema 驗證,Agent 無法判斷是哪個欄位錯了。

第 4 題

Agent 被要求把個人資料寄到核准名單以外的地址。

第 5 題

搜尋 API 回傳兩次 503,現在已經恢復正常。

第 6 題

Agent 沒有權限開啟檔案,但另有一份核准的檔案含有相同的數字。

第 7 題

付款送出後逾時,沒有人知道款項是否已送出。

第 8 題

Run 已用完整個預算,並且一小時都在重複同一個失敗的步驟。

Compact the Context

一個模擬的 Agent 已執行 300 步,Context 幾乎已滿。針對執行歷史中的每個項目,判斷應該保留在 Working Context(Keep)、濃縮成簡短的 State 筆記(Summarize),還是從 Working Context 移除(Drop,仍可留在封存中)。

已答對 0 / 8 題

第 1 題

這次 Run 的目標與期限。

第 2 題

先前已審閱、不再需要的四十筆搜尋結果,其中三筆已被使用。

第 3 題

一次失敗的嘗試,完整的錯誤訊息已在 Log 中。

第 4 題

真人審閱者的指示:「在我核准之前,不要聯絡供應商。」

第 5 題

促成目前計畫的二十則中間推理筆記。

第 6 題

這次 Run 目前的 State 與待處理動作清單。

第 7 題

一個網頁的完整文字,已儲存來源連結。

第 8 題

已做出的六個決定與各自的支持證據清單。

What Should We Observe?

最低限度的 Observability 會記錄發生了什麼、在哪裡、為什麼。針對每一筆模擬的 Log,選擇它是哪一種資訊:Run(一次執行的身分與狀態)、State(Run 目前所在位置)、Tool call(一次呼叫與其結果)、Error(什麼失敗、在哪裡)、Recovery(對此做了什麼),或 Human intervention(真人做了什麼)。

已答對 0 / 8 題

第 1 題

run-2041 於 02:00 開始,最終狀態:完成,含一次 Retry。

第 2 題

Transition:第 14 步從 VERIFYING 到 REVIEW,原因:信心低於門檻。

第 3 題

search_api(query "budget 2026") 在 820 毫秒內回傳 4 筆結果。

第 4 題

第 9 步失敗:找不到來源檔案(data-source-2)。

第 5 題

失敗後,Harness 切換到備援來源並繼續執行。

第 6 題

審閱者 A 於 09:12 核准草稿並附上意見。

第 7 題

匯出步驟的第 2 次 Retry(共 3 次),嘗試前等待 4 秒。

第 8 題

操作人員在第 22 步暫停並恢復了這次 Run。

同步我的進度加入梯次後,進度可跨裝置保存,講師也能看到

資訊

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

接下來做什麼?