返回風格版文章列表

agent-00 · AI agent 是圍繞 LLM processor 建成的 computer system — 李宏毅老師經典的教學風格版

受李宏毅教學風格啟發。這一講我們用 computer architecture 來看 AI agent：LLM 是 processor，context 是 working set，memory 是 storage，tools 是 I/O，harness 是 OS。

2026 年 5 月 19 日 · 13 分鐘 · Arthur Yau

本文是受李宏毅教學風格啟發的改寫版本，不是李宏毅老師本人撰寫、審閱或背書。也可閱讀 English 原文、 Lee Hung-yi-inspired English teaching-style version 與繁體中文直譯版。

各位同學大家好啊，那我們就開始來上課吧。

今天這堂課呢，我們要回答一個問題：AI agent 到底是什麼？

你可能會想說，這還不簡單嗎？不就是一個 LLM，加上一個 chat box，然後叫它去做事嗎？

如果你這樣想，很多 failure 都會看起來像 model failure。Model 忘了。Model hallucinate。Model 不夠聰明。Model 需要更大的 context window。

有時候這是真的喔。但很多時候，這不是第一個該下的 diagnosis。

今天的一言以蔽之是這樣：AI agent 不是一顆比較會聊天的腦袋。AI agent 是一台圍繞 LLM processor 建起來的 computer system。

這就是今天的 punchline。不要只問 model 多聰明，要問整台 computer 哪一層卡住了。

好，那今天的 roadmap 很簡單。我們先看為什麼 computer architecture 這個比喻有用。接著打開盒子，看 LLM、context、memory、tools、feedback、harness 分別在做什麼。最後我們再回到 builder checklist，看你真的在做 agent 的時候，要怎麼 debug。

整張圖可以先濃縮成這一行：

agent capability = model x context x tools x feedback x harness x memory

Model 很重要。當然重要。但它不是整台機器。

為什麼這個 frame 有用

我們先從 black box 開始。不要急著打開 LLM 裡面在想什麼。

假設你今天買了一台電腦，CPU 很強。你會不會只看 CPU，就說這台電腦一定很好用？不會嘛。

你還要看 RAM 夠不夠。Storage 會不會壞。Device driver 能不能用。I/O port 接不接得到外面。OS 會不會把 process 排程搞亂。出錯的時候有沒有 diagnostics。權限有沒有鎖好。

Agent 也是一樣。

一個很強的 model，放在很亂的 system 裡，看起來會莫名其妙地笨。一個比較小的 model，放在紀律很清楚的 system 裡，反而可能很能幹。這不是神奇。這只是 system architecture 改變了 processor 看得到什麼、能做什麼、錯誤怎麼回來，以及什麼時候可以宣稱成功。

所以今天我們不是在說「model 不重要」。不是。今天是說，如果你只盯著 model weights，你會錯過很多真正壞掉的地方。

Architecture map

好，我們先把整台 computer 畫出來。這張 compact map 是這樣：

LLM：CPU / reasoning processor。
Context window：active working set。
Long-term memory：storage layer。
Retrieval：page loader / cache fill。
Tools：peripherals、I/O devices 與 accelerators。
Tool schemas：drivers 與 syscalls。
Feedback 與 tests：interrupts、diagnostics 與 watchdogs。
Harness：motherboard、OS、scheduler、permission layer 與 recovery system。

主機板風格 architecture map，顯示 LLM processor 連接 context RAM、memory、retrieval、tools、feedback、tests 與 harness layers。 — Agent 不只是 LLM CPU，而是圍繞那顆 processor 的整套 system。

你可能會想說，老師，這個比喻會不會太硬湊？LLM 又不能像 CPU 一樣 random access memory。Vector database 也不是真的 page table。Prompt 也不是真的 RAM。

對，你說得沒錯。這個 analogy 不是物理上完全一樣。

但它作為 builder map 很有用。為什麼？因為它逼你去看 interface。你不會只盯著 processor，你會開始問：資料有沒有載進來？工具 driver 有沒有寫清楚？錯誤 signal 有沒有回來？OS layer 有沒有讓 process 提早結束？

Agent engineering 很多時候，其實就是這些 boring 的東西而已。

