Prompt Engineering 過時(shí)了，Context Engineering 也過時(shí)了。

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

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

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

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

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

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

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

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

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

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

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

進(jìn)群后，你有機(jī)會(huì)得到：

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

• 不定期贈(zèng)送熱門新品的邀請碼、會(huì)員碼；
  

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

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

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

2023 年：Prompt Engineering

這是 Prompt Engineering 的全盛期，寫好一條提示詞就能讓 AI 交付結(jié)果。Few-shot prompting、Chain-of-Thought、角色扮演，開發(fā)者社區(qū)圍繞這些技巧產(chǎn)出了大量教程和最佳實(shí)踐。但當(dāng) AI 從 chatbot 進(jìn)化為需要處理復(fù)雜任務(wù)的 Agent 時(shí)，單條指令的局限性暴露無遺。LLM 領(lǐng)域最活躍的技術(shù)博主 Simon Willison 后來一句話總結(jié)了這個(gè)階段的問題：「prompt engineering 的社會(huì)推斷含義已經(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ù)與科學(xué)，用恰到好處的信息填充上下文窗口，以服務(wù)于下一步操作。」

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

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

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

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

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

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

2026 年 2 月：Harness Engineering

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

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

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

「每當(dāng)你發(fā)現(xiàn) Agent 犯了一個(gè)錯(cuò)誤，你就花時(shí)間設(shè)計(jì)一個(gè)解決方案，使 Agent 永遠(yuǎn)不再犯同樣的錯(cuò)誤。」

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

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

02OpenAI 實(shí)驗(yàn)全解讀：不要把東西都塞進(jìn) AGENTS.md

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

實(shí)驗(yàn)設(shè)定

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

OpenAI 團(tuán)隊(duì)明確聲明這是一個(gè)「刻意設(shè)定的極端約束實(shí)驗(yàn)」（forcing function）。他們寫道，設(shè)定「零人類代碼」這條規(guī)則的目的，是倒逼團(tuán)隊(duì)去構(gòu)建能讓 Agent 大規(guī)?？煽抗ぷ鞯墓こ袒A(chǔ)設(shè)施。換句話說，這個(gè)約束本身就是為了催生 Harness。

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

報(bào)告作者 Ryan Lopopolo 寫了一句后來被反復(fù)引用的話：

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

報(bào)告中實(shí)操價(jià)值最高的部分，是團(tuán)隊(duì)在文檔工程上的試錯(cuò)過程。

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

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

    SECURITY.md           ← 安全約束

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

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

超越文檔：讓 Agent「看見」運(yùn)行時(shí)

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

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

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

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

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

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

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

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

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

這正是 Hashimoto 所說的：「讓 Agent 永遠(yuǎn)不再犯同樣的錯(cuò)誤。」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果說 OpenAI 的實(shí)驗(yàn)只是個(gè)案，說服力有限。如今 Harness Engineering 的邏輯正在多個(gè)頭部公司得到獨(dú)立驗(yàn)證。

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

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

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

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

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

LangChain：一個(gè)干凈的對照實(shí)驗(yàn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

養(yǎng)成習(xí)慣：每天下班前 30 分鐘啟動(dòng) Agent。Hashimoto 說這「給了我第二天早晨一個(gè)熱啟動(dòng)」。三類任務(wù)特別適合這個(gè)時(shí)段：深度調(diào)研（Agent 掃描整個(gè)領(lǐng)域）、并行探索（多個(gè) Agent 同時(shí)試驗(yàn)?zāi)：敕ǎ?、Issue 和 PR 分診。

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

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

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

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

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

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

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

正如 Ryan Lopopolo 在 OpenAI 報(bào)告中寫的那句話：

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

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