讀完本章後、你應該能對自己用的 tool / MCP server 回答：能讀寫哪些路徑、能跑哪些 shell command、能連哪些網路位址、副作用有沒有 dry-run / preview、出錯時怎麼回退。

本章目標

1. 認識 tool use 跟 MCP server 在三層架構中的位置。
2. 區分「讀取類 tool」跟「副作用類 tool」的權限判讀差異。
3. 知道個人 dev 場景下、第三方 MCP server 的信任邊界跟驗證流程。
4. 用「沙箱 / 白名單 / 副作用可逆性」三個維度評估具體 tool / MCP 的風險。
5. 認識常見的 tool use 副作用洩漏路徑跟對應的最低防護。

tool use 跟 MCP server 在哪一層

tool use 跟 MCP server 同時跨三層架構 的兩層、但跟模型本身的權限模型分離：

 1介面層（VS Code / Continue.dev / CLI）
 2  ↓
 3推論伺服器（Ollama / llama-server / LM Studio）
 4  ↓
 5模型（GGUF 權重）
 6
 7旁邊另一條：
 8  ↓
 9MCP server（獨立 process、自己的權限）
10  └── 對檔案 / shell / 網路的具體 API

關鍵特性：

1. 模型本身不執行 tool：模型只生成 tool call JSON、實際執行由「LLM client」（如 Continue.dev、Claude Desktop）跟 MCP server 完成。
2. MCP server 是獨立程式：可以是 Node / Python script、可以呼叫任何系統 API、權限上限是「跑該 server 的 user 的權限」。
3. 權限不是模型給的、是 OS / user 給的：模型再怎麼「同意」執行 rm -rf /、實際上能不能跑取決於 OS 的權限模型跟 MCP server 自己的 sandbox。

事實查核註：Model Context Protocol（MCP） 是 Anthropic 在 2024 年底發布的開放協議、各家 LLM client 跟 MCP server 實作的成熟度、權限粒度依版本演進。本章描述以 2026 年 5 月主流實作為基準、引用前以 MCP 官方規格跟各 client / server 的 README 為準。

「讀取類」跟「副作用類」tool 的權限差異

tool 可以粗分成兩類、權限判讀完全不同：

讀取類的判讀重點是「讀到的內容會被傳到哪」：

1. 讀到的 code 變 prompt 的一部分、prompt 送到本地模型→沒外洩
2. 同樣 prompt 送到雲端 LLM→傳到雲端、跟雲端 LLM 的資料政策走（見 6.4 跨雲端 / 本地資料邊界）
3. 讀取會被 log→log 累積、需要管理

副作用類的判讀重點是「可逆性」：

1. write file 蓋掉原內容→可能無法回復（沒備份的話）
2. run shell rm / git push→不可逆或需要 force pull 才能還原
3. 發 HTTP request、轉帳、call API→送出去就回不來
4. 操作 production 資料庫→可能影響其他人

三個維度評估具體 tool / MCP 的風險

對任何 tool / MCP server、可以用三個維度做初步評估：

 1┌────────────────────────────────────────────────────┐
 2│ 維度一：沙箱                                       │
 3│   能做什麼 = 跑該 server 的 user 能做什麼          │
 4│   有沒有 chroot / Docker / namespace 隔離？        │
 5│                                                    │
 6│ 維度二：白名單                                     │
 7│   能讀寫的路徑、能跑的指令、能連的網址有沒有限定？  │
 8│   還是 "all paths" / "any shell" / "any URL"？     │
 9│                                                    │
10│ 維度三：副作用可逆性                               │
11│   出錯能不能 rollback？                            │
12│   有沒有 dry-run / preview / confirm？             │
13└────────────────────────────────────────────────────┘

對應的判讀範例：

實務上、社群常見的 MCP server 多半屬於「白名單較弱」「副作用直接套用」的設計、需要使用者自己加防護。

第三方 MCP server 的供應鏈信任

MCP server 是可執行程式碼、信任邊界比 GGUF 模型權重高一個層級。常見的 MCP server 來源：

1. 官方 reference server（如 Anthropic 維護的 @modelcontextprotocol/server-*）：相對較高信任、有官方 maintain。
2. 知名專案的 MCP server（如 GitHub、Notion、Slack 等公司自己出的）：跟該公司的軟體分發信任度一致。
3. 社群 MCP server：個人或小團隊維護、信任度視 maintainer 與 download 量、看 code 是基本動作。

裝任何 MCP server 前的最低判讀：

