近一年來，「AI Agent」幾乎成為生成式 AI 最熱門的關鍵字。 從各種展示影片中，我們可以看到 AI 自動查資料、自動操作系統、自動完成工作流程，甚至可以自行規劃任務，看起來彷彿已經進入「AI 員工」的時代。 然而，實際開始導入企業 AI 專案後，許多團隊很快就會發現： 真正困難的，不是讓 AI 變得更聰明，而是讓 AI 在企業環境中穩定、可靠且可管理。 本文將分享企業導入 AI Agent 時，我認為最重要的幾個設計觀念。 AI Agent 到底是什麼？ 很多人誤以為： ChatGPT = AI Agent 其實兩者差異很大。 一般聊天模型的工作，是回答使用者提出的問題。 而 AI Agent 則是在收到需求後，不只是回答，而是會開始思考： 換句話說，AI Agent 的核心不是聊天，而是完成任務（Task Execution）。 它更像是一位能夠規劃工作流程、協調工具與整合資訊的智慧助理。 AI Agent 並不是獨立存在 許多簡報都把 Agent 描述成一個萬能的大腦，但在真正的企業架構中，它其實只是整個 AI 平台的一部分。 一個成熟的企業 AI 平台通常包含四個重要能力： 而 AI Agent 的角色，就是協調這些能力，完成整個工作流程。 可以把它想像成企業中的專案經理。…
Blog
Enterprise AI Is More Than LLMs: Building a High-Quality RAG Knowledge Platform
Over the past two years, Large Language Models (LLMs) have rapidly transformed the AI landscape. More and more organizations are adopting AI assistants, enterprise chatbots, and intelligent knowledge systems to improve productivity and decision-making. However, after working on multiple enterprise AI projects, I’ve noticed a common misconception: Deploying a larger LLM does not automatically lead…
Why Enterprise AI Shouldn’t Call APIs Directly: Understanding the Real Value of MCP
Many recent discussions argue that MCP (Model Context Protocol) is nothing more than an additional abstraction layer that introduces unnecessary overhead. Some even claim that AI should simply call APIs directly. At first glance, this sounds reasonable. If an AI model can already invoke REST APIs or SAP RFCs, why introduce another protocol? The answer…
為什麼企業 AI 不應該直接呼叫 API？談談 MCP 真正的價值
最近看到不少人在討論：「MCP 只是多包一層 API，還會降低效能，直接讓 AI 呼叫 API 不就好了？」 這個問題其實很好，也是許多企業開始導入 AI 時最常提出的疑問。 我的答案是： MCP 不會讓 API 更快，它的目的也從來不是讓 API 更快。 從一個收貨流程開始談起 假設一家公司的收貨人員收到一張採購送貨單。 未來，他不需要登入 ERP。 只要打開 AI 助理： 「幫我確認這張送貨單能不能收貨。」 AI 先利用 OCR 辨識： 接著查詢 ERP。 最後回答： 「採購單存在，廠商一致，數量符合，目前可以收貨。」 甚至再問： 「請幫我完成收貨。」 AI 就直接完成 ERP 收貨作業。 看起來很簡單。 但真正的問題是： AI 要怎麼跟 ERP 溝通？ 最直接的方法：讓 AI 呼叫 API 很多人第一個想到的方法就是： 只要把 API 文件提供給 AI。 例如：…
PVE: Should You Use a Container (CT) or a Virtual Machine (VM)? A Practical Guide Based on Real-World Experience
When you start using Proxmox VE (PVE), one of the first questions you’ll likely ask is: “Should I deploy this service as a Container (CT) or a Virtual Machine (VM)?” When I first began working with PVE, I was attracted by the lightweight nature of Containers and tried to deploy almost everything as a CT….
PVE：到底該使用 CT 還是 VM？一次了解兩者的差異與適用情境
開始使用 Proxmox VE（PVE）之後，很多人第一個會遇到的問題就是： 「這個服務到底要建立成 CT（Container）還是 VM（Virtual Machine）？」 剛接觸 PVE 時，我也曾經因為覺得 CT 較省資源，而嘗試將各種服務都建立成 CT。直到後來開始部署 Docker、Mail Server 等較複雜的系統，才逐漸發現 CT 與 VM 並不是誰比較好，而是適用的場景不同。 本文整理兩者的差異，以及我目前實際使用 PVE 後的建議，希望能讓剛開始接觸 PVE 的朋友少走一些彎路。 什麼是 VM？ Virtual Machine（虛擬機器）可以想像成： 在一台電腦裡，再建立另一台完整的電腦。 每一台 VM 都有自己的： 因此 VM 幾乎與實體電腦沒有差別。 優點包括： 缺點則是： 什麼是 CT？ Container（LXC）則完全不同。 它並沒有自己的 Kernel，而是直接與 PVE Host 共用 Linux Kernel。 因此它更像是一個： 彼此隔離、但共用作業系統核心的 Linux 執行環境。 由於少了一層虛擬化，因此具有不少優點： 但限制也不少： CT…
When Lean Meets AI: From Value Stream Mapping to Intelligent Warehouse Transformation
In digital transformation initiatives, organizations often rush to talk about AI, automation, and system upgrades. But if the process itself has not been clearly understood, AI will only accelerate chaos. During the planning of our new facility, we intentionally returned to a classic operational tool: Value Stream Mapping (VSM) The Origin of VSM: Lean Thinking…
當精實管理遇上 AI：從 VSM（價值溪流圖）到智慧倉儲轉型
在企業數位轉型的過程中，我們常常會急著談 AI、談自動化、談系統升級。 但如果流程本身沒有被看清楚，再多的 AI 也只是「加速混亂」。 這也是為什麼在新廠規劃過程中，我重新回到一個經典工具： VSM（Value Stream Mapping，價值溪流圖） VSM 的源頭：來自 Toyota 的精實思維 VSM 起源於 Toyota Motor Corporation 的精實生產系統（TPS），由 Taiichi Ohno 等人發展。 它的核心只有一句話： 客戶願意付錢的才叫價值，其餘都是浪費。 這句話，看似簡單，卻足以改變整個企業運作邏輯。 什麼是 VSM？ VSM 不是單純的流程圖。 它是一張把「整條價值創造流程」攤開來看的圖，包含三個關鍵元素： 一張典型的 VSM 長這樣 與一般流程圖不同的是： 通常你會發現一件震撼的事： 真正創造價值的時間，可能只有 5%–10%。 VSM 的四個核心觀念 1️⃣ 價值（Value） 例如在倉儲作業中： 這些是客戶願意為之付費的。 2️⃣ 浪費（Waste） 精實理論中的七大浪費，在倉儲場景裡非常常見： 浪費類型 倉儲例子 等待 等主管簽核 搬運 重複搬棧板 動作 多餘走動 過度加工…
Planning and Key Considerations for IT Data Room Construction
A Practical Guide Based on a Medium-Scale Factory Deployment In new factory construction or major facility upgrades, the IT data room is often not considered a primary architectural element. However, it ultimately becomes the operational backbone of all digital systems.Design omissions at an early stage almost always lead to higher costs, operational risk, and downtime…
IT 機房建置的規劃與考量
——以中型工廠新建案為例的實務整理 在企業新廠建置或既有廠房升級的過程中，IT 機房往往不是建築的主體，但卻是 所有系統穩定運作的核心。一旦在設計初期忽略，後續補救的成本、風險與停機影響，往往遠高於一開始就規劃到位。 本文以一個 中型工廠、4 櫃等級、含 AI / GPU 應用的 IT 機房 為背景，整理在規劃階段必須納入的關鍵考量。 一、機房不是放伺服器的房間，而是一個「系統」 許多問題的根源，來自於一個錯誤認知： 「機房就是找個空間，把機櫃放進去。」 實務上，機房是一個由以下系統組成的整體： 這些系統 彼此高度耦合，任何一項單獨規劃，都可能導致整體失衡。 二、空間規劃：機櫃只是其中一部分 以 4 個 42U 機櫃為例，實務上需要考量的空間包含： 實務建議 機房最怕的不是太大，而是沒有餘裕。 三、空調與冷熱通道：熱氣要「有路可走」 1. 冷熱通道的本質 如果沒有妥善規劃： 2. 熱氣最後去哪裡？ 在中型機房中，常見做法是： 不一定要做到全封閉熱通道，但至少要： 四、電力系統：從市電到機櫃的完整邏輯 1. UPS 的角色要先想清楚 UPS 解決的不是「長時間供電」，而是： 在工廠環境中： 2. 為什麼 UPS 用 kVA，而不是 kW？ 實務選型時： 3. UPS 不等於插座排 這是一個常被誤解的重點： UPS…