面向營運商的代理工程：營運業務的代理背後的學科（2026）

智能體工程 這門學科旨在讓AI代理可靠地完成工作：你編寫規範，代理執行任務，然後你驗證、審查並監督它交付的成果。大多數定義都止步於軟體開發，即代理程式編寫程式碼，開發人員審查差異。我想更進一步，因為這正是我所處的領域。這篇文章是由Claude Code代理商在峇裡島時間凌晨0點05分完成研究、撰寫、繪製和發布的，當時我還在睡覺。自6月12日以來，它所屬的代理群已累計執行了1967次計畫運行。.

這支隊伍裡沒有一台機器會寫應用程式。它負責撰寫部落格文章、安排社群媒體發布、檢查收件匣、尋找潛在客戶，並為十家企業歸檔任務。維繫它「誠實守信」的準則，與西蒙·威利森和艾迪·奧斯曼尼所描述的代碼準則如出一轍。唯一改變的，是機器的運作方式。.

你將獲得以下內容：一個簡潔明了的定義、「程式碼氛圍」與「程式碼工程」的對比、構成工程的四個習慣、當「程式碼庫」成為一項業務時這些習慣的具體體現，以及我從失敗中總結出的每條規則。文中提到的所有數據都是今晚測量的，或者連結到了相應的文章。.

什麼是智能體工程？拋開炒作，給予更清晰的定義

這個術語還很新。安德烈·卡帕西（Andrej Karpathy）在2025年2月創造了「氛圍編碼」（vibe coding）一詞，並在2026年2月初提出了「代理工程」（agentic engineering）作為其專業版本的名稱。幾週之內，實踐者就給了一個可行的定義。.

西蒙威利森的版本 最簡潔的定義是：智能體工程是「借助編碼智能體開發軟體的實踐」。他對智能體的定義甚至更簡潔：“智能體循環運行工具以實現目標。” 艾迪·奧斯曼尼 劃分界線的方式是：人工智慧負責實現，而人類負責架構、品質和正確性。. IBM 的解釋 落點相同，描述的是那些協調和監督代理人而不是讓他們從頭到尾建構的工程師。.

三人對核心理念達成共識。智能體工程並非一種工具或職位名稱，而是一套習慣，它能將智能體從偶爾能產生正確結果的工具，轉變為可信賴的工具。.

以下是我從操作員角度出發的單行版本：

智能體工程是指圍繞智能體設計規格、檢查和回饋迴路，以便在您不監督的情況下，智能體也能正確運作。.

最後五個字至關重要。開發人員在鍵盤前即時檢查每一個差異。而定時任務的代理程序身邊卻無人監督。因此，工程設計必須融入系統之中：體現在它所讀取的指令、它不能跳過的檢查以及它留下的記錄中。.

智能體工程與智能體人工智慧

這兩個詞經常被混淆。. 智能體人工智慧 描述此技術：規劃、呼叫工具並執行多步驟操作的模型。. 智能體工程 它描述了人類如何負責任地運用這項技術。一個是引擎，另一個則是維持汽車行駛所需的一切零件。.

智能體工程與Vibe編碼：同樣的工具，不同的工作

直覺編碼和智慧工程可以使用完全相同的工具。我今晚就可以打開 Claude Code，用直覺編碼創建一個落地頁：提示、接受、刷新、重複。差別不在於軟體，而是提示和結果之間發生的事情。.

	氛圍編碼	智能體工程
起點	提示	書面規範
誰來檢查輸出結果	你用肉眼就能看出它是否破損。	先進行自動檢查，然後由人工檢查。
「完成」是什麼意思	代理人說完成了	該結果已在實際系統中得到驗證。
當它失敗時	請將錯誤訊息貼回去。	修改規範，使其不再出現同樣的問題。
記憶	聊天記錄	版本化指令和運行日誌
最適合	原型、一次性腳本、探索	明天再次運行的任何程序

