編程基礎篇 · 綫性結構：你天天在用
隊列：Agent 的活是排着隊幹的
上一課的棧是「後進先出」，這一課把方向掉個頭：先進先出，一頭進、另一頭出——就是食堂打飯的那條隊。別嫌它樸素，AI 服務能扛住一萬個人同時提問、Agent 能有條不紊地幹完一串任務，靠的都是這條隊。這一課你來當調度員：親手開動一條流水綫，把它玩到積壓、再救回來。
上手 · 你來當調度員
左邊的用戶不停發請求，請求排進中間的隊列，右邊的 Agent 工人從出口那頭按順序取走處理（先來的先辦）。流水綫滾到這裏會自己開動。玩法：先把「請求量」拖到最大，看隊列多久變紅；再把「處理速度」也拉上去，看積壓怎麼被消化掉。
用戶請求
生產者
（隊列是空的）
Agent 工人
消費者
0
排隊中
流水綫還沒開動
進隊 0 ｜ 辦結 0
剛才那波積壓，就是「削峯填谷」的現場。請求突然暴漲（峯），工人一時幹不完——沒關係，隊列先兜住，誰也不丟、誰也不插隊；等請求回落（谷），工人慢慢把隊伍消化掉。要是沒有這條隊，超出處理能力的請求只能當場拒絕。你用 AI 高峯期偶爾轉圈圈但很少直接報錯，就是背後的隊列在替你排着。反過來，隊列長期是空的也説明工人配多了——隊列長度是系統健康度最誠實的儀表盤。
30 秒 · 棧 vs 隊列，只差在從哪頭取
同樣把 A、B、C 三個元素放進去再全部取出來，一鍵播放，盯住兩邊「出來的順序」。
🥞 棧（上一課的老朋友）
同一頭進、同一頭出
出來的順序：—
🚶 隊列（這一課的主角）
一頭進、另一頭出
出來的順序：—
C → B → A 和 A → B → C。兩種結構的差別就這一條：從哪頭取。棧從同一頭取，天生適合「原路退回」（撤銷、函式返回）；隊列從另一頭取，天生適合「按先來後到辦事」。收納方式沒有高低，只有合不合適。
隊列在 AI 世界裏的真身
Agent 的 todo list
Agent 把任務拆成一串子任務後，就是塞進隊列按順序幹：查資料 → 寫初稿 → 自查。先計劃的先執行，不跳步、不遺漏——這份條理不是智能，是隊列。
API 限流排隊
模型 API 每分鐘只接受固定次數的調用，超出的請求不是被扔掉，而是排進隊列等下一個窗口。你的程式偶爾「慢半拍才返回」，多半是在隊裏等。
消息隊列
大系統裏服務之間不直接喊話，而是把活寫成消息丟進隊列，對方按自己的節奏取。這就是剛才流水綫的工業級版本，行話叫消息隊列（Kafka、RabbitMQ 都是它）。
✅ 這一課想和你分享的
- 隊列 = 排隊：一頭進、另一頭出，先進先出（FIFO），排隊是為了公平
- 削峯填谷：請求突增時隊列先兜住，工人慢慢消化——不丟請求、不插隊
- 隊列長度是儀表盤：一直空轉是浪費，持續積壓要加人（或限流）
- AI 裏的真身：Agent 的 todo list、API 限流、消息隊列，全是這條隊
- 棧和隊列只差在從哪頭取：原路退回用棧，先來後到用隊列