作者：Bassim Eledath
原文：The 8 Levels of Agentic Engineering — Bassim Eledath

AI 的編程能力正在超越我們駕馭它的能力。這就是為什么所有那些拼命刷 SWE-bench 分數(shù)的努力，并沒有與工程領(lǐng)導(dǎo)層真正關(guān)心的生產(chǎn)力指標(biāo)同步。Anthropic 團隊用 10 天就上線了 Cowork，而另一個團隊用著同樣的模型卻連一個 POC（概念驗證）都搞不定——區(qū)別在于一個團隊已經(jīng)彌合了能力與實踐之間的差距，而另一個還沒有。

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

你應(yīng)該在意的另一個原因是多人協(xié)作效應(yīng)。你的產(chǎn)出比你想象的更依賴于隊友的等級。假設(shè)你是 7 級高手，晚上睡覺時后臺智能體就在幫你提好幾個 PR。但如果你的代碼倉庫需要一位同事審批才能合并，而這位同事還停留在 2 級，仍在手動審查 PR，那你的吞吐量就被卡死了。所以幫隊友升級，對你自己也有利。

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

智能體工程的 8 個等級

第 1 和第 2 級：Tab 補全與智能體 IDE

這兩個等級我會快速帶過，主要是為了記錄完整。可以隨意跳讀。

Tab 補全是一切的起點。GitHub Copilot 拉開了這場運動的序幕——按一下 Tab 鍵，自動補全代碼。很多人可能早就忘了這個階段，新入行的人甚至可能直接跳過了。它更適合有經(jīng)驗的開發(fā)者，他們能先搭好代碼骨架，然后讓 AI 來填充細節(jié)。

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

處于這個等級的大多數(shù)人也在嘗試所選編程智能體的計劃模式：把一個粗略的想法轉(zhuǎn)化為結(jié)構(gòu)化的分步計劃給 LLM，反復(fù)迭代這個計劃，然后觸發(fā)執(zhí)行。在這個階段效果不錯，也是保持掌控的合理方式。不過后面的等級我們會看到，對計劃模式的依賴會越來越少。

第 3 級：上下文工程

現(xiàn)在進入有意思的部分了。上下文工程（Context Engineering）是 2025 年的年度熱詞，它之所以成為一個概念，是因為模型終于可以可靠地遵循合理數(shù)量的指令，配合恰到好處的上下文。嘈雜的上下文和不充分的上下文一樣糟糕，所以核心工作在于提高每個 token 的信息密度。"每個 token 都要為自己在提示詞中的位置而戰(zhàn)"——這就是當(dāng)時的信條。

同樣的信息，更少的 token——信息密度才是王道（來源：humanlayer/12-factor-agents）

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

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

小模型對上下文更敏感。 語音應(yīng)用通常使用較小的模型，而且上下文大小也與首 token 延遲相關(guān)，影響響應(yīng)速度。

Token 消耗大戶。 像 Playwright 這樣的 MCP（Model Context Protocol，模型上下文協(xié)議）和圖片輸入會快速吞噬 token，讓你在 Claude Code 中比預(yù)期更早進入"壓縮會話"狀態(tài)。

接入了幾十個工具的智能體， 模型花在解析工具定義上的 token 比做實際工作的還多。

更宏觀的要點是：上下文工程并沒有消失，只是在進化。重心已經(jīng)從過濾壞上下文轉(zhuǎn)向確保正確的上下文在正確的時間出現(xiàn)。而正是這個轉(zhuǎn)變?yōu)榈?4 級鋪平了道路。

第 4 級：復(fù)合工程

上下文工程改善的是當(dāng)前這一次會話。復(fù)合工程（Compounding Engineering，由 Kieran Klaassen 提出）改善的是此后的每一次會話。這個理念對我和許多人來說都是一個轉(zhuǎn)折點——它讓我們意識到"憑感覺編程"遠不只是做原型那么簡單。

這是一個"計劃、委派、評估、沉淀"的循環(huán)。你規(guī)劃任務(wù)，給 LLM 提供足夠的上下文讓它成功。你把任務(wù)委派出去。你評估產(chǎn)出。然后關(guān)鍵的一步——你把學(xué)到的東西沉淀下來：什么有效、什么出了問題、下次應(yīng)該遵循什么模式。

復(fù)合循環(huán)：計劃、委派、評估、沉淀——每一輪都讓下一輪更好

