成功的重试可能使代理跟踪更具误导性，而非减少

我一直在思考上次发帖中提到的一个问题。假设一个代理调用一个工具，出了错，重试了几次，最终成功。乍一看，分析起来似乎很简单，对吧？将重试分组，比较它们，找出变化之处。但这里有个棘手的问题：你如何知道两个相似的调用是尝试同一逻辑操作？使用相同的工具和几乎相同的参数并不能证明它。它可能是：一次实际的重试、因不同原因再次调用同一工具、不同分支达到相似操作状态、在尝试之间状态变化，使得看似重试的东西意义不同。上次线程中有人提出了一个我赞同的观点：相似性有助于缩小候选范围，但相似性不应神奇地变成同一性。如果跟踪中有关联ID、尝试ID、相同父跨度、幂等性键、相同行被触及等，那么你就有更强的证据。如果这些都不存在，我开始认为正确的答案是承认配对是不确定的，而不是假装0.92的相似性分数使其真实。另一个我仍在思考的问题是第一差异与有用差异。首先变化的东西可能在技术上真实，但对工程师完全无用。时间戳变了，请求ID变了，一些无害的元数据移动了。与此同时，真正解释奇怪行为的事情可能发生在8步之后。但相反的问题也存在。一旦你开始对所有可能的差异进行排序，很容易构建一个花哨的噪音生成器。所以，我试图用Traser做对的事情不是：找到每一个差异，而是：显示少数真正值得工程师查看的差异。告诉我它们为什么出现，不要隐藏不确定性。好奇这里的人们今天如何处理这个问题。如果你的跟踪没有干净的重试/关联ID，你如何决定两个调用属于同一操作？你通常更关心第一差异还是第一个真正改变下游行为的差异？当你围绕这个构建启发式方法时，是什么让你足够信任它们以采取行动？另外，我在寻找更多团队作为Traser的设计伙伴，帮助我根据实际使用进一步塑造它（这是免费的，哈哈）。如果你在生产中运行代理，并有一些真实失败导致的丑陋跟踪，请告诉我。不关心运行是否让Traser看起来聪明或完全愚蠢，两者都有用。否则，如果你是一个独立开发者，只想节省一些时间，我会在下面发布链接，请随时告诉我我们可以改进什么。