跳到正文
HumanLayer Blog·· 2026-03-12精選AI 評分76

編碼智能體的 Harness Engineering：以配置改善可靠性

Skill Issue: Harness Engineering for Coding Agents

AI 導讀

HumanLayer Blog 指出，編碼智能體的許多失誤與 harness 配置有關，並整理透過配置改善輸出質素和可靠性的做法。文章建議按實際失誤調整 CLAUDE.md/AGENTS.md、MCP、技能、子智能體及 hooks，並以精簡的驗證回饋避免無關輸出佔用上下文。

推薦理由

文章將編碼智能體的可靠性問題連到 harness 配置，並整理按實際失誤調整上下文、工具與驗證機制的方法，提供可逐步迭代的工程思路。

正文 · 繁體中文

過去一年，我們目睹編碼代理以各種可以想像得到的方式出錯：忽略指示、未經提示便執行危險命令，以及在最簡單的任務上原地打轉。

我們見過團隊推出大量低質內容。我們自己甚至也推出過少量低質內容。

每次我們的直覺都一樣：

  • 「我們只需要更好的模型，GPT-6 就會解決問題。」
  • 「我們只需要更好的指示遵循能力。」
  • 「等[我正在使用的小眾程式庫]納入訓練資料後，一切就會正常運作。」

但在進行數十個項目、執行數百次代理工作階段後，我們一次又一次得出相同結論：問題不在模型，而在設定。

沒錯，模型會變得更聰明，部分現有的失效模式也會消失。但正因為模型更聰明，我們會交給它們更大、更難的新問題，而它們仍會以意想不到的方式出錯。對非確定性系統而言，意料之外的失效模式是根本問題。

gpt-6

所以，與其祈求 gpt-6.4-codex-ultrahigh_extended 拯救所有人，我們更專注於回答這個問題：「我們如何充分發揮現今模型的效能？」

有很多方法可以提升編碼代理的表現。如果你用編碼代理處理中等難度的任務，可能已經為它作過一些設定。你用過技能嗎？MCP 伺服器？子代理？記憶？AGENTS.md 檔案？

coding agent = AI model(s) + harness

這些在技術上各自獨立，但全都屬於編碼代理的設定範疇。我們稱之為編碼代理的 harness，並將它視為代理的執行環境，或是它的周邊設備：模型會使用甚麼與環境互動？

## Harness 工程

由Viv創造的Harness 工程一詞，指的是善用這些設定項目，改善編碼代理輸出質素及可靠性的做法。

harness components 圖片來自Viv 的帖文

正如Mitchell Hashimoto 所説，Harness 工程

[...] 的理念是，每當你發現代理犯錯，就花時間設計一個解決方案，確保代理不會再犯同一個錯誤。

## ……作為上下文工程的子集

我們將 Harness 工程視為上下文工程的子集。上下文工程一詞由我的共同創辦人Dex在12-factor agents中創造，是「提示詞工程」及其他一系列技巧的上位概念，旨在有系統地提升 AI 代理的可靠性。你可以在這裏找到原始演講。

Harness 工程則是上下文工程的一個子集，主要透過善用 harness 設定項目，謹慎管理編碼代理的上下文視窗。

harness engineering as context engineering

它要回答以下問題：

  • 如何為編碼代理加入新能力？
  • 如何教它訓練資料中沒有的程式碼庫資訊？
  • 如何在系統訊息中的 CRITICAL: always do XYZ 以外加入確定性？
  • 如何調整代理的行為，以配合我們的特定程式碼庫？
  • 除了「神奇提示詞」之外，如何提高任務成功率？
  • 如何避免上下文視窗膨脹得太快，或塞入太多劣質上下文？

技能、MCP 伺服器、子代理、hooks 及背壓機制，都是我們採用的戰術性解決方案。

### 對 Harness 工程的看法

