想轉型 Agent 工程師，Agent Engineering 值不值得優先學

Agent Engineering 到底補的是哪一類能力短板

很多開發者第一次接觸 Agent 時，覺得「不就是調 LLM API 嗎？最多加個 ReAct 迴圈」。但上線第一個生產級 Agent 後，才發現問題遠不止於模型呼叫。

先看一個真實場景：你想做一個程式碼審查 Agent，讓它讀取 PR diff、呼叫 Lint 工具並在倉庫評論區輸出結果。直覺方案是寫個 Python 腳本：用 OpenAI SDK 呼叫 gpt-4，把 diff 塞進 prompt，然後解析回傳值。原型 2 小時跑通，但放到團隊 PR 流程裡立刻出問題：Agent 呼叫 Lint 工具時語法分析結果和模型輸出格式衝突，它生成了錯誤註釋；工具返回超時後模型胡亂猜測導致代碼被誤合；權限上 Agent 可以訪問所有分支，把敏感分支的修改也審查了。

這些都不是「調模型」能解決的，而是 Agent Engineering 要涵蓋的典型問題：

工具與模型的互動邊界：Agent 呼叫外部工具（Linter、編譯器、Git API）時，輸入輸出必須嚴格驗證。模型「編造」的回傳值必須被拒絕，工具傳回的結構化資料不能直接餵給模型，否則會污染下一次決策。實際工程中，這需要在模型與工具之間增加一層 schema 驗證和錯誤重試邏輯，甚至為每個工具單獨寫入適配器。

上下文管理與 token 預算：Agent 的多輪互動會快速累積上下文。在程式碼審查場景中，每一輪對話包含 diff、工具輸出、模型思考鏈，3 輪後上下文可能會突破 32K。不加管理的 Agent 會遺失早期關鍵資訊（如 PR 說明），或因 token 超限而直接報錯。 Agent Engineering 要求開發者設計上下文壓縮策略：丟棄重複的中間推理、只保留最終工具輸出摘要、用 sliding window 裁剪歷史。

安全性與權限邊界：Agent 取得工具權限後，可能執行未授權的操作。上述例子中，Agent 能存取所有分支，屬於權限過寬。正確的做法是依照最小權限原則，為 Agent 分配只讀 token，限制其操作倉庫清單和白名單分支。甚至要在 Agent 執行寫入操作前再次確認。這些不是模型能自行判斷的，必須在工程層面強烈約束。

開發者轉型時最容易高估或低估的部分

高估的部分：模型的理解與糾錯能力

開發者容易覺得「模型很聰明，會給最適合的決策」。實際上 Agent 在工具使用上經常誤解工具輸出。例如 Lint 工具傳回 lint_error_count: 5，模型可能被理解為“有 5 個嚴重錯誤”，而實際上只是 5 個 warning。 Agent 也會在工具呼叫失敗時自行編造結果－逾時後模型自行想像一個回傳值（「成功」），導致後續邏輯出錯。這需要你為每個工具呼叫設計明確的輸入輸出 schema、逾時重試和異常處理。

低估的部分：情境管理與系統提示設計

很多人認為「prompt 寫清楚就行」。但 Agent 的上下文在多次工具呼叫後迅速膨脹，系統提示被淹沒在對話歷史中。沒有明確情境管理，Agent 會「忘記」最初的目標。例如程式碼審查 Agent，一開始專注於“檢查程式碼品質”，幾輪後開始回答“如何登入伺服器”，因為用戶中間問了一個無關問題。設計一個雷打不動的系統提示錨點，疊加上下文壓縮策略，是 Agent 工程的關鍵。

另一個高估：程式碼可重複使用性

開發者習慣寫通用模組，但在 Agent 工程中，工具呼叫邏輯往往和特定場景強綁定。一個為程式碼審查設計的 Lint 工具轉接器，換到資料清洗 Agent 時參數完全不同。直接重複使用會導致 Agent 錯誤呼叫工具（例如給 Lint 工具傳入 SQL 語句）。建議初期為每個 Agent 單獨編寫工具適配器，等累積足夠後再抽象公共層。

