inbox-exploration

探索收件箱

收件箱是 PostHog 展示信号报告的地方——相关观察（信号）经过聚类后，会汇总为一个问题或趋势（例如“/checkout 的错误率飙升了 3×”）。报告来自多个源产品：错误追踪、会话回放、Web 分析、实验，以及 Linear、GitHub 和 Zendesk 等集成。

收件箱是 PostHog Desktop 的一部分，这是 PostHog 面向工程团队的 Agent 化界面。

不要假定用户的项目中有报告，也不要假定任何信号源已配置——许多项目都没有设置收件箱。回答用户的实际问题之前，务必先运行下面的设置检查工作流。

何时使用此技能

• “我的收件箱里有什么？”/“我应该先看什么？”
• “显示可采取行动的报告”/“PostHog 最近标记了什么？”
• “有没有关于 <主题 / 产品领域> 的报告？”
• “这个项目配置了哪些信号源？”
• 用户粘贴了报告 ID 或 URL，并希望了解相关背景
• “修复这个收件箱项目”/“把这份报告变成 PR”/“实现这份报告”——请参阅 工作流：处理可采取行动的报告
• “忽略这个”/“暂缓这份报告”/“标记为已解决”/“我已经修复了”——请参阅 工作流：解决、忽略或暂缓报告
• “完成合并”/“运行这份报告中的建议提示词”——请参阅 工作流：对报告执行操作

如需深入调查，请转交给其他技能和工具：

• signals 技能——通过 HogQL 查询 document_embeddings 获取原始信号文本、跨信号进行语义搜索，或检查构成报告的每一条信号。
• PostHog 的产品专用 MCP 工具——当报告指向特定错误、日志行、会话、用户或时间范围时，使用相应领域工具获取更丰富的背景信息：
  • 错误追踪：对于来源于错误追踪的报告，使用 query-error-tracking-issues-list、 query-error-tracking-issue、query-error-tracking-issue-events
  • 日志：使用 query-logs、logs-count-ranges 查找问题发生前后的日志活动
  • 会话回放：使用 query-session-recordings-list、session-recording-get 查找受影响用户的录制
  • 用户 / 活动：使用 persons-retrieve、advanced-activity-logs-list 检查特定用户的 行为
  • 趋势 / SQL：使用 query-trends、execute-sql 执行临时验证查询

信号报告会告诉你 PostHog 聚合了_什么_。产品专用工具会告诉你_底层详情_——用户想要深入了解时，请结合使用这些工具。

可用工具

工具	用途
inbox-reports-list	按页列出报告，并支持筛选条件（状态、搜索等）
inbox-reports-retrieve	获取单个报告的完整详情
inbox-reports-claim	认领或释放报告，并可选择关联其实现 PR
inbox-report-artefacts-list	报告的完整工作日志——signal_finding 证据、状态判定、提交、任务运行和备注（只读）
inbox-report-artefacts-retrieve	获取单个工件的完整详情（只读）
inbox-reports-set-state	解决（resolved）、忽略（suppressed）或延后处理（potential）单个报告
inbox-reports-bulk-set-state	一次调用对 1–100 份报告执行相同状态转换（逐个返回结果）
inbox-report-actions-list	报告的 Agent 运行操作（Get it merged、建议的提示词），以及每项操作是否可以立即启动（只读）
inbox-report-actions-run	将其中一项操作作为与报告关联的后台 Agent 运行启动
inbox-ranking-outcomes-list	各排名模型结果的预测内容，以及预测周期、群组和基准率（只读）
inbox-source-configs-list	已配置的信号源（哪些产品会向收件箱提供数据）
inbox-source-configs-retrieve	获取单个信号源配置的完整记录
inbox-source-configs-partial-update	切换信号源的 enabled 标志（或调整其 config）
posthog:execute-sql（signals skill）	访问底层信号的 HogQL（请先阅读 signals skill）

inbox-reports-*-list / -retrieve、inbox-report-artefacts-list / -retrieve 和 inbox-source-configs-*-list / -retrieve 工具均为只读。开放的写入操作包括 inbox-reports-set-state（解决 / 忽略 / 延后处理单个报告）、 inbox-reports-bulk-set-state（一次调用对 1–100 份报告执行相同状态转换）、 inbox-reports-claim（认领 / 释放 / 关联 PR），参见 Workflow: resolve, dismiss, or snooze a report；inbox-report-actions-run（根据报告操作启动 Agent 运行），参见 Workflow: run an action on a report；以及 inbox-source-configs-partial-update，用于开启或关闭信号源的 enabled 标志（例如，设置为 {enabled: false} 可停止信号源向收件箱提供数据）； 此外，-create / -update 也可用于创建信号源或整体替换其配置。无法通过 MCP 暂停处理。

