本地大模型驱动 OpenAI Codex 全攻略：Ollama 一键启动、llama.cpp 进阶接入，离线搭建零负担 AI 编程智能体

本文由 莫潇羽@源码七号站（www.fuyuan7.com）撰写，转载请注明出处。

快速摘要

先把结论摆出来：到了 2026 年，OpenAI 的 Codex 已经不再是只能连云端、只能交订阅费才能用的东西。借助 Ollama 0.24 新加入的 ollama launch codex-app，你可以把 Codex 桌面端直接挂到本地跑的开源大模型上——一条命令搞定，不配环境变量、不写配置文件，连网络都可以拔掉。我自己在一台普通显卡的机器上折腾下来，本地的 Qwen3.6、Gemma 4 这类"甜点级"模型就能驱动 Codex 去自动读项目、改代码、修 bug、生成网页，全程跑在自家 GPU 上，每一个 token 都不出本机。 如果你想要更细的控制权，还能换成 llama.cpp 这条进阶路线。这篇文章我会把名词扫盲、硬件选型、Ollama 一键接入、llama.cpp 手动接入、上下文调优、实战演练、踩坑清单从头到尾讲清楚。想看完整拆解，往下翻。

一、先把这件事说清楚：本地 Codex 到底解决了什么

我先交代一下背景，不然很多人会以为"本地跑 Codex"只是个炫技的玩具。

过去一年里，AI 编程智能体（Agent）这个词被说烂了，但真正天天用的人会发现三个绕不开的硬伤。

第一个是消耗。编程类智能体跟普通聊天完全不是一个量级——它要反复读文件、跑测试、改代码、再读再改，一次像样的任务,背后的 token 用量往往是普通对话的几十倍。挂在云端 API 上，账单涨得飞快，长任务尤其肉疼。

第二个是限流和中断。Codex 这类工具天生就是为多步骤、有状态的长流程设计的，可你一旦在任务进行到一半时撞上服务端的速率限制，上下文就可能被打断，严重的时候只能从头再来。我自己踩过这个坑，写到一半被掐断、前面的推理全废，那种感觉真的很上头。

第三个是隐私与依赖。代码是很多人吃饭的家伙，受 NDA 约束、涉及内部系统的项目，源码一旦上传到第三方服务器，本身就是个合规风险。再加上一旦断网就什么都干不了，对网络不稳定的环境很不友好。

把这三件事放一起看，"能不能让智能体跑在自己机器上"就成了一个很自然的诉求。而 2026 年的转折点，是开源推理引擎和 Codex 客户端之间终于打通了。

简单说，Codex 客户端本身只是个"前端"——它负责接收你的指令、组织工具调用、展示结果，真正的"大脑"（也就是推理）可以被重定向到任何一个兼容 OpenAI 接口的服务上。本地的 Ollama、llama.cpp 恰好都能在你机器上开一个这样的兼容接口。于是结构就变成了：Codex 在前面摆样子，推理请求悄悄拐到本地 GPU 上的开源模型那里,结果再回填给你。每一次文件读取、每一个 token，都留在自己的硬盘和显卡里。

这就是本地 Codex 真正解决的问题：把"智能体能帮你干活"这件事，从云端搬回了本机，顺带把成本、限流、隐私三个坎一起迈过去了。 它已经不是聊天机器人，而是一个能动手的助手。

为了让你对这笔账有个直观感受，我把云端和本地两种方式摆在一起对比：

看这张表就明白了：本地化不是全方位碾压云端，而是用"上手难度"和"模型能力上限"换来了"成本、限流、隐私、断网"四项的彻底自由。值不值，取决于你更在意哪一头。对天天写代码、又介意隐私和账单的人来说，这笔交换通常很划算。

莫潇羽@源码七号站多嘴提醒一句：本地化不等于免费午餐。省下的是 API 账单，但你要付出显卡、电费和一点点折腾的时间成本，这笔账后面选硬件时我会帮你算清楚。

二、四个核心名词扫盲：Codex、Ollama、llama.cpp、GGUF

