提示詞卷完了，上下文也卷完了。現在卷的是"賽道"

OpenAI 剛公布了一個內部實驗：3 個工程師，5 個月，100 萬行代碼，零行手寫。

不是 Demo，不是概念驗證。是一個有真實用戶、能部署上線、會出 Bug 也能修復的生產級產品。

但讓我反復回去看了三遍的，不是這個數字。而是報告里一句不起眼的話：

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

不是模型不夠強，不是提示詞不夠精巧。是環境沒準備好。

這就是 2026 年最重要的工程范式轉移：Harness Engineering（線束工程）。

提示詞過時了，上下文也不夠用了

過去三年，行業對"怎么讓 AI 干好活"的理解，換了三次底層邏輯。

2023 年，所有人都在卷提示詞。 Few-shot、Chain-of-Thought、角色扮演，教程滿天飛。信念很樸素：問對問題，就能拿到好答案。

在聊天場景確實成立。但 AI 一旦從"回答問題"進化到"獨立干活"，光靠一條指令就不夠了。

2025 年中，焦點轉向上下文。 Karpathy 提了 Context Engineering，Shopify CEO 迅速認同。大家開始琢磨怎么動態組裝 RAG、對話歷史、工具輸出。

但下半年的實踐暴露了一個要命的悖論：即便模型支持 100 萬 Token，性能衰減在 25.6 萬左右就出現了。更嚇人的是，有人的 Agent 陷入無限循環，一次事故燒了 5 萬美元。

上下文可以告訴 Agent"知道什么"，但攔不住 Agent"做不該做的事"。

2026 年 2 月，Mitchell Hashimoto 給缺失的那塊拼圖命了名。

HashiCorp 聯合創始人，在博客里寫了一句話，我覺得簡潔到可以刻在墻上：

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

Prompt Engineering 管的是"說什么"，Context Engineering 管的是"知道什么"，Harness Engineering 管的是"在什么環境里做事"。

說白了，人類的角色從"直接干活的"變成了"設計賽道的"。你不再親手跑每一步，而是把圍欄、彎道、剎車全部提前造好，然后讓 Agent 自己跑。

OpenAI 那個實驗，到底發現了什么？

回到開頭那個實驗。

OpenAI 自己說得很明白：設定"零手寫代碼"不是為了炫技。這個約束本身就是目的。 是為了倒逼團隊去搞清楚一件事：Agent 要在什么樣的環境里，才能大規模可靠地工作？

瓶頸不在模型，在環境

初始團隊 3 人，最終 7 人。五個月交付百萬行生產級代碼，平均每人每天合并 3.5 個 PR。

但早期進展比預期慢。不是 Codex 能力不夠。是環境規范不夠。 Agent 缺少工具、缺少抽象、缺少結構。

大多數人第一反應是"模型還不夠強"。但真相恰好反過來：模型夠強了，環境沒跟上。

這一點做后端的人應該秒懂。你給一個再強的開發者，項目沒有 CI/CD，沒有代碼規范，沒有接口文檔，他一樣寫出一堆爛代碼。Agent 更甚，因為它連"憑經驗猜"的能力都沒有。

從此工程師的工作邏輯變了。 遇到 Bug 不是"換個提示詞再試一次"，而是問自己：缺少什么能力？怎么把這個能力做成 Agent 能理解、能執行的東西？

不加人，加"眼睛"

代碼產出量上去后，人類 QA 跟不上了。

團隊的做法讓我印象很深：沒有招更多測試，而是讓 Agent 自己"看見"運行時。

他們給 Codex 接上了 Chrome DevTools Protocol，Agent 可以直接啟動應用、截屏、操作 DOM、重現 Bug。再把日志、指標、鏈路追蹤全部暴露給 Agent，它可以直接用 LogQL 和 PromQL 查詢。

于是"確保服務啟動在 800ms 內"這種以前只有人才能判斷的事，Agent 也能執行了。

團隊經常看到 Codex 跑一個任務跑六個小時。通常是在人類睡覺的時候。

給地圖，別給百科全書

上下文管理這塊我看得最仔細，因為這跟我日常寫 AGENTS.md 的經驗直接相關。

OpenAI 學到的第一課：指令文件太長，Agent 反而表現更差。 一個巨大的說明文件會擠占真正重要的信息空間。當所有內容都"重要"時，什么都不重要了。

所以他們把 AGENTS.md 從百科全書變成了目錄。大約 100 行，只告訴 Agent"接下來去哪里找信息"，具體內容全在 docs/ 目錄下。

這叫漸進式披露。 先給入口，再按需深入。

更牛的是，他們連文檔維護都交給了 Agent。一個"文檔園丁"Agent 定期掃描過時內容，自動提 PR 修復。

架構圍欄：規矩越嚴，Agent 跑得越快

這個發現我一開始不太信。

團隊給應用搭了非常嚴格的架構：每個業務領域固定分層，依賴方向嚴格校驗，跨領域只能通過統一接口進入。全部通過自定義 Linter 強制執行，違反了就報錯，報錯信息里直接寫修復建議。

這種架構約束，一般大公司到幾百人的時候才會搞。但他們在三個人的時候就上了。因為 Agent 在有明確規則的環境里，跑得比"自由發揮"快得多。 規則對 Agent 來說就是導航，不是枷鎖。

集中控制邊界，局部允許自治。 這就像管理一個工程團隊：你管架構規范，不管他用 for 循環還是 stream。只不過這次你管的"團隊成員"是 Agent。

三件值得認真想的事

如果你也是一個天天跟代碼打交道的開發者，Harness Engineering 對你到底意味著什么？

第一，核心競爭力在轉移。

從"寫代碼的速度"到"理解系統的深度"。有人描述 OpenClaw 創始人用 Agent 的方式：只聊架構和重大決策，完全不碰具體實現。他腦子里裝著項目全貌，Agent 負責把想法變成代碼。

第二，今天就可以開始建自己的 Harness。

不用等什么最佳實踐。在你的項目里建一份 AGENTS.md，從最基本的內容寫起：核心架構說明、常見 Agent 錯誤、測試命令、Agent 不能碰的東西。

每次 Agent 犯錯，回來補一條規則。日積月累，這份文件就是你的 Harness。

第三，別讓初級開發者跳過"手寫代碼"這一關。

Thoughtworks 的 B?ckeler 提了一個尖銳的問題：如果新人一上來就用 Agent 寫所有代碼，從來沒經歷過手動開發的磨練，將來誰來建 Harness？

你得先知道代碼怎么寫、系統怎么崩、Bug 怎么藏，才知道賽道的護欄應該裝在哪。

2026 年最值得關注的技術辯論之一：Big Model vs Big Harness。

短期簡單任務，模型夠強就行。但長期復雜項目，沒有 Harness，再強的模型也會漂移、失控、腐化。

Hashimoto 那句話我越想越覺得精準：每當 Agent 犯錯，就設計一個方案讓它永遠不再犯。

這不就是工程的本質嗎？把經驗編碼成系統，讓錯誤只發生一次。

只不過這一次，你編碼的對象不是業務邏輯，而是 Agent 運行的整個世界。