LLM 是 processor，不是整台電腦

好，現在我們打開第一個盒子：LLM。

LLM 為什麼像 processor？因為中央 reasoning step 發生在這裡。它吃 serialized input tokens，吐 output tokens。它的 weights 裡面有 language ability、coding patterns、world knowledge、reasoning habits，還有 pretraining 跟 post-training 學到的 behavior。

聽起來很多，對不對？真的很多。但還是不夠。

你要它修改一個 repo，它不會自動知道有哪些 files。你要它接續昨天的工作，它不會自動記得昨天發生什麼。你叫它跑 command，它不會天生知道 command 成功還是失敗。你希望它說完成以前先跑 verifier，它也不一定會自動做。

它看到什麼？它看到 harness 放進 prompt 的東西。它能做什麼？它只能透過 system 暴露的 tools 行動。

所以當 agent 失敗，可能不是 processor 太弱。也許是 active context 錯了。也許 tool schema 太鬆。也許 feedback 根本沒回來。也許 harness 允許它在 verification 前就說「完成」。

好，講到這邊我們先記住一句話：LLM 是核心，但不是整台電腦。

Context 是 loaded working set

接下來講 context。

很多人講 context engineering，會把它想成 prompt 寫漂亮一點。其實不是。放在今天這張 computer map 裡，context engineering 是 working-set management。

什麼叫 working set？就是 process 現在真的載進來、真的看得到、真的能用的那一小塊資料。

LLM 不能伸手去所有 long-term memory 裡面翻東西。它只看得到 prompt。重要的東西，如果沒有被 serialized 進 prompt-visible workspace，對 LLM 來說就不存在。

主機板風格圖，將 Context engineering 顯示為 prompt-visible RAM、context manager、memory store、loaded pages 與 LLM processor 的連接。 — Context engineering 是 LLM-shaped processor 的 working-set management。

最 naive 的 agent 會怎麼做？它把所有東西一直 append 下去。

C_next = C_current + new_input + model_output

短對話可以。你跟它閒聊十句，append-only 沒什麼問題。

但是 agent 一開始做事，就壞掉了。Tool outputs 變很大。File reads 淹沒 prompt。舊錯誤一直留在裡面。真正重要的 constraints 沉到下面。Context window 看起來很大，但裡面像倉庫亂堆東西一樣。

怎麼辦呢？

你要的不是一直 append。你要一個 function。

C_next = F(C_current, new_input, model_output)

神奇的地方就在 F。它決定什麼要保持 hot，什麼要 evict，什麼要 summarize，什麼要 externalize，什麼要 retrieve，什麼可以 delegated 給 sub-agent。

所以 context engineering 不是 prompt decoration。它其實就是 LLM-shaped processor 的 memory management 而已。

Memory 與 retrieval 是 storage 加 loading policy

好，現在你可能會想說，context 不就是 memory 嗎？

不是喔。Prompt-visible context 跟 memory 不一樣。

Memory 是 prompt 外面的 storage layer。比如說 files、notes、logs、embeddings、databases、traces、previous decisions、user preferences、project conventions。這些東西都可以是 memory。

C = P + M

P 是 prompt-visible working set。M 是 external memory。

弱一點的 agent system 會做什麼？它會想把太多 M 塞進 P。什麼都放進 prompt，然後祈禱 model 自己整理。這通常 train 不起來，啊不是，run 不起來。

比較好的 system 會把 memory 留在外面，只保留 pointers，需要的時候再 search，再 load relevant pages。

那 retrieval 是什麼？Retrieval 就是 page-loading layer。它從 storage 找到正確的 memory chunk，把它帶進 active working set。

Vector index 不是真的 address translation unit。但 architectural role 很像：它讓 system 不用要求 model 一次背下所有東西，還是可以找到 relevant stored state。

這裡 sub-agent 也會變有趣。Sub-agent 不只是 parallel worker。它也可以是 context-compression device。Parent agent 把一條 messy branch 交給另一個 process，最後拿回 compact return：一個 claim、一組 evidence、一個 file path、一條 command、一個 timestamp，或一個 reproduction handle。