动手之前，先把四个高频词讲明白。新手最容易卡住的地方，就是名词没搞清就开干，结果配置全乱。术语第一次出现，我都用一句白话先解释。

2.1 Codex App：不是 IDE，是带界面的编程智能体

很多人把 Codex 当成又一个代码编辑器，这是误会。它更像一个"会自己动手的实习生"：你给它一个目标，它会自己分析项目结构、决定改哪些文件、调用工具去执行、跑完再把结果给你。

2026 年的 Codex 桌面端（Codex App）相比命令行版本多了图形界面，支持并行处理多个任务线程、内置 git 与工作树（worktree）功能，还带一个内置浏览器——它可以在浏览器里加载本地服务和页面，让你直接在页面上标注、要求修改，再在应用里审查代码、留评论、迭代，整个过程不用切走。

需要注意的是，Codex App 目前覆盖 Windows 和 macOS，Linux 端的桌面应用还没跟上。macOS 用户下载时还要分清自己是 Intel 芯片还是 Apple 芯片的版本，别装错。

2.2 Ollama：本地模型的"启动器与管家"

Ollama 是一个在本地下载、运行、管理大模型的工具。你可以把它理解成"本地模型的 App Store + 运行时"：一条 ollama pull 把模型拉下来，一条 ollama run 就能跑起来，同时它会在本机开一个 HTTP 接口供别的程序调用。

它真正的分水岭是 0.24 版本（2026 年 5 月发布）。这一版正式加入了对 Codex App 的支持，提供了 ollama launch codex-app 命令，直接启动 Codex 桌面端并指向本地运行时，省掉了过去要手动配环境变量、改 config.toml、设自定义端点的一堆麻烦。所以这条路线对版本有硬要求：必须是新版本 Ollama，老版本不支持，装之前先升级。

2.3 llama.cpp：更底层、更自由的推理引擎

llama.cpp 是一个用 C/C++ 写的高性能推理框架，跨 Windows、Linux、macOS。它的 llama-server 能把模型以 OpenAI 兼容接口的形式开出来，供 Codex 调用。

相比 Ollama 的"开箱即用"，llama.cpp 更偏底层——参数能拧得更细，模型来源更自由，进阶玩家用它能榨出更高的吞吐和更灵活的配置。代价是上手门槛更高，要自己处理编译、GPU 绑定、启动参数。后面我会把这条路线单独拿出来讲。

2.4 量化与 GGUF：为什么 30B 的模型能塞进消费级显卡

这个概念新手最容易懵，我尽量说人话。

大模型原始权重是高精度浮点数，体积巨大，显存根本放不下。量化就是把这些数字压缩成更低精度的表示（比如从 16 位压到 4 位），体积大幅缩小，精度只损失一点点。常见的量化档位写作 Q8、Q6、Q5、Q4 等，数字越小压得越狠、体积越小、也越省显存，但质量会有所下降。日常用得最多的甜点档是 Q4_K_M，在体积和质量之间比较平衡。

GGUF 则是 llama.cpp 生态里存放这些量化模型的标准文件格式。你在模型下载页看到的 xxx-Q4_K_M.gguf，就是已经量化好、可以直接喂给推理引擎的文件。正是靠量化，一个标称 30B 参数的模型，Q4 量化后只占十几 GB，普通玩家的显卡也能跑起来。

2.5 顺带说清"智能体"和"聊天机器人"的区别

新手常把这两者混为一谈，但它俩的工作方式天差地别，理解了这个区别，你才能明白为什么本地 Codex 这么吃 token、这么看重工具调用。

聊天机器人是"一问一答"：你说一句，它回一句，回完这一轮就结束了，它不会主动去做任何事。

智能体（Agent）是"给目标、自己干"：你给它一个目标——比如"修好这个游戏"，它会自己规划步骤，然后进入一个循环：读文件 → 思考下一步 → 调用工具（比如改文件、跑命令、开浏览器）→ 看工具返回的结果 → 再思考 → 再行动……一直循环到目标达成。这个"读—想—做—看"的闭环，业内叫 ReAct 式循环。

