Skip to main content
如需更详细的 Sentry 集成指南，请点击此处。
1

连接 Sentry MCP

在创建计划之前，Devin 需要访问你的 Sentry 数据。
  1. 前往 Settings > MCP Marketplace 并搜索 Sentry
  2. 点击 Enable 并通过 OAuth 进行身份验证 —— 这将授予 Devin 对你的 Sentry 问题 (issues) 、事件 (events) 和堆栈跟踪 (stack traces) 的只读访问权限
  3. 点击 Test listing tools 以验证连接是否正常
连接成功后，Devin 可以在会话中查询你的 Sentry 项目、获取问题详情和堆栈跟踪，并读取面包屑数据。了解更多：配置 MCP 服务器。
2

创建日程安排

Go to Settings > Schedules and click Create schedule。
  • Name: Daily Sentry remediation — payments-api
  • Frequency: 每天早上 6:00 (这样修复 PR 在站会前就能准备好)
  • Agent: Devin — 让 Devin 为每个错误启动单独会话，从而并行执行修复
  • Slack channel: 选择一个频道 (例如 #sentry-fixes) ，这样在运行完成并且 PR 准备好供评审时，你的团队会收到通知
  • Prompt:
3

利用你的代码库和过往修复为 Knowledge 提供初始内容

当 Devin 理解你的应用错误模式时，它能编写出更好的修复方案。与其手动编写 Knowledge 条目，不如在任意会话中让 Devin 分析你的代码库和以往修复记录，然后让它创建 Knowledge：当 Devin 在计划任务运行期间遇到匹配的错误时，这些条目会被自动调用——而上面的定时提示会指示 Devin 基于你的 PR 反馈更新 Knowledge，从而随着时间的推移不断改进。
4

一次典型运行的输出

每天早晨，Devin 会处理夜间产生的错误队列，并创建有针对性的 PR。以下是一段真实会话输出的示例：
Processed 5 Sentry errors from payments-api (past 24h):

1. TypeError: Cannot read property 'last4' of null (1,892 events)
   Root cause: Stripe webhook delivers `payment_method: null` for
   bank transfer payments. CheckoutReceipt.tsx:34 destructures
   without a null check.
   PR #612: Add null safety to CheckoutReceipt, show "Bank Transfer"
   fallback for non-card payments.

2. TimeoutError: Query timeout after 30s on /api/invoices (743 events)
   Root cause: N+1 query in InvoiceService.getMonthly() — each
   line item triggers a separate product lookup.
   PR #613: Add eager loading for invoice line items with
   Sequelize `include`.

3. RangeError: Maximum call stack size exceeded (412 events)
   Root cause: Circular reference in refund.toJSON() when a
   refund references its parent transaction which references
   the refund.
   PR #614: Break circular ref with a custom serializer,
   add max-depth test.

4-5. Two lower-frequency validation errors — PRs #615, #616.
每个 PR (pull request) 都包含一个 Sentry issue 链接、根因说明、修复方法，以及一项本可以捕获该原始错误的测试。
5

优化与迭代

运行一周后，查看哪些有效并进行调整：限定错误数量范围。 每次运行先从 top 5 个错误开始。如果 Devin 能稳定产出可直接合并的拉取请求 (PR)，可以增加到 8-10 个。如果修复需要大量人工修改，就降低到 3 个。按项目或标签过滤。 将提示缩小到特定的 Sentry 项目 (payments-api、web-frontend)，或排除噪声较大的标签。如果不同项目的错误量差异较大，可以为每个项目单独设置运行计划。从结果中学习。 运行几周后，让 Devin 分析哪些修复实际已经上线，并将结论整理进 Knowledge：