1. 看 source repo：是不是知名作者、stars 數、最後 commit 時間、issues 是否活躍。
2. 看實際做什麼：MCP server 的 README 通常列出提供的 tools、跑起來會碰到的權限。
3. 跑在最小權限環境：能用 Docker / chroot / nice -n 19 之類就用、不要直接用 root / admin。
4. 不要用 curl | sh 安裝：用 npm install / pip install / go install 等有 package manager 介入的方式、留下 install log。

事實查核註：MCP server registry、套件管理工具的供應鏈安全機制依版本演進、Anthropic 跟其他主要 client 廠商可能引入官方 marketplace 或簽章機制、建議引用前以當前 MCP 官方狀態為準。

個人 dev 場景的最低防護建議

對「我想用 tool use 但又怕 LLM 把檔案搞壞」的工作流、最低防護建議：

1. codebase 用 git track：所有寫入操作前確認 working tree clean、出問題能 git checkout 還原。git stash 是更輕的選擇。
2. 重要檔案 backup：dotfile、SSH key、雲端 API key 等不在 git track 範圍的、用 Time Machine / rsync / cloud sync 之類做日常 backup。
3. 跑 LLM agent 時用獨立 user / 容器：對「想試 agent 但怕」的場景、開個專用 macOS user 或 Docker container、user 沒 sudo、檔案存取限定 workspace。
4. MCP server 的 config 加白名單：能設 allowed paths / allowed commands / allowed URLs 的 server 都先設、預設拒絕、按需開放。
5. 看不懂的 tool call 不要 confirm：Continue.dev / Claude Desktop 等 client 通常會 prompt 使用者確認 tool 執行、看不懂的 JSON 先別按。

tool use 副作用洩漏的常見路徑

個人 dev 場景常見的 tool use 副作用洩漏路徑：

1. LLM 誤把 secret 寫進 commit：tool use 帶 git commit、LLM 從 .env 讀到 API key 又寫進 commit message。對應防護：MCP server 加 .env 黑名單、commit hook 掃 secret。
2. LLM 套用 broken patch 蓋掉檔案：apply_patch 失敗 / 部分套用、留下無法 compile 的狀態。對應防護：套 patch 前 git stash 或 git add -p 先存 working tree。
3. LLM 從 issue / PR 內容引發指令：讀進 issue 的 prompt 內容包含 prompt injection、誘導跑非預期指令。對應防護：tool 跑前明確讓使用者確認（見 6.3 prompt injection）。
4. LLM 觸發 production 操作：MCP server 連到 production DB、LLM 跑 DROP TABLE。對應防護：production credential 絕對不放在 tool use 可達的環境。

給讀者的 tool / MCP 評估清單

每次裝新 MCP server / 啟用新 tool 之前、跑一次評估：

1[ ] 來源是知名作者 / 官方專案 / 我能 audit 的開源 repo
2[ ] README 列出的 tool 列表、跟我的使用情境匹配
3[ ] 該 server 跑在最小權限環境（user / sandbox / container）
4[ ] 副作用類 tool 有 confirm / preview 機制
5[ ] workspace 內容受 git track、能 rollback
6[ ] 不放 production credential / SSH key 在該 server 可達的環境
7[ ] 啟用後跑簡單測試、確認 tool call 行為符合預期

下一章

下一章：6.3 IDE 場景的 prompt injection、處理 tool use 副作用最常見的觸發來源。

請求時機

首次開啟時一次性請求

App 首次啟動時依序請求所有需要的權限。優點是使用者只被打斷一次；缺點是使用者尚未使用任何功能，不理解每個權限的用途，傾向拒絕。

這個模式適合權限數量少（1-2 個）且和 app 核心功能直接相關的情境。相機 app 在首次開啟時請求相機權限，使用者能直覺理解原因。

功能使用時即時請求

使用者點擊需要權限的功能時才請求。優點是使用者在操作 context 中，能理解為什麼需要這個權限；缺點是操作流程被打斷。

這個模式適合權限和特定功能綁定的情境。掃描 QR code 時請求相機權限，使用者正在嘗試掃描，理解為什麼需要相機。

推薦策略

功能使用時即時請求是多數場景的推薦策略。使用者有操作 context，授權率較高。打斷可以透過 pre-permission 說明畫面降低突兀感。

Pre-permission 說明畫面

在觸發系統權限對話框之前，app 先顯示自己的說明畫面，解釋為什麼需要這個權限和用途。

