WIN7 下核对 CPU 核心数，把 Codex 的 Base URL 改到 TaoToken 后读 numberofcores

Win7 下核对 CPU 核心数，最容易被设备管理器骗：处理器一栏明明显示 4 个节点，真实物理核心却可能只有 2 个。这篇文章把核对动作交给 Codex，模型通道走 TaoToken——先在 TaoToken 创建 Key，再把 Base URL 填成 https://taotoken.net/api，之后让 Codex 跑 wmic 读 numberofcores。任务管理器同样会画出 4 个窗口，这些都是逻辑处理器在“刷存在感”；要拿真实数字，得靠 wmic 的 NumberOfCores 字段。TaoToken 不读 CPU 信息，只给 Codex 提供 Key 和通道，真正查询本机 CPU 的仍然是 wmic。

1. 设备管理器显示 4 个节点，为什么不等于 4 核

1.1 双核四线程的“障眼法”

Win7 的「计算机」右键 → 属性 → 设备管理器，展开「处理器」一栏，会看到 4 个节点；按 Ctrl+Shift+Esc 打开任务管理器，性能页里也画着 4 个 CPU 窗口。很多朋友据此判断“这台电脑是四核”，然后给虚拟机分配 4 核，结果发现性能与预期差很远。

问题出在超线程（Hyper-Threading）。一颗物理核心可以同时维护两条线程的上下文，操作系统看到的不是“1 个物理核”，而是“2 个逻辑处理器”。于是双核 CPU 配上超线程，系统就上报 4 个逻辑处理器。设备管理器和任务管理器默认展示的正是逻辑处理器数量，而不是物理核心数。用生活里的例子说，物理核心数是“收银台数量”，逻辑处理器数是“收银窗口数量”：一个收银台可以开两个窗口同时收银，但台子还是那一个。

1.2 哪一行字段才是物理核心数

要区分这两个概念，最直接的办法是查 wmic。在 cmd 里运行：

wmic cpu get NumberOfCores,NumberOfLogicalProcessors

输出会给出两列：

NumberOfCores NumberOfLogicalProcessors 2 4

• NumberOfCores：物理核心数，也就是厂商宣传里的“双核”“四核”里的那个数。
• NumberOfLogicalProcessors：逻辑处理器数，等于物理核心数 × 每核心线程数。

两者相等，说明这台机器没有开超线程；后者约为前者两倍，说明开了超线程。双核四线程的机器，真实核心数就是 2，逻辑处理器数才是 4。

1.3 为什么原文强调不只看任务管理器

网上很多教程只贴任务管理器截图，用户看到 4 个窗口就以为自己买了四核。实际上任务管理器画的是逻辑处理器，它没有撒谎，但也没把物理核心数单独标出来。原文特意教用户打开 wmic 找numberofcores，正是因为设备管理器和任务管理器都做不了“物理/逻辑”这一层区分。

wmic 的cpu get *会输出一大堆字段，CPU 型号、电压、外频、倍频都在里面，新手容易看花眼。所以核对核心数时，只取NumberOfCores和NumberOfLogicalProcessors两个字段就够了，避免被其他信息干扰。

2. 谁读 CPU、谁供通道：Codex 与 TaoToken 的分工

2.1 把执行和解读交给 Codex

wmic 命令本身不复杂，但输出之后还要人脑去判断“哪个字段是物理核心、哪个是逻辑处理器”。对不常接触命令行的朋友来说，这一步仍然容易搞错。把命令交给 Codex 会直接得多：你只问“这台 Win7 的真实核心数是几个”，它会在本机终端执行 wmic，然后把NumberOfCores和NumberOfLogicalProcessors拆开解释。

这里要强调一下链路边界。TaoToken 并不读取 CPU 信息，也不扫描你的机器。它做的事情只有一件：作为统一 API 通道，给 Codex 提供模型 Key 和 Base URL。Codex 收到你的问题后，把请求发到 Base URL 指向的 https://taotoken.net/api，模型回复后 Codex 再决定调用本机哪些命令。读取NumberOfCores的是 wmic，不是 TaoToken，也不是某个云端服务。

2.2 先在 TaoToken 创建 API Key

要让 Codex 能把请求发出去，先得有一把能在 TaoToken 通道上通过校验的 Key。打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 注册账号，进入控制台创建 API Key。这一步对应原文“打开工具、注册登录、拿到密钥”的流程，只是把目标地址换成 TaoToken。

创建时注意：

• API Key 是敏感信息，不要贴到公开仓库或聊天记录里。
• 后续所有配置里，Key 一律用YOUR_API_KEY占位。
• 如果要在多台机器上用同一把 Key，确认它的权限范围足够；如果只在一台旧 Win7 上用，单独建一把 Key 更安全。

