Agent Trace（Agent 軌跡）

3 秒看懂

一句話定義： Agent Trace 是 AI Agent 在完成一次任務過程中，其思考鏈、工具呼叫、中間觀察、決策分支和最終輸出所構成的完整可回放執行記錄。

類比： 如果傳統軟體的呼叫棧（Call Stack）是一條直線，Agent Trace 就是一棵帶有分支、迴圈和外部互動的執行樹——記錄了 Agent 從”接到任務”到”交出結果”的每一步決策與行動。

關鍵詞： 可觀測性（Observability）、除錯（Debugging）、評估（Evaluation）、合規審計（Compliance）

3 分鐘產業解釋

為什麼 Agent Trace 突然重要？

2024–2025 年，AI 應用從”單輪問答”快速演化為”多步驟自主執行”的 Agent 範式。一個典型的 Agent 可能在一次任務中：

呼叫 3–15 個外部工具（搜尋、程式碼執行、API 請求……）
進行 2–10 輪 LLM 推論
涉及多個模型路由決策（主模型、輔助模型、回退模型）
累計消耗數千至數萬 token

當任務失敗或結果不符合預期時，“哪裡出了問題？” 成為核心痛點。沒有 Trace，開發者面對的是一個黑箱——不知道 Agent 在第 7 步呼叫了錯誤的工具，還是在第 3 步的推論中產生了幻覺。

Agent Trace 的產業價值在於：它是把 Agent 從”Demo 能跑”推向”生產可用”的關鍵基礎設施層。

與傳統 APM 的關係

傳統應用效能管理（APM，如 Datadog、New Relic）監控的是確定性呼叫鏈。Agent Trace 面對的挑戰遠大於此：

維度	傳統 APM	Agent Trace
呼叫路徑	確定性，固定路由	非確定性，動態決策
執行單元	微服務、函式呼叫	LLM 推論 + 工具呼叫 + 自反思
關鍵指標	延遲、錯誤率、吞吐	Token 成本、推論質量、工具成功率、路徑正確性
重放難度	低（確定性）	高（LLM 輸出非確定性）
審計需求	傳統合規	新興：AI 安全、模型對齊、責任追溯

15 分鐘專家深入

Agent Trace 的核心結構

一個完整的 Agent Trace 通常呈現為樹形結構（通過 Span 父子關係組織）；當需要表達跨子樹的關聯時，可藉助 Span Links 建置有向無環圖（DAG）關係。其節點可分為以下幾類：

