上面的建築建議很好。但其中沒有一個完全涵蓋的是：你要如何實際驗證修復是否有效？
LLM 工具選擇是不確定的。它可能在 10 次測試運行中看起來正確，但在生產環境中仍可能出現偏差。以下幾點會有幫助：
**1. 記錄實際調用的工具**
在 AI Agent 後新增一個 Set 節點，並擷取 `{{ $json.intermediateSteps }}` — 這會揭露代理程式進行的每個工具呼叫，以及模型對每個呼叫的推理過程。沒有這個，你就只是在猜測你的描述變更是否有效。
**2. 在發佈前用對抗性提示進行測試**
進行任何架構變更後，執行一批你 *知道* 應該會觸及向量存儲的測試查詢 — 包括那些看起來像需要即時資料的查詢。檢查每個的工具日誌。這是在 1-10 的失敗情況影響真實用戶之前捕捉它的唯一方法。
**3. 預先檢索方法的一個邊界情況**
@Anshul_Namdev 的建議（預先檢索，將結果作為上下文傳遞）是最可靠的。但要留意這點：如果向量存儲返回 *空* 結果（一個知識庫外的問題），代理程式仍然會收到一個上下文區塊 — 只是一個空的。你的系統提示需要明確處理這個情況：*「如果沒有檢索到上下文，請使用 HTTP 請求工具。」* 否則代理程式可能會產生幻覺而不是正確地回退。
代理工作流程中的工具選擇不一致是一個持續的維護問題，而不是一次性的修復 — 我在這裡寫過相關的隱藏失敗模式：The silent failure: when your n8n workflow succeeds but does nothing
如果這是在驅動面向生產的代理程式，且不一致情況一直重複出現，這通常表示整體架構需要更仔細的檢查。很樂意幫助你深入思考這個問題。