智能體工程的 8 個等級
整理版優先睇
智能體工程的8個等級：從Tab補全到自主團隊的進化路徑
呢篇文章係由Bassim Eledath寫嘅，佢同好多團隊同個人交流過用AI輔助編程嘅實踐，發現AI嘅編程能力雖然進步得好快，但係工程實踐同能力之間仲有好大差距。作者提出咗一個8等級嘅進化框架，由最基本嘅Tab補全一直去到自主智能體團隊，每個等級都會帶嚟產出嘅重大飛躍。佢話個關鍵唔係一味追模型分數，而係點樣建設好上下文、工具同反饋循環，先可以真正釋放AI嘅潛力。
前兩個等級（Tab補全同智能體IDE）只係起步，大多數人已經過咗。第3至第5級先係重點：上下文工程改善每次會話嘅資訊密度，複合工程將經驗沉澱落規則文件，MCP同技能擴展模型嘅能力邊界。呢啲基礎打得好，先可以進入更高級嘅自動化。
第6至第8級就係進階玩法：Harness Engineering建立完整嘅反饋循環，等智能體可以自己驗證同修正；後台智能體令工作喺你唔喺度嘅時候都繼續推進；最後嘅自主智能體團隊就係多個智能體直接協調，不過呢個仲未成熟。作者特別強調團隊協作效應——你嘅產出好 dépend 隊友嘅等級，幫佢哋升級對你自己都有利。
- 智能體工程分8個等級，每升一級產出就會有飛躍，而且隊友之間嘅等級會互相影響吞吐量。
- 第3至第5級係基石：上下文工程提高token資訊密度，複合工程將經驗沉澱落規則文件，MCP同技能擴展模型能力。
- 第6級Harness Engineering係關鍵，建立反饋循環同回壓機制，等智能體可以自主糾錯，唔使下下等人睇。
- 第7級後台智能體令工作可以異步運行，你需要由寫code變成做編排，用唔同模型分工可以發揮羣體智慧。
- 第8級自主智能體團隊仲未成熟，目前嘅樽頸係多智能體協調同token成本，對大部分人嚟講第7級先係最大槓桿。
Dispatch
作者整嘅Claude Code技能，可以將你嘅會話變成指揮中心，喺本地運行後台worker，適合快速開發場景。
起步階段：Tab補全同智能體IDE
呢兩個等級好快帶過。Tab補全係一切嘅起點，GitHub Copilot帶起咗呢個潮流——㩒一下Tab就自動補完code。呢個模式比較適合有經驗嘅開發者，佢哋可以自己搭好骨架，然後叫AI填細節。
但係天花板始終係上下文
以Cursor為代表嘅AI專用IDE改變咗格局，將聊天同codebase連接埋一齊，跨檔案編輯方便好多。不過 AI 成日睇唔到啱嘅上下文，或者睇到太多無關嘅嘢。呢個階段好多人會用計劃模式，將粗略諗法變成結構化步驟畀LLM，再反覆迭代，然後執行。
呢種做法喺呢個等級效果唔錯，但係再上一個等級你就會發現計劃模式嘅依賴會越來越少。
核心基礎：上下文、複合同技能
第3級係上下文工程，係2025年嘅年度熱詞。模型終於可以可靠噉跟到合理數量嘅指令，所以核心工作變咗提高每個token嘅資訊密度。
嘈雜嘅上下文同唔充分嘅上下文一樣咁差
佢包括系統提示詞、規則文件、工具描述、對話歷史管理，仲有決定每輪暴露邊啲工具。雖然而家模型對嘈雜上下文嘅容忍度高咗，但係喺細模型、Token消耗大户（例如Playwright MCP）同幾十個工具嘅場景下，上下文仍然會成為瓶頸。
複合工程係一個「計劃、委派、評估、沉澱」嘅循環。最關鍵嘅一步係沉澱——將經驗教訓寫入CLAUDE.md呢類規則文件，等模型下次唔會再犯同一個錯。
但係乜都塞入規則文件會適得其反，指令太多等於冇指令
更好嘅做法係建立一個環境，等LLM自己容易揾到有用嘅上下文，例如維護一個更新緊嘅docs/文件夾。
第5級解決嘅係能力問題。MCP同自定義技能令LLM可以直接操作數據庫、API、CI流水線等。作者舉例佢哋團隊共用一個PR審查技能，會根據PR性質有條件啟動子智能體。
當智能體開始批量產出PR，人工審查就成咗瓶頸，所以自動化、一致嘅技能驅動審查係必須
- 1 用MCP連接外部工具，例如Braintrust MCP查詢評估日誌、DeepWiki MCP存取開源文檔。
- 2 當團隊多人各寫同類技能，就值得整合成共享registry，Block內部已經有超過100個技能。
- 3 留意LLM越嚟越多用CLI工具代替MCP，因為token效率更高——MCP每輪都會注入完整工具定義，CLI淨係將相關輸出帶入上下文。
進階自動化：Harness、後台智能體同自主團隊
第6級Harness Engineering關注嘅係成個環境——工具、基礎設施同反饋循環，等智能體可以喺冇你幹預之下可靠工作。OpenAI嘅Codex團隊就建立咗一套完整嘅可觀測性系統，智能體可以截圖、驅動UI、查日誌、驗證修復，淨係需要判斷先上報人工。
智能體唔只係寫code，佢睇到code產生咩效果然後迭代改進，同人類一樣
支撐呢一切嘅核心概念係回壓機制——自動化嘅反饋機制（類型系統、測試、linter、pre-commit鈎子），等智能體可以自己發現同糾正錯誤。如果你想要自主性，就一定要有回壓，否則得到嘅就係一部垃圾生產機器。
- 為吞吐量而非完美設計：要求每次提交完美只會令智能體互相覆蓋修復，容忍細嘅非阻塞錯誤先係更實際。
- 約束優於指令：定義邊界比列步驟清單更有效，因為智能體會死盯住清單而忽略其他嘢。
- 安全邊界都係一種回壓：智能體、佢哋生成嘅code同你嘅密鑰應該處於唔同信任域，防止提示詞注入攻擊。
第7級後台智能體令工作可以喺你做其他嘢嘅時候異步運行。關鍵係模型要夠聰明，可以唔使你簽字就做好計劃同執行。作者提到Ralph循環係一種流行嘅入門方式，但係PRD嘅任何唔充分描述都會反噬。
個人經驗：用唔同模型做唔同工作——Opus做實現，Gemini做探索，Codex做審查，綜合產出比單一模型更強
作者自己整咗Dispatch呢個Claude Code技能，將會話變成指揮中心，worker喺隔離上下文做嘢，你留喺乾淨嘅會話做編排。Ramp嘅Inspect就係雲端方案，適合長時間自主運行。
第8級自主智能體團隊目前仲未有人真正掌握。Claude Code嘅Agent Teams係早期實現，Anthropic用16個並行智能體從零構建咗一個C編譯器，Cursor用數百個併發智能體從零整咗一個瀏覽器。但係問題好多：冇層級結構時智能體會原地打轉；破壞已有功能；成本太高。
對於日常開發，第7級先係真正嘅槓桿，第8級仲未成熟
作者最後展望未來：語音對語音交互可能係下一步，但 perfect one-shot generation 唔現實，因為人類從來都唔會一次過知道自己想要乜。軟件開發永遠係迭代式，只係會快好多。
你喺邊個等級？點樣升呢？
呢篇文章提出咗一個清晰嘅進化路徑，由Tab補全去到自主團隊。每個等級都需要建立喺前一個等級嘅基礎之上，特別係第3至第5級嘅上下文、複合同技能。
幫隊友升級對你自己都有利，假設你係7級高手但隊友仲喺2級，你嘅吞吐量就會被卡死
所以你應該問自己：我而家喺邊個等級？我下一步要做啲咩先可以升呢？係改善上下文工程，定係開始建立反饋循環？定係試下用Dispatch玩後台智能體？
AI嘅編程能力已經超越緊我哋駕馭佢嘅能力。呢個就係點解所有嗰啲死刷SWE-bench分數嘅努力，並冇同工程領導層真正關心嘅生產力指標同步。Anthropic團隊用咗10日就上線咗Cowork，而另一個團隊用緊同一個模型卻連一個POC（概念驗證）都搞唔掂——分別在於一個團隊已經填補咗能力同實踐之間嘅差距，而另一個仲未。
呢個差距唔會一夜之間消失，而系分級別逐步縮窄。總共8個級別。讀到呢篇文章嘅大多數人可能已經過咗頭幾個級別，而你應該等唔切想達到下一個——因為每升一級都意味住產出大躍進，而每次模型能力嘅提升都會進一步放大呢啲收益。
你應該在意嘅另一個原因系多人協作效應。你嘅產出比你想象中更加依賴隊友嘅級別。假設你係7級高手，夜晚瞓覺嘅時候後台AI代理就幫你開緊幾個PR。但如果你個代碼倉庫需要一位同事審批先可以合併，而呢位同事仲停留喺2級，仲系手動審查PR，咁你嘅吞吐量就被卡死咗。所以幫隊友升級，對你自己都有利。
通過同好多團隊同個人交流渠哋使用AI輔助編程嘅實踐，以下系我觀察到嘅級別進階路徑（順序並唔系絕對嚴格）：
AI代理工程嘅8個級別
第1和第2級：Tab補全與AI代理IDE
呢兩個級別我會快速跳過，主要係為咗記錄完整。可以隨意跳讀。
Tab補全系一切嘅起點。GitHub Copilot拉啓咗呢場運動嘅序幕——㩒一下Tab掣，自動補全代碼。好多人可能早就唔記得呢個階段，新入行嘅人甚至可能直接跳過咗。佢更適合有經驗嘅開發者，渠哋可以先搭好代碼骨架，然後讓AI來填充細節。
以Cursor為代表嘅AI專用IDE改變咗格局，渠哋將聊天與代碼庫連接起來，讓跨文件編輯變得輕鬆得多。但天花板始終繫上下文。模型只能幫你處理佢能見到嘅內容，而令人谷氣嘅系，佢要麼冇見到正確嘅上下文，要麼見到太多無關嘅上下文。
處於呢個級別嘅大多數人也在嘗試所選編程AI代理嘅計劃模式：將一個粗略概念轉化為結構化嘅分步計劃畀LLM，反覆修改呢個計劃，然後觸發執行。喺呢個階段效果唔錯，亦系保持掌控嘅合理方式。不過後面嘅級別我們會見到，對計劃模式嘅依賴會越來越少。
第3級：上下文工程
而家進入有意思嘅部分喇。上下文工程（Context Engineering）系2025年嘅年度熱詞，佢之所以成為一個概念，系因為模型終於可以可靠地遵循合理數量嘅指令，配合恰到好處嘅上下文。嘈雜嘅上下文同唔足夠嘅上下文一樣差，所以核心工作在於提高每個token嘅信息密度。“每個token都要為咗自己喺提示詞中嘅位置而戰”——呢個就係當時嘅信條。
同樣嘅信息，更少嘅token——信息密度先系王道（來源：humanlayer/12-factor-agents）
喺實踐中，上下文工程涉及嘅範圍比大多數人意識到的要廣。它包括你嘅系統提示詞同規則文件（.cursorrules、CLAUDE.md）。它包括你點樣描述工具，因為模型讀取呢啲描述來決定調用邊個工具。它包括管理對話歷史，避免長時間運行嘅AI代理喺第十輪對話後迷失方向。佢仲包括決定每輪暴露邊啲工具，因為太多選項會讓模型不知所措——就好似人一樣。
而家你已經比較少聽到上下文工程呢個講法咯。天平已經傾向咗那些能容忍更嘈雜上下文、喺更混亂場景中依然能推理嘅模型（更大嘅上下文窗口都有幫助）。但注意上下文嘅消耗仍然好重要。以下幾個場景中佢依然會成為樽頸：
• 小模型對上下文更敏感。 語音應用通常使用較小嘅模型，而且上下文大小同首token延遲有關，影響響應速度。 • Token消耗大户。 好似Playwright咁嘅MCP（Model Context Protocol，模型上下文協議）同圖片輸入會快速吞噬token，讓你喺Claude Code中比預期更早進入“壓縮會話”狀態。 • 接入咗幾十個工具嘅AI代理， 模型花喺解析工具定義上嘅token比做實際工作嘅仲要多。
更宏觀嘅要點系：上下文工程並冇消失，只系喺進化。重心已經從過濾壞上下文轉向確保正確嘅上下文喺正確嘅時間出現。而正系呢個轉變為第4級鋪平咗道路。
第4級：複合工程
上下文工程改善系當前呢一次會話。複合工程[1]（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嘅性質有條件地啓動子AI代理。一個負責檢查與數據庫嘅集成安全性，一個做複雜度分析來標記冗餘或過度工程，另一個檢查提示詞健康度以確保提示詞遵循團隊標準格式。佢仲運行linter同Ruff。
點解喺審查技能上投入咁多？因為當AI代理開始批量產出PR時，人工審查就變成樽頸而唔系質量關卡。Latent Space提出咗一個令人信服嘅論點[2]：我哋熟知嘅代碼審查已經死咗。取而代之嘅系自動化嘅、一致嘅、技能驅動嘅審查。
喺MCP方面，我用緊Braintrust MCP讓LLM可以查詢評估日誌並直接做出修改。我用DeepWiki MCP讓AI代理可以訪問任何開源倉庫嘅文檔，而唔需要手動將文檔拉入上下文。
當團隊中多個人開始各寫各嘅同類技能時，就值得整合成一個共享registry喇。Block[3]（致以慰問）有一篇好好嘅文章：渠哋構建咗一個內部技能市場，擁有超過100個技能，併為特定角色同團隊策劃咗技能套餐。技能同代碼享受同等待遇：pull request、審查、版本歷史。
重有一個值得關注嘅趨勢：LLM越來越多咁用CLI工具而唔系MCP（而且好似每間公司都在發佈自己嘅：Google Workspace CLI[4]，Braintrust都即將推出一個）。原因系token效率。MCP服務器喺每一輪都會將完整嘅工具定義注入上下文，唔理AI代理系咪使用渠哋。CLI就反過來：AI代理運行一個針對性嘅命令，只有相關嘅輸出先進入上下文窗口。我大量使用 agent-browser 而唔系Playwright MCP，正系出於呢個原因。
喺繼續之前暫停一下。 第3到第5級系後續一切嘅基石。LLM喺某些事情上出奇地好，喺另一些事情上又出奇地差，你需要培養出對呢啲邊界嘅直覺，然後先可以喺上面疊加更多自動化。如果你嘅上下文系嘈雜嘅、提示詞系唔充分或唔準確嘅、工具描述系含糊嘅，咁第6到第8級只會放大呢啲問題。
第6級：Harness Engineering
火箭真系開始起飛喇。
上下文工程關注嘅系模型見到乜嘢。Harness Engineering[5]（Harness Engineering）關注嘅系構建成個環境——工具、基礎設施同反饋循環——讓AI代理可以喺你唔干預嘅情況下可靠地工作。畀AI代理嘅唔止系編輯器，而系完整嘅反饋循環。
OpenAI嘅Codex工具鏈——一套完整嘅可觀測性系統，讓AI代理可以查詢、關聯同推理自己嘅輸出（來源：OpenAI）
OpenAI嘅Codex團隊將Chrome DevTools、可觀測性工具同瀏覽器導航集成到AI代理運行時中，讓佢可以截屏、驅動UI流程、查詢日誌、驗證自己嘅修復結果。畀一個提示詞，AI代理就可以復現bug、錄製視頻、實現修復。然後佢通過操控應用來驗證，提交PR，回應審查反饋，合併——只喺需要判斷時先上報人工。AI代理唔止系寫代碼，佢可以見到代碼產生咗乜嘢效果，然後迭代改進——就好似人類一樣。
我嘅團隊做嘅系技術故障排查嘅語音同聊天AI代理，所以我做咗一個叫 converse 嘅CLI工具，讓任何LLM都可以同我哋嘅後端接口聊天，進行逐輪對話。LLM修改代碼後，用 converse 喺在線系統測試對話，然後迭代。有時呢種自我改進循環會連續運行好幾個鍾。當結果可驗證時呢個尤其強大：對話必須遵循呢個流程，或者喺特定情況下調用呢啲工具（比如轉人工客服）。
支撐呢一切嘅核心概念系回壓機制[6]（Backpressure）——自動化嘅反饋機制（類型系統、測試、linter、pre-commit鈎子），讓AI代理可以喺唔需要人工干預嘅情況下發現並糾正錯誤。如果你想要自主性，就必須有回壓機制，否則你得倒嘅就係一部垃圾生產機器。呢個概念亦延伸到安全領域。Vercel嘅CTO指出[7]，AI代理、渠哋生成嘅代碼同你嘅密鑰應該處於唔同嘅信任域中，因為埋喺日誌文件裏嘅一條提示詞注入攻擊就可能誘使AI代理偷取你嘅憑證——如果所有嘢共享同一個安全上下文嘅話。安全邊界就係回壓機制：渠哋約束嘅系AI代理失控時可以做啲乜，而唔止系應該做啲乜。
兩個讓呢個理念更清晰嘅原則：
• 為咗吞吐量而設計，唔係為咗完美。 當要求每次提交都完美時，AI代理會喺同一個bug上反覆糾纏，互相覆蓋對方嘅修復。更好嘅做法系容忍細嘅非阻塞性錯誤，喺發佈前做一次最終嘅質量檢查。對同事我哋都系咁做。 • 約束優於指令。 一步步咁提示（“先做A，再做B，然後做C”）正在變得過時。根據我嘅經驗，定義邊界比列清單更有效，因為AI代理會死盯住清單，忽略清單以外嘅一切。更好嘅提示系“呢個系我想要嘅結果，一直做直到通過曬所有呢啲測試。”
Harness Engineering嘅另一半系確保AI代理可以喺冇你嘅情況下喺代碼倉庫中自如導航。OpenAI嘅做法系：將 AGENTS.md 控制喺大約100行以內，作為目錄指向其他結構化文檔，並將文檔嘅時效性納入CI流程，而唔系依賴那些好快就會過時嘅臨時更新。
當你將呢一切都建好之後，一個自然嘅問題就出現咗：如果AI代理可以驗證自己嘅工作、喺倉庫中自如導航、唔需要你就可以糾正錯誤——咁你點解仲要坐喺張櫈度？
提個醒，對於仲系前幾個級別嘅朋友，接下來嘅內容可能聽起來好科幻（但冇所謂，先收藏，回頭再睇）。
第7級：後台AI代理
辣評：計劃模式正在消亡。
Claude Code嘅創造者Boris Cherny而家仍有80%嘅任務[8]以計劃模式開始。但隨着每一代新模型嘅發佈，經過計劃後嘅一次性成功率不斷攀升。我認為我哋正在接近咁樣一個臨界點：計劃模式作為一個獨立嘅人工介入步驟將逐漸消失。唔系因為計劃本身唔重要，而系因為模型已經足夠聰明，可以自己做好計劃喇。但有個重要前提：只有當你做好咗第3到第6級嘅工作，呢個先成立。如果你嘅上下文系乾淨嘅、約束系明確嘅、工具描述系完善嘅、反饋循環系閉合嘅，模型就可以喺唔需要你審查嘅情況下可靠地規劃。如果呢啲工作冇做到位，你仍然要盯住計劃唔放。
講清楚啲，計劃作為一種通用實踐並唔會消失，只系喺改變形態。對於新手嚟講，計劃模式仍然系正確嘅入口（如第1和第2級所述）。但對於第7級嘅複雜功能，“計劃”睇落唔再系寫一個分步大綱，而更似系探索：探查代碼庫、喺worktree中做原型實驗、摸清解決方案嘅空間。而且越來越多嘅時候，系後台AI代理替你做緊呢啲探索。
呢個好重要，因為正系佢解咗後台AI代理嘅鎖。如果一個AI代理可以生成靠得住嘅計劃並執行而唔需要你簽字確認，佢就可以喺你做緊其他嘢嘅時候異步運行。呢個系一個關鍵轉變——從“我同時切換緊多個標籤頁”變成咗“有工作喺冇我嘅情況下推進緊”。
Ralph循環[9]系流行嘅入門方式：一個自主AI代理循環，反覆運行編程CLI直到PRD（產品需求文檔）中所有事項都完成，每次迭代都會啓動一個帶有全新上下文嘅新實例。喺我嘅經驗中，要運行好Ralph循環並唔容易，PRD中任何唔充分或唔準確嘅描述最終都會反噬。佢有啲太“掉出去就唔理”。
你可以並行運行多個Ralph循環，但AI代理啓動得越多，你就越會發現時間花喺邊度：協調渠哋、安排工作順序、檢查輸出、推動進度。你已經唔寫代碼喇——你變成咗一箇中層管理者。你需要一個編排AI代理來處理調度，咁你先可以專注喺意圖而唔系後勤。
Dispatch跨3個模型並行啓動5個worker——你嘅會話保持精簡，AI代理喺度做嘢
我最近大量使用嘅工具系Dispatch[10]，呢個系我做嘅一個Claude Code技能[11]，將你嘅會話變成一個指揮中心。你留喺一個乾淨嘅會話中，worker喺隔離嘅上下文中完成繁重嘅工作。調度器負責計劃、委派同跟蹤，你嘅主上下文窗口被保留用於編排。當worker卡住時，佢會拋出澄清性問題而唔系默默失敗。
Dispatch喺本地運行，好適合你想同工作保持緊密聯繫嘅快速開發場景：反饋更快、調試更方便、冇基礎設施開銷。Ramp嘅Inspect[12] 則系互補方案，適用於運行時間更長、更自主嘅工作：每個AI代理會話都會喺雲端沙箱VM中啓動，帶有完整嘅開發環境。一個PM發現咗UI bug，喺Slack中標記出來，Inspect就會喺你合上筆記本嘅時候接手並處理。代價系運維複雜性（基礎設施、快照、安全性），但你得倒嘅系本地AI代理無法比擬嘅規模同可復現性。我建議兩者都用（本地同雲端後台AI代理）。
喺呢個級別有一個出人意料地強大嘅模式：用唔同嘅模型做唔同嘅工作。最好嘅工程團隊唔系由一羣克隆人組成嘅。團隊成員有唔同嘅思維方式、唔同嘅訓練背景、唔同嘅優勢。同樣嘅邏輯適用於LLM。呢啲模型經過咗唔同嘅後訓練，有住明顯唔同嘅性格特點。我經常將Opus分配畀實現工作，Gemini做探索性研究，Codex負責審查，綜合產出比任何單一模型獨立工作都更強。可以理解為羣體智慧，但用喺代碼上。
至關緊要嘅系，你仲需要將實現者同審查者解耦。呢個教訓我食咗太多次虧：如果同一個模型實例既負責實現又負責評估自己嘅工作，佢會有偏見。佢會忽略問題，話畀你所有任務都完成咗——實際上並冇。呢個唔系惡意，原因同你唔會幫自己嘅考試打分一樣。讓另一個模型（或一個帶有審查專用提示詞嘅唔同實例）來做審查。你嘅信號質量會大幅提升。
後台AI代理仲為CI與AI嘅結合打開咗閘門。一旦AI代理可以喺冇人坐鎮嘅情況下運行，就可以從現有基礎設施中觸發渠哋。一個文檔機器人在每次合併後重新生成文檔，並提交PR來更新 CLAUDE.md（我哋用緊呢個，節省咗大量時間）。一個安全審查機器人掃描PR並提交修復。一個依賴管理機器人唔止系標記問題，而系真正升級包並運行測試套件。好嘅上下文、持續沉澱嘅規則、強大嘅工具、自動化嘅反饋循環——而家全都在自主運行。
第8級：自主AI代理團隊
而家仲未有人真正掌握呢個級別，雖然有少數人正在向佢進發。呢個系當前嘅前沿。
喺第7級，你有一個編排LLM以中心輻射式模式向工作LLM分發任務。第8級移除咗呢個樽頸。AI代理之間直接協調——認領任務、共享發現、標記依賴關係、解決衝突——一切都可以唔需要經過單一嘅編排者。
Claude Code嘅實驗性Agent Teams[13] 功能系一個早期實現：多個實例喺共享代碼庫上並行工作，隊友喺各自嘅上下文窗口中運行並直接相互通信。Anthropic用16個並行AI代理從零構建咗一個可以編譯Linux嘅C編譯器。Cursor運行咗數百個併發AI代理持續數星期，從零構建咗一個瀏覽器並將自己嘅代碼庫從Solid遷移到React。
但仔細睇就會發現問題。Cursor發現冇層級結構時，AI代理變得畏首畏尾，原地打轉冇任何進展。Anthropic嘅AI代理不斷破壞已有功能，直到添加咗CI流水線來防止迴歸先有改善。所有喺呢個級別做實驗嘅人都講同一件事：多AI代理協調系一個好難嘅問題，仲未有人揾到最優解。
講真，我唔認為模型已經為大多數任務嘅呢種自主程度做好準備。即使渠哋夠聰明，對於編譯器同瀏覽器構建以外嘅登月級項目嚟講，渠哋仍然太慢、太費token，在經濟上劃唔來（令人印象深刻，但遠談不上成熟）。對於我哋大多數人日常嘅工作嚟講，第7級先系真正嘅槓桿所在。我唔會意外第8級最終成為主流模式，但而家我會將精力放喺第7級上（除非你係Cursor——突破本身就是你嘅業務）。
第？級
不可避免嘅“跟住落嚟系乜嘢”問題。
一旦你能熟練咁編排AI代理團隊而冇太多摩擦，交互界面就冇理由只停留喺文本上喇。語音對語音（或者系思維對思維？）與編程AI代理嘅交互——對話式Claude Code，而唔止系語音轉文字輸入——系自然嘅下一步。望住你嘅應用，大聲描述一連串改動，然後望住渠哋喺你面前發生。
有一班人喺度追逐完美嘅一次性生成：講出你想要乜嘢，AI一步到位咁完美呈現。問題在於呢個前提假設我哋人類確切咁知道自己想要乜嘢。但我哋唔知道。從來都唔知道。軟件開發一直系迭代式嘅，我認為佢永遠都會系。只不過佢會變得容易得多，遠遠超越純文本交互，而且快得多。
所以：你喺邊個級別？你做緊啲乜嘢嚟達到下一個？
你喺邊個級別？
你通常點樣用AI開始一個編程任務？
原文：The 8 Levels of Agentic Engineering — Bassim Eledath
引用連結
[1] 複合工程: https://every.to/source-code/my-ai-had-already-fixed-the-code-before-i-saw-it[2] 令人信服嘅論點: https://www.latent.space/p/reviews-dead[3] Block: https://engineering.block.xyz/blog/3-principles-for-designing-agent-skills[4] Google Workspace CLI: https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-agents/[5] Harness Engineering: https://openai.com/index/harness-engineering/[6] 回壓機制: https://latentpatterns.com/glossary/agent-backpressure[7] Vercel嘅CTO指出: https://vercel.com/blog/security-boundaries-in-agentic-architectures[8] 80%嘅任務: https://youtu.be/PQU9o_5rHC4?si=8j25qad3-J_DbCNX[9] Ralph循環: https://ghuntley.com/loop/[10] Dispatch: https://github.com/bassimeledath/dispatch[11] Claude Code技能: https://www.bassimeledath.com/blog/dispatch[12] Ramp嘅Inspect: https://builders.ramp.com/post/why-we-built-our-background-agent[13] Agent Teams: https://code.claude.com/docs/en/agent-teams
AI 的編程能力正在超越我們駕馭它的能力。這就是為什麼所有那些拼命刷 SWE-bench 分數的努力，並沒有與工程領導層真正關心的生產力指標同步。Anthropic 團隊用 10 天就上線了 Cowork，而另一個團隊用着同樣的模型卻連一個 POC（概念驗證）都搞不定——區別在於一個團隊已經彌合了能力與實踐之間的差距，而另一個還沒有。
這個差距不會一夜之間消失，而是分等級逐步縮小。總共 8 個等級。讀到這篇文章的大多數人可能已經過了前幾個等級，而你應該迫不及待地想達到下一個——因為每升一級都意味着產出的巨大飛躍，而每次模型能力的提升都會進一步放大這些收益。
你應該在意的另一個原因是多人協作效應。你的產出比你想象的更依賴於隊友的等級。假設你是 7 級高手，晚上睡覺時後台智能體就在幫你提好幾個 PR。但如果你的代碼倉庫需要一位同事審批才能合併，而這位同事還停留在 2 級，仍在手動審查 PR，那你的吞吐量就被卡死了。所以幫隊友升級，對你自己也有利。
通過和許多團隊及個人交流他們使用 AI 輔助編程的實踐，以下是我觀察到的等級進階路徑（順序並不絕對嚴格）：
智能體工程的 8 個等級
第 1 和第 2 級：Tab 補全與智能體 IDE
這兩個等級我會快速帶過，主要是為了記錄完整。可以隨意跳讀。
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 級：複合工程
上下文工程改善的是當前這一次會話。複合工程[1]（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 提出了一個令人信服的論點[2]：我們熟知的代碼審查已經死了。取而代之的是自動化的、一致的、技能驅動的審查。
在 MCP 方面，我使用 Braintrust MCP 讓 LLM 能查詢評估日誌並直接做出修改。我使用 DeepWiki MCP 讓智能體可以訪問任何開源倉庫的文檔，而無需手動把文檔拉入上下文。
當團隊中多個人開始各寫各的同類技能時，就值得整合成一個共享 registry 了。Block[3]（致以慰問）有一篇很好的文章：他們構建了一個內部技能市場，擁有超過 100 個技能，併為特定角色和團隊策劃了技能套餐。技能和代碼享受同等待遇：pull request、審查、版本歷史。
還有一個值得關注的趨勢：LLM 越來越多地使用 CLI 工具而非 MCP（而且好像每家公司都在發佈自己的：Google Workspace CLI[4]，Braintrust 也即將推出一個）。原因是 token 效率。MCP 服務器在每一輪都會把完整的工具定義注入上下文，不管智能體是否使用它們。CLI 則反過來：智能體運行一個針對性的命令，只有相關的輸出才進入上下文窗口。我大量使用 agent-browser 而不是 Playwright MCP，正是出於這個原因。
在繼續之前暫停一下。 第 3 到第 5 級是後續一切的基石。LLM 在某些事情上出奇地好，在另一些事情上又出奇地差，你需要培養出對這些邊界的直覺，然後才能在上面疊加更多自動化。如果你的上下文是嘈雜的、提示詞是不充分或不準確的、工具描述是含糊的，那麼第 6 到第 8 級只會放大這些問題。
第 6 級：Harness Engineering
火箭真正開始起飛了。
上下文工程關注的是模型看到什麼。Harness Engineering[5]（Harness Engineering）關注的是構建整個環境——工具、基礎設施和反饋循環——讓智能體能在你不干預的情況下可靠地工作。給智能體的不只是編輯器，而是完整的反饋循環。
OpenAI 的 Codex 工具鏈——一套完整的可觀測性系統，讓智能體可以查詢、關聯和推理自己的輸出（來源：OpenAI）
OpenAI 的 Codex 團隊把 Chrome DevTools、可觀測性工具和瀏覽器導航集成到了智能體運行時中，讓它可以截屏、驅動 UI 流程、查詢日誌、驗證自己的修復結果。給一個提示詞，智能體就能復現 bug、錄製視頻、實現修復。然後它通過操控應用來驗證，提交 PR，回應審查反饋，合併——只在需要判斷時才上報人工。智能體不只是寫代碼，它能看到代碼產生了什麼效果，然後迭代改進——就像人類一樣。
我的團隊做的是技術故障排查的語音和聊天智能體，所以我做了一個叫 converse 的 CLI 工具，讓任何 LLM 都可以與我們的後端接口聊天，進行逐輪對話。LLM 修改代碼後，用 converse 在線上系統測試對話，然後迭代。有時這種自我改進循環會連續運行好幾個小時。當結果可驗證時這尤其強大：對話必須遵循這個流程，或者在特定情況下調用這些工具（比如轉人工客服）。
支撐這一切的核心概念是回壓機制[6]（Backpressure）——自動化的反饋機制（類型系統、測試、linter、pre-commit 鈎子），讓智能體能在不需要人工干預的情況下發現並糾正錯誤。如果你想要自主性，就必須有回壓機制，否則你得到的就是一台垃圾生產機器。這一點也延伸到安全領域。Vercel 的 CTO 指出[7]，智能體、它們生成的代碼和你的密鑰應該處於不同的信任域中，因為埋在日誌文件裏的一條提示詞注入攻擊就可能誘使智能體竊取你的憑證——如果所有東西共享同一個安全上下文的話。安全邊界就是回壓機制：它們約束的是智能體失控時能做什麼，而不僅僅是應該做什麼。
兩個讓這個理念更清晰的原則：
• 為吞吐量而非完美設計。 當要求每次提交都完美時，智能體會在同一個 bug 上反覆糾纏，互相覆蓋對方的修復。更好的做法是容忍小的非阻塞性錯誤，在發佈前做一次最終的質量檢查。對人類同事我們也是這麼做的。 • 約束優於指令。 一步步地提示（“先做 A，再做 B，然後做 C”）正在變得過時。根據我的經驗，定義邊界比列清單更有效，因為智能體會死盯着清單，忽略清單之外的一切。更好的提示是“這是我想要的結果，一直做直到通過所有這些測試。”
Harness Engineering 的另一半是確保智能體能在沒有你的情況下在代碼倉庫中自如導航。OpenAI 的做法是：把 AGENTS.md 控制在大約 100 行以內，作為目錄指向其他結構化文檔，並把文檔的時效性納入 CI 流程，而不是依賴那些很快就會過時的臨時更新。
當你把這一切都建好之後，一個自然的問題就出現了：如果智能體能驗證自己的工作、在倉庫中自如導航、不需要你就能糾正錯誤——那你為什麼還需要坐在椅子上？
提個醒，對於還在前幾個等級的朋友，接下來的內容可能聽起來很科幻（但沒關係，先收藏，回頭再來看）。
第 7 級：後台智能體
辣評：計劃模式正在消亡。
Claude Code 的創造者 Boris Cherny 目前仍有 80% 的任務[8]以計劃模式開始。但隨着每一代新模型的發佈，經過計劃後的一次性成功率不斷攀升。我認為我們正在接近這樣一個臨界點：計劃模式作為一個獨立的人工介入步驟將逐漸消失。不是因為計劃本身不重要，而是因為模型已經足夠聰明，能自己做好計劃了。但有個重要前提：只有當你做好了第 3 到第 6 級的工作，這才成立。如果你的上下文是乾淨的、約束是明確的、工具描述是完善的、反饋循環是閉合的，模型就能在不需要你審查的情況下可靠地規劃。如果這些工作沒做到位，你還是得盯着計劃不放。
說清楚一點，計劃作為一種通用實踐並不會消失，只是在改變形態。對於新手來說，計劃模式仍然是正確的入口（如第 1 和第 2 級所述）。但對於第 7 級的複雜功能，“計劃”看起來不再是寫一個分步大綱，而更像是探索：探查代碼庫、在 worktree 中做原型實驗、摸清解決方案的空間。而且越來越多的時候，是後台智能體在替你做這些探索。
這很重要，因為正是它解鎖了後台智能體。如果一個智能體能生成靠譜的計劃並執行而不需要你簽字確認，它就能在你做別的事的時候異步運行。這是一個關鍵轉變——從“我同時切換着多個標籤頁”變成了“有工作在沒有我的情況下推進着”。
Ralph 循環[9]是流行的入門方式：一個自主智能體循環，反覆運行編程 CLI 直到 PRD（產品需求文檔）中的所有事項完成，每次迭代都會啓動一個帶有全新上下文的新實例。在我的經驗中，要把 Ralph 循環跑好並不容易，PRD 中的任何不充分或不準確的描述最終都會反噬。它有點太“扔出去就不管了”。
你可以並行運行多個 Ralph 循環，但智能體啓動得越多，你就越會發現時間都花在哪了：協調它們、安排工作順序、檢查輸出、推動進度。你已經不寫代碼了——你變成了一箇中層管理者。你需要一個編排智能體來處理調度，這樣你才能專注於意圖而非後勤。
Dispatch 跨 3 個模型並行啓動 5 個 worker——你的會話保持精簡，智能體在幹活
我最近在大量使用的工具是 Dispatch[10]，這是我做的一個 Claude Code 技能[11]，把你的會話變成一個指揮中心。你留在一個乾淨的會話中，worker 在隔離的上下文中完成繁重的工作。調度器負責計劃、委派和跟蹤，你的主上下文窗口被保留用於編排。當 worker 卡住時，它會拋出澄清性問題而不是默默失敗。
Dispatch 在本地運行，非常適合你想與工作保持緊密聯繫的快速開發場景：反饋更快、調試更方便、沒有基礎設施開銷。Ramp 的 Inspect[12] 則是互補方案，適用於運行時間更長、更自主的工作：每個智能體會話都在雲端沙箱 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[13] 功能是一個早期實現：多個實例在共享代碼庫上並行工作，隊友在各自的上下文窗口中運行並直接相互通信。Anthropic 用 16 個並行智能體從零構建了一個可以編譯 Linux 的 C 編譯器。Cursor 運行了數百個併發智能體持續數週，從零構建了一個瀏覽器並將自己的代碼庫從 Solid 遷移到了 React。
但仔細看就會發現問題。Cursor 發現沒有層級結構時，智能體變得畏首畏尾，原地打轉毫無進展。Anthropic 的智能體不斷破壞已有功能，直到添加了 CI 流水線來防止迴歸才有所改善。所有在這個等級做實驗的人都說同一件事：多智能體協調是個很難的問題，還沒有人找到最優解。
說實話，我不認為模型已經為大多數任務的這種自主程度做好了準備。即使它們夠聰明，對於編譯器和瀏覽器構建以外的月球登陸級項目來說，它們仍然太慢、太費 token，在經濟上划不來（令人印象深刻，但遠談不上成熟）。對於我們大多數人日常的工作來說，第 7 級才是真正的槓桿所在。我不會意外第 8 級最終成為主流模式，但現在我會把精力放在第 7 級上（除非你是 Cursor——突破本身就是你的業務）。
第？級
不可避免的“接下來是什麼”問題。
一旦你能熟練地編排智能體團隊而沒有太多摩擦，交互界面就沒理由只停留在文本上了。語音對語音（也許是思維對思維？）與編程智能體的交互——對話式的 Claude Code，而不僅僅是語音轉文字輸入——是自然的下一步。看着你的應用，大聲描述一連串改動，然後看着它們在你面前發生。
有一羣人在追逐完美的一次性生成：說出你想要什麼，AI 一步到位地完美呈現。問題在於這個前提假設我們人類確切地知道自己想要什麼。但我們不知道。從來都不知道。軟件開發一直是迭代式的，我認為它永遠會是。只不過它會變得容易得多，遠遠超越純文本交互，而且快得多。
所以：你在哪個等級？你在做什麼來達到下一個？
你在哪個等級？
你通常怎麼用 AI 開始一個編程任務？
原文：The 8 Levels of Agentic Engineering — Bassim Eledath
引用連結
[1] 複合工程: https://every.to/source-code/my-ai-had-already-fixed-the-code-before-i-saw-it[2] 令人信服的論點: https://www.latent.space/p/reviews-dead[3] Block: https://engineering.block.xyz/blog/3-principles-for-designing-agent-skills[4] Google Workspace CLI: https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-agents/[5] Harness Engineering: https://openai.com/index/harness-engineering/[6] 回壓機制: https://latentpatterns.com/glossary/agent-backpressure[7] Vercel 的 CTO 指出: https://vercel.com/blog/security-boundaries-in-agentic-architectures[8] 80% 的任務: https://youtu.be/PQU9o_5rHC4?si=8j25qad3-J_DbCNX[9] Ralph 循環: https://ghuntley.com/loop/[10] Dispatch: https://github.com/bassimeledath/dispatch[11] Claude Code 技能: https://www.bassimeledath.com/blog/dispatch[12] Ramp 的 Inspect: https://builders.ramp.com/post/why-we-built-our-background-agent[13] Agent Teams: https://code.claude.com/docs/en/agent-teams