AI agent 越像同事，越要看清楚它背後送出了什麼

很多人評估 AI 工具時，第一個問題都是：它聰不聰明？寫得快不快？能不能幫我省時間？

這些當然重要，但當 AI agent 開始能讀檔、改檔、跑命令、連外部工具、串接 gateway 之後，真正的信任問題已經不只在「回答品質」。

更重要的是：它到底看見什麼、送出什麼、記錄什麼。

AI agent 不是普通聊天框

一般聊天工具的風險比較直覺：你輸入什麼，它就回什麼。

AI agent 不一樣。

一個 coding agent 或工作流 agent，通常會接觸更多東西：

• 專案檔案與資料夾結構
• 終端機命令與執行結果
• git diff、測試結果、錯誤訊息
• 外部 API、gateway 或企業網路路由
• system prompt 與工具層設定
• 使用量、錯誤、請求紀錄或稽核資料

這些能力讓 agent 變得好用，也讓它進入更敏感的信任區域。

當一個工具能幫你做事，它就不再只是模型，而是一整套會讀、會送、會記錄、會執行的軟體系統。

system prompt 是信任邊界的一部分

很多人把 prompt 想成「我輸入的那段文字」。

但在實際產品裡，模型看到的上下文通常不只使用者輸入。

它可能還包含：

• 工具本身注入的 system prompt
• 當前時間、環境、工作目錄或專案資訊
• 工具可用能力與限制
• route、gateway、帳號或組織設定
• 安全、合規、反濫用或產品策略相關指示

這些內容未必全部顯示給使用者。

問題不在於工具不能有 system prompt。AI 產品本來就需要 system prompt 才能穩定運作。

真正的問題是：當 system prompt 會根據環境或設定而改變時，使用者是否知道這件事？是否能理解哪些資訊會進入模型？是否能查到可稽核的紀錄？

如果答案都是否定的，信任就會變得很脆弱。

gateway 與 telemetry 不是壞事，但要講清楚

企業或團隊使用 AI 工具時，透過 gateway 管理模型請求其實很常見。

gateway 可以提供幾個重要能力：

• 把 credential 留在伺服器端
• 追蹤使用量與成本
• 設定預算與 rate limit
• 保留 audit log
• 管理不同 provider 或部署環境

這些都是合理需求。

telemetry 也不一定等於壞事。產品團隊需要知道錯誤率、效能、濫用模式，才能維護服務品質與安全。

但問題在於透明度。

使用者不一定反對紀錄、稽核或反濫用機制；使用者真正反感的是「不知道自己被怎麼判斷、怎麼分類、怎麼記錄」。

好的工具不只要能做事，也要能讓人看懂它正在怎麼做事。

評估 AI agent，可以先問五個問題

如果你正在使用或評估 AI agent，不必一開始就陷入複雜技術細節。先問五個簡單問題就夠了。

第一，它會讀到哪些資料？

它只能看你貼上的內容，還是能讀整個資料夾、repo、瀏覽器、終端機輸出？能不能限制範圍？

第二，它會送出哪些上下文？

除了你輸入的文字，工具會不會把檔案片段、錯誤訊息、環境資訊、路由設定或其他 metadata 放進請求？

第三，它會記錄什麼？

請求內容、使用量、錯誤、執行命令、檔案變更、工具呼叫紀錄，哪些會被保存？保存多久？誰能查看？

第四，它的行為會不會依環境改變？

不同 gateway、不同組織設定、不同權限、不同網路路由，是否會影響送給模型的內容或工具可用能力？

第五，使用者能不能驗證？

有沒有 log、request preview、audit trail、設定文件、關閉選項，或至少清楚的產品說明？

這五題不一定每個產品都能完美回答，但只要完全回答不了，就代表信任成本很高。

速度讓人想用，透明度才讓人敢長期用

AI agent 的吸引力很明顯：它可以省時間、串流程、減少重複工作，甚至像一個會動手的助理。

但越是能動手的工具，越需要清楚邊界。

不透明的工具，短期可能仍然好用；長期卻會讓使用者不敢把重要工作交給它。

真正可靠的 AI agent，不只要回答得好，也要讓人知道：

• 它看見什麼
• 它送出什麼
• 它記錄什麼
• 它能做什麼
• 它不能做什麼

模型能力會快速進步，價格也會一直變。

但信任不是靠跑分建立的。

信任建立在那些看起來很無聊、卻最關鍵的地方：清楚的設定、可理解的紀錄、可控的權限，以及不把重要行為藏在使用者看不到的角落。

回文章列表