术语

各报告状态的含义（大致按分诊 Agent 应关注的顺序排列）：

• ready — 判断已完成，可采取行动的评估已就绪
• pending_input — 等待用户输入以继续处理
• in_progress — 正在进行摘要 / 判断
• candidate / potential — 已累积信号，但尚未晋升为正式报告
• failed — 处理出错
• suppressed — 已移出收件箱；默认不显示。有人或 Agent 将其驳回，或者法官在任何人审阅之前将其拦下。参见下文的 已驳回和被拦下的报告
• resolved — 报告要求的工作已完成。此状态为终止状态：已解决的报告永远不会再次晋升，因此问题复发时会新建一份报告，并关联到原报告。在关联的实现 PR 合并时自动设置，也可通过 inbox-reports-set-state 直接设置（参见下文的工作流）

默认情况下，inbox-reports-list 会排除 suppressed 报告，并按 -is_suggested_reviewer,status,-updated_at 排序——先显示用户本人建议的报告，再按状态排序，最后按更新时间从近到远排序。筛选方式请参阅工具的输入架构。

已驳回和被拦下的报告

suppressed 报告有两种来源。收件箱会在各自的视图中显示这两类报告，而 inbox-reports-list 可通过其 view 参数执行相同的区分：

view	列出符合以下条件的 suppressed 报告	suppression_source
dismissed	被人或 Agent 驳回、已合并到另一份报告，或其 PR 未合并即关闭的报告	dismissed
held_back	法官在任何人审阅之前拦下的报告	safety_judge, not_actionable, system

每条 suppressed 报告都包含两个字段，用于区分其来源：

• suppression_source — 除非状态为 suppressed，否则为 null。
  • dismissed：有人选择移除该报告。请查看 dismissal_reason 和 dismissal_note 了解原因。
  • safety_judge：安全法官判定该报告不安全。
  • not_actionable：可操作性法官判定该报告不可采取行动。
  • system：管道因其他原因拦下了该报告。没有驳回记录且没有法官判决的旧报告也会显示此值。
• suppression_explanation — 当来源为 safety_judge 或 not_actionable 时，显示法官的说明。对于其他来源，或法官未给出说明时，为 null。

只有 dismissed 是由人或 Agent 作出的决定。其他来源都是尚未经过任何人审阅的法官判决，而法官也可能出错。不要告诉用户是他们隐藏了被拦下的报告。

在以下情况下，审阅时应包含被拦下的报告：

• 用户询问 PostHog 筛除了哪些内容，或为什么收件箱中缺少预期的报告
• 用户要求全面审阅或审计收件箱，而不只是查看可操作队列
• 在创建或合并报告之前，需要根据完整的收件箱状态进行去重

若要审阅被拦下的报告，请使用 {"view": "held_back"} 调用 inbox-reports-list。显示每份报告的 suppression_source 和 suppression_explanation，以便用户判断该判决。如果用户认为报告有效，请将其恢复，并设置 state: "potential"。 该报告会返回法官拦下之前的状态。如果用户认同判决，请使用 state: "suppressed" 和 dismissal_reason 调用。之后，该报告会从 held_back 移至 dismissed。这两种调用的说明均见 工作流：解决、驳回或暂缓报告。

“建议的审核者”的含义

报告中的 is_suggested_reviewer: true 表示，当前 PostHog 用户是报告研究流程标记出的最多三名最适合处理此报告的人之一。这是判断报告与用户_个人_相关性最高的信号，在进行分诊时应重点参考。

此标记的生成方式：

1. 研究报告时，Agent 会识别与底层信号最相关的 GitHub 提交（例如，修改过出错代码路径的提交）。
2. Agent 会获取这些提交的作者，给较早且相关性更高的提交更高权重，并保留排名前三的 GitHub 登录名。这些信息会作为 SUGGESTED_REVIEWERS 产物保存到报告中。
3. 读取报告时，系统会根据各组织成员关联的 GitHub 身份（社交登录或 GitHub 集成），将这些 GitHub 登录名映射回 PostHog 用户。如果_当前_查看者关联的 GitHub 登录名在其中，该报告的 is_suggested_reviewer 就会变为 true。审核者也可以通过 PostHog user_uuid 保存（例如由 scout 或直接指定组织成员的人设置），这种情况下无需关联 GitHub，也能匹配到查看者。 对于 failed 报告以及被判定为 not_actionable 的 ready 报告，无论报告中有哪些审核者，此标记都会强制设为 false；因此，审计路由时请直接查看 suggested_reviewers。