Viv 關於 harness 工程的文章值得與這篇一併閲讀——第一篇介紹四個自訂槓桿（系統提示詞、工具／MCP、上下文、子 Agent），而第二篇則從模型原生無法做到的事情反向推導，説明每個 harness 元件存在的原因。

working backwards from what models can't do natively 圖片取自Viv 的貼文

我們會再補充兩個他沒有特別強調的調整槓桿：

  1. hooks，用於自動化整合及確定性控制流程
  2. skills，用於逐步揭露知識。（Dex 喜歡稱之為「指令模組」——更多內容會在另一篇文章中介紹。）

經過數月在複雜、既有的企業級程式碼庫中解決棘手問題後，我們發現子 Agent 是一個特別有力的槓桿。面對需要使用大量上下文視窗才能解決的棘手問題時，子 Agent 是在多個工作階段中維持一致性的關鍵。子 Agent 充當「上下文防火牆」，確保各項獨立任務可在隔離的上下文視窗中執行，避免中間過程的雜訊累積在負責協調工作的父執行緒中，讓你能在更長時間內維持一致性。

context firewall

OpenAI 最近也就此發表了一篇網誌文章。文章有不少精彩內容，似乎顯示他們認為 harness 工程就是設定 Agent 執行階段以外的一切。文章較著重背壓和驗證機制。（不過，這可能是我們理解有誤；文章內容有些含糊：文章正文只出現一次「harness」一詞，而且提及的是評測，而非 harness 工程本身。）

### 後訓練又如何？

既然前沿編碼模型會以其 harness 作為後訓練環境（例如 Claude 在 Claude Code 中、GPT-5 Codex 在 Codex 中），有人會主張，最佳的 harness 及／或設定，就是模型接受訓練時所用的那一套。

例如，Codex 模型與 Codex harness 的 apply_patch 工具緊密耦合，以開源替代方案方式打造、用來取代 Claude Code 的 OpenCode，不得不加入 apply_patch 工具，專門供 GPT／Codex 模型使用，以模仿 Codex harness，提升這些模型在 OpenCode harness 中的表現；而 Claude 和其他模型仍會使用一般的 edit 和 write 工具。

這可能表示，模型搭配其接受後訓練時所用的 harness，表現會更好；有人或會因此推斷，你不應自訂 harness。

但事情有另一面：模型可能會對其 harness 過度擬合。Viv 引用了Terminal Bench 2.0的結果：Opus 4.6 在 Claude Code 中排名第 #33，但放進一個後訓練時未曾接觸過的 harness 後，排名升至第 #5（任一方向約 +/- 4 個名次）。

terminal bench

## 打造你的 Harness

有了這些背景，讓我們看看哪些設定層面對我們影響最大。

### CLAUDE.md & AGENTS.md

在調整其他 harness 設定項目之前，通常值得先自訂 CLAUDE.md / AGENTS.md 檔案。這些 Markdown 檔案存放於程式碼儲存庫頂層，由 harness 以確定性方式注入 Agent 的系統提示詞。

我們已分享過一些關於優質 CLAUDE.md 檔案的看法，以及如何正確使用這類檔案；如果你對此不熟悉，不妨讀一讀。Matt Pocock 亦撰寫了一篇很好的後續文章，內容更廣泛地適用於 AGENTS.md。

#### ETH Zurich 的研究

ETH Zurich 發表了一項在多個儲存庫中測試 138 個 agentfile 的研究，結果顯示大部分 agentfile 毫無用處，甚至有害。之後，我們收到不少關於那篇 CLAUDE.md 文章的回應：

你看，CLAUDE.md 檔案根本沒有幫助，只是浪費時間。

的確，該研究在各式各樣的儲存庫中測試了多個 agentfile，並發現：

  • 由 LLM 生成的檔案實際上會降低效能，同時令成本增加 20% 以上
  • 人手撰寫的檔案則只帶來約 4% 的改善。
  • Agent 處理上下文檔案指示時，多消耗 14-22% 的推理 token，完成任務所需步驟更多，使用的工具也更多，但任務解決率並無提升。
  • 程式碼庫概覽和目錄清單完全沒有幫助；Agent 本身已能很好地探索儲存庫結構。

