智能體工程的 8 個等級

作者：Bassim Eledath

編譯：寶玉

AI 的程式設計能力正在超越我們駕馭它的能力。 這就是為什麼所有那些拼命刷 SWE-bench 分數的努力，並沒有與工程領導層真正關心的生產力指標同步。 Anthropic 團隊用 10 天就上線了 Cowork，而另一個團隊用著同樣的模型卻連一個 POC（概念驗證）都搞不定——區別在於一個團隊已經彌合了能力與實踐之間的差距，而另一個還沒有。

這個差距不會一夕之間消失，而是分等級逐步縮小。 總共 8 個等級。 讀到這篇文章的大多數人可能已經過了前幾個等級，而你應該迫不及待地想達到下一個——因為每升一級都意味著產出的巨大飛躍，而每次模型能力的提升都會進一步放大這些收益。

你應該在意的另一個原因是多人協作效應。 你的產出比你想像的更依賴隊友的等級。 假設你是 7 級高手，晚上睡覺時後台智能體就幫你提好幾個 PR。 但如果你的程式碼倉庫需要同事審批才能合併，而這位同事還停留在 2 級，仍在手動審查 PR，那你的吞吐量就被卡死了。 所以幫隊友升級，對自己也有利。

透過和許多團隊及個人交流他們使用 AI 輔助編程的實踐，以下是我觀察到的等級進階路徑（順序並不絕對嚴格）：

智能體工程的 8 個等級

第 1 和第 2 級：Tab 補體工程的 8 個等級

第 1 和第 2 級：Tab 補過全與智慧 可以隨意跳讀。

Tab 補全是一切的起點。 GitHub Copilot 拉開了這場運動的序幕－按一下 Tab 鍵，自動補全程式碼。 很多人可能早就忘了這個階段，新入行的人甚至可能直接跳過了。 它更適合有經驗的開發者，他們能先搭好程式碼骨架，然後讓 AI 來填滿細節。

以 Cursor 為代表的 AI 專用 IDE 改變了格局，它們將聊天與程式碼庫連接起來，讓跨檔案編輯變得輕鬆得多。 但天花板始終是上下文。 模型只能幫你處理它能看到的內容，而令人抓狂的是，它要么沒看到正確的上下文，要么看到了太多無關的上下文。

處於這個等級的大多數人也在嘗試所選編程智能體的計劃模式：把一個粗略的想法轉化為結構化的分步計劃給 LLM，反复迭代這個計劃，然後觸發執行。 在這個階段效果不錯，也是保持掌控的合理方式。 不過後面的等級我們會看到，對計畫模式的依賴會越來越少。

第 3 級：上下文工程

現在進入有意思的部分了。 情境工程（Context Engineering）是 2025 年的年度熱詞，它之所以成為一個概念，是因為模型終於可以可靠地遵循合理數量的指令，配合恰到好處的上下文。 吵雜的上下文和不充分的上下文一樣糟糕，所以核心工作在於提高每個 token 的資訊密度。 「每個 token 都要為自己在提示詞中的位置而戰」——這就是當時的信條。

同樣的訊息，較少的 token－資訊密度才是王道（資料來源：humanlayer/12-factor-agents）

在實務中，情境工程涉及的面比大多數人意識到的要廣。 它包括你的系統提示詞和規則文件（.cursorrules、CLAUDE.md）。 它包括你如何描述工具，因為模型讀取這些描述來決定要呼叫哪個工具。 它包括管理對話歷史，避免長時間運行的智能體在第十輪對話後迷失方向。 它還包括決定每輪暴露哪些工具，因為太多選項會讓模型不知所措——就像人一樣。

如今你已經不太聽到上下文工程這個說法了。 天平已經傾向於那些能容忍更吵雜的上下文、在更混亂的場景中依然能推理的模型（更大的上下文窗口也有幫助）。 但注意上下文的消耗仍然很重要。 以下幾個場景中它依然會成為瓶頸：

