前端抛出 500。Stack trace 指向一个 React 组件。真正的问题在三个服务之外，由泄漏的后台作业耗尽的数据库连接池。

你可以点击浏览 trace waterfall、关联时间戳并阅读提交历史。或者你可以把它交给 Sentry 的 Seer，一个由 LLM 驱动的调试代理，它读取你的 traces、错误和代码，然后告诉你什么坏了。

Seer 擅长这个。但它不是灵媒。这两个说法之间的差距就是本文要讨论的内容。

Statistical debugging 实际上的含义

Statistical debugging 使用多次执行中的模式来精确定位 bug。传统调试器向你展示一次运行。统计方法查看分布：哪些函数一起失败、哪些 traces 与错误相关、哪些提交 preceded a crash spike。

Sentry 多年来一直在做统计部分。Seer 添加了一个 LLM 来在这些数据之上推理因果关系。它没有取代统计。它解释了它们。

Seer 不会凭空 hallucinate 根因。它查看的是你会查看的相同的 traces 和 stack traces，但它在几秒钟内读取数千个 spans，并将它们与你的 codebase 相关联。

Seer 如何在不被 spans 淹没的情况下读取 trace

一个 distributed trace 可以包含数千个 spans。把它们全部喂给 LLM 的 context window 是混乱的根源。模型会 fixation 在不相关的细节上并错过信号。

Sentry 通过构建一个精简的 trace tree 来解决这个问题。Seer 看到的不是每一个 span，而是一个 transaction 的层次结构——将 spans 分组为有意义的单元的 service boundaries。这棵树显示哪些 transaction 调用了哪些其他 transaction、它们花费了多长时间，以及其中是否发生了任何错误。

以下是原始 trace 的概念性表示：

GET /api/checkout
├── POST /payment-service/process
│   ├── SELECT * FROM orders
│   └── UPDATE inventory
├── GET /user-service/profile
│   └── SELECT * FROM users WHERE id = ?
└── POST /notification-service/email
    └── SMTP send

Seer 接收到这个标注了时间和错误状态的树。它看到结账请求调用了三个下游服务。除非它要求，否则它不会看到每一个单独的数据库查询。

关键词是”除非”。Seer 有工具。如果树表明支付服务有问题，它可以获取该 transaction 内的完整 spans、按 ID 关联的错误事件或 CPU profiles。它决定接下来查看什么。

这种 agentic 方法与”把这个 trace 粘贴到 ChatGPT”和 Seer 实际所做的事情之间的区别。聊天机器人只有一次机会。Seer 得到一个循环：观察、推理、获取更多数据、再次推理。

Seer 为解决跨服务问题而构建

在 traces 之前，Seer（当时称为 Autofix）依赖于 stack traces 和 breadcrumbs。这对单体应用有效。对分布式系统无效。

考虑一个前端 500 错误。Stack trace 指向一个 fetch 调用。没有 traces，Seer 会得出结论前端坏了。有了 traces，它看到前端调用了 API gateway，后者调用了 auth service，后者因为一个证书轮换而抛出了 token validation 错误。

Sentry 自己的团队内部也遇到了这个问题。Sentry 后端和 Seer 微服务之间的认证问题已经持续了好几天。Seer 在获得 trace tree 和对两个仓库的访问权限后，识别了根因，并在两个服务中打开了 pull request。

这就是承诺。难点在于设置。

Seer 能帮助你之前需要什么

Seer 需要三样东西才能很好地工作：

1. 关联的 traces。

如果你的服务使用不同的 Sentry 项目而没有 distributed tracing，Seer 看到的是孤立的错误，而不是 trace tree。你需要在每个服务中安装 Sentry SDK，并进行 trace header 传播。

在 Python 中：

import sentry_sdk

sentry_sdk.init(
    dsn="https://your-dsn.ingest.sentry.io/project-id",
    traces_sample_rate=0.1,  # Adjust for your volume
)

对于跨服务传播，SDK 在支持的 HTTP 客户端上自动读写 sentry-trace 和 baggage headers。如果你使用自己的客户端，手动附加 headers：

from sentry_sdk import continue_trace

headers = {}
continue_trace(headers).apply_to_request(headers)
response = my_custom_http_client.get(
    "http:// downstream-service/api",
    headers=headers,
)

没有这些，Seer 将前端和后端错误视为不相关的事件。Trace tree 永远不会形成。

2. 关联的代码。

Seer 搜索你的 codebase 以将 traces 与实现相关联。这需要 GitHub 集成，并将仓库映射到 Sentry 项目。Seer 无法从 zip 文件或本地路径读取你的代码。

3. 足够的信号。

一个只有自动插桩 HTTP spans 的 trace 告诉 Seer 服务 A 调用了服务 B。但它不会告诉 Seer 中间发生了什么业务逻辑。Custom spans 很重要。

