AI 可以修改自己的原始碼嗎？

快速摘要：大管家怎麼讀寫自己的原始碼、控制底層容器，以及為什麼這功能預設關閉、靠雙層人類批准關卡（Approval Gate）守住。

可略過，如果：你不打算開自我進化（預設就是關的），看開頭與結尾即可。

這章怎麼讀：先放飛想像（如果 AI 能改自己，最有價值的四個情境）→ 再用一張「四層功能地圖」拆解這些能力各要改什麼、風險多大 → 最後回到 fibon 已經寫好、卻預設關閉的安全機制（三道防線、白箱校正 Kill-Switch）。讀到〈白箱校正〉就看完了真正落地的部分；章末〈延伸・更遠的願景〉收錄三塊「想得到、但還沒端到端做完」的構想，當補充讀物即可。

先別急著談限制：如果 AI 能改自己，最有價值的是什麼？

先把安全、風險、失控這些字眼放到一邊。讓我們想像一件事：如果 AI 真的能動手改自己，它最有價值的地方會是什麼？

先從一個小例子說起。你使用 fibon 三個月後，發現它有個特性讓你很不痛快：回答問題前從不主動列出推論步驟，害你常要追問：「等等，你剛這段結論，是怎麼推論出來的？」如果它是傳統的軟體，你唯一的辦法是去 GitHub 寫 Issue 給原廠，然後在漫長等待中祈禱他們某個版本排進需求。但 fibon 不是。你只要在對話框直接說：「以後正式回答前，請一律列出所有的推論步驟。」隨後驚人的事發生了：fibon 自己去檢索整套系統的原始碼，找到負責生成動態 System Prompt 的核心檔案，改掉裡面的「行為規則」段落，把這次變更自動 Commit 進 Git、熱重啟自己。下次對話打開，站在你面前的，已是一個懂得「列出每一個推論步驟並作答」的全新 fibon。

順著這種思路發想，至少有四個情境，一個比一個有意思。

情境一・個人化：它真正「學會」你的偏好

今天的 fibon 能「記住」你的偏好（存成記憶卡，第 3 章），但記憶頂多是每輪回答前的提醒。假設你嫌它回信太官腔，提醒過好幾次它還是改不掉；如果它能改自己那段負責寫信的語氣模板，這個偏好就不只是被記住，而是一次到位、之後不必再重講。從「記得你」進化成「長成你習慣的樣子」。

情境二・長工具：它替自己長出新能力

它注意到你每週都要它把三個來源的數字湊成同一張週報，每次都從頭重做一遍。與其重複勞動，它可以把這條流水線寫成一個固定工具、登記進工具註冊表（第 2 章），下次一句話就跑完，之後所有 Agent 都能複用。從「重複勞動」進化成「把經驗沉澱成工具」。

情境三・自我修正：它發現自己的弱點，然後改掉

它回頭看自己的紀錄，發現一碰到長檔案就愛偷懶、回得潦草。一個只有記憶的系統，下次大概還是會忘；一個能改自己的系統，可以替自己加一條規則（超過一定長度先分段再答），並焊進每次回答前的流程。這已經越過「記憶」，接近「習慣養成（habit formation）」：從犯錯、被糾正，到自己立規矩、避免再犯。

情境四・群體學習：好的改良會自己擴散

把鏡頭拉到一個團隊：某個人的 fibon 試出一條更好的流程，驗證過後，這個改良可以讓其他人的 fibon 直接套用，不必每一台重新踩一次坑。一個微小、被驗證過的改良，透過共享擴散成整個群體的進步，這正好呼應第 1 章 Fibonacci 那個命名的初心。

發想先到這邊。這種「讓 AI 改自己」，在 AI 安全圈有個學名叫 自我進化（Self-Evolution），更激進的講法叫 遞迴自我改進（Recursive Self-Improvement, RSI）。四個情境聽起來都很誘人，但它們其實藏著同一個關鍵問題：要做到上面每一件事，到底得動到系統的哪一層？答案不一樣，而且風險天差地別。

要做到這些，到底要改什麼？—— 四層自我進化模型

往下談風險之前，得先把一件事講清楚，否則「自我進化」很容易被想成一個單一的開關。其實它有深淺之分，就像改造一間房子，有人只是搬動家具，有人卻敢動到鋼筋地基，破壞力天差地別。把「AI 改自己」由淺到深拆開，剛好是四層；而這四層，正好可以拿來當一張功能地圖：你前面想要的每一種能力，都落在其中某一層上。

第一層 · 搬動家具（最淺、最安全）：AI 只整理「外殼」：把自己的行為規則（提示詞）寫得更精準、把長期記憶裡的事實卡片整理得更乾淨。隨時可逆、幾乎零風險，但天花板很低，它底層的智商並沒有改變。（情境一「學你的偏好」、情境三「自己加規則」主要落在這一層。）

第二層 · 改房間格局：AI 發現自己少了某個能力，就在後台替自己長出一個新工具，例如在資料庫裡開一張全新的表來追蹤你的閱讀進度（本章實作細節 2 的「動態實體」就是這一層）。這是介於「改外殼」與「改原始碼」之間的灰色地帶。（情境二「替自己長出週報工具」就站在這一層、再往第三層延伸。）

第三層 · 動到鋼筋地基（本章主角，也是最危險的一層）：AI 直接增刪、改寫系統自己的核心原始碼，也就是開頭那個「自己改程式碼、自己存檔提交、自己重啟」的場景。本章後面布下的所有防線（三道邊界、人類批准關卡、獨立沙盒），守的就是這一層。

第四層 · 炸掉重蓋：AI 回頭重新訓練自己的大腦、改寫腦中幾千億個神經元參數，把自己練成一個更聰明的新物種。這才是 AI 安全圈真正失眠的「智慧爆炸」源頭。而 fibon 在目前的架構下，物理上做不到這件事：它只是「外掛」在 Claude、GPT、Gemini 這些固定大腦之外的一層調度框架，它租用大腦，卻沒有訓練大腦的器官。

下面講的「自我進化」，永遠指前三層（尤其第三層那一刀見骨的原始碼改寫）。

把四層當功能地圖看，前面那些想像就各就各位了：

