K1 論文詳解

背景

當我們談論一個 AI agent 有多強，往往只想到它背後的基礎模型（foundation model）夠不夠聰明。但實際上，agent 的能力有一大部分來自它的「harness」——也就是負責組裝 prompt、管理狀態、呼叫工具、協調多輪執行流程的那層程式碼骨架。無論是終端機操作型 agent（如 Terminus-2），還是多介面的程式碼助手（如 Codex，涵蓋 CLI、TUI、app-server、沙盒環境），這層 harness 都會隨著模型更新、API 變動、環境需求改變而必須不斷修改。

問題是，這類 production harness 通常規模龐大、模組間高度耦合，而且「行為」（behavior）往往分散在多個檔案、多個執行階段，甚至跨越狀態暫存器（state register）才能完整實現。舉例來說，Codex 這個專案本身就有 2,267 個檔案、34,363 個內部函式、140 個執行階段。當開發者或 coding agent 收到一個修改需求（例如「讓某個完成判斷更穩定」），第一步永遠是「這個行為到底寫在哪裡」——這件事被稱為 behavior localization（行為定位）。

現有的程式碼搜尋、repository 索引、長文本處理技術雖然能協助檢閱程式碼，但它們解決的是「怎麼讀」，而不是「行為對應到哪些程式碼」這個核心的映射問題。因為修改需求描述的是「系統應該做什麼」，而 repository 卻是照檔案與模組組織的，兩者存在根本性的落差。這個落差沒被解決之前，即使給 agent 再大的 context window，它仍然得靠自己一點一滴地在程式碼海中摸索，這正是本論文要解決的瓶頸。

方法

論文提出兩個核心設計：Harness Handbook（行為手冊）與 Behavior-Guided Progressive Disclosure，簡稱 BGPD（行為導向的漸進式揭露）。

Harness Handbook 是一個以「行為」為中心、自動從 harness codebase 合成出來的表示法，靠靜態分析加上 LLM 輔助結構化產生，把每個行為明確連結回它對應的原始程式碼位置。它分成三層加一個補充視角：

• L1（系統總覽）：描述整體架構與執行模型；
• L2（元件總覽）：說明各個執行階段（stage）的職責與資料流動；
• L3（實作條目）：具體對應到程式碼的條目，附帶可驗證的原始碼定位資訊（source locator）；
• 另外還有一個 state-register 視圖，專門追蹤那些跨階段共享的狀態暫存器讀寫點，這正是最容易被關鍵字搜尋遺漏的地方。

建構流程是三個確定性（非隨機、可重現）階段：

1. 靜態事實抽取：用語言專用的 adapter 直接解析 repository，抽出函式、邊界、簽名與呼叫圖，這步完全不靠 LLM；
2. 行為組織化：分兩種模式，一種是「以函式為葉節點」（function-as-leaf，適用於 Terminus-2 這類從可信種子骨架出發的系統），另一種是「以檔案為葉節點」（file-as-leaf，適用於 Codex 這類需要從 repository 推斷階段結構的系統）；
3. 階層式合成：把階段骨架轉換成 L1–L3 的文件樹，每個節點都附上經過驗證、對應到目前程式碼的原始碼定位。

有了 Handbook 之後，BGPD 讓 agent 依照「由粗到細」的方式導覽：先看系統層級的行為索引，逐步下探到具體元件與實作細節，最後把候選的程式碼位置拿去跟目前的原始碼做驗證，確認沒有過時或錯位，才進入編輯規劃階段。這種方式本質上是把「行為定位」拆解成可驗證的檢索步驟，而不是一次性丟給模型去大海撈針。

實驗結果

研究團隊在兩個真實的開源 harness 上做評測：Terminus-2（Python，6 個原始檔、103 個函式、20 個執行階段、106 個 L3 條目，是一個透過 tmux session 執行「觀察—決策—行動」迴圈的終端機 agent）與 Codex（Rust，2,267 個檔案、34,363 個內部函式、140 個執行階段、2,267 個 L3 條目，是涵蓋多種介面的程式碼 agent）。

在整體修改計畫品質（plan quality）上：

• Codex 的整體勝率（win rate）從 28.3% 提升到 38.3%，增加 10.0 個百分點；
• Terminus-2 的勝率從 26.7% 提升到 45.6%，增加 18.9 個百分點；
• 其中「定位」（localization）這個維度增幅最大：Terminus-2 +12.2 點，Codex +2.2 點。

更值得注意的是，這些提升並非靠燒更多 token 換來的——反而更省：

