这篇文章解决什么问题
适合正在尝试或打算尝试本地模型接入开发工具链的开发者。如果你在考虑"要不要把本地模型接进 Claude Code / Cursor / Copilot"，这篇文章用一次真实的失败经验告诉你：关键问题不是模型能不能跑，而是能不能稳定承载 agent 环境。
背景：为什么要折腾本地模型
我日常使用 Claude Code 做 AI 辅助开发，背后是 DeepSeek 处理复杂判断、Codex 负责工程执行。这个分工运行得不错，但有一类任务一直让我觉得"杀鸡用牛刀"：
ai-context的上下文更新dev-session-guard的 start-day / next-plan / acceptance / end-day- 读取已有事实源、整理状态、生成下一步建议
这些本质上都是项目书记员的活儿：读文件、整理信息、写更新，最后人看 diff 决定是否 commit。它们不是高风险代码修改，错了可以 git 回滚；也不是复杂产品决策。理论上，本地模型完全够用。
如果能让本地模型承担这些高频、低风险、重复性的维护劳动，DeepSeek 就可以继续留给复杂判断，而我的模型成本会大幅下降。
机器条件和模型选择
我的机器：i7-14700KF、48GB 内存、RTX 5060 Ti 16GB 显存。按常规理解，跑一个 12B 量级的本地模型没有太大压力。
选择 gemma4:12b，因为它刚好卡在一个合理位置：不算特别小，理论上能处理文档和上下文维护；也不算太大，不至于把 16GB 显存完全顶满。
预期的分工很清晰：
本地模型：小任务、文档型、非决策类
DeepSeek：大任务、判断型、复杂分析
Codex：工程执行、UI 还原、代码落地部署本身没有大问题
Ollama 安装、模型目录放到 D 盘、拉取 gemma4:12b。过程中遇到过网络 EOF、TLS handshake timeout，但断点续拉后成功。
用 Ollama CLI 直接调用：
ini
ollama run gemma4:12b --think=false "只回答OK"模型正常返回 OK。本地模型部署本身是成功的。
之后尝试通过 CC Switch 接入 Claude Code。最初想把 Ollama 当 OpenAI-compatible provider 接入，但 CC Switch 当前页面是 Claude 供应商，高级选项里只有 Anthropic Messages 原生格式。后来确认 Ollama 支持 Anthropic Messages 兼容接口，于是按 Claude provider 配置：
makefile
请求地址：http://127.0.0.1:11434
API Key：ollama
API 格式：Anthropic Messages（原生）
实际请求模型：gemma4:12b到这里为止，看起来链路是通的。真正的问题在接入 Claude Code 完整模式之后才暴露出来。
第一层：thinking 输出爆炸
Claude Code 中输入一个很简单的问题后，直接报错：
vbnet
API Error: Claude's response exceeded the 32000 output token maximum.把输出上限提高到 65536，依然报同样的错误。问题不是上限太小，而是模型在 Claude Code 的完整系统提示和工具上下文下，输出行为失控了。
gemma4:12b 在 Ollama 的 Anthropic 兼容接口下会返回 thinking content block。Claude Code 的系统提示、工具说明、项目上下文都很长，很容易诱发模型生成超长 thinking。
普通 Ollama chat API 可以用 {"think": false} 禁用，但这个字段对 /v1/messages 的 Anthropic 兼容接口无效。实际需要传：
json
{
"thinking": {
"type": "disabled"
}
}问题是，Claude Code 自己不会主动帮你传这个字段。
第二层：加代理之后，正文开始循环
为了解决 Claude Code 无法主动传 thinking.disabled 的问题，我做了一个本地代理：
rust
Claude Code / CC Switch
-> http://127.0.0.1:11435
-> Ollama http://127.0.0.1:11434代理做了几件事：
perl
自动注入 "thinking": { "type": "disabled" }
把 max_tokens=65536 截断为 2048
给 system prompt 加反重复提示
过滤 thinking block代理日志显示这些处理确实生效了，但 Claude Code 完整模式下仍然会出现正文循环：
vbnet
Please
Please
Please
API Error: Claude's response exceeded the 65536 output token maximum.这时已经不是 thinking 泄漏了，而是 Gemma4 在 Claude Code 完整系统提示、插件、项目上下文下，正文输出也开始失控。
问题从"少传了一个参数"，变成了"这个模型面对 Claude Code 的完整 agent 环境时不够稳定"。
第三层：--bare 能用，但项目能力被削弱
继续测试发现：
css
claude -p "OK" --bare --model gemma4:12b可以成功。不加 --bare，同样走代理，仍然复现 65536 报错。
这说明 --bare 可以绕开一部分 Claude Code 默认上下文，让模型稳定下来。但代价也很明显：它会跳过大量 Claude Code 默认能力，包括自动项目发现、插件同步、hooks、LSP、memory、部分动态上下文等。项目 skills 一开始也无法加载。
后来通过 --add-dir 可以重新发现项目 skills，但走到这一步，事情已经变味了：
为了让本地模型稳定，需要本地代理、参数注入、固定启动脚本、额外 add-dir，还失去了 CC Switch 热切换的优势。原本想要的是"低成本维护工作流"，结果变成了"为了让模型能工作，不断维护另一套接入工程"。
核心判断：裸聊可用 ≠ Agent 可用
这次探索最重要的收获不是 Gemma4 能不能跑，而是一个方法论判断：
本地模型裸聊能用，和它能不能进入 Claude Code 完整工作流，是两回事。
本地模型能回答"OK"，只能说明它作为聊天模型可用。但要成为 Claude Code 后端，它需要承受的是一整套复杂环境：
perl
长 system prompt
tools 协议
skills 机制
项目上下文
streaming 输出
多轮状态
文件读写
agent 行为约束这些东西叠在一起之后，模型要做的不只是"回答问题"，而是要稳定地遵守协议、控制输出、理解工具调用、不要循环、不要过度 thinking、不要被复杂上下文带偏。
gemma4:12b 在普通聊天下没问题，但在 Claude Code 完整模式下没扛住。这次失败不是硬件失败，也不是本地部署失败，而是工作流适配失败。
模型分层的思路仍然成立，但有一个前提
我的模型分层思路没有变：
小任务、文档型、非决策类 → 便宜模型
大任务、判断型、复杂分析 → DeepSeek
工程执行、UI 还原、代码落地 → Codex但这次补上了一个关键前提：
便宜模型必须能稳定承载当前 agent 壳。
如果模型在 Claude Code 完整模式下连输出都控制不住，那它再便宜也不能进入日常工作流。因为它省下来的模型成本，会变成更多的排障成本、等待成本和心智负担。这恰恰违背了最初引入本地模型的目的。
一个很容易踩的坑
对个人开发者来说，工具探索最容易掉进一个坑：为了省一点模型成本，反而引入一堆新的维护成本。
这次及时停下来，是正确的。最终我的操作是：
删除 gemma4 模型
停止 Ollama 和本地代理
清除相关环境变量
卸载 Ollama后续如果还要继续试，应该换一个更面向 agentic coding 的模型（比如 Qwen3-Coder），而且验证目标应该是"能不能稳定跑 Claude Code 完整模式"，不是"本地模型能不能聊天"。
这件事的价值
这次探索虽然没有"成功"，但它确认了一件事：
AI 工具链不是单点能力竞争，而是工作流稳定性竞争。
一个模型跑分高、显存够、CLI 能回答，都不代表它能进入真实开发流。真正重要的是它能不能稳定接住现有工具链里的上下文、协议、插件、文件操作和行为约束。
总结
- 本地模型部署成功 ≠ 能进入 agent 工作流
- Gemma4 12B 在 Claude Code 完整模式下，从 thinking 爆炸→正文循环→bare 降级，是一个递进的稳定性问题
- 便宜模型必须能稳定承载当前 agent 壳，否则省下的成本会变成排障成本和心智负担
- 工具探索只能服务主线，不能吞掉主线
欢迎大家畅所欲言：
- 你试过本地模型接 IDE 或 CLI 开发工具吗？遇到了什么问题？
- 如果换一个更面向 agentic coding 的模型（Qwen3-Coder、DeepSeek-Coder），你觉得能不能扛住？
- 你是怎么平衡"探索新工具"和"不拖累主线进度"的？