[AI 分享] 主流AI熱詞一次搞懂

 [AI 分享] 主流AI熱詞一次搞懂

摘要：從Token、Prompt到RAG、Agent與工作流，系統拆解AI熱詞的由來與用途。

內容:

此貼文的核心目標，把目前主流的 AI 熱詞講清楚，幫助使用者之後再遇到各種新名詞時，不再感到焦慮。整體拆解方式很清楚：每一個概念都回答兩件事，第一，這個詞為什麼會出現；第二，它實際解決了什麼問題。

一開始先講的是 Token 和 Context Window。AI 並不是像人一樣直接閱讀整段文字，而是會先把輸入內容拆成更小的資訊單位，這些單位就叫 token。模型一次最多能處理多少 token，就叫 context window，也就是上下文視窗。像常見的 128k 上下文，本質上就是 AI 一次能看多少資訊。不過，視窗大不代表一定更聰明，因為資訊太少答不出來，資訊太多也可能被干擾。真正影響效果的，不只是模型能看多少，而是使用者怎麼把任務說清楚。

接著出現的是 Prompt。大家很快發現，同樣一件事，不同問法，AI 回答的品質差很多。隨便問一句，可能得到一堆空泛內容；但如果明確交代角色、任務、背景、輸出格式與要求，結果就會明顯更具體、更有結構。所謂 prompt engineering，本質上不是什麼神秘咒語，而是替 AI 寫一份工作說明書，讓它更準確理解任務。

但 Prompt 再強，也解決不了一個根本問題：AI 不知道的事情就是不知道。像公司內部文件、專案程式碼，或昨天才發生的新資訊，如果模型沒見過，就只能猜，於是容易出現一本正經胡說八道的情況。這時就引出了 RAG。

RAG（檢索增強生成） 的邏輯很簡單，就是不要讓 AI 只憑記憶回答，而是先查資料，再根據資料生成答案。做法通常是先把文件、手冊、程式碼等內容放進知識庫，當使用者提問時，系統先檢索相關資料，再交給 AI 回答。這樣產生的答案就不再只是猜測，而是有來源依據。

RAG 也帶出了幾個常見概念，包括 Embedding、向量資料庫、知識庫。Embedding 可以理解成把文字轉成一串數字，方便電腦比較語意距離。這樣即使兩句話字面不同，只要意思接近，系統也能找出相關內容。向量資料庫就是專門存放這些向量，幫助快速找到語意相似的資訊。RAG 的重要性在於，它讓 AI 第一次具備了接入外部知識的能力。

不過，傳統 RAG 更像一次性的搜尋：問一次，查一次。面對複雜問題時，這通常不夠，所以又出現了 Agentic RAG。它不像單純搜尋引擎，而更像研究助理，能判斷資料夠不夠、不夠就換關鍵字繼續查、必要時拆成多個子問題，甚至交叉比對不同來源。到了這一步，AI 已經不只是被動回答，而開始有一點主動研究的能力。

接下來的熱詞是 Tool Calling。RAG 讓 AI 會查資料，但還不代表它能真的做事。Tool Calling 的意義在於，讓 AI 從「提供建議」變成「執行動作」。例如查詢訂單狀態、執行程式碼、讀取日曆，這些都可以透過呼叫外部工具完成。這代表 AI 不只是告訴你怎麼做，而是真的幫你做。

但問題又來了：現實中很多系統沒有 API，或即使有 API，也很難整合。大量工作其實發生在網頁、後台、管理系統中，例如點按鈕、填表單、上傳檔案、切換頁面，這些並不是單純呼叫 API 就能完成的，因此又發展出了 Computer Use。

Computer Use 的概念，是讓 AI 像人一樣操作電腦。它不只是呼叫工具，而是能看懂畫面、理解介面，接著用滑鼠和鍵盤去執行操作，例如打開網頁、點擊按鈕、輸入內容、提交表單、下載或上傳檔案。這對於老舊系統、沒有 API 的內部平台特別重要，因為它讓 AI 有機會進入那些原本只能人工處理的工作流程。不過這個方向也有不少難點，例如介面變動、按鈕識別錯誤、驗證碼、安全與權限等問題，所以想真正穩定落地，還需要很多工程能力支撐。

當 AI 既能查資料、又能呼叫工具、還能操作電腦時，下一個問題就是：它能不能自己完成一個複雜任務？ 這就是 Agent。

很多人把 Agent 理解成更聰明的聊天機器人，但其實不準確。Agent 的關鍵，不是聊天，而是它能圍繞一個目標，自己拆解步驟、選擇工具、執行動作、觀察結果，再依結果調整下一步。普通聊天機器人是你問一句它答一句；Tool Calling 是你叫它做一件事，它去呼叫一次工具；Agent 則更像你給它一個目標，它自己想辦法往前推進。

這也是為什麼 Agent 最早在程式設計領域爆發得特別快。因為程式碼有清楚的檔案結構、具體的錯誤訊息、可執行的測試、可追蹤的版本控制，很適合 Agent 這種「計劃—行動—觀察—調整」的循環模式。像現在的 AI IDE、AI Coding Agent，以及延伸出的 Vibe Coding，本質上都在往這個方向走：由人描述目標，AI 生成實作，人再負責驗收、調整與把關。

但 Agent 越強，風險也越大。它可能會誤改檔案、刪除內容、生成不安全的程式碼、消耗大量 token，甚至做出表面能跑、實際不敢上線的結果。因此，真正要把 Agent 用到生產環境，光靠模型能力不夠，還需要一整套外部約束，這就引出了 Harness Engineering。

Harness Engineering 可以理解成給 Agent 套上的安全帶、方向盤、儀表板與煞車系統。如果模型是發動機，Harness 就是整輛車的控制系統。它通常包含許可權控制、工具白名單、執行沙箱、操作追蹤、錯誤重試、輸出驗證、人工審批、成本控制、安全邊界、回滾機制與評測系統等。核心目標不是讓 Agent 看起來更聰明，而是讓它變得安全、可控、可追蹤、可驗證。這也代表 AI 落地的難點，正從「模型夠不夠聰明」轉向「系統夠不夠可靠」。

最後，內容進一步帶到 Workflow（工作流）。因為企業裡的真實工作，通常不是單一 Agent 就能完成，而是一整條流程。例如客戶提交表單後，系統要先讀表單內容、判斷客戶類型、生成跟進建議、分配給合適人員、寄送通知，再同步到其他系統。這時 AI 不再只是單點能力，而是要嵌進整個業務流程中，成為流程的一部分。

整體來看，這支影片是在幫大家建立一條清晰的 AI 演進脈絡：從最早理解輸入資訊的 token 與 context window，到讓任務描述更清楚的 prompt；再到讓 AI 具備查資料能力的 RAG，延伸到能主動研究的 Agentic RAG；接著從 Tool Calling 到 Computer Use，讓 AI 從回答問題走向實際操作；再往上發展成能自主拆解與執行複雜任務的 Agent；最後再用 Harness Engineering 與 Workflow，把 AI 真正帶進可控且可落地的企業場景。

簡單說，這些熱詞不是彼此割裂的新名詞，而是一條很清楚的能力升級路線：AI 先學會理解，再學會查資料，再學會用工具，接著學會操作系統，最後進入真實工作流程。