Rider 用实时 Profiler 数据让 AI 精准诊断瓶颈

Essential productivity kit for .NET and game developers

有一个值得思考的案例：你的应用冻结了十秒钟，你问一个 AI Agent 出了什么问题。它实际上会做什么？长期以来，诚实的答案是：它翻遍你的代码，然后胡乱猜测。

分析器工具捕获的快照是运行时证据。它清楚地知道 CPU 去了哪里。但一个没有访问分析器数据的 Agent 无法读取它。所以它只能做能做的事：扫描项目，找一些似乎有问题的低效率代码，然后自信地把它们当作瓶颈呈现出来。有时候它运气好。在真正的冻结上，通常不会。

我们一直在 Rider 中构建一些东西来解决这个问题：一个由 dotTrace 支持的分析能力，用于 AI Assistant 内部的 Agent，叫做 dottrace-analyze。这个想法非常直截了当。你给 Agent 一个已经用 dotTrace 捕获的 .dtp 快照——可以来自独立分析器、命令行工具或 Rider 内的 dotTrace——而不是在源代码中游荡，它首先读取分析数据。它找到时间实际去了哪里，沿着热路径回溯到你的代码，并解释什么是慢的、为什么慢，以及接下来应该看什么的建议。

我们进行了评估。为了避免打分成为个人判断，每个答案都是根据一个固定的 LLM 作为评判者的标准来评估的：Agent 是否识别了主要热点、解释了机制、避免了误导性的弯路，以及提出的修复是否遵循了证据？结果甚至超出了预期，所以为什么不从最戏剧化的开始呢：

dotTrace 支持的能力改进了更广泛评估批次的结果，然后在对 Agent 轨迹的更仔细观察中显示了相同的模式。

分数是根据已知的参考根本原因进行评判的；轨迹数据显示 Agent 如何到达其答案的。

案例研究：一个没有 dotTrace 时 Agent 找不到的 UI 冻结

我们的一个测试场景是早期版本的 Avalonia，在关闭时用来挂起。这个问题甚至在两年前蔓延到了 Rider 本身，这说明了来自流行开源项目的性能下降有多容易渗透到你的应用中。

为了澄清我们的方法论：我们故意测试了 AvaloniaUI/Avalonia#16633 修复前的 Avalonia 版本。对我们来说，使用一个已知的、已经解决的 Bug 很关键，因为它为评估提供了一个干净的参考答案。

我们用该 Agent 针对这个问题运行了十次（带能力）和十次（不带能力），并让一个 LLM 评判根据已知根本原因对每个诊断进行 0 到 10 的打分。

没有该能力，Agent 的平均分是 10 分中的 1.6 分。它翻遍了渲染代码，列出了一些通用建议，从未找到真正的问题。

有了该能力，它在全部十次运行中都得了 10 分。

同一个 Agent，十次运行，根据已知根本原因进行评判。

这就是"这里的代码看起来可疑"和"快照说冻结在这里"之间的区别。

结果不是"有点好转"：Agent 从可靠地迷茫转变为可靠地正确，没有任何偏差。

它找到的是一种即使你有几个小时也很难通过阅读代码发现的东西。冻结不在任何一个明显的地方。它来自于文本布局路径深处的单个逐字符操作，单独来看很便宜，但运行了这么多次以至于吞掉了大部分 CPU。那个成本只有在你能看到时间实际去了哪里时才会显现出来。Agent 根据快照直接跟踪到了它，解释了为什么它这么昂贵，并指出了会修复它的改变。

完整基准：八个场景，80 次运行

Avalonia 场景只是我们评估的一个切片。在检查该案例的多次运行后，我们将批次扩展到来自不同项目的八个 .NET 性能调查场景，并将相同的 Agent 在有和没有分析器访问的情况下进行了比较。以下是该能力对每个场景平均准确度分数的改变，满分 10：

在 80 次运行中，该能力改进了平均质量和一致性。

最大的收益出现在答案真正存在于运行时证据中的地方。平的或略微负面的情况也很有用：它们显示了产品应该避免调用更重的分析器工作流的地方。

在全部 80 次运行中，平均准确度分数从 4.71 提高到 8.15。得分 8 或以上的运行数大约翻了一倍，从 29 到 59。精确找到根本原因的运行数（完美的 10）翻了不止一倍，从 20 到 48。