仔細閲讀研究內容，可見我們文章中的説法是正確的：

  • 由 Agent 生成的檔案效果更差。沒錯，我們當時説過：

    避免自動生成檔案。你應仔細編寫其中的內容，以取得最佳效果。

  • 許多檔案過度引導模型使用特定工具，導致結果更差。沒錯，我們當時説過：

    指示愈少愈好。雖然不應省略必要指示，但應在檔案中加入盡可能少的指示。

  • 檔案包含無關的上下文。沒錯，我們當時説過：

    採用漸進式揭露

  • 人手撰寫的檔案幾乎沒有幫助，原因是包含太多條件式規則。沒錯，我們當時説過：

    CLAUDE.md 的內容應精簡，並普遍適用。

我們的 CLAUDE.md 不足 60 行。

### MCP 伺服器用於提供工具

MCP 伺服器 主要用於將工具接入編碼 Agent，讓它具備檔案 I/O 和 bash 指令以外的功能。MCP 規格亦包含資源、提示詞和引導式提問等其他功能，但MCP 用戶端和編碼 Agent 框架通常未能妥善支援這些功能。

MCP 規格支援在你（或 Agent）的本機執行的伺服器，讓 Agent 能與本機環境互動；此外，規格亦支援以 HTTP 為基礎的 MCP 伺服器，讓 Agent 連接 Linear、Sentry 等遠端工具和服務。

將 MCP 伺服器接入編碼 Agent 時，可用工具清單、工具説明及呼叫工具所需的引數，都會注入編碼 Agent 的系統提示詞中。因此，MCP 伺服器可以利用工具説明，向 Agent 提供何時使用工具的指示，從而調整 Agent 的行為。 

警告：由於 MCP 伺服器的工具説明會加入編碼 Agent 的系統提示詞，切勿連接不信任的伺服器。這可能成為提示詞注入的危險途徑！即使沒有提示詞注入，STDIO 伺服器及其他透過 npx 或 uvx 在用戶端執行的伺服器，也能在你的主機上執行程式碼。

#### 工具太多並非好事

我們親身經歷過：在 Agent 中接入太多 MCP 工具，工具説明就會填滿上下文視窗，令你更快進入「愚蠢區域」：

too many tools

指令預算同樣重要——每項無關的工具説明，都是代理程式必須處理、卻毫無益處的指令。

事實上，這些失效模式如此常見，以至於 Anthropic 推出了MCP 工具搜尋的實驗性支援，讓 Claude 在用戶連接了過多 MCP 工具時，逐步取得工具資訊。簡而言之：如果你沒有積極使用提供大量工具的伺服器，就把它關掉。

我們亦發現，如果 MCP 伺服器提供的功能，與訓練資料中已有充分示例的 CLI 重複，直接提示代理程式使用 CLI 效果更好。對於 GitHub、Docker 或大多數資料庫等工具，你的程式碼代理程式可以直接使用合適的 CLI 和 shell 指令。模型在訓練期間已充分接觸這些工具，因此早已知道如何使用；此外，你還可以將它們與 grep 和 jq 等工具組合使用，進一步提升上下文效率。

#### 時刻進行上下文工程

在 HumanLayer，我們曾使用 Linear MCP 伺服器一段時間，後來才發現自己實際上只會用到它提供的一小部分工具——於是我們編寫了一個小型 CLI，封裝 Linear API 並提供上下文效率更高的回應，還在CLAUDE.md檔案中加入了 6 個使用範例：

## Linear

Use the Linear CLI for:

