working-with-scouts

与 Signals 探查器协作

探查器是一种按计划运行的 Agent，会按自己的时间间隔自动唤醒，查看一个 PostHog 项目，然后将发现作为报告写入 Signals 收件箱，或在没有发现时结束运行。 可以把这支队伍想象成一群你聘来替你留意情况的初级分析师：他们无人值守地工作，坚持较高的证据标准，而且——至关重要的是——与你合作得越多，他们就越出色。 你写下的每条驳回理由、留下的每条备注、采取行动的每份报告，都会反馈到他们接下来的工作中。

本技能是这段协作关系的操作手册：如何委派监控任务、如何处理收到的结果，以及如何引导这支队伍逐渐聚焦于团队真正关心的事项。 三个相关技能介绍了具体操作流程——下方的工作流移交时，请参考它们：

技能	涵盖内容
authoring-scouts	编写、编辑和调整探查器：技能正文、配置、备注的写入端、测试循环
exploring-scouts	只读可观测性：探查器队伍列表、运行历史、暂存区记忆、健康状况评估
inbox-exploration	收件箱本身：对报告进行分类、深入查看、采取行动，以及解决／驳回／延后处理

首先：这支 scout 队伍正在运行吗？

不要把任务委派给一支并不存在的队伍。 读取两项信息即可确认：posthog:scout-metadata-get 会说明项目是否已加入并启用 scouts；posthog:scout-config-list 会列出名册——每个 scout 占一行，包含其计划、enabled、emit 状态和description。 无论名册显示什么，都先检查是否已加入——配置行在退出后仍会保留，因此已停止运行的项目可能还留着一份启用状态的 scout 名册，但这些 scouts 实际上不会运行（如果所有条目的 last_run_at 都已过时，就是明显的信号）。 （Scout 工具最近从 signals-scout-* 重命名为 scout-*；如果 scout-* 名称返回未知，请尝试旧的 signals-scout-* 名称。） 这里所有操作都遵循同一条访问规则：scout 行位于项目的规范父项目中，因此每次 scout 读写操作——包括读取这份名册，以及下面的笔记和配置调整——如果凭证仅限于子环境，都会返回 403；请从父项目操作（或使用有权访问该项目的凭证）。

• 尚未加入 — 引导用户前往 Signals scout 设置或 PostHog Desktop 完成引导，不要凭空捏造活动记录。
• 已加入，名册为空 — 很可能是刚加入，正在等待协调器首次运行（届时会自动注册配置）；应如实说明，而不是让用户重新走一遍引导流程。
• 已加入，存在名册条目 — 说明每个 scout 的 enabled、emit（false = 试运行：会运行，但不会写入任何内容），以及 status / pause_reason。 在深入排查之前，scout 已暂停或处于试运行状态，通常就足以解释大多数“scouts 什么都没做”的反馈。 还要检查 posthog:scout-project-profile-get 上的 summary.emit_eligibility（如果只需要检查是否满足条件，请传入 summary_only=true）。当 can_emit 为 false 时，scout 的写入无法到达收件箱。在承诺覆盖范围之前，先展示其 remediation。blocking_reason 用于标识阻止条件：ai_processing_not_approved 或 source_disabled 适用于团队中的所有 scouts。scout_emit_disabled 则适用于单个 scout 的试运行设置。该 scout 会继续调查，但不会发出发现或报告。在运行之外调用工具时，返回的是团队级别的结果；传入 run_id 可检查单个 scout 的写入资格。 （对于只读调用者，profile 是由 scout 运行生成的缓存快照，因此 404 表示没有新鲜的 profile，而不是不符合资格；请改为通过 posthog:inbox-source-configs-list 检查 signals_scout 来源配置，并将资格视为未知，而不要因 profile 而阻止操作。）

