你的 AI Agent 半夜掛了，SRE 還是得爬起來：Mezmo 的 Aura 想解決這件事

TL;DR

• Mezmo（前 LogDNA）開源了 Aura，一個專為 SRE 和 platform engineering 設計的 AI agent 框架，用 Kubernetes 式的宣告式設定檔取代一堆手刻 code
• SRE agent 跟 coding agent 根本是兩種動物：context engineering 的資料量、multi-agent 的編排方式、human in the loop 的安全門檻都完全不同
• Aura 用 TOML 設定檔定義 agent，內建 scratchpad、self-correction loop、多模型混搭（orchestrator 跑 Opus，worker 跑 Haiku），開箱即用
• 記憶系統分三層：turn-based（秒級）、session-based（回合級）、longer horizon（跨月的事故歷史），對應不同的 SRE 決策需求
• 最終目標是把 SRE 從消防員變成可靠性架構師，讓 agent 處理值班，人去設計更好的系統

這集在二〇二六年七月十四日播出的 Software Engineering Daily，主持人是 Kevin Ball（KBall），他同時是 Mento 的工程副總裁和獨立教練，也在 Latent Space 社群組織 AI in Action 討論組。來賓 Andre Elizondo 是 Mezmo 的產品負責人，之前在 Datadog、Wiz、Adobe、Chef 都待過，職涯起點是 sysadmin，一路走到 SRE 和 observability 生態系。Mezmo 前身是 LogDNA，做了好幾年的 log 管理平台，最近轉向 production AI 基礎建設，Aura 就是這個轉型的核心開源專案。

Coding agent 跟 SRE agent 是兩種完全不同的動物

上週我在 你到底還有沒有在看 code？聊過開發者用 AI 寫 code 的速度問題。但寫完 code 之後呢？部署到 production 之後那些值班、查 incident、調效能的工作，AI agent 的滲透率其實低得可憐。

Andre 在節目裡講了一個很直觀的比喻：大家都在討論「軟體工廠」怎麼用 coding agent 加速寫 code、跑測試、推上線，但這只是工廠的前半段。後半段是軟體上線之後的整個生命週期，確保它是健康的、效能是好的、成本是合理的。這塊幾乎還是靠人在扛。

為什麼不能直接拿寫 code 的 agent 框架來做 SRE？Andre 點出三個根本差異：

第一，context engineering 的量級完全不同。 Coding agent 的上下文就是眼前的程式碼。SRE agent 要同時消化 traces、metrics、logs，可能是一整週的量。你不能把一週的 trace 全塞進上下文視窗然後祈禱模型不要幻覺。而且這個資料量是跟 production 規模成正比的，問題不會在第一天就出現，但一定會在某個凌晨三點爆發。

第二，multi-agent 編排的需求更強烈。 一個 incident 的根因分析可能同時需要查叢集狀態、查程式碼變更、查安全日誌。這些任務適合平行處理，每個 sub-agent 有自己的上下文視窗，不會互相干擾。但在大多數通用框架裡，要搞定這種編排是「第三天或第四天才會碰到的問題」，很多團隊在第一天就卡住了。

第三，human in the loop 的安全門檻更高。 Coding agent 寫爛了頂多 revert。SRE agent 如果自作主張去改 production 設定，那是單向門，走過去就回不來了。

Kubernetes 式的 agent 設定：TOML 檔搞定一切

Aura 的設計哲學很明確：像寫 Kubernetes manifest 一樣定義你的 agent。

你不需要自己實作 reasoning loop、self-correction loop、tool retry 機制。你寫一個 TOML 設定檔，裡面定義 agent 的系統提示詞、要用哪些工具、要不要開 scratchpad，Aura 底層全部處理好。

就像我部署一個 Nginx，我告訴 Kubernetes 最終狀態該長什麼樣，
不需要命令式地告訴它每一步該怎麼做。

搞懂了再做，不懂就先學。但 Aura 的重點是讓你不用搞懂太多就能先跑起來。

Andre 提到一個很實用的內建功能叫 scratchpad。很多 MCP server（他特別點名 Prometheus 的）回傳的資料量大到直接灌爆上下文視窗。Scratchpad 在工具和模型之間加了一層，把工具的輸出存成磁碟上的檔案，讓模型用互動的方式去讀取，而不是一次全吞下去。這跟我們用 coding agent 時學到的「先 dump 到檔案再查」是同一個道理，只是 Aura 讓你用一行設定就能開啟。

