醫療 AI Agent 記憶機制（下）：強化思考鏈與工具調用策略

本文為系列文章之「下集」。若您尚未閱讀上集，建議先參考：醫療 AI Agent 記憶機制（上）：在地化優先與合規挑戰

Key Takeaways

• 思考鏈（CoT）不只是概念：單一/多/樹狀/圖狀四種模式對應不同的醫療推理場景，越複雜的模式計算成本越高，也越難解釋
• Tool Calling 的資安不只是「加密」——具體是 TLS 1.3 傳輸、HSM 管理憑證、稽核日誌三層保護，病患資料不離開本地網路邊界
• 四層 Agent 架構的設計原則：資訊在 Agent 間只傳最小必要量，原始病患資料不在 Agent 間流通
• 反思機制的落地形式：臨床人員的審核修改動作，直接成為 SLM as Judge 的訓練訊號

思考鏈在醫療場景裡長什麼樣

上集討論了 AI Agent 的記憶機制——它決定 Agent「記得什麼」。這集的主題是推理機制——Agent「怎麼想」。思考鏈（Chain-of-Thought，CoT）是其中最核心的概念，但光靠定義說明不夠，醫療場景的 CoT 需要用具體情境來理解。

單一思考鏈（Single-Thought Chain）

最基本的線性推理：Agent 一步一步依序思考，前一步的輸出是下一步的輸入。

醫療場景範例：一位患者問「我可以吃香蕉嗎？」

Step 1：確認患者身分 → 查詢個案記錄
Step 2：讀取相關資料 → 腎功能 eGFR 42（輕中度下降）、鉀離子 5.1 mEq/L（偏高）
Step 3：查詢食物資料庫 → 香蕉含鉀量：中型一根約 422 mg
Step 4：對照臨床標準 → 腎病患者每日鉀攝取建議上限 2,000 mg，但血鉀偏高時需更嚴格控制
Step 5：生成回應 → 「以您目前的腎功能和血鉀數值，建議暫時避免香蕉，可改以蘋果或西瓜替代，請與您的營養師確認。」

這條推理鏈是線性的、步驟清楚的、可以逐步驗證的。在醫療合規層面，這種可解釋性是必要條件。

限制：單一問題可以，但當問題需要平行考量多個維度時，線性思考容易漏掉某條線索。

多思考鏈（Multi-Thought Chain）

同時啟動多條獨立的推理路徑，最後整合。

醫療場景範例：患者回報「最近飯後兩小時很容易餓，而且最近血壓有點高」

推理路徑 A（血糖管控角度）：
  - 飯後兩小時易餓 → 可能是血糖波動（餐後高峰後快速下降）
  - 查詢過去兩週飲食記錄 → 精製碳水比例偏高
  - 推論：血糖控制需要調整，建議增加蛋白質與膳食纖維比例

推理路徑 B（心血管角度）：
  - 血壓偏高 + 飲食記錄 → 鈉攝取量過去一週平均 3,200 mg/天，超過建議的 2,300 mg
  - 查詢用藥記錄 → 目前無服用降壓藥
  - 推論：飲食減鈉是第一步，若持續超過建議值兩週應告知主責醫師

整合：
  - 兩條路徑的建議有重疊（飲食調整），也有各自的追蹤指標
  - 整合輸出：飲食建議 + 血壓追蹤計畫 + 需要上報給醫師的條件

比單一鏈更全面，但整合步驟本身需要額外的邏輯確保兩條路徑不衝突。

樹狀思考（Tree-of-Thoughts）

把推理展開成樹狀結構，在每個節點評估多個可能的下一步，選擇最合理的分支繼續。

醫療場景適用：需要多步驟規劃的複雜案例，例如為一位合併有糖尿病、輕度腎病、高血壓的患者擬定為期四週的飲食照護方案。

這類問題的特點是：每個飲食建議都可能有多個合理選項，而不同選項在長期效果上有顯著差異。樹狀思考讓 Agent 在生成計畫時，不只給出第一個想到的方案，而是先探索幾個分支方向，在每個節點評估可行性，再選定最適路徑繼續展開。

