事件背景：服務全綠，不代表工作流健康
原文記錄的是一套名為 Taraol 的黑客松原型：規劃、研究、寫作、批評與路由五個 AI Agent，各自運行於不同容器，透過 HTTP 串接。某次執行中，writer 不斷交稿、critic 不斷退回，兩者跨服務反覆呼叫 Gemini；然而各服務仍在線、HTTP 持續回傳 200，模型也都有產出合法文字。從傳統監控看來一切正常，真正失控的是整體流程。原始案例與作者揭露的數據見：https://dev.to/bek-dev-22/how-we-caught-and-contained-a-runaway-ai-agent-loop-with-signoz-1548
來源事實：planner 已完成自身工作；writer 只看見另一筆修改請求，critic 只看見另一份草稿。沒有單一服務掌握全貌，迴圈只存在於服務之間的呼叫關係。這也說明事件核心並非「模型沒有回答」，而是系統欠缺對任務是否收斂的判斷。
迴圈如何被看見
Taraol 在每次 Agent、模型與工具操作建立 OpenTelemetry span，並在跨服務請求中傳遞 W3C 的 traceparent。如此一來，分散在五個容器的動作仍屬於同一條 trace，後端便能重建 planner → researcher → writer → critic → router 的完整路徑。
這項機制不是專案自行發明的私有關聯格式。W3C Trace Context 規範明確定義以標準 HTTP 標頭傳遞追蹤識別資訊，使單一邏輯操作可跨越多個服務而保持關聯：https://www.w3.org/TR/trace-context/。這項交叉查證支持原文的核心技術前提：只要每一跳正確延續追蹤脈絡，後端確實可以觀察跨程序的重複邊，而不必要求某個 Agent 成為全知的總控中心。
原型另以實驗標籤區分正常與 runaway 版本。原文公布的一次執行中，正常版本使用 2,799 tokens、直接成本 0.0079 美元、平均耗時 50,340 毫秒；runaway 版本則為 14,342 tokens、0.0406 美元與 130,017 毫秒。這是單次示範結果，不是可外推至所有模型或架構的效能基準；它真正證明的是，重複呼叫會同時反映在 token、成本、延遲及服務邊的遍歷次數上。
從偵測到阻斷：把權責拆開
原型中的 Watcher 查詢近期遙測資料，依 trace 與服務邊分組，尋找「重複遍歷但沒有進展」的模式，再寫入 loop_detected 紀錄。SigNoz 的警示規則決定是否升級處理，Controller 才負責暫停 Agent 或切斷特定服務邊；執行結果又以 agent_paused 或 edge_broken 回寫，形成稽核軌跡。
本文觀點：這種分工比讓偵測器直接關閉服務更重要。Watcher 回答「是否可疑」，警示規則承載組織政策，Controller 才握有變更執行狀態的權力。日後若需調整門檻、加入人工核准，或只阻斷高風險工具，便不必把營運政策硬寫進每一個 Agent。
為何現在值得注意
一般 Web 服務常以錯誤率、延遲與可用性為主要指標；Agent 系統卻可能在每一個技術步驟都「成功」時，持續做錯誤的事。HTTP 200 只證明某次呼叫完成，不能證明任務取得進展，也不能證明成本、工具副作用或迭代次數仍在容許範圍。
OpenTelemetry 官方資料也顯示，生成式 AI 遙測可記錄模型名稱、輸入與輸出 token、停止原因、Agent 與工具呼叫；提示詞、工具參數及結果則屬選擇性內容，預設不擷取，因為可能含有敏感資料：https://opentelemetry.io/blog/2026/genai-observability/。因此，可觀測性不是「把所有對話全部存下來」，而是先建立足以回答成本、路徑與收斂問題的最小遙測集合。
實際影響與合理推論
合理推論：若同類迴圈出現在正式環境，直接後果不只是一張較高的模型帳單。它還可能占滿工作佇列與供應商速率配額，拖慢其他正常請求；若 Agent 能寄信、下單、寫入資料庫或呼叫企業系統，每一次重試也可能產生外部副作用。這些影響並未由 Taraol 實驗逐項量測，不能當成該案例已發生的事實，但都是重複工具呼叫可合理導出的營運風險。
因此，實務上的停止條件不宜只設「最多重試三次」。較完整的防線應同時觀察：
- 單一工作流的總迭代、token、時間與金額上限；
- 相同 Agent 邊或相同工具在短時間內的重複次數；
- 輸出是否出現可量化進展，而非僅換字重寫；
- 熔斷後採取降級回覆、人工接管，或整體終止；
- 涉及付款、通知與資料寫入時，是否具備冪等控制。
容易忽略的限制
原作者明確承認，這仍是黑客松系統：暫停與斷路器狀態只存在記憶體，服務重啟就會清除；提示注入偵測僅靠正規表示式；通知管道仍有人工設定；Watcher → alert → Controller 的端到端測試也需補強。內容擷取雖有助除錯，正式上線前更必須處理遮罩、保存期限與存取權限。
此外，追蹤資料能顯示「writer 與 critic 重複互叫」，卻不必然知道兩份草稿是否語意相同。所謂「沒有進展」仍需要應用層定義；不同任務可能要用狀態變更、評分改善、工具結果或人工規則判定。偵測門檻過低會誤殺正常反覆修訂，過高則可能在攔截前已耗費大量資源。
對台灣團隊的意義與觀察指標
對正在導入客服、文件處理、研究助理或內部流程 Agent 的台灣團隊，重點不是一定要採用 Taraol 或 SigNoz，而是把驗收範圍從「能否回答」擴大到「能否受控地完成」。採用標準化 trace context 與 OpenTelemetry，亦可降低日後更換模型、框架或可觀測性後端時重新埋點的成本。
後續最值得觀察的指標包括：每項任務的 P95 Agent 跳數與 token、相同服務邊重複率、停止條件觸發率、熔斷後成功降級率、人工接管時間，以及每次介入是否都有可追溯紀錄。更關鍵的訊號則是「成功回應但未完成業務目標」的比例。當這個數字被正式納入營運儀表板，AI Agent 才算從可展示的功能，走向可治理的生產系統。