一个真实案例：我们如何用 Token 配置让 LLM 系统稳定跑起来

一句话结论：
如果你的 LLM 会被连续使用，
token 问题迟早会从「成本问题」变成「稳定性问题」。

这不是一篇讲“怎么省 token”的文章，
而是一份关于 系统如何避免被 token 拖死的工程复盘。

你大概率已经遇到过这个问题

如果你在跑的不是 demo，而是一个真实系统，你应该见过这些情况：

• 对话越长，模型越容易忘记最早的关键约束
• response 越来越慢，token 花得越来越多
• 最后只能靠人手动清上下文，或者直接重开 session

这些都不是模型不行。
而是系统在假设一件错误的事：

“上下文可以无限堆。”

不能。

我们先改了一个假设

在开始调任何参数之前，我们先统一了一个前提：

Context 不是聊天记录，而是稀缺的系统资源。

像内存一样，用完就会出事。

一旦你接受这个前提，解决思路会非常清晰。

直觉级解决思路（不看配置也能懂）

我们只做了三件事：

防止无限膨胀 → 永远留安全余量 → 给系统介入节奏

换成人话就是：

1. 一定要有兜底机制
2. 不能把 token 用到刚刚好
3. 清理要有节奏，而不是等炸

如果你理解到这里，已经理解了 80%。

完整、可运行的真实配置（只出现一次）

✅ 下面这段是 完整、可运行的真实配置
✅ 你可以直接 copy 使用
✅ 后面只解释“为什么存在”，不再拆 JSON

{
  "agents": {
    "defaults": {
      "contextPruning": {
        "mode": "cache-ttl",
        "ttl": "5m",
        "softTrimRatio": 0.3,
        "hardClearRatio": 0.5
      },
      "compaction": {
        "mode": "safeguard",
        "reserveTokensFloor": 20000,
        "memoryFlush": {
          "enabled": true
        }
      },
      "heartbeat": {
        "every": "55m"
      }
    }
  }
}

如果你现在只想“用”，到这里就可以停了。

如果没有 contextPruning，会发生什么？

不谈字段，谈结果。

没有兜底机制，系统一定会走到这一步：

• context 越堆越长
• 有效信息比例持续下降
• 最终一次请求直接爆 context

所以在我们的系统里：

contextPruning 不是智能优化，而是强制止血。

它的定位，和操作系统里的 OOM killer 一样：
不优雅，但救命。

你只要记住这一句。

compaction 解决的不是“现在”，而是“下一步”

另一个常见错误是：

“这一步还能跑，那就继续用。”

问题是：
你永远不知道下一步会不会是一个大请求。

所以我们强制要求：

• 永远预留一块 token 空间
• 必要时可以丢掉运行态记忆

原则只有一句话：

宁可忘掉过程，也不要卡死系统。

heartbeat 的作用，其实很简单

heartbeat 不是提醒人，
而是提醒系统：

• 现在是不是该检查一次上下文状态了
• 是否应该提前介入，而不是等爆炸

它的意义是 平滑处理，不是控制。

一个真实运行中的状态变化

在真实使用中，系统大致是这样跑的：

1. 初期：context 自然增长，不做干预
2. 中期：系统只保留决策和约束，释放推理过程
3. 接近水位：先温和裁剪，必要时强制止血
4. 进入下一阶段：仍然有足够 token 处理新任务

整个过程不需要人盯。

最后一句话

这套配置不是“最佳配置”，
也不是为了炫技。

它只做了一件事：

让系统在真实、混乱、长时间使用的情况下，还能稳定跑下去。

如果你做的是一个真的会被人用的系统，
token 管理不是可选项，是迟早要补的系统工程。

喜欢这篇文章？
🐦 点击这里一键分享到 X (Twitter)