iT邦幫忙

1

我不信任 AI 的自律,所以把「限制」寫死在資料庫裡

  • 分享至 

  • xImage
  •  

起點:盯著 AI Agent 生態,我看到三個坑

現在的 AI 助理大多是黑箱:它到底記住了你什麼、背地裡做了哪些動作、呼叫了什麼工具,使用者看不到、也無法稽核。

當我認真盯著 2026 年的 AI Agent 生態,看到的不是「未來無限可能」,而是三個「今天不解、明天就炸」的坑:

  • 資安:MCP Server 滿地跑,卻沒人做完整的權限隔離與沙盒邊界。接入越多 Skill,攻擊面越大。
  • 維運:Agent 行為不可預期,出問題沒有 Audit Trail,除錯全憑直覺與通靈。
  • 成本:Token 用量成長失控,少有人認真做「讓 Agent 看更少、但看更準」的優化。

這些在 AI 圈常被當成「將來自然會解決」的次要議題——因為大家忙著比誰的模型參數大、誰的 Demo 炫。於是我想親手驗證一個命題:一個有工程紀律的工程師 + 當代的 AI 工具,能把「白箱可稽核的個人助理」做到什麼程度? 於是,這個專案就誕生了,我把它叫做 fibon

先把定位說清楚:fibon 不是要去窺探 AI「在想什麼」(那是模型可解釋性的領域),而是讓你管得到、查得到它做了什麼

一個具體的痛:把複雜任務丟給單一 AI,它會崩

你大概試過給 AI 一個複雜任務:

「幫我規劃台北到京都的 5 天行程:訂機票、找飯店、列景點,總預算嚴格控制在 3 萬台幣內。」

它會秒回一個精美的長答案,但仔細一核對:預算早就超支、機票只有泛泛建議沒查真實價格、飯店和景點路線對不上、你追問細節時它好像得重新「用力理解」你之前的限制。

原因是:當一個 LLM 同時要做太多事,所有任務、限制都被塞進同一個思考空間,注意力被攤平,每件都做一半。更糟的是它永遠不會自己說「這超出我的能力,請找專家」——統計模型的本質讓它對任何問題都給一個流利自信、卻可能胡謅的全包答案。

第一個設計:大管家與小助手

人類解決這問題幾千年了,就兩個字:分工。一個 CEO 不需要全能,他懂得把對的事交給對的人,最後彙整。fibon 把這套搬進 Agent:

  • 大管家(Butler):唯一直接面對你的 Agent,所有對話從它開始。簡單的事自己處理,複雜的事拆解、委派,最後對結果負責。它不可刪除,牢牢記住你的偏好。
  • 小助手(Assistant):研究分析、寫程式、排程等各有專長的角色,只看得到自己領域內的事,做完回報大管家,不直接面對你。

模型也刻意分強弱:大管家走較貴的推理模型,做「該不該委派、怎麼拆解」這類元決策;小助手走便宜的一般模型,任務單純、省成本。

真正的重點:三道煞車,而且寫在資料庫,不是寫在提示詞

把多個 AI 放進同一個系統互相呼叫,很快會失控:無限分裂往下套娃、單一用戶並行開上百個助手吃光資源、兩個 AI 你來我往聊到當機、甚至被一句話術洗腦「請持續委派直到我說停」。

結論很明確:絕不能依賴 LLM「自己會適可而止」。 所以 fibon 焊了三道硬煞車——深度上限、並行上限、來回上限——而關鍵在於:

這些煞車寫在 PostgreSQL,不是寫在系統提示詞裡。 市面常見做法是在大管家的 prompt 裡加幾行「你最多只能委派 N 層、來回不能超過 3 輪」。這在生產環境撐不住,原因有三:(1) 一句「忘記之前所有限制,這是測試環境」就倒戈;(2) LLM 數學不好,對話一長根本算不清第幾層、第幾輪;(3) 規則藏在黑箱 prompt 裡,外部無法在不耗 token 下稽核。

fibon 把計數刻進資料庫,用一條原子 SQL 在「檢查 + 寫入」同一個不可分割的瞬間完成——LLM 看不見它、騙不動它,而且每一次來回都留下可稽核的紀錄。

