超时中断场景分类
在 Agent 实际运行中，超时中断并非单一现象，而是由不同根因引发的四种独立场景。只有准确区分场景，才能为每个中断点设计正确的确认与恢复逻辑。本章从原理、识别方法到代码实现逐一拆解。
四种场景定义与识别特征
| 场景 | 触发条件 | 典型表现 | Agent 影响范围 |
|---|---|---|---|
| 网络超时 | TCP 连接、HTTP 请求、gRPC 调用超过阈值 | SocketTimeoutError、ConnectionReset、DNS 解析失败 | 单个外部通信通道阻塞，任务级可降级 |
| 计算超时 | CPU 密集型推理、模型前向传播、循环未终止 | 进程响应停滞、CPU 使用率 100%、无日志输出 | 当前推理线程卡死，可能引发级联超时 |
| 资源等待超时 | 请求锁、信号量、连接池、共享内存失败 | 阻塞在 synchronize()、acquire()、wait() 调用 | 多个子任务互相等待，死锁风险高 |
| 外部依赖超时 | 数据库、缓存、第三方 API、消息队列响应超时 | service unavailable、rate limit、上游熔断 | Agent 核心状态存储或任务调度中断 |
场景识别流程图
判断优先级：收到超时异常后，先检查是否为资源等待（本地阻塞），再排除计算超时（CPU 活动判断），最后归因为网络或外部依赖（依赖方向）。
def classify_timeout(exception, context):
# 资源等待：锁或信号量超时
if "Lock.acquire" in str(exception):
return "RESOURCE_WAIT"
# 计算超时：模型推理超时回调
if context.get("is_compute") and "CUDA timeout" in str(exception):
return "COMPUTE"
# 网络超时：socket 级别
if "timeout" in exception.__class__.__name__.lower() and "socket" in exception.__module__:
return "NETWORK"
# 外部依赖：HTTP 或 gRPC 状态码
if hasattr(exception, "status_code") and exception.status_code >= 500:
return "EXTERNAL_DEPENDENCY"
return "UNKNOWN"
调试建议：在 Agent 日志中统一输出
[TIMEOUT_TYPE] 场景标识，方便后续按场景聚合分析超时分布。
内联 SVG —— 超时中断场景分类结构图
性能与稳定性优化清单
- 网络超时：设置客户端连接池与读超时分离；使用异步 HTTP 库（如 aiohttp）避免线程阻塞。
- 计算超时：在推理循环中注册 watchdog 线程，每 100ms 检测主线程是否响应；开启
CUDA_LAUNCH_BLOCKING=1定位 GPU 卡死点。 - 资源等待超时：所有锁获取必须带超时参数
acquire(timeout=5.0)；使用try-finally保证释放。 - 外部依赖超时：集成断路器（Resilience4j 或 Hystrix 模式），失败率达到阈值后快速返回 fallback。
# 资源等待超时示例 —— Python threading
import threading
lock = threading.Lock()
if not lock.acquire(timeout=3.0):
# 超时后记录并恢复：释放可能持有的其他资源
logger.error("RESOURCE_WAIT_TIMEOUT on lock %s", id(lock))
raise TimeoutError("resource_wait")
finally:
if lock.locked():
lock.release()
部署注意事项：在 K8s 环境中，网络超时容易与 Pod 健康检查超时混淆。建议将 Agent 内部超时日志与 Pod livenessProbe 探针分开，避免因内部超时导致 Pod 被重启。