为什么 Agent 会卡死
真实场景中循环挂掉的几种典型模式，以及用户会看到什么
本页解决的问题
先给结论「为什么 Agent 会卡死」要解决的关键问题是什么？
真实场景中循环挂掉的几种典型模式，以及用户会看到什么
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
模型忘了上次已经做过这件事，或者认为上次没成功所以要重试，但参数一模一样，结果也一模一样。
典型场景：反复读取同一个文件、反复搜索同一个关键词、反复调用同一个 API
Agent 在忙，但每一轮只做边缘操作：整理格式、反复确认、做无关搜索。看起来在工作，实际没有推进核心目标。
典型场景：Agent 在复杂任务中迷失方向，不断做安全但无用的小动作
当上下文过长或模型困惑时，它会退化为复读模式：把之前的输出再生成一遍。模型并没有卡住，它已经迷路了。
典型场景：长对话后期、上下文接近窗口上限、任务描述模糊
工具 A 超时 → Agent 重试 → 还是超时 → 换个方式调 → 还是不行 → 试工具 B 来绕过 → B 依赖 A 的结果也挂了 → 雪崩。
典型场景：外部 API 限流、数据库连接池耗尽、第三方服务临时宕机
选择一种模式，看后台日志长什么样
「四种生产环境特有的卡死模式」里的风险边界在哪里
「模型忘了上次已经做过这件事，或者认为上次没成功所以要重试，但参数一模一样，结果也一模一样」把安全问题从一句“请模型不要犯错”拉回到权限、数据和环境。真正需要保护的是：模型即使判断失误，系统也不能让错误变成不可逆的结果。
把模型建议和实际权限分开
在「典型场景：反复读取同一个文件、反复搜索同一个关键词、反复调用同一个 API」涉及的流程中，要分别检查用户能要求什么、模型能建议什么、工具实际允许什么，以及谁有权批准写入或发送。网页、文档和工具返回值都可能携带不可信指令，不能因为它们看起来像说明就自动提升权限。
安全设计必须包含失败和恢复
结合「工具 A 超时 → Agent 重试 → 还是超时 → 换个方式调 → 还是不行 → 试工具 B 来绕过 → B 依赖 A 的结果也挂了 → 雪崩」做一次反向演练：加入错误输入、缺失凭证或迟迟不到的审批，确认系统会拒绝、暂停并留下可追踪信息，而不是继续执行到底。
从「四种生产环境特有的卡死模式」走到「选择一种模式，看后台日志长什么样」
「四种生产环境特有的卡死模式」先把问题落在「模型忘了上次已经做过这件事，或者认为上次没成功所以要重试，但参数一模一样，结果也一模一样」上；到了「选择一种模式，看后台日志长什么样」，讨论继续推进到「同参数循环 收益递减 文本复读 工具雪崩 ← 选择一种模式开始模拟 生产环境的 Agent 挂法和实验室里不一样：用户不会告诉你「Agent 死循环了」，他只会说「你的 AI 怎么这么慢/这么蠢」。 识别这些模式，是做防护的前提」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
做安全判断时，把“模型想做什么”和“系统允许做什么”分开，逐个检查数据边界、工具权限、人工确认和失败后的恢复路径。
- 「四种生产环境特有的卡死模式」：模型忘了上次已经做过这件事，或者认为上次没成功所以要重试，但参数一模一样，结果也一模一样
- 「选择一种模式，看后台日志长什么样」：同参数循环 收益递减 文本复读 工具雪崩 ← 选择一种模式开始模拟 生产环境的 Agent 挂法和实验室里不一样：用户不会告诉你「Agent 死循环了」，他只会说「你的 AI 怎么这么慢/这么蠢」。 识别这些模式，是做防护的前提
- 「最后的要点」：工具 A 超时 → Agent 重试 → 还是超时 → 换个方式调 → 还是不行 → 试工具 B 来绕过 → B 依赖 A 的结果也挂了 → 雪崩
最后的「最后的要点」把讨论落到「工具 A 超时 → Agent 重试 → 还是超时 → 换个方式调 → 还是不行 → 试工具 B 来绕过 → B 依赖 A 的结果也挂了 → 雪崩」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。