如今企業發佈的程式碼數量比以往任何時候都多，這得歸功於代理式（agentic）程式設計工具。對產品團隊而言，加速的開發步調是一大福音。但對網站可靠性工程師（SRE）而言，湧入的新增、機器產生的程式碼卻是負擔。

為什麼？因為當系統出問題時，沒有人能完全理解底層系統的運作方式。要找出哪裡出錯、如何修復，以及如何避免未來重蹈覆轍，都既困難又耗時。同時，時間限制依然嚴格，停機所帶來的成本也和過去一樣不容忽視。

若把修復代理所撰寫程式碼的任務交給人類，很容易讓團隊成員精疲力竭；這做法本末倒置。

如果代理正在撰寫程式碼，而人類難以跟上，那麼解決方案是否應該以 AI 對抗 AI——部署 AI 代理來找出故障系統的根本原因？答案是肯定的。好消息是，隨著 AI 模型的進步，根因分析的能力正在提升，儘管 OpenRCA 基準仍遠未飽和。

由於這些效能提升，Sam Farid 與 Nate Heinrich 所屬的 Chronosphere（Palo Alto Networks 旗下公司）認為，代理正是前進的方向。他們兩人建議貴公司應先嘗試自行建置 AI SRE，再考慮供應商的解決方案。

Chronosphere 本身提供 AI SRE 產品，為何其前線工程師仍主張先自行打造？Heinrich 在《The New Stack》最新一集 podcast 中表示，他之所以鼓勵大家自行建置代理，是因為這過程能有效收集並整理公司系統運作的相關資訊。

最終產出是一份 Markdown 檔案，可作為代理在追蹤根本原因時的重要上下文；對願意投入的公司而言，收集資訊的過程本身既是旅程也是目的地。

當然，Chronosphere 相信，當公司嘗試自行打造內部 SRE 代理後，會發現需要一套遙測服務來收集日誌與追蹤，以及一套可觀測性工具來儲存與關聯這些資訊。而這些正是 Chronosphere 所提供的，同時也包含現成的 AI SRE。不過，我很欣賞與這兩位技術專家對談，他們並未一味推銷自家產品是唯一解方。

請點擊播放，享受這集內容。您或許會獲得勇氣，開始繪製內部系統地圖，以供未來的代理使用。畢竟，當凌晨時分系統崩潰，而您並非撰寫那段程式碼的人時，難道您不希望獲得協助嗎？

YOUTUBE.COM/THENEWSTACK

科技發展迅速，別錯過任何一集。訂閱我們的 YouTube 頻道，即可收看所有 podcast、訪談、示範以及更多內容。

Group Created with Sketch.