審計軌跡

在實踐中

這個詞來自會計：審計軌跡指的是從一張彙總報表上的某個數字，一路回溯到它背後原始憑證的那條紙面路徑；而當年讓它值得保留的那些性質，到了軟體裡一條都沒變。條目只追加、從不修改，於是日後起爭議時讀到的還是當初那份記錄。每條條目點名的是行動的主體本人，而不只是一個賬號或一個程序，於是一個動作能被歸到一個答得起話的人頭上。最關鍵的是，這份記錄由執行工作的系統寫下，而不是由希望這件事被執行的那一方寫——當事方自己寫的日誌是一段敘述，它的可信度與當事方的可信度完全相等。最後這條性質，直接決定了 AI Agent 究竟能不能被治理：如果記錄「它做了什麼」的那份記錄是 Agent 自己寫的，那麼去問 Agent「有沒有出問題」根本不構成一種控制。

ObjectStack 把這件事記錄為 sys_audit_log——一個只追加的平臺物件，而不是一個日誌檔案。它的每一個欄位都是隻讀，API 只暴露 get 與 list，因此不存在經由表單或端點的寫入路徑；行是由內部鉤子在動作執行的同時寫下的。每一行帶著動作、它觸碰的物件與記錄、執行的使用者，以及變更前後的值，於是「那筆折扣是誰改的」得到的是一份 diff，而不只是一個時間戳。即便是一次並非以人的身份認證的寫入，也照樣可歸屬：服務主體會以 svc:名稱 的形式落在 actor 列上，而不是留下一個空值。保留期是宣告出來的、而非順其自然：該物件在 ADR-0057 下被歸入合規賬本這一保留類別，熱存 90 天，隨後歸檔而非刪除，歸檔副本保留七年。

有一條設計規則值得借走，無論你用不用這個平臺：合規介面上絕不能出現一個自己並不填充的列。一個空單元格會被讀成「已採集，且什麼都沒發生」，而不是「根本沒采集」——這兩種誤讀裡，前者危險得多。所以沒有寫入方的審計動作、沒有寫入方的列，都是從賬本里刪掉，而不是留在那裡冒充一次並不存在的採集。另一條規則是賬本只有一本、不是兩本：Agent 的動作與人的動作由同一個執行時記錄在同一個地方，用同一套篩選、同一種 diff。這正是「審閱 AI 與審閱人是同一件事」得以成立的原因——而它成立的前提，是那一行由執行時來寫，不是由 Agent 來寫。