提示詞工程、上下文工程都過時了，現(xiàn)在是 Harness Engineering 的時代

Prompt Engineering 過時了，Context Engineering 也過時了。

2026 年開年，開發(fā)者社區(qū)最熱的關(guān)鍵詞叫 Harness Engineering。

2 月 5 日，HashiCorp 聯(lián)合創(chuàng)始人 Mitchell Hashimoto 在博客發(fā)文，把 AI 輔助開發(fā)中一種正在被越來越多頂尖團隊采用的工程實踐正式命了名——Harness Engineering。六天后，OpenAI 發(fā)布了一份詳細的內(nèi)部實驗報告，標題直接用了這個詞。再之后，知名工程師 Martin Fowler 在 Twitter 上為 Thoughtworks 工程師對這份報告的深度分析站臺。

一個月之內(nèi)，Harness Engineering 從一篇博客文章變成了開發(fā)者社區(qū)的高頻詞。

一個新的共識正在形成：在 AI Agent 編碼領域，決定結(jié)果好壞的最大變量，往往不是模型有多聰明，而是模型被放在了一個什么樣的環(huán)境里。

LangChain 的編碼 Agent 在 Terminal Bench 2.0 基準測試上，通過僅優(yōu)化 Agent 運行的外部環(huán)境（文檔結(jié)構(gòu)、驗證回路、追蹤系統(tǒng)），排名從全球第 30 位躍升至第 5 位，得分從 52.8% 飆到 66.5%。底層模型一個參數(shù)都沒改。安全研究員 Can Boluk 僅僅改變了 Agent 的代碼編輯格式，Grok Code Fast 1 的基準得分就從 6.7% 躍升至 68.3%。

而 OpenAI 的那份報告，則記錄了另一個更直觀的工程事實：5 名工程師，五個月，零行手寫代碼，通過 Codex Agent 協(xié)作交付了超過 100 萬行代碼的生產(chǎn)級軟件產(chǎn)品。

模型能力的競賽仍在繼續(xù)，但真正在一線決定 Agent 工程產(chǎn)出質(zhì)量的杠桿，已經(jīng)轉(zhuǎn)移到了「環(huán)境」一側(cè)。

這個「環(huán)境」，就是 Harness。

??關(guān)注 Founder Park，最及時最干貨的創(chuàng)業(yè)分享

超 22000 人的「AI 產(chǎn)品市集」社群！不錯過每一款有價值的 AI 應用。

邀請從業(yè)者、開發(fā)人員和創(chuàng)業(yè)者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關(guān)注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準的 AI 產(chǎn)品曝光渠道

01從 Prompt、Context 到 Harness，業(yè)界的認知在逐漸升級

Harness Engineering 不是憑空冒出來的概念。從 Prompt 到 Context，每個概念都對應著開發(fā)者社區(qū)對「如何讓 AI 可靠工作」這個問題的一次認知升級。

2023 年：Prompt Engineering

這是 Prompt Engineering 的全盛期，寫好一條提示詞就能讓 AI 交付結(jié)果。Few-shot prompting、Chain-of-Thought、角色扮演，開發(fā)者社區(qū)圍繞這些技巧產(chǎn)出了大量教程和最佳實踐。但當 AI 從 chatbot 進化為需要處理復雜任務的 Agent 時，單條指令的局限性暴露無遺。LLM 領域最活躍的技術(shù)博主 Simon Willison 后來一句話總結(jié)了這個階段的問題：「prompt engineering 的社會推斷含義已經(jīng)偏離了本意。大多數(shù)人聽到 prompt engineering，想到的就是對著 ChatGPT 打字。」

2025 年中：Context Engineering

2025 年 6 月，OpenAI 聯(lián)合創(chuàng)始人 Andrej Karpathy 發(fā)帖：

「+1 for 'context engineering' over 'prompt engineering'...... 這是一門精微的藝術(shù)與科學，用恰到好處的信息填充上下文窗口，以服務于下一步操作。」

