跳到主要內容
NTPU AI Learn

AI 302 · 模組 7

Observability、Reliability 與 Operational Boundaries

系統出了問題時，我們能不能知道「發生了什麼、為什麼、在哪一步」？

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

資訊

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

學習目標

  • 說明 Observability，並區分 Trace、Log、Metric 與 Event History
  • 把一次 Run 描述為 State Transitions、決策、Tool Calls、Verification 結果、人工動作、錯誤與 Recovery 動作的紀錄
  • 用 Error Provenance 追溯錯誤最初發生的位置
  • 選擇 Reliability 指標，例如 Completion Rate、Retry Rate、Escalation Rate、Recovery Rate、Latency、Cost 與 Step Count
  • 定義 Operational Boundaries 與 Safe Stop 條件：步驟、重試、成本與時間上限、允許的動作與必要核准
  • 完成活動 7：設計最小 Observability 計畫，並擬定 Reliability & Observability Scorecard

該觀察什麼

10 分鐘

為什麼需要 Observability：Run、Step、Event、Log 與 Metric

會驗證、重試與恢復的 Harness，只有在人能看見它做了什麼時才值得信任。Observability 是指從系統留下的紀錄，理解一次 Run 內部發生了什麼的能力。沒有它，失敗的 Run 是一個黑盒子，看似成功的 Run 也無法被檢查。

核心問題

系統出了問題時，我們能不能知道發生了什麼、為什麼發生，以及在哪一步？

Observability 的詞彙（模擬範例）
名詞意思模擬範例
Run工作流程從觸發到最終狀態的一次執行處理一批進件文件的一次 Run
StepRun 內的一個工作單位「擷取欄位」這個 Step
Event在某個時間點發生的事第 4 步開始、Verification 失敗、有人核准
Event History一次 Run 依序排列的 Event 清單該次 Run 依時間順序的完整時間線
TraceRun 相連的路徑：哪些 Steps 依什麼順序執行，結果如何步驟 1、步驟 2、步驟 3 重試一次，然後人工審核
Log對發生的事所做的一筆記錄或細節某個工具在 10:42 回傳逾時錯誤
Metric跨多次 Run 或 Steps 量測出的數字本週的 Retry Rate
Run StatusRun 目前的狀況執行中、等待人工、失敗、已完成

資訊

Human、AI、Human：人決定哪些事必須可被觀察，Harness 負責記錄，人閱讀紀錄並對後續行動負起責任。

重點: 每次 Run 都會留下 Trace、Events、Logs、Metrics 與狀態。要在出事之前，就先決定要記錄什麼。

10 分鐘

Observability 模型與 Error Provenance

有用的 Run 紀錄不只包含最終答案，還包含走過的路徑與沿途的理由。六類資訊涵蓋大部分需求，合起來能讓人重現一次 Run 的經過。

Observability 模型：一次 Run 記錄什麼
  1. Run
  2. State Transitions
  3. Agent 決策（Decision Trace）
  4. Tool Calls（Tool-call History）
  5. Verification 結果
  6. 人工動作（Human Intervention History）
  7. 錯誤
  8. Recovery 動作

資訊

圖的文字版：Run 是容器。Harness 在裡面記錄 State Transitions、Agent 決策、Tool Calls、Verification 結果、人工動作、錯誤與 Recovery 動作。每一筆紀錄都附著在這次 Run，以及它發生的 Step 上。

Error Provenance 是指知道錯誤從哪裡來，而不只是知道錯誤出現了。一個錯誤的最終數值，可能源自三步之前的錯誤工具結果，並通過了一個沒有檢查的步驟。要追溯它，就需要把每個錯誤連結到它的 Step、輸入、相關的 Tool Call，以及使用它的決策。

  • 為每次 Run 設定 Run ID，並為每個 Step 設定識別，讓紀錄可以互相對應
  • 記錄每次 Transition 前後的 State
  • 記錄呼叫了哪個工具、輸入為何、結果為何，並讓敏感內容不進入 Logs
  • 記錄每個決策由誰或什麼做出，包括人工核准與 Override
  • 記錄錯誤、發生的 Step 與採取的 Recovery 動作

資訊

僅為範例：LangGraph 這類有狀態框架，會在執行從一個 Node 移到下一個 Node 時記錄 Graph State，可作為 Trace 的來源。這裡的概念不依賴任何單一框架。
自我檢測

一次 Run 得到錯誤的數值。哪些資訊最能幫你找到錯誤最初發生的位置？

一次 Run 得到錯誤的數值。哪些資訊最能幫你找到錯誤最初發生的位置？

重點: 記錄 State Transitions、決策、Tool Calls、Verification、人工動作、錯誤與 Recovery，並都綁定到 Run 與 Step。

Reliability 衡量

9 分鐘

Reliability 問題與指標

Reliability 是指工作流程持續做對事的穩定程度。靠感覺無法改善它，需要幾個問題，以及回答這些問題的數字。

  • 工作流程有完成嗎？
  • 發生了幾次 Retry？
  • 失敗發生在哪裡？
  • 多常需要人工升級？
  • Recovery 成功了嗎？
  • 這次 Run 花了多少成本？
  • 花了多久時間？
  • 系統有停留在它的界線之內嗎？
