讓本機 Qwen3.8 Flash Next UD-IQ4_XS 主導開發：按需派工 GPT-6.1 Sol、GPT-6 Astra，並整合 Codex 圖片生成服務

在上一篇 Strata 實測中，我已經用 64 GB RAM 與 RTX 5060 Ti 16 GB 執行 Qwen3.8-Flash-Next UD-IQ4_XS。模型能在自己的電腦上運作之後，下一個問題是：如何讓它接手日常開發，並在需要時找得到合適的外援？

先前的嘗試，是由雲端模型派工作給本機 Qwen，再透過 code review 與 harness 調整它的工作方式。這次我把主導權交給本機 Qwen，讓 OpenCode 提供讀檔、修改、測試與派工能力；GPT-6.1 Sol 和 GPT-6 Astra 則成為可按需呼叫的子代理。圖片生成另外封裝成工具，透過本機 Codex 執行。

截至 2026 年 10 月 25 日，這套設定已完成新對話預設模型驗證、兩條子代理路由測試，以及圖片生成後交回 OpenCode 開啟的完整流程。以下記錄實際採用的設定、途中遇到的問題，以及這些測試能說明的範圍。

本機 Qwen 負責主流程，雲端模型提供外援

這套配置包含三個代理與一個圖片工具：

這裡的分工是我為工作流設定的角色，沒有把 Sol 限制成只能寫程式，也沒有把 Astra 限制成只能提建議。兩個外援在取得明確的修改範圍後，都可以直接實作與測試；如果任務只要求診斷或 review，就維持唯讀。

Qwen 保留規劃與驗收責任。簡單修改通過驗收後即可交付，不固定為每次修改安排另一個模型再 review 一輪。

實際協作關係可以整理成：

「本機」描述的是 Qwen 的推論位置，以及 Codex CLI 的啟動位置。Sol、Astra 與圖片生成仍會使用雲端能力；交給外援的任務內容也會隨請求送往雲端。

先把派工條件與交接內容寫清楚

我在 Qwen 的工作指示中，設定了幾個判斷原則。

目標清楚、範圍可控、驗收條件明確的任務，由 Qwen 自己處理。方向已經確定，但需要較大的跨檔案實作或持續除錯時，可以交給 Sol。遇到根因不明、證據互相矛盾，或需要架構取捨的問題，則可以直接找 Astra。

這表示 Qwen 不必先找 Sol，失敗後才能找 Astra。派給誰取決於問題本身。

另一條規則是：同一問題經過兩次有實質差異的修正仍無進展，或開始重複已證明無效的方法時，應停止自行重試並尋求外援。單純重跑指令或換個說法，不算新的修正；測試仍然失敗，也不一定代表沒有進展。

這些是寫在代理提示詞中的工作規範，仍由模型判斷如何執行。目前沒有另外實作失敗次數計數器或自動切換狀態機。

子代理會取得新的對話，因此每次交接都要求包含：

• 任務目標與可觀察的驗收條件。
• 工作區、相關檔案、現有差異與不可改動的限制。
• 這次是唯讀診斷，還是允許修改及測試。
• 錯誤輸出、重現方式、已嘗試的方法與結果。
• 需要回報的修改、驗證結果與尚未確認事項。

對共享檔案，我另外寫入「同一範圍同時只由一名代理修改」的規範。外援接手後，Qwen 暫停修改該範圍，直到結果交回；已經套用的 patch，也不應再套用一次。這項協作規則目前同樣由提示詞約束，沒有新增檔案鎖。

OpenCode 的模型與權限設定

本次使用 OpenCode 2.0.32，設定放在使用者的全域設定目錄。Windows 上的位置為：

C:\Users\<你的帳號>\.config\opencode\
├─ opencode.json
├─ agents\
│  ├─ qwen-main.md
│  ├─ sol.md
│  └─ astra.md
└─ plugins\
   └─ codex-image\

OpenCode V2 可以使用 Markdown 檔定義代理，包含模型、模式、權限與工作指示；全域代理檔會套用到不同專案。以下節錄這次已套用的設定，省略既有 provider、MCP 與其他外掛內容。OpenCode 代理文件

{
  "default_agent": "qwen-main",
  "model": "strata/qwen3.8-flash-next-unsloth-ud-iq4_xs",
  "permissions": [
    {
      "action": "subagent",
      "resource": "*",
      "effect": "deny"
    }
  ]
}

這段應合併到既有設定，不宜用它直接覆蓋整份檔案。它的前提是 Strata provider 與 OpenAI 登入已經配置完成，模型識別碼也能被目前的 OpenCode 環境解析。這裡保留的 strata/...unsloth... 是既有服務的設定識別碼；本次路由測試沒有重新核對後端實際載入的權重版本。

