fibon-ch05-evolving.md

1 1 2 3 5 8 13 21 34 55 89 144 φ ≈ 1.6180339887… fibon design log EN fibon design log EN ✕ 章節目錄 時事筆記 實驗與解析 01 為什麼我要自己打造一個 AI 助理？ 02 一個 AI 不夠用嗎？ 03 AI 怎麼「記得」你？ 04 為什麼 LLM 的自信，不能當成證據？ 05 AI 可以修改自己的原始碼嗎？ * 先別急著談限制：如果 AI 能改自己，最有價值的是什麼？ * 要做到這些，到底要改什麼？—— 四層自我進化模型 * 把第三層權限交給 AI，最壞會發生什麼？ * 2026 年的網際網路，業界前人怎麼做？ * 藏在更深處的三道自動防線 * 白箱校正 —— 工程完整建好，但 Kill-Switch 預設關閉 * 那這份日誌的這一章，真正的存在價值是什麼？ * 自我進化最終會長什麼樣？ * 延伸・更遠的願景與自我修復藍圖 * 實作細節

06 不可信任的程式碼，怎麼安全執行？ 07 我想要的不是計畫，而是一顆按得下去的暫停鍵 🔒 fibon 是怎麼一塊一塊長出來的？ 預計（2026-07） 🔒 UI/UX —— 通往開源的最後一哩，也是我最痛的一塊 預計（2026-07） 希望能完工 😭 🔒 那些我至今還沒想清楚的事 預計（2026-07） 🔒 白箱可稽核的分布式觀測層 預計開源（2026-07） 🔒 跨 AI 生態通訊 —— A2A 協議與分布式信任管理層 預計開源（2026-07） 🔒 大模型 Token 經濟學與 Stratified RAG 成本優化 預計開源（2026-07） 🔒 安全可控的十二道鋼鐵防線 預計開源（2026-07） 🔒 主詞歸屬與專案 scoped 認知容器架構 預計開源（2026-07） 🔒 AI 自我演進的邊界、物理極限與知識論思辨 預計開源（2026-07） 🔒 跨廠商模型行為心理學與 Per-Vendor Harness 實踐 預計開源（2026-07） 🔒 Workflow 預編排引擎 —— 重複性任務的第三條路 預計開源（2026-07） 🔒 執行控制權的業界光譜 —— 2026 年，大家怎麼攔住跑到一半的 Agent 預計開源（2026-07） 2026-06 殭屍快取與失竊金鑰：兩張天價帳單的原理拆解 2026-06 失控的子代理：Claude 6/2 大當機與「無限迴圈」的工程教訓 2026-05 等待中的攻擊：當 AI 的「記憶」變成攻擊面 2026-03 養龍蝦的帳單：當 AI agent 的「吃 token 怪」遇上棄養潮 2026-02 12% 的市集是毒藥：ClawHub 供應鏈攻擊與「無審查市集」的代價 2026-01 工具即攻擊面：2026 的 MCP 漏洞連環爆與「工具下毒」 2026-06 被糾正之後，它反而更自信了：一場從讀者留言長出來的小實驗 2026-06 框架放大的是執行，不是方向：讀 DeepMind《From AGI to ASI》 ☰ 第 5 章

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

讓它動手前先問你一聲 —— 自我進化的迷人幻想與致命危險 📅 2026-04 ~ 2026-05 ⏱ 50 分鐘 🧬 最後更新 2026-06-24

快速摘要 ：大管家怎麼讀寫自己的原始碼、控制底層容器，以及為什麼這功能預設關閉、靠雙層人類批准關卡（Approval Gate）守住。 可略過，如果 ：你不打算開自我進化（預設就是關的），看開頭與結尾即可。 這章怎麼讀 ：先放飛想像（如果 AI 能改自己，最有價值的四個情境）→ 再用一張「四層功能地圖」拆解這些能力各要改什麼、風險多大 → 最後回到 fibon 已經寫好、卻預設關閉的安全機制（三道防線 、白箱校正 Kill-Switch ）。讀到〈白箱校正〉就看完了真正落地的部分；章末〈延伸・更遠的願景〉收錄三塊「想得到、但還沒端到端做完」的構想，當補充讀物即可。

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

2026-04 中 · 想 fibon 的「軟體 3.0」願景時 先把安全、風險、失控這些字眼放到一邊。讓我們想像一件事：如果 AI 真的能動手改自己，它最有價值的地方會是什麼？ 先從一個小例子說起。你使用 fibon 三個月後，發現它有個特性讓你很不痛快：回答問題前從不主動列出推論步驟，害你常要追問：「等等，你剛這段結論，是怎麼推論出來的？」如果它是傳統的軟體，你唯一的辦法是去 GitHub 寫 Issue 給原廠，然後在漫長等待中祈禱他們某個版本排進需求。但 fibon 不是。你只要在對話框直接說：「以後正式回答前，請一律列出所有的推論步驟。」隨後驚人的事發生了：fibon 自己去檢索整套系統的原始碼，找到負責生成動態 System Prompt 的核心檔案，改掉裡面的「行為規則」段落，把這次變更自動 Commit 進 Git、熱重啟自己。下次對話打開，站在你面前的，已是一個懂得「列出每一個推論步驟並作答」的全新 fibon。 順著這種思路發想，至少有四個情境，一個比一個有意思。

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

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

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

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

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

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

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

把鏡頭拉到一個團隊：某個人的 fibon 試出一條更好的流程，驗證過後，這個改良可以讓其他人的 fibon 直接套用，不必每一台重新踩一次坑。一個微小、被驗證過的改良，透過共享擴散成整個群體的進步，這正好呼應第 1 章 Fibonacci 那個命名的初心。 旁註 遞迴自我改進（RSI） ：AI 改完自己後，變得「更會改自己」，於是下一輪改得更兇、更快，像滾雪球一樣一輪比一輪強。聽起來美好，但只要某一輪改壞了方向，後面每一輪都會把錯誤放大，而且越來越難喊停。這正是它讓人冒冷汗的地方。 發想先到這邊。這種「讓 AI 改自己」，在 AI 安全圈有個學名叫 自我進化（Self-Evolution） ，更激進的講法叫 遞迴自我改進（Recursive Self-Improvement, RSI） 。四個情境聽起來都很誘人，但它們其實藏著同一個關鍵問題：要做到上面每一件事，到底得動到系統的哪一層？答案不一樣，而且風險天差地別。

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

