在過去一年間，關於 Agent 工程 的討論已經轉向 束具 (harnesses) 與 循環 (loops)、艦隊 (fleets) 與軟體工廠。我個人的看法是，工程師需要掌握外部循環——也就是這些系統的責任歸屬。隨著 Fable 和 GPT-5.6 等強大模型問世，這個原則只會變得更加重要。
Agent 具有槓桿效應，而槓桿效應會帶來義務。必須有人能夠清楚解釋：改變了什麼、為何是安全的，以及如果出錯會發生什麼事。 否則，這些行動就無法被合理正當化。這也使得組織一開始就不太可能要求引入它們。
因此，我想要討論三個術語。第一個是品質，指的是我們在讓系統運作之前所安裝的所有檢查機制。這些檢查會產出證據，而根據這些證據，我們可以推導出一個裁決。
第二個是裁決，指的是在我們的工作進入依賴系統之前所做的最終決定：我是這份內容的生產線負責人。我領導的團隊所產出的工作，都掛在我的名下。模型或許可以撰寫內容，但裁決權在我手上。沒有我的決定，我團隊的工作就不能進入我們的依賴系統。裁決是一種生產決策：我們應該發布、攔截、轉向、縮小回應範圍、增加護欄，還是直接拒絕？
第三個是可答責性，指的是如果有人提出質疑，我能夠解釋原因的保證。
換句話說，我們的 Agent（我將其定義為模型加上檔案、工具、記憶、技能、沙盒、權限、可觀測性及復原機制的束具）是執行我們循環（我將其定義為調查、實作、驗證，然後重複）的主體。而它也創造了我們的軟體工廠。
模型只是引擎。而束具——包含工具、記憶、權限、沙盒、測試——是你圍繞引擎打造的車輛，讓它能夠安全地執行實際工作。
將這個束具包裹在一個可重複的循環中：調查、實作、驗證、重複。這個循環讓一次成功的運行，轉變為一個你可以信賴並重複執行的流程。將束具包裹在一個可重複的循環中——調查、實作、驗證、重複——並由獨立的檢查（而非模型自己的說詞）來決定工作是否完成。
現在，同時運行許多個循環。一個工廠就是大規模運行的循環——Agent 在內部完成工作，而人類則在邊界地帶掌握決策權。
而這個工廠的核心，是系統內部與系統外部之間一條審慎的界線。 系統內部：我們收集輸入（來自產品團隊的意圖、先前已發布工作的知識、近期事件的資訊，或使用者的具體回饋）。Agent 循環會調查任務、實作計畫、驗證結果。然後，證據會穿越這條界線。一個掌握著依賴系統的人類，在看到證據後，決定是否繼續進行。
而這，朋友們，就是我們正努力推動的轉變。過去，我們的 Agent 是在執行循環的內部子循環中工作。現在，它們執行的是整個內部執行循環。工程師則掌握外部循環。
在系統內部，我們的 Agent 實際上只做一類事情：能力。也就是調查任務、實作計畫、測試結果並回報的能力。那是模型的能力。而我們說過，那個未來已經到來。
在系統外部，也同樣只有一類事情：自主能動性。也就是決定、驗證、批准與承擔的自主能動性。
你看，我們談的仍然是程式碼。只是它需要存在於一個被妥善管理的地方，並由懂行的人來執行。
AI 程式碼的潛力已不再是邊緣話題。在 Sonar 2026 年的一項調查中，我們詢問了團隊關於由 AI 輔助的提交所佔比例。這個比例雖然不高，但已不容忽視。而且有幾位受訪者表示，他們預期 AI 輔助提交的比例將會大幅成長。Sonar 的《2026 年程式碼狀況報告》發現，有 42% 的已提交程式碼是 AI 生成或顯著由 AI 輔助的，而且他們預期這個比例會持續成長，而非趨於平緩。
換句話說，創造正在變得越來越便宜。而更稀缺的資源則是審查、驗證、理解和維護。
我們讓生成速度的提升，遠遠快於我們對控制速度的提升。因此，我們產生了信任驗證的鴻溝。許多我們交流過的人，仍然對 AI 程式碼表達了一定程度的不信任。然而，似乎較少有人能持續地將這種不信任，建構成他們的驗證流程。
這是一個危險的處境。我們將會需要更便宜、更清晰的方式來驗證 AI 程式碼的可信度。
如果你看看 GitLab 2026 年 6 月的報告，你會發現治理問題已經轉變。GitLab 2026 年 6 月的 AI 責任研究顯示，審查和驗證是當前使用 AI 時的瓶頸，而更令人擔憂的是，治理通常發生在程式碼創建之後，在我們已經接受了風險並失去了對所有權的控制之後。如今，問題不僅在於控制。更關乎我們對系統設定了哪些限制。關乎我們將如何用證據來檢查工作，以及如何讓團隊負起責任。關乎誰將擁有 AI 生命週期的哪個部分。
所以，本系列文章的最後一個區別，在於流程與品質之間。品質是「反壓力」的概念。我們是從字面上理解它的。我們不希望賦予 Agent 它們所能行使的最大自主權。 我們希望賦予它們剛好足夠的自主權，使我們擁有足夠的反壓力來阻止它們、規範它們、檢查它們的工作，並確保我們的人性價值。
一般的工程作業會發出許多訊號，用來指示正在進行的工作是否在正軌上。例如型別檢查、測試、鉤子、沙盒限制、稽核日誌、監控器。我們的工程系統充滿了這類訊號，而它們的設計目的就是提供足夠的反壓力，以維持系統的誠實運作。
因此，只要我們的 Agent 也發出同樣的訊號，我們就可以信任一般的工程機制能提供適當的反壓力。
信任我們的系統，並不代表我們不希望有人在循環中參與。 這只代表人類不需要在內部循環中。我們希望他們在限制循環（我們該設定什麼輸入、架構、指令或不變量？）、取樣循環（我們該取樣和審查多少輸出？）、稽核循環（我們該保留哪些證據，以及如何確保稽核日誌有效？）以及所有權循環（我們該掌握生產邊界的哪個部分？）中。
但人類不需要在內部循環中。
Agent 所交付的成果，可能遠超過你能審查的量。
而稀缺的資源，是你自己核心的人類判斷力，並輔以來自日誌或測試等品質訊號。
AI 2026 年 6 月的報告顯示，在實驗環境中，針對小時級時間跨度的 Agent 委派，基本上已經實現。OpenAI 今年關於 Agent 與未來工作的研究 為這些想法提供了絕佳的來源。因此，我們需要開始思考如何建立這個所有權邊界，因為我們的系統開始交付超過我們所能審查的成果。
而這就是可答責性發揮作用的地方。
因為對於長週期 Agent 來說，在小時級時間跨度內做出的決定，本質上就是決定。而且並非所有決定都會被記錄下來。你無法將它們全部追溯回輸入的 token。如果你所做的只是相信你所得到的輸出是針對當前問題的正確選擇，那麼你將需要花費數百甚至數千小時的人力來重構導致該輸出的決策鏈，而這幾乎是不可能的。因此，再次強調，可答責性必須成為我們系統設計的核心。
三項隱藏成本
這裡有三項隱藏成本：
認知投降 ~ 盲目接受 AI 給你的一切。 當你將工作委派給 Agent 時，這項工作本身看起來可能是 Agent 的工作。但實際上，它是你的工作。關乎你的聲譽。是你的責任。你的軟體承受了輸出中的缺陷。你的軟體需要被修改以反映那些輸出。因此，Agent 的輸出變成了你的答案。而隨之而來的是全部的責任。華頓商學院的研究 指出，當 AI 正確時，這沒什麼問題。但當 AI 錯誤時，情況就不妙了。當 AI 出錯時，仍有近四分之三的人接受了它的結果，而且他們的信心甚至比沒有 AI 時還高。
認知負債 ~ 侵蝕你對如何解決問題的理解和記憶。 當你將工作委派給 Agent，你就是在將所有的思考工作外包出去。雖然自己全面思考需要時間和精力，但在一個龐大的程式碼庫中思考，需要耗費你在試圖加速學習曲線時所無法取得的資源。因此，你得到的輸出，往往是你自己無法達到的。而 Agent 規劃的時間跨度越長，Agent 產生的程式碼與你對它的理解之間的差距就越大。這個差距會不斷複合。負債會不斷累積。而爬升學習曲線的成本會幾乎呈指數級增長。Anthropic 的一項隨機對照試驗 探討了依賴 AI 撰寫程式碼的工程師，是否與自己撰寫程式碼的工程師一樣理解那些程式碼。結論是令人沮喪的：在理解力測驗中，依賴 AI 的工程師得分比不依賴的工程師低了十七個百分點，分別是 50% 與 67%。
再者，還有編排稅 ~ 現在很容易啟動大量的 Agent，但你的認知頻寬無法以同樣的方式平行化。 引導你的 Agent 遠離最糟糕的行為、分類 Agent 產出的工作以找出需要你關注的部分、指揮它優先關注你重視的工作、在你讓它運行之前驗證你最重要的限制條件和最危險的假設……
所有這些都需要付出努力，而且無法自動化。
人類的判斷力無可取代。
老舊系統在這裡尤其危險，因為你需要稽核的系統行為，不在程式碼裡。它存在於那些「傷疤」之中。
解決方案？在架構決策中，將「注意力」列為優先事項。使用工作樹、範圍和證據，來減少你的初始計畫與從中衍生出來的工作之間的耦合。為了解決無法行動的步驟而設定時間盒。並且嚴格將軟體的變更設定為「選擇加入」的權限。
Alpha、衰減與品味：這是塑造跨領域職業生涯與表現的三個核心模式。
Alpha 是最高成就者在競爭中佔據的領先位置，當你正在執行你最高價值的遊戲行動時。衰減是每個人都透過重複和觀察他人而學到的既定模式（你可以把它們想像成高原期）。品味是我們能在 Alpha 中感知領先態勢，或在衰減中感知變化的最早跡象。它是我們在沒有任何證據顯示任何事情正在發生之前，就對即將到來的事物做出的判斷。Paul Graham 的觀點 是，當任何人都能創造任何東西時，選擇創造什麼就變得更加重要。而 Mitchell Hashimoto 的定義則是操作性的：在沒有任何客觀指標存在的情況下，做出高品質的定性判斷。從現在開始，品味驅動一切：Alpha 的轉變就是品味的改變。而衰減之所以消退，是因為我們開始品味到不同的東西。
下一步？將你的品味操作化。如何做？給它一個名字，反映你正試圖將什麼從邊緣系統提升到意識層面。透過評論和範例來練習它。讓它的基本原理變得清晰明確。
並且持續做出能為你的行業帶來最持久競爭優勢的動作。那是什麼？持續將邊界從單純執行任務，提升到教導它、系統化它、決定何時該執行它，以及擁有最終結果。
每個人都是開發者，但並非每個人都是工程師。當一個開發者擁抱更嚴謹的工作紀律時——包含徹底且邏輯合理的推理、考慮限制與取捨、辨識風險與暴露、以及實際的問責制——他便轉變成了工程師。
在未來，人們將離開工程領域的行政工作，並擁抱隨著工程變得更加嚴格而湧現的新角色。這些角色將從工藝精神中分離出來，但會明確每個人的職責。將會出現原型設計者、建構者、清掃者、發展者、維護者。
人類也同時掌握著系統另一端的邊界。在另一個方向上增加 Alpha：選擇什麼值得做、定義應該在什麼限制下進行、決定證據是否足夠以繼續進行，以及關懷最終結果。無論是一個團隊還是一百個團隊，這都是只有人類才能掌握的邊界。
問責制將擴展工廠。 就像注意力與品味一樣，問責制也是讓一切運作順暢的三個二元性之一。沒有問責制，就沒有規則。 無法應對質疑者。沒有取捨。沒有風險。沒有安全網。如果沒有人承擔決策的後果，那麼高自主能動性只會帶來混亂。
一個邊界的半衰期是一次發布，但一個署名 (signature) 的半衰期是一段職業生涯。署名是你的名字與工作掛鉤，使你覺得自己可以為所發布的成果負責。技能給你槓桿；問責制則將槓桿轉化為信任。
只有人能做出選擇。只有人能承擔後果。Agent 可以被要求在政策範圍內安全地選擇、路由、合併和升級問題，但它們無法承擔後果。
也許每個程式碼庫都應該附帶某種問責合約，明確說明：變更被接受時所理解的檢查清單、支撐決策的證據、誰對變更負責，以及變更被阻止後的系統狀態。就像這樣：
- 你的注意力與品味
- 你的證據、裁決與所有權
- 你的 Alpha、衰減與品味
高自主能動性
在典型的 Agent 工作流程中，高自主能動性是一門藝術，知道何時委派、何時檢查、何時停止，以及何時擁有流程的結果。自主能動性的階梯從低到高分別是：標記潛在問題、調查問題、執行解決方案、診斷問題、提出解決方案、建議修復方法，以及最終解決問題。在自主能動性階梯上的一個高層次是辨別力：發現了問題，但它不值得修復，繼續前進。
支撐軟體工廠的十二根支柱
老舊系統是希望擴大規模的工廠的前沿陣地。所有那些聰明的小創新現在可能感覺沒什麼，但生產環境的複雜度遠高於此。當建立一個全新的系統時，規劃和實施足夠的反壓力機制要容易得多，因為你擁有完全的控制權。然而，當你將智慧 Agent 加入一個遺留系統時，那就是另一回事了。
遺留系統包含了：完整的生產行為、客戶的未來期望、遷移歷史、發布與預算週期長度、未明言的假設、邊緣案例、資料異常、操作手冊程序，以及所有因缺乏維護意願而累積的「傷疤」。
要成為老舊系統的守護者，需要一種持久的工程能力。必須將隱性知識轉化為明確的限制、在團隊間和世代間保持其一致性、將這些知識形式化為測試程序和功能規格，並將知識與客觀證據連結起來。所有這一切，都要同時將失敗轉化為更多的學習。因為如果系統得不到它一直以來所得到的關照，一切都可能崩潰。
新工作是真實的工作
隨著規模擴大，工作會變得更加有趣。因為當其他一切都已建成，人們會想要建造新東西。 他們會想要運用他們透過工藝所發展出的 Alpha 和品味，來設計可以嫁接在軟體工廠上的新循環。或者他們會想要建造全新的系統，將軟體工廠的所有知識，運用於一個優雅、用意良善、且遵循原則的努力中。他們會想要設計和實作新形式的證據，以達到足以驗證新系統的標準。他們會想要維護那些現在已經複雜到需要專門關注的老舊系統。他們會想要設計和管理新的反壓力機制。他們會想要設計新的 Agent。他們會想要建立自主能動性。
而當他們這麼做的時候，他們會發現這一切都是真實的工作。這是一件好事。
自動化創造了瓶頸。這些是值得擁有的生產瓶頸。因為自動化給了我們工業規模的控制力。但工業規模也帶來了新的瓶頸。瓶頸從「我們能建造這個嗎？」轉移到了「這個東西應該存在嗎？我們能為它負責嗎？」
我所建議的，是一個實用的運作模型，用以擴展 Agent 工程。其中有內部循環和外部循環。內部循環是完成工作的地方。循環的設計要盡可能獨立。將所有品質保證和驗證都放在循環內部。一旦你設計並驗證了循環本身，你剩下要做的，就是透過建立一個反壓力機制來授予自主權，這個機制控制著循環運行的速率及其運作範圍。並將人類置於他們應有的位置，負責做出正確的決策。 不要把理解當作一個交接點或發布閘門，而要把它視為一個決策點，讓人類能夠提供他們的洞察。接著，對於每一個存在並被回饋到生產環境以及新團隊和工程師手中的工件，留下更好的工件。
建造工廠；維持運作；讓工作變得清晰可讀、可驗證、有人負責。
Agent 可以撰寫它。但在它到達使用者手中之前，必須有人解釋它為什麼應該存在，為什麼它足夠安全可以成為生產環境的一部分，以及當它出錯時他們會怎麼做。
這就是 Agent 工程在外部循環的體現——這就是現在的工作。
Pangram 已將本文評定為 100% 人類撰寫：https://www.pangram.com/history/ae6caccc-b70f-4336-a019-5c3411516871