正因为它要反复读、反复调工具，一次任务背后的 token 消耗才会是普通聊天的几十倍；也正因为每一步都依赖工具调用，模型"会不会规规矩矩地按格式调用工具"就成了体验好坏的命门——这也是我前面反复强调"工具调用可靠性"比"参数大小"更重要的根本原因。

把这四个词理顺，后面的操作你就不会一头雾水了。下一章我们先解决一个最现实的问题：你的机器，到底能跑多大的模型。

三、硬件与显存：你的机器能跑多大模型

这一章是动手前的"体检"。模型选多大、跑得快不快，本质上由你的显存说了算。先给一张我自己整理的对照表，按显存分层，方便对号入座。

3.1 什么是"甜点级"模型

所谓甜点级，指的是参数量大致落在 4B 到 40B 之间、能在消费级显卡上跑得动、又不至于太笨的那批模型。它们是性价比最高的区间：太小了智力不够，撑不起智能体的多步推理；太大了普通显卡放不下、跑得龟速。对绝大多数个人玩家来说，16GB 到 24GB 显存配一个 27B 上下的模型，就是最舒服的落点。

视频里那位讲解者提到，6GB、8GB 显存现在也能把本地 Codex 跑起来——这话没错，但要客观看待：小显存能"跑起来"和能"跑得爽"是两码事。8GB 跑个小模型做做演示没问题，真要它去啃一个有几十个文件的项目、连续调用工具，体验就会打折。我的建议是，预算允许的话，显存优先堆到 16GB 以上。

3.2 MoE 架构：为什么有的模型"显存占得少、还跑得快"

你在选型时会频繁看到一种写法，比如 30B-A3B、26B-A4B，这背后是 MoE（混合专家） 架构，值得单独说一句。

传统的"稠密模型"，每处理一个 token 都要让全部参数参与计算。MoE 则不一样：模型内部分成很多个"专家"（各自擅长不同的事），每来一个 token，由一个路由器决定只激活其中几个专家。于是出现了两个数字：

• 总参数量：决定模型的"知识储备上限"和占用的显存/内存。
• 激活参数量：决定每次推理实际算多少、跑多快。

30B-A3B 就表示总共 30B 参数、但每个 token 只激活约 3B。这样一来，它的推理速度接近一个 3B 小模型，质量却能逼近大得多的稠密模型。对显存吃紧的人来说，MoE 是个好东西——比如 Gemma 4 的 26B-A4B，只有 4B 激活，配合较低量化甚至能在 8GB 级别的显卡上挤进去。

一个小提醒（莫潇羽踩过的坑）：MoE 模型"激活少"不代表"显存占用少"。总参数还是要进显存/内存的，激活少只影响计算速度。别看到 A3B 就以为 3B 的显存够用，那是误解。

3.3 不只是显存：内存、硬盘和带宽

除了显存，还有几样东西会影响体验，新手容易忽略：

• 内存（RAM）：MoE 模型常用"显存放不下的部分卸载到内存"的玩法，内存太小会成为瓶颈。32GB 起步比较从容。
• 硬盘：一个量化模型动辄十几到二十几 GB，多存几个就奔着上百 GB 去了，留足空间。
• 内存带宽：本地推理的吐字速度很大程度上由带宽决定，这也是 Apple 芯片统一内存在本地推理上表现不错的原因。

3.4 量化档位怎么选，外加一个白话估算法

第二章讲过量化是什么，这里给你一个实操层面的选档思路，免得对着一堆 Q4、Q5、Q6 发懵。

• Q8 / Q6：质量最接近原版，但体积大、吃显存，显存富裕（比如想在 24GB 上跑 27B）才考虑。
• Q5_K_M：质量和体积都比较体面，显存够的话是个不错的折中。
• Q4_K_M：最常用的甜点档，绝大多数人从这里起步就对了。
• Q3 及以下：压得很狠，显存实在紧张才用，质量下降会比较明显，做正经活之前先测一下它还靠不靠谱。