• 小模型對上下文更敏感。 語音應用通常使用較小的模型，而且上下文大小也與首 token 延遲相關，影響響應速度。
• Token 消耗大戶。 像 Playwright 這樣的 MCP（Model Context Protocol，模型上下文協定）和圖片輸入會快速吞噬 token，讓你在 Claude Code 中比預期更早進入「壓縮會話」狀態。
• 接入了幾十個工具的智能體， 模型花在解析工具定義上的 token 比做實際工作的還多。

更宏觀的重點是：上下文工程並沒有消失，只是在進化。 重心已經從過濾壞上下文轉向確保正確的上下文在正確的時間出現。 而正是這個轉變為第 4 級鋪平了道路。

第 4 級：複合工程

上下文工程改善的是目前這次會話。 複合工程（Compounding Engineering，由 Kieran Klaassen 提出）改善的是此後的每個會話。 這個理念對我和許多人來說都是一個轉捩點——它讓我們意識到「憑感覺編程」遠不只是做原型那麼簡單。

這是一個「計畫、委派、評估、沉澱」的循環。 你規劃任務，給 LLM 足夠的脈絡讓它成功。 你把任務委派出去。 你評估產出。 然後關鍵的一步──你把學到的東西沉澱下來：什麼有效、什麼出了問題、下次應該遵循什麼模式。

複合循環：計畫、委派、評估、沉澱－每一輪都讓下一輪更好

魔力就在「沉澱」這一步。 LLM 是無狀態的。 如果它昨天重新引入了一個你明確移除的依賴，明天它還會這麼做——除非你告訴它不要。 最常見的解決方法是更新你的 CLAUDE.md（或等效的規則檔案），把經驗教訓固化到每一次未來的會話中。 但要注意：什麼都往規則文件裡塞的衝動可能適得其反（指令太多等於沒有指令）。 更好的做法是創造一個環境，​​讓 LLM 能自己輕鬆發現有用的上下文－例如維護一個保持更新的 docs/ 資料夾（第 7 級會詳細講這個）。

實踐複合工程的人通常對餵給 LLM 的上下文高度敏感。 當 LLM 犯錯時，他們的本能反應是先想上下文是不是缺了什麼，而不是怪模型不行。 正是這種直覺，使得第 5 到第 8 級成為可能。

第 5 級：MCP 與技能

第 3 和第 4 級解決的是上下文問題。 第 5 級解決的是能力問題。 MCP 和自訂技能讓你的 LLM 能存取資料庫、API、CI 管線、設計系統，還有用於瀏覽器測試的 Playwright、用於通知的 Slack。 模型不再只是在思考你的程式碼庫——它現在可以直接操作了。

關於 MCP 和技能的優質資料已經不少，我就不贅述它們是什麼了。 但舉幾個我使用它們的例子：我們團隊共享一個 PR 審查技能，大家一起迭代改進（現在仍在改變），它會根據 PR 的性質有條件地啟動子智能體。 一個負責檢查與資料庫的整合安全性，一個做複雜度分析來標記冗餘或過度工程，另一個檢查提示詞健康度以確保提示詞遵循團隊標準格式。 它也運行 linter 和 Ruff。

為什麼在審查技能上投入這麼多？ 因為當智能體開始批量產出 PR 時，人工審查就成了瓶頸而非品質關卡。 Latent Space 提出了一個令人信服的論點：我們熟知的程式碼審查已經死了。 取而代之的是自動化的、一致的、技能驅動的審查。

在 MCP 方面，我使用 Braintrust MCP 讓 LLM 能查詢評估日誌並直接做出修改。 我使用 DeepWiki MCP 讓智能體可以存取任何開源倉庫的文檔，而無需手動把文檔拉入上下文。

當團隊中多個人開始各寫各的同類技能時，就值得整合成一個共享 registry 了。 Block（致以慰問）有一篇很好的文章：他們建立了一個內部技能市場，擁有超過 100 個技能，並為特定角色和團隊策劃了技能套餐。 技能和程式碼享有同等待遇：pull request、審查、版本歷史。