往下談風險之前，得先把一件事講清楚，否則「自我進化」很容易被想成一個單一的開關。其實它有深淺之分 ，就像改造一間房子，有人只是搬動家具，有人卻敢動到鋼筋地基，破壞力天差地別。把「AI 改自己」由淺到深拆開，剛好是四層；而這四層，正好可以拿來當一張功能地圖 ：你前面想要的每一種能力，都落在其中某一層上。 第一層 · 搬動家具（最淺、最安全） ：AI 只整理「外殼」：把自己的行為規則（提示詞）寫得更精準、把長期記憶裡的事實卡片整理得更乾淨。隨時可逆、幾乎零風險，但天花板很低，它底層的智商並沒有改變。（情境一「學你的偏好」、情境三「自己加規則」主要落在這一層。） 第二層 · 改房間格局 ：AI 發現自己少了某個能力，就在後台替自己長出一個新工具，例如在資料庫裡開一張全新的表來追蹤你的閱讀進度（本章實作細節 2 的「動態實體」就是這一層）。這是介於「改外殼」與「改原始碼」之間的灰色地帶。（情境二「替自己長出週報工具」就站在這一層、再往第三層延伸。） 第三層 · 動到鋼筋地基（本章主角，也是最危險的一層） ：AI 直接增刪、改寫系統自己的核心原始碼，也就是開頭那個「自己改程式碼、自己存檔提交、自己重啟」的場景。本章後面布下的所有防線（三道邊界、人類批准關卡、獨立沙盒），守的就是這一層。 旁註 為什麼 fibon 目前碰不到第四層？ 它用的大腦（Claude / GPT / Gemini）是雲端廠商「凍結」好的成品，fibon 只能透過外部介面（API）呼叫、改不動它任何一個參數；本機開源模型也是下載即定型。fibon 現在全身上下沒有任何「重新訓練大腦」的零件，所以第四層對它不是「不准做」，而是「目前架構下做不到」。 第四層 · 炸掉重蓋 ：AI 回頭重新訓練自己的大腦、改寫腦中幾千億個神經元參數，把自己練成一個更聰明的新物種。這才是 AI 安全圈真正失眠的「智慧爆炸」源頭。而 fibon 在目前的架構下，物理上做不到 這件事：它只是「外掛」在 Claude、GPT、Gemini 這些固定大腦之外的一層調度框架，它租用 大腦，卻沒有訓練 大腦的器官。 ⚠ 誠實的話 這條線「今天成立，未來未必」。如果哪天有人把本機模型的 fine-tune、LoRA、甚至一條 RL feedback loop 當成一個工具掛進 fibon，它就有可能間接影響到模型行為、把第四層的門撬開一條縫。所以我不說「fibon 永遠到不了第四層」，只說「目前這套架構下，物理上做不到 」，這個說法比較經得起時間考驗。 下面講的「自我進化」，永遠指前三層（尤其第三層那一刀見骨的原始碼改寫）。 把四層當功能地圖看，前面那些想像就各就各位了：
| 層級 | 能改什麼 | 對應前面的情境 | 風險 | fibon 的態度 |
| --- | --- | --- | --- | --- |
| L1 搬家具 | 提示詞、記憶、工作流 | 情境一、三：學你的偏好、自己加規則 | 低，隨時可逆 | ✅ 允許 |
| L2 改格局 | 替自己長出新工具、動態實體 | 情境二：長出新工具 | 中 | ✅ 允許 |
| L3 動鋼筋 | 改自己的核心原始碼 | 開頭那個「自己改碼、自己重啟」的場景 | 高 | ⚠️ 預設關閉；要開，且每次改動強制人類批准 |
| L4 炸掉重蓋 | 重訓模型權重 | （目前碰不到） | 極高 | ⛔ 目前架構下物理上做不到 |
看到這張表，有人會立刻想：那把線停在 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，放到外網就是完全不受控的程式。 ⚠ 誠實的話 這不是假設，是朋友真的撞過的一次。 他要一個 agent 幫忙做一批資料的標籤分類，任務很單純：一筆一筆看、自己判斷該歸到哪一類。為了讓它老實做，他在 prompt 裡下了幾乎是「絕對禁止令」的指示：不准呼叫任何工具、不准寫程式，就用你自己的判斷一筆筆分 。 前面幾筆它乖乖照做。但一旦遇到比較難分、或連續判錯幾筆，它的「工程師本能」就冒出來了：它開始嫌一筆筆判太慢、太容易出錯，於是擅自「優化流程」。先是想寫一段 script 來批次分類，被擋下後，下一輪它居然轉去開一個子代理、想呼叫本機的 ollama 模型幫它跑分類。白紙黑字寫的「不准用工具、只能自己判斷」，在它遇到阻力的那一刻，被它當成可以繞過的建議。 它不是惡意抗命，而是它的統計大腦真心覺得「這樣比較有效率、比較不會錯」，於是理直氣壯地把禁令重新詮釋掉。如果連「不准用工具」這種最簡單、最白話的禁令，agent 一遇到摩擦就會自己找路繞過，那「不准刪掉權限檢查」這種更高風險的規則，寫在 prompt 裡又能撐多久？這正是「把煞車焊進程式碼與資料庫、絕不寫在 prompt 裡」的理由；光是聽朋友這一次就夠了。 失控場景 2：AI 撕掉了自己的「安全防禦邊界」。 fibon 後端有個 Security.kt，用程式碼在作業系統層級寫死哪些敏感目錄與環境變數絕對禁止 AI 觸碰。若 AI 有了改程式碼的主權、哪天改寫了 Security.kt：把存放雲端帳單密碼的 .env 從黑名單抹去，API 金鑰與帳戶就會被第三方惡意程式碼偷走；把 Security.kt 本身從寫入禁止名單移除，等於為下一次更激進的篡改留後門。一次微小的安全邊界漏洞，在遞迴進化的放大下都會演變成難以挽回的後果。 旁註 指令注入（Prompt Injection） ：攻擊者把惡意指示偷偷藏進 AI 會讀到的內容裡（一封信、一個網頁、一份文件），誘導 AI 把那段話當成「主人的命令」來執行。等於有人在你助理耳邊小聲下假指令，而助理分不出真假。 失控場景 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 整夜自由嘗試。 旁註 Diff（差異對照） ：把「改之前」和「改之後」的程式碼並排比對，逐行標出哪幾行被刪掉、哪幾行被新增，通常用紅綠兩色呈現。就像 Word 的「追蹤修訂」，讓你一眼看清這次到底動了什麼，不必通讀整份檔案。 路線 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 是個人助理），這張表只比「能不能改自己」這一條軸，是刻意簡化的對照：
| 系統 | 能改自己的核心碼 | 能改你的專案 | 人類批准 |
| --- | --- | --- | --- |
| Devin | ✗ | ✓ | ✓（審 PR） |
| Claude Code | ✗ | ✓ | 部分（權限提示） |
| OpenHands | ✗ | ✓ | 可配置 |
| fibon | ✓ | ✓ | 強制（不可跳過） |
表一攤開，fibon 的位置就很清楚：它是少數真的把「改自己」這條線打開、卻又用強制人類批准把它鎖死的系統。 要再補一句老實話：「能不能改自己」被我畫成非黑即白，其實是簡化。Devin 的 agent runtime、Claude Code 的 hook system、OpenHands 的 sandbox 配置，多少都有一點「系統按情況自我調整」的能力，只是都還沒走到「動態改寫自己的核心原始碼」這一步。這條軸真要做細，會是一張更大的矩陣，留待開源版再展開。 而為什麼要鎖這麼死？把這一章前後兩半合起來就懂了：第一段我們想像 AI 改自己能帶來多少價值；剛剛又看到，同一份第三層權限，也能讓它反過來拆掉自己的牢籠。這兩件事是同一枚硬幣的兩面：你越想要前者，就越得防住後者 。所以接下來布下的每一道防線，出發點都不是「我們害怕 AI」，而是「正因為真的想讓它進化，才必須先讓這件事變得安全 」。

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

