一份共享 coding agent 的稽核日誌是一份僅供附加（append-only）的記錄，每個請求一行、每個核准一行，由機器的主人持有並可由其匯出。它能在事後回答：誰要求 agent 做了什麼、誰允許了這件事、實際執行了什麼，以及花費了多少成本。如果 agent 始終只由其主人使用，執行環境自帶的記錄就足夠了。但只要有第二個人可以發送請求，情況就完全不同了。
本文將依讀者需要的順序條列這些欄位，接著說明哪些內容絕對不能放進去。
請求行
每個請求在達到最終狀態時，都會精確產生一行記錄。
核准行
核准會獨立成行，因為它們屬於決策，而決策的讀者與執行的讀者並不相同。
請求行與核准行，其中核准的推送以琥珀色顯示，過期的刪除以紅色顯示。
哪些內容絕不能出現在日誌中
- 機密（Secrets）。 憑證核准記錄的是存取了某個金鑰的事實，而不是金鑰本身。
- 檔案內容。 Diff 是路徑與行數。程式碼變更位於版本庫中，由版本庫本身的存取控制來管理。
- 完整指令輸出。 最後幾行輸出已足以解釋失敗原因。完整的日誌可能包含任何內容。
- 其他房間。 每個房間的日誌僅限於該房間範圍。主人可以跨房間查看；成員只能看到自己的房間。
不只是欄位，更是核心特質
僅供附加（Append-only）。 沒有人能編輯日誌，包括主人在內。修正內容會以新的一行呈現。
主人持有。 由執行該工作的機器的主人持有這份記錄，且可以將其匯出。請求者可以在房間內看到自己的記錄行。
撤銷時仍保持完整。 撤銷授權或機器會取消排隊中的工作，並讓正在執行的工作順利完成，因此日誌絕不會出現「有東西在跑，但我們停止監控」的斷層。
包含主人操作。 主人對自己的 agent 雖然不需要經過核准，但他們的請求會以相同方式記錄。一份只記錄外部人員的日誌，只記錄了一半的風險。
閱讀日誌
有三個問題最常被提出，上述欄位只需一次篩選就能解答每個問題：
- 「那是誰推上去的？」 依規則 = push 篩選核准行，讀取誰提出的請求與誰做的決定。
- 「為什麼這個請求花了一個小時？」 比較 created 與 started；等待核准通常就是答案。
- 「這個月把 agent 借出去花了多少錢？」 將誰提出的請求不是主人的請求行用量加總。
常見問題
房間時間線就是稽核日誌嗎？ 時間線是單次執行詳細且供人類閱讀的記錄。稽核日誌則是跨多次執行、每個事件一行的摘要，專為篩選與匯出而設計。muti 兩者皆會保留；日誌衍生自 daemon 上傳的相同事件。請參閱 daemon 會上傳哪些內容。
日誌會保留多久？ 只要房間存在，請求行與核准行就會一直保留。刪除房間採用軟刪除（soft-delete）；主人仍會保留該記錄。
請求者能看到其他人的記錄行嗎？ 他們可以看到房間的時間線，其中包含該房間內每個人的請求。匯出權限則屬於主人。
主人的請求也需要核准才會被記錄嗎？ 不需要。主人的執行不需要核准就會被記錄，標註為 rule = owner。
日誌是讓「你稍後可以隨時撤銷」成為真正承諾的基石。為你的 agent 開設一個房間，它就隨附了一份完整日誌。
發布於