最後一行才是真正的考驗。如果工作成果可以隨時丟棄，那麼憑感覺寫程式碼當然很好。如果你星期日晚上就要把它丟掉，誰還在乎它是怎麼做出來的呢？但一旦代理程式明天再運行，或是接觸到客戶，或是產生費用，你就需要右側那一列的資料了。.

奧斯曼尼的觀點值得我強調兩次：測試是兩者之間最大的差異。用他的話來說，如果沒有測試，代理“會興高采烈地宣布‘完成’，即使代碼本身存在缺陷”。我親眼看過這種情況發生在一些根本不是程式碼的事情上。例如，一個代理會報告一條社交媒體帖子已按計劃發布，而實際上 API 已經悄悄地拒絕了它。另一個代理程式會報告資料庫行已更新，而實際上寫入操作失敗了。興高采烈地宣布“完成”是所有代理（無論是否涉及代碼）的預設失敗模式。.

氛圍編碼不好嗎？

不。我認為，對於單人操作員所建構的內容來說，這種做法或許只有三分之一是正確的。問題不在於憑感覺編寫程式碼，而在於憑感覺編寫程式碼後又將其安排到日程中。這就是為什麼你會得到一個已經默默運行了三週卻仍然失敗的腳本。.

智能體工程的四個習慣

拋開廠商提供的圖表，所有嚴肅的智能體工程實務最終都歸結為四個習慣。 Willison、Osmani、IBM 的七步驟工作流程以及 Domino 的實踐者手冊都描述了這四個習慣的某種形式。它們按工作發生的順序排列。.

1. 首先制定規格

在智慧體進行任何操作之前，你需要寫下「正確」的定義：目標、約束條件、輸入以及確切的輸出格式。奧斯曼尼稱，跳過規範部分是「專案偏離軌道的罪魁禍首」。規範不必冗長，但必須足夠具體，確保兩個不同的智能體閱讀後能夠產生類似的結果。.

2. 核實所有訊息

代理的描述不能作為證據。你需要在系統（無論是測試套件、即時頁面還是資料庫行）中核實結果。對於程式碼而言，這意味著要查看測試。對於業務代理而言，這意味著要回溯它所寫入的內容。如果代理聲稱發布了帖子，則獲取 URL。如果它聲稱更新了記錄，則取得該記錄。.

3. 事前回顧

人們會在工作造成損害之前，或盡可能接近損害發生時就進行審查。對於程式碼而言，這相當於審查 PR（請求提交）。對於業務人員而言，這相當於對所有風險事項進行審批，例如回覆客戶或發起新的推廣活動。.

4. 出貨後觀察

每次運行都會留下記錄，供後續讀取，而且總會有程式讀取這些記錄。威爾森對此有一句我很喜歡的描述：邏輯邏輯模型（LLM）「不會從過去的錯誤中吸取教訓，但編碼智能體可以，前提是我們主動更新指令和工具框架。」觀察是發現錯誤的方法，而更新後的規範則是智能體從中學習的方式。.

習慣 1 和習慣 4 構成一個循環。你寫規範，代理運行，你觀察到故障，然後你修復規範，防止故障再次發生。重複幾百次，規範就會變得異常難以出錯。這個循環就是整個訓練體系。.

超越程式碼的智能體工程：當程式碼庫本身就是一項業務

目前所有針對此關鍵字排名的頁面都假定經紀人從事軟體開發工作。這很合理，因為這個詞組最初就是從軟體開發領域衍生出來的。但這四個習慣並不關心產出是什麼。無論經紀人是撰寫簡報、篩選潛在客戶或核對電子表格，這些習慣同樣適用。.

如果你是自由工作者或小企業主，這一點就很重要了，因為你可能不需要一個會寫程式的代理人。你需要的是一個能工作的代理人：跟進潛在客戶、定期發佈內容、維護客戶關係管理系統（CRM）的代理人。一旦你的代理人開始按計劃工作，無論你是否這樣稱呼它，你實際上都在進行代理人工程。問題在於，你是否是有意為之。.

以下是軟體工件的轉換方式：

