Difyコミュニティ、エージェントの履歴再生におけるキャッシュの問題を報告　ランダムなツール呼び出しIDが推論コストを押し上げる可能性

Difyのツール型エージェントで、デプロイチームが確認すべきキャッシュ上の問題が報告された。10月9日に公開されたコミュニティ報告によると、過去のツール呼び出しの内容が変わっていなくても、システムは次のターンで履歴を再構築する際に新しいランダムな識別子を生成する。報告された環境はソースからセルフホストしたDify 1.17.1で、問題はFunction Callingエージェントの履歴組み立て処理に焦点を当てている。問題報告

報告では、organize_agent_historyが問題箇所として挙げられている。この処理は過去のツール名を順に処理し、uuid.uuid4()でtool_call_idを生成して、ツール呼び出しとその結果の両方に同じIDを割り当てる。この方法なら同一ターン内の対応関係は保てるが、履歴メッセージを再生するたびにフィールドの値が変わる。報告者が示した確認方法は、エージェントにツールを使わせてから会話を続け、送信された2ターン分のリクエストを比較し、同じ過去の呼び出しのIDが変化しているかを確認することだ。再現手順とコード上の位置

技術的なリスクは、プロンプトキャッシュがプレフィックスを照合する仕組みにある。Anthropicのドキュメントによると、キャッシュの対象にはツール定義、システムプロンプト、メッセージが含まれる。キャッシュブレークポイントより前の内容が変わると、プレフィックスのハッシュも変わる。そのため、変動するIDが実際のモデルリクエストに含まれる場合、その呼び出しを含む履歴プレフィックスが再利用されなくなる可能性がある。さらに前にある固定部分が引き続きキャッシュにヒットするかは、ブレークポイントの設定による。この推論から、すべてのプロバイダーで請求額が増えると直接結論づけることはできない。プロンプトキャッシュの仕組み

報告では、履歴レコードの主キー、ツールのインデックス、ツール名から安定したUUIDを導出し、ターンをまたいだ一貫性と同一ターン内の一意性を両立させる案が提案されている。確認時点でこのIssueは未解決のままだ。ページ上の技術的な返信は自動化ボットによるもので、メンテナーの確認とはみなせない。また、キャッシュヒット率やコストについて、条件を管理した測定結果も示されていない。修正案と議論

エンジニアリングチームはまず、連続するターンのリクエストを保存し、差分がIDだけに起因するかを確認したうえで、サービス側のキャッシュ読み取りトークン数とレイテンシを照合できる。今後は、上流で安定IDが採用されるか、ツール結果との対応関係が検証を通過するか、プロンプト組み立て時のほかのフィールドも変動するかを確認するとよい。修正による実際の効果を判断するには、こうした証拠が必要だ。