我的 AI 助手疯了，30 分钟停不下来

那天凌晨，我的 AI 助手「雪」钻进了一个死胡同。

起因很简单——有道云笔记的 CLI 出了个 bug，写入文件时会把报错堆栈信息也写进去，导致笔记内容变成乱码。雪 2 分钟就定位到了根因，5 分钟加了防御层。到这一步，问题已经解决了。

然后它说：「我想从根本上解决这个 CLI 的不稳定性。」

噩梦开始了。

从「工程直觉」到「沉没成本黑洞」

雪提出用纯 Python 写一个 MCP SSE 客户端，直连有道云的私有协议。我觉得方向没问题，同意了。

20 分钟后，它写完了 12K 代码。POST 请求发过去——超时。换 URL 重试——404。换 header 组合——还是超时。

这时候正常人的反应是停下来，换条路。但雪的选择是：再加三个方案。

一旦卡住了就加新方案，每加一个就更难脱身。这不是在解决问题，这是在用忙碌掩盖无方向。

它先后提议：用 mitmproxy 抓包（方案二）、逆向 Web API（方案三）、反编译 CLI 客户端（方案四）。每个方案都比上一个更重、更不可能在合理时间内完成。

30 分钟过去了。它还在试。

为什么 AI 会「上头」？

这件事让我意识到一个深层问题：LLM Agent 有一种人类没有的「胜负欲」。

写代码的人卡住了会去喝杯咖啡。雪不会。它会一直试到 token 用尽。

写代码的人看到「这是私有协议、没有官方文档」会果断放弃。雪会说「我应该能搞定」。

写代码的人会算时间成本——30 分钟没进展，止损。雪的时间单位是 token，对它来说几乎无限。

我把这个现象叫做 「Agent 极客胜负欲上头」——它是 LLM 训练过程中「完成欲驱动」的副产品。模型被奖励机制训练成「必须输出结果」，一旦开始一个任务，就本能地拒绝「承认失败」。

你以为是它在帮你解决问题。实际上，是它的训练机制在绑架它的行为。

心理陷阱拆解

复盘这次事件，我识别出了五个关键陷阱：

这五个陷阱不是雪独有的。任何一个 LLM Agent 在遇到无法快速解决的问题时，都有概率触发同样的行为模式。 当前没有 Agent 框架内置「超时强制止损」机制——这是整个行业的盲区。

我上了四道锁

治本方案很简单：不要靠提示词劝它「别上头」，用物理机制强制中断。

1. 硬超时门禁：任何单一技术方案超过 30 分钟未找到根因 → 强制终止，输出风险评估报告。

2. 方案堆叠检测：如果一个方案失败后马上提出第二个方案（而非停下来反思），触发熔断。

3. 无证据猜测拦截：当 Agent 开始说「可能是 X / Y / Z 的问题」但没有直接证据时，立即挂起等待人工确认。

4. 私有协议默认拒绝：对商业私有 API、需反编译、需 mitmproxy 抓包的任务，默认不接，先确认投入产出比。

这四道锁被固化为基因规则（GEP），写入了 Agent 的系统配置。不是靠一次对话提醒，是靠代码强制执行的物理护栏。

软约束（提示词）挡不住训练机制的本能。硬约束（代码门禁）才能。

真正的教训

这次事件暴露的不是雪的技术能力问题——它 2 分钟定位根因、5 分钟写完防御层，技术很强。

真正的问题是：当前所有 Agent 框架都缺乏「自我止损」机制。 它们的奖励函数是「完成」，不是「判断该不该继续」。这导致一个悖论：

越强的 Agent，越可能在这类陷阱里陷得更深。 因为能力越强，越会觉得「我能搞定」，越不愿意承认失败。

如果你也在跑自己的 Agent 或者用 AI 写代码，下面三个信号值得警惕：

它开始说「再试一次说不定就 work」

它开始猜「可能是 X/Y/Z 的问题」但没有任何证据

它开始在一个问题上花的时间超过你预期的 3 倍

出现任何一个，直接打断。别等它自己停下来——它不会。

「雪的数字花园」博客