• Codex 的規劃 token 用量從每次請求 0.102M 降到 0.089M，減少 12.7%；
• Terminus-2 從 0.058M 降到 0.053M，減少 8.6%。

對照獨立、由更強模型產生的參考計畫（reference plan）做比對時：

• Codex 的 symbol 層級 F1 提升 18.8 點；
• Terminus-2 的檔案層級 F1 提升 10.6 點；
• 「完全答錯」（wrong，即零重疊）的比例最多下降 25.9 點。

按修改需求類型細分也一致向好：查詢式修改（不指名具體目標）Codex 提升 26.7 點、Terminus-2 提升 23.3 點；跨檔案端到端能力新增（cross-file）Codex +16.3 點、Terminus-2 +20.0 點；最難的「對搜尋不友善」案例（search-hostile，也就是實作藏在鏡像或 fallback 路徑中）Codex +20.0 點、Terminus-2 +33.3 點——這正是傳統關鍵字搜尋最無力的場景。按難度細分，六組比較的增幅介於 3.7 到 33.3 個百分點之間，顯示 Handbook 輔助對簡單和複雜任務都有幫助。

論文附錄還舉了一個具體案例：在 Terminus-2 的一次「三次連續確認才判定完成」需求中，規劃 agent 透過 Handbook 索引先定位到 Completion Gate 階段與對應的暫存器，接著發現該暫存器的寫入點牽涉初始化與每輪重置邏輯，最終在 terminus_2.py 中精確找出三處需要修改的位置，把原本的布林旗標邏輯改成整數計數器。這類分散在多處、彼此透過狀態耦合的行為，正是關鍵字搜尋最容易漏掉的類型。

意義

這篇論文把焦點從「agent 能不能生成正確的程式碼修改」往前移了一步，指出真正的瓶頸其實是「知道該改哪裡」。過去大家傾向於用更強的模型、更長的 context window、更好的程式碼搜尋工具去解決這個問題，但論文證明：把「行為」明確地組織成可導覽、可驗證的表示法（Harness Handbook），再搭配漸進式揭露的檢索策略（BGPD），能讓相對較弱的規劃模型在定位精準度上逼近更強模型的水準,而且用更少 token 完成。

對於正在打造或維護 agent harness 的團隊來說，這意味著與其把心力全押注在換更貴的模型上，不如投資在把系統的「行為—程式碼」映射關係顯性化。尤其當 harness 規模擴大到數千個檔案、數萬個函式時（就像 Codex 這種真實案例），這種結構化的行為手冊可能會成為維護大型 agentic 系統不可或缺的基礎設施，就像過去的 API 文件或架構圖之於傳統軟體工程一樣。這也呼應了一個更大的趨勢：agent 系統的可演進性（evolvability），不只取決於模型能生成什麼，更取決於整個系統是否「可讀、可導覽、可修改」。

背景

近年來,文字生成圖像(text-to-image)與指令式圖像編輯的能力快速進化,但真正頂尖的表現幾乎都被閉源系統壟斷。像 Nano-Banana-Pro、GPT-Image-2 這類系統展現出的生成品質與編輯精準度,遠遠拋離大多數開源模型。問題在於,這些閉源系統的強大往往不是單一模型的功勞,而是「系統級整合」的結果——背後可能疊加了多個子模型、重寫(rewriting)模組、後處理與檢索增強等工程手段,但具體怎麼做,官方幾乎不公開任何細節。這使得開源社群長期處於「知道结果強,但學不到方法」的窘境。

Boogu-Image-0.1 就是在這個背景下誕生的計畫。研究團隊提出一個問題:如果不靠堆疊龐大算力與海量私有數據,單純從「模型理解能力、數據品質、訓練流程」三個環節做針對性優化,再輔以推理階段的智能體式擴展(agentic inference-time scaling),開源模型能把差距縮小到什麼程度?他們給出的答案相當激進——僅用 2.0862 億(208.62 million)張獨特圖片、理論訓練成本約 40 萬美元,就打造出一個統一理解與生成的模型家族,並在標準 benchmark 上追平甚至超越其他開源模型,逼近頂尖閉源系統的水準。這個資料規模,按論文自述,大約只有閉源系統的十分之一量級,凸顯了「用資料效率換算力」的核心主張。

方法

Boogu-Image-0.1 家族包含四個變體:Base(標準文生圖)、Turbo(快速推理版本)、Edit(指令式圖像編輯)以及 Edit-Turbo(快速編輯版本),四者共用約 100 億(10B)參數規模的骨幹網路,並額外釋出量化的 fp8 版本以降低部署門檻。

