设想 Agent 正在帮你处理一个测试失败

当 Agent 读完报错日志后它会定位到相关配置文件，接下来开始生成修改方案。但往往它的回答停在半个代码块里导致你手忙脚乱；点击重新生成后又可能卡住甚至直接返回 “overloaded”，连一句话都没有。若 Agent 对所有失败都无脑重试，后续任务很容易出现连锁错误。

再看使用者痛点一，回答被截断。信息不完整

当模型输出因为长度上限而中止时你已经拥有一份响应，但内容还没结束。你需要判断这半段是否应该保存，否则每次重试都会丢失已有进度。

如何判断是否保留？

• 上下文太长导致请求超限时只能进入异常处理分支。
• 如果是“max_tokens”停止原因。先扩大输出空间，再重新请求。

失败发生的位置。决定了程序能做什么

我们把三种常见情况整理成表格：

现象	程序拿到的信息	恢复动作
模型输出到达长度上限	响应已存在但未完成	扩大 max_tokens，再请求；若仍不足，则开启续写
接口调用异常	No正常响应。只能捕获异常信息	按指数退避重试
上下文过长导致拒绝请求	No正常响应，只能裁剪消息历史	紧急压缩为最近五条消息，再重试一次；若仍超限则直接报错并结束任务。怎么说呢，

回答写到一半时第一次先扩大输出空间

这一步主要是不要立即把半截回答写入消息历史。而是先给模型更多空间完成当前任务。

if response.stop_reason == "max_tokens":
if not state.has_escalated:
max_tokens = ESCALATED_MAX_TOKENS
state.has_escalated = True
continue
# 此逻辑位于回复写入消息历史之前

如果扩容后仍不足。则加入一次“续写”提示：

Output token limit hit. Resume directly — no apology,no recap. Pick up mid-thought.
# 限制最多执行三次续写

为什么要限制？多次续写往往说明任务粒度过大或答案方式不合适，一直追加只会得到冗长却难读的答案。

上下文太长时最近五条消息只是应急方案

此处采用极简压缩。仅保留最近五条对话记录，以快速降低请求长度。

def reactive_compact -> list:
tail = messages
return Earlier conversation trimmed. Continue from where you left off."
}。*tail]
# 压缩后的消息替换原来的历史，接下来
调用模型

与 s08 的“常规压缩”不同，这里不保留工具调用与结果的完整配对，仅保证请求能够通过。若压缩后仍超限，则直接返回错误并终止循环——这避免了无限删减导致任务主要信息丢失。

限流 / 服务过载 的处理主要是控制重试节奏

遇到 HTTP 429 或服务器错误时需要做的是“慢下来”，而不是继续猛撞接口。我们使用指数退避加随机抖动来防止大量并发重试造成雪崩效应。

 d> ) ) ) )

# 次失败次数	基础等待时间
1 次 | 0 秒 | )
4 次 | 16 秒 | 最多可等待数十秒 )

说到实现细节，

• @with_retry 将 “429/503” 等临时错误交给指数退避；其他异常则直接抛给外层循环处理。这样分层清晰、易维护，
• If multiple Agents retry at same time after a shared cooldown,random jitter spreads traffic.

备用模型还没有接上 —— 一个实现缺口

代码中仅有切换状态行：

state.current_model = FALLBACK_MODEL
# 切换日志已打印。但后续重试仍用旧模型
#endif
lambda mt=max_tokens,mdl=state.current_model:
client.messages.create
# lambda 中 mdl 已被闭包固定为旧值
# 正确实现：
def request:
return client.messages.create(
model=state.current_model,system=system,messages=messages,tools=TOOLS,max_tokens=max_tokens,)
如果只更新状态而未更新闭包里的默认参数，备用模型永远不会真正生效。这段代码提醒我们：**状态变化并不等同于接下来操作一定读取最新值**。

教学代码省略了哪些真实程序所需功能？

);;

位置	当前做法	实际程序还需要补充
紧急压缩保留最近五条消息	保护工具调用与工具结果关联

• - 缓存与弹性：服务端建议等待时间延迟函数支持该参数。
\
• - 重复调用：当前没有读取接口响应中的 wait-time 信息来 retry 间隔。
\
• - 重试次数：循环总共请求 X 次并区分额外重试次数。
\
• - 后备模型更新：必须确保每一次请求都读取最新的 current_model 状态，而不是闭包缓存旧值。
\
• - 续写控制：固定最多三次续写，并根据新产生内容判断是否继续。\
• - 消息完整性校验：紧急压缩后可能导致工具结果丢失，需要进一步检查。\
• - 日志与监控：明确记录每一次恢复动作，以便排查问题。\

再看一下缺陷，

• The current example only prints a log for fallback model switch but never actually uses it.
• The emergency compression only keeps last five messages and doesn't preserve tool-call/result pairing。which may break downstream logic.
• No adaptive wait‑time extraction from server responses.
• No clear separation 娱乐ween total retry attempts and per‑error‑type retries.
• The code assumes unlimited retry loops without enforcing hard limits on overall attempts.
• Coding errors in table formatting above – this version presents m as bullet lists instead of an actual table for clarity. <\/ul>

本章小结 & 接下来计划

• 三种恢复方法已补齐：
  • 输出不足 → 扩大 token 上限 → 可选续写;
  • 上下文超长 → 紧急压缩至最终五条 → 单次重试；若仍超限即终止，
  • 临时不可用 → 指数退避 + 随机抖动；最多尝试 N 次，<\/ul> <\/li>
  • 尚需改进之处 \u2026–>–>–>–>–> <\/ul>

下章节将聚焦任务管理层面——待办列表、跨会话恢复和长期执行依赖关系的完整方法设计。

---