Gary Talks Stuff：Google Agentic Engineering 課程精華 Day 1 — 從 Vibe Coding 到 Agentic Engineering

開場閒聊

「現在有 85% 的專業開發者在用 AI coding agent，41% 的新程式碼是 AI 寫的。」Gary 一開場就丟出這兩個數字，但隨即話鋒一轉：「Vibe coding、agentic engineering 這些詞，十個人講有十種意思，有人說 vibe coding 是未來，有人說那是垃圾 code 的製造機。」

他提到 Google 最近上線了一套五天的 AI 開發課程，這是第一次把整個業界正在收斂的共識寫成一套正式的框架——光是 Day 1 的講義就厚達 51 頁。他用 15 分鐘把 Google Agentic Engineering 課程精華 Day 1 的四個核心主題濃縮出來：從 Vibe Coding 到 Agentic Engineering 的定位光譜、比 Prompt Engineering 更重要的 Context Engineering、Agent 等於 Model 加 Harness 的公式，以及 Token 經濟學背後的財務邏輯。

懶人包速覽

核心痛點	關鍵觀點
Vibe Coding 與 Agentic Engineering 到底差在哪？	兩者是一條光譜，不是二選一的開關。分水嶺在於驗證——沒有測試與 Evals，無論 Prompt 多精緻都還是 Vibe Coding。
為什麼我的 AI agent 常常出包？	大多數失敗不是因為選錯模型，而是 Configuration 問題：缺工具、規則太模糊、少 Guardrail、Context 充滿雜訊。
投資 Harness 值得花時間嗎？	從 Token 經濟學來看，前期 Capex（建構測試、Context、Evals）高，但每個功能的編輯成本大幅下降，是財務槓桿。
AI 開發者的角色會怎麼轉變？	從寫程式的人變成 Conductor 與 Orchestrator——在指揮模式與放權模式之間切換，判斷力比實作能力更值錢。

Google 這門課程把這些從業界各處散落的共識收斂成一個完整的框架，是我近期看過最紮實的 AI 開發實戰課程整理。

光譜不是開關：Vibe Coding 到 Agentic Engineering 的連續性

2025 年 2 月，Karpathy 創造了「Vibe Coding」這個詞，描述一種完全順著感覺走、用自然語言描述需求、遇到錯誤直接貼回給 AI 修的新寫程式方式。這個詞會爆紅，是因為它精準描述了許多人早就開始使用的 AI 開發模式——但也因為爆紅而被過度濫用。

一個資深工程師用 AI 實作規格明確的功能算 Vibe Coding 嗎？一個團隊用 Agent 執行規劃好的架構算嗎？到 2026 年初，Karpathy 自己又補充了「Agentic Engineering」這個詞，用來描述有紀律的那一端。

Google 課程的第一個核心主張是：這兩個東西不是開關，是一條光譜。光譜上有三個位置——Vibe Coding、Structured AI Assisted Coding、Agentic Engineering——判斷標準不是用不用 AI，而是 AI 的輸出周圍有多少結構、驗證以及人類判斷。

講義中的對照表呈現了三項關鍵差異。第一是 Intent 的規格化程度：Vibe Coding 是隨口的自然語言 Prompt，Agentic Engineering 是正式的 Spec、架構文件與 Memory Files。第二是驗證方式：Vibe Coding 的標準是「看起來會動」，Agentic Engineering 則仰賴自動化測試、CI/CD Gates 與 LM Judges。第三是錯誤處理：Vibe Coding 把錯誤貼回去叫 AI 自己修，Agentic Engineering 讓 Agent 在定義好的邊界內自我診斷，人只處理架構層級的問題。

Gary 用一個生動的比喻總結：「你跟 CTO 說我們在 Vibe Coding 付款系統，他臉都綠了。但你說我們在做 Agentic Engineering——AI 負責實作，人類設計約束，測試覆蓋確保正確性——聽起來就沒那麼膽戰心驚。」

整條光譜上最大的分水嶺是驗證，而驗證有兩種：Tests 負責確定性（這個 Function 給這個輸入就該產出這個輸出），Evals 負責非確定性（Agent 走的路徑對不對？工具選的對不對？）。Google 講得很死——沒有這兩個東西，無論 Prompt 寫得多精緻，你做的都還是 Vibe Coding。

Context Engineering：比 Prompt Engineering 更關鍵的技能