在架構選擇上,團隊沿用開源社群成熟的 FLUX.1 VAE 作為圖像的隱空間編碼器——儘管論文中也坦言這顆 VAE 的重建損失(reconstruction loss)相對較大,是未來可以優化的方向之一。整體訓練策略並非依賴堆更大的模型或更多的算力,而是三管齊下:

1. 模型理解能力的針對性提升:強化模型對文字語意、版面配置、雙語(中英文)文字渲染的內在理解,這也是模型能同時做好「簡單文字」與「密集文字」排版的關鍵。
2. 數據品質而非數量取勝:在僅有 208.62 million 張圖片的規模下,團隊更注重數據的篩選、清洗與配對品質,而非單純擴大資料量級。
3. 訓練流程優化:透過改良的訓練 pipeline,在有限運算預算下擠出更高的樣本效率,使得 Base 模型的理論訓練成本被壓低到約 40 萬美元——這個數字相較於一般認知中訓練頂尖生成模型動輒數百萬美元的量級,是相當顯著的成本壓縮。

除了訓練端的優化,論文另一個重點是推理階段的智能體式擴展(agentic inference-time scaling)。也就是說,模型在推理時不只是「一次生成」,而是引入類似智能體的迭代機制,在生成或編輯過程中進行自我檢查、修正與多輪擴展,藉此在不增加模型參數的前提下,進一步拉升最終輸出品質——這也是論文強調「即便算力極度受限,仍能大幅提升生成與編輯表現」的實作手段之一。

實驗結果

為了評估模型表現,團隊建立了名為 Boogu Arena 的評測機制——一套以大型語言模型作為裁判(LLM-based preference evaluation)的競技場,涵蓋超過 1,000 條(1K+)測試提示詞(prompts),並產出 ELO 排行榜,橫向比較領先的閉源與開源系統。在這套評測體系下,Boogu-Image-0.1 與 Z-Image-Turbo、Qwen-Image-2512 等主流開源模型,以及 Nano-Banana-Pro、GPT-Image-2 等閉源系統同台較量。

從公開的定性比較來看,Turbo 版本在「攝影寫實」與「簡單文字渲染」情境下表現亮眼,達到接近滿分的評價等級;Base 版本則在「簡單文字」與「密集文字排版」兩項情境上都拿下最高評等,顯示其在雙語(中文/英文)文字渲染上的優勢——這正是許多開源文生圖模型的弱項,尤其是中文長文字的排版準確度,過去往往只有頂尖閉源模型才能穩定處理。

論文的整體結論是:Boogu-Image-0.1 在標準 benchmark 上「持續追平或超越」其他開源模型,並且在多項指標上「逼近」領先的閉源系統表現。雖然論文未在摘要與公開頁面中列出如 GenEval、DPG-Bench 等傳統學術 benchmark 的具體分數細節(這部分應詳見論文完整技術報告與附錄),但其透過 Boogu Arena 的大規模人類偏好式評測,提供了更貼近實際使用場景的橫向比較基準。值得注意的是,這些成果是在僅 208.62 million 訓練圖片、約 40 萬美元訓練成本的條件下取得,對比動輒需要數千萬甚至更高預算的閉源系統,呈現出相當可觀的「性價比」落差。

意義

Boogu-Image-0.1 最大的價值,不只是又一個「開源刷榜」的模型,而是它示範了一條「資料效率優先」而非「算力堆疊優先」的技術路線。當前多模態生成領域普遍存在的迷思是:想要逼近 Nano-Banana-Pro、GPT-Image-2 這類系統,似乎非得砸下天文數字的訓練預算與海量私有數據不可。Boogu-Image-0.1 用實際結果反駁了這個假設——透過在模型理解、數據品質、訓練流程三個環節做精細優化,再搭配推理階段的智能體式擴展,即使在「高度受限的運算預算」下,依然能大幅拉近與頂尖系統的差距。

對開源社群而言,更關鍵的是團隊選擇以 Apache 2.0 授權,完整釋出模型權重、程式碼與訓練「配方」(recipes)。這代表其他研究者與開發者不僅能直接使用四個變體(Base、Turbo、Edit、Edit-Turbo)進行文生圖與指令式編輯,還能複製甚至進一步優化其訓練 pipeline,而不必從零摸索。這種「開放方法論」而非僅「開放權重」的做法,對於解決當前生成式 AI 領域「閉源系統靠系統工程取勝、卻不透露細節」的資訊不對稱問題,具有指標性意義。