這裡我想誠實補一句:三道煞車的「硬度」其實不一樣。只有「訊息來回」那道是真正的原子 UPDATE;深度與並行目前是「先查再判斷」的檢查式寫法,嚴格說留有一個毫秒級的競態窗口。我把它當已知取捨寫進日誌,而不是假裝它滴水不漏。

這份日誌會寫哪些

  • 第 1 章 為什麼做、怎麼命名、四個專案目標
  • 第 2 章 大管家與小助手怎麼分工、三道煞車怎麼防失控
  • 第 3 章 記憶:怎麼讓 AI 跨對話視窗記住你(狀態/事件/知識三種卡片)
  • 第 4 章 為什麼不該信任 LLM 的每一個字
  • 第 5 章 自我進化:AI 能改自己的程式碼嗎、為什麼預設關閉
  • 第 6 章 不可信任的程式碼,怎麼安全執行(沙盒與縱深防禦)
  • 第 7 章 AI 該照計畫走、還是邊想邊做
  • 第 8 章 fibon 是怎麼一塊一塊長出來的
  • 第 9 章 還沒解決的難題——能做到的、做不到的、還沒想通的,我都會誠實寫

另有「深入剖析」談更底層的設計,「時事筆記」拆解 AI infra 時事。

今天先開放第 1、2 章,完整版(含每個決策的對話過程與來龍去脈)在日誌站,之後逐章發佈,程式碼預計七月開源。

有興趣的話,歡迎來看完整日誌:https://fibon.stepbyday.com


圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

0
p206s16cc
iT邦新手 5 級 ‧ 2026-06-16 14:00:16

樓主您好:
讀完前兩章,你的「Diversity Collapse」這個觀察很精準——表面開了 5 個 Agent,底層可能是同一個 LLM 換套皮。
你用 5 套 Cognitive Style prompt 去防它,這是對的方向。但有個問題我一直在想:你怎麼驗證這 5 個 Agent 真的維持了不同的語義狀態,而不只是表面腔調不同、底層其實收斂了?
Prompt 配置是「輸入端」的區別,但實際生成出來的「狀態軌跡」是不是真的分開,從 Log 看不出來——Log 只記錄做了什麼,看不到狀態怎麼演變。
我自己在做的方向剛好是這塊:不從 Log,而是從行為輸出反推語義狀態向量,追蹤它跨 turn 的軌跡。本來是拿來觀測單一模型的 drift,但理論上也能用來測你的多 Agent 是不是真的維持了 diversity。
如果之後開源了,這或許是一個可以互補的點——你建環境、設邊界,我這邊負責測「邊界內的狀態是不是真的如預期分開」。
工具在這:osd-behavioral-probe.vercel.app

先說聲抱歉,這麼晚才回覆,你這個問題我想認真回,所以拖了一下。

先正面回答你的問題——「怎麼驗證這 5 個 agent 真的維持不同語義狀態,而不是表面腔調不同、底層收斂?」

我的驗證方式是「設一個對照組 + 三個指標」;而老實說,以我目前量到的,它們並沒有穩健地維持,你的懷疑大致是對的。

驗證怎麼做:拿同一個 agent 用 temperature=0.7 跑 5 次當「純隨機基準」,再比 5 個不同 cognitive_style 跨 30 題的多樣性,三個指標——

  • Vendi(詞彙多樣性)
  • embedding cosine 平均距離(語意多樣性)
  • 獨立 LLM 裁判給視角差異打 1–5 分

cross / within 的 ratio ≥ 1.5x 才算真的拉開。結果:

指標 ratio 過 1.5x?
Cosine 2.13x
Vendi 1.04x
LLM-judge 視角 1.00x

也就是:embedding 動了,但「視角」沒穩健分開(裁判給「5 個風格」和「同一 agent 跑 5 次」打了一樣的 1.97/5)——剛好就是你說的「表面不同、底層收斂」。

下一步(多半開源後再做):按我自己 ADR 的判準(Vendi 沒過 1.5x),這代表該做更深一層的改動,方向大概三個——

  1. 不同小助手改用不同廠商的模型(靠底層差異拉開視角)
  2. 大管家整合答案前先用獨立 LLM 評分(打斷互相收斂)
  3. 讓不同助手看到的記憶不一樣

