Replit Monitoring Agent 登場，修復與重新發布拆成兩個開關

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Replit 在 2026 年 10 月 22 日發布 Monitoring Agent（監控代理）。從這天起，發布在 Replit 平台上的 App 出狀況時，代理可以讀正式環境（production，使用者實際連線的版本）的紀錄與指標，調查警報原因、嘗試修復並驗證變更，最後在你授權的範圍內把修好的版本重新發布。適用對象是在 Replit 上有已發布 App 的開發者與小型團隊，設定按每個 App 分開配置，不會一次套用到整個帳號。

這次發布真正值得停下來看的設計，寫在官方文件裡：監測警報、自動修復（Auto-fix）、自動重新發布（Auto-republish）是三個各自獨立的開關。發布文把功能包裝成「每人一位自動值班工程師」，文件卻明確寫著 Auto-fix 本身不授權代理把變更發布到正式 App，自動重新發布則還掛著實驗功能的標籤。修好程式，與讓使用者實際用到修好的版本，是兩件事，中間那道門 Replit 留給開發者自己決定要不要交出去。

從通知到動手修，監控迴圈補上了後半段

今年稍早，Replit 先推出 App Monitoring，提供正式環境的健康檢查與異常警報：App 出狀況時你會收到通知，但接下來查紀錄、找原因、改程式、重新發布，仍然全部自己來，而這通常發生在一人團隊最不方便的時候。這也是 AI 做 App 浪潮的後半段課題：NBER 的研究量出，App 的生產速度明顯加快之後，瓶頸落在出貨與持續被使用，上線之後的維運正是其中一環。

Replit 在這次發布文（由 Akram Hussein 與 Carl Cortright 署名）把 Monitoring Agent 定位成把監控的迴圈「關起來」：代理不再只負責告訴你什麼壞了，還會往下接手診斷與修復，發布文甚至以「首款」形容這個能看、能修、能部署的代理。這是 Replit 自己的說法；實際上能走到哪一步，要看文件怎麼定義權限。

文件把自動修復的工作拆成三段。收到警報後，代理先結合正式環境指標、執行紀錄（runtime logs）與程式碼調查原因；找到可行的原因時，嘗試修復並驗證變更；驗證完成後，只有在自動重新發布也開啟的前提下，才會把修復發布出去，否則你是在代理對話裡檢視結果，自己決定何時重新發布。

Pin

舊的監控頁並沒有被取代：健康圖表、資源用量與可以直接翻看的紀錄，仍然在 Monitoring 工具裡自己查。新的代理接的是警報之後的行動層，與舊監控頁並行分工。

官方同時把這一步放進更大的願景：過去六個月，Replit 陸續上線黑箱資安掃描、成長分析系統與這次的生產監控，發布文以「自主軟體團隊」形容這個方向，讓代理分攤維運、資安與優化，人負責定方向。類似的路線也出現在 Cursor Projects 的常駐協調代理。願景歸願景，落到設定頁面，它是一次一個開關。

警報、修復、重新發布：三個開關分別管到哪裡

三個設定的關係可以想成一條權限階梯。

最底層是監測警報。開了它，Replit 的自動檢查會盯三種訊號：應用程式錯誤紀錄、HTTP 錯誤與請求延遲。它只負責通知，代理不會碰你的程式碼。既有 App 在發布設定裡打開後立即生效，不用重新發布一次；網站是否活著的可用性檢查則是另外管理，不混在同一個開關裡。

往上一段是 Auto-fix（自動修復）。開啟後，代理會在背景回應警報，做調查、嘗試修復與驗證三段工作。修復結果不會自己上線：你會收到事發摘要的信，並可以在代理對話裡看到發生什麼事、改了哪些內容；看過、同意之後再重新發布 App，修復才會真正生效。也就是說，這一段買到的是「醒來已經有人把原因查好、修好」，最後按下發布鍵的仍然是人。這種機器做事、人留核准權的分層，也是企業代理平台常見的設計，例如 Sakana Aquarium 就把供應商回覆接進人工核准流程。

最後一段是 Auto-republish（自動重新發布），文件標明它是實驗功能，而且必須先開啟 Auto-fix 才能打開。它讓代理把驗證過的修復直接部署到正式環境。官方在文件裡特別提醒，有些變更本質上風險較高，並且點名資料遷移與索引操作（index operations，影響資料庫查找資料的效率）這兩類。

新 App 的設定位置不太一樣：首次發布時，監測選項出現在流程中的建議附加項目裡，勾選後跟著首次發布一起生效，可用的平台也會順帶啟用可用性檢查（uptime checks）。

Pin

要退回來也簡單。關掉 Auto-fix 就停止自動調查與修復，警報可以留著繼續收；想讓修復繼續自動跑、但保留人工發布，就只關 Auto-republish。

警報只盯三種訊號，修復也沒有成功保證

兩個容易過度期待的地方，文件都先講明了。

先講覆蓋範圍。自動警報只看應用程式錯誤紀錄、HTTP 錯誤與請求延遲三種訊號，文件也明說這些檢查沒有涵蓋代理能調查的所有指標。這三個選擇有其邏輯：應用程式錯誤紀錄抓的是程式自己丟出的例外；HTTP 錯誤看的是端點回應的狀態碼，使用者這次操作有沒有被打回；請求延遲抓的是「還活著、但慢到影響使用」的中間地帶。三者加起來仍不是全部，換句話說，沒收到警報不等於沒有問題，只代表那個問題沒落在這三個探測器上。