Agent Trace (單次任務執行)
├── [Task Input] 使用者指令 / 任務描述
├── [Planning]   規劃步驟 (LLM 推論)
│   ├── Input tokens: ...
│   ├── Output tokens: ...
│   ├── Latency: ...
│   └── Model: ... (model name, provider)
├── [Tool Call #1]
│   ├── Tool name: "web_search"
│   ├── Input: {"query": "..."}
│   ├── Output: {...}
│   ├── Latency: ...
│   └── Status: success / error
├── [Observation] Agent 對工具返回結果的解讀 (LLM 推論)
├── [Decision Branch] 是否需要更多工具呼叫？
│   ├── → [Tool Call #2] ...
│   └── → [Self-Reflection] 自反思 / 修正 (LLM 推論)
├── [Aggregation] 彙總資訊 (LLM 推論)
└── [Final Output] 最終回答 / 動作

Trace 中每個節點的關鍵後設資料

每個 Trace 節點通常攜帶以下結構化資訊：

模型呼叫詳情： 選用的模型名稱/版本、輸入 Prompt（含 System Prompt）、輸出 Completion、Temperature 等引數
Token 計量： Input/Output/Total tokens，用於成本核算
延遲分解： 首 Token 時間（TTFT）、每 Token 生成時間（TPOT）、端到端延遲
工具互動記錄： 工具名稱、輸入引數、原始返回、錯誤碼（如有）
元推論資訊： 當前推論步驟的目標、對上一步結果的評估
使用者標識與會話 ID： 用於多輪會話追蹤和按使用者聚合分析

同步 Trace 與非同步 Trace

同步 Trace： Agent 按順序執行，Trace 是線性鏈（Chain），結構最簡單
非同步/並行 Trace： Agent 同時呼叫多個工具，或在規劃階段並行探索多條路徑，Trace 呈 DAG 或樹形。此時 Trace 系統需處理併發節點的時序對齊問題
多 Agent Trace： 多個 Agent 協作時，需要跨 Agent 的 Trace 關聯（通過統一的 Trace ID 或 Span ID 串聯），這是當前技術前沿的難點之一

Trace 與 Evals 的關係

Trace 不僅用於除錯，更是**自動化評估（Evals）**的資料基礎：

從 Trace 中可以提取”黃金路徑”（Ground Truth Trajectory）用於建置評估資料集
可以對 Trace 中每一步的推論質量進行打分（Step-level Evaluation）
可以統計工具呼叫成功率、路徑長度分佈、回退頻率等聚合指標
可以通過比較”好 Trace”與”壞 Trace”來發現系統性缺陷

技術原理（最深一層）

Agent Trace 的採集機制

Agent Trace 的技術實現通常分為三個層次：

1. Instrumentation（埋點/插樁）

┌──────────────────────────────────────────────────┐
│                Agent Execution Layer              │
│                                                  │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐   │
│  │ LLM Call │───▶│ Tool Call│───▶│ LLM Call │   │
│  │  (Span)  │    │  (Span)  │    │  (Span)  │   │
│  └────┬─────┘    └────┬─────┘    └────┬─────┘   │
│       │               │               │          │
│       ▼               ▼               ▼          │
│  ┌───────────────────────────────────────────┐   │
│  │          SDK / Auto-Instrumentation       │   │
│  │   (攔截模型呼叫、工具呼叫、自定義事件)      │   │
│  └───────────────────┬───────────────────────┘   │
└──────────────────────┼───────────────────────────┘
                       │ Export (OTLP / HTTP / gRPC)
                       ▼
              ┌─────────────────┐
              │  Collector /    │
              │  Trace Backend  │
              └─────────────────┘

主流埋點方式：

裝飾器/Context Manager 埋點： 在程式碼層面用 @trace 裝飾器包裹 LLM 呼叫和工具函式，手動但靈活
自動插樁（Auto-Instrumentation）： 通過 monkey-patch 或包裝層攔截對 OpenAI / Anthropic / LangChain 等 SDK 的呼叫，自動建立 Span
架構原生整合： 部分 Agent 架構（如 LangGraph、CrewAI、AutoGen）內建 Trace 匯出能力

2. 資料模型

Agent Trace 的資料模型通常借鑑 OpenTelemetry 的 Trace/Span 概念並加以擴充套件：

Trace (一次完整任務執行)
 └── Root Span (任務級別)
      ├── Child Span: Planning (LLM 推論)
      │    ├── Attributes: model, tokens_in, tokens_out, latency_ms
      │    └── Events: [thinking_step_1, thinking_step_2, ...]
      ├── Child Span: Tool Execution
      │    ├── Attributes: tool_name, input, output, status
      │    └── Links: [related_spans]
      ├── Child Span: Reflection (LLM 推論)
      │    └── Attributes: model, tokens_in, tokens_out, ...
      └── Child Span: Final Response Generation
           └── Attributes: model, tokens_in, tokens_out, ...

關鍵概念：

Trace ID： 全域性唯一標識，貫穿一次任務的全部執行步驟
Span ID： 每個執行步驟的唯一標識
Parent Span ID： 建立 Span 之間的父子關係，嚴格構成一棵樹（如需表達有向無環圖關係，可通過 Span Links 實現）
Attributes： 鍵值對形式的結構化後設資料
Events： 時間點標記（如”Agent 決定調用搜索工具”）
Status： OK / ERROR / UNSET

OpenTelemetry 相容性： 行業正在推動將 LLM/Agent Trace 納入 OpenTelemetry 標準。OpenTelemetry 社群已有關於 GenAI 語義約定的討論和草案，但截至 2025 年中，該規範尚未正式定稿為穩定版本，部分廠商已按草案實現 [標註：規範狀態以 OpenTelemetry 官方倉庫為準]。

3. 儲存與查詢

Trace 資料的特點是：單條資料量中等（一次任務 Trace 可達數十 KB 到數百 KB），但查詢模式多樣（按時間、按使用者、按模型、按工具、按結果質量過濾）。

常見儲存方案：

列式儲存 / OLAP 資料庫： 適合聚合統計（如”過去 24 小時工具 X 的平均延遲”）
文件資料庫： 適合 Trace 原始結構的儲存和完整回放
時序資料庫： 適合延遲趨勢監控
實際生產中，多數廠商採用混合儲存方案

Trace 視覺化與除錯

典型的 Agent Trace 視覺化包括：

時間線檢視（Waterfall）： 類似瀏覽器 DevTools 的瀑布圖，橫軸為時間，縱軸為 Span 層級，直觀展示各步驟耗時和併發關係
樹形檢視： 以樹形展示 Span 父子關係，可展開每個節點檢視後設資料
表格檢視： 多條 Trace 的列表，支援按維度過濾和排序
對比檢視： 兩條 Trace 並排對比，高亮差非同步驟

技術演進史

時間	里程碑	意義
2022 及之前	LLM 應用以單輪問答為主	無需 Trace；簡單的日誌記錄即可
2022.11–2023	ChatGPT 引爆 LLM 應用；LangChain 快速崛起	Chain 模式開始普及，`langchain.debug` / `langchain.verbose` 提供最基礎的呼叫鏈列印
2023 H1	LangSmith 推出（LangChain 團隊）	首個聚焦 LLM 應用可觀測性的商業平台；支援 Trace 記錄、資料集標註、評估
2023 H1–H2	Arize 推出 Phoenix（開源）；Helicone 上線	開源與商業方案並行發展；Trace 概念從”日誌”向”可觀測性平台”進化
2023 H2	Langfuse 開源釋出	開源 Agent Trace 領域的重要參與者；強調自託管和隱私
2024	Agent 架構百花齊放（LangGraph、CrewAI、AutoGen 等）	Trace 需求從”Chain”升級到”Graph/Tree”；多 Agent Trace 成為新挑戰
2024 H1	OpenTelemetry GenAI 語義約定草案討論啟動	行業開始尋求 Trace 資料的標準化和互操作性
2025 H1	頭部廠商平台化；Trace + Evals + Prompt 管理融合	可觀測性從單一 Trace 儲存演化為涵蓋開發全生命週期的 MLOps 平台

技術路線對比

維度	自建 Trace 系統	開源方案（Langfuse / Phoenix 等）	商業 SaaS（LangSmith / Braintrust / Helicone 等）
資料主權	完全自控	自託管，資料不出域	資料託管在供應商側（部分支援私有化部署）
上線速度	慢（需自研採集、儲存、UI）	中等（部署+整合 SDK）	快（註冊即用）
功能深度	取決於投入	Trace 記錄+基礎評估+基礎視覺化	通常更豐富：高階評估、Prompt Hub、A/B 測試、迴歸檢測
多 Agent 支援	需自行設計	部分支援，能力在演進中	部分支援，能力在演進中
成本	研發人力為主	基礎設施成本（儲存/計算）	SaaS 訂閱費，可能隨 Trace 量線性增長
適用場景	超大規模部署、極致合規需求	成本敏感、需定製、資料敏感	快速迭代、團隊規模中小、希望聚焦業務

[注：各方案功能以 2025 年中各產品官方文件為準，具體能力請查閱最新版本。]

上下游

上游依賴

┌─────────────────────────────────────────────┐
│                 上游技術棧                    │
├─────────────────────────────────────────────┤
│ LLM Provider API     (OpenAI / Anthropic /   │
│                       Google / 本地部署模型)   │
│ Agent Framework       (LangGraph / CrewAI /   │
│                       AutoGen / 自研架構)      │
│ 工具生態              (搜尋 / 程式碼執行 / DB /  │
│                       API 整合)               │
│ 基礎設施              (K8s / 向量資料庫 /      │
│                       訊息佇列)               │
└─────────────────────────────────────────────┘

下游應用

┌─────────────────────────────────────────────┐
│                 下游價值層                    │
├─────────────────────────────────────────────┤
│ 除錯與開發     定位失敗步驟、最佳化 Prompt       │
│ 評估與迴歸     自動化質量評估、版本間迴歸測試   │
│ 成本分析       按使用者/任務/模型聚合 token 成本  │
│ 安全與合規     行為審計、內容稽核、責任追溯     │
│ 產品洞察       使用者行為分析、Agent 效率最佳化     │
└─────────────────────────────────────────────┘

關鍵指標

指標	含義	為何重要
Trace 完整率	被成功採集的 Agent 執行佔總執行的比例	低於閾值時除錯將出現盲區
採集開銷（Overhead）	Trace 埋點引入的額外延遲佔總延遲比例	Agent 任務本身延遲較高（秒級~分鐘級），通常可接受 [定性]
Span 數量 / Trace	單次任務 Trace 中的 Span 節點數	反映任務複雜度；過多 Span 可能意味著效率低下
工具呼叫成功率	Trace 中工具呼叫返回成功狀態的比例	工具失敗是 Agent 失敗的主要原因之一 [定性]
平均推論輪次	一次任務中 LLM 被呼叫的平均次數	輪次越多，成本越高，延遲越大
Token 消耗 / Trace	單次任務的總 token 使用量	直接關聯成本
端到端延遲 P50/P95/P99	任務完成時間的分佈	使用者體驗和 SLA 的核心指標
回退/重試頻率	Agent 在執行中觸發回退策略或重試的頻率	高頻率可能反映工具不穩定或規劃質量低

供需與市場資料

需求側驅動力

Agent 應用規模化： 隨著 Agent 從實驗走向生產，可觀測性從”nice to have”變為”must have”
監管與合規壓力： EU AI Act 等法規要求 AI 系統具備可解釋性和可追溯性（具體條款以正式法律文本為準）
成本控制需求： LLM 呼叫成本在 Agent 場景下可能快速膨脹，Trace 是成本歸因的基礎

供給側格局

商業 SaaS： LangSmith（LangChain 生態）、Braintrust、Helicone、Weights & Biases Weave、Arize 等
開源： Langfuse（MIT 許可）、Arize Phoenix 等
雲端廠商內建能力： 主要雲端廠商（AWS、Azure、GCP）在各自的 AI 平台中逐步整合 Trace 能力 [具體功能以各廠商官方文件為準]
傳統 APM 廠商擴充套件： Datadog、New Relic、Dynatrace 等傳統可觀測性廠商已開始提供 LLM Monitoring 功能 [具體功能以各廠商官方文件為準]

市場規模

Agent Trace / LLM Observability 作為 LLM 應用基礎設施的子賽道，尚處於早期階段，無權威第三方機構釋出獨立市場規模預測。可參考的是更大的 LLM 工具鏈/MLOps 市場，但具體數字各報告口徑差異較大 [標註：未充分揭露]。

代表公司與資本對映

公司/專案	定位	融資/狀態	與 Agent Trace 的關係
LangChain (LangSmith)	Agent 架構 + 可觀測性平台	Series A（具體金額以公開資訊為準）	LangSmith 是其商業可觀測性產品，與 LangGraph 深度整合
Langfuse	開源 LLM 可觀測性	開源專案，已獲種子輪融資 [以官方公告為準]	核心產品即 Agent Trace 平台，支援自託管
Arize AI	ML/AI 可觀測性平台	已融資 [以 Crunchbase 等公開資訊為準]	Phoenix（開源）+ 商業平台覆蓋 LLM/Agent Trace
Braintrust	AI 評估+可觀測性	已融資 [以公開資訊為準]	將 Trace 與評估、Prompt 管理深度整合
Helicone	LLM 可觀測性（代理模式）	已融資 [以公開資訊為準]	通過 API 代理方式零侵入採集 Trace
Weights & Biases	MLOps 平台	已融資至 C 輪 [以公開資訊為準]	Weave 產品線覆蓋 LLM/Agent Trace
傳統 APM（Datadog、New Relic 等）	通用可觀測性	上市公司	LLM Monitoring 擴充套件功能

[注：融資資訊以各公司官方公告或 Crunchbase/PitchBook 等公開資料來源為準，此處不編造具體金額。]

投資邏輯

核心論點

“賣水人”邏輯： Agent 應用層競爭激烈（誰贏不確定），但無論誰贏都需要 Trace 基礎設施。Agent Trace 之於 Agent 應用，類似於 APM 之於 Web 應用——是不可或缺的基礎設施層。
平台粘性： Trace 資料是 Agent 開發的”記憶”，積累越久遷移成本越高，具備天然的鎖定效應。
向上擴充套件潛力： 從 Trace（觀測）→ Eval（評估）→ Prompt 管理（最佳化）→ 資料集建置（訓練/微調反饋），一條完整的 Agent 開發平台價值鏈正在形成。

風險點

被平台吞噬： Agent 架構（如 LangChain、CrewAI）和雲端廠商可能將 Trace 作為內建功能免費提供，獨立 Trace 廠商的生存空間可能被壓縮
標準化導致商品化： 如果 OpenTelemetry GenAI 規範成熟，Trace 採集層可能變成標準化商品，差異化移向儲存/分析/評估層
市場時機： Agent 應用規模化尚在進行中，Trace 需求的爆發時點存在不確定性
估值與商業化驗證： 該賽道多數公司尚處早期，商業模式和單位經濟性待驗證

常見誤讀糾偏

誤讀 1：Agent Trace ≈ LLM 呼叫日誌

糾偏： LLM 呼叫日誌只是 Agent Trace 的一個子集。完整的 Agent Trace 還包含工具呼叫記錄、多步推論鏈的拓撲關係、決策分支、使用者反饋、時間線資訊等。一個複雜的 Agent Trace 可能包含十數個 Span，涉及多種型別的互動，遠非簡單的請求-響應日誌可以覆蓋。

誤讀 2：有了 Trace 就能自動評估 Agent 質量

糾偏： Trace 提供的是原始執行資料，而非評估結論。從 Trace 到評估還需要：① 定義評估維度（準確性、效率、安全性……）；② 建置評估方法（規則匹配、LLM-as-Judge、人工標註……）；③ 建立基準線（Ground Truth）。Trace 是評估的必要條件，但非充分條件。

誤讀 3：Trace 採集會嚴重影響 Agent 響應速度

糾偏： Agent 任務的端到端延遲通常在秒級到分鐘級（主要由 LLM 推論和工具呼叫決定）。Trace 採集（記錄後設資料並非同步匯出）引入的開銷通常是毫秒級，佔總延遲比例極低 [定性判斷]。但需注意：如果 Trace 採集涉及同步網路寫入或大量資料序列化，在高併發場景下仍需關注其影響。

誤讀 4：所有 Agent 都需要生產級 Trace

糾偏： 對於簡單的單步工具呼叫 Agent（如”查天氣→回答”），Trace 的價值有限。Trace 的價值在任務複雜度高、決策路徑長、涉及多個工具和多次 LLM 推論的場景下最為顯著——這恰恰是當前 Agent 落地最受關注的場景。

學習路徑

Level 0  概念理解
  │  ├── 讀完本頁，理解 Agent Trace 的定義和價值
  │  └── 使用一個簡單 Agent（如 LangChain ReAct Agent），
  │      開啟 verbose/debug 模式，觀察輸出
  ▼
Level 1  動手體驗
  │  ├── 部署 Langfuse 或 Arize Phoenix（開源版）
  │  ├── 用 SDK 對一個簡單 Agent 進行插樁
  │  ├── 在 UI 中檢視 Trace 時間線和詳情
  │  └── 思考：哪些 Span 耗時最長？哪個工具呼叫失敗了？
  ▼
Level 2  評估整合
  │  ├── 基於 Trace 資料設計自動化評估流程
  │  ├── 實現 LLM-as-Judge 或基於規則的 Trace 質量打分
  │  └── 建置 Trace 迴歸測試（新版本 vs 舊版本的 Trace 對比）
  ▼
Level 3  生產化
  │  ├── 設計高併發下的 Trace 採集架構（非同步匯出、取樣策略）
  │  ├── 實現跨多 Agent 的 Trace 關聯
  │  ├── 整合成本分析和告警
  │  └── 研究 OpenTelemetry GenAI 語義約定並跟進標準化進展
  ▼
Level 4  前沿研究
     ├── Trace 資料用於強化學習反饋（RLHF/RL from Trajectories）
     ├── Trace-driven Prompt 最佳化（自動從失敗 Trace 中提取改進策略）
     └── 多 Agent 協作場景下的分散式 Trace 拓撲設計

一句話總結

Agent Trace 是將 AI Agent 的”黑箱行為”轉化為”可觀察、可除錯、可評估、可審計”的結構化執行記錄，是 Agent 從實驗室走向生產環境的不可或缺的基礎設施層。

延伸閱讀與來源

資源	說明
Langfuse 官方文件	開源 Trace 平台，文件質量高，可作為技術實現參考
LangSmith 官方文件	LangChain 生態的商業 Trace/評估平台
Arize Phoenix GitHub	開源 LLM 可觀測性工具，含 Trace 和評估功能
OpenTelemetry GenAI 語義約定草案	關注 OpenTelemetry 官方 GitHub 倉庫中的 `semantic-conventions` 倉庫，追蹤 GenAI 相關規範進展
LangChain / LangGraph 原始碼	理解 Agent 架構如何內建 Trace 能力
Anthropic / OpenAI API 文件	理解 LLM API 層面返回的後設資料（usage、model 等）

[注：本文所有技術描述基於公開的架構設計理念、開源專案文件和行業通用實踐。因檢索未獲取到外部資料，未標註具體來源的定量資料均為定性表述或估算，不構成精確技術規格。]