•
OpenClaw創始人：Vibe Coding已經是貶義詞了！Meta軟體工程師爆料：矽谷Agentic Engineering五大支柱！要給Agent寫程式碼，而不是寫給人！
進入2026以來，許多 AI 圈的大神和大佬們都在提一個新概念：“agentic engineering”，智能體工程。
先是前 OpenAI 聯合創始人、大神 Karpathy 表示：Agentic Engineering 會是下一個階段。
然後 OpenClaw 的創始人 Peter Steinberger 在加入 OpenAI 之後的一次播客中則給出了更為激進的說法：現在提 Vibe Coding，已經是一個侮辱性詞語了。
那麼，大佬們為什麼會這樣說？智能體工程究竟都做那些呢？
近日，Meta資深工程師John Kim分享了內部的實踐做法。
John表示，agentic engineering和vibe coding完全不同，這兩個概念之間的差距，遠比想像中大。
有人給ChatGPT 或 Gemini 輸入一個提示詞，複製一段程式碼，部署在本地localhost 上，截圖發圈，說“我做了一個產品”。這種熱情值得鼓勵，但這不是工程。
但他並不是在否定這些嘗試。他表示，很多人嘗試用AI程式設計、探索新工具是非常棒的事情。但把“vibe coding”和“AI 程式設計”劃等號，其實是對整個行業的傷害。所有做AI程式設計的人都被歸為“vibe coding”，這並不是一個合理的做法。
“工程意味著系統設計、上下文管理、驗證閉環、工具建構，以及長期演進的能力。工程是可持續的，是可復用的，是可積累的。”
非常有“α含量”的是，John 還給出了 agentic engineering 的五大支柱：context engineering（上下文工程）、agentic validation（Agentic驗證）、agentic tooling（Agentic工具化）、agentic codebase（Agentic程式碼庫）、compound engineering（複合式工程）。
John 在介紹這五大支柱的同時，也爆料了許多前沿公司，如OpenAI、Anthropic、Google、Meta等頂尖工程師的“黃金做法”。
下面是更詳細的觀點整理，各位enjoy：
上下文工程才是王道！
“第二大腦”會成為重要的工程
真正決定Agent上限的，並不是模型參數規模，而是它所處的資訊環境。John表示，上下文是最關鍵的一點，輸入垃圾就會輸出垃圾。
John表示，在工作中經常會被問道這樣的問題：現在模型的上下文窗口非常大，直接把所有內容都喂進去不就好了？還需要最佳化嗎？”
在他看來，即使上下文窗口很大，也不意味著要堆砌資訊，而是精準篩選。因為模型的本質是基於統計機率生成輸出。它會根據你輸入的資料，計算某種機率分佈，生成一個最可能的輸出結果。因此，在做上下文工程時，你必須認真思考：到底需要給模型多少、什麼樣的上下文，才能讓它把事情做好。
此外，他還提出了“第二大腦（second brain）”的概念，即那些不直接屬於程式碼本身，但圍繞程式碼存在的領域資訊，比如產品資訊、產品規格、配置決策、領域規則等這些原本存在於工程師腦海裡的知識，應該存放在那裡，才能讓 AI 輕鬆獲取？
談到實現方式，以ClockCode 為例，他給出了聯眾解法：一是，可以在本地維護一個.cloud 檔案，把不適合直接寫進程式碼庫的內容放進去，二是，直接提交到程式碼倉庫中。
對於提交到程式碼倉庫這一方法，John提到OpenAI 做了一個實驗，並在一篇名為《Harness Engineering》的文章中提及，正在把越來越多的資訊推入程式碼庫，目的是給AI 提供更多上下文。他們實際上是在為 AI 最佳化程式碼庫，而不僅僅是按照人類開發者的習慣去組織程式碼。
John認為，“第二大腦”會成為一個重要的工程領域，它早在 RAG 系統中就已經出現，而現在它只是疊加在 agentic engineering 之上的又一層能力結構。
Agentic驗證：沒有驗證閉環，輸出只是機率猜測
當Agent開始承擔真實工程任務時，生成能力不再是瓶頸，驗證能力才是關鍵。John 明確提到，讓Agent能夠自我驗證，是讓其輸出質量顯著提升的關鍵因素之一。
他引用Boris Chen的實踐經驗強調，是否具備驗證機制，是“生成糟糕輸出”和“真正可用且經過驗證的結果”之間的巨大差異。
在John看來，驗證可以嵌入多個維度，比如，在後端任務中加入整合測試或單元測試；在前端任務中，讓Agent自己操作 Chrome 瀏覽器、截圖並進行自我驗證；在移動端場景下，甚至可以使用 ADB 來模擬互動，無論採用什麼驗證方式，這將是創造性工程大量湧現的地方。
此外，他特別指出，驗證極具挑戰尤其是UI驗證。比如，目前在沒有成熟視訊模型進入Agent解碼循環的情況下，我們如何確認介面互動的真實效果？”截圖是一種方法，但並不完美。領域特定語言（DSL）、模擬器控制邏輯、可觀測資料分析，都是可能的替代路徑。
再比如，在日誌層面，Agent在驗證過程中能“觀察”到那些可觀測資料？這些資料能否幫助它完成自我驗證？諸如，OpenAI 開始使用 LogQL，在驗證循環中記錄大量記錄檔，讓Agent在執行過程中攜帶日誌資料，從而判斷資料是否真實正確，而不是只依賴測試結果。
“沒有驗證循環，Agnet只是一次性推理工具；有驗證循環，Agent才具備自我修正與質量保證能力。”
Agentic工具化：凡是需要人手操作的地方，都是摩擦
當Agent執行流程頻繁被打斷時，問題通常不在模型，而在工具層。
John引用Peter Steinberger 的觀點，將這種阻礙稱為“摩擦”。他也發出了這樣的疑問：“什麼在阻礙Agent？Agent循環中有那些步驟必須由人類接手？”
如果每次遇到邊界條件都需要人工干預，那麼自動化永遠無法形成穩定結構。
反觀Agent技術越來越成熟，他也承認，有越來越多的公司開始建構Agentic工具，比如ChatGPT和Gemini引入搜尋功能、深度研究、多模態能力、任務系統等能力，這些本質上都可視為Agentic工具。
在John看來，OpenClaw是Agentic工具最成功的案例。他指出，OpenClaw成功的重要原因並非模型能力更強，而是建構了大量 CLI 工具，讓Agent能夠完成原本需要人工處理的任務。
“工具化的本質，是將一次性的人類操作轉化為可復用的自動能力。當Agent無法完成任務時，與其手動接管，不如建構一個工具。”
凡是需要登錄網站修改配置、手動觸發指令碼、重複執行命令的地方，都意味著潛在的工程機會。
Agentic程式碼庫：程式碼的結構，決定了Agent的理解深度
你的程式碼庫是否為AI Agent做過最佳化？
John給出的回答是：大多數老項目幾乎完全沒有為Agent做過最佳化。目前有多少是死程式碼或糟糕的設計模式？有多少相互競爭的框架共存於其中？
他強調道，清理程式碼庫、提升工程質量非常重要。因為每一次“糟糕的上下文”進入你的Agent循環，本質上都在污染Agent。Agent本質上是機率性的，如果你的程式碼中存在奇怪的、相互衝突的模式，就必須主動清除它們。
在John看來，OpenAI在這方面做的更好，OpenAI最佳化檔案結構時始終讓AI能夠穩定、持續地生成一致的內容。此外，他們還加入了面向Agent的日誌系統，讓Agent可以讀取日誌資料。建立的文件不僅服務於人類開發者，也服務於Agent，以便Agent能夠掌握領域知識。
“OpenAI將所謂的“黃金原則”直接編碼進程式碼倉庫。規則非常明確、風格高度統一，這種一致性是為未來的Agent而設計，而不僅僅是為未來的人類工程師。”John補充道。
“我們必須意識到，我們不再只是為下一位工程師寫程式碼，而是在為下一位Agent寫程式碼。”
複合式工程：當能力開始疊加
John表示，“複合式工程”的思維方式，是團隊成功的關鍵。”
何為複合式工程？John做了詳細的拆解：如果把‘上下文工程、Agentic驗證、Agentic工具化、Agentic程式碼庫最佳化’全部結合起來；如果把所有知識都放入程式碼庫，讓Agent能夠看到、共享；如果整個團隊都真正認同 agentic engineering 的理念，就會產生一種新的行為模式：隨著時間推移，不斷複利增長。
“簡言之，每當最佳化一個工作流、加入一個新技能；每當建構一個新的 MCP；每當把這些能力納入程式碼庫與共享庫中，這一切都會產生複利效應,這就是複合式工程。”
在五大支柱中，John把複合式工程放在了最後，原因在於這些理念必須被真正內化，並在團隊中傳播。同時,他也道出了目前大部分團隊存在的問題：每個人都有自己的工作流，每個人都在本地做最佳化，但團隊內部缺乏統一理念。
Jonh認為，未來的團隊應該向OpenAI團隊學習，因為他們集體認同這一理念，共同復合地積累知識、工具和工作流，讓Agent隨著時間推移越來越強大，能夠自我驗證、持續運行，甚至讓程式碼在很大程度上“自我建構”。 (51CTO技術堆疊)