在 qwen-main.md 中，主代理只開放兩個派工對象：

---
mode: primary
model: strata/qwen3.8-flash-next-unsloth-ud-iq4_xs
permissions:
  - action: subagent
    resource: "*"
    effect: deny
  - action: subagent
    resource: sol
    effect: allow
  - action: subagent
    resource: astra
    effect: allow
---

sol.md 的模式、模型與派工權限為：

---
mode: subagent
model: openai/gpt-6.1-sol
permissions:
  - action: subagent
    resource: "*"
    effect: deny
---

astra.md 則使用：

---
mode: subagent
model: openai/gpt-6-astra
permissions:
  - action: subagent
    resource: "*"
    effect: deny
---

以上是設定區段的節錄。Markdown 本文會成為該代理的 system prompt，取代 provider 的預設提示詞，因此正式代理檔也保留完整的開發、工具使用、交接與驗收規範。只有模型名稱與權限並不足以表達整套工作方式。

全域的 subagent: "*" 拒絕規則仍然保留。OpenCode 會先套用全域權限，再套用代理自己的規則，最後一條符合條件的規則生效，因此 Qwen 可以額外允許 Sol、Astra；沒有另外開放的代理，則繼續受全域規則限制。OpenCode 權限合併與規則順序

目前的派工關係如下：

我最後保留了這個單層結構，沒有新增 Qwen worker，也沒有加入多層派工或額外的 Strata 併發排程。這讓每次任務的責任與交接比較容易追蹤。

修改設定後還有一點容易忽略：既有對話會保存自己的代理與模型選擇。新預設不會自動取代舊對話的選項，因此我另外建立未指定代理與模型、也沒有被專案設定另行覆蓋的新對話，確認它確實使用 Qwen。

完整代理檔、圖片外掛與合併設定範例已整理為文章配套原始碼。重現時先確認 OpenCode 的 Strata 與 OpenAI 連線可用，再單獨確認本機 Codex CLI 已完成 ChatGPT 登入；兩者的登入狀態需要分別檢查。接著備份既有設定、放入代理檔與外掛、合併設定並重新載入，最後建立新對話逐項測試。配套說明列出檔案位置與檢查指令。

用實際讀檔驗證 Sol 與 Astra 的路由

模型出現在選單中，只代表它可以被選取。為了確認派工真的可用，我安排了一個小型測試：讓 Qwen 分別啟動 Sol 與 Astra，要求它們讀取工作區內的測試檔案，回傳預先寫好的值。

驗證時除了看回覆內容，也檢查子對話紀錄中的工具執行與模型識別碼。

這次測試明確要求 Qwen 使用兩個外援，任務也沒有涉及修改程式。它證明了連線、派工、工具讀檔與結果回傳可以運作。

至於 Qwen 能否在真實開發中選對求助時機，以及這種分工是否提高完成率、縮短時間，仍需要另外設計程式任務來評估。角色分工已寫入設定，實際開發效益還需要持續量測。

把本機 Codex 的圖片能力接成工具

圖片生成採用另一條路徑。

OpenCode 已經可以透過既有登入使用 Sol 與 Astra，但圖片生成仍需要有相應的工具入口。因此我先確認本機 Codex 能生成圖片，再把流程封裝成 OpenCode 外掛，提供名為 codex_image 的工具。

這是本次實作的自訂工具。僅在提示詞中寫上 codex_image，不會讓尚未安裝外掛的 OpenCode 自動具備這項能力。

實際呼叫流程為：

1. Qwen 把用途、主題、構圖與風格整理成圖片需求。
2. OpenCode 呼叫 codex_image。
3. 外掛啟動本機 Codex CLI，確認使用既有 ChatGPT 登入。
4. Codex 使用內建圖片生成能力，產生圖片檔案。
5. 外掛檢查檔案後，複製到目前專案。
6. Qwen 使用 read 開啟交付檔案；工作指示另外要求檢視圖片是否符合需求。

這次圖片工具內部固定使用 GPT-6.1 Sol、low 推理設定執行 Codex 任務。這個執行層與 OpenCode 的 sol 子代理分開，圖片測試也沒有先委派 Sol 或 Astra。Sol 在這裡負責執行圖片任務，實際圖片產出由 Codex 的圖片生成能力完成。

OpenAI 的文件說明，Codex 內建圖片生成會計入一般 Codex 使用額度；使用 API key 則適用 API 計費路徑。這次沿用既有 ChatGPT 登入，沒有另外配置 Images API key，也沒有加入失敗後自動改走 API key 的替代路徑。Codex 圖片生成說明

