今天的核心是權限控管跟引用驗證不能交給 prompt 去「請模型注意」，要做成 deterministic 的檢索層跟事後檢查：ACL 過濾發生在文件進入 context 之前,不是進了 context 之後靠 LLM 自律;引用則要在生成後驗證來源 ID 確實在允許的檢索集合裡。練習題取自 OpenAI 的真實面試(同一題也在 Google、Lyft 被回報):「設計一個搜尋內部文件的 agent,必須遵守權限、引用來源、且該拒答時會拒答」,關鍵不是背出 RAG 架構,是能示範一套「把安全邊界放進程式碼、把語意判斷留給模型」的分工邏輯。
agent 一旦串了多個 retriever、sub-agent 跟 tool call，光看最終答案對不對已經不夠；今天練怎麼把評估拆到每個環節，並用一道多工具 agent 評估題練習完整回答。
今天練 agent 架構的拆分判斷：每多一次交接就多一個會出錯的步驟，0.95 的單步成功率連乘 10 步只剩約 0.60，所以多 agent 只有在每個 worker 範圍夠窄時才划算；工具要少而精，每個工具定義都會佔每次請求的 context，也多一個選錯的機會；MCP 管 agent 往下接工具與資料，A2A 管 agent 之間委派長時間任務，同一個 codebase 裡的多 agent 用框架內建編排就好；MCP 的 tools、resources、prompts 由不同角色控制，readOnlyHint 這類標註只是提示，授權要在 server 端做。練習題改編自 systemdesign.academy 的多 agent 系統設計題。
今天的 LLM & Agent Engineering 輪練涵蓋四個核心概念：workflow 跟 agent 的分界其實是一條 agency 光譜，多一分自主性就多付一分可預測性、延遲跟成本；agent loop 的四個組件(model、tools、context、stop conditions)裡最容易被忽略的是 forced stop 跟完成前的驗證；context engineering 的核心是把 prompt 當 API 設計，instructions 放在資料前面、用 delimiter 隔開不信任內容、搭配 lost-in-the-middle 的版面安排；agent 評估要做到 span-level scoring(工具選對沒有、檢索相不相關)而不是只看最終答案對不對，因為 tracing 跟 evaluation 是兩件事。練習題是改寫自 GitHub 上 AI-Engineer-Interview-Questions 題庫的 agent 設計與評估情境(自擬整合，非公司洩題)：設計一個會呼叫建工單工具的企業知識庫客服 agent，拆解思路把「先判斷該不該用 agent」到「評估設計不能只看最終輸出」串成一套完整的推理鏈。
今天換個角度練 LLM & Agent Engineering，不再重複前幾週練過的 RAG vs Agent 決策框架跟 context engineering，改聚焦 agent 一旦真的跑起來之後最容易出包、也最容易在面試被追問到詞窮的一段：infinite loop、選錯工具、參數格式錯這三種失敗模式要怎麼分開防；一個長時間跑的 agent 光靠 max_turns 不夠，termination condition 要疊 step budget、cost ceiling、goal-completion 判斷三層；agent 的評估不能只看「有沒有做完」，業界現在會拆成 tool selection quality（選對工具了嗎）、action advancement（有沒有往目標前進）、context adherence（有沒有守住給定的限制）三個獨立指標；guardrail 設計要用信心或金額門檻分流，低風險自動執行、高於門檻轉人工審核。練習題來自候選人回報的真實 AI Engineer 面試題「What are the main failure modes of agents and how do you handle them?」，拆解思路把失敗模式、termination、guardrail 串成一套完整答案。
今天的 LLM Engineering 輪練涵蓋:什麼時候該用複雜 agentic 系統而不是簡單 RAG(先看業務價值再看 benchmark 數字)、context engineering 為什麼不等於 prompt engineering(lost in the middle、工具作用域、記憶體管理)、LLM 評估的離線/guardrail/線上三分類各自的用途、guardrail 該怎麼分層防禦(輸入過濾、輸出驗證、eval harness、red teaming),以及一題改編自真實 OpenAI 面試準備教材的 RLHF reward overoptimization 拆解——reward model 只是人類偏好的 proxy,PPO 會鑽這個 proxy 的漏洞,瓶頸是標註資料品質而非算力,真正的解法是換成可驗證的 reward(RLVR)。
這輪 LLM & Agent Engineering 聚焦 2026 年面試官最愛拆的架構決策：RAG 跟 agent 不是二選一而是分工——RAG 負責有引用來源的政策問答，agent 只在任務需要跨系統多步驟操作時才上場；guardrails 要分成離線評估（release 前抓 regression）跟線上攔截（即時擋掉不安全輸出）兩層，核心原則是「模型只提案，決定性系統才授權與執行」；評估上除了傳統的 LLM-as-a-Judge，agent 還要做軌跡評估（trajectory-based evaluation）去檢查每一步決策，不能只看最終答案。練習題是一道 PracHub 整理的『設計企業客服 agent』系統設計題，練的是怎麼把 RAG 路徑跟 agent 路徑講清楚，並且把授權層講成整題的關鍵。
LLM & Agent Engineering 面試考的重點不是『你會不會串 LangChain』，而是你能不能把一個模糊的『系統壞掉了』拆成可診斷的子問題。今天聚焦四個高頻概念：RAG 的『retrieval 對、答案卻錯』要拆成 retrieval 和 generation 兩段分開評估；agent context window 變大不能解決品質下降,因為問題是 context pollution（雜訊稀釋注意力）不是 token 數不夠;RAG 跟 fine-tuning 的選擇邏輯是『RAG 管知識、fine-tuning 管行為』；LLM-as-judge 有一致性偏誤與自我偏好偏誤,不能單獨當唯一指標。練習題是一道很常見的企業面試情境題:『retrieval 90% 準、答案只有 60% 準,怎麼診斷』,走一遍把模糊症狀拆成可驗證假設的完整思路。
2026 年的 AI Engineer 面試已經不再只考「RAG 怎麼做」，而是考你能不能在失敗模式下做出有依據的取捨。今天聚焦五塊：RAG 該不該升級成 agentic RAG、context window 的分層組裝與 lost-in-the-middle 問題、guardrails 怎麼擋住惡意輸入與輸出、RLHF 的 reward model 訓練流程，以及怎麼從 trace 裡分辨 retrieval 失敗、generation 失敗還是 agent 卡進無限迴圈。