开发了一个本地工具，用于缩小成功但错误运行的范围

嘿，大家，我构建了一个东西，我想在与其他工程师交谈后可能会有所帮助。这个领域我厌倦了一遍又一遍地听到同样的废话。明显的模式：运行完成，跟踪存在，没有明显爆炸的东西，最终结果仍然是错误的，然后有人必须花一个下午手动挖掘执行过程，试图找出哪一部分实际上值得首先追踪。是的是的，我知道理想的答案是更早地结构化系统。添加不变量，评估每个阶段，验证状态，使交接明确，所有那些好东西。有些人绝对这样做，它消除了许多这种痛苦，但从我进行的对话来看，许多人最终仍然手动比较步骤输入和输出，与好的运行进行差异对比，反向跟踪状态，或者盯着跟踪试图找出哪个差异实际上重要。所以我说管他呢，让我们看看是否可以自动缩小一些范围。经常出现的东西：前一步看起来没问题，但下一步实际收到不同的状态；工具调用说成功，但响应体包含错误或速率限制；错误的账户/ID被传递下去，而每个步骤都保持模式有效；提示或模型输入更改而跟踪没有明显显示；重试最终成功但执行路径现在不同；配置的模型/提供者不一定是实际服务请求的那个；验证步骤被跳过，所有下游仍然完成。所以我构建了Traser。你给它一个可疑的运行和可选的受信任的运行。它规范化执行，对齐相应的步骤，比较输入、提示、工具参数、输出、状态、重试、来源和其他记录的行为，抑制较低价值的差异，然后给你一小套基于证据值得检查的地方。目前没有LLM进行诊断。当前引擎是确定性的，跟踪分析运行在浏览器中。嗯，也故意不声称根本原因。如果它发现在第4步账户ID更改了，那是证据表明第4步可能值得调查，而不是证明第4步导致了最终结果。我正在验证的部分是排名和对齐是否在真实运行中节省了人们的时间，或者它只是看起来更聪明的差异。这显然仍然是小玩意儿的东西，现在就试试吧，让我知道你是否真的觉得它有用。如果它给出一个愚蠢的候选，错过重要的东西，或者根本没节省你的时间，我宁愿听到这些。