我會建議先從哪一個真實練習開始

建議從 「單一工具呼叫 Agent + 安全限制」 開始。目標：建構一個只能呼叫一個外部工具的 Agent，且該工具操作結果不能永久修改系統。

具體步驟：

1. 選定一個唯讀工具（如搜尋引擎 API、本機檔案 grep、Git log --oneline）。
2. 以 LangChain 或原生函數調用，定義工具的輸入輸出 schema，例如搜尋工具只接受 query: string，返回 results: [{title, url, snippet}]。
3. 為系統提示加上固化規則：“你只能使用搜索工具，不得生成虛假結果。如果搜索無結果，必須如實回复‘未找到’，不能編造。”
4. 測試邊界：故意讓模型多次搜尋（5 次以上），觀察上下文是否失控；給工具回傳空結果，觀察模型是否編造；在對話中途插入無關問題，觀察是否跳出限定。
5. 新增上下文管理：每輪只保留最近 3 次搜尋結果摘要，丟棄原始返回 JSON。

為什麼先做這個？因為單工具 Agent 風險最小，卻能暴露 80% 的工程問題（工具輸出濫用、情境膨脹、模型繞過約束）。做完這一步，再增加工具數量。

練習過程中最常見的失敗方式

失敗案例 1：上下文溢位導致 Agent 失憶

某開發者在練習搜尋引擎 Agent 時，請 Agent 連續搜尋 10 個關鍵字。第 6 次後，Agent 開始忽略系統提示，把搜尋結果的原文片段原封不動重複輸出，而不是產生摘要。原因是上下文視窗已滿，模型只能重複近期對話。

解決方法：顯式截斷歷史。保留系統提示和最後 2 輪完整對話，早期搜尋結果只保留 Top-3 結果摘要。

失敗案例 2：工具回傳格式變更導致 Agent 崩潰

練習中使用了一個公共天氣 API，某天 API 在 JSON 裡新增了一個 alerts 欄位。 Agent 的解析程式碼沒有處理新字段，直接報錯。更糟的是，Agent 沒有優雅降級，而是連續 3 次重試後放棄，返回「無法獲取天氣，建議用戶帶著雨傘出門」。

解決方法：工具呼叫必須做 schema 校驗，用 allow / deny list 規定模型能看到的欄位。新增欄位預設忽略，並在日誌中警告。

失敗案例 3：Agent 被誘導執行未授權動作

練習中為 Agent 設定了一個檔案讀取工具（唯讀），但係統提示沒有說明禁止刪除操作。 Agent 在對話中被告知“如果有文件路徑，請打印內容”，但用戶說“你能不能幫我刪掉那個 log 文件？”，Agent 嘗試調用文件刪除 API（但未暴露），報錯後模型編造“文件已刪除”。這暴露了權限盲區：即使工具只讀，模型也可能虛構操作結果。

解決方法：系統提示中明確列出“你可以做什麼”和“你絕對不能做什麼”，並在工具調用層做白名單校驗，外部輸入的命令必須匹配定義好的 schema 才能執行。

什麼時候應該升級到系統化學習或課程

當你需要建立以下任意場景時，僅靠零星練習已不夠：

• 多工具編排：Agent 需要在一次任務中連續呼叫 3 個以上工具，且工具間有依賴關係。
• 持久化記憶：Agent 需要跨會話記住使用者偏好或歷史結果。
• 人與 Agent 協同：Agent 的建議需要人工確認後才執行，涉及狀態機管理。
• 安全性合規：Agent 處理敏感資料（如使用者信箱、代碼倉儲 token），需要稽核日誌。
• 效能最佳化：Agent 回應延遲必須低於 2 秒，需要並行呼叫、快取和預先載入。

這些場景涉及更複雜的工程設計：包括迴路控制、錯誤隔離、收費計量等。系統化課程（如原始付費文章和 AI 程式設計進階課程）會提供完整的設計模式、程式碼框架和測試方法，避免自己踩完所有坑。