Claude Code 原始碼外洩，究竟 Anthropic 是如何實現 Harness，讓 coding agent 可以穩定長時間運作？

問題 1 / 5

在開發 Coding Agent 時，所謂的「Harness」包含哪些核心工程組成，其本質作用為何？

Q: 在開發 Coding Agent 時，所謂的「Harness」包含哪些核心工程組成，其本質作用為何？

Harness 是包在 AI 模型外層的一套厚重的工程包裝，它是將模型轉化為可靠產品的關鍵結構。根據內容，Harness 的核心組成包括：執行環境與工具接口： 提供模型運作的場所及與外部工具互動的管道。權限制度： 規範 Agent 的行為邊界，防止其在未經授權下做出高風險決策。記憶機制與任務編排： 管理任務狀態並規劃執行流程。驗證流程： 讓 Agent 具備自我審查與確認產出品質的能力。Harness 的本質並非單純增加功能，而是「把不穩定的模型變成可管理的系統」。模型本身存在不穩定、易失焦及在資訊不全時自作主張的問題，Harness 透過工程細節壓低錯誤率、縮小失控邊界，並確保流程可回退、可重來且可審查。這使得成熟的 AI 產品不再只是「模型加殼」，而是將模型視為其中一個元件的完整系統。

Q: 為什麼單純增加上下文長度（Context Window）不足以解決長任務處理的問題？有效的解決方案是什麼？

處理長任務的挑戰不僅在於記憶容量，更在於模型在長上下文環境下的注意力劣化。當對話過長時，模型會開始混淆先前的選擇、忘記既定限制，甚至在任務未完成時提早收尾。因此，長任務的真正解法並非盲目擴張上下文，而是「把狀態外部化」。具體的工程實踐包括：結構化文件： 利用如 feature list、progress log、plan file、init script，以及 CLAUDE.md 或 AGENTS.md 等文件。跨 Session 延續： 將不可遺失的資訊寫入聊天歷史之外，讓 Agent 每次進場時能直接讀取明確的狀態說明，而非從模糊的對話紀錄中猜測進度。這種做法的核心觀念是「不要把對話當作唯一的工作載體」。透過將任務狀態從暫時記憶抽離並轉化為外部記錄，才能確保 Agent 在長時間運作中維持決策品質與穩定推進。

Q: 在系統設計中，為什麼「確定性控制」（Deterministic Control）必須下沉到系統層，而非僅寫在 Prompt 裡？

Prompt 本質上是對模型的語言引導，屬於非硬性的執行約束。當模型判斷失誤、上下文滿載或任務目標與規則衝突時，寫在 Prompt 裡的規則極易被弱化或遺失。為了確保規則「每次都必須成立」，成熟的架構會將其下沉至系統層（Deterministic Control Layer）。這類控制機制包含：Hooks 與 Checkpoints： 在特定節點強制執行檢查。權限引擎（Policy Engines）與分類器（Classifier）： 硬性限制操作範圍。自動化流程： 例如編輯後強制執行格式化（Format）或在壓縮上下文後重新注入關鍵資訊。這類設計類比於傳統軟體工程中，將關鍵業務約束放在資料庫 Schema 或驗證器中，而非僅靠前端文字提醒。Prompt 可以描述原則，但不能取代制度；唯有透過系統層的保證，才能提供務實且可靠的執行約束，這也是 Harness Engineering 中最容易被低估的務實環節。

Q: 請說明文中提到的三段式權限中介層設計，以及其解決了什麼樣的人機互動問題？

在 Agent 具備改檔、執行命令及存取網路的能力時，權限設計成為產品架構的核心。官方的設計思路是建立細緻的中介層，以解決「人工審批疲乏」的問題。當使用者頻繁點擊同意時，警覺性會崩壞，導致審批失去安全意義。三段式設計如下：低風險操作： 如讀取檔案或專案內的局部修改，可直接放行。限定範圍的自動操作： 如特定類型的測試、格式化或局部編輯，在預設範圍內自動執行。高風險操作： 如破壞性 Shell 指令、外部資料傳送或跨專案行為，必須由分類器識別或人工介入。</ol這種分層設計並非附屬功能，而是讓 Agent 的自主性（Autonomy）達到商用標準的必要條件。它在「全手動」與「全放權」之間取得平衡，確保安全性的同時，也避免了因過度干預而導致的使用者體驗惡化。

Q: 多 Agent 架構中的「Context Firewall」概念為何？它如何提升系統的穩定性？

Context Firewall（上下文防火牆） 是多 Agent 協作中的核心價值，其目的並非單純的任務平行化，而是為了保持主控 Agent 的上下文環境「乾淨」。其運作機制與優點包括：隔離調試過程： 主控 Agent 負責規劃與決策，而將局部任務交給獨立的子 Agent（Subagents）處理。子 Agent 在執行過程中的失敗嘗試、調試資訊或局部猜測會被隔離在其獨立的上下文中。避免污染： 當子 Agent 完成工作後，僅將必要的結果與結論回傳給主控 Agent，防止主線對話被瑣碎資訊污染，進而維持高品質與長壽命。角色拆分： 透過將認知工作拆分為 Planner（規劃者）、Generator（生成者） 與 Evaluator（驗證者），可以避免單一 Agent 同時負責多職時容易產生的「自我肯定偏差」或失焦問題。這種架構思路能建立穩定的審查迴路（Review Loop），確保系統在處理複雜任務時，能透過隔離與分工提升整體的交付品質。

AI 根據文章內容回答

Harness 是包在 AI 模型外層的一套厚重的工程包裝，它是將模型轉化為可靠產品的關鍵結構。根據內容，Harness 的核心組成包括：

執行環境與工具接口： 提供模型運作的場所及與外部工具互動的管道。
權限制度： 規範 Agent 的行為邊界，防止其在未經授權下做出高風險決策。
記憶機制與任務編排： 管理任務狀態並規劃執行流程。
驗證流程： 讓 Agent 具備自我審查與確認產出品質的能力。

Harness 的本質並非單純增加功能，而是「把不穩定的模型變成可管理的系統」。模型本身存在不穩定、易失焦及在資訊不全時自作主張的問題，Harness 透過工程細節壓低錯誤率、縮小失控邊界，並確保流程可回退、可重來且可審查。這使得成熟的 AI 產品不再只是「模型加殼」，而是將模型視為其中一個元件的完整系統。

其他問題

Q2 為什麼單純增加上下文長度（Context Window）不足以解決長任務處理的問題？有效的解決方案是什麼？ Q3 在系統設計中，為什麼「確定性控制」（Deterministic Control）必須下沉到系統層，而非僅寫在 Prompt 裡？ Q4 請說明文中提到的三段式權限中介層設計，以及其解決了什麼樣的人機互動問題？ Q5 多 Agent 架構中的「Context Firewall」概念為何？它如何提升系統的穩定性？