Shopify CEO Tobi Lutke 緊隨其后，發(fā)布了一條獲得 190 萬瀏覽量的帖子：

「我真的很喜歡 context engineering 這個詞。它更好地描述了核心技能：為任務提供讓 LLM 有可能解決它的全部上下文的藝術(shù)。」

Simon Willison 在博客上做了總結(jié)：

「我認為 context engineering 會留下來。跟 prompt engineering 不同，它的推斷定義跟本意高度吻合。」

Context Engineering 的核心轉(zhuǎn)變在于：焦點從「寫好一條指令」擴展到了「設計一個動態(tài)系統(tǒng)來組裝上下文」。RAG、對話歷史、工具輸出、系統(tǒng)指令的編排，都成了工程師需要操心的事。

但 2025 年下半年，一線實踐者開始發(fā)現(xiàn)：光有好的上下文，Agent 依然會失控。

2026 年 2 月：Harness Engineering

技術(shù)播客 Vanishing Gradients 的一集節(jié)目標題直接點破了這個矛盾：「Why Agent Context Isn't Enough」（為何僅有 Agent 上下文依然不夠）。節(jié)目揭示了一個關(guān)鍵悖論：上下文窗口的擴大，并不等于 Agent 性能的線性提升。即便模型理論上支持 100 萬 Token 的上下文，性能衰減在 25.6 萬 Token 左右便已出現(xiàn)。播客還記錄了一起造成 5 萬美元損失的事故：一個無人監(jiān)控的 Agent 陷入無限循環(huán)，API 賬單累積到被人發(fā)現(xiàn)時已經(jīng)來不及了。

上下文可以告訴 Agent「知道什么」，但無法阻止 Agent「做不該做的事」。

Mitchell Hashimoto 在 2 月 5 日的博文中為這塊缺失的拼圖命了名：Engineer the Harness（工程化線束）。他的定義很簡潔：

「每當你發(fā)現(xiàn) Agent 犯了一個錯誤，你就花時間設計一個解決方案，使 Agent 永遠不再犯同樣的錯誤。」

六天后 OpenAI 官方的報告發(fā)布，業(yè)界的討論也逐漸熱了起來。

回過頭看，三個階段的關(guān)系用一句話就能說清：Prompt Engineering 管的是「說什么」，Context Engineering 管的是「知道什么」，Harness Engineering 管的是「在什么環(huán)境里做事」。

02OpenAI 實驗全解讀：不要把東西都塞進 AGENTS.md

OpenAI 的這份報告是理解 Harness Engineering 的核心文本。里面的工程細節(jié)值得展開。

實驗設定

團隊從 3 名工程師起步，最終擴展至 7 名。五個月內(nèi)構(gòu)建并交付了一個內(nèi)部測試版軟件產(chǎn)品，已有外部 Alpha 測試用戶。代碼庫覆蓋應用邏輯、基礎設施、工具鏈、文檔和內(nèi)部開發(fā)工具，全部由 Codex Agent 生成，無一行人類手動編寫。

OpenAI 團隊明確聲明這是一個「刻意設定的極端約束實驗」（forcing function）。他們寫道，設定「零人類代碼」這條規(guī)則的目的，是倒逼團隊去構(gòu)建能讓 Agent 大規(guī)模可靠工作的工程基礎設施。換句話說，這個約束本身就是為了催生 Harness。

效率數(shù)據(jù)也很突出：平均每名工程師每日 3.5 個 Pull Request 的合并吞吐量。代碼審查通過 Agent 對 Agent 的循環(huán)實現(xiàn)了大規(guī)模自動化，人工監(jiān)督僅保留在高層架構(gòu)決策環(huán)節(jié)。

報告作者 Ryan Lopopolo 寫了一句后來被反復引用的話：