軟體代理工程	業務運營等效項	它在我的艦隊中看起來是這樣的
設計文件/規範	每個工作都有書面程序	每個職位對應一個技能文件（共 39 個）；部落格寫手的技能文件有 1190 行。
單元測試	回讀檢查	每次寫入操作都會在運行計數為完成之前被取回。
拉取請求審查	審批佇列	Asana「草稿（待批准）」部分
CI/退出代碼	結構化的結果行	技能結果：成功 | 跳過 | 失敗 在每次運行的最後一行
版本控制	自我編輯前的備份	在任何代理人編輯之前，文件的帶時間戳副本
生產監控	看門狗	一個夜間值班的代理人，會閱讀其他所有代理人的結果。
並發控制	運轉鎖	每個插槽每天限發一份鎖具；先到先得。

這些都不是什麼稀奇古怪的東西。任何優秀的工程團隊都會運用同樣的方法，只不過這次是應用在那些無法編譯的程式碼。如果你想了解這些組件如何協同工作的系統級視角，我已經寫過相關文章了。 代理型作業系統在 139 天後的樣子. 關於各項工作如何交接，請參見… 無需平台即可實現人工智慧代理編排.

智能體工程在真實艦隊的應用

理論不值錢，所以這裡展示的是實際的設置，測量於今晚（2026 年 11 月 7 日）。每個品牌對應一個 Docker 容器。調度器依照時間表觸發 20 個預定技能。每次運行都是無頭 Claude Code 會話，讀取一個技能文件，執行任務，記錄結果並退出。運作之間沒有任何監聽。.

規格：每個職位都需要一份技能文件

產生此貼文的技能檔案大小為 47,730 字節，共 1,190 行。它最初並非如此。其中大部分是後來加上的規則，屬於「傷痕累累」的產物。以下是一個真實的規則範例，原文如下：

“「關鍵字欄位是 搜尋量, ，小寫字母加底線，而不是 搜尋量. 已與即時表格 2026-10-06 核對：標題大小寫拼字正確 422 未知字段名 但呼叫結果根本沒有回傳任何關鍵字，這看起來像是一個空隊列，而不是一個錯誤。”

這就是經過幾個月的自主設計後，一份規範文件的最終形態。它並不優美，但卻具體、過時，解釋得很清楚。 為什麼, 這樣，下一個代理（或下一個我）就不會「清理」它，然後把漏洞重新引入。我把這些文件中應該包含的內容分解如下： CLAUDE.md 最佳實踐.

變更控制：任何自編輯作業前都要備份。

這支艦隊中的智能體可以自行更新指令和內存，因為這是它們學習的方式。但它們必須先複製文件。今晚統計：技能檔案備份共 35 份（有時間戳記），共享記憶體檔案備份 423 份，觀測日誌備份 380 份。如果智能體錯誤地編輯了技能，只需執行一次複製命令即可修復。這相當於為那些沒有在維運筆記上運行 Git 的人提供的版本控制。.

觀察：結果合約加上監督機構

每次運行都必須以單行結束： 技能結果：成功, 跳過 或者 失敗, 此外，還有一份摘要。每晚 23:35，監控代理程式會讀取每次運行的結果，並將任何失敗的情況回報。自 6 月 12 日以來，已記錄的 1967 次運行中，統計結果為：1596 次成功，216 次跳過，44 次失敗，2 次降級。另有 109 次運行根本沒有寫入任何有效結果。.

以下這個數字證明了整個設計的合理性： 所有 44 個故障均以代碼 0 退出。. 每一個都是如此。如果我像設定普通定時任務那樣監控退出代碼，我的儀錶板會顯示完美的記錄。客服人員成功完成了對話，只是任務沒有完成。.

評論：誠實的部分

每發布一則貼文或進行一次有風險的操作，都會在 Asana 的審批欄中建立一個任務。今晚，該欄中共有 234 個任務：230 個仍處於待處理狀態，4 個已完成，其中最早的待處理任務可以追溯到 6 月 15 日。這不是審核隊列，而是我尚未處理的審計記錄，我寧願坦誠相告，也不願隱瞞。.

