（看到最後就會知道為什麼是這張圖了 XDD）

過去十五天，我們把 LLM 底層的運作機制大概講了一遍。我相信底層還有很多細節，技術也會持續進步，很快我們現有的認知又會翻新，但這沒什麼關係，至少這段過程我們一直都在。

理解了這些原理後，我們會知道原本看似黑盒的 LLM，本質上就是一套嚴謹的數學計算，也是在與 AI 互動時的「大腦」。這時很自然會引出另一個問題：「那『AI Agent』又是什麼？」

題外話：我也是剛好現在的公司產品名稱也有啥啥 Agent 的，才大概理解 Agent 表達的意思，反正就是「代理人」、「幫你做事的角色」嘛哈哈。跟這裡的 AI Agent 應該也是異曲同工之妙。

一、LLM 是 AI Agent 的一部分

先釐清我所理解的名詞定義：LLM 本身並不是 AI Agent，它是 AI Agent 中負責「大腦」的那一部分，它靜靜地被部署在伺服器的 GPU 顯存中。只要 Client 沒有發 Request，它連一個字都不會產生；Client 發了 Request，它做完運算後把結果吐回來，就立刻結束。如果 Client 與模型的互動只是「我發一句、他回一句」，那在處理真實世界的應用時，就會遇到一些問題：

1. 無狀態：模型記不住任何東西
   每次推論都是獨立的。如果沒有 Client 在背後幫忙把過去的歷史紀錄打包送過去做 Prefill，模型聊到第二句就會完全失憶。（當然狀態也可以保留在伺服器端，就像我們常見的 AI 網頁聊天平台那樣，但雲端儲存的安全與隱私疑慮，往往會讓許多開發者或企業卻步）
2. 無環境介面：模型沒有手也沒有腳
   模型沒有檔案讀寫權限，碰不到本機作業系統，也無法自己執行 git status 或 go test 這種指令。報錯了可能就會需要由人類複製貼上，解決了又得由人類複製貼回專案，很像早期 AI 剛推出時所使用的操作。
3. 無執行迴圈：模型無法自主推進與修正
   在面對更複雜的任務時，往往會拆成多步驟任務。修改程式碼往往會引發新的錯誤，所以單次對話時常無法一步到位。模型如果一次輸出完就收工，就會沒辦法自己觀察終端機反饋來調整策略，然後繼續推進直到目標達成。反而變成剛剛說的早期模式：我們複製結果給它，再把它的結果拿來執行。（雖然聽起來很笨，但一兩年前大家確實是這樣做的，而且即便只是這樣大家還是覺得很潮 XDD）

這三個問題點出了從「純粹的大腦」到「自主的 Agent」之間的鴻溝。要讓 LLM 走出聊天框，真正走進專案協助開發的話，我們不能只給它一個被動的問答介面，而是必須在大腦的外層實作一套控制與管理程式，它就是 Agent Harness。這套程式負責幫大腦裝上記憶、接上手腳，並用狀態機迴圈推動它自主完成任務。從很早期的 AutoGPT 到現在主流的 Claude Code、Antigravity CLI 都是 Agent Harness。（是不是覺得「對耶！AutoGPT！還有過這個東西耶」，它都還有在繼續更新，超猛的～）

而前陣子討論很熱烈的 Harness Engineering，指的就是在這套外層控制程式上賦予更多工程能力，讓 AI Agent 能處理的事情越來越多。

二、什麼是 AI Agent？

時任 OpenAI 安全研究負責人 Lilian Weng 在 2023 年發表的技術文獻《LLM Powered Autonomous Agents》中，形式化定義了現代自主 Agent 的系統架構。她將一個能自主運作的 AI Agent 系統拆解為：

這四個部分各自有明確的分工，彼此透過迴圈串聯：

1. LLM：Core Controller
   負責決策與邏輯推理。它根據當前的上下文與可用工具清單，輸出兩種結果之一：純文字思考（Thought）或結構化的工具呼叫請求（Action）。
2. Planning：State Machine
   負責任務拆解與狀態機推進。包含子目標拆解（Subgoal Decomposition）與自我反思（Self-Reflection）。在程式碼中，它主要由狀態機迴圈驅動，不斷推進「呼叫模型 -> 取得工具請求 -> 執行工具 -> 回傳結果」的生命週期。
3. Memory：Context Management
   即 Day 11 提到的上下文管理。包含短期記憶（當前工作階段的對話與工具回傳訊息）與長期記憶（Vector DB 檢索或本機歷史儲存）。因為模型推論本質無狀態，每一輪都要依賴 Client 重新組裝 Prompt 再傳給 LLM，才能讓 LLM 擁有足夠的上下文。
