程式設計基礎篇 · 線性結構：你天天在用

佇列：Agent 的活是排著隊幹的

上一課的棧是「後進先出」，這一課把方向掉個頭：先進先出，一頭進、另一頭出——就是食堂打飯的那條隊。別嫌它樸素，AI 服務能扛住一萬個人同時提問、Agent 能有條不紊地幹完一串任務，靠的都是這條隊。這一課你來當排程員：親手開動一條流水線，把它玩到積壓、再救回來。

上手 · 你來當排程員

左邊的使用者不停發請求，請求排進中間的佇列，右邊的 Agent 工人從出口那頭按順序取走處理（先來的先辦）。流水線滾到這裡會自己開動。玩法：先把「請求量」拖到最大，看佇列多久變紅；再把「處理速度」也拉上去，看積壓怎麼被消化掉。

👥
使用者請求
生產者
（佇列是空的）
😴
Agent 工人
消費者
0
排隊中
流水線還沒開動
進隊 0 ｜ 辦結 0
2.0/秒
2.0/秒
灰 = 空轉 ｜ 綠 = 健康 ｜ 紅 = 積壓超過 8 條
剛才那波積壓，就是「削峰填谷」的現場。請求突然暴漲（峰），工人一時幹不完——沒關係，佇列先兜住，誰也不丟、誰也不插隊；等請求回落（谷），工人慢慢把隊伍消化掉。要是沒有這條隊，超出處理能力的請求只能當場拒絕。你用 AI 高峰期偶爾轉圈圈但很少直接報錯，就是背後的佇列在替你排著。反過來，佇列長期是空的也說明工人配多了——佇列長度是系統健康度最誠實的儀表盤。
30 秒 · 棧 vs 佇列，只差在從哪頭取

同樣把 A、B、C 三個元素放進去再全部取出來，一鍵播放，盯住兩邊「出來的順序」。

🥞 棧（上一課的老朋友）

同一頭進、同一頭出

出來的順序：—

🚶 佇列（這一課的主角）

一頭進、另一頭出

出來的順序：—
A、B、C 依次放入，再全部取出
C → B → A 和 A → B → C。兩種結構的差別就這一條：從哪頭取。棧從同一頭取，天生適合「原路退回」（撤銷、函式返回）；佇列從另一頭取，天生適合「按先來後到辦事」。收納方式沒有高低，只有合不合適。
佇列在 AI 世界裡的真身
📋

Agent 的 todo list

Agent 把任務拆成一串子任務後，就是塞進佇列按順序幹：查資料 → 寫初稿 → 自查。先計劃的先執行，不跳步、不遺漏——這份條理不是智慧，是佇列。

🚦

API 限流排隊

模型 API 每分鐘只接受固定次數的呼叫，超出的請求不是被扔掉，而是排進佇列等下一個視窗。你的程式偶爾「慢半拍才返回」，多半是在隊裡等。

📮

訊息佇列

大系統裡服務之間不直接喊話，而是把活寫成訊息丟進佇列，對方按自己的節奏取。這就是剛才流水線的工業級版本，行話叫訊息佇列（Kafka、RabbitMQ 都是它）。

✅ 這一課想和你分享的