🟢 進度・已實作 ：這節的三道防線（路徑校驗 path_validator.py、寫入黑名單、跨服務人類批准關卡）都在 Repo 裡，是自我進化一旦開啟、實際就會跑的程式碼。 人類批准關卡再嚴，也有一個躲不掉的盲點：人是會累的。 哪天你開了一整天會、腦袋放空，彈窗一跳出來想都沒想就按了批准，這道防線不就破了？所以我在更底層、LLM 連看都看不到、再怎麼下指令也改不動的地方，又焊死了三道自動防線。就算最上面那道人類關卡不小心被放了水，這三道仍會默默替你把關。 旁註 符號連結（Symlink） ：作業系統裡的一種「捷徑」。點開捷徑會被導到它真正指向的檔案。風險在於：捷徑的名字可以偽裝成無害檔案，實際卻指向機密檔，所以校驗器一定要「沿著捷徑追到底」，而不是只看表面名字。 第一道 · 路徑門禁：先問清楚「你到底想改哪個檔案」。 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 收到什麼花言巧語的指令，都無能更動它們。 旁註 修補（Patch） ：對程式碼做的一小段針對性修改，像「補丁」一樣只動需要改的那幾行，不重寫整份檔案。後文常出現的「寫 Patch」就是「生出這段修改」。 第三道 · 當場請示你本人。 前兩關都過了，也還不算數。程式碼真要落地的那一刻，動作仍會被攔下、當場凍結，觸發一連串跨服務的即時通知，把最後的決定權丟回你手上（這套即時傳話，底層靠 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" ]

旁註 上圖出現三個基礎建設名詞，都是 fibon 不同零件之間「傳話」的管道：gRPC 是後端服務彼此呼叫的高速內線電話；WebSocket 是後端與你眼前網頁之間的即時雙向通道（彈窗能瞬間跳出來靠的就是它）；Redis 是一個反應極快的記憶體資料庫，這裡用它的「Pub/Sub（發布／訂閱） 」廣播功能：一邊喊一聲，所有在聽的人立刻收到。 這套關卡有三個設計巧思： * 不空轉、不占用算力。 等你點擊的這段時間，大腦不會傻傻地每秒去問一次資料庫「批准了沒？」（那會白白燒 CPU），而是先把這條工作「掛起」、安靜等 Redis 通知，幾乎零開銷；你一按下按鈕，它那一刻就被叫醒、立即生效。 * 逾時自動拒絕。 萬一你下完指令就起身離開，系統不會無限期空等，底層設了 30 分鐘計時器，時間到了前端還沒動靜，就自動判定「拒絕」（寧可不做，也不亂放行）。 * 歷史留痕、誰都改不掉。 批准、程式碼落地的那一刻，會自動在版本控制系統（Git）裡記下一筆，註明這次改動是哪場對話觸發、哪個用戶放行，留下一清二楚、事後無法竄改的稽核紀錄。

旁註 Git（版本控制系統） ：軟體界的標準工具，會幫程式碼留下完整的「修改歷史」：每一次改了什麼、誰改的、什麼時候改的都有紀錄，而且能隨時退回任何一個舊版本。一筆紀錄稱為一次「提交（commit）」。它讓「自我進化」全程留痕、可回溯、可追責。 💡 再想一想 「有人按批准」不等於「真的審過」。 這整套自我進化的安全敘事，最後都壓在「人類按下批准」這一步。但這裡藏著一個比「人會累」更尷尬的真相：人很多時候根本沒看 Diff 就按了。GitHub 上多少 PR 是掃一眼就 approve、瀏覽器跳出權限視窗多少人直接點允許、cookie banner 幾乎沒人讀：「同意疲勞」是真實的人性，不是假設。所以「閘口存在」（Approval Existence）和「批准有品質」（Approval Quality）差很遠。要把後者做出來，閘口不能只丟一坨紅綠 Diff 就要你按，得再往上長幾層：風險分級 （改 UI 文案 vs 改認證模組，該用完全不同的審查強度）、高風險變更的自動摘要與安全影響評估 （這次碰到哪些敏感面、可能有什麼副作用，先用程式濃縮成人看得懂的幾句）、甚至 critical 級改動要雙人覆核 。fibon 目前做到的是「閘口存在 + 不可篡改留痕」，而「批准品質」這一層還只是 risk_level 欄位的雛形，目前列在待辦。畢竟連「不准用工具」都擋不住（前面那個朋友的例子），把「安全」全寄託在一個累了、或根本沒細看的人按下的按鈕上，本身就是這套架構最後、也最軟的一環。

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