「我們目前最困難的挑戰(zhàn)，集中在設計環(huán)境、反饋回路和控制系統(tǒng)上。」

報告中實操價值最高的部分，是團隊在文檔工程上的試錯過程。

早期，團隊犯了一個經(jīng)典錯誤：把所有信息塞進一個龐大的 AGENTS.md 文件。系統(tǒng)說明、架構(gòu)規(guī)范、代碼風格、邊界條件...... 全部堆在同一份文檔里。結(jié)果 Agent 被信息淹沒，性能反而下降。

他們最終演化出的方案是一個漸進式披露模型。AGENTS.md 被精簡為約 100 行的「目錄」角色，指向一個結(jié)構(gòu)化的 docs/ 目錄：

    SECURITY.md           ← 安全約束

Codex 的發(fā)現(xiàn)機制是逐級讀取：從全局配置 ~/.codex/AGENTS.md 到項目根目錄，再到子目錄，就近優(yōu)先。比如 services/payments/ 下可以放一份 AGENTS.override.md，用 make test-payments 覆蓋根目錄的 npm test 規(guī)則。大小上限默認 32 KiB。

這套目錄結(jié)構(gòu)背后的核心假設是：Agent 不需要在一開始就知道所有事情，它需要在正確的時機獲得正確粒度的信息。跟人類工程師入職的邏輯一樣——沒有人第一天就讀完公司所有文檔。

超越文檔：讓 Agent「看見」運行時

靜態(tài)文檔之外，OpenAI 團隊做了一件更激進的事：把可觀測性數(shù)據(jù)直接暴露給 Agent。

日志、指標、追蹤信息，通過本地可觀測性棧（每個工作樹獨立實例化）向 Codex Agent 開放。Agent 可以使用 LogQL 和 PromQL 查詢來驗證服務啟動時間和關(guān)鍵用戶旅程的性能指標。

更進一步，Agent 甚至可以通過 Chrome DevTools Protocol 操作瀏覽器：重現(xiàn) Bug、驗證修復、直接對 UI 行為進行推理。

這意味著 Agent 不再只是一個「寫代碼的工具」。它能看見代碼運行后發(fā)生了什么，并據(jù)此判斷自己寫的代碼到底對不對。

機械化的架構(gòu)圍欄

OpenAI 團隊定義了嚴格的分層架構(gòu)依賴流向：Types → Config → Repo → Service → Runtime → UI。任何違反依賴方向的代碼都會被機械化攔截。

攔截機制有兩種。一是確定性 Linter。有一個細節(jié)值得說：工程師花了數(shù)小時重寫 Linter 的錯誤輸出格式。目的只有一個，讓 Agent 能「讀懂」出了什么問題，并據(jù)此自動修復。Linter 輸出的受眾從人類變成了 AI——這件事本身就是 Harness Engineering 思維的典型體現(xiàn)。

二是基于 LLM 的審計 Agent，用于檢查那些難以用形式化規(guī)則捕捉的語義違規(guī)。

兩種機制組合，確保了 Agent 生成的代碼在架構(gòu)層面的長期一致性。團隊的思路是：每當 Agent 犯一個新類型的錯誤，就回頭加一條約束。日積月累，Harness 越來越健壯，Agent 能犯的錯越來越少。

這正是 Hashimoto 所說的：「讓 Agent 永遠不再犯同樣的錯誤。」

03B?ckeler 的解讀：Harness Engineering 的三級框架

OpenAI 的報告是一手的工程記錄，信息密度很高但組織偏松散。Thoughtworks 的 Distinguished Engineer、生成式 AI 交付專家 Birgitta B?ckeler 在 martinfowler.com 上發(fā)表的分析文章，把這些實踐提煉成了一個清晰的三維框架。

Martin Fowler 本人在 2 月 17 日的 Twitter 帖子中稱贊了這篇報告：

「Harness Engineering 是對 AI 使能軟件開發(fā)關(guān)鍵部分的有價值框架。Harness 包括上下文工程、架構(gòu)約束和垃圾回收。」

