計量表一直在執行

首個昂貴的智慧體執行並不像治理問題，而更像賬單問題。團隊在計量表開啟後收到第一張智慧體發票，按成本排序後，發現某個執行的成本是中位數的40倍。提供商計量表顯示令牌和總額，應用日誌顯示請求成功，追蹤檢視器顯示簡潔的請求與響應。沒有任何一項能解釋為什麼這個執行耗時漫長而其他執行乾淨利落。

在我之前的文章《補貼結束：使用工具的智慧體實際成本》中，我論證了基於用量的計費並未讓智慧體變得昂貴，而是讓既有成本變得可見。賬單並未變大，只是變誠實了，而誠實的賬單是你可以針對其進行工程最佳化的。

但可見不等於可歸因。要歸因使用工具的智慧體的成本，你必須看穿產生成本的執行內部。一旦建立這種可見性，你就會發現成本只是問題首次變得可見的地方。成本激增、不安全委託和失控動作是不同的失敗，但它們暴露了同一個缺失的層：控制平面無法治理它無法獨立觀察的迴圈。

賬單是誠實的，但未加解釋。發票上的數字沒錯，只是不完整。提供商計費可以告訴你消耗了什麼，但通常無法告訴你平臺內的哪個設計選擇導致了消耗。應用日誌可以告訴你外部請求是否成功，但往往無法告訴你智慧體是如何到達那裡的。這讓團隊對著賬單爭論不休，而他們真正需要的是審計追蹤。

所謂控制平面，是指單個智慧體之上的平臺層，組織在此集中觀測並實施策略、訪問、預算、路由和執行約束。多陣列織已擁有該層的部分元件。但它們常常缺失的是其下的證據層：記錄智慧體實際做了什麼、逐輪遞進的迴圈感知記錄。

控制平面是策略決策所在。觀測基座是控制平面讀取的證據。檢測點是智慧體無法繞過的執行時關卡：模型閘道器、工具代理、API閘道器、執行沙箱、執行時框架和策略引擎。

許多組織檢測了應用邊界，隨後部署了實際工作在迴圈內完成的系統。結果是控制平面有觀點但證據不足。

迴圈是觀察的單位。以下是空追蹤背後的錯誤：智慧體可觀測性常被當作應用可觀測性的加重版，但它的形狀完全不同。工作單位改變了，而檢測沒有。傳統服務處理請求並返回響應；請求是自然追蹤單位。智慧體並非處理請求，而是朝著結果工作。它推理、呼叫工具、讀取結果、再次推理，直到決定完成、觸及邊界或升級。單一使用者意圖可能扇出多個模型呼叫、多個工具呼叫，以及每輪變化的上下文視窗。重要的訊號是這些輪次之間的關係，而非任何一輪的時序。

由此得出三件事，每件都打破了應用監控默默依賴的假設。第一，上下文是累積狀態，而非固定載荷。每輪可能攜帶先前的訊息、工具描述、檢索檔案、中間結果和早期決策。你必須能夠逐輪觀察狀態增長，因為增長正是成本和風險所在。第二，工具呼叫是一級決策，而非實現細節。模型選擇了哪個工具、傳入了什麼引數、結果多大、策略是否約束了呼叫，都是治理記錄的一部分。路由準確性和路由成本是從兩個方向審視的同一審計。第三，每個執行都可能成為自己的追蹤樹。相同的提示週二可能走與週一不同的路徑，因此固定的呼叫圖和乾淨的服務對映假設了智慧體可能不具備的規律性。如果觀察單位仍是請求，你會看到10,000次成功呼叫，卻從未注意到那一次本應三輪卻跑了十五輪的迴圈。

一旦你接受迴圈是單位，需求就變得具體。你需要智慧體下方捕獲的少量特定訊號，並儲存於可跨整個艦隊查詢的位置，而不僅僅是每執行檢視器內。在我為某大型醫療機構執行的試點中，我們首先建立了這一層，基於OpenTelemetry、Cloud Trace和資料倉儲中的用量日誌表。具體技術棧不如形狀重要，其可推廣性遠超該場景。

每個使用者意圖至少應產生一個執行追蹤。每個迴圈輪次應表示為跨度或穩定分組屬性。模型呼叫、工具執行、策略檢查、重試和後處理應作為該輪下的子跨度或結構化事件。確切的命名約定不如保留迴圈的因果結構重要。

訊號 控制平面為何需要它 示例欄位 執行和輪次結構讓執行作為因果樹而非扁平呼叫列表可讀 run_id, turn_id, parent_span_id, timestamp 令牌和模型核算使成本可逐輪、逐模型、逐工具路徑解釋，而非僅僅在聚合中可見 model, input_tokens, output_tokens, cached_tokens 工具呼叫事件記錄委託決策，識別過大或重複的工具結果 tool_name, parameter_shape, result_bytes, row_count 護欄決策事件顯示哪些控制觸發，是允許、拒絕、重寫、約束還是升級了動作 policy_id, policy_decision, reason_code, enforcement_point 身份和許可權上下文重建工作執行於誰許可權下、當時適用哪個資料範圍 principal_id, delegated_scope, service_account, data_scope 結果和邊界後設資料區分乾淨完成與重試、邊界命中、升級和使用者可見失敗 turn_count, stop_reason, loop_bound_hit, payload_cap_hit, outcome_status 這些都不稀奇，實際設計工作不是發明新的遙測原語，而是管理基數、保留、載荷捕獲、取樣策略、模式演化，以及追蹤資料、用量資料、身份資料和策略資料之間的連線。

