瀏覽器開了很多頁面，終端跑過幾條命令，Agent還在說“繼續整理”。主管最想知道的不是它忙不忙，而是：離那份能用的結果，到底近了哪一步？
觀察AI Agent進展，不能只看流暢的敘述，也不必要求它披露隱藏推理。讓每個階段指向一件可檢查的證據。 開啟了來源、提取了事實、形成了比較，是三個不同的狀態。
Buda的Agent Workspace把聊天、Drive、Terminal、Browser和Git放在同一工作臺中。可見的工具動作幫助人介入，但不是完整審計日誌，更不是所有結果正確的保證。
開始前，約定下一件能開啟的東西
以下為虛構的低風險內部研究任務：根據獲准檢視的公開資料，整理三家供應商的服務範圍、報價入口和未知項。不是向供應商詢價，不傳送訊息，不處理賬戶秘密。示例路徑與階段狀態只解釋方法，不是實際執行截圖或測量結果。
與其說“查完告訴我”，不如先約定：
當前子目標：確認三家供應商的官方資料入口
下一件產物：sources.csv，含URL、讀取狀態、可核事實及未知項
下一個檢查點：在比較前，先展示這份來源清單
停止條件：頁面不可讀、關鍵欄位無來源、需要賬戶授權
允許動作：讀取公開頁面、寫本次結果目錄
禁止動作：聯絡供應商、登入個人賬戶、寫生產記錄
檢查點不是每隔幾分鐘報一次“還在做”。它應發生在證據狀態變化時：從找到入口，到抽取資訊，再到足以做比較。事先約定到這個粒度，主管才能知道下一次應該看什麼。
四類訊號，各自證明到哪一步
| 可見訊號 | 能說明什麼 | 還缺什麼 | 下一步核驗 |
|---|---|---|---|
| Browser開啟頁面 | 頁面被訪問；正文可讀時才有資料可用 | 來源是否官方、欄位是否真的出現 | 對照URL和頁面原文 |
| Terminal顯示命令 | 嘗試執行了操作 | 退出碼、錯誤和有效輸出 | 看完成狀態及相關輸出，不只看命令列 |
| Drive有檔案 | 路徑下存在產物 | 內容、完整度、版本和出處 | 開啟檔案，核對修改與實際內容 |
| Git出現diff | 有內容變更 | 測試、稽核或部署結果 | 讀差異；測試需獨立證據，部署另行驗收 |
Agent tab裡的工具呼叫可展開輸入和輸出。這能把一句“已整理”拆成可核動作；但一個標籤頁沒有顯示的事情，不能據此斷言從未發生。用正面證據確認進展，不把介面可見範圍誇大成完整事件記錄。
用三個階段快照，區分活動和進展
下面是同一個虛構任務的預期證據變化，不是三次已經執行的測評。
快照一：找到了入口。 瀏覽器開啟三家網站，sources.csv只有URL和讀取狀態。這可以證明來源入口已列出，還不能說服務範圍已經核實。主管下一步應看每條事實的出處，而不是要求立即給供應商排名。
快照二：兩家有事實，一家有缺口。 檔案新增了兩家的服務說明、原文位置和抓取時間；第三家報價頁不可讀，價格保持未知。與快照一相比，可用於比較的事實增多了。未知項被準確記錄也是進展，不必為了“完成三家”而猜一個價格。
快照三：比較稿可開啟。 comparison.md逐項引用來源，區分已核事實與待確認事項，並連結回清單。主管現在才有材料判斷是否滿足內部討論需要。寫出比較稿不代表可以聯絡供應商或作採購決定。
三個階段都可能有很多頁面和命令。真正的區別是：可核事實增加了嗎，缺口是否更清楚，下一階段是否有足夠輸入？
一個空檔案，足以戳破“已完成”
假設Agent說“比較表已生成”，Drive裡也出現 comparison.md，但開啟後只有標題，甚至是空檔案。這隻能證明檔案存在，不能證明比較已完成。
檢查標題下面有沒有三家物件、對應事實、來源與未知項。檔案變大也不是質量證明：重複貼上一段話，位元組數照樣上漲。修改時間只能幫助定位某次寫入，不替代內容檢查。
這時不必立刻重啟Agent或重新執行所有步驟。先要求給出當前檔案位置、已完成部分、未完成原因和下一個最小動作。如果當前狀態無法確認，保留現有檔案與會話，先澄清，而不是用一次重新執行覆蓋證據。
三種停滯，要問三種問題
等授權：問缺哪一項許可。 例如頁面要求登入。確認是否存在獲准路徑；沒有就保留缺口，不把“授權還沒到”當“Agent不會做”。也不要為推進研究而預設授權訪問私人賬戶。
來源失敗：問能否縮小到已核材料。 如果第三家頁面不可讀，讓Agent明確影響哪一項比較、有哪些合法替代來源需要確認。負責人可以接受“兩家已核、一家未知”的內部稿，也可以停止比較。不能把失敗頁面的快取摘要寫成官方事實。
原地重複：問本輪新增了哪條證據。 多次重新整理同一個失敗頁面、重複執行相同命令，若沒有新增可核資訊，就不算階段推進。沒有統一的“等五分鐘就卡住”閾值；應按來源狀態、工作量和下一件產物判斷。
可以直接提出這段請求：
請給出當前子目標、最新證據檔案與版本、已經核實的事實、仍未知的內容，以及下一檢查點。若需要許可權或來源無法讀取，說明最小缺口；不要補造欄位、擴大任務或自動重啟。
這是建議的監督請求，不是Buda後臺會自動執行的控制策略。
繼續、補輸入，還是縮小範圍？
如果事實與產物在增加，且沒有越界，繼續到下一個檢查點。如果缺的是負責人能提供的日期、路徑或授權，先補輸入。若證據支援不了最初目標，就縮小交付或停止那部分判斷。
把決定記成一句可追溯說明：“第三家價格未知；本輪只比較已核服務範圍，採購判斷留待確認。”這比“任務基本完成”更有用，也不會誤導下一位接手的人。
執行中檢查點解決的是如何決定下一步，不替代終稿驗收。並行產物整合還需要檢查不同產物的口徑和責任；監督邊界也不能靠一段自述來代替。
常見監督問題
沒有程式碼任務，還需要看終端和Git嗎？
只看與本任務有關的證據。純資料整理更應核輸入清單、提取結果、來源和最終檔案版本。沒有Git差異不等於沒有工作，不必為了顯得可觀察而製造提交。
Agent說完成，檔案也有了，還要看什麼？
開啟實際檔案，對照約定的物件、欄位、出處與未知項。再核對是否存在獨立的傳送或釋出請求；生成不代表傳送，diff也不代表部署。
其他Agent能直接讀這些檔案嗎？
不要假設。先核它實際獲准讀取的路徑與共享範圍；Agent Drive與Space Drive不同。需要交接時，明確授權位置與具體版本，不為方便而複製私人資料到共享目錄。
從一次內部研究開始建立檢查點
在Buda裡先給一個低風險任務約定下一件可開啟的產物，執行時用Workspace裡的工具動作與實際檔案對照。方法重複後，可以在Buda AI的Marketplace搜尋並安裝合適的Skill，檢查它是否輸出來源、缺口和檢查點。
先讓“正在處理”有證據，再讓監督頻率變少。減少打擾的前提，不是相信更多進度描述，而是每次介入都知道該看哪份東西。