16:00
畫面卡住
瀏覽器顯示舊狀態。Agent 需要知道資料長什麼樣子，而不是猜一個欄位名。
#42 已收到退款事件，畫面卻還卡在「處理中」。Agent 先查 orders，接著提議把幾筆狀態改成 paid。你本來只想讓畫面跑起來，但這份 fixture 同時被 e2e、同事和明早的 CI 使用。這是一個很常見的本機情節。專案的 Docker 資料庫裡，有一份用來重現付款頁 bug 的資料：訂單
如果資料庫真的只在你眼前活五分鐘，直接開 client、讓 Agent 幫忙打一兩句 SQL，很合理。可是一旦「確認 bug」變成「改掉大家都依賴的資料」，工作的性質已經變了：你需要的不只是連得上，而是下一個人看得懂、下一台機器跑得出同樣結果。
16:06
一筆修正要寫進 fixture
這不再是讀取；錯的條件可能讓下一個測試從一份已被污染的資料開始。
翌日 09:12
CI 沒有重現你的結果
對話紀錄找不到完整條件，卻有人得重新拼出昨天到底做了什麼。
這時候怎麼選工具
直接 DB client
適合：可拋棄的實驗、合成資料，以及可信任開發者會逐條查看的 SQL。
MCP database server
適合：Agent host 需要低風險、互動式的 tool 探索，而且該 host／server 的授權與日誌模型已符合需求。
dbcli
適合：真實資料、共享 fixture、migration、CI、incident runbook，或任何另一個人必須重跑的結果。
一開始
只是想確認畫面能不能跑
直接 client 讓 Agent 很快拿到答案。
五分鐘後
要改共享 fixture
改用 dbcli，留下下一個人也能執行的指令。
直接讓 Agent 操控 client
快的是眼前這一次
Agent 可以在 GUI、driver 或 shell 裡自行瀏覽、拼 SQL、送出寫入。上下文都在這場對話與那個工作階段裡；你在旁邊盯著時很有效率。
但當它提議「順手把三筆資料改好」，真正重要的資訊散在聊天、工具輸出和瀏覽紀錄：到底查過哪些欄位、WHERE 條件是什麼、那個寫入有沒有先被檢查過。
用 dbcli
留下的是下一次也能用的路徑
schema、保護規則、預覽寫入、實際執行與失敗復原，走的是同一個 CLI 介面。Agent 仍可以很快，但它交給你的不只是「我做完了」，而是一串可放進 PR、測試腳本或 runbook 的指令。
這不是把每個本機實驗變成嚴肅流程；是把共享資料、會重跑的操作和需要交接的結果，從一次性的聊天裡拿出來。
把這個下午的操作走一遍
這三個步驟沒有讓 Agent 少做事；它只是把原本隱藏在 client 操作裡的判斷，放到任何人都能檢查的地方。第一次看似多了幾秒，隔天少掉的卻是半小時猜測。
16:02：Agent 找不到欄位
它可能把 paid_at 想成 payment_at。先看哪些資訊不該被讀取，再把資料表真的有哪些欄位交給它。這一步很平凡，卻避免 Agent 在錯誤前提上寫出看似合理的修正。
dbcli blacklist list
dbcli schema orders --format json16:06：它想直接改 fixture
先把 UPDATE 印出來。你可以用兩眼確認條件是不是只選到 #42、它有沒有碰到退款金額或測試帳號。這是很適合人介入的幾秒鐘：SQL 還沒跑，風險卻已經具體可見。
dbcli update orders --where "id=42" --set '{"status":"paid"}' --dry-run16:08：確認後才寫入，並留下復原線索
把已確認的命令放進測試 script 或 PR 說明，不必靠記憶重建。若支援的指令失敗，--recovery 會留下機器可讀的下一步與對應 audit 紀錄；它不是魔法 rollback，但能讓排查從具體資訊開始。
dbcli query "SELECT status FROM orders WHERE id=42" --format json --recoveryMCP 在這個故事裡在哪裡？
MCP 不等於不安全，也不必和 dbcli 二選一。如果 Agent host 已替某個 database server 做好最小權限、資料遮罩、核准流程與可追查日誌，讓 Agent 用 MCP 互動式找表、讀少量資料，會很順手。它特別適合「先看看資料長什麼樣」這種探索。
差別在於責任落點。MCP 的界線與紀錄，要看 host、server 與你接上的那一個 tool 如何實作；直接 client 的界線，通常就是那次連線與操作者的習慣。
dbcli 的重點是把資料庫操作收斂成專案可約定、可檢查、可在 CI 重跑的命令契約。當需求從探索跨到寫入、共享 fixture 或交接，這個契約會比「Agent 已經連上了」更有價值。