对分诊的实际影响：

• true 表示“你是此报告的建议审核者”：你可能是负责人，但并非受指派者。流水线推导出审核者时，通常意味着你编写过相关代码（或最近修改过）；由 scout 或某人通过 user_uuid 指定你时，则意味着他们认为你是负责人。这只是一项建议，并非权威结论。
• false 不代表报告无关紧要——这可能表示：（a）代码由其他人负责；（b）建议的登录名来自提交历史，但没有组织成员关联该 GitHub 账号（通过 user_uuid 设置的审核者不受此问题影响）；或（c）源材料未关联到特定仓库或提交。
• 如果用户问“_我_应该看什么？”，请优先列出 is_suggested_reviewer: true 的报告：这些报告被路由给用户，因为用户可能是负责人。其余报告应作为次要类别提及，而不要混在一起。
• 如果用户没有任何建议报告，但收件箱并非空的，请明确说明（“收件箱中没有与你近期编写的代码相关的内容”），不要假装列表顶部的内容是根据用户个性化筛选的。

工作流：处理空收件箱或未配置的收件箱（请先阅读）

在会话中，用户首次询问收件箱时，或任何时候 inbox-reports-list 返回 count: 0 时，都要运行此检查。诊断结果决定接下来应如何回复。

步骤 1 — 查看源配置

inbox-source-configs-list
{ "limit": 50 }

三种重要情况：

情况 A — 完全没有源配置（count: 0）

用户尚未为 Inbox / signals 完成接入。**不要假装 Inbox 中有数据。**明确告知用户，Inbox 需要先配置好信号源，并推荐通过安装 PostHog Desktop 来完成配置，地址为 https://posthog.com/desktop。示例回复：

你的项目尚未配置任何信号源，因此 Inbox 目前为空。Inbox 会展示 PostHog 从错误跟踪、会话回放、GitHub、Linear 和 Zendesk 等来源自动聚类的问题和趋势。最快的配置方式是安装 PostHog Desktop — 连接完成后，信号便会开始流入，报告也会在接下来的一天左右出现在你的 Inbox 中。

除非用户想讨论配置，否则到此为止。不要再运行其他 Inbox 工具 — 返回的都会是空结果。

情况 B — 存在源配置，但全部为 enabled: false

这些来源之前配置过，但目前都已关闭。告知用户当前没有信号流入。你可以直接通过 inbox-source-configs-partial-update { "id": "<source_config_uuid>", "enabled": true } 重新启用某个来源（请先征得用户同意），用户也可以在项目的 signals 设置中将其开启。不要费心查找报告 — 任何现存报告都已过时。

情况 C — 至少有一个源配置为 enabled: true

配置看起来正常。如果 inbox-reports-list 仍未返回任何内容，最可能的原因是“还需要一些时间” — 信号正在流入，但尚未聚类成报告。简要告知用户这一点，列出当前启用的来源（例如“你已启用 GitHub 和错误跟踪”），并提出稍后再查看，或切换到 signals 技能查看原始信号量。

如果任何源配置的 status: "failed"，请在回复中指出 — 该来源目前无法产生信号，这可能导致 Inbox 内容较少。

步骤 2 — 然后再处理用户的实际问题

如果步骤 1 发现配置正常且至少有一份报告，请继续执行下面的分诊 / 深入调查 / 筛选工作流。

工作流：分诊并确定可采取行动的事项

当用户询问“我该关注什么？”或“哪些事项可以采取行动？”时：

步骤 1 — 获取待处理 / 进行中的队列

inbox-reports-list
{
  "status": "ready,in_progress,pending_input",
  "limit": 20
}

如果返回 count: 0，请先跳转到上面的空内容 / 未配置工作流，再告知用户“Inbox 为空” — 应如何回复取决于是否配置了信号源。

已认领的报告会保留其流水线状态，因此此队列也会返回其他人已经负责的工作。用户询问有哪些事项可以接手时，添加 "unclaimed": true；如需列出调用者已经负责、可能想要继续处理的事项，则添加 "assignee": "me"。

步骤 2 — 按来源和可执行性汇总

对于每份报告，响应包含：