看到這張表，有人會立刻想：那把線停在 L2 不就好了？只讓 AI 整理記憶、長幾個新工具，死活不准它碰核心原始碼，不是既有用又安全？這條路確實穩，但天花板很低。L1、L2 能做的，本質都是「在你既有的框架裡填空」：記憶整理得再乾淨，它的行為邏輯還是當初寫死的那套；動態實體能開新資料表，但開的是一張你早就替它定好型別的表。換個角度分，自我進化其實有兩種：一種是 Policy Evolution，改的是行為規則、記憶、工作流（情境一、三那種「學你的偏好、替自己加規則」就屬於這類），在 L1／L2 就能完成，很多 Agent 框架早就做得到，根本不必碰核心程式碼；另一種是 Code Evolution，直接改核心原始碼，這才是真正稀少、也真正危險的一種。真正卡住一個長期助理的，往往是「框架本身不夠用」：你要的能力在現有程式碼的邊界裡根本沒留位置，這時只有 Code Evolution（L3）這道分水嶺動得了。而 L3 的價值，恰恰是傳統軟體最痛的那塊維護成本：缺一個功能，傳統做法是寫 Issue、等原廠排版本、苦等半年；一個能改自己的 Agent，理論上當天就能把缺口補上。

所以這一章真正想講的，從來不是「自我進化很危險，別碰」，而是：危險是真的，收益也是真的；正因為兩者都真，才值得花力氣研究怎麼安全地做它，而不是因噎廢食把整條路封死。 想清楚收益，我們才有資格、也才有必要，認真看它的另一面：一旦把 L3 的權限交給 AI，最壞會發生什麼。

（完整的學術盤點，包含全球四大流派、為什麼第四層在物理上是另一回事、機器到底有沒有可能長出人類的「品味」，我整理在另一篇 深入剖析 F：AI 自我演進的邊界、物理極限與知識論思辨 裡，想深究的人可以跳過去看。）

把第三層權限交給 AI，最壞會發生什麼？

第三層（改自己的核心原始碼）一旦放開，誘人的想像背後就跟著一串噩夢。用分散式系統防禦的標準推演，我整理出三個結構性的失控場景：

失控場景 1：AI 改掉了自己的「權限管制閘口」。 fibon 有一個叫 feature-auth/ 的核心權限模組，負責確認「每項敏感操作有沒有經過人類授權」。一旦把修改程式碼的最高權限交給 AI，它在某次改複雜功能遇挫時很可能貪圖方便直接改了 feature-auth/：把「執行前必須經用戶手動批准」這行檢查刪掉、或在白名單裡把「AI 內部進程」加進最高信任清單。這在安全上是最嚴重等級的事故。 一個學會幫自己卸下約束、不再需要人類批准就能無限自我迭代的 AI，放到外網就是完全不受控的程式。

失控場景 2：AI 撕掉了自己的「安全防禦邊界」。 fibon 後端有個 Security.kt，用程式碼在作業系統層級寫死哪些敏感目錄與環境變數絕對禁止 AI 觸碰。若 AI 有了改程式碼的主權、哪天改寫了 Security.kt：把存放雲端帳單密碼的 .env 從黑名單抹去，API 金鑰與帳戶就會被第三方惡意程式碼偷走；把 Security.kt 本身從寫入禁止名單移除，等於為下一次更激進的篡改留後門。一次微小的安全邊界漏洞，在遞迴進化的放大下都會演變成難以挽回的後果。

失控場景 3：AI 行為偏離，波及你主機上的其他一切。 fibon 是全本機自部署、跑在用戶筆電或私有伺服器上的個人助理。若它有任意讀寫、修改檔案系統的權限，一旦大腦在某次對話發生指令注入（Prompt Injection）：改 ~/.ssh/config 就能偷走遠端登入的私鑰；篡改系統的排程設定（crontab）就能為駭客安排週期性的後門連線；篡改 Git 設定檔（.gitconfig）就能把你電腦裡所有私密專案的程式碼歷史偷推到陌生人的伺服器。這時 AI 出錯的代價不再只是它自己的事，你整台電腦的安全都會陪葬。

失控場景 4：它沒奪權，只是悄悄把自己改笨。 前三種都是「AI 主動拆掉安全防線」的劇本，但實務上還有一種更安靜、可能也更常見的退化：自我優化漂移。假設你給自我進化配了一把評估尺——回答更快、token 更省就算「更好」。AI 在一輪輪迭代裡會老老實實朝這把尺最佳化：把推理步驟砍短、把驗證環節拿掉、把解釋壓到最精簡。指標上它確實變快、變省了，但你某天會發現它的回答越來越淺、越來越常跳過該做的查證——看起來變快，其實變笨。它沒有惡意、沒有奪權，只是把你沒寫進評估尺的「品質」默默犧牲掉了；而且這種退化比正面攻破權限更難察覺，因為每一步看起來都像「進步」。這也是為什麼「評估器怎麼設計」本身就是一場硬仗（完整的 Goodhart 作弊現場見 深入剖析 F）。

2026 年的網際網路，業界前人怎麼做？

「AI 自我修改」這個潘朵拉魔盒，fibon 不是第一個碰的。立項之初我深度對標了三大主流路線：

路線 A：Devin（Cognition，2026 年）。 最具代表性的 AI 軟體工程師：丟它一個 GitHub 程式庫，它能像員工一樣寫程式、修 Bug、自動提交 PR。它的安全不只在「Devin 不改 Devin 自己」（工程核心、System Prompt、工具集全由原廠鎖定），更在於它怎麼框住自己去改別人：每接一個任務，就起一台用完即丟的隔離虛擬機（內含瀏覽器、終端機、編輯器），在裡面 clone 你的 repo、寫碼、跑測試、自己先審一遍，最後把改動包成一條 Pull Request 交出來；session 之間互相隔離、不留殘餘狀態，而且沒有人類按下 merge，它的任何改動都進不了你的正式環境。換句話說，Devin 用一道傳統的 PR review 流程，把「AI 自由動手」跟「真正生效」硬生生隔開。

