Agentic Engineering 是什麼？為什麼 Karpathy 要發明這個詞

Agentic Engineering 實戰手冊 第 1 / 14 篇

這是「Agentic Engineering 實戰手冊」系列的第一篇。完整系列共 14 篇，從基礎認知到系統設計到團隊導入，一個做了一年 100% AI coding 的工程師的實戰全紀錄。

2025 年我們在 Vibe Coding，2026 年呢？

2025 年 2 月 2 日，Andrej Karpathy 在 X 上發了一條推文，說他最近寫 code 的方式完全變了——「完全交給 LLM，忘記程式語言的存在，只靠直覺和 vibes。」他把這叫做 Vibe Coding。

那條推文爆了。整個 tech 圈都在討論。有人覺得這是解放，有人覺得這是墮落。但不管你站哪邊，Vibe Coding 確實描述了一個真實的現象：越來越多人開始「感覺對了就好」地用 AI 寫 code，不太在意細節，反正跑得動就行。

一年後，2026 年 2 月 8 日，同一個 Karpathy 發了另一條推文。這次他說：不，Vibe Coding 不夠。我們需要一個新詞——Agentic Engineering。

為什麼？因為過去這一年，整個產業發生了根本性的轉變。AI 不再只是你問它問題然後複製貼上答案的工具。它變成了 agent——能自己讀 code、自己寫 code、自己跑測試、自己修 bug 的自主行動者。而你，變成了管它的人。

這個轉變需要的不是 vibes，是扎扎實實的工程。

作為一個從 2025 年初就開始 100% agent-first coding 的人，我親身經歷了這一年的演化。從一開始覺得「哇這好方便」，到中間覺得「等等，它怎麼又寫錯了」，到現在理解「原來管 agent 是一門學問」——這篇文章想跟你分享的，就是這段旅程。

從 Vibe Coding 到 Agentic Engineering：一年的演化

如果要畫一個光譜，軟體開發的方式正在經歷這樣的演化：

階段	時期	你在做什麼	AI 在做什麼
Manual Coding	~2022 前	自己寫每一行 code	不存在
AI-Assisted	2022-2024	自己寫，AI 幫忙補完	Tab completion、回答問題
Vibe Coding	2024-2025	描述你要什麼，AI 寫	產生大段 code，你複製貼上
Agentic Engineering	2025-now	定義目標和限制，管理 agent	自主讀 code、寫 code、跑測試、修 bug

關鍵的轉折點在 2025 年中。那時候 Claude Code、Cursor Agent Mode、Codex CLI 這些工具開始成熟，AI 不再只是「給你一段 code 讓你貼」，而是可以直接操作你的 codebase、跑你的 test suite、甚至自己 commit code。

我記得很清楚第一次讓 Claude Code 自己修一個 bug 的感覺。我只說了「這個 API 在特定 payload 下回 500，error log 在這裡，請找到 root cause 並修好它」，然後它就開始自己讀 code、自己找問題、自己寫修復、自己跑測試。

我去倒了杯咖啡回來，bug 修好了。

那一刻，我意識到我的角色不一樣了。我不是在「寫 code」，我是在「管一個會寫 code 的 agent」。

但 Vibe Coding 和 Agentic Engineering 的差別，不在工具，在心態。Vibe Coding 是「反正 AI 會搞定，我不需要太認真」。Agentic Engineering 是「正因為 AI 在搞定，我需要更認真地管理這個過程」。

Agentic Engineering 的定義：不只是「用 AI 寫 code」

Karpathy 解釋這個詞的時候，把它拆成兩半：

Agentic——因為你的預設模式不再是自己寫 code，而是讓 agent 去寫。你從 creator 變成了 orchestrator。

Engineering——因為怎麼編排 agent、怎麼提供 context、怎麼驗證產出、怎麼管理品質，這裡面有系統性的學問。不是 vibes，是工程。

Google 的 Addy Osmani 在他的 blog 裡把 Agentic Engineering 歸納為五個原則：

1. Plan before prompting——先寫 spec，再讓 agent 動手
2. Direct with precision——給 agent 明確的、有範圍的任務
3. Review rigorously——像 review 人類的 PR 一樣 review agent 的產出
4. Test relentlessly——測試是品質保證的底線，不是可選的
5. Own the system——維護文件、版本控制、CI/CD，你是最終負責人

Django 的共同創辦人 Simon Willison 則整理了一份完整的 Agentic Engineering Patterns 指南，裡面最重要的一句話是：

「與高品質軟體工程相關的技術——自動測試、linting、清晰的文件、CI/CD、乾淨的架構——恰好也是讓 coding agent 產出更好結果的東西。」

講白了，好的工程習慣沒有被 AI 淘汰，反而被它放大了。

那它跟其他術語到底差在哪？簡單整理：

	Prompt Engineering	AI-Assisted Coding	Vibe Coding	Agentic Engineering
核心活動	寫好的 prompt	用 AI 補完 code	描述需求讓 AI 寫	編排 agent 自主完成任務
品質責任	你寫的 code	你寫的 code	你不太確定	你 review 的 code
工程紀律	低	中	低	高
適用場景	問答、文字	日常 coding	Prototype、demo	Production-grade 開發

Agentic Engineering 不是 Vibe Coding 的「升級版」。它跟 Vibe Coding 的關係，更像是 DevOps 跟「手動部署」的關係——本質上是不同的方法論，要求不同的技能，產出不同品質的結果。

數據說話：現在到底多少人在用？

Anthropic 在 2026 年 3 月發布的 Agentic Coding Trends Report 顯示，開發者有 60% 的工作涉及 AI，而且對於委派給 agent 的任務，工程師在 80-100% 的情況下仍然保持監督。

