近一年來，「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 的角色，就是協調這些能力，完成整個工作流程。 可以把它想像成企業中的專案經理。…
Category: AI
About AI
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。 例如：…
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） 精實理論中的七大浪費，在倉儲場景裡非常常見： 浪費類型 倉儲例子 等待 等主管簽核 搬運 重複搬棧板 動作 多餘走動 過度加工…
Token/s and Concurrency:
The Two Most Misunderstood Metrics in Enterprise LLM Deployment When evaluating Large Language Model (LLM) deployment options, many teams focus on GPU models and parameter counts—70B, 235B, 671B—while overlooking two metrics that actually determine whether a system is usable in real life: These two metrics directly affect: This article explains what Token/s and concurrency really…
Token/s 與並發：企業導入大型語言模型時，最容易被誤解的兩個指標
在評估大型語言模型（LLM）部署方案時，許多人會被顯卡型號、模型參數量（70B、235B、671B）所吸引，卻忽略了兩個真正決定「用起來好不好」的核心指標： 這兩個指標，直接決定了： 本文將從「工程實務」的角度，說清楚這兩個概念，以及企業在規劃本地或私有化 LLM 時，應該如何正確看待它們。 一、什麼是 Token/s？它其實就是「AI 的輸出速度」 1. Token 是什麼？ 在 LLM 中，模型不是一次輸出一句話，而是一個 Token 一個 Token 地生成內容。 模型的所有「思考與輸出」，本質上都是 Token 的連續生成。 2. Token/s 的實際意義 Token/s = 模型每秒能生成多少 Token 舉例來說： Token/s 不影響模型會不會回答對，但會直接影響： 二、Token/s 與使用者體感的真實關係 實際使用 LLM 時，使用者會感受到兩個時間點： 這兩者常被混在一起，但意義完全不同。 實務比較範例 假設模型要輸出 400 Token： 情境 TTFT Token/s 總等待時間 A 0.5 秒 10 約 40 秒 B 3 秒…
Running OpenCode AI using Docker
A Practical, Reproducible, and Enterprise-Ready Implementation Guide AI coding tools such as OpenCode AI can significantly improve developer productivity. However, installing them directly on developer machines quickly becomes problematic in team or enterprise environments: This guide shows how to run OpenCode AI inside a Docker container, following best practices for security, reproducibility, and enterprise governance….
使用 Docker 實際運行 OpenCode AI
一個可重現、可控、可維運的 AI Coding 環境實作指南 AI Coding 工具（如 OpenCode AI）若直接安裝在開發者本機，雖然方便，但在團隊或企業環境中，往往會帶來： 本文將示範 如何依照實務最佳做法，使用 Docker 建立一個可實際運行的 OpenCode AI 容器環境，讓 AI Coding 工具成為一個 可管理的工程元件。 一、整體設計目標 本實作的設計目標如下： 二、專案目錄結構 建議建立一個乾淨的目錄： 三、Dockerfile（核心實作） 以下是一份 可直接使用的 Dockerfile，已包含實務上必要的修正與安全考量。 四、Build Image 建立 build.sh： 執行： 五、執行容器（關鍵實作） OpenCode AI 需要使用者的認證資料，這些資料 必須存在主機上，再掛載進容器。 1️⃣ 主機端準備（只做一次） 登入一次 OpenCode（或依你實際使用方式）後，通常會產生： 2️⃣ run.sh（正式使用方式） 執行： 六、實際使用情境 進入後，你會在容器內： 這讓 OpenCode AI 的行為符合： 「工具可丟棄，資料留在主機」的雲原生設計原則 七、為什麼這種做法適合企業 ✔ IT…