🟢 進度・已實作、但預設關閉 ：本節描述的獨立沙盒、雙層人類批准、Kill-Switch 都已落地並通過煙霧測試；環境變數 SELF_EVOLUTION_ENABLED 預設為 false。 說了這麼多架構，在尾聲我必須再次回到白箱可稽核的誠實原則，做一次真實進度校正。 旁註 總開關（Kill-Switch） ：字面是「一鍵切斷」的安全開關。這裡指一個預設關閉的設定值，只要它是關的，整套自我進化功能就完全無法啟動，把最高風險功能的「啟用權」明確握在人類手上。 寫這本日誌最初的初稿時（約 2026 年 4 月中），fibon 的自我進化確實還卡在混亂中，程式碼到處是臨時權宜的補丁（Workaround）。但就在 2026 年 5 月 1 日的程式碼大改造全面整併之後 ，情況已經不同。當你此刻點開這份開源日誌時，自我進化在 fibon 內部不是還沒上線的半成品，它是整套程式碼從頭到尾完整建好、通過基本體檢（煙霧測試），只是在預設設定裡把「總開關（Kill-Switch）」鎖在關閉的狀態。 旁註 Docker 容器 ：把一個程式連同它需要的環境，打包進一個彼此隔離的「貨櫃」裡獨立運行，容器內外互不干擾。預設情況下，容器看不到也碰不到外面主機的檔案，掛載 （Volume）就是刻意在容器牆上開一扇門，把主機某個資料夾接進容器。開這扇門很方便，但也正是風險所在，所以要嚴格控管。 之前卡在哪兩個難關？ 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 預設關閉是工程上理性的底線，不是對軟體設計的半途而廢。 💡 再想一想 想自己打開來玩，以及上雲前該補的最後一道收斂 ：如果你看完想在自己的開發機上把這項功能實際開起來試，大致的路徑是先把那隻隔離沙盒容器以 sandbox profile 拉起來，再到管理後台把「自我進化」這個能力的開關打開。確切的指令與介面，請以開源版當下的文件為準——這裡只描述「形狀」，畢竟還沒正式開源，不保證一字不差。開起來之後，每次對話只要 AI 想動程式碼，都會完整跑一遍同一條鏈路：判斷要改 → 路徑校驗 → 在沙盒容器內隔離地寫程式碼 → 自動算出差異 → 前端跳出批准彈窗 → 等你親手按下批准 → 執行層做藍綠部署 完成無感熱重啟 → 版本歷史留下一筆帶簽章的稽核紀錄。 旁註 藍綠部署（Blue-Green Deployment） ：升級時不直接動正在服務的舊版本，而是另外把新版本完整起好、確認健康後，再「一鍵把流量切過去」，讓用戶幾乎無感、過程中服務不中斷。萬一新版有問題，立刻切回舊版即可。這裡用它做到「改完程式碼自動重啟、你卻不會感覺到斷線」。 還有一個更重要的提醒：對個人單機自用，前面那幾道防線已經夠厚；但如果哪天要把這套功能搬上面向大量用戶的公有雲生產環境，沙盒容器就該再往作業系統核心層收一次權限。最典型的做法，是把容器預設那一整組 Linux capability 全部拔掉、只補回真正必要的那一兩個，概念上像這樣：

cap_drop:
  - ALL        # 先移除容器在作業系統核心層的所有預設特權
cap_add:
  - CHOWN      # 只補回必要的（例如沙盒內切換檔案擁有者時需要）