在醫療應用上的重要限制：樹狀思考的計算成本高，更關鍵的是，每個節點的評估標準必須是明確的、可驗證的——在醫療場景，「哪個分支比較好」不能由 AI 自行定義，必須對應到臨床指引或由人類審核。否則就變成了黑盒子推理，醫療場域不能接受。

圖狀思考（Graph-of-Thoughts）

比樹狀更自由——思考節點之間可以任意連接，某個節點的輸出可以流向多個後續節點，不同分支的結論也可以匯流、互相參照。

在 DietMate 架構中的應用：圖狀思考的邏輯已經融入我們的 PICO-Graph RAG 引擎設計。知識圖譜本身就是圖狀結構，讓 Agent 在查詢「糖尿病患者的蛋白質攝取建議」時，可以同時拉到「腎功能分期」「KDOQI 指引」「台灣健保給付的蛋白質補充品」這幾個相關節點，而不是線性查詢。這種「跳躍式關聯」對於複雜的醫學知識網絡，比線性搜尋效果好得多。

工具調用：Agent 如何與外部系統互動

思考的結果需要轉化成行動。Tool Calling 讓 Agent 不只是語言模型，而是能真正操作外部系統的執行者。

在 DietMate 的架構中，Agent 能調用的工具包括：

資安設計：「嚴格加密」是指什麼

原文說「每個工具的 API 串接與資料傳輸都經過嚴格加密」，這句話太抽象。具體來說：

傳輸層：所有工具調用的網路傳輸使用 TLS 1.3，確保資料在傳輸過程中無法被截取或竄改。

憑證管理：每個工具 API 的存取金鑰（API Key）以 HSM（硬體安全模組）管理，不以明文存於程式碼、設定檔或環境變數中。即便程式碼被外部取得，也無法直接取得存取憑證。

最小權限原則：每個 Agent 只有存取它需要的工具的權限。資料擷取 Agent 能讀取病歷，但不能寫入；通知 Agent 能發送訊息，但沒有病歷讀取權限。

稽核日誌：每次工具調用記錄包含：呼叫的 Agent 身分、呼叫時間戳、呼叫的工具與端點、輸入參數摘要（去識別化後）、回傳結果摘要、呼叫耗時。這條日誌不可修改，儲存於本地稽核資料庫。

資料不出境：所有工具都在本地網路邊界內運行，病患資料的查詢與回傳不經過境外 API。這是技術架構的硬性限制，不是選項。

四層 Agent 架構：一個問題如何在系統裡流轉

用一個完整的問題流程說明四層 Agent 如何協作。

情境：一位 68 歲糖尿病合併輕度腎病患者，在 LINE Bot 輸入：「醫師說我要控制蛋白質，但我又怕肌肉流失，我每天應該吃多少蛋白質？」

用戶輸入（LINE Bot）
  ↓
【Layer 1：資料擷取 Agent】
  工作：收到問題後，觸發工具調用
  - 調用醫療 CRM → 讀取患者基本資料（年齡、體重、身高）、最近的腎功能檢驗值（eGFR、尿蛋白）、血糖控制指標（HbA1c）
  - 調用 ICD-10 → 確認診斷分類（糖尿病腎病 N08.3）及對應的臨床照護標準
  輸出：「患者摘要 + 相關檢驗值 + 適用臨床分類」（傳給 Layer 2）
  ※ 原始病歷資料不繼續往下流，只傳結構化摘要
  ↓
【Layer 2：PICO-Graph RAG Agent】
  工作：用患者摘要查詢知識圖譜
  - 構建 PICO 查詢：P=糖尿病腎病 CKD Stage 3 老年患者，I=蛋白質限制飲食，C=一般蛋白質攝取，O=腎功能保護 vs 肌肉量維持
  - 在 PICO-Graph 中進行語義檢索，找到相關節點：KDOQI 2023 更新版指引、台灣腎臟醫學會建議、肌少症預防相關文獻
  - 整理出：「CKD Stage 3 患者建議蛋白質攝取 0.6–0.8 g/kg/天，但需考量營養狀態；如有肌少症風險，應與腎臟科醫師討論個別化目標」
  輸出：「以證據為基礎的參考框架 + 文獻來源」（傳給 Layer 3）
  ↓
