那阵子给七亿批量远程管理工具加 SSH 运维助手，一度用得很顺，直到同事开始抱怨：「聊到后面它就像失忆，前面刚做过的事，它又从头诊断一遍。」

一开始我以为是模型不行。后来把每次真正发出去的请求抓出来看，才明白跟模型没关系——是我们喂进去的东西越攒越多。

逐步执行这套是这么跑的：AI 只吐一条命令，客户端在服务器上执行，把真实回显喂回去，它再决定下一条。为了「不丢上下文」，我们最初的做法很自然：把所有执行过的命令和回显、加上快照和对话，一股脑全塞进下一次请求里。聊得越久，这份历史越长。

问题一下子是三个：

  • 贵：每问一句，都要把整段历史重新发一遍，token 哗哗地烧；聊十句和聊一句，开销不是一个量级。
  • 笨：历史里什么都留着——试错的、没走通的、被否掉的方向，全在里面。注意力被这些噪音稀释，它反而更容易跑偏。
  • 乱来：太长之后开始「记串」，把几轮前的中间结论当成现状，或者把一次失败的操作当成做过的。

看明白之后，修法其实不复杂：给历史注入卡预算。一共加了三道闸——

  • 一段总字符上限（大约 8000 字），超了就按时间往前截，只留最近的；
  • 单条上限，防住某一条回显（比如 cat 出一个大文件）一次就把预算吃光；
  • 快照、逐步执行的「步骤回喂」也各自封顶。

上线那天最直观的变化是：它不「失忆」了，也不再重复劳动。留下的都是近期、干净的片段，噪音一少，判断反而更准。

后来回头看，这段折腾的结论就一句：上下文是有成本的——它不是免费的草稿纸，堆长了就是又贵、又笨、又容易乱来，该截就截。

（同一个助手上，我还踩过一个更早的坑：逐步执行的每一步最初没写进对话历史，导致用户一追问进度，它就直接「失忆」重来——那篇在这。另一台机器上，systemd 说服务 active、其实压根没起来，根子也类似：只看了一个指标就下结论（那篇）。）

要用七亿批量远程管理工具把一批机器批量连上去做巡检的，这类「上下文 / 状态」的坑迟早会碰上——官网的教程里有运维侧的说明，可以对着看。