概念位置

LLM API call 的訊息結構：

1messages = [
2  {role: "system", content: "你是專業 code reviewer..."},  ← system prompt
3  {role: "user",   content: "請 review 這段 code: ..."},
4  {role: "assistant", content: "..."},  ← 模型回答
5  {role: "user",   content: "..."},     ← 後續對話
6  ...
7]

System prompt 在 application 設計中的角色：

事實查核註：不同 LLM vendor 對 system prompt 的處理機制不同（如部分模型把 system 跟 user 視為相同優先級、部分模型有特殊訓練讓 system 較高優先）、具體行為以該模型的官方文件為準。

設計責任

理解 system prompt 後可以解釋兩個現象：為什麼同一個模型在不同 LLM 應用中的「個性」差很多（system prompt 不同）、為什麼 prompt injection 的主要目標是繞過 system prompt 的約束（攻擊者想讓模型不照原本指令走）。

實務上、設計 LLM application 時、system prompt 是行為約束的第一層、但不是唯一防線（容易被 injection 繞過）；critical 行為應該在 application 層（如 tool call 的權限白名單、輸出驗證）加第二層防護。詳見 6.3 IDE 場景的 prompt injection。

概念位置

Tool use 的典型流程：

11. 開發者定義 tools（每個 tool 含 name、description、parameters schema）
22. LLM 收到 user message 跟 tools 清單
33. LLM 決定要呼叫哪個 tool、生成結構化 tool call（JSON）
44. LLM client（不是模型本身）執行 tool call、得到結果
55. tool 結果回灌進 conversation、模型基於結果繼續生成或再呼叫

關鍵特性：

1. 模型本身不執行 tool：模型只生成 tool call JSON、實際執行由 client 或 MCP server 完成。
2. 權限由 OS / user / sandbox 決定：模型再「同意」執行 rm -rf /、實際能不能跑取決於跑 tool 的 process 權限。
3. 副作用範圍跟 tool 設計強相關：tool 寫得越通用（如 run_shell）、攻擊面越大；tool 寫得越窄（如 read_workspace_file）、攻擊面越小。

Tool use 跟 function calling、MCP 的關係：

設計責任

理解 tool use 後可以解釋三個現象：為什麼 LLM 「能跑 shell」其實是 client 跑、不是模型跑（職責切分）、為什麼 tool spec 設計直接影響攻擊面（spec 越鬆、injection 後果越大）、為什麼 agent loop 比單次 tool call 危險（多步 tool use 中 injection 累積）。

設計 tool 跟 MCP server 時、權限白名單 + 副作用可逆性 + confirm 機制是基本配置；production 場景見 LLM Agent Prompt Injection 後果治理 跟 6.2 tool use 與 MCP server 的權限模型。