Kimi K3 翻车实录：凌晨等额度，4500 燃料烧出一个教训

Kimi K3 发布了。2.8 万亿参数，全球最大开源模型。前端代码竞技场跑分 1679，压过 Claude Fable 5 的 1631 登顶。

我对新模型一向是「先跑为敬」。正好手里有个小程序项目，编辑器解析预览那块一直不太满意，AI 改完一个问题往往带出新问题。我想着正好拿 K3 试试。

用火山引擎的 Coding Plan，凌晨额度刷新。我特意等到 0 点，切换到 Kimi K3，OpenCode 的 Build 模式，回车。然后去倒了杯水。

回来的时候还没跑完。屏幕上滚动着大段的查询和测试输出，看起来像是在分析代码。又过了十分钟，还在跑。

不对劲。它在循环打印同一段内容——查询同一个文件、跑同一组测试、输出同一段分析。一遍又一遍。

我点开 Coding Plan 的用量面板：4500 燃料没了。火山 Coding Plan 一共才 10 万燃料值，这一把烧掉了 4.5%。

第一反应：模型不行？

说真的，当时就一个想法：「这模型这么拉？」K3 跑分压 Fable5，上来就死循环？果然不能信跑分。

但坐了一会儿，越想越不对。

死循环不是模型的锅

大模型是无状态的。每次收到请求，它看到的只是一段历史对话加当前状态——「代码改完了，编译报了这个错」。它基于这些信息预测下一步。但如果改了代码，编译还报同样错误，模型就会给出同样的修改。每一轮对它来说，都是第一次看到这个报错。它根本不知道自己在同一个坑里转了 20 圈。

兜底这件事，不是模型该做的，是 Agent 该做的。

Agent 手里有完整的执行历史。它知道模型已经调用了 20 次同一个查询、改了 20 次同一段代码。它能做模式检测——连续 N 轮相同调用、输出高度重复、错误不变还在改——这些全是死循环信号。这都是 Agent 层的工程能力，跟模型好坏没关系。

但前提是：你得把它配好。

我为什么踩了这个坑

我之前一直用 TRAE，它内置了循环检测。用习惯了，下意识以为所有 AI 编程工具都有这个能力。其实之前用 GLM5 也常碰到死循环，但都是在 TRAE 的壳里跑的，TRAE 帮我拦住了，我没觉得是问题。

切到 OpenCode 没多久，想当然觉得它也有循环检测。结果凌晨 0 点，裸奔跑了一晚上。

OpenCode 的刹车在哪

翻完车第一件事，是把刹车找出来，配好。

OpenCode 其实自带 doom_loop 检测——同一个工具调用，相同输入重复 3 次，自动拦。但默认是 ask：TUI 里弹个框让你选，headless 环境（Coding Plan 后台跑就是 headless）这个框弹不出来，等于没拦。

翻车后加了三层防护：

① permission.doom_loop: "deny"

重复调用直接终止。搞低级错误的时候特别好使——忘了加参数、路径写错了、少配了环境变量，模型反复调同一个失败命令，三轮就停。

② agent.build.steps: 50

这是硬刹车。最多执行 50 轮工具调用，超出强制转纯文本回复。Plan 模式 30 轮就够了。跟 doom_loop 不一样的是，steps 不管你输入变没变，到上限就停——doom_loop 抓重复操作，steps 抓整体失控。

③ default_agent: "plan"

默认先进规划模式，只读不改、先出方案。很多死循环是因为模型一边读一边改、改出问题又回头改，plan/build 分开大幅降低这种混乱。

两层兜底加一层预防，就是我用 4500 燃料换来的配置。

避坑，就一件事

新工具到手，第一件事不是跑任务，是搞清楚它的刹车在哪。

• OpenCode — agent.build.steps 默认没上限，permission.doom_loop 默认 ask（headless 不起作用），两者都要手动配，不配就是裸奔
• Claude Code / Cursor — 默认有步数限制，但也看一眼确认
• TRAE — 内置循环检测，基本不用管
• Codex CLI — --max-turns 参数

然后新模型先跑小任务，确认工具链配合没问题再上强度。长任务前看一眼用量面板，跑完确认消耗。发现输出开始重复，手动终止。

工具层的兜底比人肉监控靠谱，但前提是你得先把它配好。

---

K3 翻车这件事，说到底不是 K3 的锅，也不是 OpenCode 的锅。是我忘了，AI 编程这件事，驾驶员不是模型，是我自己。驾驶员的第一课，是先把安全带系好。

凌晨 0 点烧掉的 4500 燃料，就当系安全带的学费了。