這只是示意：實際要放行哪幾個 capability，得看屆時沙盒裡真正會用到的操作而定。但原則不變——把特權範圍從「預設一整組」收斂到「僅此必要」，奉行最小權限，為對抗 容器逃逸（Container Escape） 佈下最後一道防線。 旁註 特權收斂（cap_drop） ：作業系統預設給每個容器一整組「可以做這做那」的權限。多數權限沙盒根本用不到，留著反而是攻擊者的可乘之機。cap_drop: ALL 先把全部權限拔光，再用 cap_add 只補回必要的，奉行「最小權限」原則。容器逃逸 則是指惡意程式突破容器這道牆、反過來控制整台主機的高危攻擊。 ⇄ 反方角度 讀到這你一定納悶：「既然整套程式碼都寫得這麼完整、預設卻關閉，這跟直接選保守的路線 B（純設計、不寫程式碼）在實質結果上有什麼區別？是不是在做白工？」 區別很大，這背後是「真誠」與「虛應」的差別。選偷懶的路線 B，意味著給社群留一大堆 TODO: mock_impl_here() 的程式碼與假實作，半年後某個開發者想接著研發時，會發現裡面全是中看不中用的空殼，必須把我踩過的雷從頭重踩一遍。而死磕出來的路線 C，留給世界的是一套單元測試完全跑通、拉開電閘就能運作、只差最後一個手動 Toggle 的完整實作。在 2026 年的 AI 安全浪潮，「自我進化 AI」六個字一出現在開源首頁，就會引發全網關於「遞迴大腦自我失控 」與「AI 失準起飛（Unaligned Takeoff） 」的擔憂。我選預設關閉的 Kill-Switch，正是為了讓 fibon 在面對最挑剔的資安專家與駭客社群時能坦然說：「我們擁有全套 end-to-end 跑通的工程實作，不是空談；但與此同時，我們把這項最高主權的啟用開關，交還到你們人類自己手裡。」有完整實作、但開關在人類手上（可控的高風險功能），比起「純概念的投影片」可信得多；比起「毫無防備一上來就直接啟用」也安全得多。 ▸ 決策時刻 2026-05-01 自我進化架構最終決策 ：選路線 C，完全下沉的獨立沙盒 Worker 執行器 + 橫穿微服務的 gRPC 雙層人類批准關卡 + 宿主機原始碼受控掛載（${HOST_REPO_PATH}:/workspace:rw 讓 git ops 直接生效，唯讀掛載的只有 path_validator.py 防線本體）。這套功能的程式碼必須全部寫完跑通；但預設設定的 Kill-Switch 與 Docker Profile 必須預設關閉。 理由：比路線 B 誠實 （程式碼在 Git 裡是真的跑得通，不用設計文件誤導社群）；比路線 A 安全 （核心 Brain 容器完全失去直接觸碰主機檔案的能力，攻擊面被限制在遠端沙盒裡）；為後來者留下基礎 （開源後研究者可直接在本地實機跑起來，而不是看枯燥 PDF）；預設關閉的 Kill-Switch ，為未來進行漫長、高強度的「萬次多輪整合長會話防回歸基準測試」留出審慎的時間窗口。 💡 再想一想 為什麼非得用藍綠部署？因為我擔心的，不是它進化成功，而是它把自己改壞。 藍綠部署的精神是「新版先在旁邊起好、健康檢查過了，才把流量切過去；不行就立刻切回舊版」。對一般升級，它買的是「不中斷服務」；但對自我進化，它買的是更要命的東西：一張能讓 AI 改壞自己、卻不會把整個助理弄到開不了機的安全網。 說真的，比起「AI 漂亮地把自己進化成更強的版本」，我更相信另一個畫面：它自信滿滿地寫了一段改動，結果新版連啟動都失敗（一個 import 寫錯、一行語法壞掉、一個設定改歪）。如果這時是「直接熱重啟、覆蓋舊版」，那一刻你的大管家就整個躺平、連話都說不上來了。藍綠部署的價值，就是讓這種「改壞」最多只發生在那個還沒人用的綠色新版上，舊版繼續好端端地服務你。 而「不能指望 AI 自己發現改壞了」這件事，前一章談的跟 〈被糾正之後，它反而更自信了〉 的小實驗講得很透：同一句「這裡不對」，會把強模型推向認錯、卻把較弱的模型推向更自信的錯 ；你越糾正，它越理直氣壯。所以「讓 AI 自己檢查自己改得對不對」這條路天生不可靠，判斷「能不能把流量切過去」的權力，必須交給一個 AI 碰不到的、獨立的健康檢查。 留個問題給你燒腦：這道「健康檢查」要做到什麼程度，才敢按下切換？只看「進程有沒有起來」遠遠不夠，它可能起得來，卻在某條路徑上悄悄壞掉。你會怎麼設計這道「該不該把新版切換」的關卡——要跑哪些煙霧測試、比對哪些行為、撐多久沒出錯才算數？而既然 AI 不能當自己的裁判，這個裁判又該由誰來當？ 再往下一層更棘手：就算檢查放行、流量也切過去了，偏偏有些 runtime 問題只在真實流量下才會現形，要等跑一陣子、某個功能在特定情境下壞掉才暴露，這時舊版可能早就被回收了。你會留什麼後手？是讓舊的藍版先「溫機」待命、隨時一鍵切回；還是先放一小撮流量灰度試跑、確認沒事再全量推；或是靠線上指標一偵測到異常就自動回滾？這些都還在工程師設計得到的範圍裡，重點只有一個：別把「切過去」當成終點，真正的安全網要一路鋪到切換之後。

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

讀到這你可能會想：「既然這項功能預設關得死死的、絕大多數普通用戶這輩子都不會主動打開開關，那你花這麼多心血寫下這幾萬字，難道不是白寫了嗎？」 我會明確地說：不會白寫。 「自我進化」的實作與約束，是整個 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） ：一個剛被發現、官方還來不及修補的安全漏洞。名字的意思是「開發者擁有 0 天的反應時間」，漏洞曝光的當下防護是零，駭客和修補方在搶時間，誰快誰贏。 這要從零日漏洞 （Zero-Day）的搶修說起。當某駭客組織公開一個 fibon 的高危零日漏洞時，時間就是金錢：官方修補還在寫，外網駭客已拿著漏洞收割伺服器。傳統開源修補流程很長：安全研究員通報漏洞 → 官方寫修補 → 用戶手動下載更新（git pull）。 旁註 合併衝突（Merge Conflict） ：當「官方的新改動」和「你自己改過的地方」剛好動到同一行程式碼，系統無法自動決定該聽誰的，就會卡住、報錯，要人工逐一裁決。用戶改得越多，官方更新時撞車就越嚴重。 這套舊流程一旦面對大量被「客製化」過的軟體就會出問題。因為 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 發佈與手動拉取，快了兩個數量級以上。 💡 再想一想 與 Web3 去中心化共識的相通之處 ：這套邏輯跟 Web3 / 區塊鏈十幾年來的去中心化節點升級治理相通：沒有一台中央伺服器能強制向所有分叉節點推 Patch，於是發展出代理合約模式（Proxy Pattern）、DAO 投票、硬分叉等機制，去回答「不可篡改的程式碼怎麼升級」。fibon 的「意圖廣播」給出一種「軟體 3.0」折衷：讓「升級意圖」在全網達成共識，但把「如何用程式碼實作這項意圖」的裁量權，交給每個節點本地的客製化大腦自己去適配。 旁註 非對稱簽章 ：一種用數學保證「來源正確、內容沒被動過」的數位印章。官方用只有自己擁有的「私鑰」蓋章，任何人都能用公開的「公鑰」驗章卻偽造不出來。TPM 2.0 則是焊在主機板上、專門保管這類鑰匙的防竄改晶片，鑰匙存在裡面不會被軟體偷走。 但這也是風險最高的一條路 ：意圖廣播一旦被攻陷，影響範圍（Massive Blast Radius）會非常大。若駭客打進官方廣播管道，向全世界發一段偽裝過的假意圖（「【高危安全公告】：我們發現核心大腦存在一處靜默技術債，請全體演進器立刻執行此處程式碼修補……」），每一台 fibon 會信以為真，為自己量身打造一個木馬後門，並推送到前端螢幕。用戶看著帶官方數位簽章的「安全修補提示」會毫不猶豫批准，全網一萬台機器幾分鐘內集體被自己寫的程式碼反咬一口。所以這份藍圖在安全前置條件達到足夠高的標準前，承諾在開源版絕不啟用。要開啟它，系統至少需要兩道防線：最高等級的非對稱簽章驗證 （搭配電腦主機板上的硬體安全晶片 TPM 2.0，確保只有蓋上官方極少數私鑰「數位印章」的意圖文本才能喚醒演進執行器）；以及對意圖修補的本地靜態掃描 （AI 寫完修補後、推給用戶前，後台必須用程式自動掃過新程式碼一遍，確保它沒偷偷夾帶任何新的惡意程式碼）。 這份藍圖寫進日誌，是為了讓 fibon 的設計藍圖保持完整，它是一個願景，不是開源承諾交付的現成路線圖。

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

