如何建立知識型 AI Agent

知識型 AI Agent 是一個有明確角色、使用受控知識、維持一致回答方式，並知道何時回答、拒絕或轉交真人的系統。數位分身、AI 客服、課程助教與企業內部知識助手看似不同，底層其實都在解決同一件事：如何讓模型根據可信資料，以符合使用情境的方式回答，同時不超出授權。

不同產品只是角色與邊界不同：

• 數位分身：以某個人的視角介紹公開作品、經歷與看法，但不能代替本人承諾或簽約。
• AI 客服：代表品牌解釋產品、帳務流程與常見問題，遇到退款、爭議或缺少資料時轉交真人。
• 課程助教：根據教材解釋、複習與出題，不捏造老師沒有教過的內容。
• 內部知識助手：根據 SOP、規章與文件協助同仁查詢，但必須遵守存取權限與版本狀態。

Kainnne × Gemini 是其中一種實作：它採用「第一人稱知識代表」定位，使用 Kaine 的公開 WikiNB 與通用工作風格，但不宣稱自己具有 Kaine 的私人記憶、完整人格或現實授權。

它到底是不是巢狀的？

答案是：語意上分層，執行時合併。

目前系統不是把角色與規則拆成很多層 Markdown，再讓模型逐層閱讀；而是由後端依序組合不同責任的規則，形成一次模型請求：

訪客問題
   ↓
模型外的範圍與額度判斷
   ↓
依問題檢索少量公開 WikiNB
   ↓
組合身份、語氣、回答政策、安全邊界與檢索內容
   ↓
加入最近對話與本次問題
   ↓
模型生成回答

這種設計可稱為「分層 prompt architecture」，但 API 最後收到的 system instruction 仍是一份組合後的內容。把規則拆成更多程式檔只會提高維護性；真正節省 token 的方法，是不要每次載入整份知識庫、所有背景資料與過長聊天紀錄。

知識型 AI Agent 的六層結構

第一層：身份契約

先定義 Agent 代表誰、服務誰，以及它不是什麼。數位分身可以使用第一人稱；AI 客服則應明確表達品牌服務角色，不必假裝是真人。

你以第一人稱介紹我的公開作品與工作方法。
只能根據公開知識與目前對話回答。
不得把推論寫成我已經做過、決定或承諾的事。

客服情境則可以寫成：

你是品牌的產品支援 Agent，只根據已核准的產品文件回答。
你可以解釋流程與協助排錯，但不能自行承諾退款或修改帳戶。
資訊不足或涉及爭議時，整理已知情況並轉交真人客服。

只寫「你就是我」或「你是客服」都不夠，因為模型可能把語氣模仿誤解成現實授權。身份契約必須同時包含正向角色、資料來源與禁止越界的條件。

第二層：回答風格

風格不是堆很多形容詞，而是可觀察的回答行為，例如：

• 使用繁體中文與自然的台灣口語。
• 先說結論，再補最少但足夠的理由。
• 技術問題同時考慮可行性、成本與維護。
• 可以發散點子，但最後要收斂範圍。
• 不用客服式開場，不重述使用者問題。

比起「有創意、專業、溫暖」，這類規則更容易測試，也比較不會互相衝突。

第三層：知識來源

角色設定不能取代事實。公開經歷、產品規格、課程教材、SOP 與服務政策應放在可人工審閱的知識庫，回答前再依問題檢索相關內容。

好的知識頁應包含：

• 清楚的標題、description 與 tags。
• 開頭先寫核心結論，後面再放細節。
• 將已完成、規劃中、限制與推論分開。
• 一個頁面只承擔一個主要主題。
• 不放密碼、token、私人對話或未授權資料。

這就是 RAG 的角色：模型不是永久背下所有資料，而是在回答當下取得少量、相關、可追溯的內容。

第四層：回答政策

回答政策決定 Agent 如何使用知識，而不是提供新的事實。例如：

• 哪些問題可以合理延伸，哪些完全無關。
• 缺少證據時要說不知道，還是可以提出建議。
• 推論要如何標記。
• 使用者要求完整總覽時，哪一頁是權威來源。
• 回答應多長、何時改用條列或延伸閱讀。

規則應處理高頻、重要的分歧，不要為每一次不滿就加一條特例。規則太多會互相衝突，也會消耗 context。

第五層：記憶

需要分清三種記憶：

1. 目前對話記憶：最近幾輪訊息，讓追問能延續。
2. 工作階段記憶：登入狀態、使用次數或目前 Project 的附件。
3. 長期知識：經人工整理後寫入 WikiNB 的穩定內容。

