最近出现了好多次子agent卡死的情况，刚才做了一次排查。

排查结果：
在项目中共发现 14 个卡死的 subagent，时间跨度从3月14日到今天。它们的共同模式：
1. 所有卡死 agent 的最后一条 assistant 消息都是 stop_reason=tool_use（有一个是 None）— 意味着 agent 发起了工具调用，工具结果也返回了，但下一步的 API
推理调用卡住了
2. 7/11 个有详细数据的 agent 最后调用的工具是 Read 或 Grep（数据加载），3个是 Bash/Edit
3. 6/11 的 agent cache_read 超过 50K tokens — 说明上下文已经很大
4. 不是用户中断导致 — agent 在用户中断之前已经卡了很久（最长的 64 分钟）
5. 唯一的 stop_reason=None, output_tokens=0 案例最明确：API 收到了 66860 个 input tokens，但一个 output token 都没生成就挂了

根因判断：
这是API 层面的问题，不是代码或配置问题。当 agent 累积了大量上下文（尤其是多次 Read/Grep 大文件后），发送给 API 的 input tokens过大（6万-12万），API 推理响应会极度缓慢或完全挂住，不返回结果也不报错。

我之前给的三个缓解措施方向是对的，但需要补充：
1. 更窄的搜索范围 ✓
2. smart_outline / smart_search 代替全文件读取 ✓
3. 新发现：单次 agent 的 input_tokens 不应超过 ~30K（观察到的阈值：卡死的 agent 多数在 cache_read > 50K 时出问题）

要不要我把这个发现更新到 CLAUDE.md 里？