再教你一个新手都能用的显存粗估法：一个模型 Q4 量化后，权重大致占用"参数量(B) × 约 0.6GB"的显存，再加上 KV 缓存（跟上下文长度成正比）和一点系统开销。举个例子，一个 27B 的稠密模型 Q4 大约 16GB 权重，再留 2–4GB 给上下文和系统，所以 24GB 的卡跑它比较从容、16GB 就有点紧。这只是个拍脑袋的估算，真要精确请用对应模型的官方显存表，但它足够帮你在下载前判断"会不会爆"。

MoE 模型要特别注意：估算时按总参数算显存占用，按激活参数算速度。比如 35B-A3B，显存按 35B 估、速度按 3B 体验，这就是它"占得多但跑得快"的来源。

四、选模型：2026 年本地编程模型怎么挑

模型这块更新非常快，我尽量给你一个到 2026 年中仍然站得住的判断框架，而不是死记某个名字。先讲选型逻辑，再上对比表。

编程用的本地模型，挑的时候盯三件事：智力（尤其是代码推理与多步任务能力）、工具调用的可靠性、以及能不能塞进你的显存。下面是当前几条主流选择。

4.1 Qwen3.6 系列：编程首选的国产开源

阿里的通义千问 3.6 系列（2026 年发布）在本地编程场景里口碑很硬。两个型号最值得关注：

• Qwen3.6-27B（稠密）：主打"旗舰级智能体编程"，在 SWE-bench Verified 这类权威代码评测上拿到约 77% 的成绩，是同体量里很能打的。适合 24GB 显存的机器。
• Qwen3.6-35B-A3B（MoE）：总参数更大但每次只激活约 3B，显存吃紧时是救星，配合内存卸载能在 16–24GB 的卡上跑起来。

它的另一个优势是中文场景表现好、上下文窗口很长（原生几十万 token，可扩展到百万级），许可证也宽松。如果你主要写中文注释、做中文项目，Qwen3.6 往往是第一选择。

4.2 Gemma 4 系列：函数调用稳、多模态强

谷歌的 Gemma 4（2026 年发布）是另一极。它把函数调用（也就是工具调用）原生训进了权重里，做智能体时工具调用的可靠性比较稳；同时支持多模态（文本 + 图像等）、覆盖一百多种语言、上下文也很长。

• Gemma 4 26B-A4B（MoE）：4B 激活，低量化下能压到很小的显存占用，是 12GB 这类中端卡里少有的"30B 级"可选项。
• Gemma 4 31B（稠密）：在数学、多模态、多语言上更强。

英文为主、看重智能体工作流和工具调用稳定性的，Gemma 4 是个很稳的默认值。

4.3 其他值得知道的选项

• gpt-oss 系列：OpenAI 自己放出的开源权重，有 20B（约 3.6B 激活）和 120B（约 5.1B 激活）两档，和 Codex 的契合度天然较好。20B 这档适合消费级，120B 就要上工作站级显存了。
• GLM-4.7-Flash 这类：MoE 结构、上下文 128K、工具调用能力不错，靠 MoE 在 16GB 内存上也能转，进阶玩家可以试。

4.4 一张表对比，外加选型建议

我的实操心得是这样的：不确定怎么选，就让工具替你挑。 Ollama 的客户端里有"选择模型"的入口，你拖一下显存大小，它会自动匹配合适的模型尺寸——比如给我推过 22GB 左右的 Qwen3.6。这样能避免新手一上来就下错一个塞不进显存的大块头。下载完一个跑起来卡，就换小一号，别跟显存硬刚。

还有个反直觉的点要记住：模型不是越大越好用。 对智能体来说，一个稍小、但工具调用稳、出字快的模型，连续干活的体验往往胜过一个又大又慢、动不动就超时的大模型。我自己在 24GB 的卡上，宁可用 27B 上下的型号把交互盘得顺，也不硬上更大的把节奏拖垮。

4.5 没好显卡也别灰心：用 Ollama 代理云端模型

如果你的机器实在带不动像样的本地模型，还有一条折中路线：Ollama 支持代理一批云端模型（名字里带 :cloud 的那种，比如一些 Kimi、GLM、MiniMax、DeepSeek 系列的云端版本），通常带有比较慷慨的免费额度，对硬件几乎没要求——你本机只要装着 Ollama 就行，推理跑在对方服务器上。

