你的编程智能体账单翻倍了，却没人能告诉你原因。

实际原因在于：Claude Code、Cursor 和 Copilot 都以不同格式记录活动。只要你的团队使用了超过一种（他们肯定会用），你的可见性就会降为零。

我们构建 LangSmith 就是为了解决这个问题。它能将 Claude Code、Codex、Cursor、Copilot、Pi 和 OpenCode 的追踪数据统一为一致的格式。

• 相同的追踪树
• 相同的元数据
• 相同的查询语法 ……无论实际运行会话的是哪个工具。

你需要知道的一切：

你的编程智能体账单翻倍了。以下是修复方法。

来源：https://www.langchain.com/blog/fix-your-coding-agent-bill 上周，一家中型初创公司的工程负责人告诉我们，他的团队在两个月内编程智能体账单增长了 6 倍。不是因为工作量增加了 6 倍。而是因为没人盯着。

优步在 4 个月内就用光了 2026 年全年的人工智能预算。微软正在各团队取消 Claude Code 的授权。赛富时正面临一笔 3 亿美元的 Anthropic 账单。

“Tokenmaxxing”的后果

2026 年初，编程智能体的使用量激增，团队开始把花销当作进步来庆祝。消耗更多 token 一定意味着完成了更多工作、获得了更大杠杆、证明了人工智能投资正在产生回报。仅仅几个月后，我们就看到风向转变：账单爆炸，成本管理成为扩展人工智能工作负载的关键。

那么，如何找出哪里可以削减开支？一个功能可能涉及 Claude Code 进行初始实现、Cursor 进行内联编辑、以及 Copilot Chat 供团队成员审查。每个工具都以自己的格式记录活动。问一句“我们构建这个功能实际花了多少钱，值得吗？”大多数团队都答不上来。

这就是 tokenmaxxing 从阶段变成负债的时刻。你无法可靠地判断它是否物有所值，因为衡量标准分散在多个不互通的工具中。

实际问题是碎片化，而非数据不足

每个编码工具都会暴露一些成本可见性。Copilot 发出 OpenTelemetry span；OpenCode 有会话钩子；Pi 有扩展；Cursor 使用钩子。Claude Code 中的工具调用和 Cursor 中的工具调用记录方式不同，因此你无法将它们放在一起比较，问哪个工具更“花钱见效”。

这种碎片化在团队只使用一个工具时并不明显，但团队几乎马上就会扩展到多个工具。那么，如何获得团队实际使用的所有智能体的一致视图呢？

从可见性到控制

当我们开始与团队深入研究这个问题时，出现了一个模式：解决它不只是单一问题，而是循环的一部分。

1. 查看你的开销： 不再需要五个仪表盘、五种格式，你会希望获得一个团队实际使用的每个编程智能体的一致视图。LangSmith 现在将来自 Claude Code、Codex、Cursor、GitHub Copilot Chat、Pi 和 OpenCode 的会话追踪到同一个追踪模型中。无论哪个工具运行了会话，元数据相同、查询语法相同。你终于可以问“哪些会话开销高”，得到一个答案，而不是五个不完整的答案。

2. 跨工具标准化成本： 一旦能够并排查看会话，你就可以诚实地比较它们。跨工具标准化的 token 使用量、每次会话成本、工具调用和子智能体活动，让你终于能判断出在给定工作流中，Cursor 或 Claude Code 在花钱方面做得更多。

3. 优化你的使用： 看到数据才能进行优化，但大多数团队不会采取行动，因为没人有带宽手动审查每个会话中的浪费。这正是 Engine 发挥作用的地方：它分析智能体会话并给出具体的技能改进建议——就像一位高级工程师如果有时间审查智能体生成的每个 PR 会提出的那种改进。例如，如果智能体在会话中多次重复调用工具来获取相同的上下文，Engine 会标记出来并建议合并它们。不是用一个仪表盘告诉你开销高，而是给你一个具体要改什么的建议。

4. 管理你的支出： 我们的 LLM 网关成本上限在用户、团队和组织级别进行管控，并且很快能够将流量路由到合适的开源模型。开源模型已经变得又好又便宜，理应在每个智能体套件中成为一个选项——不是替代所有场景下的前沿模型，而是作为大多数不需要前沿智能的工作的默认选择。子智能体也是如此：廉价模型处理有范围限制的子任务，可以让智能模型避免在琐碎工作上消耗前沿级别的成本。

每个阶段都为下一阶段创造条件。可见性告诉你哪里需要优化，优化告诉你哪里需要最严格的治理，治理保护收益，以便下一轮可见性显示的是真正的进展而非新的浪费。

这个方案是为运行多个编程智能体的团队设计的——根据我们从客户那里听到的情况，大多数团队在采用后的几个月内就会进入这种状态。如果你的组织已经完全标准化在单一工具上，并且该工具的原生仪表盘已经能回答你的问题，那么你可能暂时不需要第二层。但一旦第二个工具加入，原生仪表盘就无法再回答“在所有工具中，钱都花到哪里去了”。

LangSmith for Coding Agents

你不必第一天就拥有全部四个组件。如果你的团队处于早期采用阶段，可观测性是合适的起点——你需要知道哪些智能体在运行、它们花了多少钱、哪些会话失败了，然后才能决定修复什么。如果你已经过了这个阶段，开始感受到账单压力，Engine 和 LLM 网关被设计成可以接入相同的追踪数据，因此从“我们能看见”到“我们能修复并设限”的转变不需要拆除任何现有组件。

配置完成后，编程智能体会话会像任何生产智能体运行一样，以追踪的形式出现在 LangSmith 中。根据集成方式的不同，一个会话可以包括：

• 用户和助手的交替轮次
• 包含 token 使用量和成本的模型调用
• 工具调用和 Shell 命令
• MCP 活动和子智能体调用
• 错误和时间信息

追踪被归一化为公共模型（根会话、轮次、工具调用、元数据），因此你可以使用相同的字段跨智能体进行查询。按 thread_id、模型、提供商或工具名称过滤。你可以找到开销高的会话、找出失败的工具调用、比较 Cursor 和 Copilot 的行为，而无需切换上下文。

开始使用

每个工具的设置方式不同：请找到对应步骤：

• Claude Code (https://docs.langchain.com/langsmith/trace-claude-code)
• Codex (https://docs.langchain.com/langsmith/trace-with-codex)
• OpenCode (https://docs.langchain.com/langsmith/trace-with-opencode)
• Cursor (https://github.com/langchain-ai/Cursor-LangSmith-Integration)
• GitHub Copilot (https://docs.langchain.com/langsmith/trace-with-vscode-copilot)
• Pi (https://docs.langchain.com/langsmith/trace-with-pi)
• dcode (https://docs.langchain.com/oss/python/deepagents/code/overview)

我们构建这个方案是因为我们自己也经历过这个问题：账单不断攀升，但我们不清楚哪些工作真正值得花钱。你的工程团队永远不会只用一个智能体（而且他们也不应该！），他们会根据任务选择最合适的工具。可观测性层必须适应他们的现状：不同的智能体、不同的事件格式，但都有一个地方来理解这一切。

LangSmith 为团队提供了一个位置，用于调试和衡量所有编程智能体的会话。找到你的工具并开始使用。(https://docs.langchain.com/langsmith/integrations#developer-tools)