每一行的 description 都会说明该 scout 负责监控什么——扫描这些内容即可回答“哪个 scout 负责 X？”，无需加载任何技能正文。 （description 为空的行通常是孤立条目，相关技能此前已被删除——它无法运行，因此不要将其计入覆盖范围。） PostHog 为大多数产品领域都提供了专用 scout（错误跟踪、日志、Web 分析、AI 可观测性、实验、功能标记、会话回放、调查、收入等），还提供了一个跨产品通用 scout；团队也可以添加自定义 scouts（任何技能名称都可以；只有 signals-scout- 前缀会触发配置自动注册，因此名称不同的 scout 会通过 posthog:scout-create 创建）。 每一行还包含 scout_origin（canonical 或 custom），用于区分由 PostHog 提供的 scout 和团队编写的 scout。但它无法告诉你某个规范 scout 是否已在原位编辑并偏离上游版本：该行仍会显示为 canonical。如果需要确认偏离情况，请将该行正文与 PostHog 仓库中的规范来源（products/signals/skills/<skill>/SKILL.md）进行比较；posthog:skill-get 返回的是团队正在使用的当前行，也就是编辑后的副本。

工作循环

此技能中的所有内容都是一个持续运行的循环：

1. 委派 — 决定需要监控什么，并安排合适的侦察器进行监控。
2. 接收 — 报告会送达收件箱；如果侦察器能指定合适的审核者，报告就会转交给该审核者。
3. 处理 — 核实发现，修复问题（或决定不修复），并在报告中记录结果。
4. 反馈 — 处理结果和你写下的理由，以及你留下的任何备注，都会反馈给侦察器。
5. 校准 — 定期检查团队运行状况，并将反复出现的指导意见提升为永久策略。

最重要的习惯：绝不要让报告无人处理。 处理报告——哪怕是说明理由后将其驳回——才是在训练团队。如果某个侦察器收件箱中的报告一直无人处理，系统会自动向你发出警告，随后暂停该侦察器（pause_reason=ignored；通过 Slack 投递的侦察器除外，因为无法衡量其报告是否已被查看）。 无人管理的收件箱不仅会逐渐失效，还会导致整个团队停止运行。

委派任务

需要监控某项内容时，选择能实现监控的最省力方式——大多数任务都不需要新建侦察器：

情况	操作
已有一个标准 scout 覆盖该范围	无需创建：确认已启用；如果想让它关注某个具体方向，可以给它留一条备注。
该范围已有覆盖，但你想设置临时或特定的关注重点	留一条备注（可选填 expires_at）：“本周关注欧盟注册漏斗”“我们周二上线了新版结账流程，之后的变化都是预期之内”。
已覆盖该范围的 scout 总是漏掉（或过度报告）某些结构性内容	调整它：通过 authoring-scouts 修改排除条件、阈值或范围。若只是要增加行为，优先创建一个名称不同的新 scout，因为编辑标准 scout 的条目会将其标记为已分歧，并阻止上游改进。
没有 scout 覆盖该范围（自定义事件、小众漏斗、外部系统）	通过 authoring-scouts（posthog:scout-create）编写自定义 scout。在收件箱的 scouts 选项卡中，“为此项目推荐”栏会根据项目自身的数据推荐 scout；“推荐 scout”会打开一个聊天窗口来起草 scout。自定义推荐会调用同一个创建接口；标准推荐则是一个已关闭的现有 PostHog scout，因此接受它会启用该配置，而不是创建新的 scout。
你想要的是周期性指标，而不是报告：一种无法通过查询计算的主观质量／分类评分	在结构化输出通道上编写测量型 scout：它每次运行都会评估一个样本，并记录经架构验证的 $scout_structured_output 事件，供你在洞察中制图（工作流也可以据此采取行动）；只有发生重大变化时才会提交报告。请参阅 authoring-scouts 中的周期性测量／LLM 评判模式，以及 signals-scout-mcp-tool-calls 中已发布且会记录此类事件的 scout（其 references/metrics-dashboard.md 提供了图表配置方法）。
你只想要一个即时答案	完全不要使用 scout：直接查询数据即可。scout 用于持续监控，不适合一次性问题。
references/delegation-recipes.md 收录了常见需求的实用方案——监控刚上线的事件、在限定时间内监控漏斗、生成每日日报、监控外部状态页、减少嘈杂的设备群等。

两条值得采纳的委派习惯：

• 先用真实数据验证任务。 在让侦察 Agent 关注某个事件或界面之前，先确认它确实存在（posthog:scout-project-profile-get、posthog:read-data-schema），并确认它有一定的数据量（用 posthog:execute-sql 对近期时间段快速计数——项目资料和架构工具不会返回新事件或罕见事件的计数）。监控项目根本没有采集的数据，注定会失败。
• 明确说明哪些情况值得打断人类。 侦察 Agent 设有报告门槛（“你会从头到尾负责跟进这项发现吗？”）；“告诉我任何有趣的事情”这种指示会产生噪声，而“如果结账转化率下降且进入人数保持稳定，请告诉我”则能产生有效信号。

