架構、角色與上下文紀律：如何減少 token 使用並獲得更可靠的結果

在過去幾個月，有一個重點變得非常明顯：許多前端（以及其他領域）的團隊正在親身體驗——「更強大的模型」無法拯救脆弱的架構。即使你擁有頂級的 LLM，但如果把它放入混亂的工作流程中——上下文不受控制地增長、角色混淆、不斷合併以及測試管理不善——你只會浪費 token、時間和品質。

反之，更有趣的是：一個設計良好的 harness，即使使用較便宜的模型，也能產生驚人的結果，尤其當它們被賦予明確的角色時。

Harness：到底是什麼（以及為什麼比模型更重要）

所謂「harness」，並不是指更長的提示詞或額外的規則。它是一整套：

  • 角色協調（誰規劃、誰執行、誰驗證）；
  • 上下文結構（每個代理能看到什麼，以及更新的頻率）；
  • 整合工作流程（分支、合併、衝突處理）；
  • 測試循環（快速且自動化的回饋、變更的閘道控制）；
  • 防偏移策略（限制代理偏離目標的「遊走」行為）。

實際上，這就是「一個模型在寫程式」與一個工程化的系統在產出軟體之間的差異。

單一代理的問題：偏移與上下文飽和

當單一代理需要負責大型專案時，往往會因以下具體原因失敗：

  • 它必須同時記住整體願景與局部細節。
  • 即使擁有巨大的上下文視窗，「帶著所有內容前進」的認知成本仍會不斷增加。
  • 隨著時間推移，代理可能會：
    • 失去整體畫面，優化錯誤的方向；
    • 停留在過高的層級，產生薄弱的實作；
    • 引入不一致、回歸與難以追蹤的錯誤。

這正是「偏移」的根源：它不只是模型的限制，更是流程的限制。

樹狀群體：分離上下文與責任

有效的多代理方法採用一個簡單的比喻：樹與葉。

  • 頂層有一個規劃者（planner）：維持整體視野、拆解步驟、定義驗收標準。
  • 底層則是工作者（worker）：接收小型任務並加以實作。

改變一切的關鍵規則是嚴格分工：

  • 規劃者不實作 → 不會被低層細節填滿，保持設計清晰；
  • 工作者不規劃 → 不會迷失在架構中，專注於定義明確的任務。

這種分工大幅減少單一代理「走完整棵樹」並帶著所有祖先、決策與限制前進的需求。

模型經濟學：規劃者用貴的，工作者用便宜的

這個架構最實務的結果之一，就是你可以：

  • 使用前沿模型（較貴）來規劃；
  • 使用一個或多個較便宜的模型來執行。

對習慣「只買最好的模型來擴展」的人來說，結果是反直覺的：總成本可能大幅下降，且品質不減，因為執行階段才是最消耗 token 的部分。

在不同組合的比較中，「前沿模型作為規劃者 + 經濟型模型作為工作者」的配置，能以低一個數量級的 token 成本，達到與「全程使用前沿模型」的相同功能結果。

營運品質：更少衝突、更少程式碼、更多控制

成熟的 harness 並非只看最終分數，而是任何工程師都認可的營運指標：

1) 合併衝突是混亂的徵兆

如果你的群體產生大量衝突，這不是「Git 的問題」，而是代理工作重疊過多、邊界不清的訊號。

更好的 harness 傾向於：

  • 減少在共同檔案/區域的競爭；
  • 強制整合順序；
  • 提早發現不相容性。

2) 程式碼行數 ≠ 進度

另一個模式是：產出較少的程式碼可能代表流程更乾淨。

如果系統用更少的程式碼行數解決相同任務，通常表示：

  • 較少重複；
  • 較少不必要的「創意重實作」；
  • 更好的重用與對現有函式庫/原語的遵循；
  • 較少的 churn（不斷寫、改寫、重構的循環）。

這不是絕對法則——有時更多程式碼代表「更正確」——但在代理情境中，過度產出程式碼往往是警訊。

「規格就是新的提示詞」：工作單位的轉變

對團隊成員（以及產品建構者）而言，有一個非常有價值的觀念：工作單位正在改變。

  • 自動完成 → 單位：單一行。
  • 「傳統」模型 → 單位：區塊或函式。
  • 代理 → 單位：檔案/功能。
  • 群體 → 單位：規格。

在使用群體時，上游的工作變得至關重要：一份寫得好的規格是品質的乘數。它不需要無限長，但必須可驗證：

  • 明確的功能需求；
  • 限制條件（API、效能、相容性）；
  • 驗收標準（測試、邊界案例）；
  • 不模糊的「完成」定義。

對前端開發者的實務啟示（即使範例是「後端導向」）

重建資料庫看似與前端無關，但以下情境的教訓完全相同：

  • 設計系統的重構；
  • 從 Redux 遷移到 Zustand / 從 Vue 遷移到 React / 從 CSR 遷移到 SSR；
  • 重寫包含路由、驗證、快取、i18n 的應用程式；
  • 自動化 E2E 測試與 UI 回歸測試。

如果你今天正在實驗使用代理生成程式碼，優先事項不是追逐最新模型，而是建構一個能防止混亂的 harness。

一個能撐得住的 harness 具體清單

如果你想讓這個方法可重複，以下幾點是穩固的基礎：

  1. 角色分離：規劃者 ≠ 實作者 ≠ 審查者。
  2. 小型且可驗證的任務給工作者（範圍狹窄、檔案/區域明確劃分）。
  3. 測試作為閘道：沒有測試針對性失敗前通過後的合併。
  4. 分支策略：最小化在相同檔案上的並行工作。
  5. 受控的記憶：上下文只更新有用的人工製品（決策、API、合約），而非日誌與雜訊。
  6. 營運指標：衝突、churn、LOC、綠色建置時間、回歸率。

總結：把時間花在 harness 上，而不只是模型

最後的訊息簡單且非常「工程化」：流程架構勝過原始運算力。

前沿模型可能是正確的選擇——尤其是用於規劃與決策——但實驗性昂貴系統與生產性系統之間的差異，在於你的 harness 紀律：角色分離、上下文受控、有序整合，以及引導每一步的測試。

在生成程式碼的能力已成為商品的世界中，競爭優勢轉向許多人低估的事物：如何組織代理的工作，以及如何將規格轉化為可驗證的軟體，而不耗盡預算且不失去對專案的控制。

原文：https://frontendfacile.it/blog/perche-l-harness-batte-il-modello-lezioni-pratiche-dai-sistemi-multi-agente