Reliability 指標與它們顯示的事
指標它告訴你什麼
Completion RateRun 多常抵達成功的最終狀態
Failure RateRun 多常以失敗結束
Retry RateSteps 多常需要重複執行
Escalation Rate多常需要人介入
Recovery Rate失敗多常被恢復，而不是讓 Run 結束
Latency一次 Run 或 Step 花了多久
Cost一次 Run 整體消耗了什麼
Step Count一次 Run 走了多少步，可以看出是否有 Loop
自我檢測

哪個指標最直接顯示失敗多常被處理掉，而不是讓 Run 結束？

哪個指標最直接顯示失敗多常被處理掉，而不是讓 Run 結束？

重點: 先問 Reliability 問題，再挑能回答這些問題的指標。

9 分鐘

把 Reliability 指標放在一起讀

單一數字可能誤導。Reliability Evaluation 是把指標放在一起讀，並問這個模式對設計意味著什麼。

模式與可能的意義（模擬範例）
模式可能的解讀該檢查什麼
Completion 高、Retry Rate 高Run 都完成，但要重複很多次才完成Cost 與 Latency；不穩定的工具或薄弱的 Verification Gate
Escalation Rate 很低系統運作良好，或問題被隱藏了Verification 與 Escalation 觸發條件是否太鬆
Step Count 高但沒有進展沒有好好設限的 LoopLoop 條件與步驟上限
Recovery Rate 低失敗沒被分類，或 Fallback 很弱Failure Taxonomy 與 Fallback 路徑
每次 Run 的 Cost 上升Retry 或 Context 成長正在增加Retry Policy 與 Context Compaction

注意

指標只有在有人會採取行動時才有用。要事先決定什麼數值算是問題、通知誰、對方該做什麼。不要收集沒人看的數字。

資訊

本課程範圍：本單元在設計層級選擇要觀察與衡量什麼，不教監控產品、儀表板或一般 DevOps 實務。
自我檢測

一個工作流程的 Escalation Rate 非常低。最謹慎的結論是什麼？

一個工作流程的 Escalation Rate 非常低。最謹慎的結論是什麼？

重點: 把指標當成一組來讀，並事先定義什麼算是問題、由誰採取行動。

Operational Boundaries

9 分鐘

Operational Boundaries 與 Safe Stop 條件

Operational Boundary 是系統在沒有人的情況下不得越過的界線。界線讓長時間執行或正在失敗的 Run，在成本、時間與影響上維持有界。界線在 Run 之前決定，由 Harness 在 Run 期間強制執行。

需要定義的 Operational Boundaries
界線它限制什麼模擬範例
Max StepsRun 最多能持續多久40 步後停止
Max Retries一個 Step 最多能重複幾次每個 Step 最多重試 3 次
Max Cost一次 Run 最多能消耗多少達到單次 Run 預算時停止
Max Runtime一次 Run 最多能花多久30 分鐘後停止
允許的工具與動作Run 到底能做什麼除非有人核准，否則只用唯讀工具
必要核准什麼事需要人先同意任何不可逆或對外可見的動作
Stop ConditionsRun 何時必須安全停下達到上限、重複失敗或違反安全規則
  • 達到上限時要安全停止並記錄原因，而不是繼續並期待好結果
  • Safe Stop 讓 Run 停在已知的狀態，人可以檢查，並在適當時恢復
  • 達到上限是升級給指定負責人的訊號
  • 禁止的動作即使 Agent 看起來很有把握，仍然禁止

注意

不要設計一個因為從未設定上限，而讓高影響動作不受檢查地繼續的 Harness。沒有上限的 Run，就是沒有人在控制的 Run。
自我檢測

一次 Run 在某個 Step 達到最大 Retry 上限。Harness 應該怎麼做？

一次 Run 在某個 Step 達到最大 Retry 上限。Harness 應該怎麼做？

重點: 事先設定步驟、Retry、成本與時間上限、允許的動作與核准，並在達到上限時安全停止。

實作與下一步

8 分鐘

活動 7：What Should We Observe? 與你的 Scorecard

你會拿到一個模擬的 Agentic Workflow。請為它設計最小的 Observability 計畫，並決定如何判斷它是否可靠。

  1. 定義 Run
    一次 Run 是什麼、它的 ID 是什麼、有哪些可能的最終狀態？
  2. 選擇要記錄什麼
    State Transitions、Tool Calls、Verification 結果、錯誤、Recovery 動作與人工介入：最少需要哪些？
  3. 選擇指標
    挑幾個 Reliability 指標，並說明什麼數值算是問題。
  4. 設定界線
    步驟、Retry、成本與時間上限、允許的動作、必要核准與 Stop Conditions。

完成

本單元的成果物：Reliability & Observability Scorecard。它列出你記錄什麼、你觀察的指標與門檻、Operational Boundaries，以及越界時通知誰。

注意

隱私提醒：請使用模擬或已公開的情境。不要輸入公司機密、客戶個資或未經授權的敏感資訊，並讓敏感內容不進入你設計的 Logs。

在單元 8，你會把這份 Scorecard 放進 Agent Harness & Reliability Canvas 的 Observability、Reliability Metrics 與 Operational Boundaries 區塊。

自我檢測

對最小的 Observability 計畫來說，哪一組是最好的起點？

對最小的 Observability 計畫來說，哪一組是最好的起點？

重點: 定義 Run、記錄足以說明它的最少內容、選擇有門檻的指標並設定界線，然後記入你的 Scorecard。

另存 PDF

接下來做什麼？