- **fetching issues**: `linear get-issue ENG-XXXX`
- **listing issues**: `linear list-issues` or `linear my-issues`
- **adding comments**: `linear add-comment -i ENG-XXXX "comment"`
- **adding links**: `linear add-link ENG-XXXX "url" -t "link title"`
- **updating status**: `linear update-status ENG-XXXX "status name"` ("spec needed", "research needed", "research in progress", "research in review", "ready for plan", "plan in progress", "plan in review", "ready for dev", "in dev", "code review")
- **get branch name**: `linear get-issue-v2 ENG-XXXX --fields branch` (use this when creating a worktree)
- **get images from the ticket**: `linear fetch-images ENG-XXXX` (do this any time the ticket has images in the description)

這為我們省下了數千個 token，因為 MCP 伺服器的工具定義原本會出現在代理程式的系統提示詞中；冗長的 MCP 伺服器回應則另外省下更多 token。 

### 技能適用於可重用的知識（及工具）

技能最初由 Anthropic 推出，供 Claude Code 使用，後來已成為開放標準，並獲 Codex 和 OpenCode 等其他執行環境支援。你可以在Anthropic 文件中瞭解技能的結構——在這裏，重要的是它們為何有用。

在繼續之前先提醒一下：技能登錄平台已被發現分發數百個惡意技能。對待技能時，應像對待 npm install random-package 一樣——仔細閲讀你要安裝的內容。ClawHub和skills.sh等平台可以在你的電腦上執行任意程式碼。

#### 逐步披露

我們很早就學到這一點：我們不斷把所有指示和工具塞進系統提示詞，結果代理程式的表現愈來愈差。代理程式甚至還未開始工作，我們的指令預算就已耗盡。技能透過逐步披露解決這個問題——只有在代理程式判斷（或由你替它判斷）需要時，它才會取得特定指示、知識或工具。

#### 啟用技能

啟用技能時，技能目錄中的 SKILL.md 檔案會以用戶訊息的形式載入代理程式的上下文視窗，代理程式亦會得知技能檔案的載入目錄。SKILL.md 檔案則可以告知代理程式技能還附帶了哪些其他內容：

example-skill/
|--- SKILL.md
|--- response_template.md
|--- CLIs/
   |--- linear-cli
   |--- tunnel-cli

由於每項技能都有自己的目錄，你可以更靈活地運用逐步披露：例如在技能中附帶多個 Markdown 檔案，分別介紹不同功能或用途；主 SKILL.md 檔案則可以告訴代理程式技能中還有哪些檔案，以及它應否和何時閲讀這些檔案。

#### 透過技能分發工具

不幸的是，無法將 MCP 伺服器或自訂 Agent 工具直接打包到技能中——你必須將它們寫入可執行檔、CLI、NPM 套件或其他形式，然後與技能一併發佈，或在技能檔案中指示 Agent 安裝。

例如，與其設定 Playwright MCP 伺服器，不如直接提供一項用於瀏覽網頁的技能，讓 Agent 使用 BrowserBase 的 Agent 瀏覽器技能或 Vercel 的 Agent 瀏覽器 CLI。

### 子 Agent 用於控制上下文

子 Agent 是常見但經常被誤解的 Harness 配置項目。我們試過「前端工程師」子 Agent、「後端工程師」子 Agent 和「數據分析師」子 Agent 那套做法，結果行不通。真正有效的是用子 Agent 來控制上下文。

這種做法能把整個編碼 Agent 工作階段的工作封裝起來，讓負責派發工作的 Agent 只會看到自己為子 Agent 撰寫的提示詞，以及子 Agent 的最終結果。所有中間工具呼叫、工具結果及其他訊息都不會進入父層編碼 Agent 的上下文視窗。

sub-agents

把工作拆分成明確的個別任務，再交由子 Agent 負責，是我們讓主要編碼 Agent 的對話串保持在「聰明區」的方法。日常工作流程中的研究、實作及其他多項上下文密集型工作，我們都會這樣處理。

#### 子 Agent 可避免上下文腐化

