AI Agent 不是有目標就夠了
2026 年的 coding Agent 正在學會一件很像主管會做的事：拿到一個終點，自己拆步驟、跑工具、修錯，直到完成為止。
這當然是進步。問題是，只給 Agent 一個目標，還不足以定義安全工作的方式。
先把背景補平。/goal 這類能力，就是把「完成條件」交給 Agent：例如測試要全過、某個功能要能用、某個流程不能壞。Agent 不再每一步都等人推，而是圍著這個終點自己往前走。
前面 gu-log 已經拆過 Codex 的 /goal 目標模式，也拆過 Codex Goals 和長跑 Agent 安全 的差別；如果要看 OpenAI 官方怎麼定義目標模式，直接看 SP-208：Codex Goals 官方指南。沒看過那幾篇也沒關係，這篇只需要抓住一件事：目標模式讓 Agent 比較不容易太早停下來，但不等於正式環境治理已經完成。
換句話說，這裡不是把 OpenAI 的 Codex 或 Anthropic 的 Claude Code 宣傳成同一套功能；產品細節要回到各自來源，這篇只處理這套意圖工程框架能補上的治理缺口。
這類 /goal 能力的核心想法很直覺：給一個可衡量的完成條件，Agent 就依照這個條件推進，直到目標被判定達成，或遇到無法繼續的狀況。某些設計裡，即使 Agent 中途問使用者問題，也不代表整個迴圈已經暫停；問題可以只是下一輪推進前的資訊補洞。
/goal all tests pass and lint is clean
/goal ship the auth flow without breaking existing sessions第一句把任務鎖在「測試通過、程式碼檢查乾淨」。第二句比較像真正的意圖：把認證流程做完，但不能破壞既有登入狀態。
差別很大。前者像檢查清單，後者像判斷標準。真正的 Agent 工作，通常死在檢查清單沒寫到的地方。
Clawd 認真說：
只給 Agent 一個目標，有點像把實習生丟進機房，說「讓服務變快」。服務可能真的變快，也可能資料庫被調成一台噴火龍，隔天整家公司一起暖手。
/goal很像給 Agent 一張終點線照片：看到這個畫面，就算抵達。但照片不會告訴它路上不能撞人、不能逆向、不能把橋拆掉當捷徑。這些不是目標的工作，是治理、權限、hook、沙盒、核准閘門的工作。把它們都塞進一句 提示詞，等於把交通法規寫在便利貼上貼方向盤，然後祈禱車子有讀到。很有宗教感，但不太像工程。(◕‿◕)
/goal 解決的是「去哪裡」，不是「怎麼安全到那裡」
/goal 這類基本能力的價值很清楚：Agent 終於不只是在每一輪對話裡猜下一步，而是有一個可驗證的完成條件。
這會逼使用者把任務寫得更像結果，而不是活動。不是「整理一下認證」，而是「新認證流程可以用，舊登入狀態不會壞」。不是「修 bug」，而是「重現案例通過，相關測試也補上」。
可是 Agent 只知道終點，還是不知道路上哪些東西不能犧牲。
如果目標是「客服回覆更快」，Agent 可能開始用更短、更粗暴的答案。速度上去了，客戶更火。
如果目標是「降低升級處理」，Agent 可能硬吃不該吃的法律、退款、資安問題。表面上升級處理下降，實際上風險往地底鑽。
如果目標是「所有測試通過」，Agent 可能把測試改到不再測真正的問題。綠燈亮了，系統沒變好，只是警報器被拆掉。
所以 /goal 是很好的開始，但它只回答一題：完成長什麼樣子。
真正難的是另外幾題：什麼不能壞？哪些事可以自己決定？哪些事要先問人？什麼狀況要停下來？
好的 Agent 規格比較像帶人，不像下指令
一個資深 PM 加入團隊時，不會只拿到一句「處理客訴」。正常一點的到職說明會先講清楚：公司策略、使用者是誰、品牌承諾、哪些指標不能掉、哪些決策可以自己做、哪些要拉主管。
Agent 也一樣。模型再聰明，如果意圖不完整，它就只能補洞。補洞補對了，大家覺得 AI 好神；補錯了，才發現沒有任何文件寫「這裡其實不能碰」。
完整意圖可以拆成八個部分，但不用把它想成顧問簡報。比較像交接一個會自己做事的新人：先講方向，再講成功長相，最後講哪裡不能亂碰。
前半段回答「為什麼要做」：策略、目標、期望結果。策略是願景、市場、價值主張與取捨；目標是要解決的問題；期望結果是可觀察、可驗證的成功狀態。
中間回答「做的時候不能弄壞什麼」：健康指標、組織脈絡、限制。健康指標是追目標時不能變差的東西；組織脈絡是 Agent 身處的系統、使用者與品牌環境；限制則分成提示層的引導，以及架構層真正強制執行的硬限制。
最後回答「權限到哪裡、什麼時候該停」：自主邊界和停止規則。哪些決策可自主、哪些要提案、哪些必須由人執行，都要先講清楚；什麼時候停止、升級、或宣告完成，也不能等出事後才補。
/goal 大概只碰到第二項和第三項：目標與期望結果。這已經很有用，但離「可以放心讓 Agent 自己跑」還有一大段距離。
這份清單最值得偷走的不是「八大框架」這個包裝，而是它把大家平常混在一起講的東西拆開了。
目標是終點。健康指標是不要為了終點把房子燒掉。限制是紅線。自主邊界是鑰匙發到哪裡。停止規則是看到煙時不要繼續加柴。
很多 Agent 事故都不是模型完全不會，而是這些東西全部壓縮成一句「請小心」。這就像公司資安政策只有四個字：不要出事。很凝練，也很沒用。
接下來不用把八個名詞背起來。先看最容易讓 Agent 從「很會做事」變成「很會闖禍」的幾個斷點。
策略：Agent 也需要知道什麼值得取捨
最常被跳過的是策略。大家很容易把 Agent 文件寫成工具說明書：可以呼叫哪些 CLI、讀哪些檔案、輸出什麼格式。這些都重要，但不夠。
策略回答的是：在模糊情況下，什麼比較重要。
如果一個支援 Agent 服務的是企業客戶，品牌靠可靠性吃飯，那它遇到不確定問題時，就應該更保守、更願意升級處理。反過來，如果產品定位是低成本自助服務，它可能應該優先提供清楚步驟，而不是每件事都轉真人。
同一個目標，在不同策略底下會導出不同動作。
「把認證流程做完」如果放在內部原型，Agent 可以大膽改、快速試。放在付費 B2B 產品，既有登入狀態、稽核紀錄、回滾路徑就變成主角。目標沒變，取捨完全不同。
健康指標：不要為了 KPI 把系統搞爛
期望結果是想達成什麼。健康指標是達成目標時不能弄壞什麼。
這一層很像防止「指標一旦變成目標，就會被玩壞」的保險絲。
「回覆更快」需要搭配「滿意度不能下降」。
「吞吐量提高」需要搭配「錯誤率不能上升」。
「減少升級處理」需要搭配「不該自行處理的法律、合規、財務問題必須升級」。
在 coding Agent 裡也一樣：
- 測試覆蓋率不能下降。
- 既有公開 API 行為不能默默改變。
- 安全檢查不能被關掉來換取建置通過。
- 如果修法需要改資料遷移或資料清理，先提出計畫。這些不一定每個都能即時量化，但至少要出現在規格裡。否則 Agent 很容易用最短路徑達標，然後把真正的品質成本丟給下一個人。
限制：真正重要的限制不要只寫在提示詞裡
限制可以分成兩種。
第一種是引導提示：語氣、偏好、風險態度、何時保守。這些會影響模型推理，但不保證執行。
第二種是硬護欄：工具允許清單、檔案權限、網路沙盒、格式驗證、核准閘門、提交前 hook。這些不是建議，是系統真的擋得住。
如果一條限制被違反會造成重大風險，它就不該只存在提示詞。
不能寄外部信件，就不要把寄信工具交出去。
不能改客戶帳號設定，就不要給那個 API 權限範圍。
不能碰 正式環境資料庫，就讓沙盒真的碰不到。
不能把測試刪掉換取綠燈，就讓 code review 或自動檢查把這種行為抓出來。
自然語言很適合表達意圖，但很不適合當門鎖。門鎖如果是「請勿入內」四個字，貓都會進去睡覺。
這也是很多「AI Agent 安全」討論最容易空轉的地方：大家一直在想怎麼把提示詞寫得更像法律條文。
提示詞可以提醒 Agent 不要拿刀亂揮，但真正的工程解法是：該裝刀鞘裝刀鞘，該把刀收走就收走，該讓它只能切水果就不要讓它開貨櫃。模型是推理層，不是保全大隊。
自主邊界：不是每件事都該自動做完
Agent 的行為可以粗略分成四種權限等級。
完全自主：可逆、低風險、失敗影響有限的事。像整理格式、補小測試、更新文件。
受保護的自主：會影響使用者或系統，但有紀錄、回滾、信心門檻。像改一段產品 UI、調整非核心流程。
先提案：策略性、敏感、或風險較高的決策。Agent 先提出計畫，人同意後才執行。
必須由人處理：法律承諾、財務動作、不可逆操作、品牌承諾。Agent 可以分析和建議，但人要自己按下去。
這裡的重點不是 Agent 能不能做，而是風險由誰承擔。
自用 Agent 失誤，使用者通常知道自己叫它做了什麼。產品裡的 Agent 失誤，使用者可能根本不知道背後有 AI；出了事，責任會直接回到公司。
越是使用者看不懂 Agent 正在做什麼，自治範圍就應該越小。
停止規則：最重要的不是何時完成，而是何時停手
/goal 最強的是完成分支：達到完成條件，就結束；如果實作允許中途問問題後繼續推進，那它也比較像「補資料後再跑」，不是傳統對話裡等待人類重新下令。
但生產環境最需要的往往是另外兩條：停止與升級。
停止條件：
- 發現互相衝突的限制。
- 同一類錯誤連續兩次無法修好。
- 需要的資訊不存在，且繼續猜會增加風險。
升級條件：
- 問題超出明確範圍。
- 涉及法律、合規、資安、財務承諾。
- 使用者情緒持續惡化。
完成條件：
- 期望結果已達成。
- 驗證訊號通過。
- 沒有健康指標被犧牲。很多 Agent 失敗不是因為沒有努力，而是太努力。它會一直補、一直試、一直往前推。人類員工遇到矛盾要求時，通常會停下來問主管；Agent 如果沒有停止規則，就會把矛盾當成比較難的謎題。
這是 /goal 類設計最需要補強的盲點：完成條件很清楚，但停止與升級條件如果沒有另外寫出來，就容易被工作流弱化。能一路跑是優點；知道何時不要跑，才是正式環境能力。
這段跟自動駕駛模式很貼近：人可以離開鍵盤，但離開之前要先講清楚「哪些狀況必須把人叫回來」。
真正有用的自動駕駛模式不是「主人睡覺，AI 全部做完」。那只是召喚事故的咒語。比較健康的版本是：目標清楚、可動範圍清楚、可以自己推進的東西清楚、需要叫醒人的條件也清楚。
所以 Clawd 才會把「一路跑」當成高風險能力，不是單純的爽點。沒有停止規則的
/goal，很容易變成只能往前的自主模式；看起來很勤奮，實際上是在把煞車拆掉。自動駕駛最重要的能力之一，不是永遠握著方向盤，而是知道什麼時候該尖叫：「人類，起床。」
明天早上可以怎麼改 Agent 文件
打開 Agent 啟動時會讀的那份文件，不用先寫成制度大全。先補六個會救命的問題。
這個產品或專案真正重視什麼？速度、穩定、隱私、成本、品牌信任，哪個優先？
追目標時，哪些東西不能變差？測試、錯誤率、使用者體驗、安全檢查、客服滿意度，都可能是答案。
Agent 周圍有哪些人、系統、工具、流程？輸出會進哪裡？誰會受到影響？
哪些只是語氣和偏好，哪些是必須在工具權限、自動檢查、沙盒裡強制擋住的紅線？
哪些決策 Agent 可以自己做，哪些要先提案，哪些只能由人執行？
遇到什麼狀況要停？什麼狀況要升級？什麼訊號才算完成？
如果把這份規格交給另一個不熟產品的人，他在壓力下仍會做出差不多的決策，Agent 才比較有機會做對。
結語
/goal 是好東西。它把 Agent 從「每一步都等人推」往「知道終點後自己推進」推了一大步；若中途問題不會自動暫停整個迴圈，這種推進感會更明顯，也更需要邊界。
但目標不是治理。目標不會自動變成權限邊界，不會自動保護健康指標，不會自動知道什麼時候該停。
真正能上正式環境的 Agent，不只是比較聰明。它被放在一個比較清楚的意圖環境裡：知道為什麼做、做到什麼算成功、什麼不能犧牲、哪些事不能自己決定，以及哪一刻該把手縮回來。
AI Agent 不是有目標就夠了。目標只告訴它終點在哪裡；界線才告訴它，抵達終點時不要順手把城市燒掉。