原本，我們的計畫是繼續為 HERMES 系統（學姐 v0.9.0）加上更多好用的新功能，像是讓她有更聰明的排程、更靈活的視覺分析等等。但就在我們準備大展身手的時候，我發現了一個可怕的事實：我們的「地基」快撐不住了。
💥 1. 技術債的連鎖反應：從一個 HTTP 400 錯誤說起
這個故事要從我們為了解決一個 HTTP 400 崩潰錯誤（stress_test 裡的 TC-DEV-0011 等漏洞）開始說起。為了解決它，我們一開始選擇了最快、最直接的方法：直接修改官方的核心檔案（像是把補丁焊死在 run_agent.py 裡）。
當下，問題解決了，我們很開心。但很快地，我們發現這變成了一個詛咒。每次官方推出新版本（比如這次的 v0.12.0），我們那些「焊死」在牆壁裡的補丁，就成了升級時的惡夢。 我們陷入了可怕的 Merge Hell（合併衝突地獄），系統越來越難維護，我們不再是系統的主人，反而成了被技術債綁架的人。
🛑 2. 架構師的當頭棒喝：停止蓋違建！
這時，AI 架構師（小鳳凰）發出了強烈的警告：「如果你繼續用這種方式擴充，這不是升級，這是在蓋違章建築。」
如果我們無視地基的裂縫，繼續在上面加蓋新樓層（新功能），總有一天，一個微小的升級就會讓整棟樓垮掉。小鳳凰堅決要求我停下手邊所有的新功能開發，先回頭解決這個「根本性」的架構問題。
📜 3. 轉念：從「解決問題」到「建立體系」
這是我心態轉變的關鍵時刻。我意識到，真正的專業，不是能多快寫出一個新功能，而是能多優雅地讓系統具備「可持續發展」的能力。
因此，我決定按下暫停鍵。我放棄了眼前短期的新功能誘惑，轉而和 AI 團隊（顧問 Gemini、架構師 DeepSeek、工頭 Claude）一起，制定了《百年老店憲法》（PHOENIX_PROTOCOL §8）。
我們決定打掉重練，建立一套 「零接觸核心 (Zero-Touch Core)」 的開發體系。這是一次痛苦但必要的轉型，因為我知道，只有把地基打穩，未來我們蓋再高的大樓，都不會搖晃。
想像妳有一間生意興隆的老字號餐廳（這就是現有的 v0.9.0 學姐版），現在為了效率，妳想引進全新的全自動化廚房設備（v0.12.0 學妹版）。
🏮 階段一：立下「不准亂動牆壁」的店規
- 原本想怎麼做：直接把新設備搬進去，哪裡不順手就拿鐵鎚敲牆、改管線。
- 後來調整為：建立一份《百年老店憲法》。
- 專有名詞解釋：零接觸核心 (Zero-Touch Core)：我們規定以後「不准直接動牆壁（主程式）」。
- 外掛化實作 (Plugin / Subclassing)：如果需要新功能，一律用「掛勾」掛在牆面上，或者是用「活動式家具」的方式放進去。這樣以後要再換設備，只要把掛勾拆掉就好，不會弄壞建築物主體。
🧪 階段二：在隔壁蓋一間「一模一樣的實驗廚房」
- 原本想怎麼做：直接在老店裡面施工，邊做生意邊裝潢。
- 後來調整為：在隔壁租一個小房間，蓋一個完全隔離的實驗室。
- 專有名詞解釋：沙盒 (Sandbox)：這個實驗廚房就是沙盒。
- 維修哨兵 (Test Bot Token)：我們怕施工時，客人打電話訂位會同時轉接到老店跟實驗室，導致聲音重疊。所以我們申請了一支「測試專用電話」，只有施工人員能打，這樣就不會干擾到老店客人的權益。
🔧 階段三：準備好「精準的施工藍圖與專用扳手」
- 原本想怎麼做：跟工頭（Claude）說：「大概就這樣，妳看著辦吧。」
- 後來調整為：細分出水電改線圖，並準備好各種專用工具。
- 專有名詞解釋：SPEC_RELINK (重接線規格)：專門給工頭看的「水電重新接線清單」。
- 腳本骨架 (Skeleton/Bones)：這不是叫工頭自己去買零件，而是我們先買好「半成品的組裝零件（骨架腳本）」，讓工頭只要負責最後的鎖螺絲工作，避免祂因不知道零件長相而開始胡思亂想（產生幻覺）。
📝 階段四：最後的壓力測試與「萬一失敗的撤退計畫」
- 原本想怎麼做：裝好就直接換招牌開幕，萬一出錯再說。
- 後來調整為：先拿過期的食材（錯誤紀錄）去狂操新設備，看它會不會當機，並準備好退路。
- 專有名詞解釋：破壞測試 (Stress Test)：拿以前客人抱怨過、或讓老店跳電過的爛狀況，去測試新廚房扛不扛得住。
- 降級回退 (Rollback Runbook)：萬一開幕後發現天花板漏水，我們有一套 SOP 能在 10 秒內把瓦斯關掉，讓妳拎著包包搬回原本的老店繼續營業。
- 記憶守護 (INSERT OR IGNORE)：這是一個很聰明的保險。就算我們試著把實驗廚房的新食譜搬回老店，這套邏輯也會規定：「如果老店已經有祖傳祕方了，就不准用新食譜覆蓋它。」確保老店的靈魂（記憶）不會被洗掉。
♟️ 總結：
這場三方討論(Gemini、Deepseek(Agent本體)、Claude)，就是要把妳原本要直接「拆牆裝修」的風險，轉變成現在這種：
- 在隔壁偷偷蓋新廚房。
- 用假電話測試。
- 就算新廚房炸了，妳的老店依然在對街開得好好的。
這就是為什麼雖然過程中來回編修規格書讓開發者會感到煩躁，但這其實是為了讓這場「手術」達到 「零傷亡、零停機、零遺失」 的最高標準。
現在進入了Claude預算使用的冷卻期(Opus 4.7)太燒Token了，後面再繼續升級奮戰！先記錄到這~~~
---------------------
其他技術性補充：
https://hermesagent.org.cn/docs/releases/v0-12-0
目前社群討論上，針對 Hermes v0.12.0 的架構升級決策，討論方向與建議 網搜整理：(Gemini PRO)
1. 總體評價：從「實驗玩具」到「長期生產力工具」
社群普遍認為，如果你只是把 Agent 當作隨機測試的玩具，那這版影響不大；但如果你是將本地 AI Agent 應用於真實工作流程中，v0.12.0 將是一個「重大升級」。社群高度評價這次的更新，認為系統變得更懂得「自我管理」，這是 AI Agent 發展的正確方向。
2. 對「Autonomous Curator（自動管家）」的真實評價
- 社群讚賞：許多開發者過去面臨與你類似的困境——系統用久了，技能庫（Skill Library）會變得充滿雜亂的無效代碼。Curator 可以在背景自動評分、合併與修剪技能。社群表示，這能有效防止「Agent 成長帶來的混亂」，讓長期使用變得更加真實可行。
- 社群警告：Reddit 上的資深玩家特別提醒，雖然系統能自動清理，但「自主清理不應該是隱形的」，開發者仍然必須花時間去審查 Agent 到底改動了什麼、刪除了什麼。這代表我們不能盲目信任它的自動機制。
3. 最有感的升級：打破「啟動摩擦力」
社群討論中最常被提及的「痛點解藥」，其實是系統冷啟動時間減少了約 57%。開發者們表示，過去每次測試外掛、重啟系統時的等待時間會讓人產生倦怠感；而這次啟動變快，讓日常使用的流暢度大幅提升。
4. 重大「踩坑警告」與架構變動
在升級實作面，社群也發出了幾個明確的警告信號，這與我們的擔憂完全吻合：
- 底層重構極深：這次的「自我改進循環（Self-improvement loop）」經歷了大幅升級，從原本的「自由形式」變成了「基於評分卡（Rubric-based）」的結構化模式。這意味著任何直接綁定在舊版判斷邏輯上的魔改（例如我們的影子領主），都會面臨極大的衝突。
- 安全機制預設行為改變：這是開發者最容易忽略的坑——「金鑰脫敏（Secret Redaction）」功能現在被預設為關閉狀態。如果你原本依賴系統自動遮蔽 API Key，升級後必須手動開啟，否則會有金鑰外洩或損壞 API 酬載的風險。
v0.12.0 雖然充滿了極具吸引力的新功能（如 Google Meet 整合與更強的模型支援），但它動到了非常底層的架構。連社群都在呼籲「要親自去審視系統的改變」，這代表「無腦覆蓋升級」絕對是死路一條。這更加確立了建議採用的 「局部插件化 + 雙開沙盒測試」 是最穩妥的戰略。
----
總結社群高手的真實心聲：
1. 這是「借高利貸」必經的還債過程 (Fork / Merge Hell)社群普遍認為，開發初期為了趕快把功能做出來（就像我們當初被 HTTP 400 錯誤逼瘋，緊急寫了 DEV-0017 補丁直接打在核心上），直接改底層是最快的。但這在軟體工程裡叫做「技術債」。你貪圖了開發速度，官方一推出大改版，討債的（合併衝突）就來了。社群裡每天都有人因為這樣在哀嚎，這現象再正常不過了。
2. 高手的鐵律：「絕對不碰核心，只寫外掛」(Zero-Touch Core)資深玩家的共識是：不管官方的邏輯多笨，絕對不要去改它核心的 run_agent.py。如果想加功能，永遠只能用「外掛 (Plugin)」、「中介層 (Middleware)」或「繼承 (Subclassing)」的方式處理。只要你不動核心，官方怎麼升級，你按一下更新就好，完全無痛。
3. 官方其實也在反省 (v0.12.0 的 Transport ABC)其實很多開發者也在社群抱怨 Hermes 以前的架構太死板，很難做外掛。這次 v0.12.0 推出的 Transport ABC 通訊層，就是官方聽到了社群的聲音，終於把「發送請求的底層設計圖」開放出來，讓大家不用再去硬改核心了。