再來是修復的成功率。文件用字很保守：代理在「找到可行的原因時」嘗試修復，而且「警報不保證有修復」。官方給的例子是外部服務出問題：如果你的 App 對接的服務本身停止回應，改自己的程式碼救不回那個服務，這類原因需要在 App 以外的地方處理。此時代理查了半天、回報沒有可做的事，仍然是有用的診斷結果，只是它不算修復。

驗證（validate）是流程裡最值得注意的一步。代理宣稱修好之前會先驗證變更，這讓修復比單純產生一份建議更進一步。文件沒有細說驗證涵蓋哪些行為，合理的解讀是對準警報與相關症狀：錯誤紀錄下降能佐證修復生效，卻不能證明預約流程、權限檢查這些業務規則全部符合預期。會動到資料結構的修復，正是官方點名的高風險區。代理權限擴大的同時，哪些防護該放在代理碰不到的地方，已經是這波產品共同面對的問題，OpenAI 先前公開的代理停用監控事件就是同一個方向的提醒。

不打開任何開關，也能把它當調查助手用

Monitoring Agent 有一個不必動到任何開關的用法：不等警報、不開 Auto-fix，直接在代理對話裡問正式環境的狀況。官方給的提問範例包括：「過去一小時為什麼出現 500 錯誤」「今天哪些端點最慢，比較它們的 p50 與 p99 延遲」「上次發布之後 CPU 與記憶體用量如何」「讀那個啟動失敗版本的執行紀錄」。文件建議提問時附上大概時間、時區與受影響的端點（endpoint，App 接收特定請求的位置），代理會用這些線索縮小調查範圍。

按需能查的資料，比三個警報訊號廣得多：整體流量的請求數、延遲、4xx 與 5xx 錯誤數及可用率；各端點的請求數、延遲與錯誤數，延遲還細分平均值與 p50、p95、p99 百分位數（percentile，按等待時間排序後的分布位置）；CPU 與記憶體用量、作用中執行個體數、啟動時間與執行個體存活時間；磁碟與網路用量；以及按嚴重度或部署版本過濾的錯誤紀錄。文件同時註明，可查項目取決於部署類型與雲端供應商。

把這些問題串起來，就是一次不需要開任何開關的調查流程。假設有使用者回報「送出表單一直失敗」：先問代理今天的慢端點與錯誤分布，把範圍從整個 App 縮到送出表單那個端點；再看錯誤是從哪個部署版本開始出現，請它讀那個版本的執行紀錄；必要時補一句「上次發布之後的 CPU 與記憶體用量」。這條路走完，你可能已經知道是哪次改動、哪個環節出事，要不要動手修反而是最後的決定。文件提供的按部署版本過濾紀錄，就是為了把「網站壞了」這種描述，對回一個可以查證的版本。

只看平均延遲會漏掉慢的那群使用者，是監控的經典陷阱；能把 p99 拉出來問，對「大部分人都說正常、少數人一直轉圈」的客訴特別有用。把「讀資料」與「改程式」當成兩件可分開安排的事，是這個功能在自動修復之外更平實的一面。

信箱分級與帳單：自動化的兩個附帶安排

警報通知本身有一層治理。個人層在設定的 Notifications 頁，可以把監測警報信分成五個等級：只收嚴重（Critical）、High 以上、Medium 以上、全部，或者不收信。帳號層另有收件者設定，管理員可以選擇關閉、只寄給管理員或自訂收件者，並設一組獨立的嚴重度門檻。這兩層是分開的：個人的信箱偏好，不會覆蓋帳號層已經設好的收件者安排。文件特別註明：關掉信件不會關掉監控或 Auto-fix，信箱安靜了，代理還是在跑。

看警報的地方在 Monitoring 工具的警報列表：Active 列出目前影響 App 的問題，Resolved 保留近 30 天內已不再影響的問題；Replit 暫時無法評估的警報會標示 Cannot measure。

帳單是另一件要在開啟前想清楚的事。文件寫明 Monitoring Agent 的執行可能產生 Agent 用量費用，支出狀況要在帳號的 usage 頁追蹤。自動修復在背景執行，半夜沒人盯著也不會暫停；費率數字文件沒有提供，開啟前後各看一次 usage 頁，是最實際的作法。

官方還沒回答的三件事

這次發布有三個問題，兩份官方文件都沒有給答案。修復成功率是多少？官方只說會「嘗試」，沒有提供任何比例或基準。Auto-republish 何時脫離實驗階段？沒有時間表。Monitoring Agent 的用量怎麼計費？文件只說要自己去 usage 頁看。實驗標籤也代表設定與行為可能隨版本調整，操作前以官方文件目前寫的為準。

可以確定的是設計立場：Replit 把「看到問題」「修好問題」「把修復上線」定成三段可分開授權的權限。對資料單純的靜態網站，三段全開、換取沒人值班的半夜也能自動恢復，是合理的取捨；對會動到資料庫結構的 App，官方點名的遷移與索引風險，就是保留手動發布那段的理由。開到哪一段，反映的是你對這個 App 出事時可接受的自動化程度，而不是對代理的信任投票。

如果還在猶豫，階梯本身就是路線圖：先只開警報跑一兩週，看看三種訊號在自己的 App 上吵不吵、有幾次是真的問題；覺得警報值得回應，再開 Auto-fix，親自看幾次它修了什麼；至於 Auto-republish，等它摘掉實驗標籤、或等你的 App 真的發生一次「修好了卻拖到早上才發布」的事故，再考慮也不遲。