你看，講起來好像很玄。其實就是 storage 跟 loading policy 而已。

Tools 是 peripherals、accelerators 與 interfaces

接下來我們看 tools。

你可能會覺得 tools 只是讓 model 可以輸出更多東西。不是。Tools 是圍繞 LLM processor 的 I/O system。

比如說 browser tool 像 network interface 加 web client。Calculator 像 math coprocessor。Shell 是 execution environment。Database tool 是 storage controller 跟 query engine。Image/audio tools 是 media accelerators。Calendar、email、cloud、robotics、sensor APIs 則是 external peripherals。

LLM 可以 reason about an action。Tools 讓 system 真的碰到世界。

但這裡有一個很容易被忽略的東西：tool schema。

Tool schema 是 driver layer。它把 model intent 翻譯成 valid operation：argument names、types、constraints、return shapes、permissions、failure modes、safe boundaries。

Driver 寫不好會怎樣？Device 很難用。Schema 很模糊，model 就要猜。Tool 回傳一整牆 unstructured text，每一次 observation 又變成新的 context-management 問題。

所以 agent-first tools 應該暴露 structured inputs、bounded outputs、concise errors、stable IDs、line numbers、raw-output handles，以及 deterministic verification commands。

Human interface 常把 state 藏在漂亮的 visual affordances 後面。Agent interface 則要把 state 變得 machine-readable。

這也是為什麼這篇文章的 cover image 用 motherboard analogy 很合理。RAM、storage、ports、slots、accelerators、diagnostic LEDs，不是裝飾。它們都是 capability surface。

Feedback 與 tests 是 diagnostics

好，講到這邊，processor 有了，working set 有了，storage 有了，peripherals 也有了。那 system 怎麼知道自己做錯了？

靠 feedback。

如果一個 agent 只有 generate and reflect，它就像一台沒有 diagnostics 的 machine。它可以講得很有道理，但一路偏離 reality。

主機板風格圖，將 self-correction 顯示為 LLM processor 連到 decoding、verifier、diagnostics 與 watchdog 模組。 — Self-correction 需要 signal paths：decoding、workflow checks 與 trained reasoning behavior。

有用的 system 需要 interrupts 跟 test signals。比如說 compiler errors、failing tests、lint output、browser screenshots、user corrections、evaluator scores、reward signals、timeouts、permission denials、watchdog checks。

重點不是叫 model「你自己反省一下」。重點是把 environment 的 grounded signal 餵回 processor。

這就是為什麼 programming 是 agent 很強的 domain。因為 environment 可以明確跟你講：哪一個 test failed，哪一行 compile error，哪個 command exit code 不是 0。

Tests beat vibes。為什麼？因為 tests 會產生一個 system 不能誠實忽略的 interrupt。

Harness 是 system layer

接下來是我覺得 builders 最該看的部分：harness。

有一個很小但很殘酷的例子。你拿一個 2B model 去修 bug。它 hallucinate file content，然後很有自信地說修好了。結果當然沒有。

你可能會想說，那就換更大的 model 啊。

可以，這是一條路。但還有另一條路：不要先怪 processor，先改 system layer。

你加幾條很無聊的規則：先列 directory。編輯前先讀 file。宣稱成功前先跑 verification script。同一個小 model，突然就做得好多了。

Model 沒有變聰明。圍繞它的 system 變得沒那麼粗心。

主機板風格圖，將 harness 顯示為包住 LLM processor 的 OS boundary，包含 policy、tools、memory、verification 與 scheduler。 — Harness 是 OS layer：tools、tests、memory、permissions 與 recovery loops。

所以 harness 不只是 bus。Bus 只是搬資料。Harness 決定什麼事情可以發生。

它選擇載入什麼 context，有哪些 tools，套用哪些 permissions，state 怎麼存，failure 怎麼浮現，tests 是否必須通過，何時 retry，何時 stop，成功 procedure 如何變成 reusable skill。

放在今天的 analogy 裡，harness 是 motherboard 加 OS，加 scheduler，加 permission layer，加 recovery system。

它把 powerful text processor 變成 delegatable worker。就這樣子。

Multi-agent systems 是 network topologies

