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

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

2026 年開年，開發者社區最熱的關鍵詞叫 Harness Engineering。

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

一個月之內，Harness Engineering 從一篇博客文章變成了開發者社區的高頻詞。

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

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

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

模型能力的競賽仍在繼續，但真正在一線決定 Agent 工程產出質量的杠桿，已經轉移到了「環境」一側。

這個「環境」，就是 Harness。

??關注 Founder Park，最及時最干貨的創業分享

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

邀請從業者、開發人員和創業者，飛書掃碼加群：

進群后，你有機會得到：

• 最新、最值得關注的 AI 新品資訊；
  

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

• 最精準的 AI 產品曝光渠道

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

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

2023 年：Prompt Engineering

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

2025 年中：Context Engineering

2025 年 6 月，OpenAI 聯合創始人 Andrej Karpathy 發帖：

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

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

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

Simon Willison 在博客上做了總結：

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

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

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

2026 年 2 月：Harness Engineering

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

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

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

「每當你發現 Agent 犯了一個錯誤，你就花時間設計一個解決方案，使 Agent 永遠不再犯同樣的錯誤?！?/blockquote>

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

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

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

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

實驗設定

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

OpenAI 團隊明確聲明這是一個「刻意設定的極端約束實驗」（forcing function）。他們寫道，設定「零人類代碼」這條規則的目的，是倒逼團隊去構建能讓 Agent 大規?？煽抗ぷ鞯墓こ袒A設施。換句話說，這個約束本身就是為了催生 Harness。

效率數據也很突出：平均每名工程師每日 3.5 個 Pull Request 的合并吞吐量。代碼審查通過 Agent 對 Agent 的循環實現了大規模自動化，人工監督僅保留在高層架構決策環節。

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

「我們目前最困難的挑戰，集中在設計環境、反饋回路和控制系統上。」

踩過的坑：AGENTS.md 的進化

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

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

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

    SECURITY.md           ← 安全約束

Codex 的發現機制是逐級讀?。簭娜峙渲?~/.codex/AGENTS.md 到項目根目錄，再到子目錄，就近優先。比如 services/payments/ 下可以放一份 AGENTS.override.md，用 make test-payments 覆蓋根目錄的 npm test 規則。大小上限默認 32 KiB。

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

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

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

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

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

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

機械化的架構圍欄

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

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

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

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

這正是 Hashimoto 所說的：「讓 Agent 永遠不再犯同樣的錯誤?！?/p>

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

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

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

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

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

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

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

維度二：架構約束（Architectural Constraints）

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

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

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

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

B?ckeler 把三者的關系概括得很清楚：上下文工程讓 Agent「知道該做什么」，架構約束確?！钢辉谶吔鐑刃惺隆?，熵管理保障「整個系統不隨時間退化」。

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

04Stripe、LangChain，行業有了更多實踐者

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

Stripe：工業級的線束基礎設施

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

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

工具訪問通過名為 Toolshed 的中心化 MCP 服務器實現，托管近 500 個工具，涵蓋內部系統和外部 SaaS 平臺。Agent 與人類開發者享有完全一致的工具訪問權限。

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

LangChain：一個干凈的對照實驗

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

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

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

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

LangChain 的 State of Agent Engineering 報告提供了一組行業全景數據：89% 的受訪者已為其 Agent 實施了可觀測性，但僅有 52% 實施了評估（Evals）。大多數團隊已經能「看見」Agent 在做什么，但還沒有建立系統性的機制來判斷「做得對不對」。評估體系怎么規?；蟾攀?Harness Engineering 接下來一年繞不開的課題。

05工程師的核心工作，正從寫代碼轉向設計環境

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

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

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

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

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

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

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

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

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

06開發者可以做什么？

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

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

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

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

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

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

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

但方向已經不可逆。

從 Prompt Engineering 到 Context Engineering 再到 Harness Engineering，三年間，開發者社區對「如何讓 AI 可靠地工作」這個問題的理解，已經從「寫好一條指令」演進到了「構建一整個運行環境」。

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

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

「我們目前最困難的挑戰，集中在設計環境、反饋回路和控制系統上。」

轉載原創文章請添加微信：founderparker