表格中有两件事我们想坦诚地说。

第一件是该能力发挥作用的地方：基线是无望的场景。任何答案真正存在于运行时的地方（Avalonia 冻结、Cyclops 工作负载），基线得分在 1 到 2 范围内，该能力将其提升到 9 或 10。Agent 停止分散注意力于通用优化想法，而是锚定在真正慢的东西上。

第二件是表格的底部，我们故意把它留在了里面。game-of-life、checkers-copy 和 checkers-update 即使没有任何分析器工具也处理得很好，在两个 checkers 案例中，该能力将分数略微降低了几分之一。这个教训不是该能力伤害了结果。而是有些任务不需要它。有时，当快速查看代码就可以解决时调用一个完整的分析器工作流就是浪费 token。

这实际上花费了什么

我们像追踪准确度一样仔细追踪成本，因为一个以不合理的价格产生更好答案的能力不是我们会发布的。首先是直接的部分：读取快照是真正的工作。Agent 加载分析器数据，遍历调用树，并在开始推理前将证据连接回你的源代码。在上面的 80 次运行批次中，这显示在账单上。成本从不带该能力的大约每次运行 USD 1.91 增加到带该能力的大约 USD 2.61。总批次成本从不带该能力的大约 USD 153 增加到带该能力的 USD 209。考虑到诊断改进了多少，我们认为这是一个很好的权衡，但这是一个真实的增加，我们宁愿你从我们这里听到它。

不过还有第二个效应，它往另一个方向运行。在一个额外的 Avalonia 测试案例中，一个关闭很慢的应用，不带该能力的 Agent 从未找到真正的原因。在十次运行中它一直在构建同一个似乎合理但错误的理论，广泛搜索并阅读文件，每次都得了 0 分。有了该能力，它先进行测量，根据分析器直接跟踪到负责的代码路径，每次都得了 10 分。跳过所有这些游荡也使运行更便宜更快：每次运行 USD 2.58 而非 USD 3.74，206 秒而非 373 秒。

所以公平的总结是该能力改变了钱去的地方。它在读取证据上花费更多，在探索死路上花费更少。有时这加起来会更贵，有时更便宜，但在两种情况下你都在为基于你的应用实际做的事情的答案付费，而那是我们认为值得的部分。

分析器分析有成本，但它也可以减少广泛的、无生产力的代码搜索。

快照分析增加了运行成本，而准确度大幅改进。

分析器证据减少了游荡，直接把 Agent 送到了负责的代码路径。

该能力在默认情况下并不更便宜。它改变了工作发生的地方：更多证据读取，更少死路探索。

你在 Rider 中会看到什么

工作流有意很简单：用 dotTrace 捕获一个 .dtp 快照，无论是来自 Rider 内部、dotTrace Standalone 还是 dotTrace 命令行工具。然后在 AI Assistant 工具窗口中要求你选择的 Agent 通过在提示中引用其目录来调查该快照。

在幕后，它加载 dottrace-analyze 能力并使用 dotTrace SDK 来读取分析数据；返回的是一个重点报告：

• 主要瓶颈的简短总结；
• 拥有运行时的方法、源位置和调用路径；
• 用普通开发者语言而不仅仅是方法名称表达的根本原因；
• 关于接下来应该看什么的建议。

对于更深入的调查，它可以将其呈现为一个简洁的 HTML 报告，你可以在标签中打开并与团队分享。性能工作通常是协作的，当不止一个开发者在解决问题时，一个干净的工件非常方便。

Agent 的搜索轨迹如何改变

第二次评估中最强的信号是轨迹：Agent 通过工具和文件的实际路径。无能力的运行失败不是因为它们是懒惰或不连贯的。它们广泛搜索，找到了一个真实外观的计时器问题，并围绕错误的子系统构建了一个有信心的解释。有能力支持的运行从测量开始，所以搜索空间在源代码读取开始前就围绕着热路径坍缩了。

相同的关闭任务、相同的模型、相同的代码库。区别在于第一个有用的证据。

无能力的运行：

2 个子 Agent 搜索、13 次读取、2 个 glob、2 个 grep。没有测量，只有推理。

探索关闭路径 横跨 dispose、shutdown、dispatcher 和 timer 代码。

读取渲染和分派器文件 通过 MediaContext、render timers、application lifetime 和 dispatcher 循环。