還有一個值得關注的趨勢：LLM 越來越多地使用 CLI 工具而不是 MCP（而且好像每家公司都在發布自己的：Google Workspace CLI，Braintrust 也即將推出一個）。 原因是 token 效率。 MCP 伺服器在每一輪都會把完整的工具定義注入上下文，不管智能體是否使用它們。 CLI 則反過來：智能體運行一個針對性的指令，只有相關的輸出才會進入上下文視窗。 我大量使用 agent-browser 而不是 Playwright MCP，正是因為這個原因。

在繼續之前暫停一下。 第 3 到第 5 級是後續一切的基石。 LLM 在某些事情上出奇地好，在另一些事情上又出奇地差，你需要培養出對這些邊界的直覺，然後才能在上面疊加更多自動化。 如果你的上下文是吵雜的、提示詞是不充分或不準確的、工具描述是含糊的，那麼第 6 到第 8 層只會放大這些問題。

第 6 級：Harness Engineering

火箭真正開始起飛了。

上下文工程關注的是模型看到什麼。 Harness Engineering（Harness Engineering）關注的是建立整個環境——工具、基礎設施和反饋循環——讓智慧體能在你不干預的情況下可靠地工作。 給智能體的不只是編輯器，而是完整的回饋循環。

OpenAI 的 Codex 工具鏈——一套完整的可觀測性系統，讓智能體可以查詢、關聯和推理自己的輸出（來源：OpenAI）

OpenAI 的 Codex 團隊把 Chrome DevTools、可觀測性螢幕工具 流程、查詢日誌、驗證自己的修復結果。 給一個提示詞，智能體就能復現 bug、錄影、實現修復。 然後它透過操控應用來驗證，提交 PR，回應審查回饋，合併——只在需要判斷時才上報人工。 智能體不只是寫程式碼，它能看到程式碼產生了什麼效果，然後迭代改進——就像人類一樣。

我的團隊做的是技術故障排查的語音和聊天智能體，所以我做了一個叫 converse 的 CLI 工具，讓任何 LLM 都可以與我們的後端接口聊天，進行逐輪對話。 LLM 修改程式碼後，用 converse 在線上系統測試對話，然後迭代。 有時這種自我改進循環會連續運作好幾個小時。 當結果可驗證時這尤其強大：對話必須遵循這個流程，或在特定情況下呼叫這些工具（例如轉人工客服）。

支撐這一切的核心概念是回壓機制（Backpressure）－自動化的回饋機制（類型系統、測試、linter、pre-commit 鉤子），讓智慧體能在不需要人工幹預的情況下發現並糾正錯誤。 如果你想要自主性，就必須有回壓機制，否則你得到的就是一台垃圾生產機。 這一點也延伸到安全領域。 Vercel 的 CTO 指出，智能體、它們產生的程式碼和你的金鑰應該處於不同的信任域中，因為埋在日誌檔案裡的一條提示詞注入攻擊就可能誘使智能體竊取你的憑證——如果所有東西共享同一個安全上下文的話。 安全邊界就是回壓機制：它們約束的是智能體失控時能做什麼，而不僅僅是應該做什麼。

兩個讓這個理念更清晰的原則：

• 為吞吐量而非完美設計。 當要求每次提交都完美時，智能體會在同一個 bug 上反覆糾纏，互相覆蓋對方的修復。 更好的做法是容忍小的非阻塞性錯誤，在發布前做一次最終的品質檢查。 對人類同事我們也是這麼做的。
• 約束優於指令。 一步步地提示（「先做 A，再做 B，然後做 C」）正在變得過時。 根據我的經驗，定義邊界比列清單更有效，因為智能體會死盯著清單，忽略清單之外的一切。 更好的提示是「這是我想要的結果，一直做直到通過所有這些測試。」

Harness Engineering 的另一半是確保智能體能在沒有你的情況下在程式碼倉庫中自如導航。 OpenAI 的做法是：把 AGENTS.md 控制在大約 100 行以內，作為目錄指向其他結構化文檔，並把文檔的時效性納入 CI 流程，而不是依賴那些很快就會過時的臨時更新。