從產業角度看,約 40 萬美元的理論訓練成本,加上僅 208.62 million 張圖片的資料規模,大幅降低了中小型團隊、學術機構甚至個人開發者參與統一多模態理解與生成模型研發的門檻。若後續能有更多團隊在此基礎上驗證、覆現並擴展 Boogu-Image-0.1 的方法論,有機會加速整個開源生成式視覺模型生態系的疊代速度,縮小與閉源巨頭之間的差距,也讓雙語(尤其是中文)文字渲染這項長期被開源模型忽略的能力,獲得更多關注與投入。

背景

現在的 coding agent（像是能自動修 bug、跑測試、呼叫外部工具的程式碼代理人）在實際運作時,會不斷重複一個迴圈:先發出一個動作(例如呼叫某個工具或執行程式碼),接著讀取外部回傳的觀察結果(observation),再根據這個結果繼續往下推理、決定下一步。這個「動作→觀察→接續」的迴圈,對 agent 的實用性至關重要——如果模型不擅長把工具回傳的內容正確地「接」進後續推理裡,agent 就容易斷線、瞎猜或忽略關鍵資訊。

問題在於,目前主流的大型語言模型都是用「從左到右」(left-to-right)的方式做預訓練:模型只學會「根據前文預測下一個字」,卻很少被系統性地訓練「根據後面才出現的資訊,回頭填補中間的邏輯」。而 agent 迴圈剛好需要後者——模型要先「呼叫」一個工具,再根據之後才拿到的回傳值,把後續程式碼或推理補完整。

本篇論文(arXiv:2607.12463,作者來自滑鐵盧大學、卑詩大學、NVIDIA、Verdent AI 與 Vector Institute 等機構)提出一個關鍵觀察:這種「呼叫者(caller)先綁定參數、被呼叫者(callee)在別處算出回傳值、下游程式碼再消費這個值」的結構,其實跟一般函式呼叫(function call)在語法上是同構的(structurally isomorphic)。而函式呼叫在網路規模的原始程式碼中隨處可見——這代表我們不需要昂貴的 agent 互動資料,就能從普通的 GitHub 程式碼中,大量提煉出訓練 agent「接續推理」能力所需的訊號。

方法

作者提出的核心方法是 function-aware fill-in-the-middle(FIM)中期訓練(mid-training)——插在一般預訓練與 agentic 後訓練(post-training)之間的一個自監督訓練階段。

具體流程包含以下幾個關鍵設計:

1. 函式選取(用程式依賴圖分析):先用程式依賴圖(Program Dependency Graph, PDG)分析原始碼,找出適合被「挖空」的函式,而不是隨機挖空。
2. 複雜度與可推斷性雙重篩選準則:每個候選函式會計算兩個分數——複雜度分數 Ĥ(依據程式碼行數、循環複雜度、巢狀深度)以及可推斷性分數 Î(綜合五種上下文線索:呼叫端的具體程度、被呼叫次數、函式簽名的資訊量、docstring 是否存在、類別耦合程度)。兩者以調和平均數結合並施加難度懲罰,挑出「難度適中、但context足以推斷」的函式來挖空,避免挖出根本無法從上下文猜出的函式,也避免挖出太簡單無意義的函式。
3. 多函式挖空:約 20% 的訓練樣本會同時挖空 2–3 個相關函式(而非單一函式),模擬更複雜的多步驟推理情境。
4. 思維鏈(CoT)強化:用 Gemini-3-Flash 為每個被挖空的函式生成逐步推理的理由(rationale),並經 LLM 裁判依五個維度加上可行性做品質過濾,把這段推理鏈嵌入 FIM 的中間空格區塊中——也就是說,模型不是直接背答案,而是先寫出推理過程,再補出函式本體。

訓練語料來自 968 個 GitHub 倉庫(篩選以寬鬆授權為主,80%以上為 MIT/Apache/BSD),並刻意做過去污染處理,排除掉與 SWE-Bench 來源重疊的倉庫,最終產生約 40 萬筆 FIM 樣本、共 2.6B tokens 的純 Python 語料。

訓練設定:對 Qwen2.5-Coder-Instruct(7B / 14B)與 Qwen3-8B 三個基礎模型各做 1 個 epoch 的 FIM 中期訓練,學習率 1.0×10⁻⁵,有效 batch size 128,使用 8 張 NVIDIA H100 80GB GPU,完整重現整套流程約需 5,760 GPU 小時、約 30 天。中期訓練完成後,直接套用既有、未經修改的 agentic 後訓練管線(R2E-Gym、SWE-Smith,以及針對 Qwen3-8B 的 SWE-Lego),藉此驗證這個中期訓練階段是否能「即插即用」地帶來額外收益。