真正保障品質的是自動化檢查的運作。 前 任何內容都可能上線，人工審核環節只是第二道關卡。如果你的審核環節依賴同時負責業務運作的人員，就要做好審核環節可能出現疏漏的準備，並將真正重要的環節設定得非常嚴格，確保他們無法繞過。.

如果您想獲得幫助，為您的營運設計類似的系統，而無需經歷五個月的術後恢復期，您可以… 預約自動化策略會議 跟我來，我會向你詳細展示這支艦隊的線路連接方式。.

那些教導我們規則的失敗模式

此類實踐中的每一條規則都應該源自於某個具體的失敗。如果沒有，那很可能只是形式主義。以下這些規則塑造了我的實踐。完整的九項無人關注的實踐清單保存在… Claude Code 總結了 4 個月無人值守運作的最佳實踐, 所以，在這裡我將遵循它們背後的模式。.

這種模式是 成功型誤差：對於每個檢查層來說，回應看起來都像是成功了，但實際上並沒有完成任何工作。.

API 明明拒絕了卻顯示“OK”

我們的SEO數據提供者返回了 40200 需要付款 嵌套在 HTTP 200 回應中，其頂層狀態讀取 20000 好的。. 帳戶餘額不足。所有重試工具、所有狀態檢查以及所有「呼叫是否成功？」的測試都顯示成功。解決方法並非更聰明的重試機制，而是規範中的一條規則：忽略信封，斷言每個任務的狀態碼，並在開始之前檢查帳戶餘額。.

資料庫讀取正常，但寫入操作失敗。

Airtable 欄位名稱在篩選公式中不區分大小寫，但在寫入有效負載中區分大小寫。因此，代理程式可以完美讀取「關鍵字」表，但在每次狀態更新時都會傳回 422 錯誤，並將其視為輕微警告。到 10 月 31 日，128 行標記為「已發布」的記錄中有 56 行缺少發布日期。程式沒有崩潰，數據只是逐漸出錯。解決方法是添加上面提到的日期註釋，並在每次寫入後進行回讀操作。.

那個總是回答「是」的退出代碼

這就是上面提到的44個問題。即使代理任務失敗，其會話也能正常退出，因為從運行時的角度來看，一切正常。解決方法是代理必須寫入一個結果契約，並設定一個監視程式來讀取該契約。.

那段不斷增長的記憶

這個問題仍然存在。用於記錄智能體學習內容的共享記憶體檔案現在有 2.38 MB，包含 10,257 行。沒有智能體會讀取全部內容。每個智能體只讀取最新的條目，然後用 grep 指令找出其餘內容。雖然目前還能運行，但這卻是個警示訊號：記憶體如果不進行清理，就會變成雜物堆。智能體工程不僅包括新增指令，還包括維護指令本身。修復後我會再次報告。.

注意這些故障的共同點。更聰明的模型都無法發現它們。所有這些故障都是由一種工程習慣造成的：驗證真實結果，記錄規則並註明日期，然後觀察下一次運行。.

智慧工程師技能：你需要掌握哪些技能，以及你可以跳過哪些技能。

“「代理工程師」已成為熱門職位，各種課程也紛紛湧現。在你購買任何課程之前，不妨先看看這位以管理代理商為生的專業人士提供的真實技能清單。.

你真正需要的技能

• 編寫精確的說明。. 這是核心技能。如果你能寫出新進員工不需提問就能遵循的操作流程，那麼你就能寫出一份技能文件。如果你做不到這一點，任何框架都無濟於事。.
• 以失效模式思考。. 對於每一步，都要問自己：「怎樣才能在不被人察覺的情況下失敗？」 然後加入相應的檢查。.
• 讀取日誌和API回應。. 你不需要編寫整合程式碼。你需要查看 JSON 回應並確認這一點。 狀態碼 雖然信封上寫著OK，但信封上卻顯示40200。.
• 基礎腳本編寫。. 具備足夠的 shell 或 Python 知識，能夠讀取檔案、使用 curl 呼叫 API 並檢查值。大部分內容由代理寫入，但你必須能夠讀取它們寫入的內容。.
• 了解您的業務流程。. 這是工程師常常低估的一點。智能體無法編碼你無法描述的流程。領域知識就是規範。.