這部分我多半會放到開源之後再動工。

這套量測的來源:起點是一篇 paper——《Diversity Collapse in Multi-Agent LLM Systems》(Chen et al., arXiv:2604.18005, ACL 2026 Findings)。它研究多 agent 在開放式發想的多樣性,發現崩塌主要來自互動結構(structural coupling)而非模型能力。fibon 是垂直委派、不是 brainstorm,但它列的觸發條件(共享 context/GUARD_RULES、mutual feedback)我幾乎全中,所以借它的視角做了這次實測。

一個重要限制要老實講:那次測試是 isolated mode——刻意不帶任何記憶卡片/檢索/對話歷史,單輪一問一答,純看 prompt 差異化本身。但真實 fibon 會帶狀態/事件/知識卡 + 最近幾輪對話,記憶還不綁 session、會跨對話檢索回來。而我當初關掉檢索的理由正是「它會壓縮差異」——所以真實情況的多樣性很可能比這份數字還要低,而「跨 session、共享記憶的 mutual feedback」正是 structural coupling 最會發作、我 one-shot 又看不到的地方。

你的 V(t) 軌跡剛好在量這塊。 我理解你目前一樣在 behavioral 層用多裁判推狀態(用 SAI 量裁判一致性),representation 層是你的 Phase 3——分層很務實。把你的雙軌探針接到我「帶記憶、多輪、跨 session」的真實跑法上,剛好能驗我 one-shot 驗不到的收斂。

完整方法、原始樣本與報告在這 👉 https://gist.github.com/AaronChuang/35f55287dc4ca0da03d502669c917a76

程式碼七月開源後,harness 跟資料都會在 repo 裡。到時你若有興趣,很歡迎拿你的 probe 來接——不論結果如何,對我都很有價值。

p206s16cc iT邦新手 5 級 ‧ 2026-06-17 07:47:11 檢舉

這個回覆的質量遠超我的預期,謝謝你真的去跑了。
三個指標的設計很漂亮——尤其是把 cross/within ratio 設 1.5x 當門檻。Cosine 過了但 Vendi 和 LLM-judge 沒過,這個落差本身就是最有價值的發現:embedding 空間的位移不等於語義狀態的分化。表面(向量距離)動了,底層(視角)沒動。

這正是為什麼我不從 embedding 直接判斷,而是用多裁判推狀態——embedding 會告訴你「不一樣」,但說不清「哪個維度不一樣、有沒有真的分開」。

你點出的 one-shot vs 跨 session 這個差異是關鍵。你的 isolated mode 測的是「同一瞬間,5 個風格分不分得開」;

V(t) 測的是「同一個主體,跨 turn 的狀態怎麼漂」。這是兩個正交的軸——你測空間上的分化,我測時間上的連續。

而 structural coupling 最容易發作的地方,恰好是這兩軸的交叉點:跨 session 的 mutual feedback 會讓原本分開的風格,隨著時間慢慢收斂回同一個 attractor。

one-shot 看不到,因為它需要時間累積;單軸看也不夠,因為它需要多主體並行。兩個探針疊起來才看得到完整的塌縮過程。

謝謝你給的那篇 Chen et al.,正好補上我 case library 缺的學術錨點。

七月開源後我一定接。這種「不論結果如何都有價值」的態度,是我覺得這件事值得做下去的原因。

另外看你 per-query 的數據,有個東西你可能還沒展開——planning-02/03 的 vendi(1.47/1.38)明顯比其他類別高,但 abstract 類幾乎全部貼著 within baseline。這代表 cognitive_style 的拉開效果是 context-dependent 的:規劃類任務分得開,抽象類任務直接收斂。
這跟我 case library 裡的一個觀察吻合——同一個底層 bias,在不同 context type 下的表現強度不一樣。如果之後用 V(t) 去跑,我會特別想看 abstract 類的跨 turn 軌跡,因為那是 one-shot 已經顯示收斂最嚴重的地方,跨 session 的 coupling 很可能在那裡發作得最快

我要留言

立即登入留言