2.3 准备材料清单

配置之前先确认下面几项都齐了：

• Win7 或更高版本的机器，能打开 cmd 或 PowerShell。
• 本机已经安装 Codex CLI，并至少运行过一次生成默认配置。
• 一个 TaoToken API Key，从 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 创建。
• 模型 ID，以 TaoToken 模型广场当时列表为准，不要用旧文章、旧截图里的固定名字。

另外要把两个地址区分清楚。给人看的官网是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end ；给 Codex 填的 Base URL 是 https://taotoken.net/api ，末尾不要加/v1。把官网地址当成 API 地址填进去是最常见的配置错误之一。

3. 在 config.toml 里把 Codex 指到 TaoToken

3.1 打开 ~/.codex/config.toml

Codex 的全局配置放在用户目录下的.codex/config.toml。Win7 里通常是：

C:\Users\你的用户名\.codex\config.toml

用记事本打开前，先把原文件备份一份，改成config.toml.bak。如果你的.codex目录还不存在，先随便跑一次codex命令，让它生成默认配置，再执行下一步。

打开后，把默认模型提供方切到 TaoToken，并添加对应的 provider 配置。示例如下：

model_provider = "taotoken" model = "YOUR_MODEL_ID" # 以 TaoToken 模型广场当时列表为准 [model_providers.taotoken] base_url = "https://taotoken.net/api" env_key = "CODEX_API_KEY" wire_api = "chat"

注意，model里的YOUR_MODEL_ID需要替换成模型广场上真实存在的模型 ID。不要自己猜一个 “最新版本号” 填进去，模型 ID 要以 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 的模型广场为准。

3.2 设置 CODEX_API_KEY 环境变量

toml 里的env_key = "CODEX_API_KEY"表示 Codex 会从环境变量CODEX_API_KEY里读取 API Key。所以还要在终端里设置一次环境变量。

cmd 窗口：

set CODEX_API_KEY=YOUR_API_KEY

PowerShell 窗口：

$env:CODEX_API_KEY = "YOUR_API_KEY"

这里YOUR_API_KEY换成你从 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 创建的真实 Key。注意环境变量只在当前终端窗口有效，新开窗口后要重新设置；如果嫌麻烦，可以把set写进系统环境变量，但那样就不如用配置文件来得直观。

3.3 指定模型的两种方式

config.toml里写了model = "YOUR_MODEL_ID"后，Codex 启动时会自动使用这个模型。如果你不想写死在配置文件里，也可以启动时用参数指定：

codex -m YOUR_MODEL_ID "请读取本机 wmic cpu get NumberOfCores,NumberOfLogicalProcessors 的输出"

这里的YOUR_MODEL_ID同样要去模型广场复制。两种方式二选一，都填了时命令行参数优先。

4. 让 Codex 跑 wmic，读 numberofcores

4.1 给 Codex 的指令怎么发

配置保存好、环境变量设好后，启动 Codex 对话，直接输入：

请在本机运行 wmic cpu get NumberOfCores,NumberOfLogicalProcessors，把两个字段的值读出来，并告诉我这台 Win7 的真实物理核心数是多少。

Codex 会调用本机终端执行这条命令。它读取的是本地 CPU 信息，属于只读查询，不修改注册表，不写文件，不影响系统设置。执行前 Codex 通常会展示命令并请求确认，确认后输出类似：

NumberOfCores NumberOfLogicalProcessors 2 4

4.2 让 Codex 解释输出

拿到输出后，继续问一句：

为什么设备管理器显示 4 个处理器，这里却只有 2 个核心？

Codex 会把超线程、逻辑处理器、物理核心的差异解释一遍，并且结合这台 Win7 的实际输出来讲。这样你记住的不只是“这台机器是双核”，还能理解“4 个逻辑处理器是怎么来的”。

真正从硬件里读取NumberOfCores的是 wmic，Codex 只是把命令组装好、执行、再翻译成人话。TaoToken 在这个过程中不接触 CPU 数据，它只负责模型这一环。

4.3 不想让 Codex 直接执行怎么办

如果你不希望 Codex 替你执行本地命令，可以自己在 cmd 里运行：

wmic cpu get NumberOfCores,NumberOfLogicalProcessors

把输出原样贴回 Codex 对话，让它解释。这样 Codex 完全不做命令执行，只做文本分析。两种方式最终得到的结果一样：NumberOfCores是多少，物理核心数就是多少。

5. 三种查看方式对照，wmic 为什么最权威

5.1 设备管理器：看到的是逻辑处理器节点

Win7 的「计算机」→「属性」→「设备管理器」→「处理器」，显示 4 个节点。这个视图来自 Windows 的处理器抽象，它把每个逻辑处理器都列成一个节点。双核四线程显示 4 个，四核八线程显示 8 个，逻辑上永远跟系统能调度的线程数一致。

