Supabase Agent prompts 是什麼？讓 AI 代理定時查日誌、安全與慢查詢的設定與風險
Supabase 在 10 月 20 日公布 Agent prompts，讓 Claude、Codex 或 Cursor 在唯讀權限下定時檢查正式專案的錯誤、安全、慢查詢與資源成長。本文整理四份提示的觸發門檻、query_logs 工具、設定步驟、日誌隱私與提示注入風險。
2026 年 10 月 21 日凌晨，Supabase 官方帳號在 X 上說，你的程式代理現在能查 Supabase 的日誌，官方的 skill 也會指出該盯的訊號，例如錯誤暴增、安全問題、慢查詢與用量成長，而且由你決定何時跑。
貼文附了一支 1 分 41 秒的影片，到 10 月 21 日晚間查詢時，有約 340 個讚、3.8 萬次瀏覽。
貼文的說法很容易被讀成 Supabase 內建了一個會自己盯著專案的 AI。
其實官方部落格寫得很清楚，Supabase 提供的是四份提示詞、一個新的唯讀日誌查詢工具，與更新後的 skill。真正執行與排程的，是你自己的 Claude、Codex 或 Cursor。
這個分工決定了三件事：誰付代理的使用量、日誌內容會流到哪裡，以及出事時誰負責看報告。
多數團隊現在是等使用者回報問題，才去翻日誌與資料庫報表，所以發現得晚。這套做法想讓代理先替你看一遍，並且只在有新問題或變嚴重時才回報。
我的判斷是，已有正式專案、沒有專職監控人員的小團隊，值得從一份提示、唯讀、每天或每週跑一次開始試。但需要即時告警、值班輪替，或要拿它取代完整監控系統的團隊，它現階段還不夠，因為最快的建議頻率也只是每小時一次。
要判斷這套做法可不可靠，得先看四份提示到底查什麼，門檻又從哪裡來。
Supabase Agent prompts 是什麼？四份提示詞加一個查日誌工具
Agent prompts 是 Supabase 文件裡的四份提示詞，每份告訴代理檢查專案的一個面向，並回報值得處理的問題。依 Supabase 官方文件，它們只讀取專案資料，因此不會修改任何東西。
這是 10 月 2 日 Supabase Select 活動「Operate with confidence」主題的一部分。
10 月 20 日的部落格列出五項已上線的發布。除了這四份 Agent prompts，還有 query_logs 工具、更新後的 skill、儀表板的 Health 分頁，以及 Database Connections 頁面。
MCP 是讓代理呼叫外部工具的標準介面。skill 則是一包給代理讀的操作說明，因為模型不一定熟悉每個產品，所以要告訴它遇到某類問題該先查什麼。
四份 Agent prompts 的分工如下，建議頻率是官方寫在文件裡的。
| 提示 | 檢查什麼 | 建議頻率 |
|---|---|---|
| Health | API 與 Auth 伺服器錯誤、錯誤率暴增、連線壓力 | 每小時 |
| Security | Security Advisor 的發現、驗證與授權失敗 | 每天 |
| Performance | 慢查詢、鎖等待、長時間工作階段、Performance Advisor 的發現 | 每小時 |
| Resources | 請求、錯誤、儲存、資料表與連線的成長 | 每天 |
官方對小專案的建議很務實。挑最相關的一份 Agent prompts，每天或每週跑一次，其他類別併進去，只有在需要不同負責人、排程或門檻時才拆開。
回報的格式也有規範。每個發現要附上量到的數值、對照的門檻，以及一個下一步。只有新出現或變嚴重的問題才會回報，乾淨的一次執行什麼都不說，沒辦法執行的檢查則會被明確列出。
所以它不是每次都產出一份長報告，而是設計成安靜的。這個安靜靠的是門檻，所以要先弄清楚門檻從哪裡來。
Supabase Agent prompts 的觸發門檻怎麼來
門檻來自另一份公開文件，叫做 Detection checks（偵測檢查）。每次執行時，提示會要求代理先去讀這份文件，取得最新的查詢與數值，如果讀不到，就回報無法評估，不會自己猜。
文件寫明，預設值是起始的告警政策，可以覆寫，但不是 Supabase 的服務保證。下表是我整理的主要門檻。
| 檢查 | 官方預設的觸發條件 |
|---|---|
| API 或 Auth 伺服器錯誤 | 最近一個完整 UTC 小時，錯誤至少 20 次、錯誤率至少 1%，且至少是前一小時的 2 倍 |
| 連線壓力 | 用戶端連線達 max_connections 的 80% |
| 授權失敗（401 與 403） | 以天為單位，條件同上：至少 20 次、1% 以上、前一天的 2 倍 |
| 安全與效能 Advisor | 回報 WARN 與 ERROR 等級，INFO 只當背景 |
| 長時間工作階段 | 執行中或在交易中閒置超過 30 秒，或擋住別人 |
| 查詢變慢 | 平均執行時間至少 100 毫秒且為前一小時的 2 倍，兩個區間各至少 20 次呼叫 |
| 請求量成長 | 至少 1,000 筆事件且為前一天的 2 倍 |
表格裡有兩個細節。錯誤率的比較要求兩個時段都至少有 100 筆回應，如果不夠，就判定為無法評估。查詢變慢則要先開啟 pg_stat_statements，並且保存三份相隔一小時的快照，因為它要比較前後兩個區間。
這代表流量很小的專案，Health 的錯誤率檢查可能常常是無法評估，因為一小時內不到 100 筆回應。這是我依文件規則推出來的結果，不是官方說的。
另外，資源預測要至少七天的每日數據，而且要有確認過的上限，只會回報 14 天內可能耗盡的線性估計。所以新專案的前一週，不會看到容量的趨勢預測。
官方也提醒，Agent prompts 的發現不等於原因。文件寫，一次授權失敗暴增是需要檢視的訊號，不是被攻擊的證明，所以報告要區分觀察到的事實與推測。
有了門檻，代理還需要工具去取得證據。
延伸閱讀：Claude AI 代理刪庫事件：企業導入 AI Agent 的安全警訊
query_logs 與更新後的 skill：代理怎麼拿到證據
query_logs 是新的 Supabase MCP 工具，能對專案日誌執行唯讀的 SQL，每次請求最多涵蓋 24 小時，可以聚合也能跨欄位關聯。所以 Health 提示就是用它比較每小時 API 與 Auth 的錯誤。
偵測文件說明，日誌用 ClickHouse 語法的 SQL 查，Postgres 內部狀態如連線與長查詢，則改用另一個唯讀的 execute_sql 工具。
文件還有幾條查詢規則。因為要控制掃描量，日誌查詢面會拒絕 select * 與 count(*)，要列出欄位並改用 count()，查詢要有明確的時間範圍與筆數上限。
這些規則的用意是防止代理一次掃描過多資料，也讓回傳的內容可以被控管。如果你想審查代理的行為，這是好事。
skill 則負責「知識」這一塊。官方說，supabase skill 現在涵蓋除錯。
當代理遇到 Postgres 或 PostgREST 錯誤碼、查不到資料，或被列層級安全性（RLS）意外擋下時，它要先讀 Supabase 的觀測文件再診斷，不能憑記憶。
我在 10 月 21 日查看 supabase/agent-skills 倉庫，skill 的 Debugging 一節指示代理先讀 Monitoring and Debugging 文件。這個網址目前會以 308 轉址到觀測文件頁，所以和部落格說的是同一份。
安裝指令是 npx skills add supabase/agent-skills，已安裝的人則執行 npx skills update。倉庫採 MIT 授權，查詢時約 2,900 顆星，但安裝前仍應先看過內容。
儀表板這邊還有兩項。Advisors 頁面多了 Health 分頁，會標出 Data API、Auth、Storage 與 Edge Functions 中高於正常的錯誤率，可以手動或透過管理 API 執行。
Database Connections 頁面則列出誰占著連線、哪些查詢跑太久、哪些在交易中閒置或被擋住、誰握著鎖，所以不寫 SQL 也能取消查詢或終止連線。官方說它對所有專案預設開啟，包括自架。
工具與知識都齊了，接下來是動手設定。
照官方步驟設定一次 Agent prompts 唯讀檢查
官方的設定分五步，我把它們整理成一個可完成的小任務。
先連接 Supabase MCP，限定單一專案並設為唯讀。部落格給的 Claude Code 指令，網址裡帶 project_ref 與 read_only=true，因為唯讀會讓每個查詢都用唯讀的 Postgres 使用者執行。
接著從文件頁複製提示，先手動跑一次，讀過報告再排程。官方明說，這是在信任排程之前該做的事，因為你要先知道報告長什麼樣子。
然後才是排程，可以用 Claude 的 routine、Codex 的排程任務，或 Cursor 的 automation。官方提醒，排程執行時無法停下來問你，所以只預先核准提示需要的唯讀工具。
另外要允許代理讀取提示裡連結的官方文件，否則門檻抓不到，只會回報無法評估。
排程任務每次都是全新的上下文，所以提示本身要自足。想避免重複回報，還要讓代理工具保存告警狀態，否則代理會說它分不出哪些是新的。
最後是處理報告。報告會出現在你的代理工具裡，想轉到別處可以在提示裡加上目的地，例如開一張 Linear 工單。
如果是我，會先在非正式的測試專案跑，確認報告格式看得懂，再接正式專案。小專案則先選一份，每天或每週一次，連續看三份報告，再決定要不要接工單。
設定好以後，更要先想清楚日誌會流到哪裡。
延伸閱讀：Supabase 本地開發可免 Docker：AI 代理、pg-delta 與多工作目錄怎麼配合？
日誌與正式資料會流到哪裡：權限與隱私檢查
這套做法最需要先想清楚的是資料流向。官方文件直接警告，日誌與查詢結果可能含有密鑰或個資，所以代理要保持唯讀、只回傳彙總後的證據，並遮蔽敏感值。
排程跑 Agent prompts 時，代理讀到的日誌會進入你所用的代理服務的上下文。這是我依運作方式的推論，所以日誌裡有什麼，就等於把什麼交給那家服務，請先確認你的方案與資料政策。
另一個風險是提示注入，意思是有人把惡意指令藏在內容裡，讓模型誤當成命令執行。部落格說，這些提示會要求代理忽略日誌或查詢結果裡的指令。
MCP 文件有專門的提示注入段落。Supabase 會在 SQL 結果外包上額外說明，要模型別照資料裡的指令做，但文件說這並非萬無一失，仍要檢查輸出。
文件也寫道，無人看管的排程不能逐次要求核准，應預先核准限定專案的唯讀工具，並要求遇到寫入操作時停下來提出建議。
可以用的控制手段有幾層，由窄到寬。project_ref 限定單一專案，read_only=true 限定唯讀，如果還想再收緊，features 參數可以只開放需要的工具群組。
另外，Supabase 在 10 月 2 日宣布，範圍受限的個人存取權杖已正式推出，儀表板新建立的權杖預設就是範圍受限的，官方建議從唯讀權杖開始。
MCP 的確認提示也會在建立付費資源或執行可能刪資料的 SQL 前詢問。但官方自己說這不保證能擋下一切，需要用戶端支援，而且 execute_sql 的確認只在非唯讀模式才會出現。
最後，認證失敗的分析要依狀態碼與去識別化的路徑分組，不要依使用者、電子郵件或 IP 分組。這是偵測文件的明確寫法，因為這樣報告裡就不會帶出個資。
權限收緊以後，才好回答這套做法適合誰。
Supabase Agent prompts 適合誰、不適合誰
適合的是已經有正式專案、但沒有專人看日誌的小團隊，以及獨立開發者。這類人常是出事了才發現，一份每天讀一次的唯讀報告，成本低，也容易驗證效果。
同時用 Claude、Codex 或 Cursor 的團隊也較順手，因為官方已經準備好三種工具的排程步驟。
不適合的是需要秒級告警與值班流程的團隊，因為最快的建議頻率是每小時。需要完整保存歷史指標的人也不適合，因為提示要靠你的代理工具保存快照與告警狀態。
還有一種是不願意讓日誌進入第三方模型服務的團隊，在沒有確認資料政策之前，不該開始。
適不適合之外，還有幾個限制要先知道。
Supabase Agent prompts 的限制與風險
時間解析度與門檻的前提
官方文件說明，工作階段的快照無法還原兩次排程之間已經結束的連線，所以短暫卡住的查詢可能漏掉。
門檻也有前提。最小樣本數、至少三份快照、七天歷史，都讓新專案或小流量專案很容易得到「無法評估」，而不是「正常」。官方也特別寫，沒有事件不代表服務健康。
成本、證據來源與責任界線
成本沒有明講。我讀的部落格與提示頁，沒有看到 Supabase 對這些功能另外收費的說明，但排程執行會用掉你代理工具的額度，這要自己算。
證據也都來自 Supabase 自己。貼文、部落格與文件都是官方寫的，而我沒有實際跑過，所以以上是依官方文件整理，沒有獨立測試。
責任界線則很清楚。代理回報的是線索，所以要不要改設定、取消查詢，仍然由你決定。官方的提示也明寫，不會改 schema、政策、設定或資料，不會取消工作階段，也不會執行修復。
Supabase Agent prompts 常見問題
Supabase Agent prompts 要付費嗎？
官方部落格與提示頁沒有說明另外收費。但排程與模型用量由你的 Claude、Codex 或 Cursor 方案決定，Supabase 專案本身的方案限制，則請以官方定價頁為準。
一定要用 Claude 才能用嗎？
不用。文件提供 Claude、Codex 與 Cursor 的設定步驟，如果你用別的工具，也可以把提示複製過去。重點是該工具要能排程、能保存狀態，並且可以連 Supabase MCP。
代理會改我的資料庫嗎？
提示被設計成唯讀，MCP 設定也要加 read_only=true。這兩層都到位時，代理只能讀取。但你自己改設定、放寬權限之後，保護就不再成立。
自架的 Supabase 能用嗎？
官方只明說 Database Connections 頁面包含自架專案。至於其他功能在自架環境能不能用，我讀過的部落格與提示頁沒有說明，所以請先在測試環境確認。
先用唯讀的一份提示試一週，再決定要不要排程
Supabase 這次做的事，是把「該看哪些訊號、門檻是多少、怎麼回報」寫成公開文件，讓你的代理照著跑。它的價值在於把臨時查日誌變成固定流程，所以應該把它當成每天的例行檢查，而不是多一個監控系統。
建議從一個非正式的專案開始，用 Agent prompts 中的一份，連上唯讀、限定專案的 MCP，手動跑一次 Health 或 Security 提示，讀懂報告再排程。如果連續看一週後報告都有用，再決定是否擴大。
想持續追蹤資料庫與代理工具的實用更新，可以免費訂閱 AI 郵報，並在設定前回到官方文件核對最新門檻。
資料來源
- Supabase 官方部落格 Operate with confidence: check production with your coding agent：https://supabase.com/blog/operate-with-confidence-check-production-with-your-coding-agent
- Supabase 官方部落格 Operate with confidence（Select 發布）：https://supabase.com/blog/select-2026-operate-with-confidence
- Supabase 文件 Agent prompts：https://supabase.com/docs/guides/observability/automate-with-agents
- Supabase 文件 Health 提示：https://supabase.com/docs/guides/observability/automate-with-agents/health
- Supabase 文件 Detection checks：https://supabase.com/docs/guides/observability/detecting
- Supabase 文件 Query logs with SQL：https://supabase.com/docs/guides/observability/advanced-log-filtering
- Supabase 文件 MCP：https://supabase.com/docs/guides/ai-tools/mcp
- Supabase agent-skills 倉庫：https://github.com/supabase/agent-skills
- X 貼文（Supabase 官方帳號，經 fxtwitter 鏡像讀取）：https://x.com/supabase/status/2112578077872050470
