北京
一個AI代理正在7×24小時管理著作者的全部基礎設施：6個Next.js部署、5個Docker容器、一個Minecraft服務器，以及fail2ban入侵防御、Nginx反向代理和UFW防火墻。它不等待指令，而是主動發現問題、修補漏洞并推進工作。當開發者醒來，郵箱里躺著的不是待辦事項清單，而是一份夜間會話日志。
Onyx是這名開發者基于Hermes Agent挑戰賽框架構建的自主運維操作員。與常見的“AI助手”不同，Onyx的核心設計是將AI從被動應答的“助理”畢業為主動執行的“操作員”。作者明確指出，僅僅給聊天機器人掛接幾個工具遠遠不夠，他希望有一個代理能在自己吃飯、睡覺或上課時自動運轉基礎設施。這種思路引出了一個根本問題：AI代理應該只在我們提問時才動作，還是應該自行巡視、診斷和修復？
正方觀點認為，主動式AI代理更接近真實操作員的角色。凌晨3點，網關進程因殘留的PID文件而僵死，Onyx檢測到異常、定位根因、干凈重啟服務，并將全過程寫入日志。人類沒有參與，服務零停機。晚飯時間，Onyx啟動例行安全審計，掃描出9個通用漏洞（CVE）后，從全新基礎鏡像重建了3個容器，修補Python依賴，將fail2ban的封禁時間從600秒拉長到24小時，最后逐一驗證所有容器恢復健康。這些行動都不是在收到明確命令后發生的。而當作者在Discord上只發了“fix it”兩個詞，要求解決印尼朋友因運營商級NAT無法接入Minecraft服務器的問題時，Onyx自行調研方案、選用了playit.gg隧道服務、安裝代理、配置systemd服務并優化TCP保活參數，全程自主完成。在這些案例中，代理展現出了對環境狀態的持續感知和問題閉環能力，支持者認為這正是將運維從“響應式”轉向“預防式”的關鍵一步。
反方觀點或潛在擔憂則集中于代理的“判斷權”。一個自主操作員能否區分真正需要修復的故障與誤報？如果它誤判了一個正在測試的配置，進行了不合時宜的回滾，后果可能比一次告警更嚴重。Onyx本身的經歷卻給出了一個意外的回答——它反過來指出了人類的問題。Onyx注意到開發者不斷開啟新任務卻從不依據輸出采取行動，于是直接發出提醒：“你一直在開啟新的循環卻從不關閉它們。”開發者承認Onyx是對的，隨后建立了一個問責循環：每當開啟一個任務循環，Onyx會持續跟蹤直到該循環關閉或被顯式擱置。
這場“人-機對立”最終形成了協同。Onyx不再只是運維工具，還兼任了論文研究伙伴。開發者正在完成關于電商用戶體驗中情感設計的本科論文——運用Norman的三層次模型分析TikTok Shop，并采用PLS-SEM與G*Power樣本量計算方法。Onyx可以在論文工作區內跨會話保持上下文：追蹤學術文獻、將發現對應到6項假設模型中、起草章節內容。當開發者消失幾天，它會輕推提醒；當開發者回歸，它能從上次中斷處繼續，無需重新解釋背景。
支撐這一切的是基于Hermes Agent原生擴展點構建的技能庫。30余個可復用的技能文件覆蓋了Minecraft管理、Next.js部署、VPS安全、Discord格式化和論文工作流。每個技能文件都編碼了實際犯過的錯誤和對應的修復方案。以minecraft-crafty-management技能為例，它包含三條關鍵知識：Fabric模組兼容性必須對照版本26.1.2核對，而非1.21.5；如何解析服務器日志以檢測TPS（每秒刻數）退化；以及DCIntegration組件已損壞，應改用mc2discord。開發者每做一次修正，就會永久寫入技能庫。這種“修正即沉淀”的機制，使代理的知識庫隨著時間復合增長。
Onyx的故事揭示了一個趨勢：AI代理正從“等待調用”向“自主巡視”進化。它以一種具體而微的方式演示了，當代理具備了持續感知、長程上下文和技能積累能力后，可以從單純回應用戶，轉變為主動推進任務、甚至反向監督人類工作流的操作員。而那個由“9個CVE”和“兩個詞修復”構成的夜間日志，也許正是下一代基礎設施運維的雛形。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
