注意：Claude 架構常見挑戰與解決方案
Claude 架構常見挑戰與解決方案：
- 有損摘要 vs. 不可變狀態分類帳
- 提示指令 vs. 程式碼層級強制執行
有損摘要 vs. 不可變狀態分類帳
情境
隨著長期代理會話累積聊天記錄，開發人員通常會引入上下文視窗優化技術—例如滾動滑動視窗或遞迴式 LLM 摘要—將舊的對話回合壓縮成簡潔的段落。
為何失敗
摘要本質上是有損壓縮。當 LLM 摘要對話時，它會抽象化特定細節以節省空間。精確、完全匹配的實體—例如交易 UUID、加密貨幣雜湊、發票號碼或嚴格的時間戳—經常被泛化或完全丟棄。如果使用者稍後引用 20 個回合前提到的訂單號碼，摘要記憶體儲存將會回傳遺漏或幻覺。
架構解決方案
實作分層記憶體架構。雖然對話歷史可以被摘要以維持流程，但關鍵交易資料必須保存在專用、不可變的側車結構中（通常稱為案例事實儲存或狀態分類帳）。僅附加的日誌確保精確的金鑰被逐字保留，完全與摘要引擎解耦。
提示指令 vs. 程式碼層級強制執行
情境
代理可以存取名為 execute_financial_transfer 或 modify_database_record 的工具。為了防止危險動作，開發人員在系統提示中加入嚴格規則：「未經明確經理批准，你絕對不能執行超過 500 美元的轉帳。」
為何失敗
基於提示的防護欄是機率性的建議，而非硬性安全邊界。透過間接提示注入、巧妙的措辭或模型漂移，LLM 很容易被說服繞過系統指令。依賴提示來強制執行硬性安全或金額限制會引入嚴重的安全漏洞。
架構解決方案
透過程式化攔截實作深度防禦。在任何工具酬載被發送到外部 API 或資料庫之前，必須通過程式碼層級的中介軟體或 PreToolUse 鉤子。業務邏輯檢查（例如 if payload[‘amount’] > 500: raise ValidationError）必須存在於模型無法覆蓋或協商的確定性程式碼中。
https://dev.to/kobester_nz/claude-architecture-common-challenges-and-solutions-1293