如果你想往 Agentic Engineering 那端移動，需要練習的不是把 Prompt 寫得更漂亮，而是學會 Context Engineering。這個觀念被 Gary 形容為通往 Agentic Engineering 的橋梁。

Context Engineering 的核心概念很直覺——好比幫新員工做入職簡報。一個新人來報到，你不會只丟一句「幫我把這個功能做出來」，而是會告訴他任務是什麼、專案背景是什麼、公司有哪些規範。AI 也一樣，它的產出品質跟你給了它哪些 Context 關聯性非常大。

Google 將 Context 分成六種：

• Instructions：定義 Agent 的角色與邊界
• Knowledge：給 Agent 的領域知識
• Memory：短期與長期的狀態
• Examples：行為示範
• Tools：Agent 能呼叫的工具定義
• Guardrails：硬性約束

這六種 Context 又可以大致分成靜態與動態兩類。靜態的部分像是 Instructions 和 Knowledge，寫好之後變化不大；動態的部分像是 Memory 和 Tools，會隨著 Agent 執行任務的過程不斷更新。掌握這六種 Context 的管理方式，就是從 Vibe Coding 走到 Agentic Engineering 的核心能力。

SDLC 被重新定義：Factory Model 與開發者角色的轉變

AI 對軟體開發生命週期（SDLC）的影響並非均勻加速。Implementation——實際寫 Code 的部分——從幾週縮短到幾小時，但需求訪談、架構決策、驗證品質這些環節依然維持人類的速度。

這不是舊流程被加速，而是誕生了一個全新的流程。新流程中每個階段的邊界變模糊，迭代週期從週縮短到分鐘，而 Spec 的品質變成新的瓶頸。

需求階段從「文件在部門之間傳來傳去」變成「人與 AI 的對話」。架構階段是最頑固的人類階段——因為架構決策本質上是取捨（一致性還是可用性？自己開發還是買現成的？），這些依賴商業脈絡，AI 暫時抓不到全貌。但架構定案之後的執行，AI 極度擅長。

實作階段的生產力提升根據業界調查是 25% 到 39%——但 Meta 有一個研究發現，資深工程師用 AI 做某些任務反而慢了 19%，因為時間都花在驗證和修正 AI 的產出。這兩個數據並不衝突，它們同時說明一件事：AI 不是消滅實作工作，是把實作從「寫」變成「審查、引導、驗證」。

最被低估的階段是維護。以前那種只有原作者看得懂、沒人敢動的 Legacy Code，現在 Agent 可以讀懂整個 Codebase，理解它的 Pattern，在尊重既有架構的前提下動手改。框架遷移、更新過時 API、現代化測試——這些過去風險太高沒人想碰的事，現在可以開始著手翻修了。

Google 把這些變化串成一個新模型叫 Factory Model。你不再是寫程式的人，而是工廠經理——不親自組裝每一個零件，而是設計產線、把關品質。開發者的主要產出不再是程式碼，而是產出程式碼的系統，包含 Spec 與 Context、負責實作的 Agents、驗證正確性的測試關卡、修正失敗的 Feedback Loops，以及約束行為的 Guardrails。

Agent = Model + Harness：為什麼 Configuration 比選模型更關鍵

很多人把 Model 當成系統本身——新 Model 出來就覺得 Agent 變聰明了，舊 Model 就覺得變笨了，Model 變成一切好壞的解釋。Gary 直接說這個觀念是錯的，而且會讓你把時間投資在錯的地方。

正確的公式很簡單：Agent = Model + Harness。

一顆 Raw Model 不是 Agent，它要有 Harness 給它狀態、執行工具的能力、Feedback Loop、可執行的約束，它才變成一個 Agent。你平常使用 Claude、Cursor、Codex 感受到的行為差異，很大一部分是 Harness 決定的，不只是底下那顆 Model。

Harness 有六大元件。第一，Root Files——定義 Agent 是誰、在乎什麼、什麼事絕對不能做。第二，Tools——它能呼叫的 Function、MCP Servers，以及告訴它什麼時候該用哪個的說明。第三，Sandbox——Code 在哪裡跑、能摸到什麼、摸不到什麼。第四，Orchestration——Sub-Agent 的調度、Model 之間的路由、專家之間的交接規則。第五，Hooks——生命週期固定點跑的確定性 Code，例如 Commit 前自動擋掉硬編碼的密碼。第六，Observability——Logs、Traces、Evals、成本監控。沒有這一層，你根本不知道 Agent 是做得好，還是在偷偷浪費你的錢。

