langchain-fireworks 1.6.3 封裝歷史錯誤參數，修補代理對話續接

LangChain 於 9 月 25 日發布 langchain-fireworks 1.6.3，修補代理帶著錯誤工具呼叫繼續對話時，歷史訊息可能遭 Fireworks 拒收的問題。GitHub 發布說明已列入修正，PyPI 也提供同日上傳的套件，使用者可透過正式版本取得更新。[發布說明](https://github.com/langchain-ai/langchain/releases/tag/langchain-fireworks==1.6.3)、[PyPI](https://pypi.org/project/langchain-fireworks/)

問題出現在工具執行後的回傳流程。Fireworks 官方範例會把模型原先的工具呼叫，以及帶有對應識別碼的工具結果，一起加入下一次請求。因此，即使應用程式已捕捉參數解析錯誤，歷史中仍可能留有不合規內容。維護者指出，畸形或非物件的工具參數 JSON，會讓下一輪請求遭拒，阻礙代理繼續處理錯誤。[工具呼叫文件](https://docs.fireworks.ai/guides/function-calling)、[修正說明](https://github.com/langchain-ai/langchain/pull/40818)

新版在序列化歷史訊息時，把這類參數放進名為 `__invalid_tool_call_arguments` 的 JSON 物件欄位，保留原始內容、呼叫識別碼及工具結果配對。處理範圍包含已解析與原始形式的工具呼叫歷史；有效的物件字串則原樣傳送，也不修改原本的訊息物件。[合併提案](https://github.com/langchain-ai/langchain/pull/40818)

從這個設計可推知，直接受益的是會把工具錯誤送回模型、要求重新嘗試的代理流程。封裝後，錯誤內容仍可作為診斷線索，應用程式也能保留呼叫與結果的關係。維護者明確說明，這個步驟不會猜測正確參數，也不會執行所謂修好的參數；它處理的是歷史資料的傳輸格式。[設計說明](https://github.com/langchain-ai/langchain/pull/40818)

部署時仍須區分「請求能送出」與「任務能恢復」：模型下一輪是否產生正確呼叫，取決於模型、工具描述與錯誤回饋。公開發布說明沒有提供恢復成功率或端到端延遲測試，不能據此量化可靠度增益。

工程團隊接下來應以既有失敗紀錄回歸測試，涵蓋截斷的參數文字、合法但非物件的 JSON，以及多個工具結果的配對。若系統另有歷史清理或重試邏輯，也應檢查封裝後內容如何進入日誌與後續提示。驗證時除了記錄 API 是否接受請求，也要觀察下一輪輸出的工具名稱、參數型別與必填欄位，才能確認代理確實恢復到可執行狀態。