处理返回结果

报告分流机制详见 inbox-exploration；这里的重点是，采取行动本身也是一种引导。

• 实现前先核实。 侦察报告是大模型的诊断结果，不是真相来源——修复前，请根据实时数据或代码确认报告中提到的实体和行为。 如果报告经不起核实，可以将其驳回，而要_妥善地_驳回报告本身就是有价值的工作（见下文）。
• 如实标明每份报告的最终状态：工作已完成时标记为 resolved（有 PR 支持的修复会在合并时自动解决——不要在 PR 刚打开时就标记解决）；若问题并不存在或不值得修复，则标记为 suppressed（已驳回）；若问题确实存在但暂缓处理，则标记为 potential（已搁置）。
• 驳回备注是引导信息。 驳回、搁置或恢复报告时，dismissal_note 会转发给提交该报告的侦察员，之后每次运行都会将其作为先前上下文读取。以 wrong_assignee 或 wrong_repo 为由驳回时，即使没有备注也会转发，因为原因本身就是路由反馈。 写备注时要考虑接收者：说明能确定问题的证据（“暂存环境的流量——主机名符合 *.dev.example.com，忽略此模式”），而不只是给出结论。 写得好的驳回备注是你能做的成本最低的侦察员调整；光秃秃地驳回不会带来任何经验，报告还会再次出现。 有两点需要注意：转发尽力而为，且要求驳回者在规范项目中拥有侦察员引导（技能编辑）权限；此外，在子环境的报告上执行驳回绝不会转发。在这两种情况下，备注仍会写入报告，但永远不会送达侦察员。因此，若要确保引导信息生效，请确认侦察员已收到（使用 posthog:scout-notes-list，并提供同时拥有 task:read 的凭据，因为没有该权限时衍生备注会被隐藏），或请获授权的人直接留备注。 转发的备注也会在约 30 天后过期——只有侦察员将其纳入 scratchpad 记忆后，备注才会持久保留。因此，若引导信息必须长期有效，应通过技能编辑向上级传递。
• 还有三种收件箱操作也会以同样方式提供引导信息。 在报告的“讨论”框中输入问题、为报告评分时留下备注，以及添加或移除建议审阅者，都会生成侦察员备注（可在 posthog:scout-notes-list 中查看，其 origin 分别为 report_discussion、report_feedback 或 report_reviewer_correction）。 审阅者更正是整个侦察员集群能收到的最强路由证据：它会送达提交或编辑该报告的侦察员，以及 reviewer: 记忆中提到已移除登录名的侦察员（每次更正最多通知 20 个目标，因此报告非常繁忙时可能会漏掉一些）。因此，直接更正路由错误的报告，可以让整个集群知道谁负责该领域。 转发的备注会包含 GitHub 登录名，且只有更正者在规范项目中拥有技能编辑权限时才会生成。因此，没有该权限时所做的更正，或仅添加、移除没有关联 GitHub 账号的 user_uuid 审阅者，都只会保留在报告中，不会转发。 讨论和评分路径要求完整的备注写入授权（技能编辑权限以及 signal_scout:write / llm_skill:write 密钥作用域），所以没有该权限的人输入的备注不会转发：讨论问题仍会保留在报告的讨论串中，但评分备注只会保留在分析事件中。若备注必须送达侦察员，请获授权的人将其作为侦察员备注留下。
• 解决报告并非终点——检查项会衡量修复是否有效。 检查项是侦察员（或报告流水线）附加到报告上的后续测量：一项预期结果，以及测试时间。报告解决后，计时开始；经过一段观察期（默认 24 小时；对于影响用户较慢的修复，例如移动应用发布或缓存的客户端程序包，观察期会更长）后，系统会重新测量，并将结果写入报告。这样，“这真的奏效了吗？”就会成为存储下来的事实，而不是某个人必须记得重新推导的事情。 这会改变你工作方式的三点：
  • 宣布完成前，先查看已解决报告的检查项。 posthog:inbox-report-checks-list 会显示每个检查项的 status 和 last_outcome。检查项仍处于未完成状态，表示结果即将得出，因此无需手动重新测量。查看这些记录是 exploring-scouts 的职责。
  • 检查失败意味着修复未能持续生效，复发的问题会作为一份新报告提交，并关联到原已解决的报告，而不是重新打开原报告——已解决的报告已从收件箱中移除，因此那里不会有人查看。请将新报告视为当前待处理事项。
  • 如实解决报告，并在合并时解决。 过早解决后设置的检查日期，会测量修复发布前的时间窗口，因此可能会将实际有效的修复判定为失败。 检查项只能由侦察员运行和流水线编写；没有面向个人的创建入口。因此，如果已解决的报告应该重新测量却没有检查项，唯一的办法是引导侦察员——请留下备注，要求它附加检查项，或通过 authoring-scouts 编辑技能。