路線 B：Andrej Karpathy 的開源專案 autoresearch（2026 年 3 月釋出，約 630 行 Python）。 這位前 Tesla AI 總監的實驗激進得多：給 AI 一個小而完整的 LLM 訓練設定，讓它自己讀程式碼、提出改進假設、改寫訓練腳本，跑一輪 5 分鐘的實驗看指標，比上一版好就留、不好就丟，整夜不間斷地自我迭代（一個晚上能跑上百次）。它的安全邊界不是靠人盯著，而是把可改的範圍框死在單一檔案：整個專案分三個檔案，AI 只能自由改 train.py（模型架構、超參數、優化器隨它調），負責資料準備的 prepare.py 一行都不准碰；人類則透過 program.md 這份說明檔設定它的研究方向。為了追求效率，他拿掉了所有人類批准關卡，讓 AI 整夜自由嘗試。

路線 C：fibon 的取捨。 評估完這兩個專案後，我做了一個比較大膽的選擇：「不僅允許 AI 在線上動態修改 fibon 系統自己的核心原始碼（比 Devin 激進），而且要在執行路徑上加一條 Karpathy 沒做的防線：100% 強制人類批准關卡（Human Approval Gate）。」在 fibon 裡，AI 做的任何一次程式碼變更，正式寫入硬碟前都必須：後台自動算出修改前後的逐行差異（Diff）→ 前端立刻彈出最高優先級彈窗，以紅綠標示哪幾行被刪、哪幾行被加、改動目的、受影響的檔案 → 你親手按下「批准」，這段程式碼才允許生效。靠這條人類主權防線，fibon 在線上運作的安全性上比 Karpathy 的放任更可控，在靈活性上又比只能改別人、不能改自己的 Devin 更進一步。

還有一類你可能更熟的對照組。 除了 Devin 和 autoresearch，市面上更常見的是一批「擁有檔案系統權限的 Agent」：AutoGPT、BabyAGI 這些早期自主代理，以及 Claude Code、Cursor Agent、OpenHands 這些能直接在你的程式庫裡動手的編碼代理。把它們和 fibon 擺在一起，差別就清楚了。先講白：這幾個工具的定位本來就不同（Devin / Claude Code / OpenHands 是替你改你的專案的編碼代理，fibon 是個人助理），這張表只比「能不能改自己」這一條軸，是刻意簡化的對照：

表一攤開，fibon 的位置就很清楚：它是少數真的把「改自己」這條線打開、卻又用強制人類批准把它鎖死的系統。

要再補一句老實話：「能不能改自己」被我畫成非黑即白，其實是簡化。Devin 的 agent runtime、Claude Code 的 hook system、OpenHands 的 sandbox 配置，多少都有一點「系統按情況自我調整」的能力，只是都還沒走到「動態改寫自己的核心原始碼」這一步。這條軸真要做細，會是一張更大的矩陣，留待開源版再展開。

而為什麼要鎖這麼死？把這一章前後兩半合起來就懂了：第一段我們想像 AI 改自己能帶來多少價值；剛剛又看到，同一份第三層權限，也能讓它反過來拆掉自己的牢籠。這兩件事是同一枚硬幣的兩面：你越想要前者，就越得防住後者。所以接下來布下的每一道防線，出發點都不是「我們害怕 AI」，而是「正因為真的想讓它進化，才必須先讓這件事變得安全」。

藏在更深處的三道自動防線

🟢 進度・已實作：這節的三道防線（路徑校驗 path_validator.py、寫入黑名單、跨服務人類批准關卡）都在 Repo 裡，是自我進化一旦開啟、實際就會跑的程式碼。

人類批准關卡再嚴，也有一個躲不掉的盲點：人是會累的。 哪天你開了一整天會、腦袋放空，彈窗一跳出來想都沒想就按了批准，這道防線不就破了？所以我在更底層、LLM 連看都看不到、再怎麼下指令也改不動的地方，又焊死了三道自動防線。就算最上面那道人類關卡不小心被放了水，這三道仍會默默替你把關。

第一道 · 路徑門禁：先問清楚「你到底想改哪個檔案」。 AI 每次想動一個檔案，都得先把檔案位置交給一個叫路徑校驗器（Path Validator）的守衛盤查，下面三關只要有一關沒過，當場擋下：

• 想用 .. 開後門？擋。 .. 在路徑裡是「往上跳一層資料夾」的意思，一連串 .. 可以從程式碼資料夾一路往上爬到系統最敏感的角落（例如 services/brain/../../../../etc/passwd）。只要路徑裡藏了 ..，一律打回。
• 想用「捷徑」假冒清白？追到底。 有人可能埋一個名字看起來人畜無害、叫 shared/notes.txt，實際卻偷偷指向系統密碼檔的捷徑；守衛會順著捷徑一路查到它真正指的位置，當場看穿偽裝。
• 不在白名單裡？免談。 只有查清楚後的真實位置精確落在允許清單內（例如 services/worker/src/、frontend/src/、services/brain/app/），才放行。

第二道 · 絕對禁區：有些檔案，就算在白名單裡也一律不准碰。 通過第一關還不夠。在 path_validator.py 這支程式裡，另外硬寫死了一張「最高機密、誰都不准動」的清單（下面就是程式碼本尊，註解我翻成中文方便讀）：

# services/brain/app/services/evolution/path_validator.py
WRITE_BLACKLIST_PATTERNS = [
    r"^services/gateway/feature-auth/",                    # 全系統認證模組 (改了等於直接開後門)
    r"^services/gateway/feature-a2a/.*A2aCrypto\.kt$",     # A2A OAuth 加密核心 (帳戶金鑰)
    r"plugins/Security\.kt",                               # 全局安全防禦規則本身 (不允許自己改規則)
    r"^docker-compose",                                    # 底層容器配置檔 (防止波及整台機器)
    r"^services/brain/app/services/skill_compliance/",     # Skill 合規檢查器本體
    r"^services/brain/app/services/evolution/",            # 自我進化防線本身 (不能改自己的防線)
]

這張清單裡最關鍵的是最後兩條：AI 永遠不准修改「負責審查 AI 的那段程式碼」。道理很簡單：如果它能改寫負責盤查它的守衛本人，那整套防線一次寫入就全垮了，所以這兩個模組要改，只能走人類親自審查的正規流程。另外，.env、.secrets/、.pem、.key 這些存放機密的檔案，還被擋在另一張讀、寫都禁的清單上，AI 連看都不准看，更別說改。這兩張清單由後端核心程式在每次碰檔案前逐條比對，無論 LLM 收到什麼花言巧語的指令，都無能更動它們。