實驗結果

在 SWE-Bench-Verified(修復真實 GitHub issue 的標竿測試)上,加入 function-aware FIM 中期訓練後:

• Qwen2.5-Coder-7B:15.0% → 17.8%,提升 +2.8 分
• Qwen2.5-Coder-14B:26.2% → 29.2%,提升 +3.0 分
• Qwen3-8B:31.8% → 35.0%,提升 +3.2 分

在 SWE-Bench-Lite 上提升更明顯:

• 7B:11.33% → 15.0%,+3.67 分
• 14B:18.0% → 22.0%,+4.0 分
• 8B:27.3% → 32.7%,+5.4 分

值得注意的是,這個提升在兩套不同的後訓練管線(R2E-Gym、SWE-Smith)上都成立,並且在非 Qwen2.5 系列的基礎模型(改用 SWE-Lego 管線訓練的 Qwen3-8B)上也一樣有效,顯示這不是某個特定管線的巧合,而是具有一定的泛用性。

更關鍵的是跨領域遷移效果(以 14B 模型搭配 R2E-Gym 為例):

• LiveCodeBench(非 agent 的純程式碼生成 benchmark):24.1% → 35.2%,大增 +11.1 分
• BFCL(工具呼叫 benchmark):15.8% → 18.2%,+2.4 分
• τ-bench(多輪對話工具使用 benchmark):3.4% → 7.3%,+3.9 分

論文也分析了行為層面的變化:agent 從「負面觀察結果」(例如工具回傳錯誤或測試失敗)中恢復並繼續正確推理的比率,從 24.8% 提升到 28.8%;在需要處理多個函式的單檔案任務上,增益達 +9.1 個百分點,遠高於單函式任務的 +2.1 個百分點;此外,「完全沒有產出修補(patch)」的失敗案例被幾乎完全消除。

消融實驗也驗證了各設計元件的貢獻:拿掉思維鏈理由只帶來 +1.18 分的提升,而加入 Gemini-3-Flash 生成的理由則額外貢獻 0.75 分(模型自產的理由則能還原 Gemini 版本約 70% 的效果);在函式選取演算法上,隨機挖空的平均分數是 13.95,只用 PDG 篩選可到 14.85,而完整的 PDG + 複雜度 + 可推斷性篩選則達到 15.60;在挖空粒度上,單函式挖空平均 15.60 分,而混合 80% 單函式、15% 雙函式、5% 三函式的組合則進一步提升到 16.10 分。

意義

這篇論文的核心貢獻,是指出一個過去被忽略、卻俯拾即是的訓練訊號:函式呼叫本身就是 agent「動作—觀察—接續」迴圈的天然縮影。透過巧妙的 FIM 挖空設計(而非蒐集昂貴的真實 agent 互動軌跡),就能讓模型在一般的程式碼語料裡,自然學會「先做出承諾(呼叫)、再根據之後才揭曉的結果調整推理」這種能力。

更重要的意涵在於它解決了一個實務上很棘手的問題——agentic 後訓練往往會侵蝕模型原本的通用能力(即所謂的 capability erosion):模型被大量訓練去適應特定 agent 任務格式後,反而在非 agent 的純程式碼生成(如 LiveCodeBench)或其他工具使用場景(τ-bench、BFCL)上退步。而這篇論文顯示,只要在後訓練之前,先插入這個以 Python 程式碼為主的中期訓練階段,「函式呼叫的歸納偏見(inductive bias)」竟然能夠存活過後續的 agentic 後訓練,並持續在多個不同領域的 benchmark 上帶來正面遷移——即便中期訓練語料完全只包含 Python 程式碼,效果依然能擴散到工具呼叫、多輪對話等其他情境。

對於想要打造更強 coding agent 的團隊而言,這代表一種成本相對低廉、且與現有後訓練管線相容的「加值步驟」:不需要重新設計 RLHF 或強化學習環境,只需要在既有預訓練與後訓練之間,插入這樣一段以程式依賴圖為基礎、精心設計挖空策略的中期訓練,就能同時提升 agent 在專項任務(SWE-Bench)與通用能力上的表現。論文也坦承目前僅驗證於 Python 語料與少數模型組合,對其他程式語言與非 Qwen 系列基礎模型的適用性仍待更多證據補強,但這個「函式呼叫 = agent 迴圈」的洞察,提供了一個值得後續研究延伸的通用訓練範式。