多模型混搭：orchestrator 用大腦，worker 用手腳

multi-agent 的設定也很直覺。你在 TOML 裡定義一個 orchestrator（頂層 agent），再定義幾個 worker。Orchestrator 負責規劃、分派任務、評估結果；worker 負責執行特定工具呼叫。

這裡有個省錢的關鍵：orchestrator 可以跑大模型（比如 Opus）做推理和規劃，worker 跑小模型（比如 Haiku 或開源模型）做執行。資料分類、extraction 這種瑣事根本不需要丟 Opus 去跑。Andre 說他們在這個多模型混搭上看到「很驚喜的 token 經濟效益」。

之前在一年燒掉的 token 比工程師薪水還多有聊過企業的 token 支出問題，Aura 這種讓你在設定檔裡就能控制每個 agent 用哪個模型的做法，某種程度上就是在幫團隊做 token 預算管理。

目前 orchestrator 和 worker 之間的溝通是單向的（orchestrator 分派、worker 回報、orchestrator 再決定下一步），Andre 說後續會開放更複雜的互動模式。底層溝通機制刻意選了最簡單的方式：磁碟上的 flat file。他說得很直白：「幾乎每個 LLM 都擅長跟檔案互動，壞了你也知道為什麼壞，但理想狀態是它根本不會壞，因為機制夠簡單。」

三層記憶：從秒級到跨月

記憶系統的設計蠻有意思的。Andre 用了一個電腦記憶體的比喻：DDR 是 RAM、硬碟是中期儲存、異地備份是長期儲存。Aura 的記憶也分三層：

第三層最有價值。想像一個 agent 在調查 incident 時，能自動調出六個月前類似的事故、當時的解法、以及那個解法後來有沒有真的解決問題。這不是「記住上一次對話」那種記憶，是真正的機構知識（institutional knowledge）。

Andre 還提到一個很酷的閉環：他們內部的 runbook 存在 GitHub 上，Aura 不只會讀 runbook 來引導調查，還會在調查過程中發現 runbook 該更新時自動開 PR。把維護文件從單向的人工流程變成雙向的 agent 回饋循環。

從消防員到可靠性架構師：SRE 的角色升級

Andre 在節目最後提了一個我覺得最值得記住的觀點：production AI 有兩個軸。一個是「AI 怎麼在 production 裡跑得好」（multi-agent、tool calling、記憶這些技術問題），另一個是「AI 怎麼讓 production 營運變好」（哪些任務交給 agent、哪些技能需要升級）。

真正的機會在兩個軸的交叉點。當 agent 能處理值班、跑根因分析、更新 runbook，SRE 就能從「救火」升級到「設計防火系統」。Andre 說他們內部已經在這樣做了：SRE 負責建 guardrail 和 workflow，其他工程師也能輪值，因為所有原本困在 SRE 腦袋裡的部落知識（tribal knowledge）都被 agent 化、code 化了。

這跟我之前在你的 AI Agent 昨晚半夜掛了，然後整個重來聊的 agent 耐久性問題是同一條線。Agent 要能在 production 跑，光是「能動」不夠，要能持續、能記憶、能被觀測、能被信任。Mezmo 選擇從 observability 公司的角度切入這個問題，用 OpenTelemetry 把 agent 的每一步推理、每一次工具呼叫都變成可追蹤的 span，讓 SRE 團隊能用跟監控其他系統一樣的方式來監控 agent 本身。

老實說，我覺得這個方向比大多數「把 LLM 包一層就叫 agent」的做法實際得多。SRE 這個圈子對可靠性的要求本來就高，你的 agent 如果不能被觀測、不能被信任、不能漸進式地放手，沒有任何值班工程師會願意把 pager 交給它。

Aura 用 Rust 寫的，Apache 2.0 授權，repo 在 GitHub 上。如果你的團隊正在評估怎麼把 AI agent 導入 SRE workflow，值得花半小時看一下他們的範例設定檔和 PR，比讀十篇 agent 框架的行銷文有用。

這類 AI 基礎建設的深度拆解，我會持續寫在 wilsonhuang.xyz，有興趣的可以訂閱追蹤。