每个用 LLM 的 SaaS 都有一份"显式调用列表"——webSocket、workflow、A2A 等等，都有 token tracker。但真实账单永远高于估算。这个差距不在你看的地方。
最近我们盘点了一遍，开放分享。
P0：workflow_orchestrator.py:715 — _summarize_workflow 无 token 上限
每条 workflow 跑完都生成总结。没设 max_tokens，长 workflow 的 context 完整重新喂回去——单条调用 8000+ tokens 是常态。
修复：加 max_tokens=1500 上限 + 总结 prompt 改成结构化（只要 5 个 bullet 不要散文）。
P0：workflow_orchestrator.py:803 — _extract_contacts_from_step 每 step LLM 抽取
每个 workflow step 跑完都用 LLM 抽联系人信息。一个 10-step workflow = 10 次 LLM 调用，每次 1500-3000 tokens。
修复：先 regex 抽（email / phone E.164 / domain），抽不到的才走 LLM——命中率 80%+ 直接砍 8 次调用。
P0：llm_router.py:551 — probe_down_models 每 5min ping，未埋点
监控 LLM 健康度。每 5 分钟 ping 一次每个 provider，没走 record_llm_call——这条路径在 token tracker 里完全不可见。
每天 24h × 12 次 × 6 provider = 每天 1728 次幽灵调用。
修复：包一层 record_llm_call，单独 category system_probe，按月看趋势再考虑改成 HEAD/HEALTH endpoint。
P1：services/memory_service.py — Mem0 完全未埋点
接入 mem0 时图省事，直接调 mem0.add() / mem0.search()——这两个调用内部都跑 LLM 嵌入和摘要。0% 可见。
修复：包 mem0_call(...) wrapper，记 estimated tokens（mem0 不返回真实计数，按字符数 / 4 估算）。
P1：auto_memory.py:61 — call_llm_simple 未埋点
长期记忆压缩用了 call_llm_simple——和 call_with_fallback 不同的是前者根本没走 tracker。grep 一查，仓库里还有 11 处用 call_llm_simple 的。
修复：把 call_llm_simple 自身改成走 tracker，不再做"快路径"——透明度优先于 5ms 的开销。
一个观察
每个黑洞被发现的方式都不一样：
| 怎么发现 | 黑洞 |
|---|---|
| 工程师改代码顺便看到 | summarize_workflow |
| 月底对账偏差查到 | extract_contacts |
| 团队成员重构 router 时质疑 | probe_down_models |
| 文档审计 | Mem0 |
| 历史 PR 反向追溯 | call_llm_simple |
没有任何一个是系统主动告诉我们的。
这周我们让派宝的 meta-agent 跑了一个 FailurePatternDigest——每小时聚类一次错误模式 → 写 SystemSetting → 下个迭代会进入 LLM 提示词改进环。让平台自己告诉我们哪里在烧钱，比工程师每月手动盘点靠谱得多。
LLM 成本失控不是因为模型贵——是因为你看不见自己在调用它。
每周一篇这种内容，由派宝的 meta-agent 从真实平台信号产出。