摘要： xAI 於 7 月 15 日宣布 Grok Build 開源，coding agent 與 TUI 的整套原始碼放上 GitHub，範圍從 context assembly 到 tool-call dispatch。原始碼可檢視 agent loop、工具契約、介面與擴充機制，讓 harness 行為能直接審計。文章也指出可自行編譯、接本地推論並用一份 config.toml 管理設定，但公告未列版本號與授權條款。
Coding agent 換掉底層模型，成績未必跟著換；真正左右成績的是 harness——context 怎麼拼裝、模型回覆怎麼被解析、tool call 怎麼分派、出了錯怎麼兜底。7 月 15 日，xAI 宣布 Grok Build 開源，coding agent 加上 TUI，整套原始碼都放上了 GitHub。這次不是「核心保留、只開週邊」的姿態性開源——公告講得明白，從 context assembly 一路到 tool-call dispatch，整套機制都在公開範圍裡。
這次放出了什麼：四個部分，拼出完整的 agent loop
整個 codebase 拆開來讀，大致是四個部分。第一部分是 agent loop 的本體：context 怎麼拼起來、模型的回覆怎麼被解析、tool call 怎麼被分派——這裡正是 harness 的心臟所在；模型沒動、harness 一換，表現立刻走樣，原因正在於此。第二部分是工具組：讀檔、改檔、搜尋程式碼，外加執行 commands，每項工具吃進什麼、回傳什麼，契約全都列在源碼裡。第三部分，terminal UI：input handling、rendering、plan review，還有 inline diff viewer，人類靠這一塊檢查 agent 打算做什麼、動了哪些東西。第四部分是 extension system：skills、plugins、hooks、MCP servers、subagents 各自怎麼被載入、怎麼被呼叫。
四個部分接起來，等於把一個 agent 從裡到外完整切開看了一遍；這種機會在這個領域很少見——同類產品大多不是整套封死，就是只放出 SDK 那層。並排著讀，還能讀出彼此的分工：loop 解釋了模型相同、harness 不同時，成績為何跟著變；tools 框出的是 agent 的真實攻擊面，讀檔、寫檔、跑命令，樣樣都是高權限的操作；人類的判斷就是從 TUI 進到流程裡的，plan review 和 inline diff 則是能攔下來檢查的關卡；生態能延伸到哪裡，邊界就畫在 extension system 上。
為何開源：想拿到可靠的 harness，得回到源碼
官方解釋動機的那句話值得照抄：開源是打造 robust and reliable harness 的最直接途徑——底下起碼墊著兩層意思。第一層：harness 可不可靠，文件保證不了——文件可以把 extension 的格式描述出來，可錯誤處理怎麼走、載入的先後順序、權限邊界畫在哪裡，行為實際上就由這類細節決定，而它們只寫在源碼裡。第二層：官方把原始碼的角色講得非常直白——它就是 definitive reference，對 hooks、skills、plugins、MCP servers、subagents 這五種機制撐起的擴充生態而言，唯一有權威的依據就是源碼，文件只要過時或語意含糊，一律以源碼為準。這也是給維護者的雙向承諾：版本號跟 license 條款公告裡沒寫也罷、文件追不上變動也好，讀者手上起碼還有源碼能拿來對質。
對採用者來說，帶來的是實打實的審計能力——某個 hook 到底能不能動 prompt、MCP tool 會收到哪些 context、subagent 會繼承哪些設定——這三個問題今後翻程式碼就有答案，不必再靠行為側寫去猜，也不用再聽客服的說詞。
Local-first 路線：自己 compile、本地跑 inference、一份 config.toml
公告還有另一個壓箱的重點：fully local-first 的路徑——你可以自己動手 compile、讓 agent 改接本地 inference，所有設定都交給一份 config.toml 管。對在意隱私或計較成本的場景來說，這就是分水嶺：資料從頭到尾不必離開那台機器，雲端額度的錢也不必再掏。而「全部設定都由 config.toml 驅動」還有第三層效果：設定自此只有單一真相來源；agent 的行為變得可重現、能進版本控制；團隊要交接時，把整份設定檔交出去就行，不必靠口頭描述把環境重建回來。
但 local-first 不會自動等於安全，這條界線得自己畫：跑在本地機器上的 agent 照樣可能讀到錯的目錄、執行危險的命令、或把環境變數漏出去。這些行為，開源之後你確實有能力逐一檢查；但檢查本身不會自動發生，還是得你來做：sandbox 隔離、secrets 管理、命令允許清單，部署之前每一項都要親自確認——漏了哪一項，日後事故報告開頭那一段，寫的就是它。
這份 codebase 該給誰讀
收穫最大的會是三種人。想弄懂 agent loop 怎麼設計的，從第一部分讀起：context 組裝起來的方式、tool dispatch 背後的取捨，最難光靠文件學到。要寫 extension 的，直接翻第四部分：五種擴充機制怎麼載入、怎麼被呼叫，照公告的說法，源碼本身就是 definitive reference。想把工作站做成 local-first 的，看設定這條線：自己編譯、配本地推論，這個組合本身就能完全取代對雲端的依賴。
最後兩個務實提醒：版本號與 license 條款，公告裡都沒出現，正式把程式碼納入依賴之前，授權要先自行確認；真要把整個 repo fork 回來自己養一套分支，不如換個做法——把這份源碼當成 harness 的教材，拿自己那套 context 組裝方式跟工具契約來互相比對，對多數團隊，這是槓桿更高的用法。模型一季一換，會留下來的是 harness 本身的設計模式——這正是這份源碼長期下來最有價值的地方。