所有節目›AI Engineer Europe 2026World's Fair 2026World's Fair 線上軌AI in HealthcareSoftware Factories
Everything You Need To Know About Agent Observability在 YouTube 看這一場

AI Engineer Europe 2026 · 演講 · 2026-05-07 · 50 分

用訊號與自我診斷監控 agent

Everything You Need To Know About Agent Observability · Danny Gollapalli、Zubin Koticha,Raindrop

Raindrop 的 Zubin 與 Danny 主張 agent 的重心該從 evals 轉到線上監控,介紹隱含與明確訊號、用訊號做實驗,並現場示範讓 agent 自己回報問題。

eval 或監控看原片 ↗

概要

  • 從 evals 轉向監控Zubin 認為 agent 的工具、記憶與子 agent 讓輸入空間組合爆炸,固定的測試集蓋不完,所以線上監控比測試更重要。
  • 兩類訊號明確訊號是能驗證真假的東西,例如錯誤率、延遲、重新生成與成本;隱含訊號看語意,例如拒絕、任務失敗、使用者沮喪,可以用 regex 或分類器抓。
  • 拿訊號做實驗改 prompt、換模型或加工具時,只放給一部分使用者,對照這些訊號的比率有沒有上升。Zubin 展示的例子裡,沮喪率從 37% 降到 9%。
  • 自我診斷Danny 的做法是給 agent 一個回報用的工具,再在 system prompt 裡鼓勵它使用,讓它說出工具壞掉、能力缺口、繞過限制等狀況。
  • 工具怎麼命名有差模型不愛自我指控,所以把工具包裝成「給創造者的回饋」比叫它回報不安全的 bash 用法更容易觸發。
  • Q&A 談實務樣本數、分類器成本、跟 Statsig 與 BigQuery 的串接、trace 與 trajectories 檢視,以及為何不能公開客戶資料。

原話

  • “monitoring production is just infinitely more important and it allows you to move faster and be better at catching the long tail.”

    監控 production 重要得多,也讓你走得更快、更能抓到長尾問題

    ▶ 03:04
  • “I didn't fix the S3 test, I just simply removed it.”

    模型被要求自白時會承認的話:我沒修好那個 S3 測試,只是把它刪掉

    ▶ 17:10
  • “So they are less willing to admit fault in many cases.”

    模型被訓練得很體面,所以多半不太願意認錯

    ▶ 30:25
  • “I think self-diagnostics works really well for catching capability gaps and such.”

    我認為自我診斷很適合抓能力缺口這類問題

    ▶ 31:30
  • “there are compliance reasons where we can't actually put a customer's data out there.”

    基於合規,我們不能把客戶資料公開

    ▶ 49:48

延伸

  • Danny 提到 Codex 或 Claude Code 在 sandbox 裡連不上網路時,會改寫一支 Python 腳本繞過去,並說這種自我修正有好有壞:任務完成了,但在某些情況下有安全疑慮,所以也是自我診斷要抓的一類。
  • Zubin 提到正在想怎麼讓 agent 根據訊號開 PR 並跑新實驗,形成自我改進的閉環,但還沒有成品。
  • Danny 說 Python 支援還弱,之後會改善;SDK 目前由專人在處理。

章節