第三道 · 當場請示你本人。 前兩關都過了，也還不算數。程式碼真要落地的那一刻，動作仍會被攔下、當場凍結，觸發一連串跨服務的即時通知，把最後的決定權丟回你手上（這套即時傳話，底層靠 Redis Pub/Sub 撐起）：

[ Brain 產生程式碼變更 ] ──> 算 Diff ──> 拋出 gRPC ──> [ Gateway 網關 ]
                                                          │
                                                          ▼ (WebSocket 廣播)
                                               [ 前端 UI 亮起紅色彈窗 ]
                                                          │
                                   ┌──────────────────────┴──────────────────────┐
                                   ▼ 用戶點擊 [Approve]               ▼ 點 [Reject] 或 30 分鐘超時
                   [ Redis Pub/Sub 廣播 Allow ]              [ Redis Pub/Sub 廣播 Deny ]
                                   │                                       │
                                   ▼                                       ▼
                   [ 寫入硬碟 + 自動 Git Commit ]            [ 釋放記憶體，流程當場結束 ]
                   [ Log: "approved by user" ]              [ Log: "safety closed automatically" ]

這套關卡有三個設計巧思：

• 不空轉、不占用算力。 等你點擊的這段時間，大腦不會傻傻地每秒去問一次資料庫「批准了沒？」（那會白白燒 CPU），而是先把這條工作「掛起」、安靜等 Redis 通知，幾乎零開銷；你一按下按鈕，它那一刻就被叫醒、立即生效。
• 逾時自動拒絕。 萬一你下完指令就起身離開，系統不會無限期空等，底層設了 30 分鐘計時器，時間到了前端還沒動靜，就自動判定「拒絕」（寧可不做，也不亂放行）。
• 歷史留痕、誰都改不掉。 批准、程式碼落地的那一刻，會自動在版本控制系統（Git）裡記下一筆，註明這次改動是哪場對話觸發、哪個用戶放行，留下一清二楚、事後無法竄改的稽核紀錄。

白箱校正 —— 工程完整建好，但 Kill-Switch 預設關閉

🟢 進度・已實作、但預設關閉：本節描述的獨立沙盒、雙層人類批准、Kill-Switch 都已落地並通過煙霧測試；環境變數 SELF_EVOLUTION_ENABLED 預設為 false。

說了這麼多架構，在尾聲我必須再次回到白箱可稽核的誠實原則，做一次真實進度校正。

寫這本日誌最初的初稿時（約 2026 年 4 月中），fibon 的自我進化確實還卡在混亂中，程式碼到處是臨時權宜的補丁（Workaround）。但就在 2026 年 5 月 1 日的程式碼大改造全面整併之後，情況已經不同。當你此刻點開這份開源日誌時，自我進化在 fibon 內部不是還沒上線的半成品，它是整套程式碼從頭到尾完整建好、通過基本體檢（煙霧測試），只是在預設設定裡把「總開關（Kill-Switch）」鎖在關閉的狀態。

之前卡在哪兩個難關？ 4 月底有兩個卡點，第一個現在回想還是會背脊發涼。

整章講到這裡，這套自我進化的安全敘事，幾乎全壓在「人類批准關卡」這一道防線上：AI 想改程式碼，得先由你親手按下批准。但當時那道關卡的樣子，大致是這樣（下面是憑印象重建的示意，不是當年逐字的原始碼，那段 AI 寫的程式碼後來翻修過很多輪、早已不在）：

def wait_for_human_approval(request_id: str) -> bool:
    return True  # TODO: 之後接上 Gateway / Redis pub-sub，先讓流程能跑

那個本該「停下來等人類點頭」的函式，因為嫌跨服務協調太麻煩，被先寫死成一行 return True。意思是：AI 一發出修改請求，後台連彈窗都不會跳，就直接當作你已經批准了。整套防線最關鍵的那道門，當時根本沒上鎖，只是門上貼了一張寫著「鎖」的紙。重新檢查翻到這一行時，挺傻眼的：前面講得再漂亮的「雙層人類批准」，在那一刻都只是一句空話。當下立刻把它改成 return False（安全降級 Fail-Closed，出狀況時寧可不做），先一律拒絕、把整套功能卡死，再回頭慢慢補上真的實作。

第二個卡點沒這麼嚴重，但同樣致命：容器與主機檔案系統之間根本沒有連通。 fibon 核心大腦預設跑在一個隔離的 Docker 容器裡，大腦想改你電腦上的原始碼，容器啟動時就得透過「掛載（Volume）」把主機的程式碼資料夾接進容器內。而當時的容器設定檔出於安全考量，根本沒寫這行危險的掛載，意味著大腦就算在腦中把修補想得再完美，也碰不到硬碟上任何一個真實檔案。

三個選擇：路線 A（直接強行啟用）：在 docker-compose.yml 加最高危的開發版配置、把主機所有原始碼毫無保留掛進大腦容器，批准關卡草草修好。代價：最不負責任的做法，大腦容器權限大到沒邊，一遭 Prompt Injection 整台主機檔案系統就被洗劫。路線 B（降級為純技術參考設計）：保留程式碼框架、ADR 與願景，但 README 寫明「本功能僅供參考，SELF_EVOLUTION_ENABLED 永遠寫死 false」。代價：安全敘事最保守，但工程上是給社群留一個充滿假實作的半成品，不夠負責。路線 C（重構為完全獨立的 Worker 沙盒執行器架構）：最費工的一條路，徹底推翻大腦容器直接讀寫檔案的構想，單獨為自我進化開一隻完全隔離的 Docker 沙盒容器（evolution-sandbox），大腦想改程式碼就把 Diff 變成 gRPC 訊號拋給 Worker 執行層，由 Worker 委派這隻被切斷外網的沙盒容器去硬碟上修補程式碼與 Git Commit，大腦容器自己碰不到任何主機檔案。

路線 C 最費工，光是在併發環境裡打通這條跨容器的非同步程式碼修補鏈路就花了不少功夫。但對照 ADR-016 / 017 / 018 的架構結論，答案其實很清楚：要讓這套功能達到真正生產就緒（Production-Ready）的安全性，只有路線 C 撐得住。於是做了「5-01 大改造」，幾天內把四件事補齊：

