在大多數關於代理工程（Agentic Engineering）的討論中，核心行動已從「下提示詞」轉變為「操作」。以下是窺探前沿的一些關鍵概念：軟體工廠、目標、循環、背景會話、子代理、鉤子、沙盒、以及審核代理的代理。對於未來的許多創作者來說，這種行為將從第一天起就內建在產品中：Claude Code 和 Codex 直接展現了這種轉變。
從工程師的角度來看，你會使用「低自主性」來限制風險並提高可逆性，但對明確的活動則使用「高自主性」，並利用平行代理大軍安全地重構大型程式碼庫。關於一個行動的核心問題始終是：這個任務值得什麼層級的自主性，以及什麼樣的驗證能使該層級具有說服力？
前沿的邊界是「管理者代理」——它會在觸發條件被滿足時啟動，將任務委派給其助手，同時持續驗證它們的輸出，最後只回報那些必須由人類做出的決策。使用這種配置的人，可能已經在運行數百甚至數千個代理，主要是在持續更新的程式碼庫上。如同所有關於自主性的思考一樣，每個人對於規模的感受仍然不同。
最常被提及的規模階梯來自 Steve Yegge 的單軸階梯，在「Welcome to Gas Town」和《The Pragmatic Engineer》中都有提到。如果你想用一個數字來衡量自己有多「AI 原生」，這是個很好的參考：這個階梯提供一個單一數字，讓你知道自己對某個代理的信任程度。以下是其中一個版本：
在 2026 年初，即使工作重點開始從「委派」轉向「編排」，這仍然是衡量風險的一個相當好的代理指標。然而今天，許多的技能組合，當你能同時運行多個代理時，其重要性和影響力可能會大幅提升。 單一階梯無法幫助你定位「多代理技能」的層級。
相反地，我所見過的幾乎所有關於自主性的辯論，都混淆了兩個應該被分開的問題：我們允許這個單一代理離我們多遠？以及，我們協調多個代理的能力如何？
為了分別捕捉這兩個維度，我們將使用兩個軸線：代理能力（Agency）與編排能力（Orchestration）。
在代理能力軸上，「低」包括建議候選行動並等待決策。
「中」表示代理正在處理特定任務，但限制了它的行動範圍，並持續回報它的行動及相關證據，以便你能持續引導它。
在「高代理能力」端，代理是朝著一個目標工作，進行實驗、學習、測試、尋找解決問題的方法、遇到阻礙時提問、嘗試不同方法，並將所有這些工作以證據的形式回報。
在編排能力軸上，「低」表示一個代理、一個執行緒。到了「中」，你有好幾個代理，各自在自己的工作目錄中運作，可能朝著不同的目標前進，但彼此隔離。在「高」端，你有一個編排器，它可以接收待辦事項、問題追蹤器、時間表或其他佇列，並將其轉化為持續的工作，你只需要在出問題時介入：「例外管理」。納入這些想法的主要產品和功能包括：
- Claude Code 的 /plan、/goal、/loop、/background、/batch、/code-review、/security-review 模式、子代理、鉤子、檢查點、代理委派與管理實務、背景會話、代理團隊模式、/schedule 參數
- Codex 的本地/雲端執行緒、目標模式（Goal mode）、工作目錄（worktrees）、自動化（Automations）、子代理、審查面板（review panes）、GitHub 程式碼審查、鉤子、沙盒化、自動審查（Auto-review）與重新執行
這些能力無法被容納在單一階梯中。
攀登之路：三個時代與一個統一架構
如果你從底部向上閱讀這個階梯，你會想像自己在同時提升「代理能力」和「編排能力」。實際上，這六個層級代表了我們都會經歷的三個不同時代：
首先，你處於主導地位，代理主要只是輔助，等待你的引導。
其次，代理負責一個有邊界的任務或目標，但你仍然在旁邊引導它並驗證其工作。
第三，在編排時代，系統能夠主導整個流程，將工作分派給多個代理，你大多隻需要在事情出錯時介入：「例外管理」。
這讓事情變得更簡單，因為階梯上的垂直位置很清楚地捕捉了這兩個軸線（編排能力只在接近頂端時才啟動），使其成為一個透過各階梯穩定爬升的旅程。然而，這個攀登過程仍然是我们所有人正在經歷的轉變的一部分。
一個好的工程工作日，會觸及好幾個階梯，有時更多：在一個任務的過程中，切換幾次時代是很正常的。
六個層級詳解
第 0 級：輔助（Assist）
代理會提出建議，這些建議多半是好的，也常常是完美的，但你總是需要決定它們是否足夠好以付諸行動。可以想像為自動完成、內嵌編輯建議，或是待在聊天會話中討論一個還沒有人認領的變更。適用於代價高昂的錯誤、微小的變更，或當你仍在形成自己的判斷時。驗證主要在本機端進行。
第 1 級：受監督的行動（Supervised Action）
代理會代表你編輯或執行命令，但會在執行任何後果嚴重的操作前先詢問你。 這是大多數人的預設姿態。可以在本機沙盒中進行，套用變更前需要獲得批准——每次批准都是對「這次變更可以套用」的獨立驗證——也可以在互動式會話中進行。失敗模式是「批准疲勞」；無論批准的是什麼內容，所有批准看起來都一樣。你可能會透過快速掃描 diff、遵循一些經驗法則、在批准前與其他人確認，或只是同意讓代理負責，來解決這個問題。Codex 的 Auto-review 功能透過將邊界條件的最終批准委派給一個獨立的審查代理來解決這個問題。
第 2 級：限定任務委派（Scoped Task Delegation）
將一個有邊界的任務交給代理。 該任務將有明確的目標、限制條件，以及對「完成」的運作定義。你會在附近，能夠打斷，但大多不參與。這是軟體工程世界中的重力中心。驗證正在從你身上（你可能需要休息和睡覺）轉移到代理能夠產生的證據上：通過自動化測試、正確的型別、lint 建議、螢幕截圖、重現步驟、以範例證明來源等等。
第 3 級：目標驅動的自主性（Goal-Driven Autonomy）
代理會不計一切代價達成一個目標，只有當某個條件被滿足時才會停止。 在提示模式中，這意味著提示本身就成了目標（例如：「你能將這個網頁的可互動時間（Time-to-Interactive）降低到 1 秒以下嗎？」）。在 Codex 中，這是目標模式（Goal mode）：代理會循環執行「計劃 -> 行動 -> 測試 -> 審查」步驟，直到它不再滿足成功條件。在 Claude Code 中，這是 /goal、/loop 和 /schedule 命令。要使這個層級有用，停止條件必須能以可自動化的方式進行測量。
不要讓你的代理處理模糊、寬泛的目標，例如「改善整體用戶體驗」或「讓程式碼庫更容易測試」。選擇一些具體、可測量且可自動化的目標：找出生產環境中靜態分析未能發現的錯誤、減少載入時間、確保我們有一個嚴格的 TypeScript 建置且沒有任何 any 型別、分類所有依賴項以只保留我們理解且通過測試的那些，等等。最後，為了在生產環境中找出錯誤，代理需要處於一個類似生產環境的環境中。
第 4 級：平行委派（Parallel Delegation）
跨多個代理平行工作。 每個代理都處理任務的一個隔離切片。這個層級最大的瓶頸是「分解」：定義出要委派的正確切片。支援工具包括：子代理、背景會話、/batch、工作目錄（worktrees）、代理團隊等。失敗模式是「虛假平行」：同時在多個重疊的切片上運行多個代理，結果不是完成更多工作，而是產生合併衝突和重複決策。要做好這一點，代理之間需要相互隔離，各自擁有自己的檔案和狀態。每個代理也需要有自己的審查佇列。最後，每個代理都會產生成本——就消耗的 token 而言——與同時運行的代理數量成正比。在人類方面，「編排稅」使得在幾個代理之後，增加一個代理的邊際成本會上升。
第 5 級：例外管理式編排（Managed-by-Exception Orchestration）
定義成功長怎樣，以及應該適用哪些策略。 一個管理者代理會根據觸發條件（例如新 issue、新任務、時鐘）喚醒，分派工作者代理，監控它們的進度，驗證輸出，在失敗時重試，在條件滿足時升級給更有能力的代理或人類，彙總結果，並最終將工作成果（例如 PR）和證據回送給外部系統。想像一個工廠：issue 追蹤器或待辦事項清單是輸入，工廠的產出就是產品（即許多已修復的 issue、錯誤）。代理在一個有適當隔離、充滿圍牆（以及必要的逃脫艙）的環境中工作，只有一個由管理者代理定義的「作業系統」，來規定工廠應該做什麼。
這個作業系統的設計留給了人類；OpenAI 已經為 Symphony 提出了一個規範，其核心是一個 Linear 專案：每個 issue 都會獲得自己的代理工作空間，代理會持續確保它朝著其工作空間中一個規範檔案（spec file）所定義的目標前進。人類審查可以在產生證據的層面上進行，但前沿（即在編排世界中最強大的部分）是建立擁有數百甚至數千個代理的持續運作代理工廠。在攀登的這個階段，擁有獨立驗證變得越來越重要：分開的實作者和審查者、分開的測試執行者和 QA、分開的安全檢查、分開的驗收流程關卡。
風險與可逆性設定了天花板
我記得讀過一項較早的 Anthropic 研究，內容是關於 Claude Code 的一些最困難任務，其中它請求澄清的次數是用戶打斷次數的兩倍以上。經驗豐富的用戶（約 750 個會話 vs 少於 50 個）更傾向於自動批准和打斷，同時持續關注進度。
他們還對人們如何使用 Claude Code 做了更廣泛的分析。他們研究了 2025 年 10 月到 2026 年 4 月期間，來自約 23.5 萬人的約 40 萬次會話。從每次會話中，他們可以推斷出人們做出的決策，例如在每個提示中要求多少個動作、選擇自動批准哪些動作、多常打斷等。人們做出了約 70% 的規劃決策，但 Claude 執行了約 80% 的工作。高自主性並非將人排除在外，而是從讓他們執行每一步，轉變為讓他們決定下一步的方向。
如果我們想判斷一個大型 AI 系統是否以高自主性運行，我們應該問三個問題：
- 我們需要多快才能發現自己對它正在做的事情判斷錯誤？
- 我們能多乾淨地撤銷它正在做的事情？
- 有什麼證據可以證明我們對它正在做的事情是正確的？
如果這三個問題的答案分別是：不很快、極其困難、以及只能相信摘要，那麼這就不是高自主性。
每次運行代理之前，都應該先有一份合約來定義它試圖完成什麼。
- 目標：我們想要實現的成果（不是活動，不是技術，而是結果）。
- 範圍：我們運作在什麼領域，以及允許使用哪些技術。
- 非目標：什麼不屬於目標範圍。
- 工具與權限：代理如何與世界互動。
- 停止條件：何時停止；理想情況下是一個可測量的變數。
- 證據：可用來確認某事已完成（獨立於代理）的特定測試、螢幕截圖、日誌、資料庫記錄或其他指標。
- 升級：在什麼情況下讓誰介入（包括誰來運行代理）。
- 預算：對花費在任務上的時間、精力和 token 數量的限制（token 是大型 AI 模型的預算；你也可以包含對嘗試任務次數的限制，以及對平行程度的限制）。
指標讓自主性更可靠一些
事後才決定指標可能是不夠的。指標可以預先設定，放在一份簡潔的文件中。這會讓自主性感覺更可靠，也讓相信的這一步更容易跨出。
雖然衡量成功的方法有很多種，但可以考慮針對每個自主性層級追蹤以下指標的一些版本：
- 平均干預間隔時間
- 最長成功無人值守且工作被接受的運行時間
- 在沙盒中運行的動作與被升級的動作的比例
- 自動批准與拒絕的動作百分比
- 平均每個人類指令產生的代理動作數量
- 澄清請求率 / 中斷請求率
- 每個被接受的變更所需的審查時間
- 每個信心層級上的返工率
- 每個信心層級上的缺陷逃逸率
- 每個被接受的變更的 token 成本
這些指標可以講述一個故事：一個靠人類交接來保持忙碌的單一代理，加上儀表板，就是第 4 級。一個保守的代理，沒有自動化接收、重試機制和可靠的證據就不願繼續，就是帶有真正閘門的第 5 級。
思考準備就緒程度
根據風險和撤銷的容易程度來分類工作。保守地應用自主性，只有在支持更高層級的證據累積足夠時才提升。一個受強測試和審查代理保護、並有乾淨回滾路徑的支付引擎重構任務，可以支持比一個缺乏任何權威真相來源的文件自動化任務高得多的自主性。自主性層級應該跟隨驗證流程，而不是任務名稱。
四個反模式
每個系統都容易陷入以下四種自主性反模式，除非保持警惕避免。
自主性作為地位象徵 - 代理的自主性評級變成了一個無意義的象徵地位。更高的自主性被視為能力的證明，而非安全的證明，代理以超出驗證支持的程度在運轉。修正方法：表揚和獎勵那些設定正確自主性層級並堅決避免越界的人。
權限洗白 - 批准疲勞的暴政導致我們授予 AI 代理和工具遠比必要更廣泛的存取權限。修正方法：更好的邊界總是一種解決方案，例如使用沙盒設定檔、限定可寫入根目錄、白名單命令、鉤子和 Auto-review。
摘要替代 - 假設代理的工作摘要足以取代人工審查。修正方法：如同進行完整人工審查一樣，附上相同的證據包（包括 diff、測試、日誌、螢幕截圖、審查者發現、風險、落差等），同時避免認知投降。
艦隊角色扮演 - 幾十個代理平行運行，但人類仍然手動協調每一個依賴關係。修正方法：共享狀態、所有權規則和更好的依賴關係追蹤，逐漸減少手動協調的需求。較小的進行中工作（WIP）限制會強制專注於編碼和記錄協調步驟，直到編排自動化為止。
一個校準練習
回顧你最近在代理協助下進行的十項任務。針對每個任務，記錄：所使用的自主性層級、涉及的風險、工作可被撤銷的容易程度、為滿足驗證要求而產生的證據、審查時間、是否需要任何返工，以及下次選擇的自主性層級是否仍然合適。
如何安全地攀登
一次只在一個軸線上移動。先從一個受監督的單一代理開始，處理一個有邊界的單一任務，並產生可防禦的成功證據（如果夠整潔，就是自主性層級 1）。然後逐漸在三個正交方向上進行擴展。將以讀取為主的探索任務平行化（自主性層級 4）。添加在具有受限檔案所有權規則的獨立工作目錄上運行的寫入代理（自主性層級 4）。添加週期性自動化，然後是代理主導的、基於 issue、語音等觸發的編排。槓桿的每一步提升都需要一套新的安全機制（例如新的失敗模式）。
認識它們：較長時間的單一代理運行可能導致偏離方向、上下文腐化、溝通中斷或目標偏移。背景工作可能導致陳舊的假設和薄弱的工作交接。過多的平行工作可能導致合併衝突或重複決策。過多的週期性工作可能導致靜默的 token 消耗或陳舊的提示。例外管理可能導致漫長的審查佇列和警報疲勞。修正方法不是更努力地信任；相反地，應該縮小範圍、確保更好的證據、啟用更便宜的回滾路徑、強化關卡，並定義更清晰的所有權規則。
使用自主性層級：
- 第 0 級最適合精密的工作，以及當判斷仍在形成時。
- 第 1 級最適合大多數探索性工作，如果工作在眾所周知的邊界附近進行。
- 第 2 級最適合大多數有邊界的任務，要知道可能存在未知的依賴和不可預見的陷阱。
- 第 3 級最適合成功條件可以足夠清楚陳述的情況。
- 第 4 級最適合工作可以根據這些成功條件乾淨地分割的情況。
- 第 5 級最適合跨這些不同成功條件所需的協調和溝通已被完全編碼的情況。
驗證將永遠是瓶頸。
儘管目前有些自負的言論和現有工具，一個工程團隊使用 AI 代理的成熟姿態是 校準過的自主性。
瓶頸在於協調、驗證、維護、產品判斷和事故學習。
在不久的將來，我們會想要設計出知道何時工作、何時驗證、何時提問的循環——但工程師的技能仍將體現在選擇正確的自主性層級，以及建立能防禦其陰暗面的模式和可防禦證據上。
備註：Pangram 將本文標記為 100% 人類撰寫：[https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26](https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26)