它的配置方式和本地模型几乎一样，在 Codex 里照样能选。最舒服的玩法其实是本地 + 云端混搭：日常轻量任务、涉密代码走本地，碰到特别复杂、本地模型啃不动的硬骨头，临时切到云端兜底。这样既守住了隐私和成本的大头，又不至于在难题上卡死。

当然，走云端就意味着那部分请求会出本机，涉密项目要不要这么用，你自己权衡。我个人的习惯是：默认全本地，只在明确不敏感的难题上才临时借一下云端的力。

4.6 关于榜单分数，泼一点冷水

选型时大家爱看 SWE-bench、LMArena 这些榜单，分数确实有参考价值，但别把它当圣旨。这些评测衡量的是特定、狭窄的任务，把它当信号，不要当判决。

我自己的体会是，真实体验和榜单经常对不上：有的模型分数漂亮，但在你具体的项目、具体的提示词下表现平平；有的模型综合分一般，却恰好很合你的工作流。还有个反直觉的现象——有些模型开了"思考模式"反而更不听指令，做智能体时未必是好事。所以最终决定权还是交给实测：下两三个候选，拿你自己最常干的活儿各跑一遍，哪个顺手用哪个，比纠结零点几个百分点的榜单差距实在得多。

五、最省心路线：Ollama 一键接入 Codex App

这是我最推荐新手走的路。整条链路下来就五步，关键命令只有一条。下面按顺序来，我把每一步可能踩的坑也标出来。

5.1 第一步：装 Codex 桌面端

先去拿最新版本的 Codex 应用程序安装包。它分 Windows 和 macOS 两个大版本，macOS 还要细分 Intel 芯片和 Apple 芯片，别下错——下错芯片版本装上去要么报错要么性能拉胯。

下载下来的通常是个下载器，双击后它会自己把本体（几百 MB）拉下来并安装。装完一般会自动打开。如果是第一次装，右下角是不看不到"已连接 Ollama"这类提示的，这正常——还没接进去呢。

5.2 第二步：装 / 升级 Ollama 到最新版

前面强调过，这条一键路线对 Ollama 版本有硬要求，必须是支持 ollama launch codex-app 的新版本（0.24 及以后）。老用户尤其注意，停在旧版本是接不进去的，务必升级。

去 Ollama 官网拿最新版客户端，按平台选 Windows / macOS 对应包，装好。装的过程里它会有个安装本体的步骤，等它跑完即可。

5.3 第三步：拉一个本地编程模型

打开 Ollama，找到"选择模型"的入口，按上一章的思路挑一个适合你显存的型号（比如 Qwen3.6-27B 或 Gemma 4 系列）。让工具帮你匹配尺寸最省心。

如果你更习惯命令行，也可以直接 pull。打开终端（Windows 在搜索栏输入 cmd 回车），用类似下面的命令拉模型——模型名千万别照抄，按自己显存选对应尺寸：

# 示例：拉取一个适合 24GB 显存的编程模型（名称按官方模型页为准）
ollama pull qwen3.6:27b

# 显存吃紧就换小一号，比如 MoE 版本
ollama pull qwen3.6:35b-a3b

一个 27B 上下的 Q4 模型大概十几到二十几 GB，在终端里下感觉比在图形界面里更快、进度更直观。

5.4 第四步：一条命令把模型接进 Codex

这是整条链路的核心。打开终端，敲：

ollama launch codex-app

这条命令会启动 Codex 桌面端，并把它指向本地运行时，全程不用手动配环境变量、不用改配置文件。它会列出你本地已经下载好的模型让你挑，比如第一个是 Qwen3.6，第二个是你刚拉的另一个型号。选一个跟你显存匹配的——24GB 的卡选 27B 比较稳，硬上更大的 MoE 反而会卡。

选好后它可能会问你要不要重启一下 Ollama，选 yes 即可，它会自动重启并把本地配置加载进去。重启完，你就会在 Codex 右下角看到"已连接 Ollama"的提示，说明本地模型已经接上了。

