今天,OpenAI 把 GPT-5.5 从 ChatGPT 和 Codex 里下线了,API 里它照常活着。同一天,我看到一条 GitHub issue:某个编码工具在你打开会话的那一刻,往机器上装了一个常驻后台,它会自己下载新版本、自己在后台重启。
我把这两件事放在一起看了很久。它们说的是同一件事。
会自己更新的东西,必须有能被关掉的开关。关不掉,就别让它进生产链路。
那条 issue 里的细节很扎实:自 0.157.0 起,只要开一次交互式会话,CLI 就会启动一个常驻后台,把约 374 MB 的平台包复制进用户目录,从此后端版本和你用包管理器装的 CLI 版本解耦;一个独立更新器在启动 5 分钟后检查更新,之后每小时一次,下载新版本并重启后端,正在跑的任务可能被强杀;更隐蔽的是,它会保留第一个启动会话的代理变量,后面所有会话的出站连接都走那一个出口。
这不是一串 bug,是一个设计选择的后果:后端的生命周期,不由调用它的人决定。
我做老系统改造这些年,有一条从来没破过的规矩:不能停机的东西,它的每一次变更都必须能被我看到、能被回滚预案接住。这条规矩在 AI 工具链上被默认丢掉了。原因也很简单,我们把它当「工具」而不是当「依赖」。
你把它当工具,它把自己当依赖。
工具会自己更新这件事,听起来像贴心,实际是把版本控制权从你手里挪走了。
日志里看不出来。任务失败的时候,你查的是自己的代码,不是那个半夜换过版本的后台。
同一天还有另一条。一个开源 agent 平台发版,修的三条全是同一类:修复工具在读取认证文件失败时,把还能用的配置删了;遇到畸形编码的记忆文件,用替换字符重写了一遍;被安全检查拦下的插件,enabled 状态被直接剥掉。
我读到这里的时候是有点后背发凉的。因为这一类缺陷的根因都一样:工具为了「修好」,牺牲了「不破坏」。
我在电力项目里见过太多次同样的动作。运维脚本跑在异常分支上,为了「清理干净」把唯一还完整的那份数据删了。后来我们把一条写进规范:读不懂的输入,就保留原样并退出,不许猜测,不许重建。
修复工具不是安全区。它和 agent 一样,有写入权限,也有自作主张的能力。
还有一个细节值得记:执行停止命令,只停了主进程,更新器还活着,得手动杀。
你以为关掉了,其实没关掉。
顺带说一句,今年我已经第三次遇到「验收物被改」这件事了。上一次是 agent 改校验脚本,这一次是修复工具改被修复的对象。
同一个病,换了件衣服。
一、核对「安装的」和「运行的」是不是同一个。 对你机器上每个本地 agent 命令行工具跑一次版本比对,顺手看看用户目录下有没有那种自管理的包目录。有,就纳入备份和审计范围。这一步不花预算。
二、在 CI 里显式关掉自更新和常驻后端。 无人值守的流水线必须跑在你锁定的版本上。多数工具都有对应的开关或启动参数,没有的话就在容器镜像里把版本钉死。
三、把模型名从脚本里收口到一处配置。 今天下线的那个模型,在定时任务和脚本里是静默失败的,没有界面,没有人看见。顺带提醒一句:产品侧下线而 API 侧保留,这种一半一半的退役最容易骗人。
我今年最大的一个认知变化,是慢慢不再盯着模型看,开始盯着那些不会变的东西看:边界、版本、回滚点、谁有权改。
模型三个月换一代,这几样十年不换。
你锁不住模型,但你必须锁得住跑模型的那个东西。