• 报告会分派给相关人员。 能识别出可能负责人的侦察员会设置 suggested_reviewers，收件箱会将这些报告置顶显示在相关人员的视图中。 审阅者是 PostHog 用户：侦察员可以通过 user_uuid 分派（任何组织成员均可，无需 GitHub 账号），也可以通过 github_login 分派（与成员关联的 GitHub 身份匹配）。两种方式匹配时，查看者的 is_suggested_reviewer 都会变为 true。 如果某个领域的报告总是没有路由到负责人或路由错误，这可以修正：直接更正报告中的审阅者（更正会像上文所述那样转发）、留下集群范围的路由备注（使用不带 skill_name 的 posthog:scout-notes-create，例如“将与计费相关的报告路由给 Dana”），或引导侦察员找到该领域的正确负责人（通过备注或技能编辑）。pipeline:report-research 备注只会引导流水线根据聚类信号生成的报告；直接编写报告的侦察员会自行设置 suggested_reviewers，不会读取该受众。

审计 scout 修改的内容

持有 write_scopes（通过 authoring-scouts 授予）的 scout 会修改项目中的实际对象，每项更改都会像其他编辑一样记录在项目的活动日志中。 日志行会标明 scout 的执行用户，即该次运行为其身份签发令牌的用户，并带有由服务器生成的 scout:<skill_name> 客户端标签。 该标签可识别 scout，但无法识别运行或它持有的权限范围。 要审计某次运行，仍需结合其时间窗口并与其结束说明交叉核对。

要还原某次运行所做的更改：

1. 读取运行记录（posthog:scout-runs-retrieve），查看 started_at、completed_at、metadata.write_scopes（仅当运行实际持有授权时才会出现）以及结束时的 summary。运行提示词要求获得授权的 scout 列出其修改的每个对象。
2. 检查历史记录是否可用。 有活动历史记录时，请遵循 MCP 提供的读取器指南。如果读取器不可用或访问被拒绝，请记录这一限制，并停止在该次运行中使用此读取器；不要重试其发现操作，也不要探测端点来绕过限制。其他已公布且获得授权的读取器（包括单个对象的历史记录）仍可使用。仅跳过没有可用读取器的检查。
3. 确认归属。 运行时间窗口可能包含执行用户的其他写入操作。若历史记录无法区分这些写入操作，就无法据此确定哪些更改是 scout 所为。
4. 与结束说明交叉核对。 说明中未提及的日志行，或说明声称发生但没有对应日志行的更改，都值得进一步查看。

每项获授权的权限范围会写入哪种 scopes 值：

获授权的写入权限范围	活动日志 scopes 值
notebook:write	Notebook
dashboard:write	Dashboard
insight:write	Insight
annotation:write	Annotation
alert:write	AlertConfiguration
warehouse_view:write	DataWarehouseSavedQuery、DataQualityCheck
warehouse_table:write	DataQualityCheck
llm_skill:write	PersonalAPIKey
canvas:write	Canvas
experiment:write	Experiment、FeatureFlag

某些授权也会影响名称未直接指明的对象：两个 warehouse 授权都会影响其主题下的数据质量检查；启动或暂停操作打开或关闭关联功能标志时，experiment:write 会影响该功能标志；而 llm_skill:write 会影响技能存储库的安装命令，该命令会签发或轮换执行用户的市场凭证。 权限范围名称所指的对象本身仍不会留下日志：技能正文编辑（包括其他 scout 的编辑）和仓库表写入都不会留下日志行，因此应改为查看技能的版本历史记录。 发布 canvas 也不会留下活动日志行。请查看 canvas 的版本历史记录：scout 发布的每个版本都会记录该运行的任务。