B?ckeler 將 Harness 的核心拆解為三個維度：

維度一：上下文工程（Context Engineering）

確保 Agent 在正確時機獲得正確信息。包括前面提到的漸進式文檔披露、動態(tài)可觀測性數(shù)據(jù)接入，以及 Agent 對瀏覽器行為的直接推理能力。B?ckeler 指出，這一維度與 2025 年中期流行的 Context Engineering 概念高度重合，但 Harness Engineering 將其納入了一個更完整的體系。

維度二：架構(gòu)約束（Architectural Constraints）

通過機械化手段強制執(zhí)行架構(gòu)邊界。包括確定性 Linter（輸出格式專為 Agent 設計）和 LLM 審計 Agent 的雙軌機制。B?ckeler 特別注意到，OpenAI 讓 Linter 的錯誤消息直接包含修復建議，這使得整個「違規(guī) → 檢測 → 修復」的循環(huán)可以在 Agent 內(nèi)部閉環(huán)完成，無需人工介入。

維度三：熵管理 / 垃圾回收（Entropy Management）

這是 B?ckeler 框架中我覺得最有意思的部分。她觀察到 OpenAI 團隊部署了專用的清理 Agent，定期掃描文檔漂移、模式違規(guī)和依賴問題。

為什么要單獨拎出來？因為 Harness 本身也是代碼和文檔，它們同樣會腐化。隨著代碼庫規(guī)模增長，規(guī)則文件可能變得冗長混亂，包含過時、矛盾或不再適用的指令。如果 Harness 自身腐化了，Agent 就會因為讀到混亂指令而輸出混亂代碼。熵管理要解決的就是這個問題：約束系統(tǒng)本身不能隨時間退化。

B?ckeler 把三者的關(guān)系概括得很清楚：上下文工程讓 Agent「知道該做什么」，架構(gòu)約束確保「只在邊界內(nèi)行事」，熵管理保障「整個系統(tǒng)不隨時間退化」。

她同時提了一個重要的補充：OpenAI 的報告主要關(guān)注代碼的內(nèi)部質(zhì)量和可維護性，但對功能性和行為驗證的覆蓋不足。能通過所有 Linter 和架構(gòu)測試的代碼，不等于做了用戶真正需要的事情。這個提醒很實在，也指出了接下來需要補上的一塊。

04Stripe、LangChain，行業(yè)有了更多實踐者

如果說 OpenAI 的實驗只是個案，說服力有限。如今 Harness Engineering 的邏輯正在多個頭部公司得到獨立驗證。

Stripe：工業(yè)級的線束基礎設施

Stripe 的 Minions 體系每周合并超過 1,300 個由 AI 完全編寫的 Pull Request，人類僅負責審查。

Minions 的基礎設施透露了 Harness Engineering 在大型組織中的實際形態(tài)：每個 Agent 任務在獨立的預熱 devbox 中運行，與 Stripe 工程師使用的機器完全相同，約 10 秒內(nèi)啟動，內(nèi)置 Stripe 代碼庫和服務，與生產(chǎn)系統(tǒng)及互聯(lián)網(wǎng)完全隔離。

工具訪問通過名為 Toolshed 的中心化 MCP 服務器實現(xiàn)，托管近 500 個工具，涵蓋內(nèi)部系統(tǒng)和外部 SaaS 平臺。Agent 與人類開發(fā)者享有完全一致的工具訪問權(quán)限。

Stripe 的架構(gòu)選擇也有意思：確定性節(jié)點與 Agent 節(jié)點混合的「藍圖」模式。可預測的步驟（推送到 Git、運行 Linter、觸發(fā) CI）全部交給確定性代碼處理，只在需要判斷或創(chuàng)造力的環(huán)節(jié)才調(diào)用 LLM。這種設計把 LLM 限制在「可控盒子」里，大幅提升了系統(tǒng)的可預測性。

