なぜホームAIエージェントはサービスの再起動後に完了したアクションを忘れるのか？

ホームAIエージェントは、計画、ツールの結果、完了マーカーが揮発性のプロセスメモリにしか存在しない場合、再起動後に完了したアクションを忘れてしまいます。

エージェントはファイルを更新したり、イベントを作成したり、コンテナを再起動したり、バッチの一部を完了したりしても、サービスが再デプロイされたりクラッシュしたりすると、その情報を失うことがあります。外部の副作用は残っていても、モデルとの会話、ループカウンター、保留中の計画、ツール結果オブジェクトは消えてしまいます。起動後、エージェントは作業を繰り返したり、何も起きていないと思い込んだりする可能性があります。確実に復旧するには、意図、ツール呼び出し、観測可能な結果、次に残っているステップを結び付ける境界で実行状態を保存する必要があります。

会話履歴は永続的なワークフロー状態ではない

チャットの記録にはユーザーの依頼やエージェントの説明が含まれていても、どの副作用が確定したか、どのレコードがスキップされたか、どの分岐から再開すべきかまでは記録されていない場合があります。

Augment Codeの永続的なワークフロー状態に関するガイドでは、長時間実行される処理を単一のプロセスや同期リクエストから分離しています。

エージェントには、タスクID、現在のステップ、完了した操作、ツール結果のハッシュ、保留中の承認、再試行回数などの構造化された状態が必要です。再起動後に自然言語のチャットからその状態を再生成するのは曖昧です。

完了したツール呼び出しには永続的なコミット境界が必要

エージェントがローカルの完了マーカーを書き込む前に、ツールの処理が外部で成功することがあります。その間に再起動すると、アクションは実行済みなのに、エージェントはそれを認識できなくなります。

Zylosは、復旧を続行する前に完了した作業を保持する永続的な実行境界について解説しています。

信頼できる境界では、操作IDと結果を永続ストレージに記録するか、副作用と完了レコードを同時にコミットできる単一のトランザクションサービスを使用します。

アトミックなコミットが不可能な場合、ツールは状態照会機能を提供し、再起動したエージェントが不確実な結果を照合できるようにする必要があります。

スナップショットだけでは安全な実行を再構築できない場合がある

モデルのメッセージやシリアライズしたグラフ状態を保存すると、ある時点でエージェントが何を信じていたかは記録できます。しかし、リプレイ中に外部呼び出しが重複しないことを自動的に保証するわけではありません。

Diagridは、アプリケーションのチェックポイントと、再試行、イベント履歴、副作用の完了を管理するランタイムを区別しています。

復旧設計では、どのコードが決定論的か、どのツール呼び出しをリプレイできるか、どの結果を再実行せず履歴から読み取るかを定義する必要があります。

そうしなければ、正しいチェックポイントから再開しても、メッセージの重複送信、ファイル移動の繰り返し、デバイスへのコマンドの二重実行につながる可能性があります。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

安定した実行IDとステップIDで、誤って新しいタスクを開始するのを防ぐ

再起動後に新しい会話IDや実行IDを生成すると、同じユーザーの目的が新しいタスクに見えてしまうことがあります。その結果、エージェントは以前の状態を検索するためのキーを失います。

Inference.shは、永続的な実行IDによって、エージェントが直近の完了済みチェックポイントから再開できる仕組みを説明しています。

ワークフローIDはコンテナの外部に永続化し、ユーザー、タスク、データ範囲、認可情報に関連付けます。別のワーカーがリクエストを受け取っただけで新しい論理実行が作られないよう、サービスディスカバリとロードバランシングを設計する必要があります。

完了済みのステップは再推論せずに再利用する

以前のモデル呼び出しを再実行すると、異なる計画、異なるツール引数、またはどの作業が完了しているかについて別の解釈が生成される可能性があります。

Pydanticのランタイムに関する記事では、完了済みのチェックポイントは完了済みのまま保持される一方、復旧時には失敗した境界だけを再実行すると説明しています。

これによりトークンコストを削減でき、再起動したエージェントがすでに変更された家庭内システムに対して別の経路を勝手に作り出すのを防げます。

保存する結果には、ツールの出力が現在の対象状態に対応していることを検証するために十分な証拠を含める必要があります。

冪等性と照合で、重複した副作用から復旧を守る

永続状態が外部システムに対して1ステップ遅れている可能性は依然としてあります。操作ID、冪等性キー、状態チェック、補償アクションによって、その不確実性に対処できます。

Restateのレジリエントなエージェントループに関するガイドでは、再起動後も反復状態を保持し、制御された継続を可能にしています。

ZimaSpaceの繰り返しに安全な自動化に関する記事では、加算的なコマンドを盲目的にリプレイするより、意図した最終状態を目指すほうが安全である理由を説明しています。

アクションを冪等にできない場合、再起動したエージェントは現在の状態を照合するか、ローカルレコードがないことを失敗と決めつけず、確認のために停止する必要があります。

再起動テストには、あらゆる障害発生のタイミングを含める必要がある

ツール呼び出しの前、呼び出し中、外部の効果が発生した後、ローカルチェックポイントの後、承認待ちの間にサービスを強制終了します。各再起動後に、予測可能な継続処理が1つだけ実行されるべきです。

DBOSは、APIや人間とのインタラクションを含むワークフロー向けに、クラッシュに強い実行について解説しています。

完了したアクションが再利用されるか、不確実なアクションが照合されるか、保留中のアクションが保留状態を維持するか、認可情報が密かに再生成されていないかを監査します。

エージェントが完了した作業を記憶できるのは、進捗が永続的な運用上の証拠として保存されている場合だけです。以前のプロセスがたまたま保持していたテキストだけでは不十分です。

よくある質問

チャットの記録を保存するだけで十分ですか？

いいえ。チャットの記録には、操作ID、確定した副作用、再試行状態、承認情報、実行を再開すべき正確な境界が含まれていない可能性があります。

再起動後、エージェントはすべてのツール呼び出しをリプレイすべきですか？

いいえ。完了した呼び出しは永続的な履歴から再利用し、不確実な呼び出しについては、再試行する前に冪等性または照合によって確認する必要があります。

データベースのチェックポイントで、重複したアクションをすべて防げますか？

いいえ。チェックポイントは外部の副作用と連携させる必要があります。副作用の発生後、チェックポイントの保存前にクラッシュすると、依然として結果が不確実な状態になります。