你的編程代理賬單翻倍了。以下是如何解決。

上週，一家中型初創公司的工程負責人告訴我們，他的團隊在短短兩個季度內，編程代理的賬單增長了6倍。工作難度並沒有增加6倍，只是因為沒有人監控。Uber在4個月內用完了整個2026年的AI預算；微軟正在跨部門取消Claude Code許可證；Salesforce面臨着高達3億美元的Anthropic賬單。

2026年初，編程代理使用量爆發式增長，團隊開始將支出視為進展的標誌。消耗更多token意味着完成更多工作、獲得更多槓桿，證明AI投資的回報。但僅僅幾個月後，隨着賬單飆升，成本管理成為擴展AI工作負載的關鍵。

那麼，如何確定削減開支的地方呢？一個單一功能可能涉及Claude Code進行初始實現、Cursor進行內聯編輯、Copilot Chat進行隊友評審，而每個工具都以自己的格式記錄活動。當被問及“構建這個功能實際花了多少錢，是否值得”時，大多數團隊無法回答。這就是“tokenmaxxing”從階段變成負債的時刻。你無法可靠地判斷其價值，因為衡量單位分散在互不相通的工具中。

實際問題是碎片化，而非數據缺失。每個編碼工具都提供一些成本可見性：Copilot發出OpenTelemetry跨度，OpenCode有會話鈎子，Pi有擴展，Cursor使用鈎子。但Claude Code中的工具調用和Cursor中的工具調用記錄方式不同，你無法將它們並列比較，以確定哪個工具在相同成本下做得更多。

從可視化到控制：當我們與團隊深入探討時，發現了一個模式：解決方案不是單一問題，而是一個循環的一部分。首先，可視化支出：你希望有一個統一的視圖，涵蓋團隊實際使用的所有編程代理。LangSmith現在將來自Claude Code、Codex、Cursor、GitHub Copilot Chat、Pi和OpenCode的會話追蹤到相同的追蹤模型中。相同的元數據、相同的查詢語法，無論哪個工具運行了會話。你終於可以問“哪些會話成本高昂？”並得到一個統一的答案，而不是五個不完整的答案。

其次，標準化跨工具成本：一旦你能並列比較會話，就可以誠實比較。Token使用量、每次會話成本、工具調用次數和子代理活動被跨工具歸一化，你終於可以知道在特定工作流中，Cursor或Claude Code在相同成本下做了多少工作。

第三，優化使用：看到數據使優化成為可能，但大多數團隊並未採取行動，因為無人有精力手動審查每個會話以發現浪費。這就是Engine的作用：它分析代理會話並展示具體的技能改進建議——一位資深工程師如果有時間審查代理生成的每個PR，也會提出類似的改進。例如，如果代理在會話中多次重複調用工具以檢索相同上下文，Engine會標記並建議合併它們。而不是一個只告訴你支出高的儀表板，你得到具體的改進建議。

第四，治理支出：我們的LLM Gateway在用户、團隊和組織層面實施成本上限和管控，並很快能夠將流量路由到適合的開源模型。開源模型已經足夠好且便宜，應作為每個代理工具包中的選項——不是取代前沿模型，而是作為大多數不需要前沿智能工作的默認選擇。子代理也是如此：便宜的模型處理範圍明確的子任務，可以防止智能模型在繁重工作上消耗前沿級別的成本。

每個階段都為下一階段提供可能。可視化告訴你在哪裏優化，優化告訴你在哪裏需要最嚴格的治理，治理保護了收益，以便下一輪可視化顯示真正進展而非新浪費。

這一解決方案是為運行多個編程代理的團隊設計的——根據我們從客户那裏聽到的信息，大多數團隊在採用後的幾個月內就會使用多個工具。如果你的組織完全標準化了一個工具，並且該工具的原生儀表板已經回答了你的問題，你可能還不需要第二層。但一旦第二個工具加入，原生儀表板就無法回答“在所有工具中，錢流向了哪裏？”

LangSmith for Coding Agents：你不需要第一天就擁有所有四個部分。如果你的團隊處於早期採用階段，可觀察性是開始的好地方——你需要知道哪些代理在運行、花費多少、會話在何處失敗，然後才能決定修復什麼。如果你已經過了那個階段並開始感到賬單壓力，Engine和LLM Gateway可以插入相同的追蹤數據，因此從“我們能看到”到“我們能修復並限制”不需要拆除任何現有架構。

配置後，編程代理會話作為追蹤出現在LangSmith中，就像任何生產代理運行一樣。根據集成，會話可以包括用户和助手輪次、帶token使用量和成本的模型調用、工具調用和shell命令、MCP活動和子代理調用、錯誤和計時。追蹤被歸一化為通用模型（根會話、輪次、工具調用、元數據），因此你可以使用相同字段跨代理查詢。按session_id、thread_id、model、provider或工具名稱過濾。你可以找到成本高昂的會話、失敗的工具調用，並比較Cursor和Copilot的行為，而無需切換上下文。

開始使用：每個工具的設置不同，找到Claude Code、Codex、OpenCode、Cursor、GitHub Copilot、Pi或dcode的步驟。我們構建這個是因為我們親身經歷了這個問題：賬單不斷攀升，我們不清楚哪些工作真正值得支出。你的工程團隊永遠不會標準化到一個代理上（而且他們也不應該！），因為他們會繼續選擇最適合任務的工具。可觀察性必須滿足他們的現狀：不同的代理、不同的事件格式，但有一個地方可以理解所有這一切。LangSmith為團隊提供了一個調試和測量所有編碼代理會話的統一場所。找到你的工具並開始吧。