JetBrains 在 2026 年 1 月的調查（11,000 名開發者參與）更直接：90% 的受訪者在工作中使用 AI。

聽起來很普及。但這裡有個耐人尋味的數字：開發者對 AI 準確度的信任，從去年的 40% 掉到了今年的 29%。

八成的人在用，真正信得過的卻不到三成。乍看矛盾，其實這正是成熟的訊號。

一年前，大家對 AI coding 充滿新鮮感，覺得「哇它好厲害」。一年後，大家都被 agent 坑過了——它自信滿滿地寫出不存在的 API、過時的語法、看起來對但其實錯的邏輯。信任度下降，不是因為 AI 變差了，而是因為大家更了解它的極限了。

還有一個數據很值得注意。SWE-bench 是目前最被認可的 AI coding benchmark：

• SWE-bench Verified（經過人工驗證的測試集）：最好的 model 可以拿到 ~72%
• SWE-bench Pro（更嚴格、更貼近真實世界的版本）：最好的 model 只拿到 ~23%

72% 跟 23% 的差距，就是「demo 很厲害」跟「真實世界很難」之間的距離。

Gartner 更直接預測：40% 的 agentic AI 部署會在 2027 年前被取消，原因是成本上升、價值不明確、或風控不足。

這些數據告訴我們什麼？Agent 很強大，但不是魔法。用好它，需要方法論。這就是 Agentic Engineering 存在的意義。

為什麼 Agentic Engineering 比傳統寫 Code 更難

這是 Agentic Engineering 最反直覺的地方：用 AI 幫你寫 code，居然比自己寫還需要更高的工程紀律。

原因藏在 context 裡。傳統寫 code 的時候，你可以在腦子裡 hold 住很多隱性的 context——你知道公司用什麼 tech stack、你知道這個 API 的 quirks、你知道上次那個 bug 是怎麼修的。這些資訊不需要寫下來，因為它在你腦子裡。

Agent 寫 code 的時候，它什麼都不知道。它只知道你告訴它的東西。如果你沒有把 coding conventions 寫在 CLAUDE.md 裡，它就會自己發明一套。如果你沒有寫測試，它就不知道自己寫錯了。如果你沒有 CI/CD pipeline，你就得自己一行一行看它寫的 code。

所以 Osmani 說的 paradox 是真的：

Agent 越自主，你的工程基礎設施就需要越完善。

具體來說：

• 沒有自動測試？ Agent 不知道它寫的 code 是不是對的。你也不知道。
• 沒有 linting/formatting？ Agent 每次寫出來的 code style 都不一樣。
• 沒有清楚的文件？ Agent 會自己猜你的架構意圖，通常猜錯。
• 沒有 CI/CD？ 你得手動驗證每一次 agent 的產出。

在傳統開發裡，這些東西是 nice-to-have——有當然好，沒有也活得下去。在 Agentic Engineering 裡，它們是 prerequisites——沒有這些，agent 根本沒辦法正常工作。

但反過來想，這其實是好消息。

如果你是那種一直堅持寫測試、維護文件、設定 CI/CD 的「無聊工程師」，恭喜你——你在 agent 時代突然變成最有價值的人了。因為你的工程基礎設施不只讓人類團隊工作得更順暢，現在還讓 AI agent 工作得更好。

你花在「boring engineering」上的每一分鐘，在 agent 時代的 ROI 都翻倍了。

這個系列要帶你去哪裡

這是一個 14 篇的系列，分成四個 Part：

Part I：基礎認知（你在這裡）

1. Agentic Engineering 是什麼（本篇）
2. 從「寫 code 的人」到「管 agent 的人」——工程師角色的重新定義
3. 2026 年工具全景圖——Cursor、Claude Code、Codex、Devin 的深度比較

Part II：核心技術

4. Context Engineering 深度解析——你餵給 agent 的 context 決定一切
5. Spec-Driven Development——寫給 agent 的需求文件
6. Agent 產出品質保證——怎麼知道 agent 寫的 code 是對的
7. 從 Prompt 到 Production——完整實戰紀錄
8. CLAUDE.md 大師班——設定檔系統設計

Part III：系統設計

9. MCP 與 A2A 協議實戰——讓 agent 連接更大的世界
10. Multi-Agent 編排——多 agent 協作的實務
11. Token 經濟學進階——成本控制
12. Agent 安全網設計——當 AI 有 sudo 權限

Part IV：組織與未來

13. 團隊導入——從個人到團隊的文化轉變
14. 未來展望——工程師還需要寫 code 嗎？

每一篇都可以獨立閱讀，但它們也是一本書的章節——從「這是什麼」到「怎麼做」到「怎麼做好」到「怎麼帶團隊一起做」。

如果你已經讀過我之前寫的 Agent First 日常，那篇是我個人經歷的描述。這個系列則是方法論的整理——我把一年的經驗，提煉成一套可以複製的框架。

Takeaway

1. Agentic Engineering 不是 Vibe Coding 的升級版，而是一個要求更高工程紀律的新學科。Karpathy 用這個詞取代 Vibe Coding，是因為「靠直覺」的方式在 production 環境裡行不通。

2. 80% 的開發者在用 AI agent，但只有 29% 信任它。這個信任缺口不會靠「更好的 model」來填補，而是靠更好的方法論——Context Engineering、Spec-Driven Development、品質保證流程。

3. 好消息是：紮實的工程基礎在 agent 時代比以前更有價值。自動測試、CI/CD、清楚的文件——這些「無聊」的工程實踐，現在不只服務人類團隊，也是 agent 能否正常工作的前提。

---

下一篇：從「寫 code 的人」到「管 agent 的人」：工程師的角色重新定義