Chroma 的上下文腐化研究提供了實證支持，證明我們早已指出的一點：模型在上下文長度增加時，表現會變差。避開愚笨區。

Chroma 的研究人員以大海撈針任務測試了 18 個模型。誠然，這與 Agent 式編碼大不相同，但研究結果與我們的經驗完全吻合：上下文長度增加時，表現會下降，即使是簡單任務也不例外。

更糟的是，當問題與上下文中相關資訊的語義相似度較低時，表現下降的幅度會更大。我們親眼看到這種情況即時發生：父層工作階段中的每一次中間工具呼叫、每一項 grep 結果，以及每一次最終證明無關的檔案讀取，都可能成為幹擾因素；Chroma 的研究證實，隨著上下文視窗變長，幹擾效應會累積。

#### 旁註：長上下文模型

這也是我們對「只要加大上下文視窗」這種編碼 Agent 解決方案抱持懷疑的原因。當研究機構推出某個模型的擴展上下文版本時，你通常不是得到一個更大、具有更大「指令預算」的模型，而是得到同一個模型，再配合一些巧妙的數學方法（例如 YaRN），延長模型可以關注的序列長度。

想想大海撈針問題。更大的上下文視窗不會令模型更擅長找出那根針，只會令乾草堆變得更大。就我們而言，這代表你可以把更多指令（每則用戶訊息至少包含一項指令，通常有多項）塞進上下文視窗，讓自己愈陷愈深地進入「愚笨區」。

long context

如果你認為自己需要更長的上下文，可能只是需要更妥善地隔離上下文視窗。子 Agent 從結構上解決了這個問題：每個子 Agent 都會為自己的任務取得一個全新、較小且高度相關的上下文視窗，以及一份全新的「指令預算」；只有精簡後的結果會傳回父層，讓你可以為同一個問題串連多個上下文視窗。

極限情況大概會像這樣，不過到某個程度，就會進入 Recursive Language Model 的領域。

limit case

（註：為求簡潔，省略了部分箭頭。）

#### 子代理的適用情境

適合使用子代理的例子包括：

  • 在程式碼庫中尋找特定定義或實作
  • 分析程式碼庫，找出某類工作的模式
  • 追蹤資訊在程式碼庫中的流向，例如追蹤請求如何跨越不同服務
  • 其他一般的程式碼、文件或網絡研究工作

這類任務通常問題明確、答案簡單，但需要進行大量中間工具呼叫，而你不希望或無需在父工作階段中進行這些呼叫。子代理應提供高度精簡的回覆，並遵循逐步披露原則。例如，我們的子代理會回答問題，同時以 filepath:line 格式引用來源或附上網址，讓父代理毋須接觸子代理使用的所有來源；但如果父代理需要更多詳情或確認，也會取得所需資訊，以便尋找相關脈絡：

compaction

Dex 在這裏有更詳盡的説明。

Claude Code 和其他一些編碼代理甚至提供內置的特定任務子代理，例如 Claude Code 用於探索程式碼庫的 Explore 子代理，或專為執行冗長 bash 指令並擷取資訊而設的 Bash 子代理；後者會把資訊傳回父代理，同時避免污染其上下文。其他編碼代理支援子代理，但沒有自行定義子代理；如有需要，用戶必須手動設定。

#### 子代理亦可控制成本

子代理亦有助控制成本。我們會在父工作階段使用昂貴的模型（Opus），處理規劃和協調等需要大量思考的任務；每個子代理則使用較便宜、速度較快的模型，例如 Sonnet 或 Haiku。子代理接收的任務較小且範圍更明確，能力較低、擁有較小「指令預算」的模型也能處理，因此無需把 Opus token 浪費在程式碼庫的 grep 搜尋上。

#### 所以，我們聽説你喜歡子代理

有些 harness 完全不支援子代理！就連 Codex 直到最近才支援，而且目前仍屬實驗性功能。