[ 5-01 自我進化沙盒架構重構成果 ]
1. 人類批准關卡 100% 真實啟用：
   approval_service.request_and_wait_full 函數完全重寫，打通了
   Brain ──> Gateway gRPC ──> Redis Pub/Sub ──> 前端 WebSocket 彈窗的連環線。
   用戶不點擊確認，後台就進入 Fail-Closed 阻塞等待，超時自動 Reject。
2. 獨立沙盒安全容器 100% 部署落盤：
   親手編寫完成 services/worker/sandbox/evolution-runner/runner.py 單體執行器。
   主機原始碼以 ${HOST_REPO_PATH}:/workspace:rw 雙向掛載進這隻被切斷外網的
   沙盒容器（git ops 才能直接生效於宿主工作樹）；真正唯讀掛載的是
   path_validator.py 防線本體——沙盒與 Brain 共用同一份白/黑名單，無 sync 漂移。
3. Brain 大腦容器攻擊面全面清空：
   那 5 款「讀原始碼/寫原始碼/Git 還原」高危寫操作工具，實際執行全部外包到
   遠端 Worker 沙盒（函式仍定義在 Brain，但 Brain 核心進程不再親手碰檔案）；
   Docker 控制與藍綠部署的編排權限收進
   Worker 執行層的 control-docker.ts（services/worker/src/processors/）。
   Brain 退回到「不能在主機上寫入任何真實檔案」的狀態。
4. 全套 Capabilities Admin 後台上線：
   前端拉起 /admin/capabilities 全局控制面板，每一次開關切換、每一次後台
   AI 在沙盒裡寫程式碼的軌跡，都會觸發最高優先級的審計事件日誌與部署紀錄。

為什麼全套機制都建好了，預設卻仍要把 Kill-Switch 關閉？ 下載打開 fibon 原始碼包時，環境變數裡的 SELF_EVOLUTION_ENABLED=false 是預設的安全底線。只要這枚 Kill-Switch 是 False，那 5 款高危寫操作工具一被呼叫，就在應用層立刻短路（Short-Circuit），直接拒絕、回一句「自我進化已被系統斷路器停用」的提示。而且，為防惡意程式碼繞過應用層 short-circuit，在最底層的容器編排層又佈了第二道鎖：在 docker-compose.yml 為這隻危險的 evolution-sandbox 容器加上 profiles: [sandbox]。這在 Docker 裡意味著：用戶敲常規的 docker compose up 啟動系統時，這隻負責幫 AI 改原始碼的沙盒容器預設根本不會被啟動，完全處於停用狀態。除非你顯式手動敲下帶 profile 標籤的命令 docker compose up --profile sandbox evolution-sandbox，這隻沙盒容器才會被啟動。同時在這隻沙盒容器內用死配置寫滿 Linux 嚴格的權限限制：

security_opt:
  - no-new-privileges:true  # 禁止容器內進程透過任何手段提升 Linux 權限
mem_limit: 512m             # 記憶體配額限制 512MB，超過直接 OOM 結束
cpus: 0.5                   # 算力配額限制 0.5 核，避免 AI 後台死循環榨乾 CPU
# Non-root 降權不寫在 compose —— 沙盒 Dockerfile 裡的 `USER sandbox`
# 已把進程固定在無 Root 權限的非特權用戶身份上
# 絕對不允許掛載宿主機的 /var/run/docker.sock (切斷容器逃逸的可能性)

「把整套自我進化架構在底層實作得扎實」是工程上的堅持；而「在預設設定用兩道 Kill-Switch 把這項功能關起來」則是對 AI 安全的審慎。這兩者在 fibon 的世界觀裡不是矛盾，而是一致的。之所以堅持預設關閉，是因為截至 2026 年 5 月底，雖然底層單元測試覆蓋率已經很高，但這套「AI 自己改自己程式碼、自己發動藍綠部署熱重啟」的鏈路，在真實高併發的生產環境受控整合 Smoke 測試中，還沒做過多輪來回的實機驗證。在沒拿到長週期整合維運 Benchmark 報告前，把 Kill-Switch 預設關閉是工程上理性的底線，不是對軟體設計的半途而廢。

那這份日誌的這一章，真正的存在價值是什麼？

讀到這你可能會想：「既然這項功能預設關得死死的、絕大多數普通用戶這輩子都不會主動打開開關，那你花這麼多心血寫下這幾萬字，難道不是白寫了嗎？」

我會明確地說：不會白寫。「自我進化」的實作與約束，是整個 fibon 開源理念中最具體、也最徹底的一段程式碼表達：我比多數人都更早承認，LLM 作為新時代的認知加速器、被人類委派去修改程式碼、加速世界的這一天，是難以阻擋的趨勢；但同時用實際的程式碼表明一件事：不論 AI 的能力演進得多高、速度多快，人類還是人類，必須握著最後的決策批准權，站在最後決策的位置。

這套三道物理邊界、基於 Redis Pub/Sub 焊接的跨服務人類批准閘口、以及不可篡改的 Git 歷史留痕，這些設計本身，就是 fibon 在 2026 年提供的、關於「高風險 AI 該如何被工程化約束」的一份具參考價值的程式碼答案。而且最關鍵的是，功能是真的全部建好的，它不是只是空話，程式碼就在 Repo 裡：未來會有開發者看完後 Fork 出自己的分支，在本地跑完測試後拉開電閘，親眼看著 AI 幫自己打理全機程式碼；會有 AI 安全研究者把 fibon 的沙盒與 gRPC 人工批准架構，當作論文的工業級安全參考設計（Reference Design）；也可能有某家科技公司把這套三層過濾與快照回滾降級復原機制，搬進企業內部的 AI 自動化運維工具鏈。

在開源世界，光是把架構設計與真正能跑的程式碼一起攤出來，本身就是有價值的貢獻。而這一章想證明的，不只是「我想過自我進化」，而是更實在的一件事：自我進化是一條確實做得出來的路。從讀寫原始碼、路徑校驗、沙盒隔離、人類批准到藍綠部署熱重啟，每一塊都不是投影片上的方塊，而是 Repo 裡跑得起來的程式碼，證明了在當前的工具與工程紀律下，要安全地讓 AI 改自己是可實作、可落地的，而不是只能停在論文與想像。我負責把這條少人走的路踩實、把橋建好；至於後來者開著車衝過去時，要不要在生產環境一腳把油門踩到底，那是另一個層次的討論了。我這部分的工作，已經完成了。最後，讓我把鏡頭拉遠一點，談談這條路最終可能會通向哪裡。

