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_repo 驳回即使没有说明也会转发，因为其中列出的仓库就是反馈）。 写给接收者看：明确指出能得出结论的证据（“预发布流量——主机名与 *.dev.example.com 匹配，请忽略此模式”），而不只是写出结论。 写得好的驳回说明是你能做的最省力的侦察器改进；只写一句驳回结论毫无帮助，报告还会再次出现。 有两点需要注意：转发尽力而为，并且驳回者必须在规范项目中拥有侦察器引导（技能编辑）权限；在子环境的报告上做出的驳回则完全不会转发。在这两种情况下，说明仍会记录在报告中，但不会传到侦察器那里。因此，如果引导必须生效，请确认它已送达（使用 posthog:scout-notes-list，且凭证还需具备 task:read，否则衍生说明会被隐藏），或请有权限的人直接留下说明。 转发的说明还会在约 30 天后过期——只有侦察器将其纳入便笺记忆后，它才会长期保留。因此，若要让引导长期有效，应将其提升为技能编辑。
• 还有三种收件箱操作也能以同样方式引导侦察器。 在报告的“讨论”框中输入问题、对报告进行点赞或点踩并留下说明，以及添加或移除建议审核者，都会生成一条侦察器说明（可在 posthog:scout-notes-list 中查看，其 origin 分别为 report_discussion、report_feedback 或 report_reviewer_correction）。 审核者更正是整个侦察器集群收到的最强路由证据：它会送达提交或编辑报告的侦察器，以及记忆中的 reviewer: 字段包含已移除登录名的侦察器（每次更正最多发给二十个目标，因此报告非常繁忙时可能会漏掉一些）。所以，直接在报告上修正错误路由，就能让整个集群知道由谁负责该领域。 转发的说明会包含 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。 如果某个领域的报告总是没有路由或路由错误，可以进行修正：直接更正报告上的审核者（更正会按上述方式转发），留下集群范围的路由说明（使用 posthog:scout-notes-create 且不指定 skill_name，例如“将与计费相关的报告路由给 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

有些授权也会作用于未在其名称中提及的对象：两个 warehouse 授权都会作用于其主题相关的数据质量检查；llm_skill:write 则会作用于技能库安装命令，该命令会签发或轮换执行用户的市场凭据。 作用域名称所指的对象本身仍不会记录日志：技能正文编辑（包括其他 scout 所做的编辑）和 warehouse 表写入都不会留下日志行，因此请改为读取技能的版本历史记录。 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 负责完成运行级别的主要工作：执行频率遵循情况、成功率、报告率、记忆增长）。 还有两个盲点需要你自行检查：该脚本只评估时间窗口内有运行记录的侦察员，因此要逐一检查名册中已启用但近期没有运行记录的侦察员（它们往往问题最严重，但如果侦察员的预检查跳过了运行时点，也不会写入运行记录，所以在判定其出故障前，请检查 precheck_query_source 并对预检查进行试运行；exploring-scouts 中有具体步骤）；此外，它统计的是报告写入次数，而非结果，因此请通过 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 并修复原因，探测器会恢复它）；对于团队现在关注、但尚无人监控的领域，可考虑新建侦察员：“侦察员”标签页中的“为此项目推荐”栏是一个低成本的候选来源。
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