Agentic AI

長期以來，AI 代理程式雖然能思考、能寫碼，但在作業系統與應用程式之間，總像隔著一層玻璃。透過 Obsidian 1.12.x 全新釋出的 CLI 工具，AI 終於擁有了能直接操作 UI 的「手腳」。

在完成 v1.1.0 的「評測先行」與「Wing Group」基礎後，我對方法論的可行性邊界產生了更深的思考。這場 v1.2.0 的升級，不僅是內容的增補，更是一場關於「組織靈魂」的重構——我們將其定義為 「有機賦能 OS (Organic Empowerment OS)」。 這篇文章記錄了這場從質疑、提案、計畫到實作的完整歷程。 一、 核心質疑：為什麼需要 v1.2.0？ 在實戰演練中，我發現了幾個致命的空白： 分類的死角：傳統「製造、醫療、零售」的分類太平面。一家具備電商靈魂的傳統製造廠，到底該定位在哪？ 流程的盲信：我們設計了 CoE 指導手冊，但如何確保這些流程不是 IT 部門的「自嗨」，而是真的能在業務第一線產生效能？ 動力的來源：如果轉型動力只靠 KPI，那它注定會失敗。我們需要一種更「有機」的方式讓 AI 在組織中生長。 二、 提案亮點：從「標籤」轉向「坐標」 在 v1.2.0 提案書 中，我提出了幾個翻轉性的想法： 1. 二維轉型矩陣 (2D Matrix) 不再給企業貼「產業標籤」，而是給予「動態坐標」： Y 軸：容錯維度 (高端合規 vs 開放創意)。 X 軸：數據成熟度 (遺留系統 vs 數位原生)。 這讓「混血業態」找到了自己的戰位。 2. 五大遺傳密碼 (Genetic Code) 我們解構出影響轉型的五大屬性：容錯成本、數據熵值、任務同質化、決策敏捷度、先行者密度。這就是企業的 AI DNA，決定了轉型的物理極限。 3. 指標百科 (Metrics Encyclopedia) 為了對接 CEO 儀表板，我們定義了四個頂層實徵指標： 職能位移率：先行者不累，流程才叫對。 知識資產化速率：會議從資產的「終點」變成「起點」。 去中心化成功頻次：非 IT 部門自主解決問題的次數。 決策證據密度：從「我覺得」走向「AI 實證驅動」。 三、 實作經驗：與 AI 協作的版本控制之道 這場 v1.2.0 的升級過程，本身就是一次 「Agentic Writing」 的深度實踐。 ...

昨天才剛完成《企業生成式 AI 轉型全書》的 v1.0.0 基礎版本，今天在與 AI 代理人進行了三個跨產業案例（製造、電商、醫療）的模擬演練後，我立刻意識到：「理論在與現實碰撞的瞬間，才真正開始產生生命力。」 這篇文章記錄了我如何將三個核心實戰想法注入 v1.1.0，以及這場「寫作即實驗」的進化過程。 一、 為什麼 v1.0.0 還不夠？案例演練帶來的「實戰壓力測試」 在 v1.0.0 中，我們建立了完整的理論支柱，但當我實際模擬「龍誠精密」的面試、或是「星辰康復」的醫療流程再造時，幾個深水區問題浮現了： 需求迷霧：部會或企業常說「幫我導入 AI」，但沒人說得出「成功長什麼樣子」。 學習抗性：強迫員工上課是沒用的，他們只關心這東西能不能幫他解決手頭上的麻煩。 資料沈睡：高品質的資料往往鎖在老師傅的腦袋或發黃的紙本裡，而不是數位化的 PDF 中。 這促使我們透過與 AI 持續對話，快速迭代出了 v1.1.0。 二、 v1.1.0 的三大核心躍遷 這是我在這次升級中，最想分享的三個關鍵補充做法： 1. 評測先行 (Evaluation-First)：以「考卷」定義「需求」 傳統做法是「先有系統再測試」，但在 AI 領域，這會導致資源浪費。 我提出 EDRA (Evaluation-Driven Requirement Alignment) 模式： 核心觀點：如果企業寫不出 100 題「期望 AI 達標的測試題」，就不准啟動資料整備。 抗模型歸零：模型每年都在變，但「業務考題」是企業最穩固的資產。考卷一旦建立，無論底層換成 GPT-5 還是 Llama-4，企業都能瞬間校準出最優路徑。 2. Wing Group 與分享式導入：讓學習與需求脫鉤 AI 變化太快，制式培訓永遠跟不上。我設計了 Wing Group 的敏捷機制： 小而美：2-3 人的特遣隊，週週實驗新工具，不限工作，甚至涵蓋生活。 分享式循環：產出 Simple Report 歸檔至公用目錄。 隨選隨學：核心價值在於「當員工產生需求的那一秒，隨時有案例可查」。這消弭了參與壓力，讓 AI 知識像電力一樣，開關一撥就有。 3. 共付式生活補助：利用「不拿白不拿」的心理補償 這是我對變革管理最直擊人性的設計： ...