當你把這一切都建好之後，一個自然的問題就出現了：如果智能體能驗證自己的工作、在倉庫中自如導航、不需要你就能糾正錯誤——那你為什麼還需要坐在椅子上？

提個醒，對於還在前幾個等級的朋友，接下來的內容可能聽起來很科幻（但沒關係，先收藏，回頭再來看）。

第 7 級：後台智能體

辣評：計畫模式正在消亡。

Claude Code 的創作者 Boris Cherny 目前仍有 80% 的任務以規劃模式開始。 但隨著每一代新模型的發布，經過計畫後的一次性成功率不斷攀升。 我認為我們正在接近這樣一個臨界點：計劃模式作為一個獨立的人工介入步驟將逐漸消失。 不是因為計劃本身不重要，而是因為模型已經夠聰明，能自己做好計劃了。 但有個重要前提：只有當你做好了第 3 到第 6 級的工作，這才成立。 如果你的情境是乾淨的、限制是明確的、工具描述是完善的、回饋循環是閉合的，模型就能在不需要你審查的情況下可靠地規劃。 如果這些工作沒做到位，你還是得盯著計畫不放。

說清楚一點，計劃作為一種通用實踐並不會消失，只是在改變形態。 對於新手來說，計劃模式仍然是正確的入口（如第 1 和第 2 級所述）。 但對於第 7 級的複雜功能，「計畫」看起來不再是寫一個逐步大綱，而更像是探索：探查程式碼庫、在 worktree 中做原型實驗、摸清解決方案的空間。 而且越來越多的時候，就是後台智能體在替你做這些探索。

這很重要，因為正是它解鎖了後台智能體。 如果一個智能體能產生可靠的計劃並執行而不需要你簽字確認，它就能在你做別的事的時候異步運行。 這是一個關鍵轉變——從「我同時切換多個標籤頁」變成了「有工作在沒有我的情況下推進著」。

Ralph 循環是流行的入門方式：一個自主智能體循環，反覆運行編程 CLI 直到 PRD（產品需求文件）中的所有事項完成，每次迭代都會啟動一個帶有全新上下文的新實例。 在我的經驗中，要把 Ralph 循環跑好並不容易，PRD 中的任何不充分或不準確的描述最終都會反噬作用。 它有點太「丟出去就不管了」。

你可以並行運行多個 Ralph 循環，但智能體啟動得越多，你就越會發現時間都花在哪裡了：協調它們、安排工作順序、檢查輸出、推動進度。 你已經不寫程式了——你變成了一個中階管理者。 你需要一個編排智能體來處理調度，這樣你才能專注於意圖而非後勤。

Dispatch 跨 3 個模型並行啟動 5 個 worker——你的會話保持精簡，智能體在幹活

我最近在大量使用的工具是 Dispatch，這是我做的一個 Claude Code 技能，把你的會話變成一個指揮中心。 你留在一個乾淨的會話中，worker 在隔離的上下文中完成繁重的工作。 調度器負責計劃、委派和跟踪，你的主上下文視窗被保留用於編排。 當 worker 卡住時，它會拋出澄清性問題而不是默默失敗。

Dispatch 在本地運行，非常適合你想與工作保持緊密聯繫的快速開發場景：反饋更快、調試更方便、沒有基礎設施開銷。 Ramp 的 Inspect 則是互補方案，適用於運行時間更長、更自主的工作：每個智能體會話都在雲端沙箱 VM 中啟動，並帶有完整的開發環境。 一個 PM 發現了 UI bug，在 Slack 中標記出來，Inspect 就會在你合上筆記型電腦的時候接手並處理。 代價是維運複雜性（基礎設施、快照、安全性），但你獲得的是本地智能體無法比擬的規模和可複現性。 我建議兩者都用（本地和雲端後台智能體）。