魔力就在"沉淀"這一步。LLM 是無狀態(tài)的。如果它昨天重新引入了一個你明確移除的依賴，明天它還會這么做——除非你告訴它不要。最常見的解決方法是更新你的 CLAUDE.md（或等效的規(guī)則文件），把經(jīng)驗教訓(xùn)固化到每一次未來的會話中。但要注意：什么都往規(guī)則文件里塞的沖動可能適得其反（指令太多等于沒有指令）。更好的做法是創(chuàng)造一個環(huán)境，讓 LLM 能自己輕松發(fā)現(xiàn)有用的上下文——比如維護一個保持更新的 docs/ 文件夾（第 7 級會詳細講這個）。

實踐復(fù)合工程的人通常對喂給 LLM 的上下文高度敏感。當(dāng) LLM 犯錯時，他們的本能反應(yīng)是先想上下文是不是缺了什么，而不是怪模型不行。正是這種直覺，使得第 5 到第 8 級成為可能。

第 5 級：MCP 與技能

第 3 和第 4 級解決的是上下文問題。第 5 級解決的是能力問題。MCP 和自定義技能讓你的 LLM 能訪問數(shù)據(jù)庫、API、CI 流水線、設(shè)計系統(tǒng)，還有用于瀏覽器測試的 Playwright、用于通知的 Slack。模型不再只是在思考你的代碼庫——它現(xiàn)在可以直接操作了。

關(guān)于 MCP 和技能的優(yōu)質(zhì)資料已經(jīng)不少，我就不贅述它們是什么了。但舉幾個我使用它們的例子：我們團隊共享一個 PR 審查技能，大家一起迭代改進（現(xiàn)在仍在改），它會根據(jù) PR 的性質(zhì)有條件地啟動子智能體。一個負責(zé)檢查與數(shù)據(jù)庫的集成安全性，一個做復(fù)雜度分析來標(biāo)記冗余或過度工程，另一個檢查提示詞健康度以確保提示詞遵循團隊標(biāo)準(zhǔn)格式。它還運行 linter 和 Ruff。

為什么在審查技能上投入這么多？因為當(dāng)智能體開始批量產(chǎn)出 PR 時，人工審查就成了瓶頸而非質(zhì)量關(guān)卡。Latent Space 提出了一個令人信服的論點：我們熟知的代碼審查已經(jīng)死了。取而代之的是自動化的、一致的、技能驅(qū)動的審查。

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

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

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

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

第 6 級：Harness Engineering

火箭真正開始起飛了。

上下文工程關(guān)注的是模型看到什么。Harness Engineering（Harness Engineering）關(guān)注的是構(gòu)建整個環(huán)境——工具、基礎(chǔ)設(shè)施和反饋循環(huán)——讓智能體能在你不干預(yù)的情況下可靠地工作。給智能體的不只是編輯器，而是完整的反饋循環(huán)。

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

OpenAI 的 Codex 團隊把 Chrome DevTools、可觀測性工具和瀏覽器導(dǎo)航集成到了智能體運行時中，讓它可以截屏、驅(qū)動 UI 流程、查詢?nèi)罩尽Ⅱ炞C自己的修復(fù)結(jié)果。給一個提示詞，智能體就能復(fù)現(xiàn) bug、錄制視頻、實現(xiàn)修復(fù)。然后它通過操控應(yīng)用來驗證，提交 PR，回應(yīng)審查反饋，合并——只在需要判斷時才上報人工。智能體不只是寫代碼，它能看到代碼產(chǎn)生了什么效果，然后迭代改進——就像人類一樣。

我的團隊做的是技術(shù)故障排查的語音和聊天智能體，所以我做了一個叫 converse 的 CLI 工具，讓任何 LLM 都可以與我們的后端接口聊天，進行逐輪對話。LLM 修改代碼后，用 converse 在線上系統(tǒng)測試對話，然后迭代。有時這種自我改進循環(huán)會連續(xù)運行好幾個小時。當(dāng)結(jié)果可驗證時這尤其強大：對話必須遵循這個流程，或者在特定情況下調(diào)用這些工具（比如轉(zhuǎn)人工客服）。

支撐這一切的核心概念是回壓機制（Backpressure）——自動化的反饋機制（類型系統(tǒng)、測試、linter、pre-commit 鉤子），讓智能體能在不需要人工干預(yù)的情況下發(fā)現(xiàn)并糾正錯誤。如果你想要自主性，就必須有回壓機制，否則你得到的就是一臺垃圾生產(chǎn)機器。這一點也延伸到安全領(lǐng)域。Vercel 的 CTO 指出，智能體、它們生成的代碼和你的密鑰應(yīng)該處于不同的信任域中，因為埋在日志文件里的一條提示詞注入攻擊就可能誘使智能體竊取你的憑證——如果所有東西共享同一個安全上下文的話。安全邊界就是回壓機制：它們約束的是智能體失控時能做什么，而不僅僅是應(yīng)該做什么。

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