LangChain：一個干凈的對照實驗

回到開頭的那組數(shù)據(jù)。LangChain 的編碼 Agent 在 Terminal Bench 2.0 上，通過僅優(yōu)化 Harness 而不修改底層模型，得分從 52.8% 提升至 66.5%，排名從第 30 躍升至第 5。

這個案例的價值在于變量控制做得很干凈：模型不變，Harness 變，結(jié)果劇變。在「環(huán)境比模型更重要」這個論點上，這可能是目前最直接的證據(jù)。

Anthropic 在內(nèi)部工程文檔中已經(jīng)將 Claude Code 定位為「靈活的 Agent 線束」。Harness 的概念正在被工具供應商內(nèi)化為產(chǎn)品設計思路。

MCP（模型控制協(xié)議）已在 Linux 基金會下的 Agentic AI 基金會治理，月 SDK 下載量超過 9,700 萬，獲 OpenAI、Google、Microsoft 和 AWS 采用。Stripe 的 Toolshed 就是一個 MCP 服務器。MCP 正在成為 Agent 工具訪問的通用標準，而 Harness 工程的工具層將大規(guī)模遷移到這個協(xié)議上。

LangChain 的 State of Agent Engineering 報告提供了一組行業(yè)全景數(shù)據(jù)：89% 的受訪者已為其 Agent 實施了可觀測性，但僅有 52% 實施了評估（Evals）。大多數(shù)團隊已經(jīng)能「看見」Agent 在做什么，但還沒有建立系統(tǒng)性的機制來判斷「做得對不對」。評估體系怎么規(guī)模化，大概是 Harness Engineering 接下來一年繞不開的課題。

05工程師的核心工作，正從寫代碼轉(zhuǎn)向設計環(huán)境

一件事：工程師的核心工作，正在從寫代碼轉(zhuǎn)向設計讓 Agent 可靠運行的環(huán)境。

OpenAI 實驗中的工程師，日常工作已經(jīng)變成了三件事：

第一，構(gòu)建文檔與上下文體系。維護 AGENTS.md 目錄、docs/ 下的架構(gòu)規(guī)范與設計文檔，編寫自定義 Linter（包括重寫 Linter 的錯誤消息格式，使其對 Agent 可讀且包含修復建議），建立可觀測性基礎設施使 Agent 能夠查詢運行時數(shù)據(jù)。

第二，以機器可處理的方式定義業(yè)務意圖。工程師需要把業(yè)務目標、質(zhì)量標準和邊界條件表達得足夠清晰和精確，使 Agent 能夠據(jù)此自主決策。這要求更強的系統(tǒng)性思維和抽象能力。

第三，構(gòu)建自動化的防呆驗證機制。合并門禁被最小化以避免瓶頸，系統(tǒng)轉(zhuǎn)而依賴強大的自動化守衛(wèi)。Stripe 的實踐表明，預推送鉤子和本地 Linter 在 5 秒內(nèi)解決常見問題，是減少無效 Agent 循環(huán)的關(guān)鍵。

The Pragmatic Engineer 的創(chuàng)始人 Gergely Orosz 在報道 OpenClaw 創(chuàng)始人 Peter Steinberger 的工作方式時，描述了一個很生動的場景：Steinberger 是「在腦中保存項目高層結(jié)構(gòu)的軟件架構(gòu)師」，在使用 Agent 時只討論架構(gòu)和重大決策，完全不涉及具體代碼實現(xiàn)。

越來越多人開始覺得，這就是 Harness Engineering 對工程師的要求：系統(tǒng)理解的深度，比寫代碼的速度重要得多。