在這個等級有一個出乎意料地強大的模式：用不同的模型做不同的工作。 最好的工程團隊不是由一群克隆人組成的。 團隊成員有不同的思考方式、不同的訓練背景、不同的優勢。 同樣的邏輯也適用於 LLM。 這些模型經過了不同的後訓練，有著明顯不同的性格特徵。 我經常把 Opus 分配給實現工作，Gemini 做探索性研究，Codex 負責審查，綜合產出比任何單一模型獨立工作都更強。 可以理解為群體智慧，但用在了程式碼上。

至關重要的是，你還需要把實作者和審查者解耦。 這個教訓我吃了太多次虧：如果同一個模型實例既負責實現又負責評估自己的工作，它會有偏見。 它會忽略問題，告訴你所有任務都完成了——實際上並沒有。 這不是惡意，原因和你不會給自己的考試打分數一樣。 讓另一個模型（或一個帶有審查專用提示詞的不同實例）來做審查。 你的訊號品質會大幅提升。

後台智能體也為 CI 與 AI 的結合開啟了閘門。 一旦智能體可以在沒有人坐鎮的情況下運行，就可以從現有基礎設施中觸發它們。 一個文檔機器人在每次合併後重新產生文檔，並提交 PR 來更新 CLAUDE.md（我們正在使用這個，節省了大量時間）。 一個安全審查機器人掃描 PR 並提交修復。 一個依賴管理機器人不只是標記問題，而是真正升級套件並運行測試套件。 好的脈絡、持續沉澱的規則、強大的工具、自動化的回饋循環——現在全都在自主運作。

第 8 級：自主智能體團隊

目前還沒有人真正掌握了這個等級，儘管有少數人正在向它進發。 這是當前的前沿。

在第 7 級，你有一個編排 LLM 以中心輻射模式向工作 LLM 分發任務。 第 8 級移除了這個瓶頸。 智能體之間直接協調——認領任務、共享發現、標記依賴關係、解決衝突——一切都不需要經過單一的編排者。

Claude Code 的實驗性 Agent Teams 功能是一個早期實現：多個實例在共享程式碼庫上並行工作，隊友在各自的上下文視窗中運行並直接相互通訊。 Anthropic 用 16 個平行智能體從零建置了一個可以編譯 Linux 的 C 編譯器。 Cursor 運行了數百個並發智能體持續數週，從零構建了一個瀏覽器並將自己的程式碼庫從 Solid 遷移到了 React。

但仔細看就會發現問題。 Cursor 發現沒有層級結構時，智能體變得畏首畏尾，原地打轉毫無進展。 Anthropic 的智慧體不斷破壞已有功能，直到添加了 CI 管線來防止回歸才有所改善。 所有在這個等級做實驗的人都說同一件事：多智能體協調是個很難的問題，還沒有人找到最優解。

說實話，我不認為模型已經為大多數任務的這種自主程度做好了準備。 即使它們夠聰明，對於編譯器和瀏覽器建置以外的月球登陸級專案來說，它們仍然太慢、太費 token，在經濟上劃不來（令人印象深刻，但遠談不上成熟）。 對於我們大多數人日常的工作來說，第 7 級才是真正的槓桿所在。 我不會意外第 8 級最終成為主流模式，但現在我會把精力放在第 7 級上（除非你是 Cursor——突破本身就是你的業務）。

第 ? 級

不可避免的「接下來是什麼」問題。

一旦你能熟練地編排智能體團隊而沒有太多摩擦，互動介面就沒理由只停留在文字上了。 語音對語音（也許是思維對思維？）與程式設計智能體的互動——對話式的 Claude Code，而不僅僅是語音轉文字輸入——是自然的下一步。 看著你的應用，大聲描述一連串改動，然後看著它們在你面前發生。

有一群人在追逐完美的一次性生成：說出你想要什麼，AI 一步到位地完美呈現。 問題在於這個前提假設我們人類確切地知道自己想要什麼。 但我們不知道。 從來都不知道。 軟體開發一直是迭代式的，我認為它永遠會是。 只不過它會變得容易得多，遠遠超越純文字交互，而且快得多。

所以：你在哪個等級？ 你在做什麼來達到下一個？

你在哪個等級？

你通常怎麼用 AI 開始一個程式設計任務？