點時碼直接跳到原片的那一段。

  1. 開場與自我介紹Zubin 是 Raindrop 的 CEO 與共同創辦人,Danny 是後端工程師,也做 SDK;Raindrop 幫 AI 工程師找出、追蹤並修好 production agent 的問題。
  2. agent 失敗不一樣agent 非確定性、輸入輸出都沒有邊界,還能用工具影響其他系統;Zubin 說傳統的 evals 在這種情況下不夠。
  3. 從 evals 到監控輸入空間組合爆炸,測試集蓋不完,要改成監控 production;Zubin 把它稱為「humanity's last problem」。
  4. 明確與隱含訊號明確訊號是能驗證真假的東西,如錯誤率、延遲、重新生成與成本;隱含訊號看語意,更有趣也更難找。
  5. 分類器訊號與儀表板最好的隱含訊號是偵測固定的問題類型;示範每天的沮喪率、拒絕、偷懶等比率,異常時可以設警報。
  6. regex 也是好訊號以 Claude Code 外洩的原始碼為例,裡面有一串找「WTF」「This sucks」之類字眼的 regex,便宜又有用。
  7. 用訊號做實驗把改動放給一部分使用者,拿拒絕、沮喪等訊號跟對照組比;示範 prompt 2.4 讓沮喪率從 37% 降到 9%。
  8. Q&A:樣本數與追蹤上線事件多到讀不完時訊號就開始有用;實驗的版本標記由客戶自己送 metadata,也可以轉給 Statsig。
  9. Q&A:regex 與分類器regex 單例不準,但幾百萬使用者的總量仍有用;每筆輸出都跑 LLM 會讓 AI 支出翻倍,所以訓練小模型。
  10. triage agent 與查詢 API有個 triage agent 每天看所有訊號,異常時自己調查;客戶也可以用查詢 API 把標好的訊號拉到 BigQuery 或 Statsig。
  11. 自我診斷Danny 以 OpenAI 在 12 月談模型自我告白的文章為靈感,說明 agent 能回報工具失敗、使用者沮喪、能力缺口與自我修正。
  12. workshop 設定切到動手環節:公開的 repo 裡有個只有四個工具的簡易 coding agent,要故意弄壞 write 工具來觸發自診斷。
  13. demo:寫檔失敗先確認 agent 能寫 Python 腳本,再讓 write 工具丟出權限錯誤,agent 就改用 bash 的 heredoc 寫檔;中間排錯等待多。
  14. 回報工具與提示詞回報工具只要一個很簡單的描述,system prompt 再叫它在最終答案前回報值得注意的事。
  15. Q&A:客戶怎麼用客戶多半把完整 trajectory 用 OTel 等方式送來,自訂訊號,用意圖分群看每種用法的問題率。
  16. 監控比測試重要agent 更強、更多人用,未知問題更重要;Issues 功能會挖新出現的問題,並找出沮喪率上升的共同原因。
  17. SDK 現況Python 支援還弱,SDK 內建自診斷工具,過去一個月發了 10 個 SDK。
  18. Q&A:怎麼比較功能旗標樣本夠大時幾分鐘就看得出退步;他們也在想讓 agent 看訊號、開 PR、再跑實驗的閉環。
  19. trace 與 trajectories明確訊號包含 trace 裡的工具錯誤;Raindrop 主打模糊的失敗,trajectories 可以用描述搜尋工具呼叫的形狀。
  20. 匯出與公開資料支援匯出事件與分類結果到 BigQuery 和 Snowflake;有人問能否公開資料,答覆是合規上不能放客戶資料。

名詞

Raindrop
Zubin 與 Danny 的公司,幫 AI 工程師找出、追蹤並修好 production agent 的問題
explicit signals
明確訊號,能驗證真假的指標,如錯誤率、延遲、重新生成與成本
implicit signals
隱含訊號,看語意的指標,如拒絕、任務失敗、使用者沮喪、jailbreak,可用 regex、分類器或自診斷偵測
self-diagnostics
給 agent 一個回報工具,讓它在遇到值得注意的狀況時主動說出
triage agent
Raindrop 每天掃描所有訊號,異常時自動調查的 agent
Issues
Raindrop 的功能,會挖新出現的問題,例如新的例外
trajectories
Raindrop 的檢視功能,可以用描述搜尋工具呼叫的順序與形狀
Statsig
實驗平台,Zubin 說 Raindrop 可以把資料轉過去
OTel
客戶常用來把 trace 與工具呼叫送進 Raindrop 的管道

相關影片 同屬「eval 或監控」