WordPress团队自曝：AI代理3秒烧光4美元

开发AI代理的人都有过同一种冷汗：它开始循环了。读一篇帖子，尝试编辑，遇到意外响应，再读一遍，再试一次，同样的错误再来一次——30秒内烧掉4美元API费用，什么都没做成。

PressArk团队把这个场景写进了技术博客。他们的AI助手直接嵌在WordPress后台，用户用自然语言管理整个站点：改内容、跑SEO审计、管WooCommerce产品、扫安全漏洞。代理能调用200多个工具，在真实生产环境里操作真实用户数据。失控不是成本问题，是生死问题。

「空转检测」：3轮无进展，强制拔插头

WordPress的API有个脾气：wp_update_post()可能静默失败，WooCommerce端点返回的schema和文档对不上，Elementor页面的JSON结构跟模型预测的不一样。代理看到意外结果，重试同一招，得到同样的意外，永远出不来。

PressArk的解法粗暴有效——每轮把工具调用做哈希，如果签名跟前一轮完全重合（同样工具、同样参数、同样模式），idle计数器+1。达到3轮直接强制退出，不给例外。代理收到结构化错误，用户看到「我卡住了，这是我在做的事」，而不是神秘超时。

开发期间这个简单启发式省下的失控API费用，按他们说法是以千美元计。

Token预算：65%、86%、8000三个阈值

WordPress对话膨胀极快。用户说「审计首页SEO」，代理要：读页面内容→调SEO分析工具→读分析结果→生成修复建议→执行修改→验证结果。到第4步，上下文窗口已经烧掉大半；等它想写总结，早忘了第1步发现了什么。

PressArk设了三道硬门槛：总token上限25.8万。65%（约16.7万）触发「检查点预备」——代理开始构建结构化快照，记录已完成的工作和关键发现。86%（约22.2万）启动「实时压缩」——对历史消息做有损精简，扔掉中间推理但保留决策结论。最后留8000token的「暂停余量」，确保不会顶穿天花板。

压缩不是删除。他们把对话历史转成摘要+关键数据+待办清单的混合结构，让代理既知道「做过什么」，又不背负「怎么一步步想的」。

检查点机制：卡死时能回到「上一个存档点」

最狠的是检查点系统。代理每完成一个逻辑单元（比如「已分析完标题标签」），就写入一个结构化快照：当前状态、已完成任务、待办事项、关键数据。如果后续崩溃或超时，重启后从最近检查点恢复，而不是从头再来。

这跟游戏存档一个道理。但PressArk加了层保险——检查点本身带版本校验，防止代理在恢复后陷入「发现检查点→尝试继续→遇到同样问题→再存一个同样检查点」的递归地狱。

他们公开了核心代码片段。空转检测用idle_rounds计数器，token阈值用硬编码常量，检查点用JSON序列化状态。没有花哨的机器学习，全是工程层面的防御性编程。

「我们试过让模型自己判断什么时候该停，」博客写道，「它永远觉得自己下一秒就能解决。」

这套机制跑在真实环境里的代价是：平均对话长度被压缩40%，但完成率从67%提到89%。用户看不到检查点，但能感觉到——同样的复杂任务，以前经常超时或胡言乱语，现在即使卡住也能拿到清晰的「我做到了这里，这是剩下的」。

PressArk最后抛了个问题：当AI代理的工具调用从200个变成2000个，当上下文窗口从25万token涨到250万，这些硬编码的阈值还够用吗？还是说，我们需要一种让代理自己学会「什么时候该喊停」的机制——但又要防止它学会「永远不放弃」？