事實
術語 · 來源查證 · LLM 工程 · 語言模型 · AI 人工智慧 · 名詞解析Tratopedia · 2026 年 8 月 15 日
五篇之三 · 最外面的那一層
為一個文字檔而生的詞，一個月後它指的是一切
2026 年 2 月 5 日，Mitchell Hashimoto 需要替一個習慣取個名字 —— 代理每犯一次錯，就去修它的環境 —— 找不到現成的說法，於是他叫它機具工程。他當時指的，是一個指示檔加上幾支腳本。三十三天後，Vivek Trivedy 把同一個詞掛到了模型以外的一切上：檔案系統、沙箱、編排層、掛鉤。今天百科條目採用的是後者。兩個人做的是兩件不同的貢獻 —— 一個給了名字，一個給了定義 —— 而文獻從此就一直在爭論究竟是誰創造了這個詞。與此同時，這套做法本身，早在兩人之前好幾個月就已經被完整發表過了。
命名，以及把它吞下去的那次重新定義 相隔三十三天。第二個之後的所有說法，都是它的改寫。
- 33從這個詞被造出來指一個習慣，到它指涉模型周圍的一切，相隔的天數
- 2兩項各自獨立的貢獻 —— 一個是名字，一個是定義 —— 被誤當成同一場歸屬之爭
- 1找到的比較裡，只有一個是固定模型、只更換機具的
- 0沒有任何一份資料調和剩下的那個分歧：它究竟包含情境工程，還是被情境工程包含
Mitchell Hashimoto · 2026 年 2 月 5 日
「我漸漸開始把這個叫做機具工程」
- 它的全部內容：只要你發現代理犯了錯，就花時間工程化地做出一個解法，讓它再也不會犯同一個錯。
- 它只有兩種形式，而那就是全部範圍：一個
AGENTS.md，檔案裡的每一行都來自一次代理的壞行為；以及「真正寫成程式的工具」—— 截圖與過濾測試用的腳本。沒有沙箱、沒有編排、沒有執行期基底。 - 他對命名這件事其實不情願：我並不需要在這裡發明新詞；如果已經有別的說法，我會跟上去。沒有人告訴他，五個星期後就會出現一個，並且把這個詞一起帶走。
Vivek Trivedy · LangChain · 2026 年 3 月 10 日
代理 = 模型 + 機具
- 他的註解：不是模型的，就是機具。模型本身以外的每一段程式碼、每一項設定、每一段執行邏輯 —— 檔案系統、沙箱、瀏覽器、編排、掛鉤。
- 他很小心地說明這是一種選擇，不是事實：要切開代理系統裡模型與機具的界線，有很多雜亂的方法……但我認為這是最乾淨的一種。
- 這之後的每一個定義都是它的改寫，沒有一個是 Hashimoto 那個版本的改寫。所有的漂移都發生在那三十三天裡。
維基百科 · 2026 年 8 月 13 日最後編輯
「環繞著模型的軟體基礎設施」
- 完整說法是：負責「工具使用、記憶、狀態保存、執行環境與回饋迴圈，相對於模型自身的推理」的那一層。
- 比它早一年多的情境工程，至今仍然沒有自己的條目 —— 它只是別的條目裡的一段。
- 它同時把自己引用的一份資料的日期弄錯了一年。見第三節。
Zhong 與 Zhu · arXiv · 2026 年 5 月 13 日
「一層執行期基底」
- 他們的開場是：主流解釋把這個落差歸因於模型能力。我們提出另一個位置。
- 十一項元件職責，以及一道四級階梯 H0 到 H3。其中三項 —— 失效歸因、熵稽核、介入記錄 —— 存在的目的不是讓這一次跑得起來，而是為了事後能評斷它。
- 本文只讀了摘要，因此本頁沒有引用這篇論文的任何實驗結果。
以上每一項有多確定？ 哪些讀到了、哪些仍然缺席，以及本頁第一版錯在哪裡。
| 確信程度 | 內容 | 依據 |
|---|---|---|
| 已讀原始出處 | 代理 = 模型 + 機具，以及「不是模型的，就是機具」 | Vivek Trivedy，LangChain，2026 年 3 月 10 日，讀取原始出處 |
| 已讀原始出處 | 在 Terminal Bench 2.0 上，Claude Code 裡的 Opus 4.6 分數遠低於其他機具裡的 Opus 4.6 | 同一篇。排行榜本身沒有讀，而且「遠低於」不是一個數字 |
| 由他人提供，非自行擷取 | 完整的做法 —— 初始化代理與編碼代理、兩百多項功能的 JSON、進度檔、init.sh —— 發表於 2025 年 11 月 26 日 | Anthropic，作者 Justin Young。PDF 由 djTratoh 提供；anthropic.com 對本次連線回傳 403 |
| 由他人提供，非自行擷取 | 2026 年 2 月 4 日，「Codex 機具」已被當成不需解釋的既定名詞使用 | OpenAI，Celia Chen。PDF 由 djTratoh 提供；openai.com 回傳 403 |
| 已讀原始出處 | 引導與感測；計算式與推論式；內層與外層機具 —— 以及「使用者機具就是情境工程的一種」 | Thoughtworks 的 Birgitta Böckeler，martinfowler.com，2026 年 4 月 2 日 |
| 由他人提供，非自行擷取 | Hashimoto 在 2026 年 2 月 5 日創造了這個詞，並說他不知道有任何已被接受的說法 —— 比現在大家使用的那個定義早 33 天 | 〈My AI Adoption Journey〉，mitchellh.com。PDF 由 djTratoh 提供。Osmani 直接把功勞歸給 Trivedy，在日期上是錯的 |
| 已更正 | 本頁先前說 Trivedy 那篇文章回傳 404，並據此下了結論。它從來沒有。 | 當時試的網址是本專案自己猜的，不是從任何資料抄來的。那篇文章一直都在 langchain.com/blog/… |
| 已更正 | 先前有兩句話被本頁歸給 Addy Osmani。「不是模型的，就是機具」是 Trivedy 的；棘輪那條規則是 Hashimoto 的 | Osmani 引用第一句時寫「Viv 的一句話」，第二句前面寫「大致是：」。他那篇是綜述，而本專案把它當成了原始出處 |
| 本頁的判讀 | 工作先於名字發表，名字又先於百科條目，全部發生在九個月之內 | 由各份有日期的文件拼出。沒有任何一份資料這樣說 |
時序
先有做法，再有名字，最後才有百科 從一套完整發表的方法到維基百科條目，九個月。
- 2022 年 10 月迴圈，先以論文形式出現。Yao 等人發表 ReAct，讓模型在推理與行動之間交替。此後每一套機具跑的都是這個循環：模型推理，機具執行並捕捉結果，模型再讀結果。
- 2023 年 2 月工具，也先以論文形式出現。Toolformer 顯示模型可以自行學會呼叫外部工具。維基百科把它與 ReAct 並列，視為早於這個名詞的機制。
- 2024 年 12 月想法已在，名字未到。Anthropic 主張，代理與電腦之間的介面值得投入的心力不應少於人與電腦之間的介面；工具的定義應該設計成讓模型不容易用錯。
- 2025 年 11 月 26 日整套做法，完整發表。Anthropic 的 Justin Young 寫下長時間執行代理的機具設計：一個初始化代理鋪好
init.sh、進度檔與第一個 commit；一個編碼代理每次工作階段只做一項功能，並且讓儲存庫保持乾淨。功能清單用 JSON 而不用 Markdown，因為模型比較不會去覆寫它。「機具」這個詞從頭到尾都以普通名詞出現。當時還沒有人替這門學問命名。 - 2026 年 1 月 23 日在第二個實驗室裡，這個名詞早已是平常話，而且不需要辯護。OpenAI 的 Michael Bolin 在說明 Codex 代理迴圈如何運作時，順手用了這個詞：希望這篇文章能讓你清楚看見，我們的代理（或者說「機具」）在運用 LLM 時扮演的角色。放在括號裡，當成同一件事兩個名字裡比較白話的那個 —— 比任何人替這門學問命名早了兩個星期。
- 2026 年 2 月 4 日而到了這時，連註解都省了。OpenAI 的 Celia Chen 寫道，網頁版、CLI、IDE 擴充套件與 macOS 應用程式「全都由同一套 Codex 機具驅動 —— 也就是支撐所有 Codex 體驗的代理迴圈與邏輯」。括號不見了。它就是那個東西的名字。
- 2026 年 2 月 5 日隔天，這個詞被造出來，而造它的人並不想造。Mitchell Hashimoto 在整理自己導入 AI 工具的過程時，寫到第五步 —— 把機具做好 —— 需要一個詞：我不確定業界目前有沒有廣為接受的說法，但我漸漸開始把這個叫做「機具工程」。他還補上：我並不需要在這裡發明新詞；如果已經有別的說法，我會跟上去。他當時指的，是一個
AGENTS.md加上幾支腳本 —— 檔案裡的每一行，都是他真的看過的某次代理壞行為換來的。 - 2026 年 3 月 10 日這個詞被接手，並且被撐大。LangChain 的 Vivek Trivedy 發表〈The Anatomy of an Agent Harness〉，定義出代理 = 模型 + 機具，並且從「想要的行為」倒推出每一個元件：檔案系統用來持有耐久狀態，bash 讓代理不必等人先造好工具就能自主，沙箱提供一個能安全動手的地方。距離命名三十三天，同樣一個詞現在涵蓋了模型以外的一切。後來每一份資料引用的都是這一篇，而且沒有人改動它的定義。
- 2026 年 4 月 2 日使用者這一側有了形狀。Thoughtworks 的 Birgitta Böckeler 把機具拆成兩半：在代理動作前引導它的引導，以及在它動作後觀察的感測，兩者各自可以是計算式或推論式。她也在一段側欄裡寫下了那句讓她與其他人分道揚鑣的話：使用者機具是情境工程的一種。
- 2026 年 5 月 13 日它成為一項研究綱領。Hailin Zhong 與 Shengxin Zhu 在 arXiv 貼出十六頁的形式化：十一項元件職責、一道從 H0 到 H3 的四級階梯，以及一項提議 —— 評斷一次代理執行，要看它留下的證據，而不是看有沒有生出一份修補。
- 2026 年 5 月 15 日這門手藝有了一句話的規則。Addy Osmani 在 O'Reilly Radar 上寫道：只要你發現代理犯了錯，就花時間工程化地做出一個解法，讓它再也不會犯同一個錯。他把命名歸給 Trivedy。
- 2026 年 6 月 17 日一家廠商畫下了邊界。Databricks 發表一篇說明，列出八個組成區塊、七種失效模式，並用一張表把三門學問排成階層：提示工程與情境工程都住在機具工程裡面。
- 2026 年 8 月 13 日百科全書跟上了 —— 距離命名五個月。維基百科〈Agent harness〉條目最後一次編輯，裡面有一節坦承沒有人確定是誰命名的，還有一條把 Anthropic 2025 年 11 月那篇文章標成 2026 年的引用。
論點
誰命名的，以及一個仍然未決的分歧 歸屬的問題有答案。邊界的問題沒有。
先講沒有爭議的部分，因為在本系列裡這很少見。Trivedy 三月的定義，被維基百科、Databricks、Awesome 清單與 Osmani 原封不動地沿用。三份各自獨立編成的元件清單 —— 八項、十一項、十二項 —— 差別只在切得多細，彼此之間沒有任何一處矛盾。在寫過兩個「同一個詞對不同人意思不同」的題目之後，這一個是穩的。
有爭議的是邊界。Databricks 講得很明白：提示工程與情境工程都住在機具工程裡面。機具是環繞模型的那套系統；提示與情境是這套系統的零件。維基百科同意，說機具工程「設計整個運作環境，並把另外兩者含納為其組成部分」。而 Böckeler 在一段標題正好就是這個問題的側欄裡，說了相反的話：為程式代理打造使用者機具，是情境工程的一種具體形式。同樣兩個詞，包含方向相反。
這不是其中一方沒注意到另一方。維基百科引用 Böckeler 六次 —— 她是該條目引用最多的來源 —— 卻仍然採用了她所反對的那種包含關係。有一個說得通的調和：她明講自己談的是程式代理，那裡的內層機具隨工具出廠，使用者唯一能自己搭的機具，實際上就是由指示檔與情境組成的。照這樣讀，兩邊講的是不同範圍，而且都對。但沒有任何一份資料這樣說，本頁也不會替沒有人發表過的共識代筆。
第二件值得講的，是這條紙本線索本身。維基百科替 Anthropic 那篇機具文章標的日期是 2026 年。文件上寫的是 2025 年 11 月 26 日。這不是小失誤：那篇文章之所以值得讀，關鍵就在於它早於命名，而一條把它放到 2026 年的引用，剛好抹掉了唯一重要的那件事。
本頁在同一個方向上犯了更嚴重的錯，而它被更正在上面，不是悄悄拿掉。第一版報導說 Trivedy 那篇文章 —— 這門學問的奠基文件 —— 回傳 404，並且據此下了一個結論：一門建立在「環境會腐壞、必須維護」之上的學問，已經先讓自己的紀錄腐壞了。這句話很好看，而且是假的。那個 404 的網址是本專案自己猜的，不是從任何資料抄來的；那篇文章一直都在原來的位置。對一個你自己拼出來的網址做測試，得到的是關於你那個猜測的結果，不是關於世界的結果。同樣的習慣 —— 先讀轉述、後讀原文 —— 也是為什麼 Trivedy 最有名的那句話，在這裡被歸給了引用他的人。
至於是誰命名，把兩篇都讀過之後，答案其實很清楚。維基百科說這件事有爭議，Osmani 則直接歸給 Trivedy；但 Hashimoto 那篇的日期是 2026 年 2 月 5 日，而且白紙黑字寫著：我不確定業界目前有沒有廣為接受的說法，但我漸漸開始把這個叫做「機具工程」。那就是命名，而且是不情願的命名 —— 他還補上一句：如果有現成的詞，他寧可跟著用。Trivedy 那篇是 3 月 10 日，晚了三十三天。
所以這兩個人做的是兩件不同的貢獻，而文獻把它們壓成了同一場歸屬之爭。Hashimoto 給了名字。Trivedy 給了定義 —— 而且是這樣的一個定義：一個原本為了「把指示檔顧好」而造的詞，如今涵蓋了檔案系統、沙箱、編排層與掛鉤。後來每一份資料用的都是 Trivedy 的意思。沒有一份用 Hashimoto 的；他的版本只以一個條目的身分，活在那個奪走了它名字的東西裡面。
補充
實際上要做的是什麼 Böckeler 給了架構；Anthropic 給了實作範例。
- 1在代理前面放引導前饋控制：指示檔、技能、程式碼轉寫、啟動腳本。它們預判你不想要的行為，在代理動手之前就先引導。只有前饋的機具，永遠不會知道自己的規則有沒有效。
- 2在它後面放感測回饋控制：測試、linter、型別檢查、審查代理。Böckeler 最銳利的一點是：感測器應該替它的讀者而寫 —— 一則告訴模型該怎麼修的 linter 訊息，是一種良性的提示注入。只有回饋的機具，會一直重犯同樣的錯。
- 3分清楚你用的是哪一種計算式控制是確定性的、快的 —— 測試、linter、結構分析，毫秒到秒級，結果可靠。推論式則是語意層面的 —— AI 審查、「LLM 當裁判」—— 較慢、較貴，而且不確定。便宜的計算式感測可以每次改動都跑；推論式的則必須證明自己值得。
- 4把狀態寫在模型不會吃掉的地方Anthropic 的實作範例，是本文找到最具體的建議：一份兩百多項、逐條寫成端到端描述的功能清單，一開始全部標為未通過，代理只能透過翻動
passes欄位來修改它。用 JSON 而不用 Markdown，是因為模型明顯比較不會去覆寫 JSON。再加上一個進度檔，以及每個工作階段結束時的一次 git commit。 - 5把每個錯誤棘輪成一條規則Hashimoto 的規則 —— 這個詞當初就是為這句話而造的，也是這個領域最接近方法論的東西：把錯誤當成永久訊號，而不是重跑一次就算了的壞運氣。每一個錯誤都值得換來指示檔裡的一行、pre-commit 掛鉤裡的一項檢查、審查代理裡的一個標記。只有在你真的看見一次失敗之後，才加上一條限制 —— 這能避免機具長出沒有人需要的規則。
這些到底有沒有用？把證據分級 其中兩項固定了模型。一項沒有。
| 主張 | 怎麼測的 | 值多少 |
|---|---|---|
| Terminal Bench 2.0 | Claude Code 裡的 Opus 4.6，分數遠低於其他機具裡的 Opus 4.6。同一個模型，不同機具 | 形狀是對的。被測的變因是唯一被改動的那一個，而且排行榜不屬於任何一方。由賣機具函式庫的 LangChain 報告 —— 但榜不是他們的，而「遠低於」也不是本頁能核對的數字 |
| 第 30 名 → 前 5 名 | LangChain 讓自家的程式代理在同一個排行榜上前進，「只改了機具」 | 形狀相同，但由自己報告。放在公開排行榜上，原則上是可查的 —— 這已經比這裡多數主張要好 |
| OfficeQA Pro | GPT-5.5 加上機具得 52.63%，「較 GPT-5.4 的 36.10% 提升」 | 沒有把機具單獨分離出來 —— 模型在同一步裡也換了。而且「錯誤幾乎減半」推不出來：63.90% 到 47.37%，大約是四分之一 |
第一列的那個比較才是重點，而且值得把理由講精確。本文每一份資料都主張機具和模型一樣重要、甚至更重要；其中多數在賣東西。利害關係人的斷言，是弱的證據。一個固定模型、只改機具的比較，根本就不是斷言 —— 它就是這個主張所需要的那個實驗，而 Terminal Bench 2.0 是公開的榜，不是內部的。報告它的一方同時在賣機具函式庫，並不會讓這個設計變錯；那只表示那個數字應該去榜上讀，而不是在部落格上讀，而本頁還沒有這樣做。
相比之下，Databricks 那個數字只是證據的形狀，不是證據。它在換機具的同一步裡把模型也升級了，因此沒有把兩者的貢獻分開 —— 而且它自己下的結論還高估了自己的數字。主張「機具很重要」主張得最用力的那家廠商，手上的量測反而是兩者中較弱的那個。
不過這批材料裡最有意思的，是一段反對這門學問的論證，而且出自替它下定義的人。Trivedy 的結尾直白地寫道：隨著模型在規劃、自我驗證與長時程連貫性上變強，現在由機具做的事會被吸收進模型裡 —— 「這意味著機具應該會隨時間變得沒那麼重要」。他認為這門學問還是會活下來，理由和提示工程當年一樣。但他把那句不好聽的話說出來了，而後續每一份沿用他定義的資料，都沒有跟著說。
他還點出一個熱潮通常會跳過的問題。現在的程式代理是連著機具一起做後訓練的，所以模型「在它被訓練的那套機具裡變得更有能力」 —— 而改動一個工具的邏輯，可能讓模型用得更差。他把這叫做過度擬合，這個判斷是對的：一個真正聰明的模型，在不同的修補方式之間切換應該不會有什麼困難。這也表示機具替你買到的東西，有一部分並不是普遍的能力，而是對某一次訓練的貼合。
結論
可以帶走的幾件事 五件事，依重要性排列。
一個詞改變大小的速度，可以比改變意思還快
Hashimoto 在 2026 年 2 月 5 日造出「機具工程」，指的是一個習慣加兩樣工具：一個指示檔，幾支腳本。Trivedy 在 3 月 10 日接手同一個詞，把它掛到模型以外的一切上。沒有人反對過哪一邊；後者就這樣取代了前者。提示工程的範圍收窄，情境工程的意思翻轉，而這一個是膨脹 —— 三個詞，三種「不再是原來意思」的方式。
一個比較，抵得過四句斷言
四份資料說機具和模型一樣重要；這四份都有東西要賣。有一個比較把同一個模型放進不同機具，在一個不屬於任何一方的排行榜上找到很大的落差。那個比較，才是這門學問值得認真看待的理由，而且它比那些斷言加起來還有份量 —— 包括那個在同一步裡換掉模型、然後又把自己算術講過頭的廠商跑分。
工作先來，而且早得很從容
Anthropic 在 2025 年 11 月 26 日就發表了一套完整的長時執行代理機具 —— 初始化代理、功能清單、進度檔、乾淨收尾的紀律 —— 比任何人替這門學問命名早了三個半月。OpenAI 在 2026 年 2 月 4 日已經把「Codex 機具」當成沒什麼好解釋的用語在寫。名字沒有創造這套做法；名字是後來才追上的。
先問對方指的是哪一種包含關係
定義已定，邊界未定。Databricks 與維基百科把提示工程與情境工程放進機具工程裡。而維基百科引用最多的 Böckeler 說，使用者機具是情境工程的一種。兩種讀法都已白紙黑字，沒有人調和過，而任何關於範圍的主張，在兩種讀法下意思都不一樣。
去讀原文，不要只讀轉述
本頁已更正四件事，其中三件出於同一個原因：一篇寫得不錯的綜述被放在它所綜述的文件之前讀，而它引用別人的話被當成了它自己的主張。結果是兩句話被歸錯了人，還有一項歸屬被照抄，而日期並不支持它。同時，維基百科把這個領域最重要的前身文件的日期弄錯了一年。以上每一項，都是「只要打開一份原始出處就會立刻發現」的那種錯。