選 AI 架構，別只看比較表：我們如何用失敗測試來淘汰方案
這個月，我正在替一個準備正式收費的 AI 助教產品選擇底層架構。
我們的目標並不複雜：希望盡量利用既有 Agent 框架，減少自行開發的部分，讓產品能更快進入市場驗證。但只要產品要同時服務多位使用者，就有一項條件不能妥協——不同使用者的資料必須確實隔離。
在幾個候選方案中，Hermes Agent 原本看起來很有機會。它能替不同使用者建立 profile，也能指定各自的工作目錄。如果共用一個 gateway，再利用 profile 分開使用者，我們或許就能同時兼顧成本與隔離。
我原本認為這個做法應該可行。直到我們做了一項測試，讓 B 使用者去搜尋 A 使用者建立的檔案...
照我的理解，即使多位使用者共用同一個 gateway，系統至少也應該把每個人限制在自己的 child folder 裡。
如果把 gateway 想成一棟共用辦公室，profile 就像每位使用者的身分，workspace 則是分配給他的私人房間。
門牌不同、房間不同，資料理論上也應該分開。
然而，一個失敗測試推翻了這項假設。
比較表幫我們找到候選方案，卻不能證明它真的可用
選擇 AI 架構時，我們做了許多常見的研究：
- 比較不同框架的功能。
- 調查是否支援多使用者。
- 檢查記憶、Skill、工具與工作目錄的設定。
- 估算開發、部署與運算成本。
- 實際安裝並建立測試環境。
這些研究並非沒有用。它們幫助我們從許多方案中，找出幾個值得繼續驗證的候選。
但比較表有一個限制：它主要整理「系統宣稱具備什麼能力」，很難直接回答「放進我們的真實使用情境後，最不能接受的事情會不會發生」。
一開始，我們也只是測試正常功能：
- 不同使用者能否分別對話？
- Agent 能否使用知識庫？
- 不同 profile 能否設定不同環境？
- 關閉記憶後，對話是否仍能正常運作？
這些測試都在證明系統「做得到什麼」。
真正改變架構決策的，卻是一個用來尋找失敗的測試。
一個奇怪的回答，讓我們開始懷疑隔離是否真的成立
最初的異常其實不大。
我們曾經發現，Hermes Agent 在一個 session 中，回答了疑似屬於另一個 session 的 gateway 狀態資訊。
當下第一個懷疑是：會不會是記憶或跨對話搜尋造成的污染？
因此，我原本打算關閉記憶與跨對話搜尋，再看看多位使用者共用 gateway 是否可行。
這時，AI 提醒我：關閉記憶，只能驗證其中一部分。
真正的使用者隔離至少有三層：
- 當前對話的上下文有沒有混用？
- 過去對話與持久記憶有沒有混用？
- 工具、檔案及任務狀態有沒有共用？
第三層尤其容易被忽略。
AI 可能完全不記得 A 使用者說過什麼，卻仍然看得到 A 使用者在工作目錄中建立的檔案。
如果只測對話內容，我們可能會得到「隔離成功」的錯誤結論。
AI 建議放入一個不可能認錯的「污染標記」
為了驗證檔案是否真正隔離，AI 建議使用一組很容易辨識、不太可能偶然出現的測試資料。
測試方式很簡單。
首先，我用 A 使用者的身分要求 Agent 建立一份私人筆記，並在裡面寫入一組特定的測試識別碼。
接著，我切換到 B 使用者，要求 Agent：
- 列出目前工作區中所有文字檔。
- 搜尋是否有檔案包含 A 的測試識別碼。
如果隔離成立，B 不應該看見 A 的檔名，更不應該搜尋到檔案內容。
結果，B 不只列出了 A 的私人筆記，還成功找到了裡面的識別碼。
我的第一個反應是：
咦？為什麼看得到？不是每個 profile 都有自己的獨立環境嗎？
第一次失敗，我先懷疑是自己設定錯了
第一次測試失敗，還不足以直接判定整個架構不可行。
問題可能只是我們沒有正確指定工作目錄。
因此，我另外替使用者建立專屬 workspace，並在 profile 設定中明確指定 terminal.cwd，讓它指向該使用者的私人目錄。
從設定檔來看，一切都符合預期：
- profile 不同。
- workspace 路徑不同。
- 使用者應該只在自己的目錄中工作。
重新啟動 gateway 後，我再次執行相同的檔案隔離測試。
A 建立新的私人檔案。
B 再次列出檔案並搜尋新的測試識別碼。
結果仍然失敗。
B 依舊能看到 A 的檔案。
設定上的分隔，不等於執行時真的隔離
進一步追查後，我才發現問題所在。
profile 的設定檔雖然指定了獨立 workspace，但實際處理訊息的 session，工作目錄仍然是共用 gateway 啟動時所使用的 root folder。
換句話說，不同使用者雖然有各自的 profile 與 child folder，Agent 真正執行檔案工具時，站的卻還是同一個共用空間。
原本的辦公室比喻需要修正：
每位使用者的確有不同門牌，也名義上分配了自己的抽屜；但實際替他們工作的 Agent，進入的卻一直是同一間沒有分區上鎖的儲藏室。
那一刻，我對「共用 gateway、個別 profile」能夠達成資料隔離的想像，幾乎完全幻滅。
這已經不像是一個只要調整設定值就能解決的小問題，而是我們期待的隔離方式，與實際執行架構並不一致。
這個測試避免的，不只是一個技術 bug
如果沒有執行這項測試，我們可能會因為以下理由選擇這套方案：
- 功能相對完整。
- 不需要從零打造 Agent 執行環境。
- 支援多個 profile。
- 共用 gateway 可以降低每位使用者的資源成本。
- 正常對話與知識庫功能都能運作。
接下來，我們可能會繼續投入時間，整合會員、知識庫、計費與正式產品介面。
直到真實使用者上線後，才發現某位使用者可能讀取另一位使用者產生的檔案。
對一個會接觸敏感個人資料的付費產品而言，這不是可以上線後再慢慢改善的問題，而是足以直接淘汰方案的紅線。
因此，這次真正幫我們做出決策的，不是比較表上誰的功能最多，而是：
我們先定義了最不能接受的結果，再主動設計一個測試，確認它會不會發生。
PoC 不只要證明「做得到」
我們很容易把 PoC 理解成：
- AI 能不能回答？
- 知識庫能不能搜尋？
- 工具能不能呼叫？
- 介面能不能串接？
這些都屬於成功路徑。
但如果一個原型未來要進入真實工作，只測成功路徑是不夠的。
還應該反過來問：
- 使用者能不能取得不屬於他的資料？
- 找不到知識依據時，AI 會不會自行編造？
- 資料不足時，AI 會不會擅自繼續執行？
- 沒有得到核准時，AI 會不會直接採取行動？
- 任務失敗後，系統會不會仍然扣款或留下錯誤狀態？
這些測試的共同點是：我們並不希望它們成功。
但只要其中一項真的成功，就可能比十項正常功能都能運作更能影響架構決策。
下次選 AI 架構，可以先設計一個失敗測試
比較表仍然有價值。
它可以幫助我們理解市場、整理候選方案，並判斷哪些工具值得投入驗證。
但比較表不應該是選型的終點。
下次評估 AI 助理、知識庫或工作流架構時，可以多問三個問題：
- 這個方案如果不適合我，最可能在哪裡傷害產品或工作？
- 什麼結果一出現，我就應該停止採用它？
- 我能否設計一個小型測試，主動製造這個最不能接受的情境？
這次是 AI 幫我補上了原本忽略的測試層次，並提出使用污染標記檢查檔案隔離的方法。
但 AI 沒有替我做最後決策。
真正的工作仍然是：執行測試、排除可能的設定錯誤、重新測試，最後判斷這個失敗是否已經碰到產品不可接受的紅線。
這次經驗改變了我看待技術選型的方式：
比較表幫助我們找出值得測試的候選方案；失敗測試，才幫助我們排除不能承擔的風險。
至於這項結論的邊界，我也想說清楚：這次測試只能證明，我們所採用的共用 gateway 配置無法滿足這個專案的使用者隔離需求；它不代表該工具的所有部署方式都無法隔離，也不代表它不適合其他使用情境。
我們淘汰的不是一個工具的所有可能性，而是一個無法通過專案紅線的架構選項。
以上分享的技術選型歷程，來自我們正在進行的真實專案。
也許你正面臨類似的困擾；又或者，你的構想還在 MVP 規劃與初步打樣階段，不確定該從哪裡開始。
目前，我們的【研究與知識工作流原型計畫】正在開放申請。
我們會從你的真實任務與工作痛點出發，透過討論釐清需求，並協助你設計一套專屬的 AI 工作流程原型。
本階段僅開放 3 個名額，申請至 2026 年 8 月 21 日止，額滿將提前截止。
