上个月，我们的客户在 PostHog 项目中部署了 AI 代理，尝试解决产品中的 6,124 个错误。他们解决了 4,063 个问题，抑制了 1,751 个问题，并将 310 个问题路由给了合适的团队。几乎所有这些代理都没有打开 PostHog 用户界面。
这些数字与我们对自动驾驶产品的投入相符——代理越了解你的代码库和数据，他们就能为你分担越多的日常工作，而分诊是这种转变最先显现的领域之一。
我们显然很想知道用户在使用 MCP 时遇到了哪些类型的问题。
以下是我们发现的情况。
代理程序在您的错误积压中执行三种不同的任务
我们对 30 天内由 MCP 驱动的错误分类行动进行了归类，并将它们清晰地分为三类：
已解决，也就是“我们已修复”。这是主要数据。超过 4000 个问题被客服人员标记为已完成，他们要么生成了修复程序，要么确认修复程序已发布，要么追踪到根本原因并得出结论，认为问题已自行解决。
抑制，也就是“别再给我显示这些”。大约有 1750 个问题被标记为已知噪声——第三方 SDK 警告、预期异常、以及你已经见过无数次的典型浏览器垃圾信息（ Script error. 、 ResizeObserver loop completed... 、 Object Not Found Matching Id ）。代理程序正在默默地维护着你一直想自己维护的噪声过滤器。
路线又称“负责人错误”。超过 300 个问题被重新分配给其他人或团队——有时还会创建一个新的 Linear 工单，以便新负责人可以跟踪工作进度。
三种不同的结果，三种不同的用户调用该工具的原因。我们最初认为该代理只负责初步分类，这种看法过于粗略。实际情况更像是“代理会完成所有必要的操作，然后根据情况标记问题”。
我们学到了什么
在观察实际应用中由智能体主导的紧急救治过程时，有几点特别突出。
更小、更锋利的工具胜出
我们最初推出 MCP 错误跟踪支持时， error-tracking-query-issue是一个同时处理多个任务的综合端点。但在实际使用中，我们发现客服人员希望能够将这些任务分开处理。因此，在四月下旬，我们将该工具拆分为三个端点： issues-list 、 issue和issue-events 。拆分后，批量分诊流程明显变得更加顺畅。
分诊并非一蹴而就。
我们最初将 MCP 分诊视为一个单一的工作流程——“客服人员更新问题”。但实际上，其中涉及三个截然不同的步骤：问题得到修复和解决、问题被过滤为已知噪音、问题被重新分配给合适的负责人。这三项工作需要不同的提示和不同的成功定义。我们下一阶段发布的技能将以这种方式处理它们。
错误是起点，而不是终点。
当客服人员处理错误时，他们很少止步于问题本身。他们会深入调查相关事件，找出受影响的用户，检查哪些功能开关被启用，并查看会话录像。当跨产品进行调查而无需用户切换上下文时，MCP 的强大之处就体现出来了。
搜索行为告诉我们一些意想不到的信息。
我们看到的搜索内容大约有一半符合预期——错误字符串、异常类型、常见的 JavaScript 模式。另一半则按业务界面分类：结账、计费、身份验证、嵌入。用户不仅仅是在搜索“最新的 TypeError”，他们还会问“本周结账流程中出现了哪些问题”。这清楚地表明，按业务界面筛选需要像异常类型筛选一样简单易用，目前我们已将其列入优先开发清单。
批量生产才是真正的制胜之道。
在用户界面中，单问题调试一直都可行。MCP 驱动的问题分类机制最擅长的是那种过去需要花费一个小时点击才能完成的批量操作——例如“屏蔽过去 90 天内所有与此第三方相关的噪音”或“将所有 iOS 崩溃问题转交给移动团队”。现在只需一句话就能搞定。这才是真正节省时间的地方。
这里还有一些有趣的事实：
代理最擅长处理的错误类型
MCP 驱动的分类在以下四个类别中真正发挥作用。
前端噪音，每个人都有，但没人清理。
浏览器兼容性问题、已弃用的 SDK 警告、第三方追踪器异常。“我们知道这些问题，但这并不重要”的提示信息堆积如山，最终导致你的仪表盘变得难以阅读。试试看：
试试 PostHogAI Suppress any errors matching `Script error.`, `ResizeObserver loop completed`, or `Object Not Found Matching Id` from the last 90 days.
需要过滤而非修复的网络和身份验证错误
Failed to fetch 、 AuthRetryableFetchError 、超时异常——通常是暂时性的，最好采用抑制机制结合在真正出现峰值时发出警报的方式来处理。尝试：
试试 PostHogAI Create a suppression rule for `Failed to fetch` errors from `api.thirdparty.com`, but keep me alerted if the rate exceeds 100 per hour.
需要路由的业务领域错误
结账流程中TypeError 、部署后出现ChunkLoadError 、支付 Webhook 失败等问题。请按路由或服务分组，并重新分配给负责该接口的团队。尝试：
试试 PostHogAI Group every error on `/checkout` from the last week by exception type, and assign each group to the team that owns the relevant service.
平台特定崩溃
iOS、Android 和服务器端错误，只有部分团队成员才能调查。请尝试：
试试 PostHogAI Reassign every iOS crash from the last release to the mobile team, and create a Linear ticket linking back to the PostHog issue.
值得尝试的提示
一旦您的代理连接到 PostHog 错误跟踪，这些提示就会映射到人们已经在做的实际工作中。
每周清理
- “请列出过去7天内排名前10位的错误。并分别告诉我，每个错误的数量是在增加、保持稳定还是减少。”
- “解决过去30天内尚未解决的所有问题。”
- “抑制所有符合以下列出的模式的错误。”
用于事件分诊
- “过去一小时内哪些错误开始激增？请提供前三个错误的完整堆栈跟踪信息。”
- “找出我最近一次部署后出现的所有错误。”
- “哪个用户受此错误的影响最大？错误发生前他们在做什么？”
关于路由和所有权
- “创建一个分配规则，将所有
TypeError异常发送给前端团队。” - “任何涉及
stripe的错误都应该转交给支付团队。” - “对于每个标记为
mobile活跃问题，创建一个 Linear 工单并将其分配给移动设备所有者。”
根本原因调查
- “针对此错误，请找到匹配的会话记录，并总结用户在错误发生前执行的操作。”
- “在出现此错误之前，我们的代码库发生了哪些变化？”
- “请告诉我出现此错误的用户启用了哪些功能标志。”
尝试使用MCP
在您首选的客户端中安装 MCP 服务器——AI 向导会自动处理 Claude、Cursor、Windsurf、VS Code 等客户端的设置：
或者npx @posthog/wizard mcp add
手动配置。