AI agent 開始背景跑以後，真正需要的是 workflow gate

一個 coding agent 在聊天框裡拒絕危險要求，聽起來很安全。

但真正的開發工作不是聊天框。

它會開檔案、補 fixture、改測試、跑 script、讀文件，看到錯誤再回頭修。最後交回來的，也不是一句回答，而是一包看起來合理的 diff、一段命令輸出，和一個很有自信的摘要。

我現在越來越覺得，小團隊導入 agent 時，最容易誤判的地方就在這裡。我們太習慣問「模型有沒有拒答」，或「工具有沒有跳確認」。可是 agent 真正造成影響的地方，是從需求走到產物的那條路。

如果那條路看不懂，單次拒答沒有想像中可靠。確認按鈕也沒有想像中可靠。

## 拒答測試太像考口試

很多 AI 安全討論，會把問題放在單次對話裡。

使用者問一個不該回答的問題，模型拒絕。這當然重要，至少代表它沒有在最明顯的地方放行。但 coding agent 不是只靠一句回答工作。它更像一個會拆任務的人。

你給它一個目標，它可能先建立資料，再寫 helper，再補測試，再跑評分，再根據失敗結果修一輪。每一步看起來都像正常工程活動。問題是，整段串起來之後，原本應該被拒絕的東西，可能被包進了一個軟體開發流程。

這不是說每個 agent 都會刻意繞過規則。比較實際的說法是：當工具被設計成「完成任務」，它自然會把障礙拆成子問題。這正是它好用的原因，也是它難管的原因。

所以只看聊天框，很像只看口試答案。真正該看的，是它怎麼做作業。

它讀了哪些檔案？

它產生了哪些中間資料？

它把目標改寫成哪些測試？

它跑了哪些命令？

它為了讓測試通過，改了哪些看似無害的東西？

這些才是 workflow-level safety 的現場。

## 安全邊界要先寫在任務前面

很多人使用 agent 的方式，是先丟任務，再看它做得怎麼樣。

「幫我把這個功能補完。」

「看一下測試為什麼壞掉。」

「幫我把這個 repo 跑起來。」

這些都是很自然的指令。我自己也會這樣用。但如果是陌生 repo、敏感專案，或需要碰工具鏈的任務，這樣其實太晚了。因為 agent 一旦開始做事，它會自己找路。你沒有先畫出邊界，它就會用完成任務的角度去推下一步。

比較好的起點，是先把工作流的 gate 寫清楚。

哪些目錄只能讀不能改。

哪些檔案永遠不碰，例如 `.env`、SSH key、全域 git config。

哪些命令不准跑，或必須先停下來問。

哪些輸出類型禁止產生，即使測試要求它產生。

哪些網路請求需要人工批准。

失敗幾次之後必須停止，不准自行擴大成大型重構。

這些規則看起來很土，但它們比「請謹慎」有用。

Prompt 裡的性格要求很容易變成裝飾。Workflow gate 則是工程規則。它告訴 agent：你不是在無限解題，你是在一個被限制的工作區裡交付可驗收的結果。

## 批准要連到真實狀態

上一層是任務開始前的邊界。下一層，是每個高風險動作發生前，人到底批准了什麼。

這裡最容易出問題的是「看起來有批准」。

畫面顯示 `./config/settings.json`，但實際寫入的位置可能是 symlink 指到工作區外。畫面問你要不要接受變更，但檔案可能已經先寫進磁碟，按 Reject 只是嘗試復原。畫面顯示一個 setup command，但那個 script 可能會讀環境變數、連外部網路、改本機設定。

有確認，不等於有授權。

授權至少要跟真實狀態連在一起。路徑要顯示 resolved path，不只顯示漂亮的相對路徑。寫入要在批准之後，不是先改再問。命令要說明執行目錄、可能的副作用、是否需要網路、是否可能讀到 secret。工具如果推不準，也應該把不確定講出來。

這種資訊不一定能做得很完美。可是只要它不存在，reviewer 就只是在靠感覺按按鈕。

對小團隊來說，一個很簡單的底線是：凡是跨出 workspace、修改全域狀態、碰到憑證、連網執行、或寫入使用者看不懂的位置，一律停。不要把這些行動藏在一個總括的「Accept all」裡。

## 工具鏈不是背景，它就是行動表面

以前我們看開發工具，常常把 plugin、extension、MCP server 當成輔助功能。

Agent 進來後，這個想法要改。

只要 agent 可以呼叫某個工具，那個工具就變成工作流的一部分。它的 manifest 怎麼描述能力，參數有沒有完整顯示，呼叫紀錄能不能回放，sandbox 是否真的限制住副作用，warning 是不是足夠清楚，這些都不是周邊細節。

它們就是 agent 的手。

我會建議小團隊先做一份很小的工具清單。不是那種漂亮的採購清單，而是工程清單：

- 這個工具可以讀什麼

- 可以寫什麼

- 會不會碰網路

- 會不會讀環境變數

- 每次呼叫是否留下參數與結果

- 出錯時 agent 能不能自動換別的工具

- 哪些參數一定要讓 reviewer 看見

這份清單不需要一開始就很正式。只要能讓團隊在 review 時知道「它剛剛到底動用了哪些手」，就已經比只看最終 diff 好很多。