以下四个注意事项会影响结论的含义：

• 时间窗口不能作为归因依据。 如果没有侦察器标签，时间窗口可能包含执行用户的其他写入操作。即使有标签，同一侦察器的重叠运行也可能共用该标签。请结合收尾报告中的操作者、条目和时间戳进行比对。
• 历史记录访问是可选的。 权限、Cloud Audit Logs 权益和套餐的保留期限都可能导致无法访问历史记录。缺少历史记录并不能证明某次运行没有进行更改。请暂缓依赖历史记录的结论，并继续进行独立检查；已确认的访问限制不属于缺少工具的问题。
• 试运行不会持有授权。 当侦察器设置为 emit: false 时，它从不持有已授予的作用域，包括笔记本，因此不会在上表所列作用域下写入任何行。
• 团队回退运行只保留默认授权。 如果无法再解析侦察器的作者，运行将以另一名项目成员的身份执行，且只持有 notebook:write（前提是侦察器仍有此权限），因此它只能留下 Notebook 行，不会留下其他内容。
• 被拒绝的写入不会记录，因为它从未发生。 授权只是上限，执行用户自身的权限仍然适用，因此报告写入遭拒的收尾报告不会有对应行。这种对应关系符合预期，并非差异。

调整阶梯

想让侦察器改变行为时，请从成本最低、最不永久的方式开始，逐级向上——并停在足以解决问题的最低一级：

1. 回应其输出。 附上具体且有证据支撑的说明来驳回或暂缓处理，在讨论框中提问，附注评分，或修正其审阅者（这些内容都会自动转发给侦察器）。 适用场景：一份错误报告、首次出现的已知噪声模式、被错误分流的报告。
2. 调整单次运行（posthog:scout-run-now，并附带 note）。 适用场景：现在就想检查的一次性重点（“看看结账回归问题”），且不希望留下任何会被后续计划运行读取的内容。 此备注只会调整这次运行（最多 1,000 个字符），不会作为备注传递给后续运行；不过，后续运行读取历史记录时，它仍会显示在该次运行的元数据中，因此请将其表述为有日期的一次性事项（“仅限今天：……”）。它和任何手动运行一样，会占用每日额度；除 signal_scout:write 和项目的技能编辑权限外，还需要 llm_skill:write（否则会返回 403）。没有该权限的调用方仍可在不附备注的情况下运行侦察器。
3. 添加备注（posthog:scout-notes-create，适用于单个侦察器或整个侦察器群组，也可用 expires_at 设置有效期限）。 适用场景：有时效性的反馈、提示和背景信息——“你一直标记的峰值是已知噪声”“本周深入调查欧盟地区的注册情况”“新的结账流程已于周二上线”。 备注仅供参考：它们会引导关注方向，但绝不会降低证据门槛或强制生成报告。 将 skill_name: "pipeline:report-research" 设为目标，可调整管道如何研究、判断并分流其根据聚类信号构建的报告。侦察器撰写的报告不会经过这一阶段，因此，针对这类报告的分流规则应写在整个侦察器群组的备注中（不指定 skill_name），或单个侦察器的备注中。
4. 调整配置（posthog:scout-config-update）。 适用场景：调整它_何时以及是否_运行，以及_可以访问哪些内容_，但不适用于调整_调查什么内容_；降低过于活跃的侦察器的运行频率（run_interval_minutes；如果配置包含 run_cron_schedule，则以它为准，因此也要更新或清除它），暂停某个侦察器（enabled=false），让有风险的侦察器以干运行模式运行（emit=false），授予其外部访问权限（network_access=full），为代码侦察器提供只读代码库（repositories=["organization/repository"]），让刻意保持安静的监控侦察器免于自动暂停（auto_pause_exempt=true），除了收件箱外，还将其报告发送到 Slack 频道或私信（output_destinations.slack），或指定其使用的模型（model）。
5. 编辑技能正文，或编写新的侦察器（通过 authoring-scouts）。 适用场景：永久性策略——排除条件、阈值、范围变更、新的领域。 对于自定义侦察器，这是最强有力的调整方式：技能正文由你掌控，可以随意编辑——重复出现的备注和反复使用的驳回理由都应写在这里。 对于规范侦察器，同样的编辑会使其分叉：团队的副本会被标记为已分叉，此后 PostHog 的规范同步将不会再改动它，你也不会再收到该侦察器的上游改进——需要自行维护。 如果你想拥有某个侦察器，这种取舍可能值得；但对于纯粹的增量行为，最好编写一个名称不同的新侦察器，并让原有规范侦察器保持完整且持续维护。

