【2026 最新】Harness-S 教學：兄弟框架怎麼救援、模型真的學會了嗎？CPU 檢查與證據判讀

你替 AI 助理換了一套工作流程，原本做錯的任務突然成功了。這表示模型變聰明，還是桌上多放了一張提示卡？Harness-S 教學要拆開這兩件事：借助外部框架做對，以及經過訓練後，回到原框架仍做得更好。

前半專為完全沒有技術背景、想讀懂 Agent 研究的人寫；後半給願意貼指令的新手。你會認識救援池、完成 CPU 資產檢查，並學會列出公平比較所需的證據。CPU 練習需要既有的 Python 3.10 以上與 Git；完整訓練則是另一段 GPU 工程。

本文依 2026 年 11 月 9 日查閱的原始論文、官方程式碼、配置與重現文件整理，固定版本 93f5d8a81ad8bfaa0c50b9f9710c49b693c7f2a0。AlphaLab 完成池檢查及 CPU 測試；外部 AppWorld 資料未備妥，因此 prepare、dry-run 未完成，未執行 GPU 訓練。

先說結論：救援成功，要再過「回原框架」這一關

Harness-S＝用兄弟框架找新路，再把學到的行為帶回原框架。把模型想成學徒，Harness 想成工作桌上的工具、筆記與操作規矩。換桌子能幫他做完一次；收回輔助桌後仍能做，才更接近我們關心的能力轉移。

• 先分開三個結果：資產檢查通過、救援任務成功、訓練後在原框架改善。每一項都需要自己的證據。
• 同一模型在原框架全敗後，才啟動兄弟框架的新嘗試；救援不是把失敗對話接著改答案。
• 公開預設使用規則路由；歷史論文成績、公開配置與本次 CPU 結果，應各自記錄。

一、Harness-S 教學：先認清五個零件

① 「學徒」Policy：決定下一步輸出什麼的模型策略。② 「原工作桌」H0：起始執行框架，包含提示、工具介面、上下文、記憶與執行規則。若這些還抽象，先看 Agent Harness 白話入門，把模型與執行層分開。

③ 「兄弟工作桌」Sibling Harness：沿用共同執行基礎，但修改部分支援方式。④ 「做事錄影」Trajectory／Rollout：模型從任務開始到結束的一次嘗試與紀錄。⑤ 「派桌員」Router：在執行前，依已有證據選框架。官方架構文件可以對照到這些零件的實作位置。

兄弟框架不等於多個不同模型。這套方法的重點，是同一個策略在不同支援條件下探索。框架的優劣也可能隨模型訓練而改變：初學時有用的提示卡，熟練後未必仍是最好的安排。

二、一個失敗任務，怎麼變成可學習的救援？

想像一個示意任務：「找出符合條件的訂單，整理後更新清單。」學徒可能找錯欄位、遺漏檢查，或太早交件。以下是機制示意，沒有預填任何實際任務的成功率。

• 第一步，先用 H0 做一組嘗試。公開配置的組大小是 8；只要其中有一次成功，保留原組。
• 第二步，八次全敗才救援。選出八個不同輔助框架，排除 H0；同一策略在每個框架各從任務初始狀態重新嘗試一次。
• 第三步，用整組救援軌跡替換全敗組。不是只挑成功答案貼回去，也不是把兩組都當成同一組訓練。
• 第四步，更新同一個模型策略。各軌跡保留產生它時的上下文；不能假裝兄弟框架的動作是在 H0 的提示下生成。
• 第五步，回到 H0 評估。再另外量事前 Rank-1 路由，才能分開模型本身改善和執行時輔助。

論文第 3.3 節描述全敗替換與群組相對獎勵。GRPO（群組相對策略最佳化，一種強化學習方法）會用同組結果的相對差異形成學習訊號。白話說，有做對也有做錯的組，才有機會看出哪些行為值得加強；救援若仍全敗，並不自動創造正向差異。