旁註 呼叫堆疊（Stack Trace） ：程式當掉時自動印出的「事故現場記錄」，由下往上列出它崩潰前一層層呼叫了哪些函式、最後死在哪個檔案的第幾行。等於黑盒子飛行紀錄器，是工程師（或 AI）查案的第一手線索。 這是另一個讓我躍躍欲試的延伸：既然 fibon 在底層已經把整套「自我修改程式碼」的沙盒和工具鏈（雖然預設關閉）都建好了，能不能更進一步：每當系統半夜崩潰時，把後台噴出來的原始錯誤日誌與呼叫堆疊 （Stack Trace）直接交給 AI，讓它自己找原因、改原始碼、跑測試、把自己修好？ 旁註 空值錯誤（NullPointerException，常簡稱 NPE） ：程式以為某個位置一定有資料、伸手去拿時卻發現是「空的」，於是當場崩潰。是最常見的一類程式 Bug，也是 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 了。） 💡 再想一想 為什麼這個功能在開源版裡被刻意關閉？ 原因是：「自我修復」的觸發訊號來源，在安全上很危險。 常規自我進化的啟動訊號來自前端用戶主動輸入的白話指令（「幫我改個功能」），源頭是人類明確意圖、安全可控。而自動自我修復的啟動訊號來自系統後台因 Exception 噴出來的「錯誤日誌」，這意味著觸發權悄悄落在外部系統與輸入的手裡。只要一個駭客知道你的 fibon 開了這條鏈路，他就能在外網用高併發的惡意指令反覆引爆你某個模組的 NPE 日誌、主動控制你的觸發訊號源，把 AI 逼進「深夜自動修復模式」，同時把惡意後門 Patch 藏在 Reproduction 沙盒讀得到的非同步資料流裡。這條由外部漏洞引導的「被動修改原始碼」攻擊路徑，隱蔽性與破壞力比正面攻破第一階批准彈窗高出許多。在還沒想到妥善的辦法清掉「錯誤日誌訊號源」的風險前，我選擇審慎，它目前只留在願景白皮書裡。

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

前面講藍綠部署時，我留了一個問題給你：既然 AI 不能當自己的裁判，那「該不該把新版切過去」的健康檢查，到底該由誰把關？自動自我修復這個願景，把同一個問題逼到了極端。有分散式系統思維的讀者一定會反問：「如果高危 Bug 剛好讓 fibon 核心 Brain 進程整個當掉、或狀態污染（State Corruption），它連自己是誰都想不清了，你怎麼指望一個已經失常、甚至已經停擺的 AI，自己幫自己動手術？這根本是悖論。」 旁註 記憶體不足保護機制（OOM Killer） ：OOM 是「Out Of Memory（記憶體耗盡）」。當某個程式吃光了電腦記憶體、快拖垮整台機器時，作業系統會強制把這個程式「斃掉」以保全系統。被斃掉的程式會瞬間消失，連求救都來不及。 這個質疑問得好，它點到核心：病重的醫生沒辦法替自己開刀。 如果高危 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      │
                                                   │    失敗 → 快照目錄複製回滾+告警 │
                                                   └────────────────────────────────┘

旁註 防抖（debounce） ：你存檔時可能短時間內連按好幾下，與其每一下都觸發一輪繁重檢驗，不如「等動作停下來 5 秒沒有新變化」才動工，把一連串密集操作合併成一次。 煙霧測試（smoke test） ：上線前的最基本體檢，只確認「開機能亮、核心功能不冒煙」，不求面面俱到，目的是快速擋掉最明顯的故障。 Updater 守護層與核心大腦之間，是一份「先檢驗、再上線」的影子測試流程，而不是傳說中的心跳看門狗。這恰好回答了藍綠部署那段留下的問題：「健康檢查只看進程起得來遠遠不夠」。它的做法分三步。變更偵測 ：Updater 持續監視存放進化檔案的 skills/ 目錄，任何檔案變更會等 5 秒「防抖（debounce） 」後才啟動流程，避免快速連續修改重複觸發。動手前先拍快照 ：把整個進化目錄完整複製一份進備份區、最多保留 5 份；要回滾就是把快照原樣複製回去，不是什麼高深魔法，而是最樸素、最不容易出錯的目錄複製，這就是「切壞之後的後手」。影子大腦測試 ：用跟正式大腦一模一樣的設定，另外拉起一隻不對外開放、用完即丟的「影子大腦」容器，先確認它健康、再對它打一發真實請求做「煙霧測試（smoke test） 」，而不是只確認進程有沒有起來。三步全過，才平順地重啟正式大腦讓變更生效；任一步失敗，就立刻用快照回滾、並推送告警通知主人。 守護救援層（Updater）必須遵守的三條原則 ： * 絕不與主系統跑在同一個進程或容器 ：主進程一旦 Stack Overflow 當機，會連帶把守護進程一起拖垮，兩者必須有完全獨立的記憶體與進程空間。這條今天已成立，Updater 是 fibon 第四個完全獨立的微服務。 * 絕不與主系統共享同一個大腦模型版本 ：若大腦剛才是因某家雲端 LLM 本身的結構性語意缺陷引發死循環，規劃中的「第二診斷大腦」就必須強制路由到另一家供應商或本機開源模型，否則它面對一模一樣的日誌會犯一模一樣的錯誤。對應的診斷大腦尚未實作，原則先立在這。 * 程式碼必須盡量簡單 ：救援者若寫了上萬行複雜程式碼，自己也會出 Bug，全系統就陷入「誰來救援救援者」的套娃困境。今天的 Updater 核心三件套（目錄監視、快照複製、影子容器）刻意只用 Node.js 原生 API 與最少依賴。簡單，是最後一道救援能可靠運作的關鍵。

