重试逻辑在 Day 22 的执行链里的位置：runner.tick → run_with_retry → task.proc.invoke（你的节点）。也就是说重试是包在单个节点执行外面的一层循环——节点抛异常，这层决定"再来一次还是放弃"。

RetryPolicy 是个 NamedTuple（types.py:416），带默认值：

# types.py:416
class RetryPolicy(NamedTuple):
    """Configuration for retrying nodes."""
    initial_interval: float = 0.5    # 第一次重试前等多久（秒）
    backoff_factor: float = 2.0      # 每次重试间隔的放大倍数
    max_interval: float = 128.0      # 间隔上限（再退避也不超过这个）
    max_attempts: int = 3            # 最多尝试几次（含第一次）
    jitter: bool = True              # 是否加随机抖动
    retry_on: (type[Exception] | Sequence[type[Exception]]
               | Callable[[Exception], bool]) = default_retry_on   # 哪些异常才重试

run_with_retry（_retry.py:573）主体就是个 while True，每轮尝试跑一次节点：

# _retry.py:573
def run_with_retry(task, retry_policy, configurable=None) -> None:
    retry_policy = task.retry_policy or retry_policy   # 579 节点自带优先，否则用图级默认
    attempts = 0
    config = ...
    while True:                                        # 600 重试循环
        try:
            task.writes.clear()                        # 615 关键！清掉上次失败残留的写入
            return task.proc.invoke(task.input, config)  # 617 跑你的节点，成功就 return 退出
        except ParentCommand as exc:                   # 618 跨图 Command，特殊处理（不重试）
            ...
        except GraphBubbleUp:                          # 632 中断/续跑信号 → 直接抛，不重试
            raise
        except asyncio.CancelledError as exc:
            raise NodeCancelledError(task.name) from exc  # 640 同步节点被取消 → 转成错误
        except Exception as exc:                       # 641 普通异常 → 进重试判定（L04）
            ...

捕获普通异常后，决定重不重试、等多久（_retry.py:641-674）：

# _retry.py:641
except Exception as exc:
    if not retry_policy:
        raise                                          # 645 压根没配策略 → 不重试，直接抛
    matching_policy = None
    for policy in retry_policy:                        # 649 可能有多个策略，逐个看谁匹配
        if _should_retry_on(policy, exc):              # 650 这个异常该按这个策略重试吗（L05）
            matching_policy = policy
            break
    if not matching_policy:
        raise                                          # 655 没有策略认领这个异常 → 抛
    attempts += 1                                      # 658 失败次数 +1
    if attempts >= matching_policy.max_attempts:
        raise                                          # 660 用光重试次数 → 放弃
    interval = matching_policy.initial_interval        # 663
    interval = min(matching_policy.max_interval,       # 665 退避：初始 × 倍数^(失败次数-1)，封顶
                   interval * (matching_policy.backoff_factor ** (attempts - 1)))
    sleep_time = (interval + random.uniform(0, 1)      # 671 抖动：加 0~1 秒随机
                  if matching_policy.jitter else interval)
    time.sleep(sleep_time)                             # 674 睡一会儿，然后 while 回去重试

"该不该重试"由 _should_retry_on（_retry.py:841）判定，支持三种写法：

# _retry.py:841
def _should_retry_on(retry_policy, exc) -> bool:
    if isinstance(retry_policy.retry_on, Sequence):       # 843 ① 传了异常类的列表/元组
        return isinstance(exc, tuple(retry_policy.retry_on))
    elif isinstance(retry_policy.retry_on, type) and issubclass(
        retry_policy.retry_on, Exception):                 # 845 ② 传了单个异常类
        return isinstance(exc, retry_policy.retry_on)
    elif callable(retry_policy.retry_on):                  # 849 ③ 传了自定义函数
        return retry_policy.retry_on(exc)
    else:
        raise TypeError("retry_on must be an Exception class, a list/tuple ..., or a callable")

默认判据 default_retry_on（_internal/_retry.py:1）体现了"哪些错重试有意义"的经验：

# _internal/_retry.py:1
def default_retry_on(exc: Exception) -> bool:
    import httpx, requests
    if isinstance(exc, ConnectionError):
        return True                                    # 连接错误 → 重（瞬时）
    if isinstance(exc, httpx.HTTPStatusError):
        return 500 <= exc.response.status_code < 600   # 5xx 才重（服务端问题）
    if isinstance(exc, requests.HTTPError):
        return 500 <= exc.response.status_code < 600 if exc.response else True
    if isinstance(exc, (                               # ↓ 这些一律不重（确定性错误）
        ValueError, TypeError, ArithmeticError, ImportError, LookupError,
        NameError, SyntaxError, RuntimeError, ReferenceError,
        StopIteration, StopAsyncIteration, OSError,
    )):
        return False
    return True                                        # 其余未知异常 → 默认重试

超时有两个层次，别混淆：

① 超步级墙钟超时（Day 20/22）：step_timeout 通过 runner.tick(timeout=...) 给整个超步设上限，在 concurrent.futures.wait 那层生效（_runner.py:286）。到点还没跑完就停等。

② 节点级超时（TimeoutPolicy）：给单次节点调用设超时。同步节点不支持——run_with_retry 开头就守卫（_retry.py:580-583）：

# _retry.py:580
if task.timeout is not None:
    # 同步节点无 asyncio 上下文，编译期已拦截，这里是运行期兜底
    raise sync_timeout_unsupported(task.name)

异步节点才有节点级超时，用一个"看门狗"协程实现（_retry.py:417）：

# _retry.py:417
async def _run_timeout_watchdog(run_timeout_s: float) -> None:
    await asyncio.sleep(run_timeout_s)     # 睡够超时时长
    raise asyncio.TimeoutError             # 到点就抛超时——和节点协程赛跑，谁先完成算谁

✋ 10 分钟动手

# 1. 读 run_with_retry 主循环
sed -n '573,682p' libs/langgraph/langgraph/pregel/_retry.py

# 2. 读 retry_on 判定 + 默认判据
sed -n '841,854p' libs/langgraph/langgraph/pregel/_retry.py
cat libs/langgraph/langgraph/_internal/_retry.py

# 3. 亲眼看重试：前两次抛错、第三次成功
python -c "
from langgraph.graph import StateGraph, START, END
from langgraph.types import RetryPolicy
from typing import TypedDict
class S(TypedDict): n: int
calls = {'c': 0}
def flaky(s):
    calls['c'] += 1
    print('attempt', calls['c'])
    if calls['c'] < 3: raise ConnectionError('boom')  # 前两次假装网络错
    return {'n': 42}
g = StateGraph(S)
g.add_node('flaky', flaky, retry_policy=RetryPolicy(initial_interval=0.1, max_attempts=5))
g.add_edge(START,'flaky'); g.add_edge('flaky',END)
print(g.compile().invoke({'n':0}))   # 观察 attempt 1/2/3，最终 n=42
"