健壮的异步逻辑靠“控”而非“等”：分级超时（连接/读取/任务级）、并发限流（Semaphore）、降级兜底（快速失败或有限重试）、异常隔离（gather+return_exceptions=True）、连接池复用（TCPConnector配置）。
面对不可预测的 API 延迟，健壮的异步逻辑不靠“等”，而靠“控”——控制执行节奏、控制失败边界、控制资源生命周期。关键不是让请求变快，而是让系统在快慢不定时依然可响应、可恢复、不雪崩。
设置分层超时，避免单点卡死
外部 API 延迟波动大，统一设一个全局 timeout 往往顾此失彼：设太短，正常波动就被砍掉；设太长，慢接口拖垮整体体验。应按场景分级设定：
- 连接级超时（connect timeout）：通常 1–3 秒，防止 DNS 解析或建连卡住
- 读取级超时（read timeout）：根据业务容忍度，如搜索类 5 秒、通知类 8 秒、内部服务调用 2 秒
- 任务级总超时（per-task deadline）：用 asyncio.wait_for() 或 aiohttp 的 timeout 参数封装，超时后主动取消，不等到底
并发控制 + 降级兜底，不让慢请求挤占资源
不加限制地并发调用，容易因某几个慢接口耗尽连接池或事件循环资源。需主动节流并预留退路：
- 用 asyncio.Semaphore 限制并发数（例如最多同时 10 个 HTTP 请求），防打垮下游也防自身 OOM
- 对非核心工具（如推荐、埋点、日志上报）启用 快速失败降级：首次超时即跳过，不重试；或 fallback 到缓存/默认值
- 对关键工具（如支付、库存）启用 有限重试 + 指数退避，但重试次数 ≤ 2，间隔从 100ms 起步，避免雪崩
异常隔离与结果聚合，确保主流程不中断
一个工具调用失败，不应导致整个 Agent 或服务返回空或报错。要让失败“静音化”并继续推进：
- 用 asyncio.gather(..., return_exceptions=True) 并发执行多个工具，无论成败都返回结果，主逻辑再统一判断哪些成功、哪些跳过
- 每个工具协程内部 捕获 CancelledError 和 TimeoutError，做轻量清理（如关闭临时 session），不抛出未处理异常
- 为每个工具调用添加唯一 trace_id，失败时记录延迟、状态码、错误类型，便于后续分析延迟分布和故障模式
预热连接池 + 复用会话，减少毛刺延迟
首请求慢常因 TCP 握手、TLS 协商、DNS 查询等冷启动开销。生产环境必须规避：
- 初始化 aiohttp.ClientSession 时配置 TCPConnector：开启 keep-alive、设 limit_per_host（如 10）、复用连接
- 避免每次请求都新建 session —— 它是昂贵的，应在应用启动时创建并复用
- 对高频调用的 API（如内部微服务），可提前发起一次空请求“探活”，触发连接建立和证书缓存