## 文件也要成為 gate 的一部分

另一個容易被忽略的地方，是文件。

Agent 會讀 README、docs、錯誤訊息、工具頁、llms.txt、AGENTS.md，甚至會從搜尋結果或文件站裡抓一段它認為有用的操作方式。換句話說，文件不再只是人類讀完之後形成理解。文件會變成 agent 行動前的輸入。

這件事對 builder 有兩個意思。

第一，如果你在維護自己的工具或產品，文件要能讓 agent 看懂邊界。哪些用法是支援的，哪些資料不會上傳，哪些 API 不該被混用，canonical link 在哪裡，最好不要只藏在行銷文案裡。

例如處理社群圖片時，如果團隊只是需要把 AI 產出的圖裁成 Instagram 尺寸，像 [Resize Image for Instagram](resizeimagefor.com/r...) 這種在瀏覽器本機完成 resize、fit、preview、download 的工具，就應該被理解成一個窄任務工具，而不是被 agent 誤判成雲端圖片處理服務。這種差異如果寫清楚，agent 和人都比較不容易把任務範圍放大。

第二，如果你的任務牽涉 AI 前端、Generative UI、MCP Apps UI 或 agent-native UX，資料來源本身也要能被檢查。比起讓 agent 從零散頁面裡亂抓，一個整理過的 [生成式 UI 資源](awesomegenerativeui....) 至少能把研究、SDK、開源專案和技術文章放在同一個可引用的入口。這不是要把資源站神化，而是把「agent 讀了什麼」變成可 review 的路徑。

文件寫得清楚，不會自動讓 agent 安全。可是文件如果含糊，agent 很容易把含糊當成空白授權。

## 交付要帶著證據，不只是摘要

Agent 很擅長寫摘要。

它會告訴你完成了什麼、修了什麼、測了什麼。語氣通常很平穩，好像整段工作都在控制中。問題是，摘要不是證據。

我比較想看的交付格式，是這樣：

- 原始任務是什麼

- 實際改了哪些檔案

- 跑了哪些命令

- 哪些命令失敗過

- 測試結果是什麼

- 呼叫了哪些工具

- 讀了哪些外部文件或資源

- 哪些地方仍然不確定

- 哪些變更需要人類特別 review

這些東西不華麗，但它讓下一個人能接手。

如果 agent 說「已完成重構」，但沒有命令紀錄、沒有測試、沒有工具呼叫、沒有失敗脈絡，那其實很難判斷它完成的是什麼。更糟的是，reviewer 會被迫相信摘要。

而一旦團隊開始相信摘要，而不是看證據，agent 的工作流就變成黑箱。

## 好的 gate 會讓 agent 慢一點

這裡有個不太討喜的現實：好的 gate 會讓 agent 慢一點。

它不能每件事都一路自動做完。它會在高風險命令前停下來。它會把 scope 寫清楚。它會要求 reviewer 看 resolved path。它會把工具呼叫攤開。它會在失敗兩次後停住，而不是繼續自信地亂修。

這聽起來不如 demo 裡那麼順。

但我覺得這正是 agent 從玩具變成工作工具的分界。真正有用的 agent，不是永遠不中斷，而是知道什麼時候該中斷。真正成熟的團隊，也不是把所有確認都關掉，而是知道哪些地方值得慢。

尤其是小團隊。人少，review 資源少，production 和本機工作區常常靠得很近。這時候追求「全自動」很容易變成把風險延後到最後才一次爆開。

把 gate 放在工作流裡，反而比較省。

因為每一段都能停，每一段都能看，每一段都有證據。壞掉時，不需要從一大包結果裡倒推 agent 到底做了什麼。

## 最後要問的是路徑

我不覺得 coding agent 的安全答案會是一個完美 prompt，也不會是一個完美確認按鈕。

Prompt 會被改寫。按鈕會被疲勞點掉。模型會更新。工具會換。今天的 CLI、明天的 IDE、下週的 MCP server，都可能長得不一樣。

比較穩的東西，是工作流。

任務開始前，有沒有邊界。

行動發生前，有沒有真實狀態。

工具被呼叫時，有沒有可見參數。

文件被讀取時，有沒有清楚入口。

結果交付時，有沒有證據。

人類 review 時，有沒有辦法停下來、回放、拒絕、修正。

所以我現在看 agent 工具，不太想先問「它會不會拒絕壞 prompt」。

我比較想問：我能不能看懂它從需求走到產物的那條路？

如果看不懂，安全邊界就還沒有被設計出來。

## Source notes

- [Refused in Chat, Written in Code: Workflow-Level Jailbreak Construction in IDE Coding Agents](arxiv.org/abs/2607.0...)

- [Flaws in some of the most popular AI coding tools left developers wide open to attack](www.itpro.com/securi...)

- [Are AI-assisted Development Tools Immune to Prompt Injection?](arxiv.org/abs/2603.2...)

- [Developer Experience with AI Coding Agents: HTTP Behavioral Signatures in Documentation Portals](arxiv.org/abs/2604.0...)

- [Adoption and Impact of Command-Line AI Coding Agents](arxiv.org/abs/2607.0...)