Replit Monitoring Agent：自動修復與自動上線，為何是兩個開關？
Replit Monitoring Agent 可調查正式 App 警報、嘗試修復並驗證變更。整理自動監測的三項訊號、Auto-fix 與實驗性 Auto-republish 差異、每個 App 的設定、通知及 Agent 用量費用。
App 已經上線，使用者卻突然遇到錯誤。對只有一兩個人的團隊來說，查紀錄、找原因、修程式再重新發布，常常得由同一個人完成。
Replit 在 2026 年 10 月 22 日推出 Monitoring Agent，讓代理讀取正式 App 的紀錄與指標，收到監測警報後嘗試調查、修復並驗證變更。
但自動修復與自動上線是不同設定。官方文件把 Monitoring alerts、Auto-fix 與 Auto-republish 分開，後者仍標示為實驗功能，也必須先啟用自動修復。
這個區別決定代理能做到哪一步：可以只通知、可以先改好讓人看，也可以在允許後把驗證過的修改重新發布。警報本身則不保證一定找到能修的原因。
我的判斷是，沒有專職值班人員的團隊可先利用代理縮短診斷時間，但應按 App 的資料與變更風險決定發布權限，尤其不能把資料遷移當成一般畫面修正。
先從警報實際看哪些訊號開始，才知道這個「值班代理」接手了什麼工作，以及哪些工作仍需要人處理。
Monitoring Agent 的自動警報看哪些訊號？
Replit 的自動檢查主要監看應用程式錯誤紀錄、HTTP 錯誤與請求延遲，並不是把所有營運指標都變成自動警報。HTTP 是網站交換請求與回應的方式，錯誤狀態能指出使用者這次操作是否遇到問題。
例如，一個假設的預約網站還能開首頁，送出預約卻持續失敗。單看網站是否活著，可能無法完整說明使用者的遭遇，因此應用程式錯誤與端點回應都能提供更細的線索。
請求延遲則反映完成操作要等多久。服務尚未完全中斷，也可能慢到影響使用。監測代理把這種異常與明顯報錯放進觀察範圍，讓調查不必等到整站失去回應才開始。
Replit 發布文把新功能接在先前的 App Monitoring 之後。舊的健康檢查與警報提供異常通知，新的代理嘗試往下接起診斷與修復，兩者負責的工作不同。
對創作者來說，應先知道一個警報是由什麼訊號觸發。它提供的是調查起點，不能只看到「代理正在處理」就假定所有使用者遇到的問題都已被涵蓋。
警報找到異常之後，代理才需要把正式資料與程式碼放在一起調查。
代理能讀哪些正式紀錄，如何縮小原因？
代理可運用正式環境指標、執行紀錄與程式碼調查，使用者也能主動指定時間、時區與端點請它分析。正式環境是使用者實際連線的版本，和編輯器裡正在開發的版本可能不同。
因此，錯誤出現在哪次發布之後，往往比一句「網站壞了」更有幫助。官方提供的提問範例包含查詢最近一小時的伺服器錯誤、失敗版本的執行紀錄，以及發布後的處理器與記憶體變化。
這些問題不需要先打開自動修復。使用者可以保留手動控制，請代理縮小調查範圍，再決定是否要修改程式，讓讀取與動手修改成為兩個可分別安排的工作。
自動觸發與按需查詢的範圍不同
官方文件列出的按需資料較廣，包含各端點流量與延遲、執行個體數、啟動時間，以及磁碟和網路用量，但可取得項目取決於部署類型與雲端供應商。
端點是 App 接收特定請求的位置，例如送出預約與讀取清單可能走不同端點。把時間和受影響的端點交代清楚，代理才更容易從整站紀錄縮到那條使用者流程。
延遲也可以看平均值以外的分布。官方可查的百分位數，能幫助觀察較慢的一群請求。只看平均值，可能忽略部分使用者一直等很久的情況。
例如，第九十九百分位延遲描述的是大約百分之九十九請求都落在其內的時間範圍。若平均看起來正常，但這個數值明顯拉長，調查方向便會偏向少數慢請求，接著再看它們是否集中在同一端點。
這些都是把問題問清楚的方法，並不是文件承諾代理已自動替每個 App 做同樣分析。創作者仍應提供事故時間與觀察到的行為，避免把不同時段的數字當成同一個問題。
能看到原因線索不等於一定能改好，下一步仍取決於問題是否在 App 可控制範圍內。
Auto-fix 會如何嘗試修復，何時可能無法處理？
啟用 Auto-fix 後，代理在背景調查警報、嘗試修改並驗證，但外部服務故障可能需要 App 以外的處理。官方明確使用「嘗試」來描述這段工作，警報沒有附帶修復成功保證。
例如，若 App 的程式在處理回傳值時出錯，代理可能有機會調整相關邏輯。若對接服務本身暫停回應，單靠修改 App 未必能恢復那個服務，創作者仍需要理解問題的位置。
這也會影響怎麼閱讀代理報告。找到可能原因、產生修改與確認正式問題消失，是不同階段。如果原因在外部，沒有程式變更也可能是一個有用的診斷結果。
若錯誤是在某次發布後開始，還要把代理看到的紀錄對回那個版本。否則開發中的程式已經修改，正式服務仍在舊版本，團隊可能以為問題修好了，使用者卻繼續遇到原本的錯誤。
代理調查時會結合程式碼與正式紀錄，嘗試驗證修改。驗證讓修復比單純產生一份建議更進一步，但文件沒有因此承諾每一種業務情境都會被自動測到。
對一個接受使用者資料的 App，創作者應知道變更影響的是哪條流程。錯誤紀錄減少能提供線索，卻不能直接證明預約內容、權限或其他行為都符合原本需求。
如果想把修復結果接回團隊既有審查，可搭配 AI 程式驗收流程，把程式正確性與人要確認的產品行為分別處理。
延伸閱讀：AI 程式驗收教學：人工審查、測試與逐步上線，各自能抓到哪些錯誤
修復有結果後，是否讓使用者接觸到新版本，仍由另一個發布設定決定。
Auto-republish 為何要獨立開啟？
Auto-republish 需要 Auto-fix 並仍屬實驗功能，單獨允許代理修復不會自動授權它把修改送到正式 App。這個開關決定自動化是否跨過「使用者會開始用到新版本」的界線。
若沒有打開自動重新發布，創作者可以在代理聊天裡看結果，再自行重新發布。若有打開，代理則可把驗證過的修復部署出去，並回報發生什麼事、改了哪些內容。
兩種方式的差異並不只是少按一次按鈕。保留人工發布，表示人可以先檢查變更內容與時機。自動發布則把這段決定提前交給既定設定，事故發生時便可能直接生效。
官方特別提醒，資料遷移與索引操作可能有風險。資料遷移會改變既有資料的結構或保存方式，索引則影響資料庫如何更有效找到資料，都比單純修改一段畫面文字更接近正式資料運作。
因此，一次修復通過驗證，與創作者願意讓它在任何時間修改資料環境，仍是不同問題。功能設定讓你選擇權限範圍，並沒有替每個 App 判斷可接受的影響。
選好發布責任以後，就能按每個 App 分別安排監測與修復設定，讓內部工具與重要服務保留不同的交付方式。
每個 App 如何設定，停用時會留下什麼？
監測設定以已發布 App 為單位，既有 App 的開關可以即時保存，不必為了改設定再發布一次。團隊若有內部測試工具與對外服務，可以分別設定，不必只選一種自動化程度。
依二〇二六年十月二十六日查閱的 Replit 文件，既有 App 從發布工具開啟設定後，可以先開啟監測警報，再選擇是否允許 Auto-fix，最後決定要不要啟用自動重新發布。
新 App 的首次發布畫面則有監測附加設定，修復與重新發布的選擇會從首次發布生效。這個時點差異值得留意，因為既有 App 調開關即保存，與等待下一次發布才生效並不相同。
不同組合會讓代理停在不同位置，可以先用這張表確認想交出的權限。
| 監測警報 | 自動修復 | 自動重新發布 | 可預期的工作範圍 |
|---|---|---|---|
| 開啟 | 關閉 | 關閉 | 收到異常訊號，修復由人安排 |
| 開啟 | 開啟 | 關閉 | 代理嘗試修復，人檢查後發布 |
| 開啟 | 開啟 | 開啟 | 代理可發布驗證過的修復 |
關掉自動重新發布，可以保留調查與修復，只把上線決定拿回來。關掉 Auto-fix，則停止自動調查與修復，但可以繼續保留警報，兩者適合不同的操作需求。
這些操作都回到該 App 的設定，不能由一封通知是否寄來推測。通知偏好又是另一個層次。
警報、信件與費用如何分開判斷？
關掉信件不會關閉監測或 Auto-fix，監測代理執行也可能產生 Agent 用量費用。想停止自動動作時，需要更改執行設定，僅清理收件通知並不會達成同樣效果。
個人的通知偏好可以選嚴重程度，帳號層級的收件人安排則由有權限的管理者處理。這讓「誰要知道事故」與「系統能對事故做什麼」可以各自調整。
監測工具裡的警報表也比信箱更適合追查狀態。Active 表示仍影響 App，Resolved 顯示近三十天已不再影響的問題，展開後可以看觸發原因與幾輪檢查偵測到異常。
一項警報從出現到不再影響服務，可能經過多輪觀察。保留這段狀態變化，能讓創作者對照修復與發布時間，而不是把一次收到通知當成事故的全部紀錄。
若顯示 Cannot measure，代表 Replit 當下無法評估該項，不能把它讀成狀態正常。遇到事故時，這個差別會影響人是否需要補上其他觀察方式。
Replit 的費用則應回到用量頁追蹤。代理每次調查需要讀取資訊與執行工作，官方沒有把這些運行一律列為免費，所以可依真實警報與代理活動，觀察維運功能增加的用量。
自動化擴及正式環境後，原本只有開發時才出現的 Agent 活動，也可能在使用者沒有開啟編輯器時發生。了解觸發來源，才看得懂它為何產生這些工作。
把警報狀態、代理活動與用量對起來後，團隊才看得出這項維運工作實際執行多少，再決定各個 App 要交出多少控制。
創作者要保留哪一段維運控制？
對正式服務，我會依變更對資料與使用者的影響，決定哪些 App 可以自動發布、哪些保留人工檢查修復結果。這個選擇可以按 App 分開，而不必因為期待自動維運，就一次交出所有發布決定。
如果一個 App 只是低影響的內部展示，團隊或許願意試驗較完整的自動流程。若它保存訂單、個人資料或重要作業狀態，先看診斷與修復內容，再決定發布時間，會更容易保留業務判斷。
Replit 先前談的 Self-driving company關注代理如何進入工程工作，而 Monitoring Agent 把相同方向推到使用者實際使用的服務。這也讓權限安排變得更具體。
延伸閱讀：Replit Self-driving company 是什麼？AI Agent 如何讓工程產出提高 2.9 倍
值得留下的工作紀錄，是哪個警報促成調查、代理找到什麼、修改哪些程式，以及新版本何時生效。這條路徑越清楚，創作者越能知道省下的是診斷時間，還是連發布也交給了系統。
Monitoring Agent 能把值班工作往前推一步，但最有用的起點仍是那幾個分開的開關。打開 App 的發布設定，按你希望保留的發布責任選擇組合，才是讓代理接手維運的具體方式。
常見問題 FAQ
Monitoring Agent 能幫任何網站值班嗎？
本次官方文件針對在 Replit 發布的 App，資料可取得範圍也依部署而異，沒有宣稱能直接接管所有外部網站。
關掉自動發布後，代理還能修程式嗎？
可以保留 Auto-fix，讓代理嘗試修復，再由人檢查並重新發布。自動發布是另一個需要明確開啟的設定。
不開自動修復，還能問正式環境的問題嗎？
可以。官方文件允許主動請代理查詢已發布 App 的紀錄與指標，不需要先啟用 Auto-fix。