因此，「整合既有訂閱」仍然會消耗額度。本次測試沒有量測每張圖片實際扣除多少額度，也沒有把 API token 價格換算成訂閱成本。

第一次卡住的地方是圖片交付

本機 Codex 的前兩次測試都產生了圖片，但整體流程沒有立即通過。

問題出在最後一步：當子程序嘗試把圖片複製到指定的專案位置時，被檔案權限政策阻擋。圖片已經存在，使用者要的交付位置卻沒有完成寫入，所以仍不能把整個流程算成成功。

正式版本把兩項工作分開：

• Codex 依既有圖片生成機制保存原始產物。
• OpenCode 外掛確認來源與圖片內容後，負責複製到專案。

這樣保留了 Codex 子程序的唯讀 sandbox 設定，也讓輸出位置與檔案檢查由呼叫端處理。

驗證不只看副檔名。外掛會檢查檔案是否屬於本次新建的生成目錄、時間與真實路徑是否合理，以及 PNG 結構與像素資料能否解碼，避免把舊圖片或無法開啟的檔案當成新結果。

另有一個安裝時遇到的小問題：外掛一開始被全域目錄自動載入，又在設定陣列中明確加入，形成重複註冊。移除重複項目後，外掛清單只保留一筆 local.codex-image。

完整流程交回一張可開啟的 PNG

最後一輪測試從 OpenCode 的 Qwen 主代理開始，要求生成陶瓷赤狐擺飾圖片。工具接收的需求範例如下：

{
  "prompt": "一隻陶瓷赤狐擺飾，柔和自然日光，米白背景，寫實產品攝影，無文字。",
  "output_name": "fox"
}

實際驗證結果為：

34.7 秒是這一次 runner 工具段的時間，包含登入檢查、Codex 執行、圖片驗證與複製；它不是整段 OpenCode 對話的等待時間，也不是多張圖片的平均速度。

工具每次會建立獨立的輸出資料夾，保存圖片及相關紀錄。輸出位置的一般形式為：

<目前專案>/output/codex-images/<作業名稱>-<唯一識別碼>/image.png

這次還有一項驗證界線：所用 Codex CLI 的 JSON 事件沒有提供完整的內建圖片工具呼叫紀錄，所以結果保留 nativeToolCallVerified: false。我們確認了本次新生成檔案、檔案可讀性與 OpenCode 交付流程，但沒有把模型對工具名稱的自述當作完整的內部呼叫稽核。

配套測試方面，runner 的 21 項測試與工具入口的 6 項測試通過；另外兩項建立符號連結或 junction 的測試，因測試環境不允許建立連結而跳過。

平常使用時，直接描述工作即可

完成工具安裝後，我在 Qwen 的指示中加入：

需要生成新圖片時，使用已提供的 codex_image 工具。

因此，日常使用可以直接說：

幫我生成首頁插畫，主題是智慧農業，風格簡潔、綠色系，左側留白放標題。

使用者不必記住工具名稱。Qwen 應從需求判斷需要生成圖片，整理參數並呼叫工具。需要較複雜的構圖或視覺規劃時，也可以交給 Sol；涉及整套視覺方向與困難設計時，再由 Astra 協助。

Sol、Astra 的工作指示也允許在受委派的範圍內使用圖片工具。codex_image 有自己的工具權限，與啟動子代理的 subagent 權限分開，所以禁止它們再派工，不等於禁止使用圖片功能。

這次完整流程測試有明確指定圖片工具；自然語句能否穩定觸發正確工具選擇，仍有賴後續使用驗證。現有指示已經設定好，但不能把一次明確指令的成功，當成各種說法都會正確執行的保證。

目前工具只開放從文字生成新圖片，參考圖與既有圖片編輯尚未接入。Codex 生成階段的等待上限設為 8 分鐘，另有登入檢查、停止程序與檔案驗證時間。失敗、取消或逾時後不自動重試，先檢查結果與錯誤；停止本機程序也無法保證雲端已開始的生成同步取消。

下一步量測真實開發任務

這次先建立了一條可以驗證的工作流程：新對話由本機 Qwen 接手，Sol 與 Astra 能收到任務並交回結果，圖片需求也能經由本機 Codex 產生檔案，再回到 OpenCode 開啟。

接下來值得記錄的是實際開發任務：Qwen 自行完成的比例、外援介入原因、交接是否足夠、測試通過所需時間，以及訂閱額度的使用情況。用這些資料，才能判斷目前的分工是否合適，或哪些任務應該更早交給外援。

在這些量測累積之前，我會維持目前的單層派工。讓 Qwen 持續掌握需求與交付責任，讓 Sol、Astra 處理有明確理由的外援任務，圖片則透過已驗證的工具流程交付。