AI agent 會越界，不是因為它壞，而是因為任務邊界太模糊

Ryan Vale
·
·
IPFS
·
AI agent 越界通常不是惡意，而是任務邊界太鬆。把目標、範圍、非目標與驗證方式寫清楚，才會讓 reviewer 看得懂它到底做了什麼。

很多人第一次真的被 coding agent 嚇到，不是因為它完全做錯。


比較常見的情況反而是：它把 bug 修好了，然後順手改了附近的命名；它讓測試過了，然後順手重構一段原本沒人要動的流程；它修了 UI，卻多碰了另一個頁面的狀態管理。


這種時候很難生氣。因為它看起來不是惡意，也不是偷懶。它只是太積極。


問題是，reviewer 最後拿到的不是一個清楚的解法，而是一包很難判斷授權範圍的變更。你得先問：這些檔案是本來就該改，還是 agent 自己覺得順手？這個重構是必要，還是把一個小修補變成另一個風險？如果出事，責任算誰的？


這其實不是模型性格問題。更直接地說，是任務邊界設計太鬆。


「幫我修一下」不是工單


人類同事聽到「幫我修一下登入頁的錯誤」，通常會帶著一堆默契工作。他知道哪些模組最好不要碰，知道這次只是 hotfix，不該順便整理架構，也知道如果真的需要改 API contract，應該先回來討論。


agent 不一定知道。


就算它知道，也不一定知道這一次你授權它做到哪裡。尤其現在的 coding agent 越來越像真正的工作執行器：可以讀 repo、改檔案、跑測試、開 PR、呼叫工具，甚至透過 API 被派工。它不是只在聊天室裡給建議，而是在工作系統裡產生變更。


所以「幫我修一下」太模糊了。


比較好的任務描述，至少要包含四件事：


  • 這次要解決的問題是什麼

  • 允許修改哪些範圍

  • 明確不要做哪些事

  • 完成後要交回什麼證據


例如，不要只寫「修掉設定頁的儲存 bug」。可以寫成：「只處理設定頁按下儲存後沒有顯示成功狀態的問題；優先檢查 settings 相關元件和 API 呼叫；不要重構表單架構，不要新增套件，不要修改帳號權限流程；完成後列出修改檔案、執行過的測試，以及瀏覽器驗證結果。」


這不是把 prompt 寫得比較漂亮而已。這是在定義授權。


先 review scope，再 review 品質


現在很多 review 仍然習慣先看程式碼寫得好不好：命名清不清楚、測試夠不夠、邏輯有沒有重複。這些當然重要，但 agent 產出的 diff 還多了一個更早的問題：它有沒有只做這次該做的事？


如果 scope 已經跑掉，後面的品質討論很容易失焦。


一個重構可以很漂亮，但如果它不是這次任務需要的，就會增加 reviewer 的負擔。一次依賴升級可以通過測試，但如果原本只是修一個按鈕狀態，就不該混在同一個 diff 裡。agent 最麻煩的地方不是它一定會寫爛 code，而是它可能寫出看起來合理、但超出授權範圍的 code。


所以小團隊可以把 review 順序改一下。


先看變更範圍：哪些檔案被動到？有沒有碰到非目標模組？有沒有改資料結構、API contract、權限、部署、依賴？如果有，任務描述裡有沒有授權？


確認 scope 沒問題，再看實作品質。


這個順序很務實。它可以避免 reviewer 被一個看似勤奮的 patch 帶著跑。


non-goals 要寫出來


很多 agent 任務失控，不是因為目標寫錯，而是因為非目標沒有寫。


人類溝通裡，「不要做什麼」常常靠情境判斷。但 agent 接到的是一段任務，它會傾向完成它理解中的「更好狀態」。如果你說「整理這段流程」，它可能覺得命名、檔案結構、測試、文件都可以一起整理。它不是故意越權，只是你沒有把邊界畫出來。


non-goals 可以很簡單：


  • 不要重構資料模型

  • 不要新增套件

  • 不要修改 public API

  • 不要碰付款流程

  • 不要把這次修 bug 擴大成 UI redesign

  • 如果需要改 migration、CI、部署設定，先停下來回報