為吞吐量而非完美設(shè)計。 當(dāng)要求每次提交都完美時，智能體會在同一個 bug 上反復(fù)糾纏，互相覆蓋對方的修復(fù)。更好的做法是容忍小的非阻塞性錯誤，在發(fā)布前做一次最終的質(zhì)量檢查。對人類同事我們也是這么做的。

約束優(yōu)于指令。 一步步地提示（"先做 A，再做 B，然后做 C"）正在變得過時。根據(jù)我的經(jīng)驗，定義邊界比列清單更有效，因為智能體會死盯著清單，忽略清單之外的一切。更好的提示是"這是我想要的結(jié)果，一直做直到通過所有這些測試。"

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

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

提個醒，對于還在前幾個等級的朋友，接下來的內(nèi)容可能聽起來很科幻（但沒關(guān)系，先收藏，回頭再來看）。

第 7 級：后臺智能體

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

Claude Code 的創(chuàng)造者 Boris Cherny 目前仍有 80% 的任務(wù)以計劃模式開始。但隨著每一代新模型的發(fā)布，經(jīng)過計劃后的一次性成功率不斷攀升。我認為我們正在接近這樣一個臨界點：計劃模式作為一個獨立的人工介入步驟將逐漸消失。不是因為計劃本身不重要，而是因為模型已經(jīng)足夠聰明，能自己做好計劃了。但有個重要前提：只有當(dāng)你做好了第 3 到第 6 級的工作，這才成立。如果你的上下文是干凈的、約束是明確的、工具描述是完善的、反饋循環(huán)是閉合的，模型就能在不需要你審查的情況下可靠地規(guī)劃。如果這些工作沒做到位，你還是得盯著計劃不放。

說清楚一點，計劃作為一種通用實踐并不會消失，只是在改變形態(tài)。對于新手來說，計劃模式仍然是正確的入口（如第 1 和第 2 級所述）。但對于第 7 級的復(fù)雜功能，"計劃"看起來不再是寫一個分步大綱，而更像是探索：探查代碼庫、在 worktree 中做原型實驗、摸清解決方案的空間。而且越來越多的時候，是后臺智能體在替你做這些探索。

這很重要，因為正是它解鎖了后臺智能體。如果一個智能體能生成靠譜的計劃并執(zhí)行而不需要你簽字確認，它就能在你做別的事的時候異步運行。這是一個關(guān)鍵轉(zhuǎn)變——從"我同時切換著多個標(biāo)簽頁"變成了"有工作在沒有我的情況下推進著"。

Ralph 循環(huán)是流行的入門方式：一個自主智能體循環(huán)，反復(fù)運行編程 CLI 直到 PRD（產(chǎn)品需求文檔）中的所有事項完成，每次迭代都會啟動一個帶有全新上下文的新實例。在我的經(jīng)驗中，要把 Ralph 循環(huán)跑好并不容易，PRD 中的任何不充分或不準(zhǔn)確的描述最終都會反噬。它有點太"扔出去就不管了"。

你可以并行運行多個 Ralph 循環(huán)，但智能體啟動得越多，你就越會發(fā)現(xiàn)時間都花在哪了：協(xié)調(diào)它們、安排工作順序、檢查輸出、推動進度。你已經(jīng)不寫代碼了——你變成了一個中層管理者。你需要一個編排智能體來處理調(diào)度，這樣你才能專注于意圖而非后勤。

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

我最近在大量使用的工具是 Dispatch，這是我做的一個 Claude Code 技能，把你的會話變成一個指揮中心。你留在一個干凈的會話中，worker 在隔離的上下文中完成繁重的工作。調(diào)度器負責(zé)計劃、委派和跟蹤，你的主上下文窗口被保留用于編排。當(dāng) worker 卡住時，它會拋出澄清性問題而不是默默失敗。

Dispatch 在本地運行，非常適合你想與工作保持緊密聯(lián)系的快速開發(fā)場景：反饋更快、調(diào)試更方便、沒有基礎(chǔ)設(shè)施開銷。Ramp 的 Inspect 則是互補方案，適用于運行時更長、更自主的工作：每個智能體會話都在云端沙箱 VM 中啟動，帶有完整的開發(fā)環(huán)境。一個 PM 發(fā)現(xiàn)了 UI bug，在 Slack 中標(biāo)記出來，Inspect 就會在你合上筆記本電腦的時候接手并處理。代價是運維復(fù)雜性（基礎(chǔ)設(shè)施、快照、安全性），但你獲得的是本地智能體無法比擬的規(guī)模和可復(fù)現(xiàn)性。我建議兩者都用（本地和云端后臺智能體）。

