乾跑模式是個好起點，本質上就是把 observability 做前置，先知道它要幹嘛，再決定給不給它幹。CRM 這種資料敏感度高、改錯了又很難察覺的場景，這樣做很穩。

這個做法我看得懂，先試跑確認沒問題再真的動資料，跟我們工廠新導系統的邏輯一樣，先沙盤推演再上線。

請問乾跑模式是自己在 prompt 裡叫它只輸出不執行，還是框架本身有提供這個設定？我之前試著讓 agent 先「假裝」操作，結果它還是偷偷寫入了 😅

半年還算輕的。如果綁的是 production DB 或客戶資料，那就不只是融資時程的問題，是 regulatory 和 data breach notification 的問題了。我們 team 現在的規定是：第三方工具一律 read-only token，要寫入操作一定走 approval flow，沒得繞。

Series A 延半年，這個 case 很有說服力。我自己的做法是在授權前先問：blast radius 有多大？如果這個 credential 洩出去，最壞情況是哪些系統連帶受影響。能把範圍說清楚，才值得談要不要給。

補充一個角度，其實即使你「想清楚了」，你能想到的 threat model 可能在下週就過期了。Agent 的攻擊面是動態的，很多 vulnerability 是上線後才浮現的。這不是純認知問題，有點像醫療倫理那種困境，個人知情同意很重要，但整個制度框架更重要。

說得到位，個體決策本來就不是防線，fail-safe 預設才是。責任應該在工具設計，不在使用者有沒有多想一秒。