還有一筆容易漏掉的帳：被丟掉的 H0 嘗試也花了運算。一次觸發救援的任務，會先做八次 H0，再做八次新嘗試；不能只數最後留下的八條軌跡，就宣稱總成本相同。

三、先排公平比較：重抽樣、救援、Oracle 與事前路由

如果只看「兄弟框架總有人做對」，很容易高估實際可部署能力。Oracle union（事後最佳聯集）像看完所有人的答案，再挑對的那一份；Router 卻必須先選人，再等他交卷。兩者回答的問題不同。

先固定模型 checkpoint、任務集合、初始狀態、工具權限與每次執行上限，再固定嘗試數。比較兄弟框架與 H0 重抽樣時，要讓兩邊都拿到同樣次數。Oracle 可作池的覆蓋參考，但別把它放進「上線時就能達成」的欄位。路由自身的模型呼叫、驗證集執行與延遲，也另列成本。

看模型有沒有學會，則比較相同 H0 下的訓練前後策略，並加入 plain GRPO 與 H0 rescue 控制組。論文附錄 C將 H0 rescue 定義為全敗時仍在 H0 做新嘗試；它用來追問，收益是否只是多試幾次。完整總抽樣量仍受各策略觸發救援的頻率影響。

結果表請留五欄：方法、執行框架、嘗試預算、Pass@3、Avg@3。Pass@3 是每題三次內至少成功一次的題目比例；Avg@3 是每題三次成功表現的平均。不要把一個「至少一次」的數字，當成每次都能成功。本文不把 CPU 檢查換算成任何一格任務分數。

四、Harness-S 教學動手做：CPU 檢查三道門

①「拿到哪一版？」先固定程式碼與隔離環境

先在終端機執行 python3 --version，確認至少 3.10。下列安裝只準備控制指令與輕量依賴；本階段不執行 bootstrap、Docker 建置或模型下載。若目前 Python 太舊，先換到已安裝的相容版本再建立環境。

git clone https://github.com/DeepExperience/Harness-S.git
cd Harness-S
git checkout 93f5d8a81ad8bfaa0c50b9f9710c49b693c7f2a0
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -e .
harness-s check-pool

成功時，本次固定版輸出 {"harnesses": 20}。依池驗證程式，它會核對目錄記錄的公開檔案雜湊與資產。AlphaLab 在 Python 3.12.13 的隔離環境得到這個輸出；加裝測試依賴後，官方 CPU 測試為 32 passed。這驗證資產與程式契約，尚未跑一題 AppWorld。

②「任務在哪裡？」prepare 也有資料前提

prepare 雖不分配 GPU，仍會讀取每題的 specs.json。先依 AppWorld 官方指南備妥外部環境、任務資料與相應使用權，再按 官方環境變數範本填入自己的真實路徑。程式碼授權不會代替外部資料的條款。

需核對 APPWORLD_ROOT、APPWORLD_PYTHON、POLICY_MODEL、POLICY_DIST_CHECKPOINT 與 NODE_ROOT。模型欄位分別是 Hugging Face 權重與相容的轉換後 checkpoint。不要把範本的 /path/to/... 當成已存在的資料，也別用假題目冒充官方任務。

harness-s prepare   --config configs/appworld/harness_s_4b.json   --run-dir outputs/appworld-harness-s-cpu

本次把外部輸入指向明確不存在的測試路徑後，prepare 停在缺少 data/tasks/ff58e36_3/specs.json 的 FileNotFoundError。這是缺資料的診斷，不是模型能力測試。先補對資料根目錄，再換新的 run directory 重做；不要把半成品目錄當作已準備完成。

③「只是列出計畫？」保留 –dry-run 再看命令

bash scripts/train_appworld.sh   --config configs/appworld/harness_s_4b.json   --run-dir outputs/appworld-harness-s-cpu   --dry-run

