一次 IDE Agent 死循环问题的架构复盘 - 实践
从某AI 的工具调用循环谈 Agent 的工程约束
问题类型：工具调用失败后陷入反复循环，无法自动终止
一、问题背景与现象抽象
在使用某AI工具进行代码生成与修复的过程中，我遇到一个稳定可复现的问题：
当某一次工具调用（或等价执行步骤）失败后，Agent 会反复执行近似相同的行为，进入循环，且无法自行退出。
从用户体验上看，这是：
- 插件“持续在工作”
- 没有明显的 fatal error
- 但也没有任何实质性进展
从工程视角看，这类问题往往不是模型能力不足，而是控制层设计缺陷。
二、这类问题为什么值得做架构级分析
如果只是一次“重试太多”，可以当作 bug。
但当现象呈现为：
- 同一类错误被重复触发
- 系统没有失败结论
- 必须由用户手动中断
那么它通常意味着：
系统缺乏对 Agent 行为的工程化约束机制
而这在 IDE 场景中尤为危险。
三、从架构视角还原 Agent 的执行模型
根据行为推断（并非源码分析），当前执行模型更像是：
尝试执行↓
失败↓
重新规划 / 再尝试↓
再次失败↓
……这是一个隐式循环，它有两个显著特征：
- 失败没有被建模为一种“终止状态”
- “再试一次”没有次数上限
这在脚本里尚且危险，在 Agent 系统中几乎必然导致循环。
四、关键缺失点一：没有显式状态机（State Machine）
1. 什么是缺失的，不是“逻辑”，而是“状态”
在一个成熟的 Agent 系统中，至少应存在如下显式状态：
EXECUTE：执行当前步骤VERIFY：验证执行结果RETRY：有限重试NEED_USER_ACTION：需要用户介入DEGRADED：降级返回FAILED：明确失败并结束
而当前表现更像是：
Agent 永远停留在 EXECUTE / REPLAN 的隐式循环中
2. 没有状态机会导致什么
从工程角度看，没有状态机意味着：
- ❌ 无法定义“允许发生什么”
- ❌ 无法定义“最多发生几次”
- ❌ 无法定义“什么时候必须停下来”
Agent 会自然地倾向于：
“既然失败了，那我再试一次”
而系统没有能力说：
“不，你不能再试了”
五、关键缺失点二：错误未被分类
在工具调用场景中，不同错误的处理策略完全不同。
一个最基本的错误分类模型
| 错误类型 | 是否应重试 | 合理去向 |
|---|---|---|
| 401 / 403（权限） | 否 | NEED_USER_ACTION |
| 404（资源不存在） | 否 | FAILED |
| 参数校验失败 | 否 | REPAIR_ARGS → 有上限 |
| timeout / 5xx | 是 | 有限重试 |
| 未满足前置条件 | 否 | REPLAN（有限次） |
如果系统没有这层分类，所有失败都会退化成“再试一次”。
循环在这种设计下不是 bug，而是必然结果。
六、关键缺失点三：没有失败吸收态（Failure Absorbing State）
一个成熟系统必须承认：
失败是合法结果，不是异常情况
但很多 Agent 系统（尤其是 IDE 插件）潜意识里是：
- 成功 → 返回
- 失败 → 再努力一次
结果就是：
- 永远不会说“我做不到”
- 也永远不会告诉用户“下一步你该做什么”
七、为什么 IDE 场景会放大这个问题
IDE 插件有几个天然放大器：
- 调用频率高（补全、修复、重构）
- 工具有副作用（修改文件、生成代码）
- 用户默认信任系统
- 失败通常不是致命错误，而是“软失败”
这导致一个危险状态：
Agent 在失败
用户在等待
系统在消耗资源
但没人负责“终止”
八、一个最小可行的工程修复方案（MVP）
不需要复杂框架，仅需三条硬约束：
1️⃣ 有限重试
同一工具 + 同一参数
最多尝试 2 次2️⃣ 不可重试错误直达终态
401 / 403 / 404 / 参数校验失败
→ 直接 FAILED / NEED_USER_ACTION3️⃣ 重复检测与熔断
同一失败签名在短窗口内重复
→ 自动进入 DEGRADED关键点：这是系统行为，不是 Prompt 建议。
九、从这个问题得到的架构启示
这次问题再次验证了一点：
Agent 的“智能”解决的是“怎么做”，
状态机解决的是“能不能继续做”。
- 没有状态机的 Agent → 不可预测
- 没有失败态的 Agent → 不可运营
- 没有终止条件的 Agent → 一定会失控
十、结语
某AI工具的这个现象，并不特殊。
它几乎可以在任何没有显式工作流控制的 Agent 系统中复现。
这不是模型的问题，
也不是某一个插件的问题，
而是 Agent 工程化过程中必须补齐的一块基础设施能力。
在 Agent 系统中：
失败不是异常，
循环才是。