【Layer 3：營養建議 Agent（MedGemma 本地部署）】
  工作：整合患者資料與文獻框架，生成個人化建議
  - 輸入：患者體重 62 kg、eGFR 42、目前肌肉量（若有 DEXA 資料）
  - 計算：建議蛋白質範圍 0.6×62=37.2 g/天 至 0.8×62=49.6 g/天
  - 台灣在地化：建議可選擇的蛋白質來源（雞胸肉、豆腐、蛋白），換算成日常份量
  - 生成初步建議文本，包含每日蛋白質目標範圍、建議食物選項、追蹤指標
  輸出：「個人化建議草稿」（傳給 Layer 4）
  ↓
【Layer 4：SLM as Judge Agent（本地部署小型語言模型）】
  工作：合規性與安全性審查
  - 檢查建議是否符合台灣腎臟醫學會的現行指引
  - 確認建議沒有超出衛教範疇（沒有「診斷」或「開立醫囑」的語言）
  - 確認建議包含「請與您的醫師或營養師確認」的免責聲明
  - 若發現問題：退回 Layer 3 修正 + 記錄問題類型
  - 若通過審查：加蓋合規標記，推送至營養師審核佇列
  ↓
【營養師審核】
  - 看到完整流程摘要（各層輸出 + 文獻來源）
  - 可以一鍵確認或直接修改
  - 修改後發送給患者
  - 修改記錄反饋回系統，成為 SLM as Judge 的訓練資料

整個流程中，原始病患資料（完整病歷）只在 Layer 1 讀取，向下傳遞的是結構化摘要。這不只是隱私設計，也確保後面的 Agent 不會因為看到不相關的雜訊而跑偏。

反思機制：錯誤如何變成改進

「反思」在 Agent 架構裡的落地形式，比概念層面複雜得多。在 DietMate 的設計裡，反思機制有兩個層次：

即時反思：Agent 在生成輸出後，先自我評估「這個回應是否回答了問題、是否存在邏輯矛盾、是否有超出我的能力範疇的部分」。如果自評發現問題，會先嘗試修正，再傳到下一層。這需要每個 Agent 有明確的「自我評估標準」——不是泛化的好壞判斷，而是具體的清單（例如：建議有沒有包含數值依據、有沒有引用來源、有沒有明確的行動項目）。

長期學習：營養師審核時所做的每一個修改動作，都是一個隱性的「這裡有問題」訊號。系統把這些修改記錄（修改了什麼、改成什麼）處理成訓練資料，持續優化 SLM as Judge 的審查標準和 PICO-Graph RAG 的查詢策略。

這個正向循環的速度取決於審核量。使用量越多、審核記錄越豐富，模型改進的速度越快。這也是為什麼我們說「醫療 AI 不是部署完就結束的產品，而是需要持續與臨床實踐磨合的系統」。

從架構說回決策

這一上一下兩篇文章，試圖說清楚一件事：醫療 AI Agent 的技術選擇，每一個都有它的臨床與合規理由，不是純粹的工程最優化。

CoT 模式選單一還是多路徑？看問題的複雜度和對可解釋性的要求。Tool Calling 怎麼做加密？不是「加密就好」，而是要能回答「如果系統被審計，能提供完整的資料流軌跡嗎？」。四層 Agent 為什麼這樣分工？因為原始病患資料最小流通範圍是法律要求，不是架構喜好。

技術文件寫得再漂亮，最終衡量標準只有一個：當一位患者根據 AI 建議做了決定，事後發生問題，系統能不能清楚說明「AI 為什麼這樣建議、哪個人在哪個步驟確認過、修改了什麼」。能回答這個問題的系統，才是醫療場景可以真正使用的系統。

上集記憶機制的技術背景，請參考：醫療 AI Agent 記憶機制（上）：在地化優先與合規挑戰