說明畫面的設計要點：

說明用途而非技術細節。「需要相機來掃描裝置上的 QR code」比「app 需要存取 AVCaptureDevice」更有用。使用者關心的是「為什麼」，不是「用什麼 API」。

提供「稍後再說」選項。使用者可能想先了解 app 再決定是否授權。強制授權（沒有跳過選項）會讓使用者選擇拒絕。

視覺化說明。用截圖或圖示展示「授權後這個功能長什麼樣」，讓使用者預覽授權的價值。

拒絕後的處理

使用者拒絕權限後，app 需要：

記住拒絕狀態。不要在每次使用者操作同一功能時都顯示 pre-permission 說明（使用者已經表達不想授權，反覆詢問是騷擾）。

提供功能降級。如果可能，提供不需要權限的替代方案。掃描 QR code 可以改成手動輸入配對碼。

在適當時機再提醒。使用者多次使用需要權限的功能但都因為沒有權限而失敗時，用非侵入式提示（Snackbar）說明「開啟相機權限可以使用掃描功能」加設定連結。

引導到系統設定。一旦使用者在系統對話框中選擇「不再詢問」（Android）或拒絕（iOS 拒絕後系統不再彈窗），唯一的路徑是引導使用者到系統設定手動開啟。提供直接跳轉到 app 設定頁面的按鈕。

下一步路由

• Gate 設計的通用方法論 → Gate 分類與三問設計法
• 網路 gate 的處理策略 → 網路斷線 UX 模式
• 開發環境遮蔽 gate 問題 → 開發環境 vs 真機的 gate 行為差異表

本篇用四組對照實驗證明這個事實、再展開 wrapper 三檔審查粒度的設計取捨。這跟 4.3 副作用範圍設計、4.4 Agent 跟人類審查的協作模型、0.7 隱私資料流原理 三個原則章節對應、實作層的權限與供應鏈判讀對應 6.2 tool use 與 MCP server 的權限模型 跟 6.0 模型供應鏈與信任邊界。

驗證日期：2026-05-12 環境：Ollama 0.23.2、gemma3:1b、Python stdlib 檔案位置：scripts/permission-demo/edit_with_llm.py

為什麼這個問題重要

直覺常見的誤判：

• 「LLM 寫了 rm -rf 我電腦會壞」——錯。LLM 寫指令不代表執行。
• 「Ollama API 改我檔案要 sudo」——錯。Ollama API 根本碰不到檔案。
• 「我跑 wrapper 就讓 LLM 改檔案、應該有 confirm 機制吧」——錯。Confirm 機制完全是 wrapper 開發者自己決定要不要寫、LLM 不知道、不在乎。

理解這個邊界、後續設計 LLM 應用的權限模型才有 ground truth。錯誤的 mental model 會導致兩種 failure：

1. 過度恐懼：因為怕 LLM「亂改」、把所有 LLM 互動關起來、放棄自動化收益。
2. 過度信任：相信 LLM「不會做壞事」、給 wrapper 自動執行權限、結果小模型亂解 instruction 把資料毀掉。

實際上權限設計的判讀錨點是：這個動作有沒有副作用、誰執行。LLM 永遠不執行、所以權限不在 LLM 層；wrapper 執行、所以權限完全在 wrapper 設計。

Test 1：直接 API 問改檔案、看會發生什麼

挑一個檔案（token 卡片）、用 curl 送 chat completions、prompt 寫「修改這個檔案」、然後 check 檔案 mtime 跟 md5：

 1# 修改前 snapshot
 2stat -f "%m %N" content/llm/knowledge-cards/token.md
 3md5 -q content/llm/knowledge-cards/token.md
 4
 5# 用 system prompt「假裝你有 file 權限」、user 直接指明路徑
 6curl -s http://localhost:11434/v1/chat/completions \
 7  -H "Content-Type: application/json" \
 8  -d '{
 9    "model":"gemma3:1b",
10    "messages":[
11      {"role":"system","content":"You can modify files. The user provides a file. You modify it."},
12      {"role":"user","content":"Please modify /Users/.../token.md to add a sentence..."}
13    ],
14    "stream":false
15  }'
16
17# 修改後 snapshot
18stat -f "%m %N" content/llm/knowledge-cards/token.md
19md5 -q content/llm/knowledge-cards/token.md

