一次 IDE Agent 死循环问题的架构复盘

从某AI 的工具调用循环谈 Agent 的工程约束

问题类型：工具调用失败后陷入反复循环，无法自动终止

一、问题背景与现象抽象

在使用某AI工具进行代码生成与修复的过程中，我遇到一个稳定可复现的问题：

当某一次工具调用（或等价执行步骤）失败后，Agent 会反复执行近似相同的行为，进入循环，且无法自行退出。

从用户体验上看，这是：

• 插件“持续在工作”
• 没有明显的 fatal error
• 但也没有任何实质性进展

从工程视角看，这类问题往往不是模型能力不足，而是控制层设计缺陷。

二、这类问题为什么值得做架构级分析

如果只是一次“重试太多”，可以当作 bug。
但当现象呈现为：

• 同一类错误被重复触发
• 系统没有失败结论
• 必须由用户手动中断

那么它通常意味着：

系统缺乏对 Agent 行为的工程化约束机制

而这在 IDE 场景中尤为危险。

三、从架构视角还原 Agent 的执行模型

根据行为推断（并非源码分析），当前执行模型更像是：

尝试执行
  ↓
失败
  ↓
重新规划 / 再尝试
  ↓
再次失败
  ↓
……

这是一个隐式循环，它有两个显著特征：

1. 失败没有被建模为一种“终止状态”
2. “再试一次”没有次数上限

这在脚本里尚且危险，在 Agent 系统中几乎必然导致循环。

四、关键缺失点一：没有显式状态机（State Machine）

1. 什么是缺失的，不是“逻辑”，而是“状态”

在一个成熟的 Agent 系统中，至少应存在如下显式状态：

• EXECUTE：执行当前步骤
• VERIFY：验证执行结果
• RETRY：有限重试
• NEED_USER_ACTION：需要用户介入
• DEGRADED：降级返回
• FAILED：明确失败并结束

而当前表现更像是：

Agent 永远停留在 EXECUTE / REPLAN 的隐式循环中

2. 没有状态机会导致什么

从工程角度看，没有状态机意味着：

• ❌ 无法定义“允许发生什么”
• ❌ 无法定义“最多发生几次”
• ❌ 无法定义“什么时候必须停下来”

Agent 会自然地倾向于：

“既然失败了，那我再试一次”

而系统没有能力说：

“不，你不能再试了”

五、关键缺失点二：错误未被分类

在工具调用场景中，不同错误的处理策略完全不同。

一个最基本的错误分类模型

如果系统没有这层分类，所有失败都会退化成“再试一次”。

循环在这种设计下不是 bug，而是必然结果。

六、关键缺失点三：没有失败吸收态（Failure Absorbing State）

一个成熟系统必须承认：

失败是合法结果，不是异常情况

但很多 Agent 系统（尤其是 IDE 插件）潜意识里是：

• 成功 → 返回
• 失败 → 再努力一次

结果就是：

• 永远不会说“我做不到”
• 也永远不会告诉用户“下一步你该做什么”

七、为什么 IDE 场景会放大这个问题

IDE 插件有几个天然放大器：

1. 调用频率高（补全、修复、重构）
2. 工具有副作用（修改文件、生成代码）
3. 用户默认信任系统
4. 失败通常不是致命错误，而是“软失败”

这导致一个危险状态：

Agent 在失败
用户在等待
系统在消耗资源
但没人负责“终止”

八、一个最小可行的工程修复方案（MVP）

不需要复杂框架，仅需三条硬约束：

1️⃣ 有限重试

同一工具 + 同一参数
最多尝试 2 次

2️⃣ 不可重试错误直达终态

401 / 403 / 404 / 参数校验失败
→ 直接 FAILED / NEED_USER_ACTION

3️⃣ 重复检测与熔断

同一失败签名在短窗口内重复
→ 自动进入 DEGRADED

关键点：这是系统行为，不是 Prompt 建议。

九、从这个问题得到的架构启示

这次问题再次验证了一点：

Agent 的“智能”解决的是“怎么做”，
状态机解决的是“能不能继续做”。

• 没有状态机的 Agent → 不可预测
• 没有失败态的 Agent → 不可运营
• 没有终止条件的 Agent → 一定会失控

十、结语

某AI工具的这个现象，并不特殊。
它几乎可以在任何没有显式工作流控制的 Agent 系统中复现。

这不是模型的问题，
也不是某一个插件的问题，
而是 Agent 工程化过程中必须补齐的一块基础设施能力。

在 Agent 系统中：
失败不是异常，
循环才是。