這個命令會先經過 prepare，再由 官方 launcher印出 Docker 啟動命令；dry-run 分支不呼叫訓練子程序。本次因同一資料前提未滿足，在 prepare 階段停止，沒有產生成功的啟動計畫。你資料備齊後，要核對映像、GPU 清單與掛載路徑；保留 --dry-run，先別移除。

若先前 prepare 已完成，還要打開 run directory 裡的 config.json、bindings.json、source.json 與三份分割 JSONL。它們讓你追問「用哪個配方、哪組池、哪批任務」。變更配方或來源後用新目錄，避免把不同實驗的收據混在一起。

五、公開配置與論文實驗，要分開核對哪四件事？

• 選桌方式：公開 4B 配置使用 router.mode="rules"、neighbors=5，關閉 profile calibration。規則從驗證指令做 TF-IDF 文字相似度，再以附近任務的成功表現排序；論文主要方法則描述行為檔案與 LLM 投票。
• 候選池：公開預設含 H0 加 19 個兄弟。重現文件另記錄部分歷史訓練使用 H0 加九個的子集；這兩組不能只因方法同名就視為相同實驗。
• 挑 checkpoint：公開配方用 H0 驗證成功率選 checkpoint；文件指出歷史封存實驗使用不同的固定池指標。挑選規則也會影響最後拿哪個模型比較。
• 重複與硬體：論文主表平均三次獨立執行，使用八張 H800；公開啟動預設單次，且每個推論引擎預設一張 GPU。這些是配置邊界，不能從「指令可列印」推導成「原分數已確認」。

截至上述查閱日，官方驗證狀態明確寫出：重整後的 portable GPU launcher 尚未完成端到端 GPU 訓練。待驗項目包括真實任務容器、token／mask 對齊、optimizer 更新、驗證、checkpoint 重啟與最終評估。這個具體邊界，比一句「開源了」更能幫你安排下一步。

預設規則不呼叫路由 LLM，不代表整套訓練不用算力。驗證任務仍需模型執行，策略更新仍需訓練設備。把「少了路由 API 成本」和「整個專案免費跑完」分開，才不會低估資源。

六、常見問題：八個容易混在一起的判斷

1. Harness-S 是換一個更強的模型嗎？

不是這個機制的核心。同一策略先在兄弟框架產生新軌跡，再更新模型權重；框架改變與模型學習是兩段動作。

2. 電腦只有 CPU，可以先學嗎？

可以。先做 check-pool、讀配置與建立比較表；prepare 還需要外部任務規格。完整模型執行與訓練另有 GPU 環境要求。

3. 20 個 Harness 等於 20 個模型嗎？

不是。它們是共用執行基礎的框架變體，支援同一策略的方式不同。

4. 有一次 H0 成功，也會觸發兄弟救援嗎？

不會。這裡的全敗觸發條件是整組 H0 都失敗；有成功就保留原組。

5. 兄弟救援成功，就證明能力已轉移嗎？

還不足夠。要看更新後策略在原 H0 的 held-out 任務表現，並核對重抽樣與訓練控制組。

6. Oracle 聯集可以拿來當上線分數嗎？

不能直接這樣用。它事後知道哪些嘗試成功；實際路由要在答案揭曉前選框架。

7. dry-run 成功，能寫成重現論文嗎？

不能。它檢查準備與命令生成，不會產生訓練後 checkpoint、任務成績或能力轉移證據。

8. 深層工具修改比淺層提示修改更會轉移嗎？

目前這篇採用的公開證據不足以替兩者排定普遍優劣。論文討論串中作者回覆會進一步量化這個問題；把它留作分組實驗問題，別先寫成答案。

給新手的三個重點：每次成功，都問收據在哪裡

第一，先認哪一層變了：模型權重、工作桌，還是單純多試幾次。第二，同預算比較要數被丟掉的嘗試與選擇成本。第三，回 H0 驗收時鎖定任務、checkpoint 與配方。若要理解「修改框架」本身怎麼做受控比較，可接著看 Plan／Tools／Context 消融教學；若要追訓練收據，讀 Agent Lightning 的軌跡與獎勵驗收。