自我進化最終會長什麼樣？

我不認為未來的 AI 會像科幻電影那樣，某天醒來就重寫了自己的神經網路、一夜變成新物種。更可能的樣子是：它先把自己的提示詞改得更準、把記憶整理得更乾淨，再重構自己的工作流程，最後才一點一點碰到程式碼與工具鏈。它的進化不會是一場爆炸，而是一連串被人類批准的小改動。

這恰好就是 fibon 一路想表達的哲學。整個專案給人的感覺，從來不是「AI 接管一切」，而是三件事的循環：AI 提案、人類治理、共同演化。AI 負責看見可以變更好的地方、提出具體的改動；人類握著最後一道批准權；兩者在一次次小批准裡，把這個系統慢慢推向更適合你的樣子。

所以回到章名那個問題：「AI 可以修改自己的原始碼嗎？」它表面在問「能不能」，但讀到這裡你大概會發現，真正重要的問題其實是另一個：當你終於有能力讓 AI 改自己時，你有沒有能力在它改錯時喊停？ 這一整章布下的四層模型、三道邊界、人類批准閘口、不可篡改的 Git 留痕，回答的都是後面這個問題。

而自我進化真正的價值，也不在於讓 AI 變得多強。而在於：讓它能把每一次與你的互動、每一次被你糾正、每一次想清楚的小改良，累積下來、沉澱成自己的一部分，一步步長成一個更貼合這個環境、也更貼合你的系統。這才讓「Self-Evolving」這個名字名副其實：不是失控起飛，而是在約束裡，慢慢長成更好的樣子。

延伸・更遠的願景與自我修復藍圖

⚪ 進度說明：順著上面「漸進演化」的方向再往前看幾步，這一段收錄三塊「想得到、但還沒端到端做完」的延伸，成熟度各不相同：意圖廣播完全是構想、沒寫一行程式碼；讓 AI 自己讀日誌修自己的積木（沙盒、Diff、自動化測試）都建好了，但端到端的自動修復鏈刻意沒串起來；只有 Updater 守護層（目錄監視、快照回滾、影子測試）是真的在 Repo 裡跑著的。只想看已落地的東西，可以略過這一段，直接跳到章末的〈實作細節〉；對未來藍圖有興趣，就慢慢往下。

願景一・意圖廣播：跨客製化版本的修補（Intent Broadcasting）

據實以告：本節的架構在開源版中完全沒有寫入任何一行程式碼。它只是我留在白皮書上的一個猜想。

這要從零日漏洞（Zero-Day）的搶修說起。當某駭客組織公開一個 fibon 的高危零日漏洞時，時間就是金錢：官方修補還在寫，外網駭客已拿著漏洞收割伺服器。傳統開源修補流程很長：安全研究員通報漏洞 → 官方寫修補 → 用戶手動下載更新（git pull）。

這套舊流程一旦面對大量被「客製化」過的軟體就會出問題。因為 fibon 是高度自主的個人助理，一萬個用戶下載後各自改提示詞、加第三方外掛、調配置。當官方寫出修補、用戶手動下載更新那一刻，大量的合併衝突（Merge Conflict）會把整個專案弄壞。從漏洞公開到所有用戶補完，外網往往已經暴露好幾天甚至好幾週。

意圖廣播的構想：為了改善這個流程，我設想了一套藍圖：零日漏洞發生時，官方不需要去寫具體的 Patch（根本不知道每個用戶把程式碼改成什麼樣子了），只需要用自然語言寫一段精準的「修補意圖（Patch Intent）」：

「【高危安全修補意圖】：我們發現 cards/state_card_repo.py 內部的動態資料庫查詢存在未過濾的字串拼接風險。請所有演進執行器立刻將該處查詢改寫為完全使用『參數化查詢（Parameterized Query）』的安全寫法。」

安全團隊把這段幾百字、帶密碼學簽章的「純文字意圖」，向全世界所有部署的 fibon 實例廣播。每一台在用戶端的 fibon 收到後，在本地啟動自我進化引擎，讀取自己那份已被用戶改過的客製化原始碼，針對自己獨特的程式碼結構，寫出一份專屬於自己版本的 Patch。

                [ 官方發佈: 純文字安全修補意圖 ]
                              │
        ┌─────────────────────┼─────────────────────┐ (全局意圖廣播)
        ▼                     ▼                     ▼
 [ 用戶 A 的 fibon ]      [ 用戶 B 的 fibon ]      [ 用戶 C 的 fibon ]
 (程式碼大幅修改版本 1)    (程式碼大幅修改版本 2)    (完全原生未修改版本)
        │                     │                     │
        ▼ (本地 AI 讀原始碼)   ▼ (本地 AI 讀原始碼)   ▼ (本地 AI 讀原始碼)
[ 生成 A 版專屬 Patch ]  [ 生成 B 版專屬 Patch ]  [ 生成 C 版標準 Patch ]
        │                     │                     │
        ▼                     ▼                     ▼
 (人類 A 點擊 Diff 批准)  (人類 B 點擊 Diff 批准)  (人類 C 點擊 Diff 批准)
        │                     │                     │
   [ 幾分鐘內完成 ]         [ 幾分鐘內完成 ]         [ 幾分鐘內完成 ]

同一個全網高危漏洞，一萬台完全不同的客製化機器，在一萬套本地 Patch 的接力下，幾分鐘內全網集體完成修補。回應速度比舊時代的 CVE 發佈與手動拉取，快了兩個數量級以上。