這些句子看起來有點瑣碎，但它們會讓 agent 的工作比較像一張明確的工單，而不是一個開放式願望。


對 reviewer 也有幫助。當 PR 回來時，你可以直接拿 non-goals 對照 diff。這比事後憑感覺說「你怎麼改這麼多」公平得多。


sandbox 和 logs 其實是在回答同一個問題


談 agent 安全時，大家常會提到 sandbox、approval、network policy、credentials、telemetry。這些詞聽起來像大公司才需要的治理工具，但對小團隊來說，它們其實在回答很普通的問題：


這次 agent 能做什麼？它做了什麼？哪些動作需要人同意？出了問題能不能回頭看？


sandbox 是範圍。approval 是停損點。network policy 是外部接觸邊界。logs 是事後可讀性。


如果把 coding agent 當成工作系統，而不是聊天玩具，這些都不算多餘。尤其當 agent 可以在背景跑、可以被 API 啟動、可以處理越來越長的任務時，人不可能永遠盯著螢幕。那就需要系統自己留下足夠的證據。


對日常開發來說，證據不一定要很重。至少可以要求 agent 在結尾固定交回：


  • 修改檔案清單

  • 執行過的命令

  • 測試結果

  • 沒有執行測試時的原因

  • 前端任務的截圖或瀏覽器 console 狀態

  • 它認為哪些地方仍然有風險


這些內容不是裝飾。它們讓 reviewer 可以從「相信 agent 說修好了」改成「看得懂它怎麼證明修好了」。


權限要慢慢放大


我不主張把 agent 綁到完全不能動。那樣也失去使用它的意義。


比較合理的方式，是讓權限跟可稽核能力一起成長。先從小範圍任務開始：單一 bug、單一元件、明確測試。等團隊確認 agent 能穩定遵守 scope、能交回可用證據、reviewer 也看得懂它的工作，再讓它處理更大的模組、更多工具、甚至 repo-level 設定。


這和帶新人有點像。你不會第一天就把部署權限、付款流程和資料庫 migration 全部交出去。你會先看他怎麼理解任務、怎麼回報、怎麼在不確定時停下來問。


agent 也一樣。


真正值得信任的 agent，不是什麼都能碰，而是知道這次不該碰什麼。它可以很強，但它的強要被放在清楚的邊界裡。


好的 agent 任務，其實是小型產品需求


以前我們把 prompt 當成一句請求。現在它越來越像一份小型產品需求。


不是因為要把每件事都官僚化，而是因為 agent 的輸出會進 repo、進 PR、進產品行為。當輸出有真實後果，任務描述就不能只靠一句模糊的期待。


對小團隊來說，可以先用一個很低成本的格式：


目標：
範圍：
非目標：
限制：
驗證方式：
需要停下來詢問的情況：


這幾行不會讓工作慢多少。相反，它常常會讓 agent 更快進入正確方向，也讓 reviewer 少花時間拆解一包過度熱心的 diff。


AI coding agent 的越界問題，很多時候不是因為它壞，也不是因為它想取代誰。


它只是把我們原本含糊的工作委派方式放大了。


以前人類靠默契補掉的部分，現在要寫進任務、規則、sandbox 和驗收證據裡。這聽起來不浪漫，但很實用。因為 coding agent 最好用的狀態，不是它自由發揮到讓人驚喜。


而是它能在清楚邊界內，把該做的事做完，並且讓人看得懂它到底做了什麼。


Source notes


CC BY-NC-ND 4.0 授权

喜欢我的作品吗？别忘了给予支持与赞赏，让我知道在创作的路上有你陪伴，一起延续这份热忱！

Ryan Vale
  • 来自作者
  • 相关推荐

AI agent 不是幫你寫完程式的人，而是一個需要收工規則的工作區

AI coding agent 的成熟，不是更會寫 code，而是有沒有可信的工作區

做 AI 產品時，先想清楚模型能按哪些按鈕