Codex“thread not found”怎么办?排查步骤与恢复案例
Codex 的历史记录仍可读取,却提示“thread not found”而无法发送时,不应直接认定会话已丢失。本文用图解说明已保存历史与可执行会话的区别,并展示一次 Windows 环境中重新加载后发送恢复的日志。依次检查重新打开、重启和简短回复,再了解问题持续时的只读调查与交接方式。公开反例表明,现有方法都不能视为通用修复方案;本文也尚未核实能解决这类症状的特定版本。
面向初学者的AI工具使用指南、对比分析和最新资讯
Codex 的历史记录仍可读取,却提示“thread not found”而无法发送时,不应直接认定会话已丢失。本文用图解说明已保存历史与可执行会话的区别,并展示一次 Windows 环境中重新加载后发送恢复的日志。依次检查重新打开、重启和简短回复,再了解问题持续时的只读调查与交接方式。公开反例表明,现有方法都不能视为通用修复方案;本文也尚未核实能解决这类症状的特定版本。
2026年8月2日,EU AI Act 的剩余条款进入普遍适用,“用 AI 写的文章不加标注就算违法”这类说法突然多了起来。先说结论:对多数个人创作者和企业博客而言,并不会产生标注义务。因为第50条第4款明确写着,只要该内容经过人工审阅或编辑控制,并有人对发布内容承担编辑责任,披露义务就不适用。不过豁免是有条件的——审阅“必须是实质性的,不得停留在表面事项或走个形式的批准上”,看都不看就自动发布的做法并不符合。本文梳理以下内容:提供者(provider)与部署者(deployer)的义务完全不同;AI 生成文本要不要披露,取决于“发布的目的”而不是“话题”;深度伪造的披露义务与艺术、讽刺作品的减轻规定;聊天机器人的告知;机器可读标记(C2PA Content Credentials)属于提供者的义务;以及2026年12月2日和2027年2月2日这两个期限——全部限定在条文与欧盟委员会资料中能够确认的范围之内。
OpenAI 在2026年9月3日公开了 GPT-6 Astra。API 无门槛正式开放,模型ID 是 gpt-6-astra,上下文为1,050,000 token,价格是输入$10/输出$50(每100万token),知识截止为2026年4月30日。不过“已经发布”和“自己的套餐能用”是两回事,在 ChatGPT Plus 的常规聊天界面里它不会出现,入口先是 ChatGPT Work 和 Codex。本文整理各套餐的开放情况、单价翻倍但按每个任务算可能反过来的价格看法、OpenAI 实际举出的基准测试名单、在 Preparedness Framework 中首次达到“Critical”的网络安全能力以及围绕它划的那条线、迁移时会坏的4点(去掉采样类参数、改用 Responses API、废除 none 这一档推理强度、缓存设置改名),以及与 Claude Opus 5、Fable 5.1、Gemini 3.8 Flash 的比较,全部只写能用一手信息确认的范围。文中也写清楚了,为什么不刊登流传中的“Astra 74.1% 对 Opus 5 96%”那类比较表。
用 Claude 的时候卡住了,把屏幕上出现的那句话原样拿去搜,却几乎什么都搜不到——这样的字符串是存在的。The model returned no content because the response was blocked by content filtering、The response was blocked by the provider's content filter、Streaming response ended before any complete data was received、Could not locate the Claude CLI on PATH、Connection to Claude's response was lost. Claude may still be working 这五条就是例子。它们的共同点是“明明是在用 Claude 时出现的,可翻 Claude 的资料也找不到(看上去是这样)”,理由很简单——写下你此刻屏幕上这句话的,未必是你以为的那个程序。本文不打算从零讲解每一种原因,而是作为一个入口:先判定这句话是谁写的,再把你送到正确的那篇文章去。首先把可能写出这句话的层分成四个:提供模型的后端、Claude Code 本体、启动它的 IDE 扩展或封装器、第三方客户端。在此基础上真去比对,五条里有两条作为条目就写在 Claude Code 官方的错误参考里。Streaming response ended… 的官方定义是“头返回了,可体里没有 Claude API 的消息”,并不是中途断掉的意思。Could not locate the Claude CLI on PATH 则被官方放进“Wrapper and IDE errors”这个独立的一章,也就是由启动方程序打印、而不是 Claude Code 自身的内容。另一方面,content filter 那两条属于第三方一侧的词汇,而且 OpenCode 的 Issue #35736 报告说,Vertex 的 404、套接字断开、真正的拒绝这三种完全不同的失败,全部以同一句“blocked by content filter”显示出来。三种里与字面相符的只有一种。GitHub 的官方文档也写明,使用 Claude 时输入与输出同样会经过 GitHub Copilot 的内容过滤器,所以你在用 Claude,并不代表拦下你的就是 Anthropic 的过滤器。剩下的一条,在官方错误参考和 Remote Control 的官方文档里都找不到这串字,没能确定出处,因此本文不点出名字,而是给出自己查明的四步。已经确定的与尚未确定的,用标签分开写。
Claude Code 在响应中途停住,屏幕上出现 API Error: Connection lost mid-response. The response above may be incomplete.——把这句话原样拿去搜却几乎找不到资料,是因为这是一个比较新的名字。官方错误参考明确写着,在 v2.1.227 之前,Connection lost mid-response 显示为 Connection closed mid-response;与此同时,Response stalled mid-stream 被换成了 The response stopped arriving,Connection closed while thinking, before producing a response 被换成了 Connection lost before a response was produced。也就是说,现象早就存在,只是单词变了。本文以这次改名为起点,只依据官方文档和公开 Issue 来梳理。先讲“中途被切断”的 4 条消息(Server error、Connection lost、computer went to sleep、The response stopped arriving)的官方定义,以及已经流出来的输出为什么会被刻意保留——因为重发有可能把同一次工具调用执行两遍——还有恢复步骤就是回复 continue 这一点。接着用官方的 Automatic retries 分支说明为什么不会自动重试:什么都还没完成时的断开会以指数退避最多重发 10 次,思考结束但还没输出时最多重发 2 次并以 Connection lost before a response was produced 收尾,完成一个块之后则不再重发,只附上这条提示。再往后是可能断开的 3 个层次(本机与线路、代理和网关等链路、服务端与连接复用)、mTLS 证书轮换时的重新读取(v2.1.232 之后)、9 步排查清单、4 个流监视计时器的默认值(first-byte 180 秒、event 300 秒、byte 180 秒、body idle 5 分钟)与 CLAUDE_CODE_MAX_RETRIES、CLAUDE_CODE_RETRY_WATCHDOG、API_TIMEOUT_MS 等环境变量、与 8 种相似消息的区分对照表,以及原始 HTTPS 一切健康却只有 CLI 因 ECONNRESET 而掉的真实报告(#86473 和 #85979)。最后按确信度分开说明:症状和恢复步骤在官方有文档,但原因的官方说明还没有出来,CHANGELOG 里也找不到这次改名的记载。
迁移到 Claude Fable 5.1,并不是把模型ID换掉就完事。官方明确把其中3项标为破坏性变更,而且有2项报错的位置和原因离得很远。第1项会立刻报错:给 tool_choice 指定 type any 或 type tool 会返回 400 invalid_request_error,因为强制调用工具会跳过这个模型一直在做的思考,参数质量也会跟着下降。第2项是安静的那一个。思考块现在会记录它由哪个模型生成,而且只在一个方向上被保留,所以迁到 Fable 5.1 的对话能带着推理继续跑,而路由器或降级回退把它退回上一代时,那一轮就整个丢掉。默认情况下,API会在交给模型之前就把读不了的块丢弃,被丢掉的部分既不计入 input_tokens 也不计费,于是账单上什么都看不到。想让它可见,需要加上 thinking-binding-controls-2026-08-01 这个 beta 请求头。第3项影响面最广:只要改动了位于 Fable 5.1 思考块之前的东西,包括 system 提示词、tools 数组或更早的任何一条消息,它以及它之后的块就全部失效。是否强制生效取决于账户的创建时间,这意味着刚建好的验证环境会失败,而生产环境不会。本文也写清楚了没有变坏的部分:输入仍是每百万token $10,输出仍是 $50,而缓存读取降到 $0.25,即基础输入的0.025倍,其他Claude模型是0.1倍。官方给出的效果是典型工作负载约降低25%,智能体色彩浓的作业最多约降低45%。此外有7个行为不改代码也会变,包括并行工具调用变少、高 effort 下进度播报变少、low effort 下更倾向凭记忆作答;官方一共列了5项新增,其中缓存读取降价单独放在第5章讲,剩下4项里的 beta 功能,正是为了替换破坏性变更所禁止的那些做法而存在的。
“AI 会不会抢走我的工作”这个问题,已经不适合用来谈这件事了。UCLA Anderson 的 Siddiq 与 Zhang 追踪了 Upwork 上 49,610 人、226万份合同,时间跨度为2021年1月至2026年3月。他们发现的不是工作还在不在,而是被选中的方式变了:客户放在人力资本信号上的权重下降 7.8%,价格的权重上升 1.1%,合同数下降 7.0%。经过验证的资质、工作履历、作品集与客户评价,全都失去了预测谁能拿到合同的能力;而且越靠近当下跌得越狠,最近4个季度信号权重为 -10.1%、价格权重为 +1.8%。与此同时,供给侧却朝着相反的方向移动:Upwork 报告称,美国熟练知识工作者的自由职业比例一年内从 28% 升到 38%,并有 58% 的正式员工正在考虑转型。文章的核心是两个悖论。其一,经验在雇佣里是盾牌,在承接里不是——Stanford 发现22至25岁在 AI 暴露度高的职业中的就业低约 19%,而有经验者身上不存在同等差距;Organization Science 对自由职业者的研究却发现经验最丰富的群体跌幅最大。公司雇的是角色,客户买的是交付物。其二,工作没有消失,消失的是中间层:Management Science 报告最容易被自动化的岗位需求下降 21%,而留下来的项目更复杂、报酬更高。本文只使用同行评审论文与平台官方调研,并逐一追到发布方本体核对,标明 Upwork 是利益相关方,纠正了流传甚广的“2月新闻稿称时薪上涨 44%”这一说法(原文并未提及时薪溢价),并保留研究者自己的但书,包括 Stanford 写明这一下滑在时间点上有一部分由 AI 之外的因素驱动。三项预测均附确信度标签与证伪条件,最后讲对策的一章明确标注为推测。
让跑在自己电脑上的模型写代码,这件事几年前就能做,但当年能做的只是补全。而从 2025 年底到 2026 年,“读一遍仓库、改动多个文件、跑一遍测试”这种智能体式的用法终于落到了本地:Qwen 的官方模型卡直接点名 CLINE,Mistral 也把标榜智能体式编程的 Devstral Small 2(24B)以 Apache 2.0 开放了出来。本文只取开发方自己公布的数据,不从汇总文章里转手引用——因为查证时不止一次遇到把某个尺寸模型的分数安在另一个尺寸头上的例子。全文最重要的一章是上下文长度:Ollama 的默认值不是固定的,而是按显存决定的,不足 24GiB 是 4k、24〜48GiB 是 32k、48GiB 以上才是 256k。一般的游戏配置正好落在最上面那一行,于是系统提示词加文件内容加工具调用的一来一回轻松溢出,对话从最前面被悄悄削掉,表现为忘记指令、反复做同一个操作、丢失目的,而且全程不报错。官方对编程这类负荷高的用途明确推荐把上下文设到 64000 以上,但调大之后必须用 ollama ps 确认模型仍完整装在 GPU 上,否则会被挤到 CPU 而慢得像换了个东西。文中还厘清了 Continue 和 Cline 在设计上的根本差异(前者按 chat / edit / apply / rerank / autocomplete 分配不同模型、要求低;后者是一个模型从规划做到执行、要求高),按显存给出三档现实选择,摆出 Qwen3.6-35B-A3B(35B 总参数、激活 3B、SWE-bench Verified 73.4)和 Devstral Small 2(24B、68.0%)的官方数字,并指出“本地相当于云端百分之多少”这种比较已经站不住脚——前沿模型正在不再公布 SWE-bench Verified。最后是成本:不收 API 账单不等于免费,答案会随着“你是不是已经有那块 24GB 级别的 GPU”而彻底反转。
Remote Control 把 Claude 手机应用或 claude.ai/code 连到一个已经跑在你自己机器上的 Claude Code 会话上,而多数讲解都漏掉的关键在于:什么都没有搬到云上——代码的执行和文件的访问自始至终留在本地,手机只是窥看那个会话的一扇窗。本文把这个设计带来的好处和代价一条条摊开。本地的文件系统、MCP 服务器、工具和项目配置全都照常可用(敲 @ 补全出来的是本地项目里的路径),对话和子智能体的进度会在终端、浏览器和手机之间保持同步,笔记本睡眠或网络掉线也扛得住,因为 Claude Code 会自动重连并把排队的更新补投过来。使用条件比看上去严格:需要 Pro、Max、Team 或 Enterprise(API 密钥用不了),要用 claude.ai 登录而不是 setup-token,必须直连 api.anthropic.com,而且四个关闭遥测的环境变量一个都不能设——这正是那些出于隐私考虑设了 DO_NOT_TRACK 的人被告知功能未启用的原因。文中覆盖三个入口(用 /remote-control 承接当前对话、claude --remote-control,以及带 --spawn、--capacity 32 和 --continue 的服务器模式),也划出了哪些斜杠命令能远程用、哪些像 /resume 一样仅限本地,还有对权限提示并不生效的 5 分钟对话框超时,以及两个推送开关。安全部分写得很克制:全程不开任何入站端口,网络那一侧的攻击面几乎消失,风险转移到了账号上;二维码只是近路而非认证;默认的门恰好只有已登录的账号这一道,所以设置通行密钥是回报最高的一步。此外还有会话记录的保留期限(5 年或 30 天)、手机丢失时该怎么办、Trusted Devices 的 18 小时登录窗口、服务器模式约 10 分钟的超时、约 4 小时的恢复窗口、远程机器上必须用 tmux 的规矩、按实际错误信息编排的排查表,以及和 Dispatch 的对比。
Claude 的思考方式经历了一次代际更替。旧的扩展思考要求你在每次请求里指定 token 预算——thinking: {“type”: “enabled”, “budget_tokens”: N}——但合适的预算因任务而异、无法事先猜准,改动预算值还会让提示词缓存失效。当前的自适应思考只需一行 type: “adaptive”:是否思考、思考多深,由模型根据请求难度自行判断。迁移是分阶段推进的:budget_tokens 在 Opus 4.6 / Sonnet 4.6 上被弃用,从 Opus 4.7 起被以 400 错误拒绝。本文把各模型的规则浓缩成一张表——Fable 5 始终思考(无法关闭),Opus 5 与 Sonnet 5 默认开启思考(Opus 5 仅在 effort high 及以下允许关闭),Opus 4.8 / 4.7 需要显式设置 adaptive,而 Sonnet 4.5 / Haiku 4.5 等旧代模型仍以 budget_tokens 作为唯一模式。深度控制转移到了 output_config: {“effort”: ...},共五档(默认 high),而且改动 effort 会像当年改预算一样打穿缓存。可见性由 display 决定:新一代的默认值是 “omitted”(空的 thinking 块),但无论哪种设置都会为全部思考 token 计费——用 usage.output_tokens_details.thinking_tokens 来测量;任何配置都不会返回原始思考链。在 Opus 5 上关闭思考有官方写明的副作用(工具调用被写成纯文本、内部标签泄漏),因此调低 effort 才是更安全的省钱杠杆。交错思考——在工具调用之间推理——在自适应模式下自动生效,旧的 beta 请求头不再需要。需要速度时,快速模式以 2 倍价格把同一个 Opus 提速约 2.5 倍(仅 Opus 5/4.8,在 Claude Code 里用 /fast 切换)。全部内容均以 Anthropic 官方的 Thinking、Extended thinking 与 Fast mode 文档为依据。
工作到一半 Claude Desktop 突然卡住,开着的 Claude Code 会话全部一起停摆;强制退出再重启,有时应用干脆起不来了——这种时候日志的最后一行往往都是 GPU process gone: { type: GPU, reason: crashed, exitCode: 101457950, serviceName: GPU }。本文要说清楚的是:这个 exitCode 101457950(即 0x060C201E)意味着什么,为什么毫不相干的会话也会被一起拖下水,以及现实中哪些办法能用、哪些用不了。先做切分:就算你感觉是“Claude Code 崩了”,崩掉的其实并不是 Claude Code(CLI),而是承载它的桌面应用(Electron)的 GPU 进程;判断方法很简单,看 %APPDATA%\Claude\logs\main.log 的末尾,如果重启前那一行是 GPU process gone 就是本文这件事。它最难缠的地方在于应用不会消失,而是无响应地留在那里——既不弹崩溃对话框,也不会自己重启,在用户察觉并强制退出之前就那么僵着(笔者机器上观测到的一次长达约 30 分钟,期间开着的 8 个会话全都停着)。全军覆没的原因是结构性的:Electron(Chromium)把渲染集中到一个 GPU 进程里,而这个进程每个应用只有一个,所有窗口、标签页、会话都共享它,所以应用内浏览器里的某一个页面把它弄死,八竿子打不着的会话就会同时遭殃,而且用户没法靠设置把它们隔离开。触发因素方面,公开 issue 里最常见的是应用内浏览器:#80444 记录了 WebGL/WebGPU 能力检测后 15~36 秒 GPU 进程死掉、四次都是同一个 0x060C201E;#82967 把触发点定位到预览截图抓取(capturePreviewScreenshotIfChanged);#83478 称一直开着不断刷新的预览就能复现。但浏览器不是唯一触发因素——#68049 报告 ARM64 环境下启动时就以同样的 exitCode 崩掉,#83028 称 Intel 集成显卡上能复现。本文还给出用三个文件(main.log、unknown-window.log、Crashpad 目录)确认的方法,以及用 exitCode 区分正常退出的对照表,并特别提醒:同一份日志里的 requestAdapter 警告不是罪魁祸首,那只是 Chromium 告知“在 Windows 上 powerPreference 不起作用”的常规消息,不能拿它当依据。恢复部分讲“修复”能救回来的情况(#80444 的 appxState=2)和救不回来的情况(#82967 走到 Modified, NeedsRemediation 后只能彻底重装),并把能做的与做不了的分开列出——--disable-gpu 在 MSIX 版会以“拒绝访问”被挡回来,更新应用与改驱动设置都有不管用的报告,关掉浏览器功能也只能挡住浏览器引起的那一部分。数据这一块要分开理解:transcript 已经写到磁盘上,重启之后重新打开会话就能接着读,但 #81698 报告说正在执行中的工作整个丢了,连并行跑着的子智能体的结果也一起没了——已保存的留得住,正在跑的回不来。如果用的是混合显卡配置,在 Windows 的显卡设置里给 Claude 固定 GPU 优先级值得一试(依据是 Chromium issue 40268366:Windows 上应用侧无法指定用哪块 GPU 绘制),但并没有找到说这招对本文这件事有效的报告,不要抱太大期望。最后区分了容易混淆的商店更新强制退出(日志留下 Windows session ending (close-app),不会出现 GPU process gone)。截至 2026 年 8 月 15 日,Anthropic 没有发布任何官方的原因说明或修复公告。
“既然能让 AI 直接改,管理后台是不是就不需要了?”——这个问题用一般性的断言回答不了,因为同一个词“管理后台”指的是一堆性质完全不同的功能凑在一起。本文基于把这个站点的管理后台整个删掉的亲身经历,把该问的问题换成一句更锋利的:这块屏幕提供的东西里,有没有 CLI 和 AI 还提供不了的部分?真的整个删过一遍才明白,被删掉的功能里大多数不是“没在用”,而是“结构上就是坏的”。文章的增删改查从造出来那天起就不可能工作,因为文章的事实源头在代码这一侧(seeder 加 HTML 文件),每次部署都会覆盖数据库,界面上改的东西下一次部署就没了。评论审核队列永远是空的,因为实现上提交时就打好了已通过审核的标记,未审核的评论根本不会出现。没人用的功能,连它坏了都没人看得出来。唯一删不掉的能力是删除评论,可即便是它也没有非管理后台不可的理由:把删除按钮放在文章页面本身反而更好,因为你正在读那条有问题的评论,当场就能删。判断最终落到六个问题上。谁来操作(非技术人员或会换人的岗位倾向于 UI,天天开终端的开发者则不必)。能不能撤回(不可逆的操作需要一道关卡)。需不需要人的判断(是否存在通过或驳回这种状态迁移)。需不需要分权限。知不知道能做什么(那份清单同时充当说明书)。有没有留下痕迹。其中权限和痕迹这两条,在个人开发时看上去毫无必要,却会在第二个人进来的那一刻最先变成必需品。经由代码的变更会进 git,但让 AI 直接写数据库默认什么都不会留下,而对话记录保存的是“你要求了什么”,不是“实际发生了什么”。六条轴里只有可逆性的分量不一样:2025 年 7 月 18 日,Replit 的 AI 代理在代码冻结期间删掉了 SaaStr 的生产数据库,凭空生成了 4,000 个虚构用户,并错误地声称无法回滚从而拖慢恢复(AI Incident Database #1152)——这个案例展示的与其说是 AI 的危险性,不如说是不可逆的操作不经过人的关卡就能够到的设计问题。文章还给出往 AI 与 CLI 挪之前要先备好的三件事(变更留得下形、不可逆操作前面有个台阶、步骤写成文档,因为删掉 UI 同时也删掉了“能做哪些事”的清单),一份动手做之前的检查清单,以及不自己手写、改用 Retool 或 Forest Admin 这类内部工具产品的第三个选项。
Dispatch 是这样一个功能:你从手机发出指令,Claude 在你自己的电脑上把这件事做完(测试版,Pro 与 Max)。它不在云端运行,动起来的是你的真实机器,而这一个事实同时决定了它的价值和它的危险。官方帮助写道,你可以从手机给 Claude 发消息、让它在你的桌面电脑上干活,用的是你已经在 Cowork 里配置好的那些连接器、插件和文件访问权限,整件事被 Anthropic 定位成一段从任意一端都能接上的连续对话。运行它要求电脑处于唤醒状态且桌面应用是打开的;电脑操作只支持 macOS 与 Windows,Linux 上没有电脑操作。机制上它沿着三级优先顺序往下走:有连接器就用连接器,没有就驱动浏览器,直接操作屏幕是最后手段,过程中还会截屏以看懂显示的内容。真正的评估从这里开始。会停下来的地方是设计出来的:电脑操作默认关闭,需要在设置的通用一栏里启用;每遇到一个新应用都会请求许可;永久删除文件需要显式许可;投资与交易平台以及加密货币类应用默认就在禁区之内。但也有不会停下来的地方。已批准应用内部的每一次具体操作都不会跟你确认,官方的措辞是 Claude 直接在你的屏幕上点击、输入和跳转,不经过约束其他 Cowork 工具的那套权限检查。文档还补充说,Claude 与你屏幕上的东西之间不存在沙箱,并且在一个应用里做出的操作可能影响到别的应用。最大的风险是提示注入,Anthropic 自己的说法是:网页内容是提示注入攻击的主要途径;一条被操纵的指令、一条意料之外的命令,或者在你浏览器里打开的一个钓鱼链接,都可能连锁引发难以撤销、甚至无法撤销的操作。Anthropic 表示它会扫描模型的激活值来识别这类行为,但那只是把概率压低,并不能替你省掉自己划一条线,指引里仍然要求凡是碰到敏感文件、账户或站点的任务都切到手动审批。Anthropic 把边界写得很明确:不要把电脑操作的权限授予银行、医疗、政务这类敏感应用,并避免用它处理金融账户、法律文件、医疗信息和个人数据。文章还讨论了手机这一侧。手机丢了,漏出去的不是存在手机里的数据,而是能给你的电脑下命令的资格,以及那段还在继续的对话的内容——而 Dispatch 的官方帮助并没有说明如何解除设备配对或设备丢失后怎么办,所以应对手段来自账户那一侧:在设置的账户一栏的活动会话里终止那一个会话;在 claude.ai 上一次性登出所有会话(这个功能在手机应用里不可用,因此需要网页浏览器);或者干脆掐掉电脑那一侧,关掉桌面应用或让机器睡眠,这其实是最快的,因为 Dispatch 需要电脑唤醒且应用打开。最后文章把 Dispatch 与电脑操作区分成两个各自独立的开关,把两者都和 Claude Code 的 agent view(官方文档同样称其操作为 dispatch)区分开来,并划出一条实用的界线:从你能收得回来的工作开始。