NetworkChuck 用 Paperclip 組 AI IT 團隊，追查沖水與 NAS 斷線之謎

一張 ticket 展開成網路圖、決策與排程

CEO 把故障拆給網路、儲存、掃描與資安角色。agent 登入交換器、整理工作室網路圖、比對 NAS client 是否同時掉線，也把事件擷取工具交給另一個 agent 做資安審查。產出的網路圖、Markdown 報告與時間軸都留在原任務旁，NetworkChuck 則在 Decisions 裡回答是否做沖水測試、是否先換 optical module，以及要不要另外開 ticket。

他也建立每天上午十點檢查儲存空間的 routine，指定 agent 回報剩餘容量並在異常時建立 decision。這表示 Paperclip 不只整理一次性聊天，而是把排程、執行紀錄、產物與需要人決定的分岔放在同一個地方；同時也表示它拿到的是能讀取真實基礎設施的工具，而不是隔離的示範資料。

第一份報告不敢怪馬桶，第二輪才縮到四條鏈路

第一份誠實報告沒有把「沖馬桶」寫成因果，只承認多條鏈路會在同一外力下同時掉線。NAS、路由器與交換器本身沒有停機，四條特定光纖鏈路卻會在兩秒內一起掉線；保留的一週紀錄中出現 36 次。報告因此只說沖水符合現象，開門、冷氣壓縮機或椅子撞到配線附近也都可能。

問題持續後，團隊再往下查：四個埠失去同步的頻率明顯偏高，其中一個埠自交換器開機後記錄 20,052 次 link down，旁邊可比較的埠只有 123 次。這些埠使用的第三方 SFP 模組又集中在同一批次，影片把它們視為目前最有力的共同點。NetworkChuck 最後換上 MikroTik 原廠模組，但也說要再觀察一到兩週才算結案。最後的 SFP 更換仍要觀察一到兩週，不能把換上新模組直接寫成已經修好。

控制面板有煞車，影片沒有交代帳單

Paperclip 官方文件提供公司、agent 與 project 層級的預算控制，預設可在使用到 80% 時警告、100% 時停止對應範圍；approval 也能在雇用或重大決策前要求人類核准。不過，這些上限依賴 adapter 回報與已記錄的 spend，不能直接當成供應商帳單的絕對上限，更不能證明多層 agent 分工本身划算。Paperclip 可以留下工作脈絡、設預算與暫停 agent，卻不能替你回答這整套分工是否比一個人完成更省錢。

這正是留言區最集中的疑問。擷取時互動最高的相關留言有 603 個讚，直接問整起「馬桶事件」消耗多少 token 與費用；另一則 92 個讚的留言也希望加入成本總結。影片列出十個 agent、不同雲端模型與本機模型，卻沒有公布這次任務的總用量，也沒有解釋為什麼每個角色要選那個模型。

這次示範最有說服力的不是「AI 公司已經可以自己運作」，而是失敗、阻礙、回報、審核與人類決定都有可追的工作位置。代價也同樣清楚：角色越多，呼叫模型、授權工具與檢查結果的面積就越大；Paperclip 的核准與稽核主要管得到控制面，無法自動攔下 agent 透過 shell、網路或第三方服務做出的每個外部動作。把一群 agent 畫成公司很直觀；要讓它成為可靠的 IT 部門，還得把 sandbox、唯讀權限、變更前備份、模型費用與驗收條件逐項寫進制度。