设备管理器擅长的是看硬件型号、驱动状态，而不是物理核心数。它列出的节点数量，只是“操作系统能看到的处理器图像”，不是制造商标注的核心数。

5.2 任务管理器：同样按逻辑处理器绘图

任务管理器性能页的 CPU 窗口数，也等于逻辑处理器数。某些机器在 BIOS 里关掉超线程后，4 个窗口会变成 2 个，这会让用户误以为“核心变少了”。其实物理核心没变，只是逻辑处理器数量降回去了。

所以任务管理器适合看实时负载，不适合用来回答“这台机器是几核”。

5.3 三张表对比

查看方式	双核四线程显示	实际含义
设备管理器处理器节点	4 个节点	逻辑处理器数
任务管理器 CPU 窗口	4 个窗口	逻辑处理器数
wmicNumberOfCores	2	物理核心数
wmicNumberOfLogicalProcessors	4	逻辑处理器数

设备管理器和任务管理器都没有“说谎”，它们只是没说完整。wmic 的不可替代之处，在于把物理核心数和逻辑处理器数分开列出，这也是原文把numberofcores字段当作关键点的原因。

6. 排障：wmic 不存在、401、模型 ID 对不上

6.1 wmic 不是内部或外部命令

某些精简版 Win7 会移除 wmic。先在 cmd 里单独输入wmic回车，如果提示“不是内部或外部命令”，说明系统里没有这个组件。

处理方法有两种：一是到C:\Windows\System32\wbem\下确认WMIC.exe是否还在，如果只是路径没配好可以手动指定完整路径；二是改用 PowerShell 等价命令：

Get-WmiObject Win32_Processor | Select-Object NumberOfCores, NumberOfLogicalProcessors

这条命令输出同样的字段，Codex 依然能正常解读。排障顺序上，先确认本机命令可用，再怀疑 Codex 配置。

6.2 Codex 报 401 unauthorized

401 通常是 Key 没被 Codex 读到。分三步检查：

• config.toml里的env_key是否写的CODEX_API_KEY。
• 当前终端是否真的设置了环境变量，检查命令：echo %CODEX_API_KEY%（cmd）或echo $env:CODEX_API_KEY（PowerShell）。
• 复制 Key 时有没有多余空格，或者把官网地址错填成 Base URL。

Base URL 必须是 https://taotoken.net/api ，不带/v1。如果上面的都正确，去 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 控制台重新创建一个 Key 再试。

6.3 model not found

报model not found，说明YOUR_MODEL_ID没有对上模型广场的当前列表。模型会上架、下架、更名，不要用旧文章写死的模型名。打开 TaoToken 模型广场，复制当前可用的模型 ID，再运行：

codex -m 新模型ID "继续执行 wmic cpu get NumberOfCores,NumberOfLogicalProcessors"

确认能通之后，再把config.toml里的model字段同步过去。

7. 核对完核心数，去 TaoToken 控制台对一下这次调用

7.1 用同一把 Key 在模型对话里验证

Codex 能正常问答后，先别急着关终端。打开 TaoToken 模型对话，用同一把 Key 发一条消息，验证这把 Key 在对话页里同样可用。这样做的好处是能把问题范围缩小：如果 Codex 里报错而模型对话页正常，问题多半在 Codex 配置；如果两边都报错，再看 Key 或模型 ID 是否选对。

7.2 看用量，决定要不要上 Coding Plan

回到 TaoToken 控制台 API Keys 页面，查看刚才这几次调用的记录。用量记录能让你直观看到一次 wmic 解读消耗了多少 token，进而判断这类日常系统查询的频率是否适合长期使用。如果你打算把 Codex 作为常用系统诊断工具，可以打开 Coding Plan 看套餐是否更合适；Key 不够用了，直接在控制台新建。

如果主力工具是 Claude Code，对应的环境变量接入方式在 Claude Code 接入文档 里，Base URL 同样是 https://taotoken.net/api 。

7.3 一段实在的提醒

核对核心数这件事，本质是分清“系统显示”和“硬件事实”。设备管理器里那 4 个处理器节点不是错的，它们是逻辑处理器视图；真正告诉你物理核心数的是 wmic 的NumberOfCores。把执行交给 Codex 之后，链路里每个人各司其职：wmic 负责读 CPU，Codex 负责组装命令和解释结果，TaoToken 只负责模型通道。以后遇到类似的系统查询任务，你只需要换一个自然语言问题，Codex 就能用同一套已经配好的通道继续工作。唯一要记得的是：模型 ID 列表会变，以模型广场当时显示为准；Key 别乱贴，Base URL 别带/v1。