你的编程代理账单翻倍了。以下是如何解决。

上周，一家中型初创公司的工程负责人告诉我们，他的团队在短短两个季度内，编程代理的账单增长了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为团队提供了一个调试和测量所有编码代理会话的统一场所。找到你的工具并开始吧。