哈爸碎碎念： 寫一本書不難，難的是如何讓這本書「動起來」。最近我完成了一本關於《企業生成式 AI 轉型》的小書，書名是「企業生成式 AI 轉型全書：從知識底座到自主代理人的實踐路徑」，但這次實驗最有趣的地方，不在於那幾萬字的文字產出，而是我如何引導 AI 將這些文字轉化為一套可執行的「轉型作業系統 (OS)」。 1. 源頭：從「全書 (Book)」開始 這場實驗的起點很單純：我想把對企業導入 AI 的所有思考結構化。我們從第 1 章的「為何而戰」寫到第 6 章的「產業實戰」。這本書提供了轉型的 「核心引擎 (Engine)」 與理論基礎。 但寫完後我發現，書本對企業主來說太厚了，它需要更具備「侵略性」的呈現方式。 2. 工具化：Book -> Guide -> Schema 的活化過程 我讓 AI 擔任「CoE (卓越中心) 主管」，對它下達了一個關鍵指令：「把書裡的知識，變成你隨時可以調用的技能 (Skill)。」 在這個過程中，我們延伸出了兩個關鍵組件： 實作指引 (Guide)：將書本理論範式化。它不再是長篇大論，而是 CoE 主管在不同階段（Week 1-16）該勾選的 「行動清單」。 診斷書 (Schema)：這是分析企業的 「數據規格」。在進入任何公司前，先透過這份診斷書把企業的體質數據化。 至此，Book (理論) → Guide (流程) → Schema (接口) 的三角架構正式成型。這不再只是文章，而是一套數位轉型的標準協定。 3. 測試：虛擬企業的壓力演練 為了驗證這套 OS 是否管用，我們在「數位實驗室」裡生成了三個性格迴異的病患（虛擬個案）： 龍誠精密：傳統製造業。挑戰是「老師傅的經驗傳承」與「數據沙漠」。 全球脈動：跨境電商。挑戰是「創意的無限擴張」與「預算防線」。 星辰康復：醫療機構。挑戰是「零容忍的精準」與「極端的法律責任」。 這是我覺得最具價值的部分。每一場演習都像是在對方法論進行「壓力測試」，讓我們看到同一個計畫在不同產業樣態下，會產生完全不同的執行變數。 4. 閉環：邁向 v1.1.0 的自我進化 演習結束後，我們發現診斷書漏掉了「產業時鐘頻率」這個重要參數。於是，我們啟動了 「閉環修正 (Closed-loop Update)」。 ...