在這個等級有一個出人意料地強大的模式：用不同的模型做不同的工作。最好的工程團隊不是由一群克隆人組成的。團隊成員有不同的思維方式、不同的訓(xùn)練背景、不同的優(yōu)勢。同樣的邏輯適用于 LLM。這些模型經(jīng)過了不同的后訓(xùn)練，有著明顯不同的性格特點。我經(jīng)常把 Opus 分配給實現(xiàn)工作，Gemini 做探索性研究，Codex 負責(zé)審查，綜合產(chǎn)出比任何單一模型獨立工作都更強?？梢岳斫鉃槿后w智慧，但用在了代碼上。

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

后臺智能體還為 CI 與 AI 的結(jié)合打開了閘門。一旦智能體可以在沒有人坐鎮(zhèn)的情況下運行，就可以從現(xiàn)有基礎(chǔ)設(shè)施中觸發(fā)它們。一個文檔機器人在每次合并后重新生成文檔，并提交 PR 來更新 CLAUDE.md（我們在用這個，節(jié)省了大量時間）。一個安全審查機器人掃描 PR 并提交修復(fù)。一個依賴管理機器人不只是標(biāo)記問題，而是真正升級包并運行測試套件。好的上下文、持續(xù)沉淀的規(guī)則、強大的工具、自動化的反饋循環(huán)——現(xiàn)在全都在自主運行。

第 8 級：自主智能體團隊

目前還沒有人真正掌握了這個等級，盡管有少數(shù)人正在向它進發(fā)。這是當(dāng)前的前沿。

在第 7 級，你有一個編排 LLM 以中心輻射式模式向工作 LLM 分發(fā)任務(wù)。第 8 級移除了這個瓶頸。智能體之間直接協(xié)調(diào)——認領(lǐng)任務(wù)、共享發(fā)現(xiàn)、標(biāo)記依賴關(guān)系、解決沖突——一切都不需要經(jīng)過單一的編排者。

Claude Code 的實驗性 Agent Teams 功能是一個早期實現(xiàn)：多個實例在共享代碼庫上并行工作，隊友在各自的上下文窗口中運行并直接相互通信。Anthropic 用 16 個并行智能體從零構(gòu)建了一個可以編譯 Linux 的 C 編譯器。Cursor 運行了數(shù)百個并發(fā)智能體持續(xù)數(shù)周，從零構(gòu)建了一個瀏覽器并將自己的代碼庫從 Solid 遷移到了 React。

但仔細看就會發(fā)現(xiàn)問題。Cursor 發(fā)現(xiàn)沒有層級結(jié)構(gòu)時，智能體變得畏首畏尾，原地打轉(zhuǎn)毫無進展。Anthropic 的智能體不斷破壞已有功能，直到添加了 CI 流水線來防止回歸才有所改善。所有在這個等級做實驗的人都說同一件事：多智能體協(xié)調(diào)是個很難的問題，還沒有人找到最優(yōu)解。

說實話，我不認為模型已經(jīng)為大多數(shù)任務(wù)的這種自主程度做好了準(zhǔn)備。即使它們夠聰明，對于編譯器和瀏覽器構(gòu)建以外的月球登陸級項目來說，它們?nèi)匀惶?、太費 token，在經(jīng)濟上劃不來（令人印象深刻，但遠談不上成熟）。對于我們大多數(shù)人日常的工作來說，第 7 級才是真正的杠桿所在。我不會意外第 8 級最終成為主流模式，但現(xiàn)在我會把精力放在第 7 級上（除非你是 Cursor——突破本身就是你的業(yè)務(wù)）。

第 ? 級

不可避免的"接下來是什么"問題。

一旦你能熟練地編排智能體團隊而沒有太多摩擦，交互界面就沒理由只停留在文本上了。語音對語音（也許是思維對思維？）與編程智能體的交互——對話式的 Claude Code，而不僅僅是語音轉(zhuǎn)文字輸入——是自然的下一步?？粗愕膽?yīng)用，大聲描述一連串改動，然后看著它們在你面前發(fā)生。

有一群人在追逐完美的一次性生成：說出你想要什么，AI 一步到位地完美呈現(xiàn)。問題在于這個前提假設(shè)我們?nèi)祟惔_切地知道自己想要什么。但我們不知道。從來都不知道。軟件開發(fā)一直是迭代式的，我認為它永遠會是。只不過它會變得容易得多，遠遠超越純文本交互，而且快得多。

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

你在哪個等級？

你通常怎么用 AI 開始一個編程任務(wù)？