搜索阻塞模式 寻找 waits、joins、sleeps 和 render-thread 模式。

锚定在 Win32DispatcherImpl.cs 发现 Now - dueTime 在 UpdateTimer 中并将其当作决定性线索。

证实计时器理论 读取 dispatcher 接口和队列来支持一个似乎合理但错误的诊断。

错误的目标 全部 10 次无能力运行都聚合在了错误的区域。答案听起来有根据，但从未到达关闭热点。

有能力的运行：

1 个能力调用、5 个分析器调用、1 个 grep、1 个 glob、2 次读取。先测量，再读取。

调用 dottrace-analyze 进入结构化快照工作流。

读取快照和时间线 找到一个 7.3 秒的捕获，一个核心卡住了大约 5.5 秒，GC 可以忽略。

检查运行中的调用树 最大的自身时间叶是 List<T>.Remove，通过 Classes.RemoveListener 到达。

跳转到受牵连的源 对 RemoveListener 进行 grep，读取 Classes.cs，然后定位到 SafeEnumerableList.cs。

确认根本原因 深入递归分离并识别 O(n^2) 监听器删除。

正确的目标 全部 10 次有能力运行都命名了确切的根本原因。源代码读取确认了测量的证据，而不是发明可疑列表。

在这个关闭评估中，有能力的部分平均也完成得更快更便宜：206 秒和每次运行 USD 2.58，相比无能力的 373 秒和 USD 3.74。

证据胜于猜测

你可以用一个对比总结整个结果。没有快照，Agent 能提供的最好的是"这里有一些可能很慢的代码味道"。有了它，Agent 可以说"这个快照说你的时间有 88% 去了这里，这就是为什么"。那第二句话是整个重点。

代码只有的 Agent 和分析器支持的 Agent 如何决定首先看哪里的并排视图。

性能工作有一个严格的要求，大多数编码任务没有：答案必须与程序实际做的匹配，而不是它看起来可能做的。我们评估中的强有力运行都有相同的形状：它们不仅命名了一个方法，它们解释了调用路径，量化了热区域，将根本原因与其症状分开，并提出了直接遵循分析的修复。那是一个专家的调查的形状，只有当 Agent 从一个专家会的相同证据开始时才可能。

dotTrace 已经知道在运行时发生了什么。AI Assistant 已经可以将证据转变为解释和下一步。该能力是两者之间的桥梁，在最重要的情况下，它是一个猜测的 Agent 和一个知道的 Agent 之间的区别。

现已在 Rider 2026.2 EAP 8 中提供

关于许可的说明：在 Rider 2026.2 Early Access Program 期间，你可以在 EAP 构建中免费试用此工作流。对于常规产品许可，此功能的分析部分依赖于 dotTrace。Rider 中的 dotTrace 和 dotMemory 插件可通过 dotUltimate 或 All Products Pack 订阅获得；仅 Rider 订阅不包括 dotTrace 分析。

这仍然是 Early Access Program 的一个早期的、实验性的实现，我们还有工作要做。这就是为什么你的反馈非常重要。让我们知道你对报告的有用程度或它可能不完全可靠的地方。下载最新的公开构建来试试吧。

谢谢，我们为你服务！

Rider 2026.2 将 IDE 自身的智能打开给你的 AI 编码 Agent，所以它们从真实的项目知识而不是从文件和终端输出重建的知识开始工作。一组新的 Agent 能力覆盖测试、分析、重构和官方 Microsoft .NET 工作流，以及 GitHub Copilot…

ReSharper 2026.2 在 Visual Studio 中采取了朝向基于 ACP 的 Agent 支持的第一步，从 Junie Preview 开始。这是为 .NET 开发者开放 AI 生态系统的开始：你选择的 Agent 和模型，通过单一协议连接，与代码智能 ReSharper…

Rider 2026.2 发布候选已为你试用准备好了。这个即将发布的版本将 IDE 自身的智能打开给你的 AI 编码 Agent，将 GitHub Copilot 本地引入，并在 .NET 和游戏开发中都带来一波性能收益。Rider 2026.2 使调试器启动和中断…

ReSharper 2026.2 发布候选已为你试用准备好了。这个版本在 Visual Studio 中采取了朝向基于 ACP 的 Agent 支持的第一步，从 Junie Preview 开始，并用更好的分析、重构和 .editorconfig 集成来磨锐日常 C# 开发。它也带来了…