将反复使用的调整提升为永久规则。 如果你总是重复添加同一条备注，或已三次写下同一个驳回理由，那就说明该内容应该编辑到技能中——将它沿阶梯上移到正文里，这样整个侦察器群组就不再依赖你反复提醒。 反过来也一样：在决定编辑之前，先尝试将提示写成备注。 备注维护仍由人工负责——侦察器从不删除备注，因此请移除已处理事项的备注（或提前设置 expires_at），以保持信息流的高信噪比。

你不在时，这支团队学到了什么

有些反馈循环会自动运行——了解它们的存在会改变你的工作方式：

• 便笺式记忆。 侦察器会写入持久的团队级记忆（基线、噪声模式、去重门槛、允许列表），并在多次运行中变得更安静、更精准。 如果侦察器不再标记某些内容，在假设它出问题之前，先检查便笺（查看 posthog:scout-scratchpad-search 中的 noise: / addressed: / dedupe: / allowlist: 条目）——它可能是有意学会了抑制这些内容。
• 自动暂停。 如果某个侦察器的报告无人关注——没有打开、没有评分、没有操作——它会先收到警告（status=pending_pause），然后被暂停（paused_by_system，pause_reason=ignored）。阅读也算关注，但目前只有云端 Web 收件箱会记录打开情况——通过其他客户端（桌面端、移动端）阅读的记录尚不会持久保存，因此如果侦察器的报告只在那里被查看，仍需设置 auto_pause_exempt。 只是安静的侦察器只会被标记，绝不会被暂停——保持安静可能正是它的工作；通过 Slack 发送的侦察器也会被排除，因为扫描过程无法看到报告在那里被查看。 重新启用本轮扫描暂停的侦察器后，它会恢复运行并获得新的宽限期，因此扫描会等待约两周，再重新判定并再次评估；对于不应由扫描评估的侦察器，请明确设置 auto_pause_exempt。
• 故障熔断器。 如果某个侦察器的定时运行持续失败，且故障时间超过十二小时中断所能解释的范围，就会被暂停并设置 pause_reason=repeated_failures，以免它每个周期都消耗一个沙箱。 阈值会随计划频率调整：失败次数需超过十二小时内可安排的运行次数，但至少为五次，且不超过二十五次。每日运行的侦察器在失败五次后暂停，按滚动每小时运行的侦察器在失败十三次后暂停；cron 计划会统计经过夏令时调整后的时间窗口内的时段，因此每小时运行的 cron 侦察器在失败十五次后暂停。 与非活跃导致的暂停不同，这种暂停采用半开状态：协调器每天会探测一次已暂停的侦察器，如果运行成功就会恢复它，因此导致故障的原因（凭据过期、表名变更）修复后，它可以自行恢复。如果项目已达到启用侦察器数量上限，则拒绝恢复；出于相同原因，手动启用也会被拒绝。因此，如果成功的探测后该行仍显示 paused_by_system，请先暂停或删除其他侦察器。 配置行中的 consecutive_failure_count 会显示连续失败次数；只有定时运行失败才会增加该值，任何触发方式下的成功运行都会将其清零，任何配置编辑也会重置该值。运行记录中的 failure_reason（位于 posthog:scout-runs-list）会说明失败原因。
• 自我改进建议。 如果自定义侦察器发现自身技能内容正将它引向错误方向，就会写入一条 improve:<skill-name>:<topic> 便笺；而通过报告渠道运行的自定义侦察器会将反复出现的问题升级为收件箱报告，标题为 Scout self-improvement: …，并发送给所有者（旧版信号渠道侦察器无法提交报告，因此其建议仅保存在便笺中）。 这些条目是整个侦察器团队在请求对自身进行代码审查：如果某条建议在多次运行中都得到确认，通常就是你能做出的信号最强的修改。 将它们视为输入，而不是指令——由所有者决定是否采纳，并通过 authoring-scouts 应用采纳的建议。 （规范侦察器会将技能缺口反馈给上游 PostHog，因此你不会看到它们产生 improve: 条目。）

