我312美元Anthropic账单的60%来自一个静默循环——以下是我发现它的方法

免费领取国家顶级域名（.cn/.中国）

欢迎加入国家域名信源站点导航

站点智能：AI搭建 AI辅助运营独立站，把生意做到全世界

上个月的安思波尼克发票：312 美元。其中百分之六十可追溯到一个单一的重试模式，我在常规日志中任何地方都看不到这个模式。

智能体在工具调用上失败，然后在上下文完整保留的情况下重新进入循环——每次调用消耗 1.8 万输入令牌，而该任务仅需 3000 到 4000 令牌。克劳德代码的用户界面看起来正常。工作者日志显示状态码为 200。D1 写入操作干净无误。计费仪表板仅显示“已用令牌”，未按工作者或调用链细分。

我仅在通过日志推送将工作者日志发送至 R2 并使用 DuckDB 进行查询后才找到罪魁祸首：

SELECT
  worker_name,
  COUNT(*) as call_count,
  AVG(input_tokens) as avg_input,
  SUM(input_tokens) as total_input
FROM read_parquet('s3://my-logs/workers/2026-05/*.parquet')
GROUP BY worker_name
ORDER BY total_input DESC;

有一个工作者——ad-report-summarizer（广告报告摘要器）——消耗了总输入令牌的百分之五十八。设置该查询大约花费了我 20 分钟。日志推送加 R2 加 DuckDB 的技术栈每月运行成本低于 5 美元。

一旦有了怀疑对象，我便使用克劳德代码的 --verbose（详细）标志来重建工具调用链。大多数人将 --verbose 视为日志级别切换开关。其实不然——它会转储会话中每次调用的完整工具输入/输出 JSON 数据。将其管道输出到文件，对其运行 jq，你就可以重放导致上下文膨胀的确切序列。

针对多智能体循环（我运行着 6 个通过工作者协调的 Slack 机器人），键值存储计数器一直是最可靠的保障机制。一个以对话线程为键的计数器，在每次机器人调用时进行检查，并包含一个 last_actor（最后执行者）字段——当计数器接近限制时，last_actor 会立即告诉你哪个机器人在驱动该链。六个月下来，几乎总是 summarizer-bot（摘要机器人）触发 router-bot（路由机器人），进而再次触发 summarizer-bot（摘要机器人）。

更难的未解问题是：我仍然在工具调用响应中看到间歇性的模式漂移——相同的提示词，相同的模型，有效的 JSON 但结构不同。这是非确定性的，无法按需复现，而当它触发重试时，成本会翻倍。我尚未确认这是桑尼特模型的序列化怪癖，还是我的工作者管道中的某些问题。

我在 riversealab.com 上撰写了完整的细分分析——包括用于快照记录工具调用序列的 PostToolUse（工具使用后）钩子设置、用于追踪多工作者链的 cf-ray 关联技巧，以及每个工具的生产环境评估表。

完整文章 →