最後更新時間： 2026 年 09 月 06 日
你是否會好奇為什麼別人的AI Agent（AI 代理、AI助理）那麼厲害，我的卻不行？AI代理那麼厲害，背後到底是怎麼運作的？
雖然對一般使用者來說，不用理解模型訓練的每個細節，也不必知道演算法的原理，但是，如果對它的運作方式有基本概念，就能更流暢的使用AI Agent。
而且當Agent表現不如預期時，也更有概念要如何改善，不用再求人。
本篇將用簡單易懂的方式帶你了解Agent基本的運作原理，並提供一些使用時該注意的細節，提升你的AI協作力！快來看看吧！
Agent的構成：語言模型與運作框架
大型語言模型（Large Language Model，LLM）是透過大量的資料，經過訓練後的結果，不過說穿了，他的功能只有一個：透過上下文來預測、生成輸出結果。
但這明顯和平常使用AI的經驗不同，因為我們現在可以用AI上網查資料、寫報告、生成投影片……，怎麼看都不像是只有一個單一功能。
其實是因為現在使用的各種AI服務，除了提供作為大腦的語言模型之外，還設計了大語言模型的「運作框架」，這套框架的工程就是所謂的Harness Engineering。
而這個語言模型加上運作框架的組合就是所謂的Agent：
- 大型語言模型：根據上下文預測和生成輸出
- 運作框架：控制和維持Agent運作、執行工具、管理記憶和上下文等等
接下來，我們先針對大型語言模型本身講起。
LLM運作的基本：機率與Token
雖然語言模型非常強大，但是它運作的方式卻出乎意料的笨。
簡略的流程如下：當我們送出提示詞（prompt）後，會先將提示詞換成詞元（token），然後將token作為輸入放進大語言模型進行運算，計算輸出token的機率，最後選一個作為輸出。
LLM生成輸出的簡略流程如下：
- 當送出提示詞（prompt）後，先將提示詞換成詞元（token）
- 將整串token作為輸入放進LLM進行運算，計算下一個token的機率分布
- 依據不同的參數設定選一個做為輸出的token
- 將前一步的輸出token接在原本的輸入後面，做為新的輸入串，重新回到第2步產生下一個輸出，不斷這個過程直到出現結束條件。
- 將token還原成文字呈現給人看
這裡有兩個重點：機率跟token。
機率
機率是在模型訓練過程決定的，會受到訓練資料的影響。
使用時必須注意，語言模型的輸出基本上就是不斷的透過機率猜測下一個token來回答問題，所以答案有隨機性。
這也是為什麼在某些問題上AI顯得特別笨，例如多位數的加減乘除，因為他們並不是真的計算，而是透過機率產生結果。
此外，因為訓練的資料並不100%是正確的，所以模型也有可能學到錯誤的資訊。
而這個隨機性、還有錯誤的學習資料，很可能就是導致模型產生幻覺（Hallucination）的原因。
Token 詞元
我們可以把Token視為是大語言模型運算基本單位，不過一個Token並不直接代表一個中文/英文字。
之前有一個問題是大語言模型連草莓的英文，strawberry，有幾個r都會回答錯。
這也跟token有關，因為大語言模型並不真的「看」到幾個r來回應，而當時有一個讓模型回答正確的方法是改成問：s-t-r-a-w-b-e-r-r-y有幾個r，這樣回答就會是對的，其實是因為這樣問的話，每個單字就會變成獨立的token。
實際上token可能代表多個字或是不到一個字，如下圖：
想要親自測試文字跟Token的轉換的話，可以到OpenAI的Tokenizer試試看strawberry被拆成了幾個token？
對於透過API來使用AI的人來說，Token還有另一個重大的意義，就是他是計價收費的標準。
使用API的話，會依照你使用了多少輸入Token和輸出Token來收費，完全按照你的使用量來計費，和一般使用者的訂閱制是截然不同的收費方式。
影響AI回答的關鍵：上下文 Context
有一種會讓人覺得AI笨笨的情況是：他的回答總是沒有回答到「點」上，講了落落長，但沒有直擊重點。
這種情況常常是源於他沒有足夠的上下文（Context），所以只會給你「最有可能的」答案，而不是針對你的情況給出最「適合你的」答案。
舉例來說，「幫我寫一封請假的信」就是一個缺乏清楚上下文的提示詞，沒有說明請假對象、原因、語氣和你的身分，所以AI只能憑空猜測，就很可能給你一些比較空泛通用的回答。
這時候只要在提示詞提供足夠的資訊就可以讓回答的品質大大提升，可以好好針對你的情況來「客製化」回答問題，而這個寫好提示詞的工作就是提示詞工程（Prompt engineering）。
從原理來看，這些背景，如：你的身分、語氣等等，出現在AI運算的輸入時，自然地就會影響輸出的機率，所以更可能答出適合你的答案。
順帶一提，提供給AI參考的截圖、檔案等也會成為上下文，並不是只有聊天文字是上下文而已。
所以，除了好的模型之外，好的上下文也是相當重要的，這點不論是單純和AI聊天，還是進階的使用專案、CLI工具（如：Claude Cowork、Codex、Claude Code等等），都是一樣的，只是上下文要如何提供的差異而已。
除了我們對話提出的提示詞之外，還有針對Agent設定的系統提示詞（System Prompt），通常並不會讓使用者看到，這是模型開發商預先設計好，用來規範模型行為，和提供模型一些必要的資訊。
如果對模型商的系統提示詞如何撰寫有興趣，可以參考看看Claude公開的系統提示詞。
所以一個對話的一開始，即使還沒有輸入任何提示詞，就已經會有系統提示詞作為上下文了。
AI的記憶力上限：Context Window
雖然提供好的上下文有助於AI更好的回答，但是AI的記憶力是有上限的。如果上下文太長，就有可能超出極限，這個極限我們稱之為上下文視窗（Context Window）。
以前（其實也沒有很久以前），ChatGPT-3.5剛問世的時候，比較常見聊天聊到一半他就忘記前面聊過的內容，或是聊到一半他就停止不再輸出，這就是因為對話已經超過上下文視窗了。
可以想成是一個人帶著A4大抄去考試，考試的題目就是最新的提示詞，所有的上下文則寫在這份大抄上，協助考試。
隨著不斷來回對話，當這張A4寫滿了，就必須移除部分內容，這樣才能騰出空間放新的對話，通常會自動移除最舊的內容。
不過，現在上下文視窗隨技術優化越來越大，這個大抄越來越大張，加上現在有很多額外工程協助解決這個問題。
例如：偵測到已經快要到極限時，自動總結（壓縮）前面談話的重點，在後續對話中改成用這個總結來代替原本的對話內容。
值得一提的是，即使沒有達到上下文視窗，隨著上下文變多、變混亂，甚至有跟現在問題無關或矛盾的內容，都會讓AI回答的品質變差，這個現象稱之為上下文腐化（Context Rot）。
就像是那張大抄雖然還沒寫滿，但塞了一堆無用的資訊，結果就是垃圾進、垃圾出（Garbage in, garbage out），模型運算出一些爛回答。
為了避免這個情況，可以養成一個好習慣，就是不要一直在同一個對話裡問問題，如果一個問題已經有了答案，下一個不相關的問題就開新的對話。
因為新的對話會使用新的工作階段（Session），也就是會用全新的空白大抄重新開始。
駕馭模型的運作框架：Harness Engineering
Agent除了擔任大腦的語言模型之外，另一個重要的部分就是維持Agent良好運作的框架了，也就是所謂的Harness（Harness原意為馬具，這裡用來指駕馭模型的運作框架）。
這個框架要負責的事情很多，比如說：讓Agent可以使用工具、管理記憶系統、處理模型看到的上下文、維持Agent多步驟的行動等等。
可以說是除了生成之外的一切都交給這個運作框架了，而各家模型商可能會有不同的運作邏輯，以下會舉一些常見的功能逐一簡略說明，讓大家有基本的概念。
給AI更強的能力：使用工具
現在所有Agent必備的功能就是要讓模型可以使用工具，而最常見的工具就是網路搜尋。
每個模型都有它的出廠日期，當你問時效性比較新的問題，因為她的訓練資料中沒有答案，他就必須要透過網路來取得最新資訊。
所以網路搜尋就是一個必要的功能，但是，實際上模型是怎麼使用網路搜尋的呢？
要讓模型能夠使用工具必須要克服以下幾個問題：
- 讓AI知道有哪些工具可以使用
- 讓AI生成使用工具的指令
- 運作框架依據指令執行
- 執行結果送回給模型作為上下文
- AI依據結果繼續生成輸出
為了解決上述幾個問題，Harness就要做一些必要的處理。
首先要在新的對話告訴AI可以使用的工具清單，這份清單通常由Harness自動處理，使用者不用在提示詞中額外說明。
這個清單可能會說明了工具名稱、工具的描述（使用工具可以做什麼、什麼時候使用這個工具等）、工具所需要的參數等等。
再來要偵測模型是否要使用工具，所以要偵測模型生成的輸出是否符合執行工具的指令。
例如詢問「今日台股表現如何？」，AI可能會生成以下指令：
{
"tool":"WebSearch",
"arguments":{
"keyword":"台股大盤 收盤表現"
}
}
當Harness偵測到執行工具的指令後，實際去執行網路搜尋，再把執行結果加入新的上下文作為輸入，讓AI繼續生成輸出。
中間林林總總的處理過程很多都是在背後運行，不需要給使用者看到的，所以平常使用時並不會知道有這麼多工程。
現在除了一些模型商預設好的工具之外，還可以依據自己的需要來安裝或是打造自己的工具，其中最常見的工具類型就是Agent Skills、MCP（Model Context Protocal，模型上下文協定）。
使用工具時，最常見的問題就是：明明給了工具，但模型就是不會用欸？
這時候根據運作的邏輯，就可以檢查兩個重點：
- 工具有沒有正確安裝
- 工具的描述是否清楚
當工具沒有正確安裝時，Harness給AI看的工具列表就沒有該工具的資訊，AI自然就不會使用。
另一種情形則是工具的描述太過模糊，AI可能覺得這並不是使用工具的時機，而選擇不使用，如果你的AI有時候會正確呼叫工具，有時候不會，很有可能是這個問題。
還有另一個常見的問題是你安裝了很多個工具，但工具彼此間的功能可能有一些重疊，甚至是重複，結果會導致Agent使用工具時會不知道要用哪一個，結果就是回答的品質不穩定。
AI的記憶系統
看到這裡，相信大家已經知道AI的每個工作階段有獨立的上下文視窗，也就是說每次對話的脈絡是不同的。
但是，有些資訊可能會需要跨對話的脈絡，最常見的例子就是關於你的個人資訊。
因為當AI知道你的個人資訊時，在回答時可以針對你的背景、你的偏好等等來回答問題。
以ChatGPT為例，你可以自己在設定中自己提供一些關於你自己的個人細節，你也可以開啟記憶功能，讓他自己從對話紀錄中，記錄下他對於你的認識。
這些記憶會記錄在額外的位置，等到新的工作階段開啟時，由Harness自動載入到上下文內。
管理AI的上下文：Context Engineering
我們已經知道上下文會強烈影響AI生成輸出的結果了，而AI Agent又有各式各樣的上下文來源：系統提示詞、記憶系統、使用者提示詞、工具的執行結果等等。
這些管理AI能「看到」哪些內容做為上下文的工程，被稱之為上下文工程（Context Engineering）。
其實前面也已經提到了很多上下文工程的內容，例如：工作階段一開始自動載入記憶系統的資料、整理工具執行結果做為新的上下文輸入、偵測上下文視窗自動壓縮等等。
由於上下文的提供會很大一部分影響AI輸出的表現，而且又有Context rot的現象，所以要怎麼在有限的Context window中放入有用、必要的資訊就變成了重要的課題。
而每個Agent的Harness是怎麼處理上下文的方式也不盡相同，我建議可以去看Claude Code的文件，他以互動的方式呈現Claude Code的Context window是怎麼樣隨對話累積的。
這是我覺得在呈現對話過程中，Context window到底放了哪些東西、哪些內容使用者不會在螢幕上看到、Harness還做了哪些Context engineering等等，最清楚的一個。
雖然每一家的Agent提供的功能不盡相同（雖然也彼此「參考」來參考去的，所以有很多相同的功能），Harness作法可能不同，但對於概念理解會相當有幫助。
這裡也要提醒大家，雖然Harness自動的管理上下文，但是像工具、記憶或指令的內容都可以定期去檢查一下，因為在修修改改的過程中可能會出現錯誤、過時、矛盾的內容。
總結
本篇將Agent拆成兩個部分：大語言模型和運作框架Harness。
分別介紹了模型的基本運作原理，包含Token、機率和上下文的概念；Harness如何架構了記憶、工具使用、上下文管理等等功能。相信讀完本篇文章的你對Agent能有更深一步的了解。
這些觀念也能夠破除一些對AI的「幻象」，他並不是什麼神奇魔法，而是一個結構謹慎的強大系統。
希望這些觀念能讓你更懂Agent，並有助於你更順暢的和你的Agent協作！
