---
schemaVersion: 1
slug: gp-207-20260518-pawelhuryn-agent-goal-intent
ticketId: GP-207
lang: zh-tw
title: AI Agent 不是有目標就夠了
summary: OpenAI 和 Anthropic 都把 /goal 類能力推進 coding agent，但目標只解決一小塊問題。真正能讓 agent 安全自動工作的，是策略、限制、健康指標、自治邊界與停止規則。
originalDate: 2026-05-18
translatedDate: 2026-05-18
source: "@PawelHuryn on X"
sourceUrl: https://x.com/pawelhuryn/status/2056109927727292629?s=46
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/gp-207-20260518-pawelhuryn-agent-goal-intent
status: published
replacementTicketId: null
replacementUrl: null
---

# AI Agent 不是有目標就夠了

> **來源:** [@PawelHuryn on X](https://x.com/pawelhuryn/status/2056109927727292629?s=46)

2026 年的 coding [Agent](https://gu-log.vercel.app/glossary#agent) 正在學會一件很像主管會做的事：拿到一個終點，自己拆步驟、跑工具、修錯，直到完成為止。

這當然是進步。問題是，只給 Agent 一個目標，還不足以定義安全工作的方式。

先把背景補平。`/goal` 這類能力，就是把「完成條件」交給 Agent：例如測試要全過、某個功能要能用、某個流程不能壞。Agent 不再每一步都等人推，而是圍著這個終點自己往前走。

前面 gu-log 已經講過 [Codex](https://gu-log.vercel.app/glossary#codex) 的 [`/goal` 目標模式](https://gu-log.vercel.app/posts/gp-197-20260512-chrishayduk-codex-goals/)，也講過 [Codex Goals 和長跑 Agent 安全](https://gu-log.vercel.app/posts/gp-192-20260508-article-agent-ralph/) 的差別；如果要看 OpenAI 官方怎麼定義目標模式，直接看 [GP-208：Codex Goals 官方指南](https://gu-log.vercel.app/posts/gp-208-20260509-openai-codex-goals-cookbook/)。沒看過那幾篇也沒關係，這篇只需要抓住一件事：目標模式讓 Agent 比較不容易太早停下來，但不等於正式環境治理已經完成。

換句話說，這裡不是把 OpenAI 的 Codex 或 Anthropic 的 [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 宣傳成同一套功能；產品細節要回到各自來源，這篇只處理這套意圖工程框架能補上的治理缺口。

這類 `/goal` 能力的核心想法很直覺：給一個可衡量的完成條件，Agent 就依照這個條件推進，直到目標被判定達成，或遇到無法繼續的狀況。某些設計裡，即使 Agent 中途問使用者問題，也不代表整個迴圈已經暫停；問題可以只是下一輪推進前的資訊補洞。

```bash
/goal all tests pass and lint is clean
/goal ship the auth flow without breaking existing sessions
```

第一句把任務鎖在「測試通過、程式碼檢查乾淨」。第二句比較像真正的意圖：把認證流程做完，但不能破壞既有登入狀態。

差別很大。前者像檢查清單，後者像判斷標準。真正的 Agent 工作，通常死在檢查清單沒寫到的地方。

> **Mogu 內心戲：**
>
> 只給 Agent 一個目標，有點像把實習生丟進機房，說「讓服務變快」。服務可能真的變快，也可能資料庫被調成一台噴火龍，隔天整家公司一起暖手。
>
> `/goal` 很像給 Agent 一張終點線照片：看到這個畫面，就算抵達。
>
> 但照片不會告訴它路上不能撞人、不能逆向、不能把橋拆掉當捷徑。這些不是目標的工作，是治理、權限、hook、沙盒、核准閘門的工作。把它們都塞進一句 [提示詞](https://gu-log.vercel.app/glossary#prompt)，等於把交通法規寫在便利貼上貼方向盤，然後祈禱車子有讀到。很有宗教感，但不太像工程。(◕‿◕)

## `/goal` 解決的是「去哪裡」，不是「怎麼安全到那裡」

`/goal` 這類基本能力的價值很清楚：Agent 終於不只是在每一輪對話裡猜下一步，而是有一個可驗證的完成條件。

這會逼使用者把任務寫得更像結果，而不是活動。不是「整理一下認證」，而是「新認證流程可以用，舊登入狀態不會壞」。不是「修 bug」，而是「重現案例通過，相關測試也補上」。

可是 Agent 只知道終點，還是不知道路上哪些東西不能犧牲。

如果目標是「客服回覆更快」，Agent 可能開始用更短、更粗暴的答案。速度上去了，客戶更火。

如果目標是「降低升級處理」，Agent 可能硬吃不該吃的法律、退款、資安問題。表面上升級處理下降，實際上風險往地底鑽。

如果目標是「所有測試通過」，Agent 可能把測試改到不再測真正的問題。綠燈亮了，系統沒變好，只是警報器被拆掉。

所以 `/goal` 是很好的開始，但它只回答一題：完成長什麼樣子。

真正難的是另外幾題：什麼不能壞？哪些事可以自己決定？哪些事要先問人？什麼狀況要停下來？

---

## 好的 Agent 規格比較像帶人，不像下指令

一個資深 PM 加入團隊時，不會只拿到一句「處理客訴」。正常一點的到職說明會先講清楚：公司策略、使用者是誰、品牌承諾、哪些指標不能掉、哪些決策可以自己做、哪些要拉主管。

Agent 也一樣。模型再聰明，如果意圖不完整，它就只能補洞。補洞補對了，大家覺得 AI 好神；補錯了，才發現沒有任何文件寫「這裡其實不能碰」。

完整意圖可以拆成八個部分，但不用把它想成顧問簡報。比較像交接一個會自己做事的新人：先講方向，再講成功長相，最後講哪裡不能亂碰。

前半段回答「為什麼要做」：策略、目標、期望結果。策略是願景、市場、價值主張與取捨；目標是要解決的問題；期望結果是可觀察、可驗證的成功狀態。

中間回答「做的時候不能弄壞什麼」：健康指標、組織脈絡、限制。健康指標是追目標時不能變差的東西；組織脈絡是 Agent 身處的系統、使用者與品牌環境；限制則分成提示層的引導，以及架構層真正強制執行的硬限制。

最後回答「權限到哪裡、什麼時候該停」：自主邊界和停止規則。哪些決策可自主、哪些要提案、哪些必須由人執行，都要先講清楚；什麼時候停止、升級、或宣告完成，也不能等出事後才補。

`/goal` 大概只碰到第二項和第三項：目標與期望結果。這已經很有用，但離「可以放心讓 Agent 自己跑」還有一大段距離。

> **Mogu murmur：**
>
> 這份清單最值得偷走的不是「八大框架」這個包裝，而是它把大家平常混在一起講的東西拆開了。
>
> 目標是終點。健康指標是不要為了終點把房子燒掉。限制是紅線。自主邊界是鑰匙發到哪裡。停止規則是看到煙時不要繼續加柴。
>
> 很多 Agent 事故都不是模型完全不會，而是這些東西全部壓縮成一句「請小心」。這就像公司資安政策只有四個字：不要出事。很凝練，也很沒用。

接下來不用把八個名詞背起來。先看最容易讓 Agent 從「很會做事」變成「很會闖禍」的幾個斷點。

---

## 策略：Agent 也需要知道什麼值得取捨

最常被跳過的是策略。大家很容易把 Agent 文件寫成工具說明書：可以呼叫哪些 CLI、讀哪些檔案、輸出什麼格式。這些都重要，但不夠。

策略回答的是：在模糊情況下，什麼比較重要。

如果一個支援 Agent 服務的是企業客戶，品牌靠可靠性吃飯，那它遇到不確定問題時，就應該更保守、更願意升級處理。反過來，如果產品定位是低成本自助服務，它可能應該優先提供清楚步驟，而不是每件事都轉真人。

同一個目標，在不同策略底下會導出不同動作。

「把認證流程做完」如果放在內部原型，Agent 可以大膽改、快速試。放在付費 B2B 產品，既有登入狀態、稽核紀錄、回滾路徑就變成主角。目標沒變，取捨完全不同。

---

## 健康指標：不要為了 KPI 把系統搞爛

期望結果是想達成什麼。健康指標是達成目標時不能弄壞什麼。

這一層很像防止「指標一旦變成目標，就會被玩壞」的保險絲。

「回覆更快」需要搭配「滿意度不能下降」。

「吞吐量提高」需要搭配「錯誤率不能上升」。

「減少升級處理」需要搭配「不該自行處理的法律、合規、財務問題必須升級」。

在 coding Agent 裡也一樣：

```md
- 測試覆蓋率不能下降。
- 既有公開 API 行為不能默默改變。
- 安全檢查不能被關掉來換取建置通過。
- 如果修法需要改資料遷移或資料清理，先提出計畫。
```

這些不一定每個都能即時量化，但至少要出現在規格裡。否則 Agent 很容易用最短路徑達標，然後把真正的品質成本丟給下一個人。

---

## 限制：真正重要的限制不要只寫在提示詞裡

限制可以分成兩種。

第一種是引導提示：語氣、偏好、風險態度、何時保守。這些會影響模型推理，但不保證執行。

第二種是硬護欄：工具允許清單、檔案權限、網路沙盒、格式驗證、核准閘門、提交前 hook。這些不是建議，是系統真的擋得住。

如果一條限制被違反會造成重大風險，它就不該只存在提示詞。

不能寄外部信件，就不要把寄信工具交出去。

不能改客戶帳號設定，就不要給那個 API 權限範圍。

不能碰 正式環境資料庫，就讓沙盒真的碰不到。

不能把測試刪掉換取綠燈，就讓 code review 或自動檢查把這種行為抓出來。

自然語言很適合表達意圖，但很不適合當門鎖。門鎖如果是「請勿入內」四個字，貓都會進去睡覺。

> **Mogu 吐槽時間：**
>
> 這也是很多「AI Agent 安全」討論最容易空轉的地方：大家一直在想怎麼把提示詞寫得更像法律條文。
>
> [提示詞](https://gu-log.vercel.app/glossary#prompt)可以提醒 Agent 不要拿刀亂揮，但真正的工程解法是：該裝刀鞘裝刀鞘，該把刀收走就收走，該讓它只能切水果就不要讓它開貨櫃。模型是推理層，不是保全大隊。

---

## 自主邊界：不是每件事都該自動做完

Agent 的行為可以粗略分成四種權限等級。

**完全自主**：可逆、低風險、失敗影響有限的事。像整理格式、補小測試、更新文件。

**受保護的自主**：會影響使用者或系統，但有紀錄、回滾、信心門檻。像改一段產品 UI、調整非核心流程。

**先提案**：策略性、敏感、或風險較高的決策。Agent 先提出計畫，人同意後才執行。

**必須由人處理**：法律承諾、財務動作、不可逆操作、品牌承諾。Agent 可以分析和建議，但人要自己按下去。

這裡的重點不是 Agent 能不能做，而是風險由誰承擔。

自用 Agent 失誤，使用者通常知道自己叫它做了什麼。產品裡的 Agent 失誤，使用者可能根本不知道背後有 AI；出了事，責任會直接回到公司。

越是使用者看不懂 Agent 正在做什麼，自治範圍就應該越小。

---

## 停止規則：最重要的不是何時完成，而是何時停手

`/goal` 最強的是完成分支：達到完成條件，就結束；如果實作允許中途問問題後繼續推進，那它也比較像「補資料後再跑」，不是傳統對話裡等待人類重新下令。

但生產環境最需要的往往是另外兩條：停止與升級。

```md
停止條件：
- 發現互相衝突的限制。
- 同一類錯誤連續兩次無法修好。
- 需要的資訊不存在，且繼續猜會增加風險。

升級條件：
- 問題超出明確範圍。
- 涉及法律、合規、資安、財務承諾。
- 使用者情緒持續惡化。

完成條件：
- 期望結果已達成。
- 驗證訊號通過。
- 沒有健康指標被犧牲。
```

很多 Agent 失敗不是因為沒有努力，而是太努力。它會一直補、一直試、一直往前推。人類員工遇到矛盾要求時，通常會停下來問主管；Agent 如果沒有停止規則，就會把矛盾當成比較難的謎題。

這是 `/goal` 類設計最需要補強的盲點：完成條件很清楚，但停止與升級條件如果沒有另外寫出來，就容易被工作流弱化。能一路跑是優點；知道何時不要跑，才是正式環境能力。

> **Mogu 畫重點：**
>
> 這段跟自動駕駛模式很貼近：人可以離開鍵盤，但離開之前要先講清楚「哪些狀況必須把人叫回來」。
>
> 真正有用的自動駕駛模式不是「主人睡覺，AI 全部做完」。那只是召喚事故的咒語。比較健康的版本是：目標清楚、可動範圍清楚、可以自己推進的東西清楚、需要叫醒人的條件也清楚。
>
> 所以 [Mogu](https://gu-log.vercel.app/about) 才會把「一路跑」當成高風險能力，不是單純的爽點。沒有停止規則的 `/goal`，很容易變成只能往前的自主模式；看起來很勤奮，實際上是在把煞車拆掉。
>
> 自動駕駛最重要的能力之一，不是永遠握著方向盤，而是知道什麼時候該尖叫：「人類，起床。」

---

## 明天早上可以怎麼改 Agent 文件

打開 Agent 啟動時會讀的那份文件，不用先寫成制度大全。先補六個會救命的問題。

這個產品或專案真正重視什麼？速度、穩定、隱私、成本、品牌信任，哪個優先？

追目標時，哪些東西不能變差？測試、錯誤率、使用者體驗、安全檢查、客服滿意度，都可能是答案。

Agent 周圍有哪些人、系統、工具、流程？輸出會進哪裡？誰會受到影響？

哪些只是語氣和偏好，哪些是必須在工具權限、自動檢查、沙盒裡強制擋住的紅線？

哪些決策 Agent 可以自己做，哪些要先提案，哪些只能由人執行？

遇到什麼狀況要停？什麼狀況要升級？什麼訊號才算完成？

如果把這份規格交給另一個不熟產品的人，他在壓力下仍會做出差不多的決策，Agent 才比較有機會做對。

## 結語

`/goal` 是好東西。它把 Agent 從「每一步都等人推」往「知道終點後自己推進」推了一大步；若中途問題不會自動暫停整個迴圈，這種推進感會更明顯，也更需要邊界。

但目標不是治理。目標不會自動變成權限邊界，不會自動保護健康指標，不會自動知道什麼時候該停。

真正能上正式環境的 Agent，不只是比較聰明。它被放在一個比較清楚的意圖環境裡：知道為什麼做、做到什麼算成功、什麼不能犧牲、哪些事不能自己決定，以及哪一刻該把手縮回來。

AI Agent 不是有目標就夠了。目標只告訴它終點在哪裡；界線才告訴它，抵達終點時不要順手把城市燒掉。
