一个周二下午，我的AI Agent信誓旦旦地告诉我：/users接口响应时间是47秒。真实数值是47毫秒。

我已经跟这个Bug死磕了两天。加了MCP服务器日志，逐token检查模型回复，修改系统提示词，对比各种假设。没有一处明显指向问题根源。

打开网易新闻 查看精彩图片

唯一没做的事：打开实际执行轨迹，查看模型和工具之间的精确交互。

Apidog的AI Agent调试器让我省下了大量时间。12分钟后，Bug定位完成。

配置其实很简单：基于gpt-5.5的Agent，一个快速搭建的MCP服务器，暴露了一个工具get_response_time(endpoint)，系统提示词很短，用户提问是"Quelle est la vitesse du endpoint /users？"

Agent回答得又快又自信，但全是错的。我观察到的回复包括："Le endpoint répond en 47 secondes"、"Environ 0,05 seconde"、"La performance est acceptable"。

调试Agent的麻烦在于，错误可能藏在任何地方：系统提示词、模型选择、工具定义、传给工具的参数、工具返回的响应、模型对响应的解读。服务器日志通常只能展示这条链条的一部分。

Apidog调试器分成三个面板：左侧Sessions，中间Tours，右侧Traces。点击一个session，再点击一个tour，Traces面板就会显示完整的执行树。

你能看到：模型收到的系统提示词、用户提示词、调用的工具名称、传给工具的JSON格式参数、工具返回的JSON格式响应、模型的最终回复，以及该轮次的时间、token数和成本。

在我这个出问题的session里，工具调用是正确的：get_response_time(endpoint="/users")。模型选对了工具，参数也没错。

然后我看了工具返回的结果：{"value": 47, "p95": 89, "samples": 1240}。指标管道返回的是毫秒值，模型却假设成了秒。

Bug不在MCP调用环节。它在返回数据的格式里，在没有明确说明单位的缺失里。

修复只花了六行代码。我修改了MCP服务器的响应，让单位变得明确：

{
"value": {"amount": 47, "unit": "ms"},
"p95": {"amount": 89, "unit": "ms"},
"samples": 1240
}

又在系统提示词里加了一句："Les résultats des outils renvoient les unités explicitement. Lisez-les attentivement."

用同样的提示词跑了三次。三个session都正确回答：接口响应约47毫秒。token成本也比之前几次执行更低。