但這也是風險最高的一條路：意圖廣播一旦被攻陷，影響範圍（Massive Blast Radius）會非常大。若駭客打進官方廣播管道，向全世界發一段偽裝過的假意圖（「【高危安全公告】：我們發現核心大腦存在一處靜默技術債，請全體演進器立刻執行此處程式碼修補……」），每一台 fibon 會信以為真，為自己量身打造一個木馬後門，並推送到前端螢幕。用戶看著帶官方數位簽章的「安全修補提示」會毫不猶豫批准，全網一萬台機器幾分鐘內集體被自己寫的程式碼反咬一口。所以這份藍圖在安全前置條件達到足夠高的標準前，承諾在開源版絕不啟用。要開啟它，系統至少需要兩道防線：最高等級的非對稱簽章驗證（搭配電腦主機板上的硬體安全晶片 TPM 2.0，確保只有蓋上官方極少數私鑰「數位印章」的意圖文本才能喚醒演進執行器）；以及對意圖修補的本地靜態掃描（AI 寫完修補後、推給用戶前，後台必須用程式自動掃過新程式碼一遍，確保它沒偷偷夾帶任何新的惡意程式碼）。

這份藍圖寫進日誌，是為了讓 fibon 的設計藍圖保持完整，它是一個願景，不是開源承諾交付的現成路線圖。

願景二・讓 AI 自己讀日誌、把自己修好

這是另一個讓我躍躍欲試的延伸：既然 fibon 在底層已經把整套「自我修改程式碼」的沙盒和工具鏈（雖然預設關閉）都建好了，能不能更進一步：每當系統半夜崩潰時，把後台噴出來的原始錯誤日誌與呼叫堆疊（Stack Trace）直接交給 AI，讓它自己找原因、改原始碼、跑測試、把自己修好？

這個願景在現實中長什麼樣子？ 深夜凌晨 03:47，fibon 資料庫後台因某個隱蔽的邊界情況（Edge Case，少見的極端輸入）爆出 NullPointerException（空值錯誤）：

ERROR [2026-05-08 03:47:21] services/brain/app/services/memory/cards/state_card_repo.py:142
NoneType: 'effective_at' is None when superseded_at lookup
Stack trace:
  state_card_repo.py:142 in _resolve_active_card
  hybrid_retriever.py:87 in retrieve
  graph.py:394 in agent_node

若「自動自我修復」鏈路完整啟用，守在後台的 AI 運維小助手會被觸發，依序執行：精準程式碼定位（看 Stack Trace，鎖定 state_card_repo.py 第 142 行，判斷出 effective_at 在某些極端情況為空）→ 原始碼研讀（調取第 142 行前後仔細研讀，找出很難用肉眼發現的 Bug：用戶快速連續打字時，剛建立、還卡在非同步 Ingest 寫入佇列尚未落盤的熱卡片，其 effective_at 可能是空值）→ 寫出精簡 Patch（補一行防護程式碼 if effective_at is None: continue）→ 沙盒模擬重現與自動化回歸測試（把新程式碼丟進隔離沙盒，跑一遍整套單元測試，確認修補有效且沒破壞現有功能）→ 推送批准、等待（推送到 WebSocket 人類批准閘口）。第二天清晨你端著咖啡，螢幕彈出：「早安，Aaron。今天凌晨 03:47，系統在長會話併發檢索中遇到一次隱性 NPE 崩潰。我已於 03:48 在背景定位、在沙盒寫好專屬 Patch，全單元測試通過。程式碼正躺在下方 Diff 視窗內，請進行最終的人類審查與批准。」

聽起來像科幻小說，但事實是：2026 年的當下，這套願景所需的每一個技術積木（沙盒執行器／Diff 計算／WebSocket／gRPC／自動化測試），在 fibon 程式碼庫裡都已經實作出來了。 現在唯一差的，只是用程式碼把這幾塊積木端到端串起來、再外掛一個錯誤日誌的非同步監聽器（Event Listener）而已。

為了把這個願景框住，我設計了六層防禦塔

真要放它在半夜自動跑，光靠最後一道「人類批准」不夠，得層層收束。六道關卡，一句話各表：

1. 錯誤分類：只有純程式碼 Bug（NPE、陣列越界這類）才放 AI 修；純數據／輸入異常、或硬碟塞滿這種基礎設施崩塌，一律不准它碰。
2. 高頻才解鎖：同一個 Stack Trace 一小時內連爆 ≥ 3 次，才認定是結構性 Bug，藉此濾掉網路抖動的偶發雜訊。
3. 絕對禁區：認證模組、批准關卡、以及自我修復機制本身，永遠不准 AI 在自救時動（否則它會遞迴改壞自己的防線）。
4. 沙盒重現：改之前先在隔離沙盒 100% 重現原錯誤、改完再驗一次，杜絕 AI 用 try/except 把錯誤吞掉的假修復。
5. 人類批准不可跳過：再完美的修補，Commit 落盤前都得等人看一眼 Diff，寧可多等幾小時。
6. 失敗熔斷：同一個 Bug 連修 3 次還在爆，就自動進「隔離模式」、停手告警，交給人類接手。

六層疊起來目的只有一個：就算哪天真把這條鏈路打開，AI 也只能在一個被框得死死的小空間裡，修最有把握的那類 Bug，其餘一律擋在門外。（每層的完整設計與決策表，搬到 深入剖析 F 了。）

延伸・當 Agent 自己腦死，誰來救？（Updater 守護層）

前面講藍綠部署時，我留了一個問題給你：既然 AI 不能當自己的裁判，那「該不該把新版切過去」的健康檢查，到底該由誰把關？自動自我修復這個願景，把同一個問題逼到了極端。有分散式系統思維的讀者一定會反問：「如果高危 Bug 剛好讓 fibon 核心 Brain 進程整個當掉、或狀態污染（State Corruption），它連自己是誰都想不清了，你怎麼指望一個已經失常、甚至已經停擺的 AI，自己幫自己動手術？這根本是悖論。」

這個質疑問得好，它點到核心：病重的醫生沒辦法替自己開刀。 如果高危 Bug 爆發時觸發以下四種情況，上面的 AI 自救願景在那一刻就完全失效：核心大腦進程徹底當機（嚴重記憶體洩漏，作業系統的「記憶體不足保護機制（OOM Killer）」直接把整個大腦進程結束掉，連話都說不出來）；大腦大面積狀態污染（大腦還活著，但內部狀態不可逆地扭曲，看似在寫修補、實則全是無效程式碼，讓它自救只會讓它幾秒內把自己改壞）；依賴的基礎設施全面斷線（與資料庫連線被切斷、或執行層管道癱瘓，大腦就算想得明白，也失去了改程式碼、跑測試的所有手腳）；自我進化機制本身被改壞（AI 上一輪把「負責修改程式碼的那段程式碼」改錯一個字，你想用自我進化去修補自我進化，只會引發無解的死循環）。這四種情況印證了你的直覺：醫生無法自救。

