AI Agent 工程師的崛起

歷史總愛押韻，而且通常發生在我們最安逸的時候。

想像一下 90 年代末。如果你懂得如何馴服 HTML，再加上一點 Perl 或 PHP 弄出一個能運作的網站，那你簡直就是個巫師。你是網頁工程師，整個世界都在你的掌握之中。你正在打造網際網路的店面。

快轉到 2009 年。iPhone 剛剛敲開了新世界的大門。突然間，沒人那麼在乎你的靜態網站了。能量轉移到了 Objective-C 和 Java 上。如果你是行動 App 工程師，你就是在編寫未來。你正在打造人們口袋裡的工具。

現在，看看 2024 年。空氣再次變得稀薄且停滯。App Store 已經飽和；Web 領域擁擠不堪。但在表層之下，一場地殼變動正在發生。我們正在離開「介面 (Interface)」的時代，進入「代理人 (Agent)」的時代。

在接下來的十年裡，最有價值的頭銜將不再是「全端工程師」或「iOS 工程師」，而是 AI Agent 工程師。

新的地殼變動

這不僅僅是另一場框架戰爭，也不是要學習一門新的程式語言。這是關於誰在做這項工作的根本性改變。

在過去的二十年裡，軟體工程是關於為人類建立清晰、確定性的路徑來點擊。你做一個按鈕；人類點擊它；程式碼執行一個函式。人類是大腦；軟體是肌肉。

這種動態正在翻轉。

在 Agent 時代，軟體提供大腦。你的工作不再是為人類建立可點擊的按鈕。你的工作是建立一個數位員工，由它來決定何時點擊按鈕，或者更好的是，它能發現根本不需要那個按鈕。

我開發產品已經超過十年了，我能感覺到腳下的地面正在移動。如果你今天能寫出一個 Agent——一個為你服務、自動化你的工作流程或服務你的客戶的 Agent——你就擁有了和 1999 年那個剛學會如何把生意搬上網的小子一樣的槓桿。

但這裡有個殘酷的事實：如果你拒絕學習這個，如果你堅持只寫純粹確定性的程式碼，你就有可能成為桌上出版時代的排字工人。

解密魔法：工具 (Tools) 與語境 (Context)

當人們聽到 "AI Agent" 時，他們會想像「天網 (Skynet)」或是某種極其複雜的神經網路架構。讓我們撥開這些雜訊。

打造 Agent 不是魔法，它是工程。歸根結底就是兩件事：工具 (Tools) 和 語境 (Context)。

我發現大多數開發者把這件事想得太複雜了。他們以為需要訓練模型。其實你不需要。Claude、GPT-4、Llama 這些模型已經夠聰明了。你的工作是賦予它們雙手和記憶。

1. 工具（賦予模型雙手）

大型語言模型 (LLM) 就像是一個「缸中之腦」。它能思考，但無法觸碰世界。「Agent」簡單來說，就是一個被賦予了 API 端點或 CLI 指令權限的 LLM。

你告訴模型：「這裡有個工具叫 list_files。這裡有個工具叫 read_file。這裡有個工具叫 send_email。」

2. 語境（賦予模型方向）

接著你定義角色。「你是一位資深 QA 工程師。你的目標是修復這個儲存庫 (repository) 中的型別錯誤。」

就這樣。這就是核心迴圈。

如果你用過 Cursor 或 Claude Code，你就已經見過這種運作模式。你不需要微觀管理每一次編輯。你只說：「修復 utils.ts 裡的型別錯誤。」

Agent 會思考：好的，我需要先看看檔案。 它決定使用 ls 工具。然後它決定使用 grep 或 read。它發現了錯誤。它決定編寫修復程式碼。它執行編譯器來檢查它的工作。

這就是突破點。這不再只是「聊天」了。這是一個決策迴圈。模型正在選擇拿起哪些工具來解決你交給它的問題。

從聊天機器人到決策引擎

過去兩年，我們一直卡在「聊天 (Chat)」階段。我們把 AI 當作聰明的圖書館員——我們問問題，它給答案。

那個階段正在結束。

Agent 階段是關於執行 (Execution)。這意味著將 CLI (命令列介面) 不再視為你打字的地方，而是模型的遊樂場。

想想這對新創公司意味著什麼。過去，如果我想建立一個處理客戶退款的服務，我需要建立 UI、後端、資料庫，並僱用一個客服團隊來點擊按鈕。

今天，我可以寫一個 Agent。我給它 Stripe API 的存取權限（工具）和我們的電子郵件歷史記錄（語境）。我給它一個策略：「如果用戶在 7 天內不滿意，就退款。」Agent 讀取進來的郵件，決定是否符合標準，觸發 Stripe 退款工具，並起草回覆。

不需要 UI。不需要客服工單佇列。只有一個目標和一組工具。

打造 Agent 的「混亂過渡期」

我不想在這裡描繪一個烏托邦。過去六個月我一直在 Agent 開發的戰壕裡深耕，讓我告訴你：這真的很混亂。

傳統程式碼是邏輯的。If X then Y。它要嘛成功，要嘛崩潰。

Agent 工程是機率性的 (Probabilistic)。你建立了 Agent，給了它工具，有時候它會決定用鐵鎚來開窗戶。有時候它會幻想出一個不存在的參數。

這正是新技能的所在。

成為一名 AI Agent 工程師不僅僅是寫 Python 腳本。它是關於：

• 提示工程即架構 (Prompt Engineering as Architecture)：設計系統提示詞 (System Prompts) 來約束模型的行為。
• 評估驅動開發 (Eval Driven Development)：你無法為「創造力」編寫單元測試，所以你需要建立評估流程 (Evaluation pipelines) 來衡量 Agent 完成任務的成功率。
• 工具設計 (Tool Design)：建立足夠「乾淨」的 API 介面，讓模型能夠理解而不會感到困惑。

我看過 Agent 陷入無窮迴圈，試圖修復它們自己製造的 bug。我看過它們自信地刪除了錯誤的檔案。這就是現實。但解決這些摩擦點，正是價值創造的地方。

實戰建議：今天如何開始

如果我今天從零開始，或者想要轉換職涯跑道，這是我會做的事：

1. 停止開發 GUI：至少在你的 Side Project 上試試。試著在沒有前端的情況下解決問題。你能只用 CLI 和 LLM 解決它嗎？
2. 學習介面協定：了解 OpenAI 的 Function Calling 或 Anthropic 的 Tool Use 是如何運作的。這是 Agent 時代的 TCP/IP。
3. 做一個「實幹家」而不是「空談者」：不要建立一個只會回答你行事曆問題的機器人。建立一個能管理你行事曆的機器人。賦予它刪除事件的能力。去感受賦予 AI 寫入權限時的那種恐懼感。那才是你真正開始學習的時候。
4. 精通語境管理：學習如何將正確的資訊塞進 Context Window (語境視窗) 而不讓它溢出。RAG (檢索增強生成) 僅僅是個開始。

前方的機會

我們正望向一個未來：一個單打獨鬥的開發者，裝備著一支專門的 Agent 艦隊，可以完成一家 20 人新創公司的工作。

創造的門檻正在降至零。但編排 (Orchestration) 的門檻——即理解如何將這些大腦串聯起來——正在成為新的護城河。

十年前，你被僱用來寫程式碼。 今天，你被僱用來架構那個「寫程式碼的系統」。

列車正要駛離車站。你可以選擇站在月台上緊抓著你的舊框架不放，或者跳上車，幫助鋪設軌道。

讓我們開始打造吧。