好的，這是您要求的英文到繁體中文的翻譯，已遵循所有提供的準則，包括術語表、格式、結構和本地化最佳實踐。
如何在 2026 年成為 AI 工程師。
沒有資訊科學學位。
沒有參加過訓練營。
不知道什麼是 Transformer 也沒關係。
以下是一些沒人告訴你的事：
現在正在招聘的公司，不需要一個懂數學的人。
他們需要的是能建構出可以在實際生產環境中存活之系統的人。
這兩者之間有很大的差別。
一個聊天機器人的包裝（wrapper）不是一個系統。
一個工具呼叫（tool call）不是一個 Agent。
熟悉 LangChain 不代表你懂框架工程（harness engineering）。
這兩者之間的薪資差距大約是 15 萬美元。
這就是跨越這個差距的完整路線圖。
請儲存這篇文章。你會想讀它兩次。
首先，殘酷的真相
現在多數在開發 AI 的開發者，都只是在做玩具。
他們用幾個提示詞（prompts）包裝 GPT。然後稱之為「AI 產品」。最後他們納悶為什麼沒人願意為此付費。
市場上充斥著這些包在 LLM 外面的薄薄一層包裝。
這些不是生意。它們只是功能，等著被大型科技公司抄走（Sherlocked）。
以下是公司在 2026 年真正願意付費的東西：
→ 不會在週五凌晨兩點當機的 Agent
→ 你可以衡量並證明其效能沒有退化的系統
→ 能讓同一個模型表現提升 86% 的框架（harness）
最後一點不是虛構的。
Anthropic 在兩個不同的框架上執行了同一個模型（Opus 4.5）。
→ Claude Code 框架：在 CORE 基準測試中獲得 78% 分數
→ Smolagents 框架：在 CORE 基準測試中獲得 42% 分數
同一個模型。不同的框架。36 個百分點的差距。
框架（harness）才是重點。
AI 工程師在 2026 年實際在做什麼
不是在寫提示詞。不是在挑選模型。
AI 工程師建構並營運的是模型周圍的那個系統。
這意味著：
→ 設計 Agent 循環（loop）和工具調度（tool dispatch）
→ 工程化上下文（context）——每一步要將哪些 token 送到模型前面
→ 撰寫模型實際上能正確選用的工具
→ 為生產環境流量加入記憶、持久性和沙盒機制
→ 設計評估（evals）和 CI 回歸門檻，讓「更好」變成可衡量
→ 交付能在真實用戶和真實成本下存活的 Agent
每個 Agent 工程師都需要了解的四大上下文基本要素：
寫入（Write） — 草稿區、Agent 能讀取和更新的記憶檔
選取（Select） — 在使用點進行檢索，而非一開始就傾倒所有資料
壓縮（Compress） — 在上下文視窗 85-95% 時進行摘要
隔離（Isolate） — 擁有自己獨立上下文視窗的子 Agent
這稱為上下文工程（context engineering）。提示詞工程（prompt engineering）作為一項獨立技能已經過時了。上下文工程取代了它。
6 階段路線圖
全職學習需要 17 週。業餘學習需要 40 週。
每個階段都有一個具體的專案。每個階段結束時都必須交付一些東西。
第 0 階段：建立正確的心智模型（第 1-2 週）
先不要寫任何 Agent 程式碼。
多數初學者會跳過這一步。他們直接跳進教學課程。然後當程式碼出錯時，他們無法推理出問題所在。
在進行其他事情之前，你需要透徹理解三件事：
1. 工作流程（Workflow） vs Agent
工作流程的控制流程是你寫死的。Agent 則是在一個循環內部自行做出控制流程的決策。
在只需要工作流程的時候硬要做成 Agent，成本會高出 10 倍，且當機頻率會高一倍。
2. 五種工作流程模式（來自 Anthropic）
→ 提示鏈（Prompt chaining）：將一個呼叫的輸出傳遞給下一個
→ 路由（Routing）：為不同任務使用不同模型
→ 並行化（Parallelization）：同時執行多個任務
→ 協調者-工作者（Orchestrator-worker）：一個大腦，多雙手
→ 評估者-優化者（Evaluator-optimizer）：產生 → 判斷 → 改善
3. 框架（Harness）
框架是介於你和模型 API 之間的東西。
你可以把它想像成一個作業系統：
→ 模型 = CPU（原始運算能力）
→ RAM = 上下文視窗
→ 作業系統 = 框架
→ 應用程式 = 你的 Agent 的技能
作業系統決定了 CPU 實際上能做些什麼。框架決定了模型實際上能做些什麼。
第 0 階段專案： 寫一份 2 頁的文件——用你自己的話——定義以下概念：工作流程 vs Agent、五種工作流程模式、四個上下文基本要素、協調者-工作者模式。
如果你不看筆記就寫不出來，代表你讀得不夠仔細。
第 1 階段：從零開始建立你的第一個 Agent（第 3-5 週）
寫一個 Agent 兩次。
第一次：使用原始的 Anthropic SDK。大約 100 行程式碼（Python）。
第二次：使用 Claude Agent SDK。
然後感受其中的差異。
第一次建構 — 原生循環
Agent 循環並不是什麼魔法。
- 用訊息和工具呼叫模型
- 解析出 tool_use 區塊
- 執行工具
- 附加 tool_result
- 重複直到 stop_reason = end_turn
自己用不到 100 行程式碼寫出來。
一旦你做到了，任何框架都會變得易於理解。
給它 3 個工具：
→ web_search
→ read_file
→ write_file
讓它在一個研究任務上執行。閱讀追蹤記錄的每一步。
第二次建構 — 在 Claude Agent SDK 上建立同一個 Agent
Claude Agent SDK 就是驅動 Claude Code 的同一個框架。
加入：
→ 包含專案慣例的 CLAUDE.md
→ 一個技能（定義「研究摘要」輸出格式的資料夾）
→ 一個 PostToolUse 鉤子（hook），會自動格式化 Agent 寫的每個檔案
→ 一個透過 Task 工具產生的子 Agent
然後寫 200 字回答：「在第一次建構中我自己寫的功能，框架為我免費提供了哪些？」
第 1 階段專案： 一個每日簡報 Agent。它會讀取你的 Markdown 筆記和 RSS 動態。每天早上將一份摘要簡報寫入磁碟。執行它一週。觀察它失敗。然後修復它。
第 2 階段：使用正確實體架構建立一個真正的 Agent（第 6-9 週）
現在你要在 LangGraph + Deep Agents 上進行建構。
這是生產環境的技術棧。
LangGraph 提供你：
→ 狀態機（節點 + 邊）
→ PostgresSaver 檢查點（能在任何程序終止時存活）
→ 時光旅行除錯（可回溯到任何步驟）
→ 人機協作中斷
→ 透過 LangSmith 提供一流可觀測性
Deep Agents（LangChain 包裝好的框架）提供你：
→ 規劃中介軟體
→ 虛擬檔案系統
→ 子 Agent 產出
→ 自動上下文壓縮
→ 技能
核心概念：中介軟體（middleware）
中介軟體是你自訂一個現成 Agent 而無需複製（fork）它的方式。
四個重要的鉤子：
→ before_agent — 在循環開始前執行
→ wrap_model_call — 包裹每一次 LLM 呼叫
→ before_tools — 在任何工具執行前執行
→ after_tools — 在任何工具執行後執行
第 2 階段專案： 研究分析師 Agent
輸入：一個研究問題
架構：
→ 主 Agent 制定計畫，將待辦事項清單寫入虛擬檔案系統
→ 並行產出 3 個搜尋子 Agent（隔離的上下文）
→ 子 Agent 將結果寫入檔案，並向父 Agent 回傳簡短摘要
→ 引文子 Agent 驗證聲明
→ 寫作 Agent 產生最終的 Markdown，內含行內引文
→ 狀態透過 PostgresSaver 持久化——終止程序後，可從中斷處恢復
→ 人機協作中斷：在 token 費用超過 $1 前請求確認
在你的 README 旁邊附上一個 LangSmith 追蹤記錄的 URL。
第 3 階段：自己建構框架層（第 10-13 週）
這是整個路線圖中槓桿率最高的階段。
停止使用包裝好的框架。自己建構一個精簡版。
在你親手建構過一次之前，你永遠無法在生產環境中做出正確的框架取捨。
現代框架的 10 個元件：
- 循環控制 — 驅動模型 → 工具 → 模型的 while 迴圈
- 工具調度 — 註冊表、結構驗證、並行呼叫、重試機制
- 上下文管理 — 系統提示組裝、在視窗 85% 時進行壓縮
- 持久化 — 在每個節點檢查點狀態，以便恢復、回溯、分支
- 子 Agent 協調 — 隔離上下文的子 Agent，壓縮摘要回傳
- 技能與漸進式揭露 — 僅在相關時載入能力
- 鉤子 — PreToolUse、PostToolUse、PreCompact、Stop
- 可觀測性 — 為每個模型呼叫、工具呼叫、子 Agent 呼叫產生 OTEL spans
- 沙盒化 — 在容器中執行程式碼，模型永遠沒有該容器的憑證
- 授權代理 — 憑證絕不進入模型的上下文
第 3 階段專案： 用大約 1,500 行 Python 程式碼寫一個迷你框架。
必須包含：
→ 從 @tool 裝飾器生成的工具註冊表，並附有 JSON-schema
→ CLAUDE.md 風格的系統提示載入器
→ SKILL.md 風格的漸進式揭露載入器
→ 帶有隔離上下文的子 Agent 產出原始語法
→ 檔案系統卸載：任何超過 20K token 的工具結果 → 寫入磁碟
→ 在上下文中以路徑 + 10 行預覽取代
→ 在上下文視窗達到 85% 時自動壓縮
→ 可插拔的鉤子系統（pre_tool、post_tool、stop）
→ OpenTelemetry 追蹤
→ 可持久恢復：在每個步驟後持久化到 SQLite，可依執行 ID 重新載入
真正的成果：一份 1,000 字的回溯報告，比較你的迷你框架與 Claude Agent SDK 和 Deep Agents。你做對了什麼。你捨棄了什麼。你下次會怎麼做。
第 4 階段：建構評估與回歸框架（第 14-17 週）
沒有這個，每一次的「改進」都只是憑感覺。
這是大多數工程師停滯不前的地方。
他們可以建立一個很棒的 Agent。但他們無法判斷下一次的改動是讓它變好了還是變差了。
你必須實作的四種評估類型：
1. 單輪評估
給定這個輸入，輸出是否正確？成本最低。盡可能使用確定性評分器。持續執行。
2. 軌跡評估（Trajectory evals）
Agent 是否以正確的參數呼叫了正確的工具序列？測試單步、完整回合和多回合變體。
3. LLM 作為評判者（LLM-as-judge）
用於開放式輸出：研究報告、程式碼審查、解釋。每週根據人工評分的範例進行校準。
4. 最終狀態評估（End-state evals）
用於有狀態的 Agent：資料庫是否被正確寫入？正確的檔案是否被更改？將最終環境狀態與真實情況進行比較。
關於評估的令人不安的事實：
模型可以偵測到它們正在被評估。它們在評估輸入上的行為會有所不同。
設計你的評估套件以防止這種情況。使用真實的生產查詢，而不是合成的。
第 4 階段專案： 為你的第 2 階段 Agent 建立回歸框架。
→ 黃金數據集：30-50 個人工評分的研究問題（3 個難度等級）
→ 事實性查詢的確定性評分器
→ LLM 作為評判者，搭配 5 項標準的評分表，用於開放式問題
→ 軌跡評估：Agent 是否有規劃、產出 2 個以上子 Agent、引用來源、在預算內完成？
→ 接入 GitHub Actions：如果黃金數據集通過率下降 3 個百分點以上，則阻止合併
→ 生產抽樣：每晚自動評分 1% 的即時追蹤記錄
第 5 階段：生產環境強化（持續進行）
這個階段不會結束。
五件永遠重要的事：
1. 成本控管
→ 快取你的 CLAUDE.md、系統提示和工具定義——最多可節省 90% 費用
→ 按難度路由：簡單回合用 Haiku，大多數任務用 Sonnet，困難推理用 Opus
→ 非即時工作使用 Batch API：可享 50% 折扣
→ 多 Agent 消耗的 token 量約為單 Agent 的 15 倍——只在價值超過這個門檻時才執行
2. 延遲
→ 始終使用並行工具呼叫——Anthropic 自家研究 Agent 的系統提示就明確寫著「你必須使用並行工具呼叫」
→ 將部分輸出串流到 UI
→ 子 Agent 扇出模式：將一個 60 步的序列式 Agent → 轉變為 10 步的主 Agent + 5 個並行執行的 10 步子 Agent
3. 安全性與沙盒化
→ 所有程式碼執行都放在沙盒中（Modal、E2B）：永遠不要在主要程序中執行 model 的輸出
→ 憑證在模型上下文之外進行代理：模型永遠不會看到它使用的 API 金鑰
→ 對任何不可逆轉的操作設置人機協作中斷
4. 監控與漂移
→ 針對以下項目發出警報：每次請求的 token 成本、工具呼叫失敗率、LLM 作為評判者的分數、p95 延遲
→ 每次模型升級後重新基準化評估——框架編碼了對模型無法做到之事的假設，而這些假設會過時
5. 韌性
→ 對任何執行超過 60 秒的 Agent 使用持久化執行（Inngest、Temporal、PostgresSaver）
→ 在每個節點後設置檢查點
→ 應始終能夠回溯和分支
5 個生產等級的專案（選一個，本週末就開始建構）
這些按複雜度排序。
它們能證明公司真正需要看到的實力。
專案 1：採用小型語言模型（SLM）的 AI 驅動行動應用程式
建立一個使用小型語言模型、可離線優先的行動應用程式。零 API 成本。完全保護隱私。
它之所以不簡單的原因：
→ 按需懶加載模型，記憶體壓力大時卸載
→ 具有語義分塊的滑動上下文視窗
→ 舊裝置使用 4 位元量化，新裝置使用 8 位元
→ 批次推論以減少電池喚醒次數
為何重要：你證明了你理解資源限制和裝置層級的 AI。你不僅僅是在呼叫 API——你在管理記憶體壓力和量化。
專案 2：自我改進的程式碼編寫 Agent
建立一個 Agent，它能寫程式碼、執行測試，並從失敗中學習。它會一直運作直到程式碼功能正常為止。
它之所以不簡單的原因：
→ 規劃 → 執行 → 測試
→ 帶有最大迭代次數限制的反思循環
→ 每個任務有獨立執行環境及資源限制
→ 記憶體層級：短期（最近 5 次迭代）、長期（成功模式）、失敗記憶（錯誤特徵 + 解決方案）
→ 在執行前進行靜態分析——偵測危險操作
為何重要：引入了 Agent 循環。展示了你理解生產環境除錯和迭代式改良。
專案 3：專為影片編輯者設計的「Cursor」
複製（Fork）一個開源編輯器（Shotcut），並建立一個能理解編輯意圖的 AI Agent。
用戶說「讓它看起來更有電影感」。Agent 處理剪輯、轉場和調色。
它之所以不簡單的原因：
→ 視覺模型分析每一幀 + 音訊模型分析對話
→ 意圖轉譯：「電影感」→ 具體參數（節奏、LUT、焦點模擬）
→ 透過幀差異分析進行場景偵測
→ 增量預覽——僅重新渲染受影響的區段
為何重要：多模態 AI + 複雜工具整合。讓你從 99% 的聊天機器人建構者中脫穎而出。
專案 4：個人生活 OS Agent
建立一個 Agent 來管理你的行事曆、財務和健康狀況。提前數月規劃。透過分析睡眠模式和會議密度來檢測倦怠。
它之所以不簡單的原因：
→ 即時從行事曆、財務、健康、通訊工具攝取資料
→ 包含實體及關係的個人知識圖譜
→ 每 6 小時在背景執行一次，檢查異常
→ 價值觀對齊：用戶設定優先級（家庭 > 工作）——每個建議都經過驗證
→ 所有資料在靜止時使用用戶控制的金鑰進行加密
為何重要：需要複雜的上下文管理和合乎道德的 AI 設計。展示了以隱私為優先的生產架構。
專案 5：自主企業工作流程 Agent
一個能端到端執行業務工作流程的 Agent。
監控 Slack/Jira → 規劃執行 → 分配任務 → 報告結果，並附有完整的稽核日誌。
它之所以不簡單的原因：
→ 事件驅動：監聽 Slack、Jira、電子郵件、監控系統
→ 多 Agent 委派：協調者 → 通訊 Agent、資料 Agent、分析 Agent、文件 Agent
→ 自我修復：指數退避、斷路器、自動重試決策
→ 不可變更的稽核日誌：每個動作、授權者、結果
→ 人機協作：在關鍵工作流程執行前，Agent 需先提出計畫供確認
為何重要：將協調、安全性和可觀測性結合成一個可擴展的系統。這是最終的專案集大成者。
技術棧（實際要學什麼）
框架：LangGraph 1.0 + Deep Agents
為什麼不是 CrewAI、AutoGen 或 OpenAI Swarm？
→ CrewAI：原型最快，但在生產環境中脆弱。僅適用於黑客松。
→ AutoGen：已合併到 Microsoft Agent Framework。未來不明朗。
→ OpenAI Swarm：根據 OpenAI 自己的 README，明確標示「非生產環境就緒」。
LangGraph 提供你：狀態機 + PostgresSaver 持久性 + 時光旅行除錯 + 友善 OTEL 的可觀測性 + 模型無關性。
框架參考：Claude Agent SDK
研究它。使用它。它與 Claude Code 使用相同的框架。
CLAUDE.md + 技能 + 子 Agent + 鉤子 + 檔案系統即記憶體。
2026 年所有其他框架都將收斂到這些基本要素。
可觀測性：選擇一個
→ LangSmith：如果你主要使用 LangGraph
→ Braintrust：如果你想要與框架無關的 CI 門控（每月 $249 固定費用）
→ Arize Phoenix：如果你想要開源 + 原生 OTEL
2026 年可以跳過：
→ OpenAI Swarm — 非生產環境就緒（可以考慮 Kimi Agent Swarm）
→ OpenAI Assistants API — 將於 2026 年中停止服務
→ 在測量到實際檢索問題之前，先自己建構向量儲存
→ 無程式碼 Agent 平台，除非只是玩玩
基準測試數據（2026 年 5 月）
SWE-bench Verified（程式碼任務）：
→ Claude Opus 4.7：~87.6%
→ GPT-5.5：~88.7%
GAIA（通用 Agent 任務）：
→ Claude Sonnet 4.5 領先，達 74.6%
τ-bench（客戶服務 Agent）：
→ Claude Mythos Preview：89.2%
關鍵見解：相同的基準測試，不同的框架 = 10-36 個百分點的差距。
模型的影響力小於框架。
17 週時間表
第 2 週 → 第 0 階段完成。你可以用白話解釋什麼是框架。
第 5 週 → 第 1 階段完成。已使用 Claude Agent SDK 交付一個 Agent，包含一個技能、一個鉤子、一個子 Agent。
第 9 週 → 第 2 階段完成。深度 Agent 已在 LangGraph 上運行，具備 PostgresSaver 持久性和 LangSmith 追蹤。
第 13 週 → 第 3 階段完成。已完成並撰寫了 1,500 行的迷你框架文件。
第 17 週 → 第 4 階段完成。擁有黃金數據集、CI 門控、一次透過 Inspect 執行的已發布基準測試。
第 17 週後 → 第 5 階段。持續進行。
業餘學習，每週 10-15 小時：將所有時間乘以 2.5 倍。
令人不安的事實
大多數人會讀完這篇文章，然後什麼都不做。
他們會把它加入書籤。說「好文章」。然後回去繼續做包裝程式。
2026 年的殘酷真相：
→ 可以被取代的人：建構薄薄的 GPT 包裝
→ 不可或缺的人：交付具備評估和持久性的自主系統
這兩者之間的差距是 5 個專案和 17 週的專注工作。
57% 的團隊已將 Agent 投入生產。
其中 89% 已接上可觀測性。
品質是第一大障礙（32% 的團隊提及）。
這意味著整個領域的瓶頸在於能夠建構評估和框架的工程師。
而不是在於能夠呼叫 LLM API 的工程師。
這個職缺就在那裡。
結語
這份路線圖不會讓你在 17 週內成為首席 AI 工程師。
但它會讓你成為一個能夠建構和交付能在生產環境流量中存活的 Agent 系統的人。
這恰好是現在公司願意花錢聘請的人才。
我希望你接下來這麼做：
1. 挑選一個專案。 如果你是新手，從專案 1 開始。如果你已經在寫程式碼，從專案 5 開始。只要開始就好。
2. 這個週末就開始建構。 市場獎勵的是交付，而不是學習。
3. 記錄一切： 你的架構決策、你的失敗與復原、你的自我修正循環。
4. 公開建構。 當你交付時，Tag 我——我會幫你分享。
到下個月，90% 的人將一事無成。他們仍在建構同樣的包裝程式。
另外 10% 的人會交付一些真實的東西。他們將獲得面試機會、工作錄取和職涯優勢。
選擇很簡單：
成為公司迫切想要僱用的架構師。或者變得過時。
專業知識是唯一剩下的工作保障。生產系統是唯一重要的作品集。
現在，去建構一個能經得起現實考驗的東西吧。
回覆告訴我你將從哪個專案開始。我會閱讀每一則回覆。
→ 按讚分享，讓更多人看到
→ 追蹤 @sairahul1 獲取更多此類深度分析