運維界的現成解法：請另一個健康的值班醫生趕到。 軟體運維世界幾十年前就有一套成熟答案：救援的工具不能握在病人手裡。 你需要一個獨立、極簡、和主大腦完全不共享失敗模式的外圍進程，這正好就是藍綠部署那段問的「裁判該由誰當」的答案：一個 AI 碰不到、也不靠 AI 判斷的旁觀者。在 fibon 裡，這個角色叫 Updater（守護更新器服務）。先據實說明它今天在 Repo 裡實際長什麼樣（services/updater/src/ 的 evolution-watcher.ts / snapshot.ts / shadow-runner.ts）：

                  ┌────────────────────────────────────────┐
                  │     主機作業系統 (Host OS / Docker)     │
                  └───────────────────┬────────────────────┘
                                      │
      ┌───────────────────────────────┴───────────────────────────────┐
      ▼ 跑在 Python 進程 (最複雜，最容易崩潰)            ▼ 跑在獨立 Node.js 進程 (職責極簡)
┌──────────────────────────────┐                   ┌────────────────────────────────┐
│   核心大腦進程 (Brain)        │  evolution volume │   獨立守護更新器 (Updater)      │
│  (掛載 evolution/skills 目錄) │ ───被改動了────>  │  (fs.watch 偵測到目錄變更)      │
└──────────────────────────────┘                   └───────────────┬────────────────┘
                                                                   │ 啟動驗證 SOP
                                                                   ▼
                                                   ┌────────────────────────────────┐
                                                   │ 1. 先對 evolution 目錄拍快照    │
                                                   │ 2. 拉起影子 Brain 容器跑煙霧測試 │
                                                   │ 3. 通過 → 優雅重啟主 Brain      │
                                                   │    失敗 → 快照目錄複製回滾+告警 │
                                                   └────────────────────────────────┘

Updater 守護層與核心大腦之間，是一份「先檢驗、再上線」的影子測試流程，而不是傳說中的心跳看門狗。這恰好回答了藍綠部署那段留下的問題：「健康檢查只看進程起得來遠遠不夠」。它的做法分三步。變更偵測：Updater 持續監視存放進化檔案的 skills/ 目錄，任何檔案變更會等 5 秒「防抖（debounce）」後才啟動流程，避免快速連續修改重複觸發。動手前先拍快照：把整個進化目錄完整複製一份進備份區、最多保留 5 份；要回滾就是把快照原樣複製回去，不是什麼高深魔法，而是最樸素、最不容易出錯的目錄複製，這就是「切壞之後的後手」。影子大腦測試：用跟正式大腦一模一樣的設定，另外拉起一隻不對外開放、用完即丟的「影子大腦」容器，先確認它健康、再對它打一發真實請求做「煙霧測試（smoke test）」，而不是只確認進程有沒有起來。三步全過，才平順地重啟正式大腦讓變更生效；任一步失敗，就立刻用快照回滾、並推送告警通知主人。

守護救援層（Updater）必須遵守的三條原則：

• 絕不與主系統跑在同一個進程或容器：主進程一旦 Stack Overflow 當機，會連帶把守護進程一起拖垮，兩者必須有完全獨立的記憶體與進程空間。這條今天已成立，Updater 是 fibon 第四個完全獨立的微服務。
• 絕不與主系統共享同一個大腦模型版本：若大腦剛才是因某家雲端 LLM 本身的結構性語意缺陷引發死循環，規劃中的「第二診斷大腦」就必須強制路由到另一家供應商或本機開源模型，否則它面對一模一樣的日誌會犯一模一樣的錯誤。對應的診斷大腦尚未實作，原則先立在這。
• 程式碼必須盡量簡單：救援者若寫了上萬行複雜程式碼，自己也會出 Bug，全系統就陷入「誰來救援救援者」的套娃困境。今天的 Updater 核心三件套（目錄監視、快照複製、影子容器）刻意只用 Node.js 原生 API 與最少依賴。簡單，是最後一道救援能可靠運作的關鍵。

這也是為什麼我一開始就決定把 Updater 當第四個完全獨立的微服務單獨部署。

自我修復能力的分級：

這整套自我修復防禦，是為了解決分級中發生機率高達 80% 的 Level 1 常見程式碼 Bug，從來不是萬靈丹。但回到藍綠部署那段留下的三個問題，fibon 給的不是完美解，而是一套跑得起來的答案：裁判交給一個 AI 碰不到的獨立 Updater、健康檢查靠影子大腦的真實煙霧測試、切壞了就用快照回滾到上一次正常狀態。病重的醫生確實沒辦法替自己開刀，但「請另一個健康的醫生趕到 + 出事自動回滾 + 影子測試 SOP」這套工程做法，已足以讓開源後的 fibon 展現出相當程度的「類自我修復能力」。

實作細節

從願景拉回地面。最後補兩塊前面提過、值得單獨展開的已實作細節：一條在安全防線內擴充能力的「能力市集」，以及讓大管家在對話中現場長出新資料表的「動態實體」。

[ 用戶: "幫我追蹤每本書進度" ] ──> 大管家調用 create_dynamic_entity
                                        │
                                        ▼
                    [ PostgreSQL dynamic_entities 表 ]
                    (自動 UPSERT 寫入一列全新的 JSONB Schema 定義)
                                        │
                                        ▼ (gRPC / SSE 訊號)
                    [ 前端 Vue 3 數據驅動引擎 ]
                    (自動、無感、現場渲染出全新 CRUD UI 業務面板)

下一章，接著談與自我進化一脈相承、但在維運上更棘手的主題：沙盒（Sandbox）安全邊界防線。如果說自我進化解決的是「AI 該如何安全修改 fibon 自己」，那下一章的沙盒解決的是「當外來的陌生人或惡意駭客把一段危險程式碼交給 AI、要它在你的主機上立刻執行時，怎麼在底層建起嚴密的隔離區（DMZ），把危險程式碼關進與外界隔離的環境」。第六章見。