如果你只想要命令行体验，对应的命令是 ollama launch codex（不带 -app），启动的是 Codex CLI 终端版。本文主讲桌面端。

5.5 第五步：把权限、模式、浏览器设置调到位

接上之后别急着用，几个设置直接决定体验，我逐个说。

权限模式。 Codex 提供几档权限，默认通常是"手动确认"（每个动作都要你点同意），往上还有"自动审查"和"完全访问"。想实现真正的全自动——让它自己建文件、访问文件夹、改项目代码——就开"完全访问"。不过这里有个已知小坑要提醒：在桌面端用"完全访问"时，部分版本会出现补丁类工具调用失败的情况。如果你遇到改文件失败，可以退回到"自定义（config.toml）"模式，把写权限限定在工作目录里，反而更稳。我个人偏向后者，既自动又安全。

工作模式。 设置里能切不同模式，一档偏编程、一档偏日常工作，按你的用途选。

外观。 浅色深色随你喜好，纯个人口味。

内置浏览器与电脑控制。 这块是让 Codex 能"自己上网、自己点页面"的关键：

1. 打开"允许 Codex 控制内置浏览器"。
2. 打开"电脑控制"权限。
3. 把对应的浏览器扩展安装到你的 Chrome（它通常会自动跳转到扩展安装页，点"添加"即可；连接成功后会显示"已连接"）。

如果没有自动跳转安装页，到设置里找"管理 / 重新安装扩展"的入口手动装一次就行。这个扩展是 Codex 自动操作浏览器的必备件，不装它就只能干编辑器里的活，碰不了网页。

5.6 常用命令小结

5.7 跑通之后，建议先做这三件事

第一次接通别急着上正经项目，我习惯先做三件事把状态摸清楚：

• 断网验证一次。 拔网线（或开飞行模式）让它跑个小任务，确认链路确实走的是本地，不是偷偷连了云端。这一步详见第七章。
• 调一次上下文长度。 默认值大概率不适合你的显存，先按第六章把它压到一个跑得顺的值，别等卡死了才回头调。
• 拿一个小项目试手感。 让它写个网页小游戏或者修个小 bug，感受一下这个模型的速度和"听不听话"，心里有个底，再决定要不要换型号。

这三步花不了十分钟，但能帮你避开后面一大半的困惑。很多人一上来就丢大项目、开最大模型，结果卡得怀疑人生，其实是省了这十分钟的热身。

到这里，最省心的一条路就走完了。理论上现在你已经能让本地模型替你干活了。但很多人第一次跑会撞上一个共同的问题——Agent 跑得特别慢、甚至卡在重连死循环里。这不是模型笨，而是上下文长度没调好。下一章专门治这个。

六、上下文长度调优：为什么 Agent 会卡死

第一次默认配置跑起来，很多人会发现智能体慢得离谱，或者反复卡在"重新连接"的循环里。根因往往在上下文长度（context length）这个参数上。这一节稍微讲点原理，再给调法。

6.1 先理解 KV 缓存这个"成本黑洞"

模型推理时，会把已经处理过的 token 的注意力中间结果缓存下来，这就是 KV 缓存。上下文窗口开得越大，这块缓存占的显存就越多，而且是近似平方级地往上涨。窗口一大，显存被缓存吃满，速度自然崩。

于是出现了一个两难：

• 窗口开太小：一个稍大的项目，提示词的 token 数轻松超过窗口，直接报"超出上下文"的错，任务跑不动。
• 窗口开太大：KV 缓存撑爆显存，推理慢如蜗牛，甚至卡在重连死循环。

官方对编程工具的建议偏大（推荐至少 64000 token 上下文，因为读项目确实费 token），但那是给显存充裕的机器的。对消费级显卡，盲目拉到 64k 往往就是卡死的元凶。

