Model-Harness-Fit
Model-Harness-Fit 指「某個模型」與「某套 agent harness」之間的貼合程度：工具格式、回饋節奏、context 策略、驗收方式是否符合該模型在 post-training 中學到的分布。AIHAO 的駕馭工程第 8 篇主張，模型不是只針對 API 訓練，而是針對 harness 的 byte-level 慣例與 tool loop 訓練，因此單看模型名稱或 benchmark 分數會漏掉關鍵變因。
核心判斷
同一個模型換 harness，表現可能差過一個模型世代；同一套 harness 換模型，也可能讓工具格式、citation 標籤、skill 契約與 prompt cache 全部失配。文章用 Terminal-Bench 2.0、Codex / Claude 不同檔案編輯格式，以及 Cursor 對「中途切換模型」的警告說明：評估 agent 時應比較「模型 + harness」配對，而不是把模型能力當成獨立常數。
四層拆解
文章把容易混在一起的 harness 拆成四層：
- 任務分布：真正要解的任務集合。
- workflow 層：任務拆解、subagent、routing、skills、專用工具；自建 harness 通常贏在這層。
- 內層 tool loop：tool 描述、tool call 解析、結果回填、context 管理；原廠 harness 因為和模型一起訓練，通常更佔優勢。
- 模型層：權重與 post-training 內化的工具慣例。
這個拆解能化解「原廠 harness 最貼模型」與「第三方 harness 有時更強」的矛盾：原廠常贏在內層 tool loop，自建或開放 harness 則可能因為 workflow 更貼任務分布而勝出。
對 AI Ark 的用法
對 harness-engineering-for-ai-coding 來說，這補上一條時間軸：harness 會過期。memory、todo、grader、特殊 edit tool 可能原本是補某代模型短處；模型升級後，這些 scaffolding 可能變成阻力，應用 test-time-compute-evaluation 和任務級 eval 定期確認是否仍有效。
對 loop-engineering 來說，這也限制了過度抽象：不要急著打造跨所有模型的一套通用 agent framework。先固定任務分布與主模型，量測 model-harness pair；只有當多模型、多任務的失配真的反覆出現，才把 adapter、routing 或子代理模型切換變成正式設計。
中階 agentic 模型的選型訊號
BusinessNext 對 Claude Sonnet 5 的整理補上一個實務訊號：agentic 能力開始從旗艦模型下放到較便宜的中階模型，選型時不能只問「哪個模型最強」，而要比較同一個 harness-engineering-for-ai-coding 在不同模型、價格、tokenizer 與 release tier 下的任務完成率。Sonnet 5 的案例把 SWE-bench Pro、terminal-bench、Claude Code / Claude Platform 上線層級與 token 單價放在同一張表裡看，適合用來補強 agentic-ai-cost-management 的 task-level 成本視角。
這也提醒 loop-engineering：若新中階模型已能穩定完成原本要旗艦模型處理的 agentic 任務，最佳做法通常不是先加 routing framework，而是先用既有 eval 固定任務分布，量測「模型 + harness + 成本」配對是否真的改善。
Fable 5 的操作旋鈕與驗證迴圈
BusinessNext 對 Anthropic Fable 5 官方指南的整理，把 model-harness-fit 落到更具體的使用規則：effort 不是硬性 token 預算，而是模型行為旋鈕；真正的上限仍由 max_tokens 控制，prompt caching 與新版 tokenizer 也會改變成本估算。因此升級模型時，不應沿用舊模型的 token、速度或驗證假設，而要重新量測任務級成本與完成率。
這篇也補強長時序 agent 的驗證方式：Fable 5 適合處理數小時到數天的端到端任務，但可靠度來自外圍流程，而不是單次 API 請求。官方建議在建構過程中定期停下來對照 specification，並用 fresh-context verifier subagents 驗證主 agent 的成果；這和 harness-engineering-for-ai-coding 的「先 generate，再 verify」一致，也限制了 agent-framework-selection：先把驗證節奏與停止條件做小，不要一開始就堆通用 multi-agent 框架。
Fable 5 prompting 遷移：先刪過時 scaffold
AIHAO 對 Claude Fable 5 prompting guide 的整理，把 model-harness-fit 的升級動作講得更清楚：新模型不是靠更多規則發揮，而是要刪掉為舊模型補洞的過度步驟、CRITICAL / ALWAYS 式過度觸發語氣，以及 think step by step / show-your-thinking 類指令。Fable 5 的 thinking 已由 effort 控制，要求揭露內部推理反而可能觸發 reasoning extraction refusal 或 fallback，讓品質看起來「突然變差」。
這讓 model-specific-system-prompts 更具體：system prompt 應和模型的 post-training 行為、API 參數與安全分類器一起測。Fable 5 的長時程 agent 指令重點是證據式進度回報、不可逆動作才停下來問、最終摘要寫給沒看過過程的人、不要讓 context 倒數誤導模型、以及用乾淨 context subagent 驗證成果；這些都應由任務級 eval 驗證，而不是假設舊 prompt 可直接搬移。
Claude Code 團隊的刪減訊號
BusinessNext 對 Anthropic 工程師 Thariq Shihipar 的整理，補上一個更直接的實務例子：Claude Code 團隊把 system prompt 砍掉約八成，重點從「寫更多限制」改成「給足背景與工具」，讓模型自己把能力拉出來。這和 model-specific-system-prompts 的刪減型遷移一致，也提醒 harness-engineering-for-ai-coding：有時候最有效的 harness 改動不是新增 scaffold，而是移除綁住模型的舊 scaffold。
Effort 不是模型智力
BusinessNext 這篇把 Claude Code 的 model 與 effort 拆成兩個不同開關：模型決定知識與能力上限，effort 決定推理深度與 token 消耗。盲目拉滿 effort 通常只會讓成本變高，真正的修正順序是先補 context，再判斷問題是「不知道」還是「不夠認真」，最後才考慮換更大的模型。這也直接接上 build-for-next-model 與 agentic-ai-cost-management。
Fable 5 的提示詞、證據與成本閘門
BusinessNext 對 Fable 5 的整理補上一個可操作的 harness gate：完整描述最終目標，要求只回報有證據的結果，先分清是「給建議」還是「直接執行」，資訊足夠就行動而不要過度分析。模型選擇以連續多步自主執行、失敗重來成本、以及是否接受更高用量三題判斷，至少兩題為是才升級到昂貴模型；其餘工作留給較便宜模型。這把 model-harness-fit 落到「提示詞契約 + context 範圍 + task-level 成本」的組合評估。
Model platform as harness
BusinessNext 對 AWS Summit Taipei 的報導補上一個企業級案例：當 OpenAI 與 Anthropic 的模型能力逐漸趨同，企業真正難以替換的可能不是 model，而是雲端平台上的 harness 與控制層。AWS 以「model 是大腦、harness 是身體」描述這個差異；企業長期累積的記憶、身分與權限、工具閘道及可觀測性，會讓模型可以抽換，但 agent 的操作身體越用越貼合平台。
這把 model-harness-fit 的評估單位從「模型 + coding harness」延伸成「模型 + workflow + enterprise control plane」。選型時除了任務完成率與 token 成本，還要量測模型替換對記憶、權限、工具介面、audit trail 與 trace 的遷移成本；若只比較 API 價格，會低估雲端平台黏著與 vendor／values selection 的治理代價。這也直接連到 agent-ready-data-governance、ai-native-enterprise-governance 與 agent-framework-selection。
Kimi K3：開放權重與任務級貼合
BusinessNext 2026-07-17 對 Kimi K3 的整理提供一個模型選型反例：報導中的綜合 Intelligence Index 為 57 分、整體排名第四，但在前端程式碼、BrowseComp、AutomationBench-AA 與 AA-Briefcase 等特定任務又出現第一或接近頂級模型的結果。BrowseComp 還分成 30 萬 token 後壓縮 context 的 91.2 分與完整 context 的 90.4 分，表示評測結果同時受任務分布、context policy、harness 與推論成本影響，不能把單一總榜當成模型能力常數。
若 Kimi K3 後續依報導釋出完整權重，開放權重會增加部署可攜性，但不會自動消除 harness fit：仍要重測視覺輸入、百萬 token context、thinking mode、工具介面、任務完成率與每任務成本。這個案例把 test-time-compute-evaluation、agentic-ai-cost-management 與 model-harness-fit 接在一起：比較單位應是「模型 + context 策略 + harness + 任務級 budget」，而不是參數量或排行榜名次。
訂閱層級也是 model-harness-fit 的變數
BusinessNext 2026-07-20 的 Claude 方案整理補上一個產品層的選型變數：Free、Pro、Max、Team 與 Enterprise 不只差在月費，也差在可用模型、Claude Code／Cowork／Microsoft 365 的入口、使用額度，以及 SSO、SCIM、稽核日誌、資料保留與 HIPAA-ready 等治理控制。換句話說，真正的配對單位是「任務分布 + 模型 + harness + 方案權限／配額」，不能只拿 API 單價或模型名稱比較。
對 AI Ark 的實作，應先以任務級 eval 驗證同一套 harness-engineering-for-ai-coding 在不同方案與額度限制下的完成率、重試與人工審查成本；產品價格、模型清單與配額會變動，正式採購前要以官方帳號與文件為準。這也把 agentic-ai-cost-management 的 task-level budget 與 agent-skills 的能力載入邊界接到同一個選型表。
金融工作流的配對單位：範本、入口與控制層
BusinessNext 2026-07-24 對 Anthropic 金融服務範本的整理提供一個 enterprise harness 例子：同一組金融 Agent 可透過 Claude Cowork、Claude Code 或 Managed Agents 部署，差異不只在 UI，而在使用者背景、工具呼叫、後台自動化與權限／資料庫整合。Agent、Skill、Connector、Command 與 managed-agent wrapper 共同構成工作流的控制層；financial-analysis 核心模組則是多個垂直 Agent 共用的底座。這表示評估單位應是「任務分布 + 模型 + 入口／harness + 連接器與治理」，不能只比較模型名稱或 API 單價。
同一篇報導也給出遷移與驗證順序：先確認核心技能和資料管道能用，再按團隊背景選擇 Cowork、Code 或 Managed Agents，最後才客製 Skill、品牌範本、權限與新工作流。產出仍是專業人員要審核的初稿，金融資料連接器需要外部訂閱與金鑰；因此這是產品報導中的架構案例，不是獨立的成功率 benchmark。評估時可用 agent-skills 管理能力契約，用 agent-ready-data-governance 檢查資料與權限，再用 agentic-ai-cost-management 計算每項任務的完整成本。
Gemini Flash 家族：模型選型要綁任務與成本
BusinessNext 2026-07-22 整理 Google 發表的 Gemini 3.6 Flash、3.5 Flash-Lite 與 3.5 Flash Cyber：前者以較少 output token 處理 coding、知識工作與多模態任務；Lite 以吞吐與低成本服務大量搜尋／文件工作；Cyber 則聚焦漏洞偵測、驗證與修補。報導引用 Google 與 Artificial Analysis 的 token、價格、速度與 benchmark 數字，這些是來源方或第三方的 attributed claims，正式選型仍需用官方規格與固定任務集重測。
可重用的判準不是「Flash 比較便宜」，而是把 任務分布 + 模型專長 + harness + 每任務成本 綁在一起：coding／多模態、批量文件處理與資安修補應分別建立 eval；固定品質門檻後，再比較 output tokens、latency、retry 與人工審查成本。這延伸 agentic-ai-cost-management 的 task-level budget，也提醒 test-time-compute-evaluation 不要把單一 benchmark 或產品價格當成能力常數。
Claude Opus 5：把提示詞改成模型遷移的驗證工作
BusinessNext 2026-07-29 整理 Anthropic《Prompting Claude Opus 5》時，補上一個模型升級後的最小遷移順序：先重測 low／medium／high effort 在自身任務的品質、成本與延遲，再調整回覆與文件篇幅、進度回報和任務範圍；不要把前一代的高 effort、重複驗證或小任務子代理規則原封不動搬過來。這不是「新模型永遠不需要驗證」，而是把驗證從無條件 prompt ritual 改成由任務風險與 eval 決定的 harness 行為。
對 harness-engineering-for-ai-coding 而言，模型若已能自行檢查，重複要求「再確認一次」可能只增加 tool call 與 token；但 deterministic tests、權限 gate、不可逆動作的人工核准與高風險任務的獨立 verifier 仍不可刪。可重用的選型單位因此是 model + prompt contract + sensors + task-level eval，而不是單一模型名稱或一條固定 system prompt。這也連到 agentic-ai-cost-management：降低 effort 或刪除 no-op verifier 只有在完成率沒有下滑時才算節省。
Ethan Mollick：模型選擇要放回任務與組織脈絡
BusinessNext 整理 Ethan Mollick 對「共智」轉向「代理時代」的觀察：企業不能只看通用模型排行榜，而要由真正執行工作的內部專家建立 benchmark，測量模型在自家任務上的可靠性、速度與可接受取捨。這把 model-harness-fit 的評估單位從 model + prompt 推進到 model + harness + task distribution + domain evaluator；同一模型在寫程式、行銷、郵件或法律任務上的價值不能由總榜直接推導。
這個判準也連到 ai-native-enterprise-governance：企業需要由 leadership 定方向、由 lab 持續實驗、由 crowd 把工具帶入真實工作，再以 test-time-compute-evaluation 與 agentic-ai-cost-management 比較品質、延遲、重試與完整任務成本。來源中的演講與 StrongDM Software Factory 案例是人物／媒體整理，不是獨立 benchmark；可重用的是「內部專家評估 + 組織實驗室 + 明確人類角色」的選型順序。
Models、Apps、Harnesses：三層選型
BusinessNext 整理 Ethan Mollick 的《A Guide to Which AI to Use in the Agentic Era》，把 AI 產品拆成三層：model 是推理與知識上限，app 是使用者接觸模型的介面與產品入口，harness 則負責工具、規劃、長時間自主執行與實際任務串接。這個拆解把「哪個聊天視窗比較聰明」改成「哪個 model + app + harness 適合目前任務」，也讓 Claude Code、Claude Cowork 這類專用入口不再被當成單純模型版本。
可重用的選型順序是先固定任務分布與可接受取捨，再用內部使用者觀察可靠性、執行力、工具調用與完整任務成本；通用排行榜只能做初篩。文章中的訂閱價格、模型名稱與三家產品優勢是當期媒體整理，需以官方規格和 test-time-compute-evaluation 重測；若比較的是 agent workflow，還要把 agent-framework-selection、agentic-ai-cost-management 與 ai-native-enterprise-governance 的框架、成本與責任邊界一起納入。
Boris Cherny：刪除 scaffold，將資產放在驗證
BusinessNext 2026-07-30 整理 Boris Cherny 對 Claude Code 的一個更激進訊號：先用 ablation／simple mode 刪掉 system prompt 與工具框架，再逐項加回，只有在模型重複踩同一個坑時才保留那條指令。這不是「提示詞越短越好」的普遍定律，而是要求把 prompt、skill 與 hooks 視為會隨模型能力折舊的 model-harness-fit 變數；安全、權限、靜態分析、測試與介面等模型看不到的控制面仍不能用刪除取代。
這個方法把選型順序改成 刪除 → 正常使用 → 觀察重複失敗 → 最小回填 → 驗證。長時間 agent 的價值也不在「讓它一直跑」，而在能否提供可觀察的中間成果、自我檢查工具與明確停止條件；評估時應把 eval-is-spec 的任務分布、agentic-ai-cost-management 的完整任務成本與 loop-engineering 的恢復／人工接管一起量測。來源是媒體對公開對談的整理，長時程 agent 數量、效能與 eval 壽命不能視為獨立 benchmark。
Open-weight 不等於 harness portability
BusinessNext 2026-07-31 對吳恩達談 open-weight 的整理補上一個部署層判準：權重可下載與本地執行，增加了模型在 provider 受限時的可攜性，但不會自動帶走原本的 context policy、tool loop、量化限制、硬體依賴或安全更新。換句話說，評估單位仍是 model + runtime + harness + task distribution，而不是「可下載」本身；這是媒體整理的策略脈絡，不是獨立模型 benchmark。
需要本地部署時，先用固定任務集重測工具呼叫、長 context、延遲、重試、人工審查與每任務成本，再決定是否值得承擔自管 runtime 和 patch 的負擔。這與 open-weight-model-strategy、test-time-compute-evaluation 及 agentic-ai-cost-management 相連。
Brian Behlendorf 的另一個角度是：即使底層 foundation model 不開放，團隊仍能在模型上建立可替換的 harness、工具外殼與企業控制層。這表示 model-harness-fit 不只衡量「模型是否能用工具」，也要衡量控制層能否跨模型遷移、保留權限與 observability，並在 provider 受限時維持工作流；這個架構觀點仍需用固定任務集驗證，不能把 open-source label 當成 portability 保證。
Local agent 的 model + runtime + hardware fit
BusinessNext 2026-08-11 對 Meta Muse Glimmer 的整理提供一個 local-agent 例子：30B open-weight 模型不只要看參數量，還要看量化後能否塞進 24–32GB 記憶體、工具呼叫與圖表／截圖輸入是否可用，以及 runtime 是否能在本機完成錯誤診斷與重試。DFlash 草稿模型把生成速度也變成 harness 變數：主模型與 draft model 的平行驗證可能改變 latency，但不能把官方在 RTX 5090 或 MacBook 上的速度宣稱外推成所有硬體的結果。
因此，open-weight local agent 的評估單位應寫成 model + quantization + runtime + tool loop + hardware memory + task distribution。先確認 license、權重格式、實際推論後端與工具支援，再用固定任務集測量本地資料隔離、視覺輸入、程式修復、失敗重試、延遲、更新成本與人工接管；「能下載」只解決存取選項，不等於能直接取代既有 harness。這補強 open-weight-model-strategy、ai-memory-hierarchy 與 test-time-compute-evaluation。
Model + runtime + hardware fit
BusinessNext 對 AMD 收購 Taalas 的整理，把 model-harness-fit 從軟體 harness 延伸到推論硬體：Taalas 的路線是把特定模型與權重固定在晶片內，讓推論少搬運外部 HBM；可寫入的 SRAM 仍承接 KV cache 與 LoRA 等可變部分。這不是單純增加一層記憶體，而是把「模型資料放哪裡」變成硬體與 runtime 的共同選型，且報導中的吞吐量、製程與產品整合仍是廠商／媒體歸屬，不是本 wiki 的獨立 benchmark。
這種配對適合模型版本相對穩定、延遲或 token throughput 價值很高的工作負載；代價是模型更新要改光罩或重新 tape-out，大模型也可能需要多顆客製晶片。實務評估單位因此應是 model + memory placement + runtime + hardware + update cadence + task distribution，而不是只比較 GPU 型號或單一 token 數字。這補強 ai-memory-hierarchy 的物理層判斷，也連到 test-time-compute-evaluation 與 agentic-ai-cost-management：硬體專用化只有在固定任務集、更新週期與完整成本下仍勝出，才值得採用。
AMD 同時把一般 GPU、專用推論晶片與 prefill／decode 分工放進同一個系統級方案，說明異質硬體 orchestration 也屬 harness 的一部分。對 AI Ark 而言，這是「為下一個模型而寫」的硬體版本：不要把短期模型效率主張直接當成長期通用能力，先用可重跑的 workload eval 驗證效能、彈性、部署與模型遷移成本。
垂直整合：model + runtime + hardware + fab fit
BusinessNext 2026-08-07 對 SpaceX／Tesla Terafab 的整理，補上 model-harness-fit 的另一個極端：不是只替模型挑晶片，而是把邊緣推論晶片、高功率運算、製造、封裝、測試與部署需求放進同一個垂直整合決策。報導把 Optimus／Cybercab 的低延遲邊緣晶片，與太空資料中心的高功率晶片分成兩條工作負載，顯示「硬體適配」也包含場域、功耗、供應可靠度與製造控制；Terafab 的投資、需求量與時程仍是 SpaceX、Tesla 及媒體歸屬，不是獨立產能或效能 benchmark。
可重用的判準是把 model + runtime + hardware + fab + deployment environment 綁在一起評估：邊緣工作負載看延遲、功耗、感測／控制閉環與更新彈性；資料中心工作負載看吞吐、電力、封裝、供應鏈與總擁有成本。這把 edge-ai-harness 與 physical-ai-commercialization 接到本頁的模型選型，並提醒 ai-memory-hierarchy：AI 基礎設施的瓶頸可能從權重搬移、記憶體與推論 runtime，一路外溢到晶圓、封裝、能源與現場部署。
上下文工程與 1% 法則
BusinessNext 2026-08-07 對 Jeff Dean 訪談的整理，將 model-harness-fit 從模型／工具格式再擴成模型周邊系統：資料檢索、歷史紀錄、工具、記憶、權限、技能與評估流程共同決定長時程 agent 能否穩定工作。報導提到代理約使用工具十次後可能失準，因此應以技能說明、多路徑候選、外部評估與持續測試把回饋提早放入 loop，而不是把模型獨自跑到最後才驗收。這些是訪談與媒體整理的來源歸屬，不是獨立 benchmark。
同一篇報導的「1% 法則」則是產品選型的另一個 harness gate：通用模型成功率約 20% 的問題可能很快被模型供應商吸收；更有防禦力的窗口，是通用模型近乎失敗，但團隊有專有資料、領域工具或可重複 eval 能把結果推高。這與 code-abundance-product-taste、coding-agent-as-optimizer 共同提醒：要評估的是 model + context + tools + memory + eval + task distribution，不是模型名稱或一次性的成功率敘述。
Grok 4.6：長時程 agent 的模型—harness 配對
BusinessNext 2026-08-13 對 Grok 4.6 的整理把 model-harness-fit 推進到長時程 agent 評測：來源轉述 Artificial Analysis 的 GDPval-AA v2、Terminal-Bench、τ³-Banking 與 AA-Briefcase 結果，並指出 Grok 4.6 的定位不是單題推理分數，而是能否在較長任務軌跡中持續操作、自我測試與驗證。這些分數、53 輪對 103 輪的回合數與每題成本都是來源方／第三方 attributed claims，不能直接外推成所有任務的模型優勢。
可重用的選型單位因此應寫成 model + harness + task distribution + inference budget：固定工具、context policy、驗證節點與任務集後，再比較完成率、恢復能力、回合數、延遲、token／美元成本與人工接管。若模型的長時程表現靠更長的 tool loop 或更多自我驗證取得，test-time-compute-evaluation 與 agentic-ai-cost-management 就必須和 model-harness-fit 一起量測；不能只用 61 分的總榜或標準 token 價格做決策。
Gemini 3.7 Flash：中階模型的品質—速度—成本 Pareto
BusinessNext 2026-08-14 對 Gemini 3.7 Flash 的整理，把編碼、agentic work、速度與價格放進同一個模型選型案例：官方測試中它在 FrontierCode 1.1 Main、Code Arena 領先 GPT-5.6 Terra，但在 DeepSWE v1.1 與 Terminal-Bench 2.1 落後；Artificial Analysis 則轉述其綜合智慧指數只差一分、每秒輸出約 340 token、單一任務平均 1.7 分鐘。這些分數、速度與費率是 Google／第三方／媒體 attributed claims，不能直接外推成所有 harness-engineering-for-ai-coding 任務的優勢。
可重用的判準不是「Flash 便宜」，而是固定任務分布、工具迴圈、context policy 與品質門檻後，比較 model + harness + task outcome 的 latency、retry、人工審查、cached input 與完整任務成本。對 coding 與 agent 工作，Gemini 3.7 Flash 這類中階模型若已達到可接受品質，應先用 test-time-compute-evaluation 畫出 quality／latency／cost Pareto，再決定是否需要旗艦模型或額外 orchestration；促銷價格與模型版本則必須以官方規格和當期帳號重測。
Gemini 3.7 Flash：模型、訂閱層級與任務 fit
BusinessNext 2026-08-17 的同 article ID 修訂版，將 Gemini 3.7 Flash 的 coding／agent 宣稱放回 Google AI Plus、Pro、Ultra 5x 與 Ultra 20x 的訂閱層級。文中列出 FrontierCode、DeepSWE、WebDev Arena、GDP.pdf 與 AutomationBench 等結果，也描述 Flash 在多步驟工具呼叫遇到障礙時的澄清行為；這些效能、價格、額度、模型清單與地區開放狀態都是 Google／BusinessNext／第三方來源 attribution，不是 AI Ark 的獨立 benchmark。
可重用的選型單位因此不只是 model + harness，還包括 app／runtime + subscription capacity + task distribution：同一個 Flash 模型在 API、一般聊天、Spark agent 或 Workspace 入口，可能受不同模型版本、算力額度、context window、工具權限與背景執行限制影響。正式比較時，應固定帳號地區、模型版本、任務集、工具 loop 與品質門檻，再記錄完成率、澄清／人工接手、延遲、retry 與完整任務成本；不能用月費或產品頁上的模型名稱直接推導能力。
文章對 Flash-Lite、Flash、Pro 的任務分工也補上升級順序：日常摘要與高吞吐工作先用低算力模型，策略分析與多步驟推論再用 Flash，需要深度程式、數學或跨檔案分析才升級 Pro。這與 test-time-compute-evaluation 的 budget-aware 曲線及 agentic-ai-cost-management 的 task-level budget 相連；先量測既有 harness 是否達到品質門檻，再決定增加模型、算力或訂閱層級，而不是把最高方案當成預設答案。
開放模型的生態訊號與 fit 邊界
BusinessNext 2026-08-17 整理 Hugging Face 報告，指出 Qwen 的平台下載、衍生模型與 GGUF 活動都領先其他模型家族；但下載量是檔案請求活動，不是去重使用者、品質或商業採用的直接證據。這些訊號適合用來觀察模型是否形成可被微調、量化與部署的生態，不能取代固定任務集上的完成率與錯誤分析。
因此，本地模型的評估單位仍是 model + license + quantization + runtime + hardware memory + tool loop + task distribution。Qwen 的 GGUF 流量與小模型下載占比可提示哪些尺寸較容易落地，但正式選型仍要用 test-time-compute-evaluation 驗證延遲、重試、人工審查與每任務成本，並以 open-weight-model-strategy 檢查權重可攜性與維護責任。
Portable Computer：本地 model + runtime + hardware fit
BusinessNext 2026-08-26 對 Portable Computer 的整理，提供一個把 model-harness-fit 落到產品部署的案例：它不是只下載一個模型，而是把 orchestrator LLM、subagent LLM、agent harness、工具與 sandbox 一起放到本地硬體。第一波支援 DGX Spark（GB10、128GB unified memory），後續才規劃至少 24GB VRAM 的 RTX PC；本機模型包含 Qwen 3.8 27B、Perplexity 後訓練的 PPLX 27B，Nemotron 3.5 Lightning 30B 仍是後續支援。
Perplexity 宣稱 on-device 27B harness 為 82.6%、PPLX 27B 為 85.4%，但文章未提供完整任務集、評測協定與獨立重現，因此只能當作產品方訊號。可重用的評估單位應寫成 model + post-training + runtime + hardware memory + tool loop + egress policy + task distribution，再用 test-time-compute-evaluation 比較完成率、延遲、重試、資料外送與維運成本；這也連到 edge-ai-harness、agent-sandbox-architecture 與 cloud-agent-vs-localhost-agent。
Provider continuity is part of fit
BusinessNext 2026-08-31 對 OpenAI／Cursor 供應爭議的整理，補上一個常被模型 benchmark 遮住的 harness 變數：第三方 coding tool 的可用模型集合會受到 provider contract、控制權變更、服務條款與未來模型供應影響。OpenAI 官方公告稱，在 SpaceX 收購 Cursor 後，既有 OpenAI 模型暫維持到 2026-11-12，但不再提供新模型；Cursor 則表示 OpenAI 約占其用戶流量 5%。前者是供應商公告，後者是 Cursor 自報數字，兩者都不構成品質、流量或可靠性 benchmark。
因此，模型 + harness 的選型除了工具格式、context、task distribution 與成本，也要測 provider continuity：控制權變更觸發條款、既有／新模型的存取差異、通知期、fallback provider、模型介面 adapter、遷移測試與使用者對模型差異的敏感任務。這是由事件整理出的治理觀察，不表示某一家 provider 必然會斷供；正式判斷仍需查看合約並用固定任務集重跑品質、延遲、重試與人工審查成本。
Fable 5.1：模型升級同時是 harness migration
BusinessNext 2026-09-02 對 Claude Fable 5.1／Mythos 5.1 的整理，補上一個模型遷移的具體案例：兩者共用底層模型，但 safeguards、存取資格與產品入口不同；同時 Fable 5.1 的 1M context、128K max output、always-on adaptive thinking，以及 forced tool use 不支援等 API 契約，都可能改變既有 agent harness 的行為。這表示「同一模型」不等於「同一執行環境」，model-harness-fit 還要把 release tier、fallback、tool contract 與安全政策一起固定。
Artificial Analysis 在其 Intelligence Index 設定下測得 Fable 5.1 max effort 為 66 分，但單任務成本為 3.76 美元，高於 Fable 5 的 3.14 美元，並歸因於約 1.7 倍的 output tokens；這與 Anthropic 對典型／高度 agentic workload 的成本估計不是同一分母。可重用的選型單位因此應寫成 model + safeguard／fallback + effort + tool loop + task distribution + full task cost，再用既有 eval 重測完成率、硬答／幻覺、輸出 token、cache hit、retry 與人工審查，而不是只看總榜或 cache 單價。
最小遷移順序是：先 replay 舊任務與工具契約，再檢查 thinking block、forced tool、structured output、fallback 與 cache 行為，最後才調整 effort、max_tokens 與 verifier。這是由官方 API 變更與第三方成本／評測報告整理出的工程判準，不是 Fable 5.1 在 AI Ark 任務上的獨立 benchmark。
Gemini 3.8 Flash／Cyber：reasoning 回合與 trusted access 都是 fit 變數
Google 官方對 Gemini 3.8 Flash 的發布說明指出，複雜任務會執行更多 reasoning steps、反覆呼叫工具，可能以較多 token 換取品質；3.7 Flash 則保留給 efficiency-first workload。3.8 Flash Cyber 另透過 Fairwind 只提供給受信任防禦者。這些是供應商的模型行為、價格與存取敘述，不是 AI Ark 的獨立能力或安全 benchmark。
因此，Gemini 3.8 的 fit 評估單位應寫成 model + effort／推論回合 + tool loop + task distribution + release tier + full task cost：先固定任務、品質門檻與工具契約，再比較 3.7／3.8 的完成率、輸出 token、回合數、retry、延遲、人工審查與 access／safeguard 差異；不能因 token 單價相同或官方 benchmark 較高，就假設既有 harness 已完成遷移。
Muse Spark 1.3：agentic 評測的 effort／harness trade-off
BusinessNext 2026-09-03 的 Muse Spark 1.3 案例把模型升級的兩個面放在一起：Meta 官方稱 1.3 在長時程 agentic work 中改善澄清、不可逆動作確認與多工作流，並相較 1.2 約少 20% tool calls、25% tokens；這些仍是 provider 自述，沒有 AI Ark 的獨立重測。
Artificial Analysis 在自己的 Intelligence Index 方法下報告 xhigh 為 61 分、limited-preview max 為 62 分；Tau3-Bench Banking、Terminal-Bench 2.1 與 GDPval-AA v2 的 agentic 指標較 1.2 上升，但 max 版本以更多 turns 與 reasoning tokens 換取部分提升，且 AA-LCR／AA-Omniscience 有小幅退步。這是第三方特定設定的觀察，不是跨 harness 的通用排名。
可重用的評估單位因此應固定 model variant + inference effort + tool loop + harness + task distribution + full task cost：先 replay 同一組任務，再比較完成率、澄清／人工接手、工具回合、輸入／輸出 token、延遲、retry、artifact correctness 與人工審查。模型升級後，少掉的 tool calls 不必然代表所有 workload 都更便宜；要把產品端 coding comparison 與第三方 Intelligence Index 分開記錄，避免混用分母。
GPT-6 Astra：同一模型的 harness 與 monitorability 邊界
BusinessNext 2026-09-04 對 GPT-6 Astra 的整理顯示，模型評測不能脫離 harness：文章區分保留隱性推理狀態的 Provider Adapter 與 Standard harness，且 OpenAI 官方也提醒研究／API 評測的 system prompt、工具與 production ChatGPT 可能不同。因此 ARC-AGI-3 或其他 benchmark 的高分只能在明確記錄 model、effort、工具、harness、分母與執行環境後解讀。
Astra 也把 fit 評估推進到安全控制面：模型可用的工具、網路出口、sandbox、完整 trajectory／CoT monitoring、misalignment stop 與 Trusted Access 資格，都是執行環境的一部分。若 model + harness 在 cyber 任務上更強，不能只追求較高完成率，還要固定 permitted task、拒答邊界、monitor false positive、人工接管與撤回條件；monitorability 下降時，單一 CoT 監控尤其不能被當成完整安全證據。
最小遷移順序是：先 replay 同一組任務與工具契約，再比較 Provider Adapter／Standard harness 的完成率、回合、token、延遲、失敗與安全事件，最後才調整 effort、verifier 或 rollout tier。OpenAI 的 benchmark 與 safety 結果是供應商測試訊號，不是 AI Ark 既有任務的品質、成本或安全結論。