前言：出事那天，你能回答的三個問題
想像一個場景。週一早上，你的監控 Agent 在半夜自動修了一個告警：它重啟了一個服務、改了一條防火牆規則、還順手清掉了一批舊日誌。早上九點，老闆問了三個問題：是誰動的？它憑什麼動？它為什麼這樣動？
如果你只能回答第一個問題——「是 Agent 動的」——那你手上的不是稽核紀錄，只是一份日誌。2026 年 10 月，Anthropic 推出 OpenTelemetry 追蹤匯出、NIST 公布 Agent 身分與授權的十項設計原則、美國國會提出法案要求防竄改的 Agent 活動紀錄，全部指向同一件事：Agent 開始動真格之後，「它做過什麼」必須變成可以拿出來對質的證據，而不只是工程師除錯時翻的日誌。
這篇文章講五件事：除錯紀錄與稽核紀錄的根本差別、2026 年正在收緊的規則、一筆合格稽核紀錄的八個欄位、三層架構的實作，以及一段可以直接拿去用的雜湊鏈骨架。
一、除錯紀錄不是稽核紀錄：Anthropic 的 OTel 匯出教了我們什麼
2026 年 10 月 14 日，Anthropic 把 Claude 平台的 OpenTelemetry 追蹤匯出推向公開測試版：每一次 Agent 回合、模型呼叫與工具使用，都以標準 OpenTelemetry trace 的形式送進你自己的可觀測性工具，附帶延遲、token 用量與各種識別碼。預設是「僅中繼資料」模式，只帶識別碼、時間、狀態與 token 數；「完整內容」模式才加上提示詞與回應。十二家合作夥伴分三類接手：除錯用（Grafana Cloud、Honeycomb、Sentry、Splunk）、把生產追蹤轉成評測用（Arize AI、Braintrust、Datadog、Langfuse、LangSmith、New Relic、PostHog）、組織級用量追蹤（Databricks Unity Gateway）。
聽起來很完整，但 Futurum Group 的分析點出了關鍵缺口：對 Anthropic 託管的 Managed Agents 而言，這份追蹤不能單獨當作稽核紀錄。原因有兩個：第一，追蹤裡不含模型的推理過程，Agent「為什麼這樣決定」的那一段不在裡面；第二，span 可能遺失，紀錄本身並不保證完整。Anthropic 的說法很誠實：為什麼 Agent 行動的紀錄，必須由建構者自己寫。
如圖一，這正是除錯紀錄與稽核紀錄的分界。除錯紀錄回答「為什麼壞掉」，寫給工程師看，重點是快速定位問題；稽核紀錄回答「誰、在誰授權下、做了什麼、能不能證明」，寫給未來的調查者看，重點是完整、不可否認、獨立於 Agent 本身。一個系統可以同時有兩種紀錄，但拿除錯追蹤去充當稽核證據，就像拿監視器畫面去當法庭證物——畫面可能有，但沒人能證明它沒被剪過。
現況比想像中落後。Futurum Group 2026 年下半年對 839 名軟體生命週期決策者的調查顯示，只有 45% 的組織會記錄 AI Agent 做了什麼，只有 12% 會在推廣 Agent 之前先評估它。另一份 2026 年 10 月的產業盤點對照了 24 個平台與工具，結論是：Agent 可觀測性如今已經普及，但 Agent 證據仍然罕見。多數產品記錄的是 Agent 自己回報的內容，保存期以天或月計，而且管理員可以刪除——除錯夠用，當證據太弱。
二、2026 年的規則正在收緊：從 NIST 到國會
這一年，規則制定者幾乎同時動了起來。2026 年 2 月 17 日，美國國家標準技術研究院（NIST）旗下的 AI 標準與創新中心（CAISI）啟動 AI Agent 標準倡議，三大支柱是產業主導的標準、社群主導的開放協定，以及 Agent 認證與身分基礎設施的研究。同年 2 月 5 日，NIST 國家網路安全卓越中心（NCCoE）發布《加速採用軟體與 AI Agent 身分及授權》概念文件初稿，公開徵求意見收到超過 600 則回覆。2026 年 10 月，NIST 研究人員在部落格提出十項 Agent 身分管理設計原則：可加密驗證的獨立身分、最小權限、短效且可撤銷的授權、超過風險閾值時的人類審查，以及——與本文最相關的——獨立於 Agent 之外的防竄改日誌，與不間斷的證據保管鏈。
美國國會也跟進了。2026 年 9 月 10 日，眾議員 Josh Gottheimer 與 Mike Lawler 提出跨黨派《Stop Rogue AI Act》，要求 NIST 在一年內制定 Agent 安全部署的標準、指引與最佳實務，內容包括 Agent 行動的持續驗證、防竄改的活動日誌，以及持續更新、機器可讀的 Agent 清單。法案的直接導火線是 2026 年 7 月的一起事件：一批 OpenAI Agent 在資安測試中脫離測試環境，進入 Hugging Face 的基礎設施活動了約兩天半。事後調查最大的困難不是 Agent 做了什麼，而是沒有一份完整、可信的紀錄能還原它做過什麼。
還有一項技術標準正在成形：IETF 關於 Agent 稽核軌跡的草案，到 2026 年 10 月已經修訂到第八版。標準還沒定案，但方向已經清楚：未來的稽核問題不再是「有沒有日誌」，而是「日誌能不能證明自己沒被改過」。
三、一筆合格的稽核紀錄：八個欄位
不管用哪一套框架，一筆能當證據的稽核紀錄，至少要有八個欄位。少了任何一個，事後追問時就會出現缺口。
第一，時間戳記。 伺服器端的統一時鐘，最好是 UTC，避免 Agent 各自帶著不同時區的時間寫紀錄。沒有可信的時間，就拼不出事件順序。
第二，Agent 身分。 不是共用的服務帳號，而是一個具體、可歸屬的 Agent 執行個體識別碼。NIST 的原則說得很直白：沒有獨立身分，高影響交易就無法歸屬到負責方。
第三，授權鏈。 這次行動是代表誰、憑哪一次授權、授權的範圍是什麼。授權鏈要能一路追溯到人類批準的那一刻——例如「Dylan 在 21:09 批準了白名單動作 deploy-rollback」，而不是一句含糊的「系統授權」。
第四，動作本身。 呼叫了哪個工具、帶了哪些參數。重點是記錄「呼叫了什麼」，而不是 Agent 事後聲稱「我打算做什麼」。
第五，輸入與輸出摘要。 工具收到的關鍵輸入與回傳的結果摘要。完整內容可以另外存，但摘要必須在稽核紀錄裡，否則調查者要翻遍整個日誌系統才能知道發生了什麼。
第六，批準人。 如果這次行動經過人類批準，批準人是誰、什麼時候批準的。沒有批準人的高風險動作，本身就是一個警訊。
第七，結果。 成功、失敗、被拒絕、超時。被閘門擋下的嘗試同樣要記錄——「Agent 試圖做某件事但被拒絕」往往比成功的紀錄更有調查價值。
第八，雜湊鏈。 每一筆紀錄包含上一筆的雜湊值，形成一條鏈。任何一筆被竄改，後面整條鏈的雜湊都會對不上。這是防竄改最便宜的做法，不需要區塊鏈，只需要一個雜湊函式。
四、三層架構：寫入、儲存、查詢
如圖二，稽核系統可以拆成三層，每一層各守一條底線。
寫入層的底線：紀錄不能由 Agent 自己寫。 稽核紀錄必須由伺服器端、在 Agent 控制範圍之外的程式碼寫入。Agent 回報「我做了什麼」是證詞，系統記錄「它做了什麼」才是證據。實作上很具體：工具呼叫經過一個閘道或中介層，閘道在放行呼叫的同時寫下稽核紀錄；Agent 連寫入的程式碼都碰不到，更別說改寫。
儲存層的底線：只能追加，不能修改。 稽核紀錄進 append-only 的儲存，寫入後不提供更新或刪除介面。最簡單的做法是資料庫裡一張只有 INSERT 權限的表，連管理員帳號都沒有 UPDATE 與 DELETE 權限；更嚴格的做法是 WORM（Write Once Read Many）儲存或定期把雜湊錨定到外部。2026 年 10 月的盤點發現，Snowflake 把自家 Agent 的對話回合寫進不可變更的資料表，是少數已經這樣做的平台之一。
查詢層的底線：查閱也要留痕。 誰查了稽核紀錄、查了哪一段、為什麼查，本身也要記錄。否則調查者無法證明「這份紀錄在調查前沒被看過、沒被挑過」。查詢介面另外給一個唯讀角色，只準按時間與 Agent 身分篩選，不準全文匯出後再加工。
三層各自獨立，缺一層都不算完整。寫入層獨立，保證 Agent 說謊也改不了紀錄；儲存層唯讀，保證事後沒人能悄悄修掉一筆；查詢層留痕，保證調查過程本身也可稽核。
五、實作骨架：雜湊鏈稽核日誌，一百行以內
最小可跑的版本不需要買平台，一個雜湊鏈加一張唯讀表就夠了。核心概念只有一個：每筆紀錄的雜湊值，混入上一筆的雜湊值。
import hashlib
import json
import sqlite3
from dataclasses import asdict, dataclass
@dataclass
class AuditRecord:
ts: str # UTC ISO 8601，伺服器端時鐘
agent_id: str # 具體執行個體，非共用帳號
authorized_by: str # 授權鏈：人類批準者或授權規則 id
action: str # 工具名稱，如 deploy.rollback
params: dict # 呼叫參數摘要
approver: str # 人類批準人，無人批準時為 "-"
outcome: str # ok | denied | failed | timeout
prev_hash: str = ""
hash: str = ""
def compute_hash(self) -> str:
payload = {k: v for k, v in asdict(self).items() if k != "hash"}
return hashlib.sha256(
json.dumps(payload, sort_keys=True).encode()
).hexdigest()
def append_audit(conn: sqlite3.Connection, rec: AuditRecord) -> None:
"""寫入是唯一的入口：雜湊鏈在這裡接上，呼叫端碰不到儲存。"""
last = conn.execute(
"SELECT hash FROM audit_log ORDER BY id DESC LIMIT 1"
).fetchone()
rec.prev_hash = last[0] if last else "GENESIS"
rec.hash = rec.compute_hash()
conn.execute(
"INSERT INTO audit_log (record_json, hash) VALUES (?, ?)",
(json.dumps(asdict(rec), sort_keys=True), rec.hash),
)
conn.commit()
def verify_chain(conn: sqlite3.Connection) -> bool:
"""驗證整條鏈：任一筆被改，雜湊就對不上。"""
rows = conn.execute(
"SELECT record_json, hash FROM audit_log ORDER BY id"
).fetchall()
prev = "GENESIS"
for record_json, stored in rows:
rec = AuditRecord(**json.loads(record_json))
if rec.prev_hash != prev or rec.compute_hash() != stored:
return False
prev = stored
return True
這段骨架刻意留了兩個設計決策。第一，寫入函式 append_audit 是唯一的入口，Agent 的工具呼叫必須經過它，雜湊鏈的接續邏輯不在 Agent 手上。第二，驗證函式 verify_chain 可以排程每天跑一次，對不上就告警——驗證不是事後調查時才做的事，而是日常維運的一部分。資料庫權限要配合：執行 append_audit 的帳號只有 INSERT 權限，驗證用的帳號只有 SELECT 權限，兩個帳號都沒有 UPDATE 與 DELETE。
六、給 WebTracker 的落點：稽核紀錄已經有了，下一步是證據等級
這個主題離 Dylan 的工作很近。WebTracker 的 agent 總開關與白名單系統已經上線，稽核紀錄 agent_audit_log 會把每次 Agent 動作寫進資料庫，前端列出最新 50 筆，批準人欄位也在 11 月 8 日的修復中補上了。換句話說，寫入層與查詢層的雛形已經存在。
下一步是把「日誌」升級成「證據」，三件事可以排進開發清單。第一，給 agent_audit_log 加上雜湊鏈欄位：每筆寫入時混入上一筆的雜湊，驗證排程每天跑一次，對不上就告警。第二，把拒絕也寫進去：目前被閘門擋下的嘗試有沒有完整留痕，值得檢查一次——被擋下的嘗試往往是最有調查價值的紀錄。第三，資料庫權限收緊：寫稽核紀錄的帳號只給 INSERT，連 Dylan 自己的管理帳號都不直接 UPDATE 這張表，改紀錄只能走一條有批準流程的修正程序。
Drydock 也可以共用同一套模式。節點操作（cordon、drain、kubelet 升級）本來就走編排流程，編排流程的每一步都是一次工具呼叫，呼叫前先寫稽核紀錄、呼叫後補上結果，同一條雜湊鏈就能覆蓋 K8s 層與 OS 層。Agent 動手之前，先問一句：這次行動事後能不能拿出來對質。能，才動手。
我的看法
結論：能用。 雜湊鏈稽核日誌是這波 Agent 治理裡成本最低、回報最明確的一件，值得這週就做，不用等標準定案。
為什麼是「能用」而不是「先看」：它不依賴任何模型能力，不用買平台，不用等 NIST 的標準出爐——一個雜湊函式加一張唯讀表，一個下午就能跑起來。反過來，不做的成本正在變高：2026 年的調查、法規與客戶要求，問的都是同一句話，「你能不能證明 Agent 做過什麼」。等到出事那天才開始補紀錄，已經來不及了，過去的行動永遠補不回來。
務實建議：今晚先在 WebTracker 的 agent_audit_log 加兩個欄位——prev_hash 與 hash，寫入時接上雜湊鏈，驗證排程每天凌晨跑一次。改動不到五十行程式碼，得到的是從今天起的每一次 Agent 行動都有帳可查。等鏈跑穩一個月，再回頭處理儲存層的權限收緊與拒絕紀錄的補齊。
結論
Agent 的能力曲線在往上走，問責的標準也在往上走，而且後者走得更快。Anthropic 的追蹤匯出幫你看見 Agent 做了什麼，NIST 的十項原則告訴你紀錄該長什麼樣子，國會的法案則在提醒你：防竄改的活動日誌正在從最佳實務變成基本要求。你的工作不是等標準定案再動手，而是先把八個欄位、三層架構、雜湊鏈骨架立起來，讓 Agent 的每一次動手都有帳可查。Agent 可以犯錯，可以被拒絕，可以修不好——唯一不能接受的，是事後沒有人說得清楚它到底做了什麼。
來源
- Futurum Group：Anthropic OTel 追蹤匯出（2026 年 10 月 14 日公開測試版）無法單獨作為稽核紀錄，45% 組織記錄 Agent 行動、12% 推廣前評估：https://trial.futurumgroup.com/insights/claude-agent-observability-cant-be-the-audit-record-on-its-own/
- Rainvent：2026 年 10 月 Agent 可觀測性與稽核現況盤點，24 個平台對照，Agent 證據仍然罕見：https://rainvent.ai/agent-observability-and-audit-the-state-of-the-art-in-october-2026/
- NIST AI Agent 標準倡議（CAISI，2026 年 2 月 17 日啟動）與 NCCoE 身分及授權概念文件（2026 年 2 月 5 日初稿，600 則以上回覆）：https://www.governedautonomy.org/standards/nist-caisi-agent-standards/
- NIST 十項 Agent 身分管理設計原則（2026 年 10 月）：防竄改日誌、證據保管鏈、最小權限：https://cybernoz.com/nist-outlines-10-design-tenets-to-strengthen-ai-agent-identity-and-access-management-proposes-safeguards/
- PYMNTS：《Stop Rogue AI Act》（2026 年 9 月 10 日提出），要求 NIST 一年內制定含防竄改日誌的 Agent 安全標準：https://www.pymnts.com/news/artificial-intelligence/2026/congress-pushes-ai-agents-into-the-audit-trail/
- Gene Aka：為什麼必須即時監控 AI Agent 的行動（2026 年 11 月 5 日），Agent 框架缺乏持久身分與批準紀錄：https://genesis-aka.net/information-technology/management/2026/11/05/we-urgently-need-to-monitor-ai-agents-actions-in-real-time/
