讓背景 agent 接手營運雜務

094Justin Smith（Resolve AI）24:562026-08-09 上架

Always-on agents run production without the on-call tax — Justin Smith, Resolve AI

Justin Smith 認為程式碼寫得再快，卡關的仍是上線後的營運。這場介紹 Resolve AI 的背景 agent：怎麼觸發、靠什麼理解環境，以及部署監控、例行報告、回答 Slack 問題的實例。

這場講了什麼

• 瓶頸在營運，不在寫程式：Justin Smith 引用一份調查，說工程師有 70% 的時間不是花在寫程式，而是花在維運已上線的程式。AI 讓出貨更快，上線後的問題也跟著變多。
• on-call 是起點，背景 agent 是重點：Resolve AI 一開始做的是 on-call agent，每個警報進來都能做分流與根因調查。這場把時間放在處理「沒有火災」時的營運雜務。
• 任務等於執行加上 production context：Justin 說執行只是載入儀表板，production context 才能判斷「這個指標看起來不對」。兩者缺一不可。要掌握 production context，得有一套學習系統記下服務之間怎麼互動、熱點在哪，而且跟著系統一起演進。
• 觸發方式有三種：排程（例如早報、每週四的 on-call 交接）、事件串流（部署管線、Slack 訊息），或直接用訊息交辦。agent 跑在雲端沙箱，闔上筆電也照常運作。
• 四類可以交出去的工作：部署監控、定期檢查、營運報告與交接，以及回答工程問題的第一線。Justin 強調這些只是他們看過成效好的用法，可以自己發揮。
• 互動留在原本工作的地方：任務用對話設定，結果出現在 Slack 或 MS Teams，想改報告長短就在討論串裡直接說。Justin 也提到所有功能都能透過 MCP server 接進自己的 agent harness。

影片從哪一段開始看15 段

1. 00:12開場與自我介紹Justin Smith 是 Resolve AI 的創始產品工程師之一，在監控與可觀測性領域待了 15 年以上，曾任職 Splunk 與 VMware。
2. 01:00第一波 AI 的副作用開發者出貨更快、PR 更大，連不懂程式運作原理的非開發者也開始出貨。
3. 01:52寫程式從來不是瓶頸引用調查：工程師 70% 的時間花在維運、除錯、on-call、更新 runbook 等上線後的事，而 AI 程式碼讓這些更難。
4. 03:50以 AI 對付 AI 帶來的複雜度答案是把 AI 用在 production 裡；Resolve 當初的假設就是寫程式變快之後，需要更多 AI 來營運系統。
5. 04:40on-call agent 與背景 agent每個警報都能分流、做根因調查，事件擴大成跨團隊時也有 agent 協助；另有處理長尾營運雜務的背景 agent。
6. 06:32學習系統的必要模型本身夠聰明，難的是長期掌握服務之間怎麼互動、熱點在哪，所以需要隨系統演進而成長的學習系統。
7. 09:08營運的長尾工作盯部署是否健康、早報、P99 飄移有沒有人看、容量報告、定期健檢，這些不在任何職務說明裡卻總得有人做。
8. 10:17任務是什麼任務是執行加上理解如何執行的 context；Justin 認為 production context 比執行更重要。
9. 11:22何時跑、怎麼跑可依排程、事件串流或訊息觸發；跑在雲端沙箱，有檔案系統，並靠記憶系統在不同任務間共用學到的東西。
10. 13:17部署監控CI/CD 的檢查只是基準線；feature flag、基礎設施變更常沒有任何監控，agent 可以補上這一塊。
11. 14:56其餘三類工作定期檢查（含限期盯一個第三方服務）、營運報告與交接，以及用 Slack 訊息觸發、回答工程問題的第一線。
12. 17:23示範：部署監控在示範環境裡，GitHub tag 一出現，agent 就判斷是 release，依變更內容擬出專屬的檢查計畫，並持續追蹤。
13. 19:59示範：報告與 Slack 頻道交接報告太冗長就在討論串裡要求縮短，agent 會更新任務本身；被動盯頻道時，也會自己決定要不要回應。
14. 22:15用對話設定任務對 agent 說想要一份定期健康摘要，它會先探索環境、問幾個問題，再建好初版讓人測試並分享給團隊。
15. 23:03收尾每家公司的工作都不一樣，要有創意地交辦；功能可經 MCP server 接入自家 harness，技能也能沿用。

值得記的話5 句

• So really coding was never the big bottleneck, right?所以說，寫程式從來就不是最大的瓶頸，對吧？02:10

• Prices are going up, companies are getting a lot more stringent on what's being used for AI.價格在漲，公司對 AI 用在哪裡也管得越來越嚴02:43

• it's one thing to go check a dashboard. It's another thing to say that metric smells off.去看儀表板是一回事，覺得某個指標不對勁又是另一回事10:32

• It's not hard for me to go answer questions, but it's disrupting me.回答問題對我不難，但會打斷我16:19

• And none of this is hard coded in.這些都不是寫死的19:15

名詞與人物7 個

Resolve AI

Justin Smith 任職的公司，做的是替 production 營運工作的 agent

on-call agent

Resolve 最早做的 agent，對每個警報做分流與根因調查

background agent

沒有緊急事件時，依排程、事件或訊息去做營運雜務的 agent，這場的主題

production context

對自家系統的理解，例如服務如何互動、熱點在哪，用來判斷某個訊號重不重要

learning system

記錄並隨環境演進更新對系統理解的記憶機制，讓不同任務共享學到的東西

deployment monitoring

依每次變更內容擬定專屬檢查計畫並持續追蹤，補 CI/CD 檢查不到的地方

MCP server

Justin 說 Resolve 的能力都能經由它接進其他 agent harness

提到但沒有展開

• Justin 說無限 token 的時代快結束了，所以需要 full stack AI：重點不再只是模型，而是模型周圍的 context，以及模型在特定領域裡能做什麼。
• Resolve 的 agent 能發 Slack 私訊，於是會先私訊工程師「我想我知道答案但不確定，回覆之前能幫我確認嗎」。Justin 把這叫做自然冒出來的行為。
• 部署監控的示範裡，那次 release 是 checkout 取代 currency service，agent 就決定盯 checkout 的延遲與錯誤率，再順著因果鏈檢查 Kafka pipeline；檢查時程也不是寫死的，可以讓它多等一小時，或三天後再回來確認部署是否還健康。

Agent開發工具產業觀察

在 YouTube 看原片 ↗