@ArizePhoenix: Phoenix's agent PXI can propose annotation categories, annotate traces en mass, and even suggest fixes based on pattern…

Phoenix’s agent PXI can propose annotation categories, annotate traces en mass, and even suggest fixes based on patterns of failures. Learn how to do it:

https://t.co/6eQUMchZKz

TL;DR: 使用 Phoenix 的 Pixie 助手对购物代理的 17 个错误跨度进行分类、批量标注，并基于观察生成系统提示修复建议。

识别与过滤错误跨度

上一集我们总共发现了约 11 个错误跨度，但并非所有错误都值得立即修复——速率限制、数据库宕机、空值检查等许多问题不在可控范围内。需要先用状态码错误宏过滤出所有错误跨度，再进一步分析来源。

切换到“全部”视图后，嵌套的错误也显示出来，最终我们得到 17 个跨度。

让 Pixie 分析错误并提出分类建议

点击 Phoenix 中的 Pixie 胶囊图标，向它发送指令：“Pixie，看看所有错误跨度，分析哪里出了问题，并给出一些分类建议。” Pixie 会自动从根跨度切换到“全部”视图，并提供详细的观察日志。

观察结果包括：

• Chroma DB 连接被拒绝
• API 速率限制（多次出现）
• 无效工具调用（两次）
• 价格问题（三次）
• 空产品数据（出现次数最多）——搜索项目或获取产品崩溃时产生
• LLM 错误（三个）
• 工具超时、无效工具、基础设施故障等

细化分类粒度：从“空产品数据”拆分为更细的类别

空产品数据 这个标签太宽泛，不符合“是或否”的分类原则。好的分类应该像“这只猫是不是白色”一样明确，而不是“猫是什么颜色”这种开放式问题。

再次询问 Pixie：“我觉得至少有一个类别太宽泛了，你能再细分一下吗？” Pixie 建议 工具超时 是最可拆分的类别，并将部分归为 提示注入。实际分析发现：智能体正确拒绝了提示注入，但仍然因真正的购买产品服务超时而报错。最终决定拆分为“工具超时”和“提示注入”，确认后提交。

批量标注 17 个错误跨度

Pixie 询问是否需要继续用这些新类别标注所有 17 个跨度。选择“继续标注这些跨度”。在设置中可切换到“绕过批准”，这样 Pixie 无需每次确认即可自动执行批量标注操作。

标注结果显示在跨度列表中，每个跨度被标记为对应的错误类别（例如：空产品数据、速率限制等）。

逐个检查标注的跨度

1. Chroma DB 宕机（基础设施故障）

不在控制范围内。添加备注：这是基础设施问题，不是提示词或我们能控制的事情，提交 bug。

2. 注入尝试

智能体正确执行了职责——模型拒绝透露系统提示。这不是 bug，而是功能。

3. 工具购买产品超时（30000 毫秒）

应提交 bug。

4. 无效工具调用：购买零个物品

查看对话记录，发现 LLM 以为可以接受数量为零，但实际上不允许。这属于可修复的问题。

用 Pixie 分析跨度并生成修复提示

从跟踪跨度中读取当前的系统提示，询问 LLM：“如果仔细看，它就在这里。Pixie 现在正在查看我们识别出的所有不同问题，并提出一个新的系统提示。” Pixie 分析后提出修订后的系统提示，内容如下：

这是一个 Wonder Toys 购物代理，目的是帮助用户购买玩具。可以使用搜索产品或购买产品工具，但只有当客户明确要求购买时才调用购买产品。不允许传递零数量。

这是一个很好的示范：使用 LLM 识别不同跟踪中的问题，并基于模式自动建议修复方法。但要注意：推荐的修复只是一个假设，直到实际测量、评分和加权后才能确认效果。下一集将采用这个提示，并实际验证它是否能减少错误跨度中的错误数量。

Source: YouTube 视频：Phoenix’s agent PXI can propose annotation categories, annotate traces en mass, and even suggest fixes based on pattern…