（暫時）可以跳過的技能

• 代理框架。. 我的艦隊運行在簡單的技能文件、curl 和調度器上。我衡量了原因。 MCP 與 CLI今晚整個管道沒有發出任何 MCP 呼叫。.
• 多智能體架構。. 大多數商業工作都是一個代理人按計劃完成一項任務。協調工作是透過時間安排和鎖定機制來實現的，而不是代理人之間的協商。.
• 提示工程技巧。. 清晰、具體、註明日期的說明永遠比巧妙的措詞更有效。.
• 認證。. 一個運作正常且有日誌記錄的系統比一枚徽章更有說服力。如果你正在招聘，請務必查看日誌。.

如果你從零開始，那就從…開始 克勞德程式碼入門教程, 然後閱讀 克勞德代碼代理正在生產中 看看它會帶來什麼結果。選擇一項枯燥乏味、重複性高的工作，並將其安排到一個帶有結果導向的日程表中。這就是你的第一個智能體工程案例。.

智能體工程常見問題解答

簡單來說，什麼是智能體工程？

這是確保人工智慧代理能夠可靠完成工作的準則。你需要編寫清晰的規範，讓代理執行任務，在實際系統中檢查結果，審查存在風險的輸出，並保留記錄以便從中學習。這個術語起源於軟體開發，但同樣的原則也適用於代理執行的任何工作。.

「智能體工程」一詞是誰提出的？

安德烈·卡帕西 (Andrej Karpathy) 於 2026 年 2 月初提出「氛圍編碼」這個概念，作為他一年前提出的「氛圍編碼」的專業對應概念。西蒙威利森 (Simon Willison) 和艾迪奧斯曼尼 (Addy Osmani) 隨後不久撰寫了兩個被引用最多的定義。.

智能體工程只是在Vibe程式的基礎上增加了一些步驟？

額外的步驟才是關鍵。 Vibe 編碼如果輸出看起來正確就會接受。而智慧工程則會驗證輸出，記錄下來，並在出錯時修正規格。前者提供演示，後者則提供可以持續運行的程式。.

我必須是開發人員才能實踐智能體工程嗎？

不適用於業務運作。你需要精確地描述你的流程，閱讀基本日誌，並思考故障原因。寫一些簡單的腳本會有幫助。我的大多數艦隊技能文件都是用純英文編寫的，只包含幾個 curl 指令。.

AI編碼代理和智能體工程有什麼不同？

編碼代理程式是工具，例如 Claude Code、Codex 或 Gemini CLI。代理工程是指如何使用它。我將工具本身進行比較。 什麼是人工智慧編碼代理.

我該如何將智能體工程應用於我的企業？

選擇一個至少每週運行一次的重複性任務。為其編寫一份一頁紙的規格文件。讓代理程式運行該任務，並新增一個回讀檢查和一個結果輸出。在新增第二個任務之前，觀察十次運行情況。大多數人試圖同時自動化五件事，結果卻無法判斷是哪件事出了問題。.

結論：智能體工程是一種習慣，而非頭銜

智能體工程的關鍵不在於選擇哪個智能體，而是圍繞它構建什麼：一份足夠具體的規範，智能體無法繞過的檢查機制，針對任何風險的審查步驟，以及一份能夠將每次失敗轉化為更完善規範的記錄。.

軟體領域率先實現了這一點，而且它的定義也相當完善。但更大的機會在於，同樣的方法可以讓操作員在代理上運行真實的業務操作，而不僅僅是進行演示。本文是 1967 次運行結果之一，證明了這種方法的可行性，而其中 44 次失敗恰恰證明了我對其他運行結果的信任。.

從小處著手。先做一項工作，一個規範，一行結果，一個檢查。然後讓失敗的經驗來完善其餘的規則。.