还有个细节值得知道：llama.cpp 这类服务在上下文用满后，会按"滑动窗口"丢弃较早的 token（保留一部分关键开头），这会带来重新评估的停顿，表现出来就是"卡一下"。窗口设得越大、越接近占满，这种停顿和重算就越频繁。所以"开大窗口"不仅更吃显存，还可能因为反复重算而拖慢节奏——这是很多人没意识到的隐性成本。

6.2 调法：在能跑动的前提下，往小了压

实操结论很简单：在不报"超出上下文"的前提下，把上下文长度往小压，智能体的速度会明显变快。 比如默认是 32k，你可以试着改成 16k 甚至 8k，代理（agent）干活的流畅度立竿见影。

在 Ollama 里改上下文，可以用运行时参数：

# 在已加载的模型会话里设置上下文长度
/set parameter num_ctx 16384

或者在 Ollama 的设置界面里，把模型的上下文长度调到一个你显存扛得住、又够装下当前项目提示词的值。

我的经验法则：先从 16k 起步，跑顺了再视项目大小往上加；一旦发现卡顿或重连，就往下压。显存越小，越要把这个值压低。 这个参数没有放之四海皆准的值，是个要根据机器和项目反复试的平衡点。

调好上下文，你的本地 Codex 基本就"活"过来了。接下来聊一个很多人第一次都会懵的问题：它怎么张口就说自己是 GPT-5？

七、关于"它说自己是 GPT-5"：一场模型身份的误会

接上本地模型后，几乎每个人都会做的第一件事，就是问它："你底层是什么模型？"然后得到一个让人困惑的回答——它会一本正经地说自己是"基于 GPT-5 构建的 Codex 编码代理"。

别被骗了，它现在跑的根本不是 GPT-5，而是你本地通过 Ollama 部署的那个开源模型。

7.1 为什么会自报家门错乱

原因不在模型撒谎，而在 Codex 给它注入的系统提示词（system prompt）。Codex 在每次对话开头都会塞一段身份设定，告诉模型"你是 Codex"。本地模型很听话地照着系统提示词回答，于是不管底层换成了谁，它都会说自己是 Codex / GPT 那一套。这是工具层面的"人设注入"，跟实际权重是哪个模型无关。

如果你介意，可以通过覆盖系统提示词的方式让它如实自报；但对干活来说，这个自报身份基本没影响，知道它是怎么回事即可。换句话说，模型说自己叫什么，跟它实际是谁，完全是两码事——前者是工具给它贴的标签，后者才是你显卡里真正在跑的权重。别被这层标签带偏判断。

7.2 一个最硬的验证办法：拔网线

光看它嘴上说什么没意义，最干脆的验证是断网。

打开飞行模式、把网络彻底断开，然后随便让它干个活——比如写个网页小游戏。你会发现它照样跑得动、照样能生成代码、照样把游戏做出来。打开任务管理器看，吃的是本地 GPU。

这就铁证如山了：它如果真连的是云端 GPT-5，断网后必然瘫痪；既然断网还能干活，说明推理就是发生在你本机的开源模型上。 这一步我建议每个人都亲手试一次，断网那一刻心里就踏实了——这才是"真·本地 AI"。

莫潇羽@源码七号站的小习惯：第一次接新模型，我都会断网跑一个小任务做验证，既确认链路没走云端，也顺便摸一下这个模型的实际速度。

八、进阶路线：用 llama.cpp 手动接入 Codex

Ollama 那条路够省心，但如果你想要更高的吞吐、更细的参数控制、更自由的模型来源，llama.cpp 是更进阶的选择。这一章门槛会高一些，新手可以先收藏，跑顺了基础路线再回来啃。

8.1 为什么要折腾 llama.cpp

简单说三点好处：参数能拧到很细（量化、KV 缓存类型、GPU 层数、并行度都能手动指定），吞吐往往更高，模型来源也更广——你可以直接喂任意来源的 GGUF 文件。代价就是要自己处理编译、GPU 绑定和启动参数，配置链路比一条 ollama launch 长不少。说白了，Ollama 把方向盘焊死了让你省心，llama.cpp 则把每个旋钮都交到你手里，自由的另一面就是你得自己为调坏了负责。愿意花时间研究的人，能从它身上榨出 Ollama 给不了