大家都會用 AI 工具已經不稀奇了，把 know-how、工作脈絡重新設計成可以被 AI 協作、接手、維護的系統，那才是價值所在。
今年的 2026 Generative AI 年會，主軸是 Agent First，要談論把 Agent 接進真實工作之後，工程、產品、組織會長成什麼樣子。這次有兩個整天，三場年會主題：開發者年會、Vibe Coding 以及年會。開發者談 Harness、Vibe Coder 談規格與部署、年會談企業案例與重要趨勢。
今年的講座一樣非常精彩，這篇先整理第一天的兩個部分：開發者年會與 Vibe Coding。以下是一些現場筆記，也混雜一點個人心得。
開發者年會
最先開場的是開發者年會，聚焦在工程落地，怎麼把 Agent 做成可控、可驗證、可部署、可維護的產品系統。這次三位講者雖然切入角度不太一樣，但傳達出來的方向不約而同都有重疊的部份，個人認為蠻有趣的。
Harness 的本質
先建立一下背景：什麼是 Harness Engineering？
如果把模型想像成一個很強但不穩定的能力來源，那 Harness 就是包在模型外面的工程控制系統。它負責決定模型該看什麼、能做什麼、怎麼驗證結果、什麼時候修正，以及什麼時候停止。
Harness 的本質不是讓模型變強，而是讓能力可控。
這代表開發者的工作焦點正在改變：
- 以前：怎麼寫 prompt，讓模型愛聽
- 中期：怎麼給 context，讓模型看對東西
- 現在：怎麼設計系統，讓 agent 朝正確方向收斂
Harness 不是越多越好，context 也不是越大越好。過多 context 會稀釋注意力，甚至把錯誤資訊一起帶進去，反而成為幻覺來源。關於這點，有實際跑過流程的人應該都隱約感受過這個現象哈哈。
Loop 又是什麼
今年也開始有提到 Loop Engineering，Loop 可以先不用想得太高深，它本質上就是把 Agent 的工作流程做成「產出 -> 檢查 -> 修正 -> 再檢查」的回饋迴圈。
一般使用 AI 時，我們常常是丟一個問題，拿到一次結果，然後由人來判斷好不好。但 Agent 要進入工程或產品流程時，不能每一步都只靠人肉檢查；系統本身需要知道什麼叫做做對、什麼叫做做錯，以及錯了之後要怎麼修。
我的理解是，Agent 不應該只是生成一次就結束，而是要形成一個可以反覆修正、驗證與交付的迴圈。
比較完整的 loop 可以整理成：
- Guide：告訴 Agent 該怎麼做
- Generate：產出結果
- Sensor：檢查結果是否正確
- Fix：根據回饋修正
- Deliver：達到標準後交付
Agent 有時候會覺得沒問題就停了，所以需要自動觸發輸出、回饋、驗證與修正；tool call 之後也可以再接回饋驗證，而不是盲目信任結果。
有 sensor 的生成才會變成工程迴圈。
（但……對，大造詞時代，為什麼這件事需要被發明成一個新的 engineering 來描述 XD）
（我要開始主張，沒辦法寫成跟磚頭一樣厚的教科書的工程不叫工程）
關於 Context 的管理
第二天年會也有提及 context 作為個人或企業資產的主張，因此我這邊就忽略這部份，只提及開發者年會強調的重點：安全。
不要 100% 相信任何由 LLM 產生或轉述的資訊；絕對不能外流的東西，不應該直接進 context。
因為放進 context 的東西，你無法保證下次會以什麼方式流出，應該用內部系統設計處理，而不是單純丟給模型。
所以安全設計要回到系統架構：
- 想做什麼
- 能不能做
- 是否應該放行
- 哪些資訊只能用 reference
- 哪些操作需要權限檢查
- 哪些應該透過 system 路徑，而不是交給 agent 自由處理
Agent 能力 = 模型 × Harness × Context
模型本身很重要，但真正決定產品能不能落地的，是模型外面的系統設計，以及你自己掌握的 context。像專家使用哪些工具、需要哪些背景知識、產業 know-how 怎麼整理，這些都不是單靠模型能補齊的。
此外驗證也是 harness 的心臟，因為模型可能偏好自己熟悉的輸出風格，所以在整個流程裡面可靠的是外部、帶工具、可重跑的驗證。例如說：要讓系統能實際檢查結果，能跑測試就跑測試、能驗 schema 就驗 schema。
換句話說，沒有驗證機制的 Agent 只是比較會說話；有 sensor、constraint、可重跑驗證的 agent，才比較接近可維護系統。
這其實跟軟體工程蠻像的啊哈哈，因此更也能夠呼應後面年會所提及的「人的價值沒有消失，但位置變了」，這邊我看到的是軟體工程不會消失，它反而是 agent 工程建設的基礎，所以我蠻同意講者所說：
並沒有「xxx 已死」這件事，後者是基於前者的發展上，而非取而代之。
（數學是科學之母，已經很少職業是直接與數學相關，得利於現代工具的開發超過半數情境甚至不需要完全懂數學也能夠做工程，然而卻幾乎不會聽到「數學已死」的言論）
（對沒錯，上面是數學系出身的牢騷 XD）
（啊對販賣焦慮的人脛骨都去給飛旋踏板撞一撞）
Agent 進入產品的方式
Agent 嵌入產品分成兩種架構，很適合彙整成產品設計觀點：一是替客戶準備一個受管控的 agent 工作環境，二是把 agent 藏在服務後面。
前者主要著重的點是平台管理，需要訂定 workspace 邊界、成本、安全、context 控制。而後者就比較像是使用者照常操作產品，服務背後由 agent 判斷與執行。
另外還有個很重要的概念：維護。這三場其實都在提醒 agent 開發不是寫完 prompt、skill 就結束。寫完反而才是開始，後面會發生什麼事情才是關鍵。領域知識可以寫進 skill，但安全、放行、權限與操作邊界要由 app / platform 把關。上下文會腐爛，不該全部都記；這類東西如果沒有更新與遺忘機制，未來反而可能污染工作。不論未來還有什麼規範性文件，我的理解是這些都是需要維護、驗證、更新、淘汰的工程資產。
整體開發者年會心得
整體來說，軟體開發從原先叫模型出來做事的模式，進入到下個階段：是否能設計一套工程系統，用來控制模型、驗證結果、管理 context、保護權限、支援產品化。未來開發者的差異不只在會不會用 AI，而是在能不能設計出可靠的 harness、有效的 loop、乾淨的 context，以及可被重複驗收的 agent 工作流程。
模型差距縮小時，系統設計差距會被放大。
也就是說，以後大家用的模型可能差不多，但誰能設計出更好的 harness、驗證流程、上下文管理與安全邊界，誰的 agent 就更可靠。
目前已經不缺生成能力或工具了，反而是要把模型能力包進可控的工程系統裡，進行有意識的收斂。開發者年會就真的很開發者面向：agent 如何真的被開發、驗證以及部署，實至名歸。
濃縮條列一下：
- Agent 是系統工程
- Harness 的目標是可控
- Loop 裡一定要有 sensor，否則只是重複生成
- 驗證要外部化、工具化、可重跑
- Context 是能力來源，也是風險來源
- Agent 產品化時，安全與權限要靠架構，不要靠模型自律
唉好累，吃工程師這頓飯越來越難了。
Vibe Coding 主題
再來就是以 Vibe Coding 作為主軸的多個 20 分鐘講座。很明顯在補現實面，AI 可以很快做出東西，但做出來不等於能上線，也不等於能維護。這點跟去年相比，算是很大的差異。
最大的風險跟以往差不多
跟以往一樣，Vibe Coding 如果只是對 AI 說「幫我做某個功能」，那其實很像開盲盒。你不知道它理解了什麼、不知道它改了哪裡、不知道它有沒有誤傷其他地方。
這時候規格就變得很重要，流程上也可以檢視是否有做到這些事情：
- 講清楚為什麼要改
- 講清楚要改什麼
- 補上影響範圍
- 讓另一個 AI 來看也不會誤會
- 最後把提案、實作、歸檔串成流程
為什麼感覺就是一般軟體工程必須做的事情啊XD 但事實證明，就真的有團隊是完全不寫測試的，所以 AI 導入後也只是把原本的混亂放大。所以我常常在思考，如果對象是開發文化良好的團隊，這一切是不是本來就算理所當然？
Harness / Loop 開始進入實戰
雖說是 Vibe Coding，但這次都是資深硬底工程師，因此在現實層面講得非常具體，也幾乎可以接續上午開發者年會的深入主題，另外開出新的支線。Harness 和 loop 的延伸就是其中之一。
把 Harness 從概念變成實作：generator agent 負責產出，evaluator agent 負責測試、linter、檢查，再透過 agent looping 形成循環。
透過 loop，讓 AI 自己評估、自己修、自己升級。重點是要有明確結果、知道過程，也要讓它可以自己改程式。開發步驟也要盡量拆小，讓 subagent 去執行。換句話說，這其實也是在思考如何把人從流程裡抽掉。
不過要做到這件事，前提還是要先定義什麼叫做「修對」。如果沒有標準，AI 只是在反覆修改；有了標準，loop 才有可能真的收斂。
越是有機率性的東西，越需要用死板且嚴謹的方式規範且檢查。
另一個很有意思的方向是：不是什麼都適合交給廠商，企業基於此已漸漸開始發展內部平台與自建能力。
這跟接下來會提及的「context 是企業資產」接得起來。模型可以外部買，但資料、流程、分析 pattern、內部 know-how 不一定能外包。AI 平台不是單純買工具，而是要保留自己的判斷、資料與競爭優勢。
我很喜歡這類企業案例，觀點很務實又新鮮 XD 像是從銀行案例來看，有些東西如果交給廠商，可能會失去競爭優勢。尤其像市場資訊、競爭情勢、提高聲量這類能力，真正有價值的不是工具本身，而是分析方式、資料來源，以及行銷策略的調整等等。
經過一年，工作流變順了嗎
相信多數非軟體業、非科技業的團隊，在導入 AI 時，很多還是會以 AI 能不能讓工作流程變順暢作為主要考量。AI 很會生成，學習能力強的人也做了很多小工具，但這不代表工作流真的變順，變成工具還是工具，流程還是流程。
真正困難的是資料怎麼傳遞、責任怎麼接續、誰來 audit，以及 MCP 或工具鏈有沒有被監督。最麻煩的甚至不是壞掉，而是看起來好像可以用。因此在瘋狂生成的時代，AI 工具最大的風險之一反而是半能用、看似能用，最後沒有人知道它錯在哪裡。
AI 讓開發變快，但也讓我們更快撞上產品化、維運與風險控管的問題。
從小需求至內部系統
這次也有小需求逐漸長成內部系統的案例。我覺得其中兩個很直白的過程很值得寫下來：
- 好的命名是人跟機器之間的橋樑
- 人的權限不夠，AI 就也不能有權限
應該可以作為 vibe coding 小白的入門 slogan XDD
這跟 Agent 產品化非常相關。AI 不是魔法，它只是進入既有組織流程的一個執行者；如果資料模型、命名、權限邊界原本就混亂，AI 只會把混亂放大。因此要讓 AI 踏入流程以前，先整頓流程是最重要的事情。
我個人百分之兩百同意這個概念：AI 會把現在的狀態放大。
（再說三遍：AI 會把現在的狀態放大、AI 會把現在的狀態放大、AI 會把現在的狀態放大）
（有感受到怨念嗎？）
（再說最後一遍：若本來就一片混亂，AI 只會把混亂放大）
關於第一天講座整體收穫
整體感覺來說，第一天大多數內容都圍繞著「收斂」。我認為這次的 Vibe Coding 已經跟以往認知，或是大眾認知中的 Vibe Coding 不太一樣了哈哈哈哈。它開始有越來越多工程考量，不太是純靠氛圍的感覺。
能生成不等於能交付；能交付也不等於能長期維護。
所以第一天給我的收穫應該也可以收束成 Vibe Coding 的重點正在從做得出來轉向成 agent 也要自己收得回來。如果 Agent 要自己修，我們就要先定義什麼叫做修對；如果 AI 要進入產品與流程，我們就要補上規格、驗證、權限、觀測與維護這些基本功。
結果繞了一圈，還是回到軟體工程哈哈哈哈。