在構建「WalkGIS —— 全台散步地圖」專案的過程中，我與 AI Agent (Antigravity) 進行了一場深度的架構辯論。核心問題在於：當我們希望 AI 能像人類一樣理解地圖時，傳統的 GIS 資料庫還是最好的選擇嗎？ 這篇文章記錄了我們如何從傳統的 SpatiaLite 方案，轉向一個更輕量、更適合 LLM 的 “Text-based GIS” 架構。 1. 痛點：AI 讀不懂二進位碼 (Binary Blob) 起初，我們理所當然地選擇了 SpatiaLite 作為 SQLite 的空間擴充。它是業界標準，功能強大。但是，當我嘗試讓 Agent 讀取資料庫時，問題出現了： Agent: “我讀取到了 geometry 欄位，但它是 binary blob，我無法直接解析它的座標。” SpatiaLite 為了效能，將幾何資料存為二進位格式。這對 QGIS 很好，但對 LLM 來說，就像是一本無字天書。如果要讓 Agent 理解「后里馬場在哪裡？」，我們必須寫額外的 Python 程式碼去解碼它，這增加了依賴度與複雜性。 2. 決策：擁抱 WKT (AI-First Approach) 既然我們的目標是 “Agentic GIS”，為什麼不直接存成文字呢？ 於是，我們做了一個大膽的決定：棄用 SpatiaLite，擁抱 WKT (Well-Known Text)。 我們將 DB Schema 修改如下： CREATE TABLE walking_map_features ( id INTEGER PRIMARY KEY, name TEXT NOT NULL, -- geometry BLOB, <-- 傳統做法 (X) geometry_wkt TEXT NOT NULL -- 新做法 (O) : POINT(120.735 24.298) ); 這個改變帶來的紅利是巨大的： ...

這次來大阪旅遊，除了享受美食與美景，我還做了一個特別的實驗：練習使用生成式 AI (GenAI) 來輔助旅遊規劃與決策。這不僅僅是問 Gemini「大阪哪裡好玩」，而是更深入地利用 AI 的邏輯推演與資料整理能力，來解決旅遊中遇到的「資訊過載」與「複雜交通」問題。 以下分享我如何運用 NotebookLM 與 Agentic AI (Antigravity) 來理解大阪梅田站這座複雜的交通樞紐。 1. 出發前的深度規劃：Gemini 與 NotebookLM 的協奏曲 在規劃階段，我先利用 Gemini 進行初步的發散式探索，詢問關於一日行程、深度旅遊建議以及景點背後的歷史文化。 操作心法：我將 Gemini 生成的對話內容匯出成 Markdown 檔案個別匯入 NotebookLM 作為知識庫。 AI 產出： 視覺化理解：利用 NotebookLM 整理出的重點，可以產出更清楚、方便理解的旅遊重點圖表或指南。 這種「先用 Gemini 生成，再用 NotebookLM 固化知識」的方法，讓我對大阪的歷史脈絡與行程要點有了更紮實的認識，而不僅僅是走馬看花。 2. 行程當日的即時戰略：Agentic AI 的動態規劃 到了當天，行程往往需要彈性調整。例如第二天我想去「四個特定的地方」，但我只知道名字，不知道確切位置和順序。 我的指令：給 AI 四個地點（Samuhara 神社、@cosme、Motherhouse、Loft），請它確認地點、找官網、並建議順序。 AI 的價值： 地理邏輯判斷：AI 發現其中一家神社比較遠且早開，其他三家都在梅田商圈，因此建議「先去神社，再回梅田一網打盡」。 Google Maps 整合：它直接吐給我一個規劃好的 Google Maps 路線連結，點開就能導航。 3. 破解「梅田大迷宮」：結構化資訊的力量 大阪梅田車站被稱為「大迷宮」，地下地上錯綜複雜。一般的地圖看了一頭霧水，本來是一頭霧水，但跟 AI 詢問一些架構問題，能幫助自己理解交通網絡。 3.1 根據地圖詢問交通架構 我先給地圖照片問 AI：「大阪車站的交通架構是什麼？有哪些節點？」AI 幫我釐清了 JR 大阪站、阪急梅田、阪神梅田以及幾條地下鐵線路的相對關係，建立了我腦中的「骨架」。 ...

探討 AI 代理人化後的管理挑戰，提出「AI 安全官」概念，從行為意圖、特徵值到本質進行多層次安全監控。

探討 Agentic AI 帶來的安全挑戰，提出監控、即時阻攔與長線溯源結合的「全戰線」防禦機制。

為了解決機器人「已讀不回」的問題痛了一整晚後，我決定不只要修好它，還要讓它變聰明。本文分享如何利用 n8n 的 AI Agent 節點，結合 Google Gemini 模型與外部工具 (Calculator, Wikipedia)，打造一個不只能聊天，還能「思考」並「主動查證」的智慧助理。