from sentry_sdk import start_span

def process_payment(order_id):
    with start_span(op="payment.process", description="Validate and charge"):
        validate_order(order_id)
        charge_customer(order_id)

没有这些，Seer 看到 HTTP 请求和数据库查询之间是一个黑盒。

没人写在营销文案中的权衡

Seer 有真正的局限性，Sentry 对此相当诚实。

准确率很高，但不是 100%。

Sentry 报告了 94.5% 的根因识别率。这意味着大约每二十个问题中有一个被误诊。对于高严重性事件，在部署修复之前，你仍然需要人工验证 Seer 的结论。

每次运行都要花钱。

Seer 运行每次根因分析大约花费 1 美元，加上月度订阅费。自动扫描更便宜，每个问题 0.003 美元。对于一个每天处理数十个问题的团队来说，这会累积起来。仔细配置自动化阈值。

它无法修复它看不到的东西。

如果你的 traces 采样率为 1%，而 bug 只出现在另外 99% 中，Seer 就找不到它。如果根因在一个不向 Sentry 发送 traces 的第三方服务中，Seer 会撞墙。如果问题是一个从不抛出错误的逻辑 bug，Seer 永远不会触发。

LLM 在某些类型的推理上仍然很差。

一项 Microsoft 研究证实了大多数开发者的猜测：AI 代理擅长定位问题，但在原因与症状相距较远时，难以进行根因分析。跨时间的因果关系，尤其是涉及 race condition 或 state corruption 时，仍然很困难。

Seer 何时表现出色，何时应该跳过它

Seer 值得尝试的情况是：

  • 你有一个分布式系统，traces 跨多个服务关联
  • 问题涉及 Sentry 已捕获的明确错误事件
  • 根因可能在你自己的代码中，而不是第三方依赖
  • 你有足够的 trace 量，手动调查很繁琐

跳过它的情况是：

  • 你的 traces 没有跨服务关联
  • 问题是间歇性的，很少在 traces 中捕获
  • 你需要对活跃事件进行亚分钟级响应（Seer 运行需要几分钟）
  • 根因几乎肯定是基础设施，而不是代码

如何实际尝试它

如果你已经在使用付费的 Sentry 计划，Seer 可以作为 14 天试用版使用。

  1. 在 Sentry 组织设置中连接 GitHub
  2. 在 Seer 设置中将你的仓库映射到 Sentry 项目
  3. 确保在 SDK 中启用了 tracing，并设置了 traces_sample_rate
  4. 打开任何问题并点击 Find Root Cause

对于自动运行，配置一个停止点。大多数团队从 Stop after Root Cause 开始。一旦你信任了准确率，你可以让它提出解决方案或起草 pull request。

如果你使用 Cursor 或 Claude Code，你可以直接在 IDE 聊天中通过 Sentry 的 MCP server 调用 Seer。

诚实的底线

Seer 可以通过构建精简的 trace tree、按需获取详细数据以及跨 codebase 推理来找到 traces 中的根因。对于关联良好、插桩充分的分布式系统，它确实很有用。Sentry 自己的工程师在跨服务问题上节省了数天的调试时间。

它不是理解你自己系统的替代品。它是一个非常快、阅读量很大的实习生，能读取 traces 和代码，但仍然偶尔会把责任推给错误的服务。用它来加速调查，而不是消除调查。

如果你的 traces 干净、关联且充满有用的 spans，Seer 可能会给你留下深刻印象。如果不是，先修复 traces。没有 LLM 能调试你从未费心插桩的东西。

常见问题

Seer 能与自托管的 Sentry 一起工作吗？ 不能。Seer 是一个需要 sentry.io 的云服务。它依赖 Sentry 自己的基础设施来运行 LLM 代理和访问你的遥测数据。自托管实例无法访问 Seer。

Seer 能分析 Python 和 JavaScript 之外的语言的 traces 吗？ 可以。Seer 从 Sentry 读取 trace 数据，而不是原始的语言特定遥测数据。任何使用 Sentry SDK 插桩并产生 traces 的服务都可以输入 Seer。代码分析步骤需要 GitHub 集成，它适用于任何语言。

如果 Seer 弄错了根因会怎样？ 你可以在分析过程中提供反馈，Seer 会将其纳入考虑。最终输出在任何代码更改应用或 PR 打开之前总是需要人工批准。除非你明确配置，否则不会自动发布任何内容。

这与只是把 stack trace 粘贴到 Claude 或 ChatGPT 中有什么不同？ 聊天机器人获得一个包含你粘贴内容的单一 context window。Seer 获得一个 agentic 循环，可以访问你的完整 trace tree、关联的错误、CPU profiles 和 codebase。它可以在推理时获取更多数据，并且因为它读取了实际代码，所以了解你系统的结构。