AI 代理監控新思維：別信自我報告，改讀系統日誌

我最初的代理儀表板依賴代理自行報告工作。如果代理工作了卻沒有報告，辦公室看起來就會空蕩蕩的。那是 9 月 21 日的設計。四天後，在增加了一堆額外功能後，我要求從頭開始重新設計。一個依賴被監控對象來報告狀態的看板，當被監控對象沉默時就會變空白。解決辦法就是停止詢問代理任何事情。

這與 Refmade 的關係是，我正在獨自開發一款桌面應用程式，它以一個小型辦公室的圖示，顯示你的 Claude Code 和 Codex 會話正在做什麼。這是一個獨立的應用程式，不隸屬於 Anthropic 或 OpenAI。Claude Code 和 Codex 代理在我指導下編寫了大部分程式碼，而我負責規劃、決策和審查。目前使用者介面是韓文，本系列後續文章會改變。

本系列早期文章提到：第一個辦公室是我在 9 月 20 日建立的代理團隊儀表板（第一篇文章），在接下來的幾天裡，範圍擴展到留言簿、禮物和一個包含 266 個裝飾品的轉蛋系統（第二篇文章）。這篇文章講述了我停止這些功能的那一天。

9 月 25 日，我將現有產品與最初的計畫進行比較，並告訴代理產品已經偏離了方向。我想要的東西很簡單：看到協調和本地命令列介面（CLI）實際如何運行，感受工作完成的進度，偷看其他人的辦公室，並看到每個代理的工作和交接。我要求從頭開始重新設計，而不是打補丁。

設計文件以診斷開頭。在 9 月 21 日到 25 日之間，產品增加了迷你首頁、禮物、獎勵箱轉蛋、代幣金字塔、公共村莊、文章翻譯以及從網路在你的電腦上執行任務的功能。每個功能都讓它偏離了核心問題：我的 AI 團隊現在在做什麼？那天我回答了四個設計問題。

一個辦公室樓層作為中心畫面。其他人的辦公室只對朋友可見。協調僅從終端機進行，網路視圖為唯讀。範圍僅限於設計文件和一個動態原型，不觸及任何現有程式碼。朋友可見的想法一直持續到 9 月 27 日，也就是第六篇文章。

第一個設計看起來是這樣的。之前（9 月 21 日）：代理 --寫報告--> 看板；沒有報告 = 空辦公室。之後（9 月 25 日）：CLI --寫會話日誌--> 磁碟；辦公室讀取日誌（唯讀）；不需要報告，沒有什麼會被遺忘。Claude Code 和 Codex 已經將每個會話寫入本地文件。

這些文件顯示會話何時開始、每個步驟呼叫了哪個工具、哪個子代理由誰產生，以及透過一些推斷，請求何時結束。所以新的規則是這些。一個會話就是一個團隊。主會話是團隊負責人。每個子代理都是團隊成員，透過其中繼資料文件中的 parentAgentId 連結到其父級，workflowPhase 說明它屬於哪個工作流程階段。

每個桌上的監視器會根據代理正在做的事情改變顏色，這僅由工具名稱決定。隱私方面與可靠性方面同樣重要。設計指出辦公室將根據時間戳、工具名稱、父級連結和請求邊界運行，不會讀取提示詞、程式碼或文件路徑。

我在即時讀取器存在之前就將這個界限寫入了文件中，因為一個需要你的提示詞的儀表板是不同的產品。後來發布的讀取器稍微不那麼純粹：它會查看記憶中的一些文字來應用其規則，並為本地頁面保留一個會話標題、一個資料夾名稱和一句話的結果。第四篇文章列出了它查看和保留的內容。

我那天沒有建立即時讀取器。9 月 25 日的原型透過新規則重播了我自己真實的 Claude Code 日誌，時間是 9 月 24 日韓國時間凌晨 02:00 到 03:30 的 90 分鐘。擷取器省略了訊息文字、路徑和工具參數。

重播顯示的結果如下：團隊（會話）數量 10 個，代理 79 個（10 個負責人，56 個工作流程代理，11 個子代理，2 個分支），動作 4,699 個，交接 157 次（59 次委託，66 次報告，32 次傳遞），完成的請求 45 個。

32 次「傳遞」是從工作流程標籤推斷出來的（當代理的標籤匹配且時間線對齊時，擷取器會將工作從一個代理傳遞給下一個），所以這一個應視為猜測，而非測量。其他計數來自擷取腳本，它們與原型播放的重播文件匹配。我無法顯示原型的螢幕截圖，因為其中的團隊名稱是我機器上的真實會話標題。

下面的兩張截圖來自目前的應用程式，使用我用於發布說明的公開演示數據。它們顯示了相同的想法在成長後的樣子：辦公室計算正在工作的人數、完成的請求以及等待我回應的請求。Refmade 的辦公室標頭，演示數據。韓文顯示「1 個任務正在等待你的回答」（橫幅），「我的辦公室」，「9 人正在工作」，「0 個已完成請求」，「1 個需要我的回答」。

遊戲主題中的團隊面板，演示數據：「進行中的任務。2 個團隊正在工作。1 個需要我的回答。」任務名稱「分類客戶查詢回覆」是虛構的。

從頭開始重新設計意味著一個移除清單，而移除清單比功能清單還要長。從新應用程式中移除的功能：迷你首頁、留言簿、禮物（9 月 21 日至 22 日），獎勵箱轉蛋、266 個裝飾品（9 月 21 日至 25 日），代幣金字塔、工地村莊、A/B 世界（9 月 24 日），公共村莊、文章翻譯（4 種語言）（9 月 24 日），從網路在我的電腦上執行任務（9 月 22 日至 23 日）。設計文件指出，當實施開始時，移除的程式碼會移至歸檔資料夾，而不是被刪除。

首先，觀察無法知道計畫。會話日誌不會說明還剩下多少步驟，因此被觀察的團隊永遠無法獲得進度百分比。只有透過我自己的 refmade run 命令啟動的團隊才知道其計畫（「5 個中的 3 個已完成」），並且只有該團隊會顯示進度計數。我寧願缺少一個數字，也不願發明一個。

其次，看板顯示的是「已完成請求」，而不是「已成功」。當 Claude Code 結束其回合時，請求就完成了；第四篇文章涵蓋了其他情況。工作是否良好是另一個問題，日誌無法回答。看板上的措辭保持了這種區別。

還有一個風險不在我的程式碼範圍內。日誌是每個供應商的內部格式，版本更新可能會改變它們。讀取它們是一種賭注，賭它們的格式足夠接近，讓我能夠跟上。

獨立的設計審查給原型打了 6 分（滿分 10 分），並列出了八個問題。我解決了所有八個問題：面板重新渲染時焦點跳走、完成看板在行動裝置上被裁剪、文字最小 11 像素、我的回合和等待問題的顏色太接近，以及時間軸的鍵盤控制。檢查報告零設計錯誤，並且在 360 到 1920 像素範圍內沒有水平滾動。

根據簡報自己的清單，仍有粗糙之處：角色以直線行走，沒有步行動畫，藝術是 9 月 21 日資產的臨時剪貼，原型中的三個朋友是虛構的例子。下一篇文章將介紹讀取器如何區分請求與工具結果、分支與真實子代理，以及請求何時真正結束。應用程式連結將在系列的最後一篇文章中提供。

對於你自己的代理的狀態看板，你寧願相信它們自己說做了什麼，還是磁碟上的文件說做了什麼，即使文件格式可能會改變？