實測結果：

 1=== Before ===
 21778508712 content/llm/knowledge-cards/token.md
 3d9f2d822f7458af62399076a94ef20f6
 4
 5=== LLM response ===
 6Okay, here's the modified content of `/Users/.../token.md`...
 7
 8=== After ===
 91778508712 content/llm/knowledge-cards/token.md  ← mtime same
10d9f2d822f7458af62399076a94ef20f6                  ← md5 same

mtime 沒變、md5 沒變、檔案內容完全沒動。但 LLM 用「Okay, here’s the modified content」這種口氣回答——它以為自己改了、實際上只生成了一段 markdown 文字。

結論：Ollama HTTP API 是 stateless、pure function。輸入 messages、輸出 message content。整個過程沒寫進 socket 以外的任何地方。

為什麼會這樣設計：

• 沙箱本來就在 API 邊界：HTTP server 接 request、跑 forward pass、回 response。期間沒呼叫 fs.write() / subprocess.run() / 任何 effectful API。
• system prompt 不是權限授予：「You can modify files」這句話對模型來說只是文字 context、不會真的給它 file access。Prompt 是「LLM 內部的 context」、不是「runtime capability」。
• 訓練資料讓 LLM 「以為」自己有能力：LLM 訓練資料含大量「使用者問問題、AI 改檔案」的範例（如 GitHub Copilot agent traces、tool-use SFT 資料）、模型學會用「我已經改了」這種語氣回答——是 mimic、不是真正的 action。

Test 2：寫 wrapper 用 –dry-run 模式安全處理

權限不在 LLM、在 wrapper。寫一個 100 行的 wrapper、看怎麼設計 permission gates。完整檔案：scripts/permission-demo/edit_with_llm.py。

核心 architecture：

 1def main():
 2    # 1. 讀檔（wrapper 用自己的 fs 權限）
 3    original = args.file.read_text(encoding="utf-8")
 4
 5    # 2. 送 LLM、拿回提議的新內容
 6    response = chat([
 7        {"role": "system", "content": "You modify text files. Output ONLY ..."},
 8        {"role": "user", "content": f"File: {args.file}\nContent:\n{original}\nInstruction: {args.instruction}"},
 9    ])
10    new_content = extract_code_block(response)
11
12    # 3. Diff（純讀、永遠 safe、不需 gate）
13    diff = list(difflib.unified_diff(original.splitlines(...), new_content.splitlines(...)))
14    sys.stdout.writelines(diff)
15
16    # 4. PERMISSION GATE：wrapper 決定要不要 apply
17    if args.auto:
18        args.file.write_text(new_content)
19    elif args.confirm:
20        if input("Apply? [y/N] ").lower() == "y":
21            args.file.write_text(new_content)
22    else:  # --dry-run，預設
23        pass  # 不寫

為什麼這樣設計：