在組織層面，變化也很大。OpenAI 的 3-7 人團隊完成了以前需要數(shù)十人規(guī)模的工程輸出。Stripe 讓單名工程師可以同時向多個 Agent 分配不同任務。團隊結(jié)構(gòu)正在向兩三人甚至單人團隊收斂，完整擁有從規(guī)劃到上線的功能全生命周期。「合理團隊規(guī)模」的底層計算邏輯正在被重寫。

B?ckeler 在這一點上提出了一個所有技術(shù)管理者都該想想的問題，她稱之為「學徒缺口」（Apprentice Gap）：如果初級開發(fā)者過早進入 Agent 驅(qū)動循環(huán)，未經(jīng)歷手動開發(fā)的鍛煉，他們可能缺乏未來構(gòu)建健壯 Harness 所需的深度系統(tǒng)直覺。她建議將「體驗工程」（Experience Engineering）視為下一個核心挑戰(zhàn)，設計保留手動開發(fā)直覺的學習路徑。

06開發(fā)者可以做什么？

Hashimoto 的六階段采用旅程是目前操作性最強的個人路線圖。他自己正處在第五階段。以下是從他的博文和實踐中提煉的行動建議：

起步：把同一個任務做兩遍。先自己手動完成，再讓 Agent 重新做一遍。Hashimoto 說自己「真的把工作做了兩遍」，目的是建立對 Agent 能力邊界的直覺。他總結(jié)了三個關(guān)鍵發(fā)現(xiàn)：把會話拆成獨立清晰的任務；把模糊需求拆成「規(guī)劃」和「執(zhí)行」兩個階段；給 Agent 自我驗證的方法。

養(yǎng)成習慣：每天下班前 30 分鐘啟動 Agent。Hashimoto 說這「給了我第二天早晨一個熱啟動」。三類任務特別適合這個時段：深度調(diào)研（Agent 掃描整個領域）、并行探索（多個 Agent 同時試驗模糊想法）、Issue 和 PR 分診。

關(guān)鍵躍遷：在你的項目里建一份 AGENTS.md。這不需要是一份完美的文檔。從最基本的內(nèi)容開始：項目的核心架構(gòu)說明、常見的 Agent 錯誤及應對方式、測試和 Lint 命令、Agent 絕對不能碰的部分。每次 Agent 犯錯，就回來補一條規(guī)則。日積月累，這份文檔就會長成你的 Harness。

Hashimoto 還分享了一條心態(tài)層面的建議：「關(guān)掉 Agent 的桌面通知...... 作為人類，我的職責是控制何時中斷 Agent，而非被它中斷。」

對技術(shù)負責人來說，最實際的建議是：選一個新項目做試點。OpenAI 和 Stripe 的成功案例都有一個共同前提，要么從零開始，要么在成熟的內(nèi)部基礎設施上運行。遺留代碼庫的改造是另一個量級的工程挑戰(zhàn)。此外，Evals（評估體系）是下一個必建能力。當前僅有 52% 的團隊部署了評估系統(tǒng)，這個差距就是你的機會窗口。

OpenAI 的報告發(fā)布至今只有一個月。Hashimoto 自己也說，他還處在六階段的第五階段。行業(yè)里絕大多數(shù)團隊還停留在前三個階段。

但方向已經(jīng)不可逆。

從 Prompt Engineering 到 Context Engineering 再到 Harness Engineering，三年間，開發(fā)者社區(qū)對「如何讓 AI 可靠地工作」這個問題的理解，已經(jīng)從「寫好一條指令」演進到了「構(gòu)建一整個運行環(huán)境」。

軟件工程團隊的核心競爭力，正在從「誰的工程師代碼寫得更好」轉(zhuǎn)向「誰的工程師能設計出更好的 Agent 運行環(huán)境」。

正如 Ryan Lopopolo 在 OpenAI 報告中寫的那句話：

「我們目前最困難的挑戰(zhàn)，集中在設計環(huán)境、反饋回路和控制系統(tǒng)上。」

轉(zhuǎn)載原創(chuàng)文章請?zhí)砑游⑿牛篺ounderparker