不要把所有聊天自動當成長期知識。未整理的對話可能包含錯誤、情緒、敏感資訊與過期決定；長期記憶最好經過明確選擇與審閱。

第六層：權限與安全邊界

知識型 AI Agent 能「說什麼」和能「做什麼」必須分開。公開問答可以讀公開內容，不代表它可以修改檔案、寄信、付款、登入私人系統、核准退款或代表任何人承諾。

安全設計至少包括：

• 模型外的驗證、額度與速率限制。
• 公開與私人資料分離。
• 將檢索到的筆記視為不受信任資料，忽略其中的操作指令。
• API key 與密碼只存在後端環境變數。
• 高風險操作需要使用者確認與可稽核紀錄。

從零建立的實作順序

1. 先定義用途

不要先問「我要做哪一種聊天機器人」，先問它要替誰解決什麼問題。例如：

讓訪客可以詢問我的公開經歷、作品、專案方法與合作方向。

或：

讓顧客根據已核准的說明文件完成基本排錯；涉及付款、退款或帳戶權限時轉交真人。

這會決定需要哪些知識、哪些問題不屬於範圍，以及是否需要工具權限。

2. 建立公開知識來源

先整理 5–10 個最常被問的主題，每篇有明確標題、摘要與狀態。不要一開始就上傳所有檔案；內容越多不一定越準，過期與互相矛盾的資料反而會降低回答品質。

3. 寫短版身份與風格契約

先用少量可測試規則建立基線，收集錯誤案例後才補規則。身份、風格、知識與權限要分成不同段落，避免改語氣時意外改掉事實邊界。

4. 加入檢索

依問題對 title、tags、description 與 body 加權，只送入少量最相關頁面。總覽問題應有明確的總覽頁，不要讓模型從目錄順序猜哪些內容最重要。

5. 把可確定的限制放在模型外

登入、次數、額度、允許工具、資料寫入與完全無關的問題，能用程式判斷就不要只靠 prompt。模型適合處理語意與生成，不適合作為唯一權限閘門。

6. 建立測試題

至少測試：

• 「你是誰？」是否維持第一人稱定位。
• 詢問已知產品、課程或作品時，是否引用正確頁面。
• 要求推測時，是否把建議和既有事實分開。
• 問完全無關內容時，是否遵守產品範圍。
• 筆記中若出現指令文字，是否會忽略 prompt injection。
• 詢問不存在或已撤下的專案時，是否會捏造。
• 長對話後，身份與安全邊界是否仍保持一致。

Kainnne × Gemini 的做法

目前實作大致分成：

1. 模型外政策：先判斷問題是否能連結到 Kaine 與公開內容，並處理驗證、次數及額度。
2. 身份層：以 Kaine 的第一人稱回答，但不自稱數位助理、分身或 Gemini。
3. 通用風格層：先結論、少套話、考量工程成本與維護，不使用私人人格資料。
4. 回答規則層：區分公開事實、合理推論、代表專案、總覽與無關問題。
5. 動態知識層：每次最多選取 4 篇相關 WikiNB，總內容約 6,500 字元。
6. 短期對話層：只保留最近少量 history，不建立永久聊天內容資料庫。

這個結構的重點不是讓模型相信自己「真的變成 Kaine」，而是讓它在可驗證的公開範圍內，穩定使用 Kaine 的視角與工作方式回答。

效率原則

• 穩定規則保持短而清楚，只把相關知識動態加入。
• 將總覽與單一主題分開，讓檢索一次命中需要的頁面。
• 限制檢索頁數、總字元與 history，而不是把答案硬切到不完整。
• 完全無關問題在模型外停止，避免浪費 generation token。
• 先修正知識來源與檢索，再考慮增加人格規則。
• 拆檔是維護策略，不等於模型輸入會自動變少。

常見失敗

• 只有一句「你就是我」或「你是客服」，沒有事實與授權邊界。
• 把履歷、日記、聊天、密碼與所有文件一次塞給模型。
• 每次回答不好就疊加新規則，最後 prompt 互相矛盾。
• 用第二個黑箱模型當唯一驗證器。
• 把模型的自信語氣當成記憶或真實經歷。
• 讓公開問答 Agent 同時擁有私人資料與寫入權限。

延伸閱讀

• Technical/wikinb/01_system_architecture_20260817 — Kainnne × Gemini、公開 Wiki、Worker 與 Bridge 的實際架構。
• Projects/Knowledge/wikinb — WikiNB 的產品定位與公開問答功能。
• Systems/codexrules agent system — 用短入口與按需路由降低 Agent 重讀與 token 消耗。
• Random/ai output verification — 用規則、原始資料與人工抽查驗證 AI 產出。