Google 課程給了兩個案例證明 Harness 的重要性。HumanEval 2.0 是一個很硬的 Coding Agent Benchmark，有一個團隊完全不換 Model，只改 Harness，就把成績從 30 名以外拉進前 5 名。另一個是 LangChain 的實驗——同一個 Model，只調整 System Prompt、Tools 跟 Middleware，就加了 13.7 分。

Gary 總結：「大部分的 Agent 失敗都是因為 Configuration。Agent 出包的時候，你的第一反應是怪 Model，打開排行榜想換一顆，但真正的原因通常是缺一個工具、一條規則寫得太模糊、少一個 Guardrail，或者 Context 塞滿雜訊。」

他的實戰建議是：Agent 出包時，不要修完 Bug 就走。多花五分鐘回頭問自己——我的 Rules、Workflows、Skills 哪裡可以改，讓這種錯誤不再發生？把答案寫回你的 Harness。這樣每跑一輪，系統就更可靠一點，錯誤也從成本變成資產。

Token 經濟學：Capex 與 Opex 的 AI 投資思維

光說道理不夠，Google 這門課程用財務概念來量化 Harness 的投資回報——Capex（前期投資）與 Opex（營運成本）。

Vibe Coding 看起來超便宜——一個月的訂閱費、幾句 Prompt 就能開工，前期投資趨近於零。但它藏著三個會複利成長的營運成本。第一是 Token 燃燒率：沒有整理過的 Context 整包丟進去，然後反覆叫 Model 修自己沒驗證過的錯，這個低成本的迴圈每一輪都在燒 API 費用。第二是 維護稅：沒有結構一致性的 AI Code，半年後出 Bug，工程師要花好幾天逆向工程那坨義大利麵。第三是 資安補救：Code 生得快漏洞也多，Production 環境修一個資安漏洞的成本是設計階段抓到的好幾倍。

Agentic Engineering 把這套帳整個反過來。前期要投工程時間設計 API Schema、建測試套件、整理 Context——Capex 高——但每個功能的編輯成本大幅下降，因為 AI 是在一座治理好的工廠裡跑。產出天生結構就是對的、預先測過的、符合公司標準的。

LLM 是按你送進去的每一個 Token 收費的。把 10 萬 Token 的 Report 整包塞進每一個 Prompt，從 Token 效率來說非常不友善。一份精準的文件或提示詞會直接拉高 First Pass 成功率——第一次就做對，等於省掉整條 Trial and Error 的錢。你不能決定一個 Model 的費用，但你可以用比較少的 Token 數完成一樣的任務，只要你管理好 Context。

QA 精選

Q1：Vibe Coding 和 Agentic Engineering 的差別到底在哪？用什麼標準判斷自己現在屬於哪一種？

判斷標準不是你用不用 AI，而是 AI 輸出周圍有多少結構、驗證以及人類判斷。Vibe Coding 是隨口的自然語言 Prompt，驗證標準只有「看起來會動」，錯誤處理是把錯誤貼回去叫 AI 自己修。Agentic Engineering 有正式的 Spec 文件、自動化測試加上 CI/CD Gates，Agent 在定義好的邊界內自我診斷，人只處理架構層級的問題。Google 講得很死：沒有 Tests 跟 Evals，無論 Prompt 寫得多精緻，你做的都還是 Vibe Coding。

Q2：Context Engineering 具體該怎麼做？六種 Context 之間有沒有優先順序？

Context Engineering 的核心就是把對新員工做入職簡報的邏輯套用到 AI 上。六種 Context 分別是 Instructions（角色邊界）、Knowledge（領域知識）、Memory（狀態記憶）、Examples（行為示範）、Tools（工具定義）、Guardrails（硬性約束）。實務上可以從 Instructions 和 Tools 開始——先定義清楚 Agent 的角色和它能用的工具，這兩項做好了，再把 Guardrails 加上去防止 Agent 跑偏。Knowledge 和 Examples 則是持續疊加的過程，不需要一步到位。

Q3：Harness 投資的回報週期大概多長？小團隊值得花時間做嗎？

從 Token 經濟學的角度來看，Harness 前期 Capex 高但每個功能的編輯成本會大幅下降。Google 課程中 HumanEval 2.0 的案例顯示——完全不換 Model，只改 Harness，成績從 30 名以外拉進前 5——這表示 Harness 的回報幾乎是立即可見的。對小團隊來說，可以先從十行的 Agent Markdown 開始，把基礎站姿、慣例、硬規則、Workflow 寫下來，然後 Agent 每做一件你不想再看到的事就加一條規則。這個過程本身就有複利效應，一個月後這份文件會比一開始好用非常多。