幸好，你仍可透過編寫 MCP 伺服器來使用這種強大的上下文封裝模式：伺服器提供一項工具，用來啟動新的代理工作階段。該工作階段會接收父代理傳來的提示詞，並以該提示詞作為用戶訊息啟動新的編碼代理工作階段，然後把子代理的最終回覆訊息傳回父代理。

這裏有一個非常粗略的伺服器範例，可用來實作這種做法。警告：如果使用這種模式的編碼代理本身支援子代理，harness 內置的子代理便可以透過 MCP 派遣子代理，結果可能會形成難以預測的傳話遊戲：

telephone

説笑而已；實際上，撰寫子代理的系統提示詞時，必須格外小心，清楚界定其職責範圍：

  • 代理的職責是甚麼——應該做甚麼，以及不應該做甚麼
  • 代理應回傳甚麼資訊，以及應如何回傳
  • 子代理應該使用哪些工具？

另外值得注意的是，許多 harness 都設有 MCP 工具呼叫逾時限制；如果你採用這種模式，可能需要設定 harness，延長 MCP 工具呼叫逾時限制。

### Hooks 用於控制流程

Claude Code 有「掛鈎」這個概念：使用者定義的命令或指令碼，會在特定事件發生時，以及 Agent 生命週期的不同階段自動執行。同樣地，Opencode 也有「外掛」這個概念，作用相同。其他編碼 Agent 可能也有類似的設定點。（可惜 Codex 沒有相應的功能。）

掛鈎的概念與 git 掛鈎相似，但靈活得多。它們可用於新增功能、整合外部服務、自動執行例行工作、修改權限，以及設定預設行為。

各種執行框架的實作細節有所不同，但一般而言，掛鈎可以：

  • 在事件發生時自動執行某項操作，而不顯示任何訊息
  • 在呼叫工具時執行，並在工具結果以外向 Agent 提供額外脈絡
  • 在編碼 Agent 完成工作前，向它顯示建置或類型檢查錯誤，迫使它繼續工作，直至解決錯誤

常見用途包括……

  • 通知：我們會設定 Agent 在完成工作或需要注意時播放聲音（例如核准要求待處理太久）

  • 核准：我們會根據輸入值及比編碼 Agent 預設權限模型更靈活的規則，自動核准或拒絕工具呼叫。例如，對於任何嘗試執行資料庫遷移的 Bash() 工具呼叫，我們都會自動拒絕，並指示 Agent 改為請用戶執行。

  • 整合：我們會讓 Agent 在完成工作時傳送 Slack 訊息、建立 GitHub PR，或設定預覽環境。

  • 驗證：如果你的框架和程式碼庫能在數秒內完成類型檢查或建置，就在 Agent 每次停止時執行，以便向它顯示錯誤——下方的掛鈎正是這樣做。

#### 掛鈎範例

以下是我透過 Claude 為我們的程式碼庫編寫的掛鈎，實作了我剛才提到的最後一個例子。Claude 停止時，掛鈎會執行我們的 Biome 格式化工具和 TypeScript 類型檢查。如果有錯誤，就會回報給 Claude；如果沒有，指令碼便會靜默結束。

#!/bin/bash
cd "$CLAUDE_PROJECT_DIR"

# prebuild generates types and builds internal SDK packages so typecheck has
# everything it needs. runs bun install afterward to pick up any new generated files.
PREBUILD_OUTPUT=$(bun run generate-cache-key && turbo run build --filter=@humanlayer/hld-sdk && bun install 2>&1)
if [ $? -ne 0 ]; then
  echo "prebuild failed:" >&2
  echo "$PREBUILD_OUTPUT" >&2
  exit 2
fi