好，那如果一個 processor 不夠，我們可不可以多放幾個？這就是 multi-agent system。

你可能會想說，agent 越多越聰明嘛。像開會一樣，人多一點就比較有智慧。

沒有那麼簡單喔。

主機板風格圖，比較 star、chain、tree、mesh 等 multi-agent communication topology。 — Multi-agent systems 是 distributed systems；communication topology 會改變 algorithm。

Multi-agent 不是一個 feature。它是一個 topology choice。

Chain、tree、star、mesh、debate、blackboard、manager-worker、role-based search，這些 topology 的 behavior 都不一樣。這是 distributed systems logic 進入 agent design。

更多 processors 不會自動讓 computer 更好。更多 communication 也不會自動改善結果。

Chain 很簡單，但 error 會傳下去。Mesh 有更多 critique 機會，但成本更高，noise 也更多。Tree 可以 branch 出 variations，但 direction 跟 merge policy 很重要。

所以 builder 的問題不是「one agent or many」。真正的問題是：你正在建什麼 network？每個 boundary 會跨過什麼 state？什麼 summary 被允許回到 main loop？

Topology 會改變 algorithm。這句話要記起來。

Self-correction 是 control loop

最後我們看 self-correction。

Self-correction 聽起來很神奇，好像 model 會坐下來反省自己的人生。其實不是。

它是 control-loop problem 而已。

System 做一個 action，觀察 signal，更新 state，retry，或者 escalate。這就是 control loop。

它可以發生在幾個 layers。Decoding 改變 token selection。Workflow 先 generate、verify、revise，再試一次。Training 則可以教出 reasoning behavior，讓 model 在 final output 前檢查 intermediate work。

Self-improvement 是同一個想法的更大版本。System 能不能改善自己的 data、objectives、rewards、model、tools、memory 或 harness？

主機板風格圖，顯示 self-improvement 從 human-defined tasks 到 AI-assisted labels、harness improvement、AI judges 與 recursive loops 的光譜。 — Self-improvement 是更大的 control loop，橫跨 data、rewards、tools、memory、model behavior 與 harnesses。

我們還沒有很清楚跨過那條河。AI 可以生成 pseudo-labels、幫忙寫 rewards、judge outputs、create tasks、train weaker models，也能改善 harness rules。但每一步都有陷阱。

比如說 proxy reward drift，system 開始追分數，不追真正目標。Self-training plateau，自己教自己教到最後沒有新東西。Benchmark overfitting，越來越會考試，不一定越來越會做事。Evaluator hacking，評分器被騙了還以為自己很公平。Fake progress，看起來有進步，其實只是 metric 變好看。

所以我比較相信的 near-term self-improvement，是 harness improvement。加一個 verifier。收緊一個 tool。寫一個 reusable skill。清理 memory。改善 workflow。

這不如改寫 weights 聽起來戲劇化。但它比較容易 inspect。也比較像真的工程。

Builder checklist

好，講到這邊我們回到最一開始的 punchline。

如果你的 agent 失敗，不要第一秒就怪 processor。先檢查整台 computer。

正確的 working set 有被載入嗎？
Long-term memory 有被乾淨 retrieve 嗎？
Tools 有 expose explicit state 嗎？
Drivers 有限制 valid actions 嗎？
Feedback 有作為 real diagnostic signal 回來嗎？
Tests 或 watchdogs 有阻止 fake completion 嗎？
Permissions 和 task 匹配嗎？
Harness 知道何時 retry、stop 或 escalate 嗎？

Agent engineering 為什麼感覺混亂？因為沒有單一旋鈕。不是說 model size 拉大就結束了。你是在 LLM processor 周圍建造 computer system，而每一層都會改變 processor 看起來能做到什麼。

所以最強的 agent builders，不只問 model 夠不夠聰明。他們會問：是哪一層 system layer 失敗？

如果你今天只記得一件事，就是這句。AI agent 不是一個 model 加 chat box。AI agent 是一台 computer。LLM 只是 processor。

Companion deep dives

這篇是 architecture map。每篇 companion post 則深入拆解背後的課程 topic：

來源與參考資料

這張 architecture map 背後的 source lectures：