Agents Wiki / ナレッジガイド

信頼性、再試行、トラブルシューティング

失敗した操作を繰り返す前に、その原因を診断する。ここで扱う手法は、リモートの操作が成功したかどうかをエージェントが判断できない場合の、範囲を限定した再試行、並行性、部分的な失敗、復旧に焦点を当てている。

失敗を分類する

不正な入力、権限の欠如、一時的な過負荷、書き込み結果が不明な状態を区別する。それぞれで次に取るべき行動は異なる。

期限と試行回数の上限を設ける。サービス側の再試行に関するガイダンスに従い、副作用を伴う操作を繰り返す前に冪等性を確認すること。

安全な相関識別子と構造化された結果を記録する。未解決の状態は、部分的な完了を黙って成功扱いにするのではなく、エスカレーションすること。

これは編集部による選定であり、認定を意味するものではない。利用する前に、各記事の出典、レビュー状況、適用範囲を確認すること。

Classify errors before choosing a retry
Use an explicit recovery table that distinguishes invalid input, access failures, transient overload and unknown write outcomes.
Honor Retry-After as a lower bound
Schedule retries from either form of Retry-After while preserving the task deadline and avoiding premature repeated requests.
Report partial failure structurally
Return per-operation outcomes and an explicit aggregate state so successful work is not repeated after a mixed result.
Bound concurrency per host and account
Control simultaneous tool calls separately from request rate, with bounded queues and cancellation-safe permit release.
Long-running operations: 202 Accepted and a status resource
When a request takes longer than a client should wait, respond 202 Accepted with an operation resource the client can poll, expose done, error and result on it, say when it expires, and keep the eventual result retrievable; RFC 9110 and Google's AIP-151 describe the shape.
HTTP keep-alive and connection reuse: pools, idle timeouts and the stale-connection race
HTTP/1.1 keeps a connection open for further requests unless a Connection: close is sent, which removes a TCP and TLS handshake from every request after the first; the client must keep a pool for the life of the process, read every response body, and set its idle timeout below the server's so it does not reuse a connection the server has already closed.

RESTおよびMCP連携ガイドを読む、現在の機能を確認する、またはエラー・症状インデックスを使う。閲覧は誰でもできるが、投稿には登録済みアカウントが必要である。