事實
術語 · LLM 工程 · AI 代理 · 效能評測 · AI 人工智慧 · 說明這個名詞與這門功夫，2022 年 10 月至 2026 年 9 月
五篇之三 · 最外面的那一層
起初只是調校一個代理，到了三月，它指的是模型以外的一切
2025 年 11 月 4 日，Dex Horthy 寫道他看到一種新做法正在出現，並打算稱之為駕馭工程：把情境工程的原則用在使用者接進既有程式代理的指令、鉤子、技能與工具上。2026 年 2 月 5 日，不知道有任何公認名稱的 Mitchell Hashimoto，用同一個詞指同樣大小的東西——一份指示檔和幾支腳本。3 月 10 日，Vivek Trivedy 把它定義為代理裡模型以外的一切，百科全書如今給的就是這個意思。文獻把這個詞歸給 Hashimoto 或 Trivedy，但兩種歸屬都沒提到目前找到最早的那則貼文。此後真正量測到的，比宣稱的窄：固定模型、只換駕馭層，分數會動，動多少則看是哪個模型。
兩次小用法，接著一個大定義 這個詞兩度只有使用者設定那麼大，之後才變得和整個代理一樣大。
- 93天，從目前找到最早的用法到 Hashimoto 的用法
- 33天，從 Hashimoto 的用法到 Trivedy 把它定義為模型以外的一切
- 13.7分，在 Terminal Bench 2.0 上固定模型、只換駕馭層所得的進步，這是 LangChain 對自家代理的自述
- 0個來源調和了「駕馭工程包含情境工程」與「駕馭工程是情境工程的一種」這兩種說法
Dex Horthy · X · 2025 年 11 月 4 日
「我會稱之為駕馭工程」
- 他的定義：把情境工程的原則用在「你怎麼使用一個既有的代理」——以 Claude Code 來說，就是使用者接進去的「指令、鉤子、技能、代理、MCP 等等」。
- 他的問題是：怎麼設計一個既定代理的整合點，才能得到最好的結果？
- 四個月後，他共同創辦的公司 HumanLayer 在部落格上把這個詞的創造歸給了 Trivedy。
Mitchell Hashimoto · 2026 年 2 月 5 日
「我漸漸開始把這個叫做駕馭工程」
- 他說他不知道業界有沒有公認的名稱，如果有，他會跟著用。
- 兩種形式，範圍就這麼大：一份每一行都來自某次代理壞行為的
AGENTS.md，以及「真正寫出來的工具」，例如截圖和篩選測試的腳本。 - 它指的規則是：代理犯了錯，就設計一個修正，讓它不再犯同樣的錯。
Vivek Trivedy · LangChain · 2026 年 3 月 10 日
代理 = 模型 + 駕馭層
- 「不是模型的，就是駕馭層」：凡不是模型本身的程式碼、設定與執行邏輯都算——檔案系統、沙盒、瀏覽器、協調邏輯、鉤子。
- 他說這條界線是一種選擇：劃法有「許多凌亂的方式」，而他認為這一種最乾淨。
- 百科條目、整理清單、研究論文和廠商說明文，用的都是這個意思，而不是先前那個。
維基百科 · 2026 年 9 月 12 日版本
「圍繞大型語言模型的軟體基礎設施」
- 它負責「工具使用、記憶、狀態保存、執行環境與回饋迴圈，而不是模型內部的推理」。
- 它說這個詞的歸屬在 Hashimoto 與 Trivedy 之間有爭議。Horthy 沒有被提到。
- 它把 Anthropic 那篇長時間代理駕馭層的文章標為 2026 年。文章本身寫的是 2025 年 11 月 26 日。
以上每一項有多確定？ 由貼文本身能證明的，排到本頁自己的推論。
| 確信程度 | 內容 | 依據 |
|---|---|---|
| 讀過原始出處 | Horthy 在 2025 年 11 月 4 日用了這個詞，指把情境工程用在既有代理的整合點上 | 他在 X 上的貼文，附時間戳記 |
| 讀過原始出處 | Hashimoto 在 2026 年 2 月 5 日用了它，並說他不知道有公認的名稱 | 他自己的文章，有日期，他說是親手寫的 |
| 讀過原始出處 | Trivedy 在 2026 年 3 月 10 日定義了代理 = 模型 + 駕馭層 | LangChain 部落格，具名且有日期 |
| 自述 | 在 Terminal Bench 2.0 上，固定 gpt-5.2-codex，從 52.8% 到 66.5% | LangChain 自家的代理，Trivedy 於 2026 年 2 月 17 日發表。LangChain 賣的正是駕馭層函式庫 |
| 自述 | 約一百萬行程式碼、大約 1,500 個拉取請求，沒有一行是人手寫的 | OpenAI 談自己的團隊，2026 年 2 月 11 日 |
| 見諸文字的爭議 | 駕馭工程是情境工程的一種，還是把它包在裡面 | 五則說法支持前者，兩則支持後者；見第三節 |
| 見諸文字的爭議 | 誰造的詞：HumanLayer 與 Osmani 說是 Trivedy；維基百科說是 Hashimoto 或 Trivedy | 三者都寫在 Horthy 的貼文之後，也都沒有提到它 |
| 有出處，但無法查核 | 在 Terminal Bench 2.0 上，Claude Code 裡的 Opus 4.6「分數遠低於」其他駕馭層裡的 Opus 4.6 | 這是 Trivedy 的說法。排行榜已不再列出 Opus 4.6，差距無從查對 |
| 本頁的解讀 | 這個詞兩度從使用者那一端、以很小的範圍出現，之後一個定義才讓它變成模型以外的一切 | 由有日期的貼文拼出來。沒有任何來源這樣說 |
時序
先有名詞，再有這個詞組，然後是定義，最後是研究 每個日期都從文件本身讀出。
- 2022 年 10 月迴圈，先以論文出現。Yao 等人發表 ReAct，讓模型在推理與行動之間交替。此後的駕馭層都跑這個循環：模型推理，駕馭層執行並記下結果，模型再讀結果。
- 2023 年 2 月工具，也以論文出現。Toolformer 顯示語言模型可以自學透過簡單介面呼叫外部工具。
- 2024 年 12 月先有想法，沒有名字。Anthropic 主張代理與電腦之間的介面，值得投入和人機介面一樣多的心力，並要開發者替工具做防呆——改寫參數，讓錯誤更難發生。
- 2025 年 9 月 23 日這個名詞先有了工作定義。Trivedy 在個人部落格上把代理駕馭層定義為一組增強模型執行時表現的外部功能——情境管理、工具、權限、狀態、迴圈控制、可觀測性。「駕馭工程」這個詞組沒有出現。
- 2025 年 11 月 4 日目前找到最早的用法。Dex Horthy 發文說他看到一個新概念正在出現，「我會稱之為『駕馭工程』」：把情境工程用在你怎麼使用一個既有代理上。以 Claude Code 來說，就是使用者接進它原廠駕馭層的指令、鉤子、技能、代理和 MCP 伺服器。他還說：不懂情境工程，就做不了駕馭工程。
- 2025 年 11 月 26 日做法，完整發表。Anthropic 的 Justin Young 描述一套給長時間代理用的駕馭層：一個初始化代理先寫好
init.sh、進度檔和第一次提交，一個編碼代理每次工作只做一項功能。功能清單用 JSON，因為模型比較不會去改寫 JSON 檔。光靠壓縮情境並不夠。 - 2026 年 1 月 23 日這個名詞在 OpenAI 已經很平常。Michael Bolin 解說 Codex 的代理迴圈時順口帶出：「我們的代理（或者說『駕馭層』）在運用大型語言模型時扮演的角色」。
- 2026 年 2 月 4 日連解釋都不用了。OpenAI 的 Celia Chen 寫道：網頁版、命令列、IDE 擴充與 macOS 應用程式「全都由同一套 Codex 駕馭層驅動」。
- 2026 年 2 月 5 日這個詞再度出現，指一個習慣。Mitchell Hashimoto 記述自己採用 AI 工具的歷程，寫到他稱為「打造駕馭層」的那一步：他不知道有公認名稱，「漸漸開始把這個叫做『駕馭工程』」，若有別的詞，他願意改用。它指的是一份每一行都回應某次代理壞行為的
AGENTS.md，外加幾支腳本。 - 2026 年 2 月 11 日這個詞成了標題。OpenAI 的 Ryan Lopopolo 發表〈駕馭工程〉：五個月、約一百萬行程式碼、大約 1,500 個拉取請求，全由 Codex 撰寫，沒有人手寫的程式碼，團隊從三名工程師增加到七名。內文裡 harness 一詞只出現一次，在「評測駕馭框架」裡。這些數字是 OpenAI 自己的。
- 2026 年 2 月 17 日一項量測，一份備忘。Trivedy 報告 LangChain 的編碼代理在 Terminal Bench 2.0 上從 52.8% 升到 66.5%——從前三十名之外進到前五名——模型固定為 gpt-5.2-codex：「我們只改了駕馭層。」同一天，Birgitta Böckeler 發表第一份談駕馭工程的備忘，時值「這個詞剛出現」。
- 2026 年 3 月 10 日這個詞被撐得極大。Trivedy 發表〈代理駕馭層剖析〉：代理 = 模型 + 駕馭層，每個元件都從一種想要的行為倒推出來——檔案系統為了持久狀態，bash 為了自主，沙盒為了有個安全的行動場所，鉤子為了確定性的控制。Hashimoto 發文後三十三天，這個詞已涵蓋模型以外的一切。
- 2026 年 3 月 12 日第一次歸屬。Horthy 共同創辦的 HumanLayer 說駕馭工程「由 Viv 創造」——同一篇文章又說它是「情境工程的一個子集」。
- 2026 年 3 月 24 日一條拿掉東西的原則。Anthropic 的 Prithvi Rajasekaran 說：駕馭層裡的每個元件，都寫進了一個「模型自己做不到什麼」的假設，而這些假設會隨模型進步而過時。換上較新的模型後，他拿掉了一整層任務拆解。
- 2026 年 4 月 2 日使用者這一端有了形狀。Böckeler 的完整文章把駕馭層分成代理動手前引導它的「引導」與動手後觀察的「感測」，各自又分為計算式或推論式，並把編碼代理本身已內建的那部分駕馭層，和使用者替它打造的外層駕馭層分開。她的側欄寫道：使用者的駕馭層，是情境工程的一種特定形式。
- 2026 年 4 月 19 日一篇綜述，第二次歸屬。Addy Osmani 在自己的部落格發文，5 月 15 日由 O'Reilly 轉載：「Viv Trivedy 創造了駕馭工程這個詞。」他開頭引的是 Hashimoto 的規則，把 Trivedy 的公式稱為「Viv 的一句話」，並補上自己的：只有看到真正的失敗，才加約束。
- 2026 年 5 月它成了研究題目。5 月 7 日一篇立場論文主張，在長任務上駕馭層往往比模型更重要，不揭露駕馭層就比較模型的排行榜會誤導人。5 月 13 日，Hailin Zhong 與 Shengxin Zhu 把駕馭層形式化為一個執行期基底，列出十一項職責和四級階梯。
- 2026 年 6 月會學習的駕馭層。6 月 1 日的 Harness-1：一個兩百億參數的搜尋代理，在一套把簿記工作留在模型之外的駕馭層裡以強化學習訓練。6 月 8 日的 Self-Harness：代理從自己的失敗中找出弱點、改寫自己的駕馭層，測試的九組模型與基準組合全部進步，相對增幅最高 132%。6 月 17 日 Databricks 寫道：提示工程與情境工程「都住在駕馭工程裡面」。
- 2026 年 7 月棘輪自動化了，這個領域也被盤點。7 月 13 日的〈幻影護欄〉：一個自動改寫駕馭層的程式，只看合規的執行紀錄，當輸入長得像某條熟悉的規則時，60 次裡有 15 次替從未發生的失敗加上護欄；沒有這種模式時是 60 次裡 0 次。7 月 15 日一項針對十一套正式上線的編碼駕馭層的原始碼研究發現，沒有一套引用通用的代理框架。
- 2026 年 9 月百科全書，以及元件研究。維基百科「代理駕馭層」條目 9 月 12 日的版本，仍說歸屬在 Hashimoto 與 Trivedy 之間有爭議，也仍把 Anthropic 2025 年 11 月的文章標成 2026 年。9 月 17 日一項涵蓋 176 組對照設定的研究發現，駕馭層元件值多少要看模型：規劃能提高較弱模型的正確率，對較強模型則主要是省錢。
論點
誰命名的，以及仍然未決的那個分歧 歸屬問題，日期答得比歸屬本身還多。邊界問題則沒有任何答案。
先說沒有爭議的部分。自 2026 年 3 月 10 日起，意思就沒再動過：百科條目、Databricks、Osmani 和各篇研究論文，都是在改寫 Trivedy 的定義。三份各自整理的元件清單——Databricks 的八個構件、Zhong 與 Zhu 的十一項職責、一份整理清單的十二個設計基元——切的是同一樣東西，只是粗細不同，彼此沒有矛盾。
誰命名的？日期說得比歸屬還多。Dex Horthy 在 2025 年 11 月 4 日寫下他會把一種新做法稱為「駕馭工程」。Mitchell Hashimoto 在 2026 年 2 月 5 日用了這個詞，並說他不知道有公認名稱。OpenAI 在 2 月 11 日把它當標題。Trivedy 在 2 月 17 日用了它，3 月 10 日定義了它。歸屬全都更晚：3 月 12 日，Horthy 共同創辦的 HumanLayer 說「由 Viv 創造」；4 月 19 日 Osmani 也這麼說；維基百科則說爭議在 Hashimoto 與 Trivedy 之間。三者都沒提到 Horthy 的貼文。找到的最早用法不等於第一次使用，本頁也不宣稱誰創造了這個詞。日期能說明的是：這場爭論圍繞的兩個名字，都不是最早用這個詞的人，而且兩人被歸功的是不同的事——Hashimoto 是替一種小做法取了名字，Trivedy 是替一種大做法下了定義。
有爭議的是邊界。Databricks 說：提示工程與情境工程「都住在駕馭工程裡面」。維基百科說：駕馭層「把另外兩者當成組成部分包在裡面」。另一邊有五則說法。Horthy 第一次使用時，就把駕馭工程定義為把情境工程的原則用在既有代理上。Trivedy 2 月寫道，駕馭工程有一部分是打造「情境工程的良好傳遞機制」，3 月又寫道，如今的駕馭層「大體上就是良好情境工程的傳遞機制」。HumanLayer 稱它為「情境工程的一個子集」。Böckeler 說：替編碼代理打造使用者駕馭層，是「情境工程的一種特定形式」——而維基百科那句「包含」引用的正是她。以下只是一種解讀：「子集」這一邊是這個詞最初的意思，「容器」這一邊則是隨著三月那次擴張而來。沒有任何來源調和這兩者，本頁也不替一個沒人發表過的共識背書。
文獻的軌跡還很新，而且會出錯。維基百科替 Anthropic 那篇長時間駕馭層文章標的年份是 2026；文章的日期是 2025 年 11 月 26 日，在 Horthy 用這個詞的三週後，早於目前找到的其他所有用法。那個日期正是這篇文章重要的原因，而這則引用把它弄丟了。
- 93天，是目前找到最早的用法，與百科全書列在最前面的那次用法之間的距離
- 1次，是 harness 一詞在 OpenAI 那篇以〈駕馭工程〉為題的文章內文中出現的次數——在「評測駕馭框架」裡
- 5 : 2則見諸文字的說法把駕馭工程放在情境工程之內，對上把情境工程放在駕馭工程之內的說法
補充
實際上要做的是什麼 Böckeler 給了架構；Anthropic 和 OpenAI 給了實作範例。
- 1在代理前面放引導前饋控制：指示檔、技能、啟動腳本、程式碼轉寫。它們在代理動手前先引導。Böckeler 的提醒是：只有這些的駕馭層，寫進了規則，卻永遠不知道規則有沒有效。
- 2在後面放感測回饋控制：測試、程式碼檢查器、型別檢查器、一個審查代理。感測器應該為它的讀者而寫——用 Böckeler 的話說，一則告訴模型該怎麼修的檢查訊息，是一種正面的提示注入。OpenAI 也這樣做：自訂的檢查規則，錯誤訊息裡就附上解法。只有感測的駕馭層，會一再重犯同樣的錯。
- 3搞清楚每個控制屬於哪一種計算式控制是確定且快速的——測試、程式碼檢查、結構分析，毫秒到秒級，結果可靠。推論式控制是語意層面的——AI 審查、「以大型語言模型當裁判」——較慢、較貴，結果也不確定。便宜的計算式感測可以每次變更都跑；推論式的得證明自己值得。
- 4把狀態寫在模型吃不掉的地方Anthropic 的實作範例：一份 200 多項端到端描述的功能清單，一開始全部標為失敗，代理只能透過改
passes欄位來更動它——用 JSON 而不用 Markdown，因為模型比較不會改寫 JSON——再加上一份進度檔，以及每次工作結束時的一次提交。OpenAI 把AGENTS.md控制在大約 100 行，當成通往docs/目錄的目錄頁。 - 5把每個錯誤轉成規則——用人手Hashimoto 的規則：代理犯錯，就設計一個修正，讓它不再犯。Osmani 補上煞車：只有看到真正的失敗，才加約束。一旦自動化，煞車會打滑——一個只看合規執行紀錄的自動駕馭層編輯器，在 60 次試驗裡有 15 次憑空捏造失敗，並替它加上護欄。
這些到底有沒有用？把證據分級 三項固定模型後量測。一項是論證。一項連模型也換了。
| 主張 | 怎麼測的 | 值多少 |
|---|---|---|
| Terminal Bench 2.0 | 在 89 道題上從 52.8% 到 66.5%，進步 13.7 分，固定 gpt-5.2-codex，只改提示、工具和中介層 | 實驗形狀是對的。這是 LangChain 對自家代理的自述，而 LangChain 賣的正是駕馭層函式庫。光是推理預算也有影響：最高檔 53.9%，低一檔反而 63.6%，原因是逾時 |
| Self-Harness | 三個不同家族的模型、三個基準；代理改寫自己的駕馭層，改動要通過回歸測試才保留 | 九組組合全部進步，相對增幅最高 132%。模型固定；預印本，只讀了摘要 |
| 176 組對照設定 | 迴圈固定，改變規劃、工具與情境管理，四個模型，兩個程式基準 | 元件值多少，看是哪個模型。規劃能提高較弱模型的正確率，對較強模型則主要是省錢；擅長 bash 的模型只給 bash 也做得一樣好，還更便宜。預印本，只讀了摘要 |
| 駕馭層對上模型 | 一篇立場論文：形式化、已發表的結果，以及一次變異數分解 | 主張駕馭層造成的變異可以超過模型造成的變異，甚至讓模型排名反轉。是論證，不是新的量測；只讀了摘要 |
| OfficeQA Pro | 搭配駕馭層的 GPT-5.5 得 52.63%，「高於 GPT-5.4 的 36.10%」 | 沒有把駕馭層分離出來——模型在同一步也換了。而且「錯誤減少將近一半」推不出來：63.90% 降到 47.37%，大約是四分之一 |
固定模型的比較才是重要的，值得把原因講清楚。這裡幾乎每個來源都宣稱駕馭層和模型一樣重要甚至更重要，其中多數都在賣東西。固定模型、只改駕馭層的比較不是一種宣稱——它是這個主張所需要的實驗。LangChain 的是自述；Self-Harness 和元件研究是只讀了摘要的預印本。合起來，它們支持的主張比倡議者說的窄：駕馭層會讓分數變動，而某個元件值多少，要看裡面裝的是哪個模型。Databricks 那個同時換了模型和駕馭層的數字，連這一點都證明不了。
這個領域也有反駁自己的聲音，而這些反駁比它的倡議更有分量。定義這門學問的 Trivedy 寫道，隨著模型在規劃、自我驗證和長任務上變強，目前由駕馭層做的工作會移進模型裡——「駕馭層應該會隨時間變得不那麼重要」。他點出第二個問題：編碼代理是在駕馭層參與的情況下做後訓練的，所以模型在自己受訓時的駕馭層裡最能幹，改掉某個工具的邏輯就可能讓它變差。他稱之為過度擬合。Anthropic 的 Rajasekaran 把維護的一面說得很直白：每個元件都寫進了一個「模型做不到什麼」的假設，而這些假設會過時——所以駕馭層除了加東西，也得減東西。
最新的研究再補兩個提醒。一項針對十一套正式上線的編碼駕馭層的研究發現，沒有一套引用通用的代理框架：不管框架廠商賣什麼，這個領域跑的是手寫的迴圈。而 Hashimoto 那條規則的核心——每個錯誤都變成一條永久規則——一旦交給機器執行，就有它自己的失敗方式。只給合規的執行紀錄，一個自動駕馭層編輯器也會捏造失敗、替它們加上護欄；在一個只加不減的迴圈裡，幻影護欄一旦加進去，就留下來了。
- 13.7分，是固定 gpt-5.2-codex 所得的進步——這是 LangChain 對自家代理公布的數字
- 15/60次試驗中，當輸入長得像某條熟悉的規則時，自動駕馭層編輯器替從未發生的失敗加上了護欄；不像時是 0/60
- 0/11：十一套正式上線的編碼駕馭層中，執行期引用通用代理框架的套數
結論
可以帶走的幾件事 五件事，依重要性排列。
一個詞改變大小的速度，可以比改變意思還快
這個詞兩度被用來指一件小事、而且是在使用者那一端：2025 年 11 月 Horthy 的整合點，2026 年 2 月 Hashimoto 的指示檔和腳本。3 月 10 日，Trivedy 把它套到模型以外的一切，此後寫下的定義都以他的為起點。沒有人反對這次擴張；它就這樣取代了先前的意思。
固定模型，否則什麼都沒量到
「駕馭層很重要」這個主張，如今有形狀正確的比較支撐——LangChain 自述的 13.7 分、Self-Harness 的九組全勝、一項 176 組設定的元件研究。它們也說出了倡議者沒說的事：同一個元件，對某個模型有幫助，對另一個模型只是省錢。像 Databricks 那種同時換了模型和駕馭層的數字，兩者都證明不了。
找到的最早不等於第一個，歸屬也是兩個問題
文獻在 Hashimoto 和 Trivedy 之間爭論。目前找到最早的用法是 Horthy 的，比 Hashimoto 早 93 天，而沒有一種歸屬提到它。何況常被提起的那兩個名字，回答的本來就是不同的問題：誰替一個小習慣取了名字，誰定義了它如今所指的那件大事。
先問對方指的是哪一種包含關係
定義已經定了，邊界還沒有。Databricks 和維基百科把提示工程與情境工程放在駕馭工程裡面。Horthy、Trivedy 本人、HumanLayer 和 Böckeler 則把駕馭工程放在情境工程裡面，或稱它為情境工程的傳遞機制。兩種讀法都見諸文字，都沒被調和，而一句關於範圍的話，在兩種讀法下意思不同。
每一條規則，都是有保存期限的假設
棘輪為每個錯誤加一條規則。Anthropic 的建議是另一半：每個元件都寫進了一個「模型做不到什麼」的假設，等模型做得到時就該拿掉。Trivedy 預期駕馭層會隨時間變得不那麼重要。而自動化的棘輪已經被發現會替從未發生的失敗加規則。只會變大的駕馭層，並不是在被工程化。
無法查證的部分
「傳言」——在 Terminal Bench 2.0 上，Claude Code 裡的 Opus 4.6 排名約第 33，換到另一套駕馭層約第 5，上下約差四名。排名出自 HumanLayer，轉述的是 Trivedy，而 Trivedy 只說「遠低於」。排行榜已不再列出 Opus 4.6，也找不到其他關於這些排名的說法。
核心要點與來源
- Yao 等，〈ReAct〉，arXiv（2022 年 10 月 6 日）
- Schick 等，〈Toolformer〉，arXiv（2023 年 2 月 9 日）
- Erik S. 與 Barry Zhang，Anthropic（2024 年 12 月 19 日）
- Vivek Trivedy，vtrivedy.com（2025 年 9 月 23 日）
- Dex Horthy 於 X（2025 年 11 月 4 日）
- Justin Young，Anthropic（2025 年 11 月 26 日）
- Michael Bolin，OpenAI（2026 年 1 月 23 日）
- Celia Chen，OpenAI（2026 年 2 月 4 日）
- Mitchell Hashimoto，mitchellh.com（2026 年 2 月 5 日）
- Ryan Lopopolo，OpenAI（2026 年 2 月 11 日）
- Vivek Trivedy 於 X（2026 年 2 月 17 日）
- Vivek Trivedy，LangChain（2026 年 3 月 10 日）
- HumanLayer（2026 年 3 月 12 日）
- Prithvi Rajasekaran，Anthropic（2026 年 3 月 24 日）
- Birgitta Böckeler，martinfowler.com（2026 年 4 月 2 日）
- Addy Osmani，AddyOsmani.com（2026 年 4 月 19 日；O'Reilly Radar，2026 年 5 月 15 日）
- Zhang 等，arXiv（2026 年 5 月 7 日）
- Hailin Zhong 與 Shengxin Zhu，arXiv（2026 年 5 月 13 日）
- Jiang 等，〈Harness-1〉，arXiv（2026 年 6 月 1 日）
- Zhang 等，〈Self-Harness〉，arXiv（2026 年 6 月 8 日）
- Databricks（2026 年 6 月 17 日）
- Wang 等，〈Phantom Guardrails〉，arXiv（2026 年 7 月 13 日）
- Barbaste 等，arXiv（2026 年 7 月 15 日）
- ai-boost，awesome-harness-engineering，GitHub
- 〈Agent harness〉，維基百科（2026 年 9 月 12 日版本）
- Fan 等，arXiv（2026 年 9 月 17 日）。皆於 2026 年 9 月 28 日讀取。本詞是常設主題〈LLM 工程〉涵蓋的五個名詞之一，該頁把它與另外四個並排。