• id、title、summary
• status、priority、actionability（注意：对于仍处于 pending_input / candidate 状态的报告，此值为 null——尚未进行判断）
• signal_count、total_weight — 驱动报告的底层证据量
• source_products — 底层信号来自哪些产品
• is_suggested_reviewer — 当前用户是否是该报告的推荐审阅者（参见上文“‘推荐审阅者’的含义”——根据相关代码的 GitHub 提交作者身份，并通过关联的 GitHub 身份映射到 PostHog 用户）
• pull_requests — 是否已针对该报告创建 PR
• work_state — unclaimed、working、in_review 或 done
• assignee — 认领该报告的人（用户、内部任务或外部 Agent）；如果无人认领，则为 null 列出由其他人负责的报告时，请说明这一点，避免让它看起来像是待认领的工作
• _posthogUrl — 指向报告的可点击深层链接；在响应中务必始终包含此项

对结果进行分组，方便用户快速浏览。优先列出 is_suggested_reviewer: true 的报告——这些报告与当前用户编写的代码相关联——然后再按优先级对其余报告分组：

## Inbox — 8 actionable reports

⭐ Suggested for you (1)
- Checkout error rate spiked 3× — error_tracking, 47 signals (you're a suggested reviewer)
  <_posthogUrl>

🔴 High priority (2 more)
- Session replays on /pricing show repeated rage clicks — session_replay, 12 signals
  <_posthogUrl>
…

🟠 Medium priority (4)
…

如果没有任何报告的 is_suggested_reviewer: true，请在列出其余报告之前明确说明——不要默默省略这一部分。

步骤 3 — 提供深入查看选项

以明确的后续选项收尾：“要我深入查看结账错误吗？” → 调用 inbox-reports-retrieve 获取完整报告，然后可选择切换到 signals 技能，查看底层信号文本。

工作流：深入查看特定报告

当用户粘贴 Inbox URL 或报告 ID 时：

inbox-reports-retrieve
{ "id": "<report_uuid>" }

返回包含 signals_at_run 和 artefact_count 的完整记录。然后读取报告的工作日志：

inbox-report-artefacts-list
{ "report_id": "<report_uuid>" }

这会返回报告的证据（signal_finding）、其状态／优先级／可执行性背后的判断（safety_judgment、actionability_judgment、priority_judgment、 repo_selection、suggested_reviewers），以及工作日志（commit、task_run、note）——通过一次只读调用，查看精编的“报告存在的原因及已完成的工作”。

只有在需要查看精编发现之外的原始信号文本时，才使用 signals 技能：

1. 使用 inbox-reports-retrieve 获取报告元数据和 id
2. 使用 inbox-report-artefacts-list 获取精编证据、判断和工作日志
3. 仅当需要查看底层原始信号文本时，使用 signals 技能的示例 2（获取特定报告的所有信号）——在 HogQL 查询中将报告 ID 作为 metadata.report_id 传入

这些层次相辅相成：inbox-report-artefacts-list 提供精编／判断后的视图（证据 + 判断 + PR／任务运行历史），而 signals 技能则可让你检查生成这些内容的原始观察结果。

工作流：处理可执行的报告

当用户想要对报告采取行动——“修复这个 Inbox 条目”“将它转成 PR”“实现这个”——而不只是阅读时。处于 ready 状态且 actionability: immediately_actionable 的报告通常是合适的候选项。这里需要遵循的准则是： 报告只是诊断，并非事实依据——实施之前，请对照实际代码进行核实。 对于来自 signals_scout（以及任何 LLM 研究来源）的报告，尤其值得再次核查；它们的 summary 往往会以肯定的语气描述根本原因，并列出文件名和函数名，但内容可能已经过时或不正确。

第 1 步 — 获取报告、检查已有工作并认领

inbox-reports-retrieve
{ "id": "<report_uuid>" }

开始任何工作前，请先查看：

• already_addressed — 如果为 true，修复可能已在进行中或已合并；请先与用户确认，再决定是否重复处理。
• pull_requests — 在创建新的 PR 前先检查现有 PR；一份报告可能对应跨仓库的 PR，或由多个 PR 组成的 PR 栈。
• work_state 和 assignee — 用于确认是否已有其他人接手。允许接手，但应有意识地进行，而不是忽略正在进行的工作。
• status — 只有 ready 报告才有已完成的判断。candidate / pending_input 报告尚未经过研究；不要根据尚未完善的摘要直接实现。

开始研究或实现之前，请先认领报告：

posthog:inbox-reports-claim
{ "report_id": "<report_uuid>" }

保存返回的 assignee.claim_id，并在后续的工作更新和产物写入中传入该值。 接手其他执行者的工作需要设置 takeover=true；过期的认领 ID 会被拒绝。 认领归属于当前内部任务或外部 MCP 客户端。认领不会过期，因此如果你离开时尚未提交修复，请务必释放报告，包括驳回报告时。释放操作只会清除所有权；已关联的拉取请求仍会保留在报告上。无论报告处于何种状态都可以释放，因此也可以释放已驳回的报告。

第 2 步 — 对照代码验证诊断（不可跳过）

先阅读报告的工作日志，了解其中的证据及其背后的判断：

inbox-report-artefacts-list
{ "report_id": "<report_uuid>" }

这会展示 signal_finding 证据、状态／优先级／可执行性判断，以及任何 commit / task_run 历史记录——这些正是你在修改代码前需要了解的“问题为何存在，以及已经做过什么”。随后，报告的 summary 会列出文件、函数，有时还会提供行号。打开这些内容并确认报告的说法成立——检查引用的代码是否存在、是否仍如报告所述，以及是否确实会导致所描述的故障。如需更深入地核查，可通过 signals 技能（metadata.report_id）获取底层原始信号，以查看整理后的发现背后的信号文本。如果诊断经不起核实，请说明原因并停止——错误的报告本身也是有用的发现（也可能适合在下文中选择 dismiss），但这并不意味着可以据此编写未经证实的修复方案。停止前，请释放你在第 1 步中认领的报告，这样报告就会回到未认领视图，而不会看起来像是有人正在处理、实际上却无人跟进：

posthog:inbox-reports-claim
{ "report_id": "<report_uuid>", "claim_id": "<claim_uuid>", "release": true }

第 3 步 — 将修复限定在正确的层

• 如果 source_products 包含 signals_scout，且根本原因在于侦察器自身的行为（例如它使用的提示词或阈值），通常更好的修复位置是侦察器的 SKILL.md，而不是执行框架。请注意，各团队自定义的侦察器位于用户的 Skills Store 中，而非此代码库，因此修复位置可能无法通过代码库 PR 触及——请告知用户。
• 否则，请将其视为常规变更：遵循代码库的约定（CLAUDE.md、特定领域的技能），尽量精简改动，并添加能够捕获所报告故障的回归测试。

步骤 4 — 创建 PR 并附加到报告

按照仓库的 PR 规范创建 PR，然后将其附加到报告：

posthog:inbox-reports-claim
{
  "report_id": "<report_uuid>",
  "claim_id": "<claim_uuid>",
  "pull_requests": ["https://github.com/example/repository/pull/123"]
}

PR 链接会累加添加，重试不会重复添加。请一次性发送所有已知 PR，以便完成状态能考虑整个 PR 堆栈。同一个 PR 可以附加到多个报告。已连接的仓库会立即验证状态并更新 Webhook。未连接仓库的 PR 也会被接受，但状态未知，因此工作合入后，请手动解决这些报告。此外，请在 PR 描述中引用报告的 _posthogUrl，以便从任一侧追踪整个流程。

不要因为创建了 PR 就解决报告。 只有当所有关联的 PR 都已关闭或合并，且至少有一个 PR 已合并时，报告才会解决。如果所有 PR 都已关闭但没有合并，报告将被抑制。任何处于打开、草稿或状态未知的 PR，都会阻止自动完成。在 PR 刚打开时手动解决报告，等于声称工作已落地，而查看收件箱的审核者无法分辨这种情况。手动解决适用于 PR 合并无法涵盖的修复，例如技能正文变更、配置变更或 NO_REPO 报告——请参阅下方的工作流。

工作流：对报告执行操作

报告可能会提供可启动 Agent 运行的操作，与收件箱中以按钮显示的操作相同：让它合并（get_it_merged）会修复报告中已打开且获批的拉取请求中的 CI 问题，并将其合并；每个建议的提示词（suggested_prompt）会发送一条报告建议的提示词。请使用这些操作，而不要使用 tasks-create-and-run：在这里启动的运行会关联到报告，因此会显示在报告的运行记录中、计入报告的任务限额，并遵循报告的代码访问规则。这两个工具正在通过功能标志逐步推出，因此可能不会出现在你的工具列表中。如果没有，请让对方前往报告的 _posthogUrl 点击按钮。

步骤 1 — 列出操作

posthog:inbox-report-actions-list
{ "report_id": "<report_uuid>" }

每个操作都会返回，无论是否可用。请选择一个 available: true 的操作。操作不可用时，disabled_reason 会说明原因（例如，没有已获批的打开 PR、未批准 AI 数据处理等）：请告知对方，而不是尝试运行该操作。text 是运行收到的首条请求，因此如果对方想知道会要求 Agent 做什么，请向其展示。

步骤 2 — 确认后运行

启动运行会创建一个任务，并消耗组织的用量；“让它合并”还可能合并拉取请求。在运行对方未明确点名要求的操作之前，请先征得对方确认。

posthog:inbox-report-actions-run
{ "report_id": "<report_uuid>", "action": "suggested_prompt", "suggested_prompt_index": 0 }

仅对 suggested_prompt 传入 suggested_prompt_index，并使用列表中的值。201 响应会返回 task_id、run_id 和 task_url。每次成功调用都会创建一个新任务，因此不要重试。如果设置了 run_error，说明任务已创建，但运行未启动：请报告错误，不要再次启动。

步骤 3 — 跟进运行

运行会在后台进行。使用 task_id 和 run_id 调用 tasks-runs-retrieve 跟进，并将 task_url 提供给对方。后台运行中无人能回答问题，因此 Agent 需要决策时，会在报告的工作日志中写入备注。使用 inbox-report-artefacts-list 读取新备注。

错误

每种拒绝都会附带一个 code。不要以相同方式重试。

状态	code	处理方法
400	report_action_unavailable	当前无法执行此操作。将 detail 告知对方。
403	report_action_unavailable	组织尚未批准 AI 数据处理。管理员可在设置中启用此功能。
403	report_action_sandbox_refused	任务沙箱无法启动报告操作。请人员从自己的会话中启动。
409	report_action_run_active	已有合并运行正在处理该报告。请根据响应正文中的 task_id 和 run_id 跟进。
429	signal_report_task_cap	报告已达到任务上限。请处理现有运行。
429	throttled, usage_limit_exceeded	已触发个人或组织的使用量限制。请等待限制解除。
402	self_driving_free_trial	该组织正在使用 Self-driving 免费试用版，无法创建拉取请求。
404	无	该索引处没有报告建议的提示词。请重新列出操作并使用新的索引。

工作流：解决、忽略或暂缓报告

三种结果，一种工具。根据底层问题的实际处理情况选择：

问题……	状态	原因
已通过你所做的工作修复	resolved	终止状态；报告已完成其使命
并非真实问题，或不值得修复	suppressed	已从收件箱中忽略，并记录原因
问题真实存在但暂缓处理，或已通过其他方式修复	potential	重新进入处理流程；问题再次出现时会重新显示

inbox-reports-set-state
{
  "id": "<report_uuid>",
  "state": "suppressed",
  "dismissal_reason": "analysis_wrong",
  "dismissal_note": "Verified against products/foo/bar.py — the cited code path can't reach this state."
}

• state: "resolved" 表示请求的工作已完成，且为终态——问题再次出现时会创建一份新报告，而不是重新打开这份报告。可从 ready / pending_input 状态转换，也可从归档时处于上述任一状态的 suppressed 报告转换；其他情况均返回 409。**仅在工作确已完成时才解决报告。**修复以 PR 形式提交后，会在合并时自动解决报告（见 Step 4）；只有在 webhook 无法触达的情况下才手动解决，例如编辑技能正文、修改配置或处理 NO_REPO 报告。此类情况请记录 dismissal_reason: "fixed_outside_posthog"（修复已完成，但未通过拉取请求提交）；如果包含修复内容的拉取请求已合并，但报告未自动解决，请使用 pr_merged；仅当问题在报告提交前就已修复时，才使用 already_fixed。如果是_你_完成了修复，请勿同时使用 already_fixed 和 state: "potential"：这种组合表示“由其他方式修复，可能再次出现”，因此报告会重新出现。
• state: "suppressed" 会将报告从收件箱中移除；state: "potential" 会将报告暂缓处理并放回工作流。暂缓时，snooze_for: <N> 会让报告保持暂缓状态，直到累计收到 N 条新信号。
• dismissal_reason 必须使用服务端验证的规范代码之一：already_fixed、report_unclear、analysis_wrong、wrong_assignee、wrong_repo、wontfix_intentional、wontfix_irrelevant、fixed_outside_posthog、no_action_needed、pr_merged、other；未列出的值会返回 400。对于不符合特定代码的情况，请使用 other 并附上 dismissal_note。dismissal_note 可自由填写（≤ 4000 个字符）。二者都会作为 DISMISSAL 记录持久保存，因此后续状态转换时仍会保留理由——解决报告时也务必填写，以便后续查看者了解_原因_。
• wrong_repo 表示 Agent 针对错误的代码仓库调查了报告。请同时填写 corrected_repository（"owner/repo"，不区分大小写；仅此原因允许填写），并指定正确的代码仓库：该更正会记录在驳回信息中，并用于此项目今后的每次代码仓库选择；若指定的代码仓库已连接到此项目，它也会成为此报告下一次选择的代码仓库。如果未提供可用的更正信息，系统会清除报告的代码仓库选择，因此恢复报告时会重新选择，而不会沿用被否决的代码仓库。
• wrong_assignee 表示报告被分派给了错误的个人或团队。这是路由反馈，并不表示报告本身有误。
• 驳回、暂缓或恢复报告时，dismissal_note 也会作为引导备注转发给提交该报告的 scout，供每次 scout 运行时在冷启动阶段读取；因此，你在此处填写的内容决定了如何避免再次提交同一份报告。请面向该读者撰写：指出能够定论的证据，而不只是给出结论。解决报告不会转发备注，因为这表示报告已完成其作用，而非提交报告有误；该备注只会保留在报告上。即使没有备注，wrong_repo 驳回也会转发：引导备注会指出报告错误针对的代码仓库，以及你提供的 corrected_repository（如果有）。转发需要与手动添加 scout 备注相同的技能编辑权限，因此，如果你对某个项目没有此权限，备注仍会记录在报告上，但不会传达给 scout。
• 这是一个有破坏性且不可幂等的状态转换；如果当前报告状态不允许此操作，将返回 409（如果 dismissal_reason 不是规范代码，则返回 400）。抑制报告前请先征得用户确认，并在备注中说明_原因_——不附理由的驳回比不驳回更糟糕。因诊断有误而被你驳回的报告（上文 Step 2）就是典型情况：使用 analysis_wrong 抑制报告，并在备注中说明证据。退款报告处于冻结状态：暂缓和解决操作都会返回 409 / skipped，并附带说明性 detail。
• 如需一次转换多份报告，请使用 inbox-reports-bulk-set-state，并传入 ids 数组（1–100）。该操作会对每个 id 应用相同的 state / dismissal_reason / dismissal_note / corrected_repository / snooze_for，并按请求顺序返回每个 id 的 results 列表，以及 transitioned_count / skipped_count / failed_count / not_found_count 汇总。每个 id 都会独立处理，因此即使部分操作失败，调用仍会返回 200——不允许转换的 id 会返回 skipped（等同于单份报告操作中的 409），其余 id 则会继续处理。请检查每个 id 的结果，不要假定整个批次都已成功。

工作流：按主题或来源筛选

“有没有关于 的报告？”——从 search 开始：

inbox-reports-list
{
  "search": "checkout",
  "status": "ready,in_progress,pending_input",
  "limit": 20
}

search 会匹配标题和摘要。如果用户询问的是某个产品领域，而不是关键词，请使用 source_product：

inbox-reports-list
{
  "source_product": "session_replay,error_tracking",
  "limit": 20
}

如果关键词搜索没有返回有意义的结果，请转交给 signals 技能——通过 embedText() 对信号文本进行语义搜索，可以找到关键词筛选遗漏的报告。

将模型预测作为构建模块

收件箱排序模型会预测每份报告的结果。inbox-reports-list 和 inbox-reports-retrieve 的每一行都会在 ranking 中包含这些预测：

"ranking": {
  "status": "scored",
  "scored_at": "2026-10-24T05:12:00Z",
  "predictions": [
    { "outcome": "open", "probability": 0.21, "lift": 1.5, "readable": true },
    { "outcome": "action", "probability": 0.09, "lift": 1.4, "readable": true },
    { "outcome": "fix", "probability": 0.3, "lift": 2.7, "readable": true }
  ]
}

• open：有人打开报告。action：有人或其 Agent 根据报告采取行动。fix：有人修复报告所描述的问题。调用 inbox-ranking-outcomes-list，了解每个结果当前的含义、时间范围和基准率，因为这些信息随所部署的模型而定。
• 预测说明的是可能发生什么，而不是已经发生了什么。较高的 fix 概率不代表报告已修复：请查看 status 和 PR 字段来确认。
• 提升率是概率除以该结果的基准率。1.0 表示平均水平的报告，2.7 表示可能性是 2.7 倍。比较不同结果的提升率。原始概率无法直接比较，因为每个结果都有自己的基准率。
• readable: false 表示训练运行无法测量该结果的留出集 AUC。谨慎使用该结果进行排序和筛选。
• status 的值为 scored、stale（标题或摘要在评分后发生变化，因此预测对应的是旧文本）、unscored（尚无评分，这不代表评分较低）或 not_available（用户无法查看排序模型，因此按模型进行排序和筛选会返回 400）。
• inbox-reports-retrieve 还会标明生成预测的 model。不同模型的预测不可比较。

常用方案：

• 可能会得到修复的报告：使用 view=actionable 和 ordering=-ranking_fix。
• 隐藏的优质报告：使用 priority=P3,P4 和 ranking_min_lift=fix:2。
• 可能是噪声的报告：三个结果的提升率都较低的报告，可以考虑合并重复项或驳回。采取行动前请先阅读报告：低提升率只是提示，不是定论。
• 在任何方案中添加 search 或 source_product，即可缩小到特定主题。

ranking_min_lift 和 ranking_min_probability 接受以逗号分隔的 <outcome>:<value> 对，并要求报告满足每一对条件。未评分和已过时的报告始终不匹配。

注意事项：

• 这些预测是模型估算值，且高端区间会高估。请用它们进行排序和筛选，不要将其视为实际赔率。
• 大多数 fix 正例也是 action 正例，因此不要将二者相加。

工作流：查看已配置的来源

当用户询问“设置了哪些信号来源？”或“ 接入了吗？”时：

inbox-source-configs-list
{ "limit": 50 }

每个条目都会返回 id、source_product、source_type、enabled、status 以及时间戳。 如需完整详情（包括每个来源的 config JSON——记录筛选条件、评估 ID 等）：

inbox-source-configs-retrieve
{ "id": "<source_config_uuid>" }

集成凭据保存在单独的 Integration 模型中——它们不在 config 内容里，因此可以放心向用户概述其中的内容。

status 字段反映底层数据导入或工作流的状态：

• running / completed — 正常输送信号
• failed — 该来源目前未生成信号；请向用户指出这一点

如需启用或停用来源，请使用 inbox-source-configs-partial-update，并传入配置的 id 和 { "enabled": true | false }——只会更改传入的字段，因此这是执行简单开关操作的正确工具（-update 会替换整条记录；-create 会创建新的来源）。更改来源前请先征得用户确认，因为启用来源会触发信号处理并产生费用。

inbox-source-configs-partial-update
{ "id": "<source_config_uuid>", "enabled": false }

提示

• 在假设收件箱为空之前，先检查设置。 如果 inbox-reports-list 返回 count: 0， 请先调用 inbox-source-configs-list——没有来源意味着用户需要安装 PostHog Desktop 才能开始接收信号；有来源但没有报告， 则意味着信号正在流入，但尚未聚类
• 始终显示 _posthogUrl，以便用户可以点击查看报告
• 默认排序已优先显示用户建议的报告——除非用户提出要求，否则不要重新排序
• 对于仍处于 pending_input 或 candidate 状态的报告，priority 和 actionability 为 null；这是预期行为，并非错误——尚未进行判断
• 默认不包含 suppressed 报告。传入 view: "dismissed" 可查看被用户驳回的报告，传入 view: "held_back" 可查看被裁定器暂缓的报告，或传入 status: "suppressed" 查看两者。 在说明报告为何离开收件箱之前，先读取 suppression_source
• 通过 MCP 暴露的收件箱写入操作包括 inbox-reports-set-state（解决／驳回／暂缓单个 报告）、inbox-reports-bulk-set-state（对 1–100 个报告执行相同操作）、inbox-reports-claim （认领／释放／关联 PR）以及 inbox-source-configs-partial-update（切换来源的 enabled 标志）。要对报告采取 行动（实现修复），请先认领报告，根据代码核实诊断，然后创建并关联 PR——参见 工作流：处理可采取行动的报告。基于 PR 的修复会在 PR 合并时自动解决，因此不要在 PR 刚创建时手动解决报告。始终也要显示 _posthogUrl 深层链接
• 绝不要直接根据报告的 summary 实现修复。 报告——尤其是 signals_scout 报告——属于大模型诊断；编写修复前，请在实际代码中确认所引用的文件／函数／行为。经核实不成立的报告应考虑驳回，而不是修复
• 对于“有哪些类型的信号？”或“所有来源最近发生了什么？”， 请切换到 signals 技能——报告层会隐藏单条观察结果；你需要查询 document_embeddings 中的 HogQL 才能看到它们
• 来源配置没有单条记录的深层链接——它们位于项目设置中，因此 inbox-source-configs-retrieve 不会返回 _posthogUrl。不要将它们与报告混淆