儲存點是團隊低估的部分。如果這些訊號僅落入追蹤檢視器，你可以精美地檢查一個執行，卻永遠無法推理一千個。治理是艦隊問題，而非單次追蹤問題，因此基座必須可查詢。

它還必須以資料最小化為設計原則：預設捕獲後設資料，例外捕獲內容。記錄工具呼叫不意味著儲存每個原始提示、完整結果集、憑據、機密文件或敏感引數於追蹤中。在監管環境中，有用的模式是將後設資料與載荷分離：工具名稱、模型、令牌計數、載荷大小、行數、策略決策、許可權上下文、請求ID，以及必要時遮蔽或雜湊的引數值。目標是足夠重建執行行為的證據，而非智慧體所見一切的失控存檔。

第一個有用版本不需要完整提示捕獲或語義評估。有了run_id、turn_id、parent_span_id、timestamp、principal_id、delegated_scope、model、input_tokens、output_tokens、cached_tokens、tool_name、result_bytes、row_count、policy_id、policy_decision、stop_reason、loop_bound_hit和outcome_status這些列，昂貴的迴圈不再是謎題，而是查詢。

確切的語法因倉庫而異，但治理問題應能不透過人工點選單個追蹤檢視器而表達：

with runs as ( select run_id, count(distinct turn_id) as turns, sum(input_tokens + output_tokens) as total_tokens, max(result_bytes) as largest_tool_result, bool_or(loop_bound_hit) as hit_loop_bound, count_if(policy_decision = 'rewrite') as rewritten_actions from agent_turn_events where occurred_at >= current_date - interval '7 days' group by run_id ) select * from runs where turns > 10 or largest_tool_result > 10000000 or hit_loop_bound or rewritten_actions > 0;

這就是欣賞一個追蹤與治理一個艦隊的區別。

在舊追蹤中，開篇的昂貴執行僅僅是昂貴。在迴圈感知追蹤中，它變得可讀：第3輪檢索了80,000行，第4輪攜帶該結果前進，第5輪選擇了昂貴模型，第6至11輪以略微不同的引數重試同一工具呼叫，執行最終因觸及迴圈邊界而非乾淨完成而停止。執行不再是謎題，而成為記錄。

一個基座，三個治理問題。值得一次正確構建的原因在於，同一基座回答了行業常分開處理的三個智慧體治理問題：成本管理、委託與訪問控制、失控行為預防。它們並非相同的失敗，但需要同類的證據。

治理問題 控制平面需要的證據 成本 輪次數、令牌數、模型選擇、上下文增長、工具結果大小、重試和停止原因 委託 主體、委託許可權、資料範圍、所選工具、動作引數和策略決策 失控行為 重複動作、迴圈邊界、載荷上限、護欄決策、被拒絕或重寫的動作以及結果狀態 成本是第一個問題，透過每輪的令牌核算，你終於能回答執行為何昂貴。你可以看到成本是來自過多的輪次、攜帶的上下文過多、工具結果過大、在錯誤步驟使用了昂貴模型，還是應該被限制的重試迴圈。

委託與訪問是第二個且更棘手的問題。在多智慧體系統中，委託是安全邊界。企業最終會被問及誰授權了某個智慧體動作、它在誰的許可權下執行、當時適用哪個資料範圍。這個問題的審計追蹤正是同一追蹤，增加了每輪的身份和許可權資訊。

失控行為是第三個問題。破壞性刪除成為傳說的故事、試圖刪除生產表的智慧體、重複發出同樣昂貴掃描的迴圈，不應只存在於事後分析中。在此模型下，被阻止的破壞性語句是一個護欄決策事件，帶有拒絕標籤；失控掃描則是一個觸及迴圈邊界或載荷上限的追蹤。有趣的治理訊號是確定性控制所拒絕的危險動作。

三個對話，一個立足點。迴圈是治理的單位，因為迴圈是成本累積、許可權行使、工具選擇、控制觸發和結果顯現的地方。

智慧體不能自己保管記錄。有一個誘人的捷徑：讓智慧體自己記錄令牌、許可權和被阻止的動作。但那是不安全的，因為智慧體可能在被破壞時篡改記錄。更根本的是，如果治理依賴智慧體自身的日誌，那麼你正在用無法獨立驗證的元件進行審計。控制平面必須從智慧體無法干預的層級讀取證據，這就是為什麼檢測點必須是執行時關卡。

智慧體可以對其內部狀態提供有用的訊號，但治理層永遠不應依賴智慧體作為其記錄的最終仲裁者。將記錄委託給被治理的實體是混淆控制平面和監督物件。