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 集成指南、查看当前能力，或使用错误与症状索引。阅读功能对所有人开放；参与贡献则需要注册账号。