# biome and typecheck run in parallel to keep the feedback loop tight.
# one quirk: biome --write exits with code 1 if it made any changes, even if it
# successfully fixed everything. so we run it twice with ||: if the first pass
# makes changes and exits 1, the second pass will exit 0 since there's nothing
# left to fix. if there are unfixable errors, both passes fail and exit 2.
OUTPUT=$(bun run --parallel \
  "biome check . --write --unsafe || biome check . --write --unsafe" \
  "turbo run typecheck" 2>&1)

if [ $? -ne 0 ]; then
  echo "$OUTPUT" >&2
  exit 2
fi

成功時，掛鈎完全不會顯示任何訊息——Agent 的脈絡中不會出現任何內容。失敗時，只會顯示錯誤；結束代碼 2 會告知執行框架重新讓 Agent 繼續工作，確保它在完成前修正錯誤。

## 背壓提升成功機會

我們之前談過背壓。核心觀點是，使用編碼 Agent 成功解決問題的可能性，與 Agent 驗證自身工作的能力密切相關。我們花了很多時間在程式碼庫中建立測試及其他背壓機制；這仍然是最值得投入時間的事項之一。

我們的程式碼庫設有驗證機制，讓 Agent 檢查自己的工作：

  • 類型檢查和建置程序（很可能使用強型別語言）
  • 單元測試及／或整合測試
  • 程式碼覆蓋率報告（我們有一個 Stop 掛鈎，會在覆蓋率下降時提示 Agent 提高覆蓋率）
  • 使用者介面互動及測試整合工具（playwright、agent-browser 等）

關鍵是，這些驗證機制必須有效利用上下文。我們曾經從慘痛經驗中學到這一點——初期我們每次修改後都會讓代理執行完整測試套件，4,000 行通過測試的結果會塞滿上下文視窗。代理隨後便會忘記實際任務，開始對剛讀過的測試檔案胡亂編造。現在我們會吞掉輸出，只顯示錯誤。建置時我們也採用同樣做法——成功時不顯示訊息，只有失敗時才會輸出詳細內容。

我們會在 CLAUDE.md 檔案中，向 Claude 提供簡潔的指示，説明如何使用所有這些機制。其中一些甚至會包裝在技能中，以便漸進式揭露。

## 結語

你完全可能花更多時間優化編碼代理的設定，而不是用它交付程式碼——我們也曾經如此。

我們的做法：以交付為先。只有在 harness 設定確實能幫助我們更快交付更多高質素程式碼時，我們才會花時間處理。代理出錯時，我們會花時間設計解決方案，避免它再次犯同樣的錯誤；但我們不會預先尋找問題來解決。

對我們來説行不通的做法：

  • 還未遇到實際故障，就先嘗試設計出理想的 harness 設定
  • 「以防萬一」安裝數十種技能和 MCP 伺服器
  • 每次代理工作階段結束時都執行整個測試套件（耗時 5 分鐘以上）（改為執行其中一部分）
  • 嘗試微調各個子代理可以使用哪些工具。這造成大量工具來回切換，結果不但沒有改善，反而更差。而且，大多數編碼代理本來就沒有完善的設定介面可供此類配置。

對我們來説行之有效的做法：

  • 從簡單做起，只在代理實際出錯時才新增設定
  • 設計、測試、反覆改進，並捨棄沒有幫助的東西。我丟棄的 hooks 遠比目前實際使用的多。
  • 透過儲存庫層級設定，將經過實戰驗證的配置分享給整個團隊
  • 以迭代速度為優先，而不是追求「首次嘗試便成功」
  • 先賦予代理一組能力（Linear），確定所需功能後，再仔細精簡向模型開放的內容。

下次編碼代理的表現不如預期時，先別怪責模型，檢查一下 harness。Agentfiles、MCP 伺服器、技能、子代理、hooks 和背壓機制——我們發現大部分可發揮作用的地方都在這些環節。模型大概沒有問題，只是技能問題。

來源：HumanLayer Blog · humanlayer.com

#教學/實踐#Agent#編碼#MCP/工具調用#Anthropic#OpenAI