thinking 面板不是 audit trail
上週末有人翻了 Claude Code 的 session log，想看看 extended thinking 到底記了什麼。結果在 thinking block 裡找到的是一個 600 字元的加密 signature，沒有可讀文字。
這件事本身不算什麼大新聞，Anthropic 文件裡有寫，只是寫得很隱晦，如果沒喝咖啡大概會滑過去。但它引出來的問題我覺得比「廠商藏東西」這個陰謀論版本更有趣，也更值得認真想：reasoning summary 等不等於可稽核性？
摘要不是原文，這不只是資訊量的問題
Claude Code 本地 log 裡的 thinking block 是加密 blob，你拿不到原始 reasoning。API 和介面（ctrl+o）回傳的是 Anthropic 產生的摘要，不是驅動那次 action 的原始思路。
作者用了個不錯的比喻：把 BMP 存成 JPEG，再把 JPEG 轉回 BMP 宣稱品質沒差。轉換過程有資訊損失，這個大家都懂。但問題更根本。
摘要和原文的差距，不只是「細節少了一些」。摘要是事後重建的敘事，原文是當下決策的過程。 這兩件事在認識論上不等價。
法庭上不接受「我告訴你他當時說了什麼」當成直接證據，要求的是錄音或逐字稿，原因就在這裡。摘要無論寫得多精準，都無法保留原始過程裡的條件判斷、被捨棄的可能路徑、或是讓模型最後轉向的那個 token。
更麻煩的是，摘要本身也是由模型生成的。你在驗證一份由被驗證者自己寫的自述。這在任何 audit 框架裡都是一個很大的問題。
Agent workflow 裡，真正該保存的是什麼
我在 multi-agent 研究上碰過這個問題的學術版本。系統的可解釋性（explainability）和可稽核性（auditability）是兩件不同的事，但很容易被混在一起講。
可解釋性說的是：你能不能用人話告訴我這個結果是怎麼來的？
可稽核性說的是：你能不能讓我從第三方視角驗證這個過程確實發生了，而且沒有被篡改？
Thinking 面板滿足第一個，它給你一個故事。但它不滿足第二個，因為你無法驗證這個故事和實際執行路徑的對應關係。
如果要認真做 agent workflow 的 audit trail，論文裡討論的最低要求通常是這幾類證據：
- Input：每次 tool call 的完整 prompt context
- Output：模型的實際回應（不是摘要，是原始 token 序列）
- Action：agent 執行了什麼操作
- Tool call：呼叫了哪個工具，帶了什麼參數
- Result：工具回傳了什麼
這五件事都有記錄，加上時間戳和 hash，才能在事後重建執行鏈。thinking block 裡的東西不在這個清單上，因為即使有，它也只是輔助理解用的敘事，不是可驗證的因果鏈。
Claude Code 的 session log 確實有記錄 tool call 和 action，這部分是有用的。真正的問題是大家看到 thinking 面板會有錯誤的安全感，以為「有 reasoning 輸出 = 有 audit trail」。
把 thinking 面板當 audit trail 會造成什麼方法論錯誤
這不是純理論問題。如果你的 agent 在生產環境裡做了一個錯誤決策，你需要回答的問題是：為什麼它在那個時間點選了那個 action？
如果你的「稽核記錄」只有 reasoning summary，你能做的是：讀一篇事後重建的自述，然後說「嗯，模型說它當時是這樣想的」。
你無法回答的問題包括：
- 那份 reasoning 是在 action 之前還是之後產生的？（模型是先行動再解釋，還是先思考再行動？）
- Summary 裡省略了哪些被考慮過但最後沒選的路徑？
- 如果 prompt context 有微小變化，reasoning 和 action 是否會一致地改變？
第一個問題尤其重要。LLM 有沒有 chain-of-thought 式的因果 reasoning，或者 CoT 只是對已確定 output 的事後解釋，這個問題在 mechanistic interpretability 社群裡還沒有定論。如果 thinking 是事後生成的，那 thinking summary 作為行為依據的論證就從根本上垮了。
把 summary 當 audit trail 的實際風險是：你會建立一套看起來有稽核機制的流程，但在真正出問題的時候，這套流程提供的是安慰感，不是可操作的根因分析。
有一篇 2023 年 Turp
in et al. 的研究做過一個實驗，有點惡名昭彰：他們在 prompt 裡加了錯誤的偏誤提示，模型仍然產生流暢的 CoT 來「解釋」一個錯誤答案，而且 CoT 完全沒有提到那個偏誤提示的存在。換句話說，模型解釋自己的理由可以跟實際影響它行為的原因完全脫鉤。
Anthropic 為什麼這樣設計
HN 討論裡有人猜測是防蒸餾，這個說法不是沒有道理。如果 reasoning 可以被完整提取，有人可以用這份資料微調一個便宜的 open source 模型，等於免費拿了 Anthropic 的工程成果。加密 reasoning 並拿住金鑰，從商業角度是合理的自我保護。
另一條解釋是 reasoning 的品質問題。原始 thinking token 可能包含很多噪音、錯誤假設、以及中途修正，直接呈現給使用者可能比摘要版本更讓人困惑，而不是更清楚。
這兩個說法都可能成立，也都跟「可稽核性」的需求正面衝突。這是商業產品必然存在的張力，我不覺得 Anthropic 做錯了什麼，但這代表你沒辦法兩件事都要，除非你有企業合約。
結語（當成備忘錄）
如果你在設計 agent 系統，需要 audit trail，thinking 面板是加分工具但不是核心機制。核心機制是可重建的執行鏈：input、output、action、tool call、result，每一步都有記錄，加上足夠的時間戳。
Thinking 面板很有用，幫助你除錯、理解行為模式、寫 post-mortem。但在告訴利益關係人「我們的 agent 是可稽核的」之前，先搞清楚你說的可稽核是指哪一種。
博士念太久的代價是，每次看到「解釋性」和「稽核性」被混著用都會有點難受。
作者：十年大博士