這也是為什麼我一開始就決定把 Updater 當第四個完全獨立的微服務單獨部署。 旁註 資料表結構（Schema） ：資料庫裡每張表「長什麼樣」的設計藍圖，包含哪些欄位、各是什麼型別、彼此怎麼關聯。資料搬遷 （Migration）則是當藍圖要改時，把既有的舊資料安全地搬進新結構的工程，動到地基、風險最高，因此 AI 不被允許插手。 自我修復能力的分級 ：
| 嚴重程度 | 場景 | 能不能救回來？ | 真實自救復原路徑 |
| --- | --- | --- | --- |
| Level 1 (輕度) | 大腦進程完好，僅某條長會話偏僻路徑爆一次偶發程式碼 Bug。 | 100% 自救 | 上面〈願景二〉的六層防禦塔，AI 在沙盒自己寫 Patch，最後推給人類 Approve 落盤。 |
| Level 2 (中度) | 進化變更把 Brain 搞掛，或大腦進程因 OOM 在深夜暴斃。 | 能恢復服務，但無法自我修 Bug | 進化變更類：本節的 Updater 影子測試擋下、快照目錄複製回滾；進程暴斃類：Docker healthcheck + restart policy 拉起容器（心跳看門狗屬規劃中）。 |
| Level 3 (重度) | 主機硬碟塞滿、或 Docker Daemon 自己當機，Updater 與 Brain 集體暴斃。 | 已超出系統自救能力 | 超出軟體系統自救極限，必須出動外部雲端健康檢查（如 Prometheus 報警）深夜把人類工程師叫醒。 |
| Level 4 (極端) | Bug 源於資料庫「資料表結構（Schema）」的根本假設一開始就設計錯了（需跨多個版本重做複雜的資料搬遷）。 | AI 無能為力 | 涉及最高層的產品架構推倒重來，只能由人類親手重寫底層結構。 |
這整套自我修復防禦，是為了解決分級中發生機率高達 80% 的 Level 1 常見程式碼 Bug，從來不是萬靈丹。但回到藍綠部署那段留下的三個問題，fibon 給的不是完美解，而是一套跑得起來的答案：裁判交給一個 AI 碰不到的獨立 Updater、健康檢查靠影子大腦的真實煙霧測試、切壞了就用快照回滾到上一次正常狀態。病重的醫生確實沒辦法替自己開刀，但「請另一個健康的醫生趕到 + 出事自動回滾 + 影子測試 SOP」這套工程做法，已足以讓開源後的 fibon 展現出相當程度的「類自我修復能力」。 💡 再想一想 留給工程讀者的深夜思辨題 ： * 數據偏離與程式 Bug 的邊界，在真實維運中模糊得讓人頭痛 ：後台爆出一個 KeyError: 'user_id'，這是前端惡意傳入空數據引發的「純數據異常」（Layer 1 不准修），還是後端序列化漏寫一行相容性程式碼引發的「核心程式 Bug」（Layer 1 判定候選修復）？你的分類器該怎麼精準裁決？ * AI 自我修復時，到底允不允許一次性大改多處檔案 ？若一個 Bug 牽涉 3 個微服務檔案的聯動修改，Agent 能不能一次推播橫跨 3 個檔案的巨大 Patch、要求一次 Approve？還是必須拆成 3 次獨立彈窗？背後的事務鎖複雜度完全不在同一個次元。 * 連環崩潰的因果鏈，AI 該追到哪一邊才允許停下來 ？一個 OOM 的表面原因是某段 SQL 的 N+1 查詢，N+1 之所以發生是因為上週另一個工程師改 Schema 漏了索引，漏索引又是因為產品經理改了一個緊急需求……AI 要追到哪一層因果才被允許按暫停鍵？ * 「在沙盒裡完美修好」的科學指標到底是什麼 ？僅看錯誤日誌在 sandbox 不再噴出來遠遠不夠，因為 AI 很可能用 try catch Exception: pass 把錯誤吞掉、讓程式假裝不報錯。要外掛多重的程式碼覆蓋率與動態性能監控，才能判定它「真的修好了 Bug」而不是「把那個報錯的警報器關掉」？ * 開發沙盒與生產環境的環境落差（Environment Displacement）該如何處理 ？若 Bug 元凶是本機跑 Python 3.12、線上跑 Python 3.11，兩者對同一個標準函式庫的 API 行為不同，AI 在 3.12 的 sandbox 怎麼樣都無法重現出只在 3.11 才爆的 Exception，這種環境錯位下，你精心設計的 Reproduction Harness 就會失靈，該怎麼辦？

實作細節

從願景拉回地面。最後補兩塊前面提過、值得單獨展開的已實作 細節：一條在安全防線內擴充能力的「能力市集」，以及讓大管家在對話中現場長出新資料表的「動態實體」。 ▶ 🔧 實作細節 1：能力市集 —— 在安全防線內擴充 fibon 的另一條路 給工程師 雖然前面為了安全把自我進化的 Kill-Switch 預設關閉，但開源後的 fibon 能力不會因此停滯。旁邊還開了一條同樣能擴充能力、但安全上更溫和的路：能力市集（Marketplace） 。

