2026 年 3 月 31 日，公開報導指出，Claude Code 的某次 npm 發布版本意外包含了一份原始碼對照表（source map），暴露出大量內部 TypeScript 原始碼。Ars Technica、Zscaler 等媒體報導稱，外洩內容涵蓋約 1,900 個 TypeScript 檔案，共計約 512,000 至 513,000 行程式碼。Anthropic 表示，此次外洩屬於發布封裝（release-packaging）問題，並未涉及任何敏感客戶資料或憑證。
多數早期報導聚焦於最引人注目的發現——記憶系統、隱藏模式、尚未發布的功能、內部命名等。但更值得長期關注的教訓其實更為低調。外洩程式碼的公開分析顯示，一個正式環境等級的程式碼 Agent，需要在模型周圍投入大量工程資源：權限管理、遙測（telemetry）、分析（analytics）、工作階段追蹤（session tracing）、工具執行、IDE 整合、MCP 整合、背景任務，以及多 Agent 協同運作。
這指向一項正在興起的專業領域：Agent 行為分析（Agent Behavior Analysis, ABA）。其目標是將每一次互動、模型呼叫、工具呼叫、核准等待、封鎖狀態、工作階段關係與治理事件，全部轉化為可查詢、可關聯、可審查的遙測資料。
正式環境 Agent 不只是模型的包裝層
Claude Code 常被視為一款 CLI 程式碼助理。但外洩原始碼的公開分析顯示，其底層其實是一套規模更龐大的執行環境：權限層、記憶層、背景工作、IDE 橋接、MCP 路徑，以及圍繞模型運作的多 Agent 協同機制。
確切的程式碼行數拆解應視為基於原始碼推導的分析結果，而非官方架構文件。儘管如此,方向已相當明確：正式環境 Agent 中，直接呼叫模型的部分只占一小塊，其餘絕大部分都是執行環境的工程建置。
對企業團隊而言，這一點至關重要，因為運營風險並不侷限於模型的回應本身——它存在於模型周邊的整個系統之中：
- Agent 呼叫了哪個工具？
- 適用了哪個權限邊界？
- 是否有人核准了該動作？
- Agent 是否卡在等待使用者輸入？
- 子 Agent 是否繼承了正確的情境（context）？
- 該動作屬於哪個工作階段（session）或父工作階段？
- 有哪些資料進入了追蹤紀錄，又有哪些被遮蔽（redact）？
這些都是可視性（observability）問題，但並非一般的 APM 問題。
Agent 可視性的三個層級是什麼？
公開的原始碼推導分析描述了 Claude Code 中三個獨立的可視性層級。即使是從零開始建置自有 Agent 執行環境的團隊，這種區分依然適用。
| 層級 | 回答的問題 | 範例 |
|---|---|---|
| 產品分析事件 | 發生了哪些面向使用者的行為？ | OAuth 流程啟動、外掛安裝、工作階段恢復 |
| 標準遙測資料 | 基礎架構的效能表現如何？ | 請求數、延遲、錯誤率、匯出器（exporter）狀態（OTel、Prometheus、OTLP） |
| 工作階段層級的 Agent 追蹤 | 某一次使用者互動在執行環境內部是如何展開的？ | 互動、LLM 請求、工具呼叫、工具因待核准而封鎖、工具執行、hook 執行 |
產品分析不應與執行環境追蹤混為一談。產品事件與模型執行片段（span）可能發生在同一個工作階段中，但兩者回答的是不同的問題。
工作階段層級的追蹤，正是為 Agent 專屬調查而設計的層級。其基本單位是一次使用者互動，而不僅僅是一次 HTTP 請求。單一回合（turn）可能包含提示（prompt）處理、多次模型呼叫、多次工具呼叫、核准等待、hook，以及恢復（resume）邏輯。若缺少互動層級的根片段（root span），調查工作就會變成一堆彼此無關的事件堆疊。
為何關聯鍵比更多日誌更重要
Agent 系統之所以難以調查，是因為同一個動作可能以多種形式出現。一個 Agent 可能是：
- 本地子 Agent
- 群集（swarm）中的隊友
- 獨立行程
- 由框架管理的工作者（worker）
- IDE 內的程式碼助理
- 透過 MCP 呼叫的工作流參與者
要理清這些關係，需要穩定的關聯鍵：
user.idsession.idorganization.idagentIdparentSessionIdagentTypeteamName
這些識別碼讓後端能夠建立一張最基本的關係圖——哪個工作階段是啟用中的、哪個 Agent 執行了該動作、該動作屬於哪個父工作階段，以及它屬於哪個團隊或工作空間。這正是 Agent 行為分析的起點。如果每一筆事件都以扁平化的日誌行呈現，團隊就無法調查多 Agent 死結、成本暴增或工具濫用事件。
語意化片段勝過函式層級的計時
傳統追蹤從函式、請求與資料庫呼叫開始。而 Agent 追蹤需要更高層級的分類體系：
agent.interactionagent.llm_requestagent.toolagent.tool.blocked_on_useragent.tool.executionagent.hook
其中 blocked_on_user 這個片段值得特別關注。在 Agent 系統中，「時間」不僅僅是機器運算的時間——核准等待、人工確認、被中斷的回合，以及人為決策，都是執行路徑的一部分。
將這段時間單獨切分出來，能讓團隊回答更精確的問題：
- 這個回合是因為模型較慢才變慢的嗎？
- 是工具執行本身較慢嗎？
- Agent 是否在等待使用者核准？
- 高風險工具是否經常被拒絕？
- 子 Agent 是否因缺乏權限而卡住？
這正是 Agent 行為分析的核心價值。它不只顯示呼叫了哪個 API——它揭示了 Agent 行為如何展開、在哪裡停下，以及哪個邊界條件形塑了接下來發生的事。
分類體系即治理機制
Agent 可視性會產生高維度、半結構化、高基數（high-cardinality）的資料。若不加節制地儲存每一則提示、工具名稱、伺服器名稱、檔案路徑、使用者訊息與內部變數，整個平台就會變得昂貴、雜訊過多且風險重重。
良好的分類體系本身就是一種治理機制。針對 Claude Code 的公開原始碼推導分析，指出了以下對企業系統至關重要的模式：
- 元資料（metadata）應依類型加以限制
- 敏感字串應要求明確處理
- 私有酬載欄位應在向外部擴散前先剔除
- 使用者自訂的 MCP 伺服器與工具名稱可能需要正規化處理
- 提示文字、工具內容與工具參數應由明確的開關控制
- 高基數識別碼應被有意識地管理
這不僅是資料模型設計的問題——它同時涉及隱私、成本、後端穩定性,以及事件審查。
TrueWatch 從這個模式中汲取了什麼
上述設計方向，與 TrueWatch 處理 AI Agent 可視性的方式不謀而合。
資料靈活，不預設固定的 Agent 形態。 Agent 的身分並非固定不變——團隊可能同時運行 OpenClaw、Claude Code、Codex、內部 Agent、透過 MCP 連接的助理，或特定產品的工作流，各自產生不同的欄位。TrueWatch 的設計目標，就是能接收異質的可視性資料並使其可查詢，而不會在第一天就強迫每個團隊套用同一套僵化的結構，因為下一個有用的欄位可能是 sessionId、parentSessionId、skillName、teamName、approvalState，或是團隊目前尚未用到的其他欄位。
蒐集與處理彼此分離。 DataKit 在目標環境中蒐集遙測資料；管線（pipeline）處理則在資料抵達平台前，負責解析、篩選、豐富化與遮蔽。這正呼應了 Claude Code 分析中的一項教訓：治理應從蒐集端就開始，而不是等資料已擴散到每一個接收端之後才進行。
DQL 提供操作人員單一的查詢平面。 Agent 行為橫跨多種資料類型——單一次調查可能同時需要追蹤片段（trace span）、Token 指標、日誌、事件、核准紀錄與服務資料。DQL 能將工具呼叫、追蹤 ID、Token 暴增、錯誤日誌與服務依賴關係串聯起來，不必讓任何人在互不相關的系統之間來回切換。
高基數資料需要被認真對待。 工作階段 ID、追蹤 ID、Agent ID、工具名稱、模型版本、提示變體與工作空間識別碼都可能迅速暴增。TrueWatch 將基數（cardinality）視為一項架構問題，而非附註小事——這樣團隊才能保留有用的細節，而不會讓可視性後端本身變成下一場事故。
Agent 行為分析的四個企業應用場景
1. Token 成本歸因
一個客服 Agent 上線正式環境。到了月底，模型 API 支出遠高於預期。應用程式日誌只能顯示總使用量，卻無法回答真正的問題：究竟是哪個技能（skill）、提示版本、模型，還是工作階段模式導致了成長？
透過 Agent 行為分析，團隊可以依應用程式、模型、技能、工作階段、工具或提示版本，對 Token 使用量進行分組。問題根源往往微不足道——例如一個新的訂單歷史技能，每個回合攜帶了過多的情境內容。修復方法通常很簡單，難的是取得可視性。
2. 高風險工具使用與緊急停止
一個運維（Ops）Agent 擁有執行資料庫維護任務的權限。某個邊界條件出錯，導致該 Agent 開始嘗試執行一類危險的 SQL 操作。
CPU 與記憶體圖表可能看起來一切正常。而 Agent 片段卻揭露了真實行為：對某個高風險工具的重複呼叫、目標資料庫、指令類別、工作階段，以及權限情境。搭配正確的告警政策，平台可以通知負責人、開立事件單，或透過受治理的工作流撤銷憑證——事後審查也能依循追蹤紀錄進行，而不必從散落各處的日誌中重新拼湊事發經過。
3. 多 Agent 死結
一個團隊運行一個群集（swarm），包含需求 Agent、程式碼 Agent 與測試 Agent。整個工作流卡住——需求 Agent 認為工作已經交接完成，而測試 Agent 卻持續等待一份永遠不會送達的程式碼輸出。
像 parentSessionId 與 agentId 這類關聯鍵，讓平台能將這些動作串聯成一張拓樸圖。團隊可能會發現，程式碼 Agent 在某次 git_commit 工具呼叫時因等待使用者核准而被封鎖，卻未能將該狀態回報給上游。若缺乏行為分析，這看起來就只是一片沉默。但有了工作階段追蹤，這個死結就有了明確的位置。
4. 合規審計與過度授權偵測
一個金融服務團隊導入了一個報表 Agent，該 Agent 應該只能存取已遮蔽（redacted）的資料集。稽核人員需要證據，證明該 Agent 從未查詢過原始客戶資料。
Agent 行為分析可以記錄每一個步驟中使用了哪個 MCP 伺服器、工具、資料集與權限範圍。任何嘗試呼叫未經核准的伺服器或原始資料來源的行為，都能被記錄、封鎖並審查——這不僅是監控，更是合規控制面的一部分。
常見問題
問：什麼是 Agent 行為分析？ 答：Agent 行為分析（ABA）是一種做法，將每一次 Agent 互動——模型呼叫、工具呼叫、核准等待、封鎖狀態與工作階段關係——全部轉化為可查詢、可關聯、可審查的遙測資料，而不是將 Agent 活動視為扁平化的日誌。
問：Claude Code 原始碼外洩事件實際暴露了什麼？ 答：根據公開報導，Claude Code 某次 npm 發布版本的封裝問題，暴露了一份涵蓋約 1,900 個 TypeScript 檔案、約 512,000 至 513,000 行程式碼的原始碼對照表。Anthropic 表示未有任何敏感客戶資料或憑證外洩。
問：為什麼標準 APM 對 AI Agent 而言不夠用？ 答：標準 APM 追蹤的是請求、延遲與基礎架構健康狀況。而 Agent 系統需要一個能夠對應到單一使用者互動（而非僅是一次 HTTP 請求）的工作階段層級，用以呈現業務語意——例如工具呼叫、核准等待、hook 執行等。
問：Agent 可視性中的關聯鍵是什麼？ 答：關聯鍵是穩定的識別碼——例如 sessionId、agentId、parentSessionId 與 teamName——它們讓可視性平台能夠重建：哪個 Agent 在哪個工作階段中做了什麼，以及該工作階段屬於哪個父工作階段或團隊。
問：TrueWatch 如何處理高基數的 Agent 資料？ 答：TrueWatch 將基數視為一項架構考量，而非事後補救的問題,因此團隊能夠以調查所需的細緻程度，保留工作階段 ID、追蹤 ID、Agent ID 與提示變體，同時不會使後端系統失去穩定性。
每一個正式環境 Agent 都需要行為分析
根據 Anthropic 的公開聲明，Claude Code 的原始碼對照表事件屬於封裝錯誤，而非客戶資料外洩事件。其更深層的教訓，關乎 Agent 執行環境的工程設計。
正式環境等級的 Agent，需要將可視性納入設計本身。產品分析、標準遙測、工作階段層級追蹤、語意化片段、關聯鍵、隱私控制、高基數管理，以及失敗後的清理機制——這些都不是可有可無的裝飾，而是基礎設施。
Claude Code 主要觀察的是自身的執行環境。而企業級可視性的任務更為艱難：需要同時觀察多種類型的 Agent——白箱 Agent、框架型 Agent、封閉的內部 Agent，以及透過 MCP 連接的工具——同時確保資料保持可查詢、可關聯且受治理。
這正是 Toby AI Agents 可視性的發展方向：讓每一次互動、工具呼叫、模型呼叫、核准等待、封鎖狀態與工作階段關係，都清晰可見，讓團隊能夠除錯、審計與運營。