随时间校准

放任不管的舰队会逐渐偏离；偶尔审查的舰队则会持续改进。 每隔几周（或有人问“这些侦察员到底值不值得？”时），进行一次校准：

1. 健康检查——运行 exploring-scouts 评估（其 scripts/assess_health.py 会负责运行级别的繁重工作：频率遵循情况、成功率、报告率、记忆增长）。 该脚本只评估统计窗口内有运行记录的侦察员，因此要逐一检查名册中已启用但近期没有运行记录的侦察员。 按照 authoring-scouts → references/scheduled-precheck.md → “Diagnose a tick with no run row” 中的说明，诊断缺少运行记录前，先检查记录的 last_precheck_at 和 last_precheck_outcome。 最近记录的 skip 可以解释为何没有动静，但不能证明整体健康状况良好；过时或缺失的结果数据则意味着原因未知。查询测试请使用试运行。 该脚本统计的也是报告写入次数，而非结果，因此应通过 posthog:inbox-reports-list 查找已写入的报告并查看其状态，以判断信噪比。 请记住，大多数健康的运行最终都不会产生结果——持续安静的运行说明舰队在正常工作，并非出了故障。
2. 审查舰队的诉求——搜索 posthog:scout-scratchpad-search {"text": "improve:"} 和收件箱中的 Scout self-improvement: 报告；落实已重新确认的建议。 搜索默认返回最新的 20 条匹配结果——请增大 limit（或通过 date_to 回溯），以免悄悄漏掉大型舰队较早的建议。
3. 整理并精简指引——将反复出现的备注和多次重复的驳回原因更新到技能正文中；删除过时的备注。
4. 合理调整名册规模：对于团队不再使用的领域，降低侦察员的运行频率或暂停它们；也可以通过计划式预检门控，让它们只在有新内容时启动（配方见 authoring-scouts）；检查 pending_pause / paused_by_system 行，并根据 pause_reason 有意作出决定，而不是默认处理（ignored：恢复运行或保持关闭；repeated_failures：读取最新运行的 failure_reason 并修复原因，探测程序会恢复它）；对于团队现在关注但尚无人监测的领域，可以考虑新增侦察员：侦察员标签页中的“Suggested for this project”栏是寻找候选对象的便捷来源。
5. 检查分发路由：如果报告堆积在共享收件箱中无人认领，请修正审阅者路由，让发现结果送达会采取行动的人：更正路由错误报告的审阅者（转发给舰队），留下全舰队可见的备注说明归属规则（pipeline:report-research 备注只会发送给基于信号生成的报告），并引导侦察员联系已知负责人。

常见请求，路由处理

用户说……	执行操作
“让一个 scout 监视 X” / “如果 Y 激增就告诉我”	使用上方的委派表；操作方法见 references/delegation-recipes.md
“我的 scouts 在做什么？” / “我的 scout 在工作吗？”	exploring-scouts
“我应该看什么？” / “scouts 发现了什么？”	inbox-exploration
“修复这份 scout 报告” / “这份报告是真的吗？”	inbox-exploration（先验证），然后采取行动；通过状态和备注完成闭环
“别再报告这个了” / “这个发现是噪声”	使用附带证据的备注将其忽略；如果再次出现，则将其提升为排除条件编辑
“本周重点关注 X”	添加有时间限制的备注（expires_at）
“现在检查 X”	使用 posthog:scout-run-now，并添加仅运行一次的 note
“把这个 scout 的报告发送到 Slack”	使用 posthog:scout-config-update 设置 output_destinations.slack；操作方法见 authoring-scouts
“把这些报告转给 ”	修改报告中的审阅者；对于长期规则，添加适用于整个 fleet 或单个 scout 的备注
“scouts 太吵了 / 太安静了”	先执行上方的校准流程；然后针对具体的问题 scout 使用逐级引导流程
“编写 / 编辑 / 重新调整 scout”	authoring-scouts
“为什么 scout 不再标记 X 了？”	先检查 Scratchpad（noise: / addressed: / dedupe: / allowlist:），然后查看备注，最后检查配置
“这个 scout 做了哪些更改？”	参见上方的“审计 scout 的更改”：查看运行时间窗口和可用历史记录
“那个修复确实生效了吗？”	对已解决的报告运行 posthog:inbox-report-checks-list；操作方法见 authoring-scouts