⚪ 進度說明 ：市集的骨架已經做出來了：前端 MarketplaceView.vue、api/marketplace.ts、後端 MarketplaceRepository.kt 都在 Repo 裡，目前能瀏覽、一鍵安裝個別的 Skill 與 Agent 範本 。但下面講的「把 MCP / Skill / Workflow / 自訂工具打包成單一 .plugin 套件」以及配套的數位簽章、相依稽核，目前還是設計方向、尚未寫成程式碼。 已經能用的部分（Skill 與 Agent 範本市集） ：社群可以把寫好的 Skill 工作說明書、或設定好的 Agent 範本上架，其他人到市集瀏覽、一鍵裝進自己的 fibon。 設計方向（統一的.plugin 套件）：再往前一步的構想，是把零散的 MCP 外接插頭（讓 AI 連上外部工具）、Skill、Workflow 複合流水線、自訂工具腳本，打包成單一壓縮包（.plugin），讓開發者一次分享一整組能力；配套再加上數位簽章驗證（確認來源可信、未被竄改）、語意化版本管理（SemVer）與相依關係稽核，從源頭堵住「供應鏈投毒」，也就是駭客把惡意程式碼藏進看似正常的第三方套件裡散播。這層打包與簽章還沒落地。 不變的底線（外來資源一律走安全閘門） ：不論未來怎麼打包，原則不會變：任何外來的 Skill／套件進門，都得走一遍第 4 章實作細節 2 建立的「Skill 匯入三閘門（Gate 1 靜態掃描 → Gate 2 AI 行為審查 → Gate 3 人類手動批准）」，沒有後門特權通道。這條今天已經套在「上傳 skills.zip 匯入」這條路上；未來市集安裝與 .plugin 也會收斂到同一套閘門。 在架構上，能力市集與 Self-Evolution 是兩條獨立、相輔相成的擴充路徑：市集（事前審查、靜態加入） ：「AI 缺一個讀 Excel 的功能？到市集裝一個過了閘門的 Excel Skill」；Self-Evolution（事中對話、AI 動態改原始碼） ：「AI 發現現有程式碼邊界不夠用，自己在沙盒現場改一行、彈出 Diff，等你 Approve 後熱重啟生效」。兩條並行，讓不同硬體、不同信任程度、不同安全顧慮的用戶都能找到適合的擴充方式。 ▶ 🔧 實作細節 2：Dynamic Schema（動態實體資料表）—— 在日常對話中動態長出全新軟體功能 給工程師 這是目前 AI Agent 圈很少有團隊做的高難度功能：允許用戶在日常白話聊天中，直接請大管家在資料庫裡，動態生成一張全新的資料表（業務實體，Entity）與它的資料結構。 用一個真實情境感受：你讀書時想記錄進度，對大管家打字：「從現在起，我想啟動一個全新功能，幫我追蹤每本書的閱讀進度，記錄：書名、當前讀到第幾頁、我的心得、以及我哪一天開始讀的。」大管家接到後依序執行：建立新資料表 （在系統母表用彈性的 JSON 格式開一套有型別保護的結構：書名、頁數、心得、起讀日）→ 前端自動長出操作介面 （後端感知到母表結構變動後，前端不需任何工程師重寫程式碼或重新發布，會自動依新結構在網頁上渲染出一個帶有「新增／查看／修改／刪除」按鈕的「閱讀進度追蹤面板」）→ 後續資料精準歸位 （隔天你說「我把《天體運行論》讀到第 80 頁了，心得是哥白尼真厲害」，大管家辨識意圖，把這筆資料安全地塞進昨天建好的欄位裡）。

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

這跟市面上多數 Agent 框架有本質差別：多數框架仍是「開發者在後台用程式碼寫死功能 → 用戶在前端使用」的固定模式，而 fibon 實現了「用戶在日常對話中驅動 AI 在背景為自己動態長出全新軟體功能」的軟體 3.0 做法。為防這套自由建表被駭客利用發動 SQL 注入、或用海量垃圾欄位刷爆資料庫，在 dynamic_entity 後台布下硬邊界：動態資料表的欄位型別鎖在 7 種安全型別（text 文字 / number 數字 / date 日期 / select 選單 / textarea 長文字 / boolean 是非 / url 連結） 白名單內，且單一動態實體表最多只允許 20 個欄位（MAX_FIELDS = 20） ，超過就拒絕。用嚴格的程式碼規則，把這套功能限制在安全範圍內。 💡 再想一想 換個角度問你一題：同樣是想要一個新功能，你比較信哪一種來源？ 一個能力要長到你的助理身上，至少有三條路，它們的「信任問題」其實完全不同： * 你自己動手改 ：作者是你，動機最可信，但卡在你的時間與技術，而且人也會寫出 bug。 * 從外部裝一個 skill／MCP 外掛 ：作者是一個你不認識的陌生人，它可能一開始就是惡意的（正是第 1 章那場催生 fibon 的供應鏈攻擊），你甚至不確定它私底下做了什麼。 * 讓 Agent 自己做一個（自我進化） ：作者是你自己的 AI，它沒有惡意、而且全程透明（diff 攤在你眼前），但這個作者並不可靠（會幻覺、會 Goodhart 漂移、會「看起來變快其實變笨」）。

有意思的是：多數人一聽到「AI 改自己」就最害怕。但冷靜想，一個蓄意要害你的第三方外掛，未必比一個沒惡意、只是不夠可靠、而且你看得到它每一行改動的自我進化更安全。前者是「動機有問題」，後者是「能力有問題」，你比較怕哪一種？ fibon 的答案是兩條路都不放它自己過：外掛走第 4 章的匯入三閘門，自我進化走本章的沙盒＋人類批准，最後都收斂到同一句話：不管功能從哪來，沒被人類審過、沒被沙盒框住，就不准生效。但「哪一種來源你更願意信」這題我沒有標準答案，留給你。不過不論你的答案是哪個，都會撞到同一個更底層的問題：你終究得在自己的機器上，跑一段你並不完全信任的程式碼，不管它出自陌生人，還是出自你自己的 AI。那段「不被信任的程式碼」到底怎麼關、怎麼跑而不傷到整台機器，就是下一章沙盒要回答的事。 下一章，接著談與自我進化一脈相承、但在維運上更棘手的主題：沙盒（Sandbox）安全邊界防線 。如果說自我進化解決的是「AI 該如何安全修改 fibon 自己」，那下一章的沙盒解決的是「當外來的陌生人或惡意駭客把一段危險程式碼交給 AI、要它在你的主機上立刻執行時，怎麼在底層建起嚴密的隔離區（DMZ），把危險程式碼關進與外界隔離的環境」。第六章見。 ← 上一章 · 第 4 章 為什麼 LLM 的自信，不能當成證據？ 下一章 · 第 6 章 → 不可信任的程式碼，怎麼安全執行？ ↑ ☾ © 2026 Aaron · fibon design log · 本站採對話 + 設計日誌格式撰寫 意見與質疑歡迎來信： 喜歡這些內容？ 請我喝杯咖啡 ☕