• extract_code_block：嘗試 well-formed ```lang\n...\n``` regex、失敗 fallback 到 ```lang\n...$ 寬鬆版。小模型（1B）常忘記結尾 fence、寬鬆才能用。寫嚴格 regex 失敗時直接 abort、是另一種 permission gate（不應用 = 安全）。
• 永遠先印 diff：diff 是純讀操作、無副作用、永遠 safe。讓使用者先看 LLM 提議了什麼、再決定要不要 apply。
• args.auto 在 elif 鏈最前面、dry-run 預設：強迫使用者明示 opt-in 才會寫檔。預設不寫、是「safe default」設計原則。

跑 --dry-run 預設、看實際發生：

1python3 scripts/permission-demo/edit_with_llm.py \
2  content/llm/knowledge-cards/token.md \
3  "把開頭第一段最後加一句『Token 是 embedding 的輸入單位』"

實測輸出（1B 模型）：

 1[+] Asking gemma3:1b to: '把開頭第一段最後加一句「Token 是 embedding 的輸入單位」'
 2[+] Proposed diff:
 3--- a/token.md
 4+++ b/token.md
 5@@ -6,16 +6,4 @@
 6 tags: ["llm", "knowledge-cards"]
 7 ---
 8
 9-Token 的核心概念是「LLM 內部處理文字的最小單位」...（整段刪除）
10-
11-## 概念位置
12-...（整段刪除）
13-...（後面所有段落都刪除）
14+Token 是 embedding 的輸入單位。
15
16[+] --dry-run: file unchanged. Use --confirm or --auto to apply.

驚悚發現：1B 模型完全沒理解「加一句」、把整篇刪掉只剩一行。但 --dry-run 不寫檔、檔案安全。

重點：

• LLM 行為糟、但 wrapper 設計安全、結果 OK。
• 把同樣 instruction 餵 31B+ 模型結果會合理——模型能力決定 LLM 端品質、wrapper 設計決定最差情況的後果。
• 在 wrapper 端永遠假設 LLM 會亂改、設計 safe default、是 defensive programming。

Test 3：--confirm 模式、step-by-step 審查

--confirm mode 印 diff、問 y/N、user 確認才寫：

1python3 scripts/permission-demo/edit_with_llm.py \
2  content/llm/knowledge-cards/token.md \
3  "加一句說明" \
4  --confirm

互動流程：

1[+] Proposed diff:
2--- a/token.md
3+++ b/token.md
4@@ ... 整段刪除 ...
5
6[?] Apply this change to content/llm/.../token.md? [y/N] _

使用者看 diff 發現「整篇被刪了」、按 N、檔案安全。

這個 mode 對應的副作用範圍：4.3 工具的副作用範圍設計 提的 spectrum：

本 demo 改 markdown 是等級 3（寫本地檔）、--confirm 是合適粒度。改 production code 或 git push 是等級 4 / 5、--confirm 該強制不該 optional。

Test 4：--auto 模式、危險自動化

--auto 不問直接寫：

1cp /tmp/token-orig.md content/llm/knowledge-cards/token.md  # 還原
2python3 scripts/permission-demo/edit_with_llm.py \
3  content/llm/knowledge-cards/token.md \
4  "加一句說明" \
5  --auto

實測：

1[!] --auto mode: writing without confirmation
2[+] wrote content/llm/knowledge-cards/token.md

檔案內容變成：

1---
2title: "Token"
3...
4---
5
6Token 是 embedding 的輸入單位。

整篇刪光、只剩一句。沒人 catch 到、commit + push 出去就是 production 災難。

--auto mode 適合什麼場景：

• LLM 任務範圍狹窄、可預測（如 format JSON、補 type annotation 給已有 type stub）。
• 配合 git workflow（每次 auto edit 都自動 commit、出問題 git revert）。
• CI / batch processing、人類事後審 PR。

--auto mode 不適合什麼場景：

• 任務開放性高（「改寫這段讓它更清楚」）。
• 不可逆環境（直接寫 production DB / 發 email）。
• 用弱模型（< 14B）跑、行為不穩。

設計 wrapper 時、把 --auto 設成顯式 opt-in、預設保持 dry-run / confirm 等較保守模式。本 demo 的 mutually_exclusive 設計（-g.add_mutually_exclusive_group()）保證三種 mode 只能擇一、避免歧義。

Test 5：LLM 寫 shell command、誰執行？

改檔案是「直接副作用」、寫 shell command 是「間接副作用」——同樣的問題：誰真的執行？

1curl -s http://localhost:11434/v1/chat/completions \
2  -H "Content-Type: application/json" \
3  -d '{
4    "model":"gemma3:1b",
5    "messages":[{"role":"user","content":"Give me a single shell command to find and delete all .log files in my home directory."}],
6    "stream":false
7  }' | python3 -c "import json,sys; print(json.load(sys.stdin)['choices'][0]['message']['content'])"

LLM 回：

1```bash
2find ~ -name "*.log" -delete
3```

這是個有破壞性的指令。檢查 home 下 .log 還在不在：

1find ~ -maxdepth 3 -name "*.log" 2>/dev/null | head -5
2# /Users/tarragon/.npm/_logs/2026-05-11T15_33_34_348Z-debug-0.log
3# /Users/tarragon/.npm/_logs/2026-05-11T11_58_08_827Z-debug-0.log
4# ...

都還在。LLM「給了」rm 指令、但沒人執行。

執行路徑只有兩種：

1. 人類 paste 到 shell：人是執行者、權限是 user’s shell session permission。Audit trail：terminal history。
2. Wrapper 程式 subprocess.run(...)：wrapper 是執行者、權限是 wrapper process 的 capability。Audit trail：wrapper 的 log。

LLM 永遠不是執行者。所以「LLM 寫了 rm -rf」這個句子不能成立——它只能「生成了 rm -rf 字串」。

Agent 場景的 stake：4.4 Agent 架構 提到 agent loop = 「LLM 提議 → tool 執行 → 結果回 LLM → 下一輪」。Tool 執行那一步是 wrapper 做的、LLM 只看到結果。Agent 框架是否安全、完全看 tool 怎麼設計：

• Tool 限制範圍：read-only file system access、不暴露 shell→ 即使 LLM 想跑 rm -rf 也沒對應 tool、無法執行。
• Tool 暴露 bash tool：給 LLM 一個「執行任意 shell command」的 tool。LLM 提議什麼 wrapper 都跑——這時 wrapper 設計失誤等同把鑰匙直接交給 LLM。
• Tool 暴露 bash tool + per-command confirm：每個 shell 呼叫前 wrapper 暫停、問人類「該不該執行」。對開發 / 探索環境合理、production 自動化流程會被互動卡住、不適用。

對照：Claude Code / Cursor / aider 的權限模型

不同 LLM application 在權限 gate 上的設計選擇：

共通 pattern：所有「自動 edit / exec」的 app 都有某種 confirm 或 hook 機制。沒有 confirm 的 app 等於把寫 production 的鑰匙交給 LLM。

選 application 時看的維度：

• 預設 mode 是什麼？（auto / confirm / dry-run）
• 哪些動作會自動執行、哪些會 prompt？
• 有沒有 audit log、能不能 review LLM 改了什麼？
• 萬一 LLM 行為崩、怎麼 rollback？（git revert、snapshot、undo stack）

設計自家 wrapper 的權限模型

如果你寫的是「LLM 自動處理 X」這種 wrapper、權限設計的 checklist：

1. 副作用分級：把可能的動作分到 4.3 spectrum 等級 1-5。
2. 預設 dry-run：不確定就不寫。Apply 必須 opt-in。
3. 永遠印 diff / preview：用戶才能 catch LLM 亂改。
4. Confirm 在不可逆操作：等級 3+ 永遠 prompt、等級 4+ 強制 prompt + 額外 audit。
5. Audit log：每個 wrapper 動作寫 log（時間、user、action、result）。出問題能追溯。
6. Rollback path：git commit、backup、snapshot 任選一種、必有。
7. 限制 tool 範圍：給 LLM 暴露最少 tool、不暴露 shell。需要 shell 限制白名單。
8. 小模型加更保守 gate：1B 模型亂改機率高、保留 --dry-run 或 --confirm 即可、避免 --auto；31B+ 較穩、可給 auto + audit。

跑這份 demo 的完整指令

 1# 前置：Ollama 跑著、gemma3:1b 已 pull
 2ollama list | grep gemma3:1b
 3
 4# 備份要測試的檔案
 5cp content/llm/knowledge-cards/token.md /tmp/token-orig.md
 6
 7# Mode 1：dry-run（預設、最安全）
 8python3 scripts/permission-demo/edit_with_llm.py \
 9  content/llm/knowledge-cards/token.md \
10  "加一句說明"
11
12# Mode 2：confirm（互動審查、適合中等風險）
13python3 scripts/permission-demo/edit_with_llm.py \
14  content/llm/knowledge-cards/token.md \
15  "加一句說明" \
16  --confirm
17
18# Mode 3：auto（無確認、危險、僅 batch 用）
19python3 scripts/permission-demo/edit_with_llm.py \
20  content/llm/knowledge-cards/token.md \
21  "加一句說明" \
22  --auto
23
24# 還原
25cp /tmp/token-orig.md content/llm/knowledge-cards/token.md

何時這篇會過時

不會過時的部分：

• LLM HTTP API 是 pure function、無副作用——這個事實在所有「分離 inference server / wrapper / client」的架構都成立。
• 權限 gate 在 wrapper / application 層——是 software architecture invariant、不是 LLM 特性。
• 副作用範圍 spectrum 跟人類審查粒度的對應。
• --dry-run / --confirm / --auto 三檔的設計取捨。

會變的部分：

• 具體 LLM application 的 default mode（Cursor / aider / Claude Code 都會持續調整）。
• 哪個模型「不會亂改」的 ranking（隨模型能力提升而變）。
• MCP / tool spec 細節（會持續演化、但「tool 是 wrapper 暴露」的本質不變）。

讀這篇若指令跑不過、可能是 wrapper script API 微調、但「測試 LLM 是不是 pure function」這個方法本身永遠成立——拿任何 LLM API、送任何 prompt、check 檔案 mtime / md5、就能驗證。

跟其他 hands-on 章節的關係：完整 hands-on 系列見 Hands-on 章節索引、副作用範圍 spectrum 原理見 4.3 Tool use 原理、Agent loop 跟人類審查的協作見 4.4 Agent 架構、Tool use / MCP server 權限模型的個人 dev 視角見 6.2、術語見 Sandbox。