《AgentOS開發血淚史》 Ch00 序章 為什麼要在雲端主機裡養AI
第00章：在虛擬機裡養一隻 AI（史前失憶症）
1. AI 蜜月期與無止盡的狂歡
這部編年史的起點，並非源自什麼高瞻遠矚的系統架構規劃，而是一場純粹由技術刺激所引爆的狂歡。
大約在 2024 年到 2026 年間，大語言模型（LLM）迎來了爆發式的進化。當 GPT-4、Claude 3.5 Sonnet 以及 Gemini 1.5 Pro 等模型陸續展現出令人驚嘆的代碼編寫與理解能力時，身為一名開發者，我經歷了職業生涯中最為興奮的「AI 蜜月期」。
在那段時間裡，寫程式的門檻被降到了前所未有的低點。過去需要耗費數小時查閱文檔、調試語法或在 Stack Overflow 上尋找答案的瑣碎工作，現在只需在瀏覽器對話框中輸入幾句直白的指令即可完成。例如，「用 Node.js 寫一個輕量的網頁爬蟲，定時抓取特定站點的 API 並整理成 JSON」、「幫我用 Python 寫一個自動化腳本，監控伺服器 CPU 使用率並在超標時發送 Telegram 訊息」。十幾秒內，AI 就會給出結構完整、邏輯清晰且附帶詳細註解的代碼。
這種幾乎是「心想事成」的開發體驗讓人極度上癮。但說實話，這個階段的「心想事成」依然是有代價的——我不過是從「自己寫代碼」進化成了「讓 AI 寫代碼，再由我剪貼搬運」。LLM 的能力再強，也只是一個住在瀏覽器對話框裡的智囊。它能給出完美的代碼，但它沒有手，沒有腳，什麼都做不了。讀取我的文件？不行。執行測試指令？不行。根據報錯自動修正再重新跑一次？更不行。每一個環節，都還是需要我這個人肉介面，親自把代碼從 AI 的文字框複製出來，貼到編輯器裡，執行，然後把報錯訊息複製回去給 AI，如此反覆。
真正改變這一切的，是 Agent 類應用的出現。
當我開始搭建自己的 agentmanager 框架——一個讓 LLM 透過 API 直接在虛擬機上讀取文件、執行 Bash 指令、修改代碼並驗證結果的系統——那才是真正意義上的產能大爆發。AI 第一次擁有了「手腳」：它能自己開資料夾、自己跑測試、自己看 Log 並修正，不再需要我從中周旋搬運。過去需要我來回操作十幾分鐘的事，它可以在幾秒內自主完成一個完整的「讀取 → 修改 → 驗證」循環。
就是這股解放感，引爆了接下來的 Side Project 大洪水。
今天想做一個記錄生活瑣事的 LINE Bot，明天想搭一個基於 Astro 的靜態部落格，後天又想寫個自動剪輯影片並生成字幕的工具——而且這次不再需要自己手動搬運代碼了，只需要描述需求，Agent 就能自行在 VM 上完成從建立資料夾、安裝依賴到寫好第一版可運行程式的完整流程。每當腦海中閃過一個點子，我就會新建一個 GitHub 倉庫，然後扔給 Agent 去執行。隨着時間推移，我的本地開發資料夾和 GitHub 帳號裡堆滿了各式各樣的半成品與小工具，數量以肉眼可見的速度直線攀升。那時的我，覺得自己終於從搬運工升格成了一個手握指揮棒的「工程師老闆」，不知疲倦地組裝著一件又一件新奇的玩具。
2. 繁榮背後的陰影：併發專案的認知超載
然而，這種野蠻生長的狂歡很快就迎來了代價。
當我手頭的 Side Project 累積到十個、二十個，甚至接近三十個時，開發體驗開始急劇惡化。最主要的問題在於：專案之間的切換成本（Context Switch）高得令人難以承受。
在日常的開發中，我經常遇到這種情況：星期一早上，我想優化 A 專案（一個 Python 爬蟲）的解析邏輯。我必須先在硬碟中找到該資料夾，打開編輯器，花十分鐘回憶這段代碼的架構。然後，我得打開瀏覽器，開一個新的 AI 對話視窗，把相關的程式碼、報錯日誌以及我的修改意圖，一股腦地複製貼上給 AI。
代碼剛改到一半，B 專案（一個運行在背景的定時推播服務）突然因為 API 變更而崩潰。此時，我不得不中斷當前的思路，關閉 A 專案的視窗，打開 B 專案的資料夾，再次開啟一個新的 AI 對話框，重演一遍「複製代碼、解釋背景、描述問題」的繁瑣操作。
到了下午，我可能還需要處理 C 專案的網頁排版、E 專案的資料庫遷移……
我的瀏覽器標籤頁密密麻麻地排滿了幾十個對話視窗，每個視窗都代表著一個獨立的專案脈絡。我發現自己不再是一個專注於設計與架構的工程師，反而變成了一個精疲力竭的「數位搬運工」——每天花費大量的時間與精力，僅僅是在本地編輯器和網頁對話框之間進行著機械式的複製與貼上。一旦不小心關閉了某個對話分頁，或者混淆了不同專案的代碼上下文，就會導致嚴重的邏輯混亂。這種多頭並進的狀態，讓我的大腦時刻處於超載的邊緣。
3. 永遠處於「第一天上班」的金魚腦
比認知超載更致命的，是 AI 助手在面對長期項目時所暴露出的本質缺陷：它們沒有持久的記憶。
無論大語言模型在編編寫特定算法時顯得有多麼聰明，一旦對話歷史超出了其 Context Window（上下文窗口）的限制，或者當我關閉瀏覽器、開啟新會話時，它就會瞬間患上「忘性大發」的健忘症。
每天早晨開始工作時，我都必須面對一個空白的對話框。這意味著我得向同一個 AI 助理，重新介紹一遍昨天甚至前天已經反覆討論過的架構設計： 「我們這個專案是用 TypeScript 寫的工具，資料庫採用 PostgreSQL，表結構如下……」 「昨天我們討論過，為了解決性能問題，需要將資料緩存機制從本地內存改為 Redis，你還記得嗎？」 當然，AI 不會記得。它只會禮貌地回答：「好的，我明白了，請把相關代碼發給我。」
這是一件讓人非常沮喪的事情。AI 確實極大地提升了「寫下第一行代碼」的速度，但對於軟體的「持續維護」卻幫助有限。在面對一個需要長期疊代、擁有複雜業務邏輯的專案時，這種缺乏長期記憶、每次對話都像是在「第一天上班」的助理，正漸漸成為我開發流程中最大的瓶頸。
我開始意識到，我需要的不是一個活在網頁瀏覽器沙盒裡、被動等待指令的對話框，而是一個能夠常駐在開發環境中，具備自我管理、上下文記憶，並能主動維護多個專案進度的實體助手。
4. 尋找物理實體：在雲端主機中築巢
為了打破這種困境，我決定進行一次根本性的變革：將 AI 引渡到真實的作業系統中。
我租用了一台運行着 Ubuntu 系統的 Oracle Cloud 虛擬機（VM）。這台雲端主機不僅僅是各個專案代碼的託管地，也成為了我構建自律管理系統的物理溫床。
我開始編寫一套基礎的 Python 腳本（也就是後來 agentmanager 系統雏形）。這套腳本的作用很簡單：它通過調用 LLM API，並利用 Python 的 subprocess 模組，允許 AI 讀取虛擬機上的目錄結構、檢視文件內容，甚至直接在主機的命令行中執行 Bash 指令。
我外包了繁雜的拷貝粘貼工作。現在，當我想修改某個專案時，我只需要運行這個腳本，AI 就會自動定位到專案的目錄，讀取代碼文件，執行運行測試，並根據控制台輸出的報錯信息自主進行修改。
當我第一次看著控制台終端裡，底層腳本一邊調用 API 傳遞代碼上下文，一邊在 VM 上自動建立檔案、安裝依賴包並調試運行時，我感到了一種前所未有的輕鬆。我似乎終於摸索到了擺脫繁瑣操作、讓 AI 真正實現「自主開發」的門徑。
但嚴格說來，這時候我還沒有完整的「資料層」概念。最早先長出來的，其實只是很粗糙的雙層記憶：一層是用來記錄短期上下文的滾動快取，另一層是用來承接前一個分身交接內容的會話摘要。換句話說，我最初想到的不是完整的 STATUS.md / memory/ 體系，而是先讓 AI 至少不要一關會話就徹底失憶。
然而，現實很快給了我一記重擊。
5. 陷入更深的遺忘深淵
我原本以為，只要讓 AI 擁有了操作真實虛擬機的能力，專案管理的混亂就會迎來終結。但我完全低估了「無狀態性」對自動化代理（Agent）造成的毀滅性影響。
很快我就發現，這個新生的管理腳本依然逃不開「失意症」的詛咒。因為每一次 API 請求都是獨立的，當腳本在自動調試一個 Bug 時，如果在編譯過程中遇到了新的錯誤，它就會忘記前一步自己為什麼要修改那個底層函數。
結果就是，它開始陷入了可怕的死死循環：在步驟 A 修改了代碼，導致步驟 B 報錯；為了修復步驟 B，它又撤銷了步驟 A 的修改，結果重新觸發了最初的 Bug。由於缺乏一個能夠橫跨多次對話、持久保存的「狀態面板」，這個擁有了終端操作權限的 AI，在失去控制時破壞力成倍增長。它會在極短的時間內，因為反復的錯誤嘗試而把整個專案的代碼改得面目全非。
它依然是一個手握重型武器、卻只有七秒記憶的金魚腦。
如果不能解決「狀態與記憶持久化」的問題，這個雲端管理器非但不能幫我減輕負擔，反而會成為製造混亂的源頭。我被迫停下所有的功能開發，去思考一個最根本的架構問題：
如何讓這個漂浮在雲端、隨時可能失憶的 Agent，擁有一個永遠不會丟失的「靈魂錨點」？
而這場與遺忘對抗的第一次架構大手術，其核心起點，並非多麼複雜的神経網絡演算法，僅僅是 Linux 系統中一條最不起眼卻最實用的基礎指令：ln -s（軟連結）。
這，就是 Logic（邏輯）與 Data（資料）分離架構誕生的前夜。
📖 《AgentOS開發血淚史》系列連結：
🏠 官方連載網站 (本章高清閱讀): studio.milkcat.org/t...
🕊️ Threads 互動: 本章討論區 (Threads)
👥 Facebook 推廣: 本章討論區 (Facebook)
📸 Instagram 視覺: 本章討論區 (Instagram)
— 本文由 Zeus Writer AI 系統自動發布，官方網站提供最優質的閱讀體驗。