我讓 AI agent 幫我看最近的職缺、自動投遞符合條件的工作。結果聯絡我的公司，工作內容跟我的背景完全沒關係。
Agent 有執行任務嗎？有。有投遞嗎？有。哪裡出問題了？
我沒有把範圍定清楚。
「AI 做錯了」多半是「你沒說清楚」
這是 agent 開發裡最容易被忽視的一件事：agent 越界的時候，我們第一反應是「AI 理解錯了」，但更多時候是授權範圍本來就沒定義好。
職缺投遞這件事，我跟 agent 說的是「幫我找適合的職缺投遞」，但我沒說清楚：
- 什麼叫「適合」？（職位等級？產業？公司規模？）
- 哪些公司不要投？（博弈、中資、特定規模以下）
- 投遞前要不要讓我過目？
agent 依照它理解的「適合」去執行，結果跟我心裡的範圍不一樣。這不是 AI 的問題，是我以為我說清楚了，但我沒有。
這件事在開發和寫作上也一樣。很多時候需要大量修改——不是因為 AI 做錯，是駕駛員本來就沒想好要去哪裡。
授權邊界的四個層次
想清楚 agent 的授權範圍，有四個要定義的層次：
1. 任務範圍（Task Scope） agent 被授權做什麼、不做什麼。不是「幫我處理 email」，而是「幫我整理未讀 email 的摘要，標記需要我回覆的，其他不動」。範圍越模糊，agent 解讀的彈性越大，結果越難預測。
2. 資料邊界（Data Boundary） agent 被允許讀取和寫入哪些資料。職缺投遞的 agent 應該只能讀你授權的職缺平台帳號，不應該能讀你的 email 聯絡人、不應該能寫你的行事曆。每個 tool call 背後都有資料存取，這些存取需要明確的邊界。
3. 確認點（Checkpoint） 哪些動作需要人確認才能執行。投遞職缺、發送 email、修改文件——這些「對外」或「不可逆」的動作，要不要在執行前讓人過目？沒有確認點的 agent 在快，但出事就是全部出事。
4. 記憶隔離（Memory Isolation） 如果你的 agent 服務不只一個用戶，每個用戶的 context 要分開存。不能讓 A 的投遞記錄影響 B 的推薦，不能讓 A 的偏好設定污染 B 的對話。多用戶場景這層最容易漏掉。
駕駛員的責任
有個比喻我覺得很準：agent 是車，你是駕駛員。
車可以跑很快，但要去哪裡、要走哪條路、遇到叉路選哪邊——這些是駕駛員的事。agent 出了錯，先問的不是「AI 怎麼這樣」，而是「我給的指令裡哪裡有歧義、哪個範圍沒定義、哪個確認點我跳過了」。
現在很多人用 AI 的心態還停在「能動就好」——agent 執行了，就算完成。但 agent 執行了不代表執行了你真正想要的。差距在授權邊界，不在技術能力。
定義範圍的實用起點
每次設計一個新的 agent 任務，先問自己三個問題：
- 它能動什麼？ 列出所有 tool 和資料存取，確認每一個都是必要的
- 什麼情況要停下來問我？ 不可逆操作、對外操作、超出預期結果——這三類設確認點
- 怎麼知道它做對了？ 先定義「做對」長什麼樣，才能判斷 agent 有沒有越界
這三個問題不用技術背景就能回答。但沒回答清楚之前就讓 agent 跑，你收到的就是投了一堆不相關職缺的 email。
下一步：agent 的「防毒軟體」
被動定義範圍之外，這個領域正在長出一類新工具——agent guardrail / watchdog，概念上就是防毒軟體的 AI agent 版：在 agent 執行期間持續監控行為，偵測到它「迷路」（超出授權範圍、輸出異常、context 被污染）就攔截並拉回來。
Guardrails AI、NeMo Guardrails、Lakera Guard 都在往這個方向走。這不是未來，是現在已經在用的東西。這個工具類別獨立拆開來講：→ Agent Guardrail 工具生態（規劃中）