Langflow 社群回報提示快取缺口，秒級時間戳可能阻斷多輪對話歷史重用

Langflow 的 GitHub 社群於 10 月 9 日提出一項與代理成本直接相關的回報：Agent 預設系統提示雖將 {current_date} 標示為「今日日期」，實際注入的卻是包含時、分、秒的 UTC 時間戳。回報者列出的環境為 Langflow 1.12.5 與主分支提交，並提供程式位置及檢查請求的方法；目前證據主要是程式行為分析，尚未附上受控成本或延遲比較。原始回報

問題出在提示的排列順序。依回報所列實作，工具呼叫代理依序組合系統提示、對話歷史、使用者訊息與代理工作區。當下一輪執行的秒數改變，位於歷史之前的系統提示便跟著改變；即使歷史內容完全相同，也無法直接重用包含該時間戳的舊快取前綴。回報另指出，同一次代理執行內的步驟仍共用提示，因此關注點是跨輪對話，而非每次工具呼叫都必然失效。回報與重現步驟

這個機制可由 Anthropic 官方文件交叉核對：Claude 提示快取依工具、系統提示與訊息的順序建立前綴，命中要求對應內容一致；系統層變動會使其後的訊息快取失效。不過，位於變動內容之前、已獨立建立的工具快取仍可能保留，因此不能把這項回報解讀成所有輸入都一定按完整價格計費。Claude 提示快取文件

回報者建議讓 {current_date} 只輸出年月日，並另設可選的時間欄位。工程上的取捨是：日期可讓同一天的系統提示保持穩定，但需要即時時間的任務仍須取得正確資訊。依快取前綴原理，團隊也可評估把易變資訊放到穩定內容之後；這是設計建議，仍須確認框架與模型 API 是否支援所需排列。

對使用 Langflow 建立長對話代理的團隊，下一步應先比對連續請求的實際系統提示，再觀察快取讀取 token 與延遲。驗證時須控制模型、提示長度、快取有效期和工具設定，避免把其他失效原因歸給時間戳。截至查核，尚無已驗證的正式修補與跨供應商量測，實際節省幅度仍待確認。