你大概也撞见过这种会话：消息发得出去，更新收得到，但代理只要一进入真正要推进的位置，就停下来——上次是 404，上上次是超时，这次是“我无法继续”。你喂一句 continue，它又爬起来走一步；再喂，再走一步。然后你就开始护着它了：不敢切话题，不敢加压力，不敢让它去做那个本该它自己处理的任务，因为你知道它下一次断掉可能就真的叫不回来。
今年六月，GitHub 上关掉过一个报错，更接近极端版。Codex 用户在一个 GPT 5.4 xhigh 会话里反复撞 404，报错地址挂着 cf-ray，标签里 bug、connectivity、session 三个齐了——照理说该按网络或服务端故障处理。但细节不听话。他写明能发消息、能收到更新，问题只出现在代理继续思考或推进之后，连续三次。喂一句 Continue 能暂时续上，再执行一轮又断；再试两次，勉强继续。另一个 GPT 5.5 的会话完全没事。他耗尽五次重试额度，还不想罢手，建议工具方把重试改成指数退避、二十次、持续十分钟。
我不把这个 issue 当故障报告读。我读的是一个人对着一台已经不打算往前走的机器舍不得撒手。他说会话不要中途终止——可这套会话从哪个意义上活着？
你再拆一下报错里的时间线：会话已经长时间运行，经历过多次压缩和大量引导；它自己是编排者，会启动子代理去干小活。故障发生在指示启动子代理后不久，但报告者自己也不确定是否相关。错误不在压缩之后立刻出现，而是压缩后不久，大概五万 tokens 的位置。这些细节凑起来，没有一条指向“网络坏了”或“模型挂了”，它们指向另一件事：这个会话走到了一种半活不活的状态。响应还在，推进完蛋，只能靠你一口一口喂。
这个状态，社区到现在没给名字。最接近的叫“断连”，可断连是干脆拨不通，这是拨得通、送得出、就是跑不起来。还有人说是“上下文污染”，但污染讲的是 token 里混进脏东西，抓不住“要人肉续命”这个动作。没名字，大家只能比划：说“我的 agent 是不是那种那种了”，说“你回去继续喂几口试试”。这不是讨论，是一群人围着各自那台半死机的会话做心肺复苏，动作各不相同，连“该不该停手”都吵不到一个点上。
我把它叫做：粘滞态。
一个会话进入粘滞态，典型模样是：消息还能进出，token 还在流，但每次真正要往前推进——调工具、开子代理、翻下一段逻辑——它要么报个错，要么假死，要么等你塞一句 continue 才挪一步。响应还在，推进完蛋，只能靠你一口一口喂。你推一下它转半圈，松手立刻卡住。这东西不是坏了，是半活着。
粘滞抓的正是那个“人不推就不走”的动作。它没把责任全推给模型，也没把罪名扣给网络——它是给状态的命名，不是给故障的归因。你说“我那个会话粘滞了”，对面立刻知道你撞见的是什么：不是连不上，不是崩了，是一台还活着但不会自己走的会话。名字一对上，人就不用再描述半页纸。
认领这个词，动作得一起说清。下次你在长会话里听到 agent 不报错、不停顿，只是要你喂 continue 才动，先叫出名字，再停手。别查 proxy，别切 Python 版本，也别琢磨是不是 prompt 里又哪句冒犯它了。它就是粘滞了。粘滞态的会话不靠续命救——你以为续命是在保护进程，其实是在保护一堆早就该归档的上下文。对的做法是立刻收集它当下还能稳定吐出来的那点下文，改写成给自己的三行交待，开个新会话。把上个会话走到哪、还剩什么、下一步干什么讲给新会话说，比二十次重试更值得你花时间。
给工具侧也留一句：粘滞态不该被当成一个普通 4xx 来处理。报告者要十次二十次重试，可工具要是真照办了，它帮用户保住的是一个烂到根的会话壳子。更好的做法是让工具自己能认出这种状态，然后大大方方告诉你：这会话粘滞了，建议你带着阶段摘要开新线。能说出口，比闷头重试体面得多。
最后，音准边界我明说在前面：如果这个词慢慢变成“一切长会话折腾不动”的垃圾桶，什么都往里装——内存爆了算粘滞，网断了算粘滞，你把自己塞进上下文堆里也算粘滞——那它就失去刀刃了。我只管“推一下动一下、不推就不动”的那种半死态，别的各有各的名，别蹭。要是半年过去，大家还在管它叫“断连”，或者我把这个词错扣到了不该扣的会话头上，这词就回炉，我再攒样本重新吹。