這是我們預計每季更新的報告第一期：大家到底請別人的 coding agent 做些什麼，以及執行時發生了什麼事。數據來自 muti 的封閉測試，涵蓋截至 2026 年 9 月 6 日的三十天，規模很小：五十八次請求、六台機器、十個房間。我們仍然決定公開，因為目前還沒有人在發布任何關於共享 agent 的數據，而誠實的小數據勝過虛構的大數字。
所有數據均為總體彙整統計。不包含任何請求文字、姓名或房間名稱。
數據
前三十天的五項數據及其分母。
我們如何解讀
在沒有任何行銷宣傳的封測階段，三分之一的請求來自非主人，這比例相當高。 主人邀請了其他人，而那些人實際使用了 agent。共享本身就是這款產品的核心，而且它自然而然地發生了。
當核准很少出現時，回應速度就會很快。 58 次請求中僅有 9 次核准，回應時間中位數為 38 秒。這正是該設計所期望的行為：四種必定暫停的動作與權限模式讓 prompt 保持罕見，因此留下來的 prompt 能得到真正的審查。請參閱 agent 在執行前應一律詢問的四種動作。
Bash 會發問。 大多數的核准都涉及 Shell 指令。檔案讀取與編輯大多在 acceptEdits 下執行；真正需要人類介入的時刻是指令。這完全符合權限模式的設計初衷。
失敗多半是執行環境問題，而非權限問題。 共有 10 次請求失敗；在時間線中，它們分別是測試失敗、缺少工具，以及一次執行環境逾時。沒有任何一次是因為核准被拒絕。
任務耗時中位數為 41 秒。 目前共享 agent 被要求的都是小而具體的事情：重新跑這個、總結那個、匯出這些。耗時較長的大規模重構很少見，而且大多由主人自己發起。
這些數據不代表什麼
- 它們不具代表性。 僅有 6 台機器，且多半是我們自己和朋友的。隨著主人數量增長，非主人的請求比例在回升之前會先下降。
- 完成不等於正確。「完成」代表執行環境執行完畢且沒有報錯；結果品質好壞並未在此衡量。
- 核准延遲取決於主人。 9 個數據點、幾位主人、一個數字。請將其視為「一分鐘以內」，而非精確的「38 秒」。
我們未來會增加的內容
下一期內容：請求類別（程式碼／文件／資料／檔案）、附帶附件的請求比例，以及依一天中不同時段劃分的核准延遲。全為總體彙整數據，且皆會附上分母公開。
統計方法
數據來自產品實際運作所使用的資料表：requests、tool approvals、room memberships 與 timeline events，按 UTC 日期統計。無抽樣。軟刪除（soft-deleted）的房間與 agent 會從「當前」計數中排除，但包含在「歷史發生」計數中。稽核模型請參閱稽核日誌必須記錄哪些內容。
常見問題
我可以取得原始數據嗎？ 不行。我們只公開彙整後的數據；請求內容對其所屬房間是隱私保密的。
為什麼在 n = 58 的規模就發布？ 因為另一個選擇是什麼都不發布，而且清楚標示分母能讓讀者自行衡量權重。下一期的規模會更大，如果沒有，我們也會說明原因。
更新頻率為何？ 每季更新，採用相同的指標以便比較，並附加上期預告的新增項目。
如果你也想出現在下一期報告中，為你的 agent 開個房間吧。
發布於