4. Tools：Action Execution
   讓模型突破權限與算力邊界，是 LLM 與外部環境互動的介面。在程式碼層面這就是由工程師實作的標準函式，例如用 Go 撰寫的 run_command(cmd string)（底層呼叫 exec.Command），或是 view_file(path string, startLine, endLine int)（底層呼叫檔案讀取 API）。這些函式的名稱、用途與參數型別會以 JSON Schema 格式定義在 Prompt 中，提供給模型選擇使用。

三、ReAct：Thought、Action、Observation

目前最經典的狀態機模式，是普林斯頓大學與 Google 研究團隊在 ICLR 2023 提出的 ReAct 架構（Reasoning + Acting）。

在實際系統中，它是模型推理與動作交織而成、循序推進的事件迴圈。舉個例子：

假設工程師在終端機輸入一項任務：

Daniel: 「請檢查 cmd/main.go 編譯失敗的原因，並將其修復。」

在 Agent 控制迴圈內部，處理過程通常按以下次序推進：

1. 循環第一輪：摸索與取得錯誤資訊：
   • Client 送出：將使用者的請求，連同可用工具清單（run_command, view_file, replace_file）包裝為 Prompt 送出。
   • 模型輸出【Thought】：「使用者表示編譯失敗，需先取得編譯器的錯誤輸出。」
   • 模型輸出【Action】：請求呼叫 run_command(CommandLine: "go build ./cmd/main.go")。
   • Client 執行並取得【Observation】：Client 在終端機執行指令，擷取 stderr 輸出：./cmd/main.go:24:12: undefined: SessionStore。
2. 循環第二輪：定位問題原始碼：
   • Client 送出：將上一輪的 Thought、Action 與 Observation 追加至歷史紀錄，再次送交模型。
   • 模型輸出【Thought】：「編譯錯誤顯示第 24 行未定義 SessionStore，需檢視 cmd/main.go 第 20 至 30 行以確認引用與宣告。」
   • 模型輸出【Action】：請求呼叫 view_file(AbsolutePath: ".../cmd/main.go", StartLine: 20, EndLine: 30)。
   • Client 執行並取得【Observation】：Client 讀取磁碟檔案，回傳該區間的原始碼。
3. 循環第三輪：套用代碼修復：
   • Client 送出：將讀取的檔案內容追加進上下文，再次送出。
   • 模型輸出【Thought】：「代碼中調用了 NewSessionStore()，但缺少套件引用。需在 import 區塊補上套件路徑。」
   • 模型輸出【Action】：請求呼叫 replace_file_content(...) 寫入修正。
   • Client 執行並取得【Observation】：Client 修改檔案並存檔，回傳修改成功狀態。
4. 循環第四輪：驗證修復結果：
   • 模型輸出【Thought】：「代碼已修改，需再次執行編譯確認錯誤是否排除。」
   • 模型輸出【Action】：請求呼叫 run_command(CommandLine: "go build ./cmd/main.go")。
   • Client 執行並取得【Observation】：終端機無報錯，Exit Code 為 0（編譯成功）。
5. 任務結束：退出狀態機：
   • 模型輸出【Final Answer】：「已為 cmd/main.go 補上缺少的套件引用，並驗證 go build 編譯通過。」
   • Client 結束迴圈，將最終結果呈現給使用者。

很不負責任地說上面這個例子是請 Gemini 想的 XDD。但簡單來說，透過這樣 Thought（推論下一步） -> Action（發出工具請求） -> Observation（接收回饋） 的循序推進，Agent 就能達成自動化解決問題的目標。

這裡突然讓我想到《PSYCHO-PASS 心靈判官》裡面一個很經典的畫面：故事裡負責審判好人壞人的西比拉系統，底層其實是由數百顆大腦聯網運作。

沒說準到最後發現數學還是戰勝不了生物學，就採取了這樣的策略 QQ。那手持 Agent Harness 的我們，都是西比拉的一份子哈哈 XDD

但是不是蠻像的，我們所有人電腦裡跑的 Agent，即便外層的 Harness 各有不同，但最終所有 Request 其實都是打向雲端同一顆共用的大腦來幫我們思考。我承認剛開始意識到是這種架構時，真的有種頭皮發麻的震撼感，但我也說不清楚為什麼。可能就像我在 Day 11 裡提到的，我以前真的以為每開一個 session，背後就有一顆專門為我服務的大腦。這種架構如果換作是我大概率設計不出來吧哈哈 XDD。

理解了 Agent 的基本結構與運作方式後，下一篇我們會介紹一下 Google 的 Antigravity CLI 這個東西。（終於要開始沾上一點邊了嗎！？）

參考資料

• Lilian Weng (2023). LLM Powered Autonomous Agents.
• Shunyu Yao et al. (ICLR 2023). ReAct: Synergizing Reasoning and Acting in Language Models.