那天下午,一個典型的 AI 開發實驗開始了。
目標很簡單:讓 Claude Code 與本地模型協作,打造一個可以離線運行的 coding agent。
但問題很快浮現。
Claude Code 在初始化工具與系統提示時,幾乎還沒開始執行任務,就已經消耗了驚人的上下文資源:
系統 prompt:約 5,800 tokens
工具描述(tool schema):超過 20,000 tokens
單次 request 幾乎逼近 30,000 tokens 上限
這意味著什麼?模型還沒開始「思考」,就已經在處理「框架負擔」。
在實務上,這會導致三個問題:
上下文壓縮導致推理能力下降
工具調用變慢甚至錯亂
local model 幾乎無法穩定對齊指令
筆者透過 AIMochi 筆記工具,整理多方公開資訊和最新報導內容,來探討這也解釋了為什麼「幻覺式 tool calling」開始出現。
很多人誤以為問題在模型本身,但實際上更核心的是:
AI coding agent 的問題不是 intelligence,而是 orchestration complexity。
Claude Code 的設計本質上是:
高度抽象工具系統
多層 MCP(Model Context Protocol)
大型 system prompt
enterprise-grade tool injection
這對 GPT-4 class 模型可能沒問題,但對 local LLM(7B–30B)來說是災難。
因為:local model 的「有效上下文」非常敏感,每一個 token 都影響 reasoning quality
當 Claude Code 在工具層過度膨脹時,一個更輕量的方案開始受到關注:OpenCode
它的核心設計哲學很簡單:「減少工具層,讓模型做模型該做的事。」
OpenCode 的差異在於:
1️⃣ 輕量工具架構
不強制注入龐大 system prompt
2️⃣ 可插拔模型層
支援:
OpenAI
Anthropic
local LLM(Ollama)
3️⃣ workflow 可控
允許 developer 自定義:
plan mode
build mode
task splitting
這一點非常關鍵,因為它把「agent 行為」顯性化了。
真正讓這個系統成立的,是:Ollama
Ollama 的價值除了模型,更是在:「把 LLM 變成本地 API」
它解決三個關鍵問題:
✔ 模型部署簡化
不用 Docker、不用 CUDA pipeline
✔ 本地推理 API 化
localhost:11434 直接可用
✔ 模型自由切換
可以快速切換:
Mistral
Llama
Code LLM variants
當兩者結合,一個完整 AI coding agent 架構誕生:User → OpenCode → Ollama API → Local LLM → Code Output
⚙️ 實際工作流拆解
Step 1:Install OpenCode
npm install -g opencode
Step 2:Install Ollama
ollama pull qwen2.5-coder
Step 3:Connect model
在 OpenCode 中設定 provider:
provider: Ollama
model: qwen2.5-coder
此專案最關鍵的一個觀察是:
同樣的模型,在 Claude Code 框架下表現更差,但在 OpenCode 下反而穩定
原因是:
1️⃣ Prompt noise reduction
Claude Code:
system prompt 過長
tool schema 過重
OpenCode:
minimal context
2️⃣ token efficiency
local model 對 token 非常敏感:少 10,000 tokens ≠ 小優化,而是「整體能力提升一個層級」
3️⃣ deterministic workflow
OpenCode 的 plan/build 分離:
plan → 推理
build → 執行
減少 model confusion
這個案例最深的啟示是:
AI agent 最大的敵人不是能力不足,而是工具太多。
當系統變成:
Browser tool
File tool
Code execution tool
memory tool
模型反而:失去 focus,增加 hallucination, tool calling 混亂
以上僅供參考與資訊分享之用!若想快速了解更多資訊,透過 AIMochi 台灣本土筆記工具,幫我們從海量資料中,梳理出關鍵資訊,讓我們精準掌握重要訊息!