CoreCoder：1,161 行的 coding agent 引擎，讀完一個下午就能自己改
Minimal AI coding agent (~1,000 lines of Python) inspired by Claude Code. Works with any LLM. Think NanoGPT for coding agents. Formerly NanoCoder.
秒懂
- 它是什麼？
- 把 Claude Code 那類工具拆到只剩 while 迴圈、模型介面與七、八個工具，用 Python 寫成可執行、可下中斷點的參考實作。它的價值在於能被讀完，不在於取代你現在的助手。
- 適合誰用？
- 如果你要的是能拆開、能下中斷點、能 fork 的教學級 agent 引擎，CoreCoder 值得 clone 下來讀一遍；如果你要的是每天拿來改公司專案的助手，它刻意留白的部分會讓你付出補齊成本。動手前先確認三件事：你的模型是否走 OpenAI 相容端點（否則要裝 corecoder[litellm]）、你的 Python 是否 3.10 以上、以及你是否接受 -p 一次性模式下必須顯式加 --yes 才會執行會改動磁碟的工具。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 2 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它想解決的不是「寫程式很慢」，而是「agent 讀不懂」
多數人談 coding agent 時，把它描述成一種近乎黑箱的東西。CoreCoder 的作者把這個印象當成要處理的問題：把 Claude Code 或 Cursor 一路剝到底，核心就是一個包住大型模型的 while 迴圈，外加七、八個讓它真的能動手的工具。README 寫得很直白，難的從來不是迴圈，而是迴圈碰到真實世界之後要應付的一切。
所以這個專案鎖定的讀者不是想找日常助手的人，而是想把 agent 架構看懂的人。它自己把定位放在 nanoGPT 那一欄：極簡、可讀，但 nanoGPT 教你訓練 GPT，CoreCoder 的主題是一個真的會改程式碼的 agent。README 也明講，把它和 Claude Code、aider 並排不是要搶使用者，它不在同一場競賽裡。這個自我定位很重要，因為它直接決定了後面所有取捨：凡是為了可讀性而犧牲的功能，都是刻意的。
規模是它最硬的賣點。引擎（迴圈、模型介面、context、工具、session）扣掉空行與註解是 1,161 行；連外層 CLI、config 與打包一起算，整個套件 24 個檔案、2,384 行實體行數、1,931 行淨行數。這個數字不是行銷詞，是可以被驗證的邊界：你可以在一個下午內把每一行讀完，並且在任意一行下中斷點、改掉、重跑。
主迴圈在 agent.py，平行工具執行也在那裡
倉庫的檔案佈局本身就是一份閱讀指南。入口是 corecoder/agent.py，213 行，註解直接標了「從這裡開始」，agent 迴圈與平行工具執行都放在同一個檔案。模型串流在 llm.py。其餘的 context 管理、工具定義、session 狀態各自成檔，全部短到可以一次讀完。
資料流大致是：使用者輸入進入主迴圈，迴圈把對話與工具定義送給模型，模型回傳的工具呼叫被解析後執行，結果再塞回對話，直到模型不再要求工具為止。README 描述的行為是，叫它修 buggy.py，它會讀檔、改碼、跑一次確認，然後自己回報改了什麼。這段敘述對應的正是那個迴圈加工具集，而不是某種隱藏的工作流程引擎。
幾個具體機制值得注意。context 壓縮分成三層，README 沒有展開每一層的觸發條件，只說明了它存在；如果你要評估壓縮策略是否適合長 session，得直接讀對應檔案的實作，這是文件較薄的一塊。工具執行是平行的，對照 213 行的總量，這代表平行化沒有動用額外的排程框架，而是寫在迴圈內部。session 狀態與 checkpoint 則對應 v0.4.2 加入的 /undo 功能。
版本推進也反映了核心之外長出來的部分：v0.5.0 加了權限層，v0.6.0 一次帶進 MCP、hooks 與 plan mode。這些都是為了讓最小核心在真實使用中站得住，而不是把核心變大。
裝起來只要三行，換供應商通常只要兩個環境變數
README 建議的路徑是 clone 後以 editable 模式安裝，因為這個專案本來就是給你邊讀邊改的：
git clone https://github.com/he-yufeng/CoreCoder cd CoreCoder pip install -e .
只想先跑起來的話，pip install corecoder 也可以。接著給它模型和金鑰。它預設說 OpenAI 相容 API，換供應商通常就是兩個環境變數。OpenAI 走 OPENAI_API_KEY；DeepSeek 是 OPENAI_API_KEY 加上 OPENAI_BASE_URL=https://api.deepseek.com 與 CORECODER_MODEL=deepseek-chat；本機 Ollama 則是 OPENAI_API_KEY=ollama、OPENAI_BASE_URL=http://localhost:11434/v1、CORECODER_MODEL=qwen2.5-coder。金鑰可以直接 export，也可以放進專案根目錄的 .env，啟動時會載入。
對於根本不提供 OpenAI 相容端點的供應商，有選用的 LiteLLM 後端：pip install "corecoder[litellm]"，README 說它能路由到一百多個供應商。這條路徑多一層依賴，換來的是覆蓋率，是否值得取決於你手上是什麼模型。
執行方式有兩種。corecoder 進互動式 REPL；corecoder -p "add error handling to parse_config()" 是一次性模式，做完就結束。這裡有個容易踩到的設計：在 -p 模式下，除非加上 --yes，否則它會拒絕執行會改動的工具。README 明確說這是刻意的。也就是說，你寫了一行指令期待它自動改檔，結果它停下來不動，不是壞掉，是權限層在運作。
另外，任何會改動磁碟或執行指令的動作都會先停下來徵求同意。這是 v0.5.0 權限層的核心行為。
「刻意留白」是設計主張，也是採用時最大的成本
README 反覆強調一句話：缺的東西不是沒做完，而是你該分支出去自己做的位置。這個說法在教學專案裡站得住，但對想直接拿來用的人來說，它就是限制清單本身。
最實際的一點是規模。1,161 行的引擎要同時容納迴圈、模型介面、context、工具與 session，每一塊能分到的複雜度都很有限。三層 context 壓縮在文件裡只有一句帶過，沒有說明閾值、觸發順序或失敗時的降級行為。當 session 拉長、工具輸出變大，這正是最容易出問題的地方，而它恰好是文件最薄的地方。你要嘛接受在遇到問題時自己讀實作，要嘛就得先做一輪壓力測試。
第二個限制是驗證範圍。README 說它對 DeepSeek、Qwen3 與 Kimi K2 透過單一 OpenRouter 相容端點做過端到端 smoke test，各自跑完完整迴圈；測試有 146 個，全綠。這是作者提供的資訊，不是第三方評測。它證明的是這條路徑能跑通，不是各種模型、各種任務類型下的穩定度。模型在工具呼叫格式上的遵從度差異很大，換一個沒被列出的模型，行為可能明顯不同。
第三個限制是定位本身。它不打算成為你的日常主力，README 寫得很清楚。如果你要的是能處理大型重構、有豐富 IDE 整合、有團隊協作功能的工具，CoreCoder 不是那個東西，而且它不打算變成那個東西。
和 aider 的差別不在功能表，在「讀完要多久」
README 的比較表把 aider 放在同一欄，並給了兩個具體數字：aider 是數萬行 Python，讀完要花幾天苦工；CoreCoder 引擎約 1,161 行，一個下午讀完。這個對比才是真正的差異點。
aider 的定位是終端機裡的 pair programming，功能面比 CoreCoder 完整得多，而且它是拿來每天用的。CoreCoder 的定位是教材加可 fork 的起點，功能面刻意精簡。兩者都會改你的檔案，都會跑指令，都需要你給模型和金鑰，但使用它們的心態完全不同：用 aider 是找一個助手，用 CoreCoder 是找一份可以拆的參考實作。
如果你真的要比功能，CoreCoder 在 v0.6.0 之後有 MCP、hooks 與 plan mode，v0.5.0 有權限層，v0.4.2 有 /undo checkpoint。這些讓它不只是玩具，但每一項的深度都和它的總行數相稱。把它們當成示範實作來讀，會比當成產品功能來期待更貼近實際。
真正該問的問題不是「哪個功能多」，而是「我需要的是助手還是範本」。需要助手的人選 aider；需要一個能在下午讀完、隔天就動手改的起點，選 CoreCoder。
維護成本、授權與升級時該看什麼
授權是 MIT，這對 fork 與商用最寬鬆，README 也把 fork 當成預期用法。實際的維護成本主要來自兩邊：一是上游改版，二是你自己分叉出去之後與上游的距離。
從版本節奏看，v0.4.2 到 v0.6.0 之間大約四天，依序加入 /undo checkpoint、權限層，然後一次帶進 MCP、hooks、plan mode。這種節奏對早期專案很常見，但也意味著 API 與行為還在移動。如果你打算跟著上游更新，每次升版都值得先看 release notes 再決定，特別是權限層與 hooks 這類會改變既有行為的改動。
反過來說，這個專案的設計本來就鼓勵你 fork 之後不再回頭。1,161 行的規模讓「自己維護一份」變成可行選項，而不只是口號。你要付出的代價是失去上游的修正，換來的是完全掌握。
LICENSE 是 MIT，具體的條款義務請自行閱讀 LICENSE 全文，本文不提供法律意見。依賴面則要注意選用性的 LiteLLM 後端會多帶一組依賴，不用就不要裝。
該不該動手：三個先驗證的點
如果你的目標是理解 coding agent 的骨架，或是在此之上長出自己的工具，CoreCoder 是目前少見的選擇：它小到能讀完，又真的能跑，README 說它讀寫檔案、執行 shell、生出 sub-agent、三層壓縮 context、回報 token 與花費，而且 146 個測試全綠。一個會動的參考實作，比一張架構圖有用得多。
如果你的目標是找一個每天用的助手，這個專案會讓你失望，而且它自己也知道。README 直說它不打算成為你的 daily driver，跑得起來是為了讓導讀不能說謊。
動手前先驗證三件事。第一，你的模型是否提供 OpenAI 相容端點；不是的話要先確認 corecoder[litellm] 這條路徑在你的供應商上可行。第二，Python 版本是否 3.10 以上，這是 README 標示的最低要求。第三，你能否接受 -p 模式下要顯式加 --yes 才會執行會改動磁碟的工具，這會直接改變你寫自動化腳本的方式。
最後一個具體的起點：clone 下來，pip install -e .，然後打開 corecoder/agent.py 的 213 行。那個檔案是整個 agent 的心臟，也是判斷這個專案對你有沒有用的最短路徑。
編輯結論
如果你要的是能拆開、能下中斷點、能 fork 的教學級 agent 引擎，CoreCoder 值得 clone 下來讀一遍；如果你要的是每天拿來改公司專案的助手，它刻意留白的部分會讓你付出補齊成本。動手前先確認三件事：你的模型是否走 OpenAI 相容端點（否則要裝 corecoder[litellm]）、你的 Python 是否 3.10 以上、以及你是否接受 -p 一次性模式下必須顯式加 --yes 才會執行會改動磁碟的工具。這三點決定了它在你手上是教材還是半成品。
社群筆記