Q4：Conductor 和 Orchestrator 兩種模式該怎麼切換？什麼場景適合哪一種？

Conductor 是指揮家模式——在 IDE 裡看著 Code 一行一行出現，隨時下指令、隨時修正，每一步都在掌控中。適合複雜邏輯、棘手的 Debug，還有不熟的 Codebase，因為這些情境你需要理解每一個改動。Orchestrator 是放權模式——定義目標後指派任務給 Agents 在背景平行跑，隔一段時間回來 Review 結果。適合 Bug Fix、照著既有 Pattern 做功能、Codebase 遷移、測試生成。開發者會在這兩個模式之間流動切換，而 Orchestrator 模式需要四項關鍵技能：Specification（任務定義清楚到 Agent 不會誤解）、Decomposition（拆成 Agent 能消化的單位）、Evaluation（快速判斷產出是否過關）、System Design（設計約束與 Feedback Loop）。

Q5：Google 這門課程的 Day 2 到 Day 5 分別涵蓋什麼內容？後續值得追嗎？

Day 2 講 Agent 工具——MCP 與 A2A 協定。Day 3 講 Skills、記憶與 Context 優化。Day 4 講 Security 與 Evaluation 實戰。Day 5 講 Spec Driven 的 Production Level 開發。從 Day 1 的內容品質來看，這是一套從觀念到實作非常完整的課程，如果 Gary 能把全系列做完，價值會非常高。課程講義中最讓人印象深刻的一句話是：「Generation is solved. Verification, judgment, and direction are the new craft.」——AI 已經解決了產出效率的問題，剩下的手藝在於驗證、判斷與方向。

主編隨筆 / Editor’s Note

Gary 在這集從頭到尾都在強調一個核心觀點：Model 你控制不了，Harness 是你唯一能控制、也最值得投資的地方。這個觀點我個人非常認同，而且我認為它在實務上有一個更隱晦但重要的應用——Harness 是最好的 Model 切換保險。

過去半年我觀察到的現象是，各家公司推出的新模型迭代速度已經快到 teams 追不上——GPT 系列、Claude Opus、Gemini、DeepSeek、Grok，每幾個月就一輪大洗牌。如果你的 Agent 系統架構是把所有邏輯塞進 System Prompt，綁死某一個模型的行為模式，那每次換模型都要從頭調 Prompt，而且還不一定調得好。但如果你已經建好了 Harness——有明確的 Tools 定義、可驗證的 Tests、攔截錯誤的 Guardrails——那換模型就像替換工廠產線上的一顆螺絲釘，只要確認 Tests 全部通過，新模型就能直接上線。

從這個角度來看，Harness 不只是提升效率的工具，它其實是反脆弱的架構設計。它讓你不被任何一家 Model 廠商綁架，讓你的系統隨著 Model 的進步自然受益，而不是每次換 Model 都要重來。

回到 Gary 最後分享的那句話：「Generation is solved. Verification, judgment, and direction are the new craft.」我認為對台灣的開發者來說，這句話還有一個更務實的意涵——寫 Code 的能力門檻正在快速降低，但理解和設計系統的能力反而變得更有價值。在 AI 協助下能寫出 Production-Level Code 的人會越來越多，稀缺的不是誰能寫出 Code，而是誰能判斷什麼 Code 值得寫。

如果這篇整理對你有幫助，後續的 Day 2 到 Day 5 涵蓋 MCP、A2A、Security 與 Spec-Driven 開發，我會持續追蹤並分享。

結語

這集 Gary Talks Stuff 整理的 Google AI 開發課程 Day 1 內容，從 Vibe Coding 與 Agentic Engineering 的連續光譜、六種 Context 的管理方式、Harness 六大元件的實戰應用，到 Token 經濟學的 Capex 與 Opex 分析，提供了一個從觀念到實踐非常完整的框架。

最值得記住的結論有三個：第一，沒有驗證的 AI 開發就是 Vibe Coding，不管你的 Prompt 寫得多好。第二，Agent 出包時先檢討 Configuration，不要急著怪 Model。第三，Harness 是你唯一能控制的資產，它的複利效應會隨著時間越來越明顯。

如果你對 Google 這套五天課程的後續內容有興趣，或想了解更多 Agentic Engineering 的實戰技巧，歡迎繼續關注這個系列。