封面：在 Microsoft Foundry 中衡量 MCP 工具调用的 Token 影响

我第一次盯着一个启用了 MCP 的智能体的 token 账单时，脑子是懵的。API 告诉我这次跑了 773 个 token。可门户里的 trace 显示的是 581/141。切到 trajectory 视图，数字又变成了另一个样子。三个地方，三套数据，哪个才是对的？

在你急着去提 bug 之前，我想先说清楚这背后到底发生了什么，以及怎么建立一套站得住脚的证据方法，让企业级的 token 核算不再靠猜。

我自己走完这一遍之后，拿到手的东西是：一个可复现的 A/B 对比方法、几张能直接用的证据模板，还有一套对账思路，能实实在在减少 FinOps 的反复扯皮。

几个术语先对齐一下

  • MCP（Model Context Protocol）：一套把 AI 模型连接到外部工具和数据源的标准协议。
  • Token：AI 模型处理文本和计费的基本单位，大致相当于 4 个字符，或者说四分之三个英文单词。
  • Trajectory 视图：Microsoft Foundry 里把智能体执行路径一步步画出来的可视化。
  • Token chips：Foundry trace 界面里那些内联显示的 token 计数小标签。
  • devtunnel：微软的一个工具，用来把本地服务临时暴露到公网上做测试。

问题出在哪

很多人有个下意识的假设：Execute Tool 这个 span 应该直接告诉我这次工具调用被计费的 token 增量。听起来很合理，但在 Microsoft Foundry 的 trace 里，遥测数据通常不是这么解读的。

我见过的几种典型翻车方式：

  • 把工具 span 当成计费边界来看。
  • 拿两次不同运行的数字直接对比，好像它们是同一笔交易。
  • 把线程里的 token chips、trace 表格里的 token 列、API 返回的 usage 字段混在一起看，中间不做任何对账。

举个具体的场景：一次启用了 MCP 的运行，API usage 里显示有工具活动，总 token 数很大；门户 trace 的截图里，Tokens In/Out 又是另一组数字。审查的人一看两边对不上，就下结论说系统不一致。可实际上，那两组数据压根来自不同的 response ID 和不同的运行上下文。

我是怎么做验证的

这次验证我用的是 Foundry 里的一个 prompt agent，配了一个内联的 MCP 工具，去调用一个天气 MCP 服务器。

核心组件是这几个：

  • Foundry prompt agent：weather-mcp-token-test-agent
  • MCP 服务器：通过 devtunnel 暴露的远程端点
  • 证据来源有三处：API 调用的 usage 对象（input、output、total tokens）、Foundry Traces 表格（Tokens In、Tokens Out），以及 trajectory 视图里的 Execute Tool 和 Chat span

智能体的 MCP 工具配置

跑下来我观察到的架构行为是这样的：

  • MCP 的调用能通过 mcp_list_tools 和 execute_tool 这两个 span 看到。
  • token 的计数出现在模型响应的元数据里，具体就是那个 usage 对象，它报告 input tokens（你发过去的）和 output tokens（模型生成的）。
  • 工具的输出会进入后续模型的上下文，于是整个回合的 token 用量被抬高。

带 token 列的 Traces 表格

Traces 的 trajectory 对话框

我的解决思路

关键是把两条对比路径明明白白地分开，不要搅在一起：

  • 路径 A：在同一个 prompt 上做严格的 API A/B 对比。
  • 路径 B：用门户 trace 作为调用行为和 trace 级 token 列的证据。

具体操作上，我用同一个 prompt 分别跑了启用 MCP 和不带工具的基线两个智能体，然后把两次的 API usage 值都记下来：

  • 启用 MCP：input 581，output 192，total 773
  • 基线（无工具）：input 57，output 57，total 114
  • 增量：总共多出 659 个 token

接着我把 trace 表格和 trajectory 视图的门户截图都抓下来，把每一行的 token 值当作各自独立的运行证据记录，而不是硬凑成一行。比如我观察到的门户行是这样的：581/141、581/141、868/97。

然后在报告里我会专门加一句对账说明：API 的 A/B 总数和门户 trace 的各行，可能对应的是不同的 response ID。它们是互补的证据，不该被强行对成一模一样的某一行。

关于 token 波动，有一点我想特别提醒：跨运行时，绝对 token 数是会变的，系统指令的差异、工具载荷的长度、模型行为、响应的格式，都会影响它。所以做 A/B 对比的时候，一定要保持同样的 prompt 和同样的基线条件。

我自己定下来的几个判断原则：

  • 把 API usage 当作增量的主证据。
  • 把 traces 和 trajectory 当作工具确实被调用、运行确实发生的操作证据。
  • 尽可能用 response ID 把证据串起来。

我踩过之后总结的几条经验

  • token 的证据来源永远要分开看：API usage 字段用于严格的单次响应核算，门户 trace 表格用于运行的可观测性，trajectory span 用于理解调用的语义。
  • 不要在没有标注"这是不同运行"的前提下，去比较不同 response ID 之间的 token 行。
  • 把 Execute Tool span 当作调用发生的证据，而不是独立的计费真相。
  • 基线和启用 MCP 的两次运行，一定要用完全相同的 prompt，这样算出来的增量才经得起推敲。
  • 截图和 ID 要放在同一个证据包里一起保存。
  • 只要报告里混用了多种证据来源，就加一段对账说明。
  • 对企业报告来说，清晰的 A/B 表格比纯文字叙述更有说服力。

写在最后

MCP 工具调用确实会实打实地推高一个回合的 token 用量，但这个增量得用有纪律的证据处理方式去测量。在我这次验证里，同一个 prompt 下启用 MCP 工具后，API 的 A/B 对比显示总 token 增加了 659 个。这个数字本身不神秘，关键是你怎么把它讲清楚、让别人信。

如果要往下走，我给不同角色的建议是这样的：

工程师可以在 Foundry 里建一个 prompt agent，拿自己某个生产环境的 prompt 跑一遍这套 A/B 方法，把 response ID 连同 token 证据一起记录下来。平台或 FinOps 的负责人，值得把一套 token 证据报告模板标准化，把 API usage 证据和门户 trace 证据分开，再接到现有的 Azure 成本分析流程里。至于写发布文章的人，直接套用这套证据模式就行：一张 trace 截图、一张 A/B token 表格、一段对账说明，能省掉不少来回审查的时间。