exploring-signals-scouts

探索 Signals 侦察器

侦察器是一种按计划运行的 Agent，会按自己的时间间隔唤醒，查看一个 PostHog 项目，判断哪些内容确实值得呈现，然后将其作为发现发送到 Signals 收件箱，或以空结果结束（这也是一种真实有效的结果）。PostHog 提供了一组标准侦察器，包括跨产品通用侦察器（signals-scout-general）以及各产品领域的专用侦察器（错误追踪、日志、AI 可观测性、实验、功能标志、会话回放、网站分析、问卷调查等）。一个项目还可以拥有标准侦察器之外的自定义侦察器——团队编写的任何 signals-scout-* 技能（例如 -brand-mentions、-mcp-feedback）也会显示在这里，因此不要假设侦察器列表固定不变：signals-scout-config-list 是项目侦察器列表的权威来源。（有一点需要注意：新编写的侦察器在协调器下次运行并自动注册配置之前，不会有配置行；也可以通过写入端的 signals-scout-config-create 手动注册。因此，新建的侦察器可能会短暂地缺少在列表中。）

此技能帮助你了解和探索项目的侦察器正在做什么，以及它们的表现如何——全程使用只读 MCP 工具。它是 authoring-signals-scouts 技能（讲解如何编写和调整侦察器）以及 inbox-exploration 技能（介绍侦察器生成的收件箱报告）的可观测性配套技能。

你可以通过各自对应的工具观察侦察器队列的五个方面：

你想了解什么	工具	能告诉你什么
哪些侦察器在运行、运行频率如何、处于何种状态	signals-scout-config-list	每个侦察器一行：计划、enabled、emit、last_run_at、description
侦察器每次运行实际做了什么	signals-scout-runs-list / -retrieve	每次运行的状态、时间、结束摘要、emitted_count、深层链接
整个侦察器队列通过多次运行积累了什么	signals-scout-scratchpad-search	团队持久记忆（基线、噪声、允许列表）
侦察器实际发出了什么	对 document_embeddings 使用 execute-sql	每条发现的权威记录（权重、严重性、置信度）——见下文
侦察器向用户呈现了什么	inbox-reports-list	达到标准并成为收件箱报告的发现

第六项用于了解整体情况的是 signals-scout-project-profile-get——它会确定性地快照“这个项目的真实情况”，供每个侦察器冷启动时使用。侦察器没有发现任何内容时，通常就是这个快照所致。

输出处理：做好将内容写入文件的准备

其中两个工具——signals-scout-runs-list，尤其是 tasks-runs-session-logs-retrieve——经常返回超出 MCP 客户端令牌预算的有效载荷，并将其溢写到文件中。这是正常情况，不是错误。请提前做好准备，而不是等调用失败后再发现：

• 在 signals-scout-runs-list 中将 limit 设得较小（约 10–15）。每一行都包含较长的文字摘要 summary，而且运行结果会按时间倒序返回，涵盖整个侦察器队列，所以即使是适中的分页也会很大。
• **会话日志本身就很大。**单次运行的日志可达数百 KB 到数 MB。使用 call --json 获取日志（这样保存的文件是真正的 JSON，而不是美化后的文本格式，可用 jq 处理），然后使用 jq 或脚本读取保存的文件，而不要直接内联读取。
• **不要手动解析会话日志。**随附的 scripts/ 会为你重建内容——见下文。

从这里开始：舰队是否已完成设置？

不要假设项目已经配置了侦察器。舰队只会为已加入 signals-scout 功能标志的团队运行；项目可能没有配置、所有侦察器都已禁用，或侦察器卡在试运行模式。 每当用户在会话中首次询问其侦察器时，都先运行此项。

signals-scout-config-list

结合以下三种情况解读结果：

配置列表不会分页——返回格式为 { results: [...] }（纯数组），没有 count 字段。结合以下三种情况解读结果：

• 列表为空（results: []） — 尚未注册任何侦察器。项目尚未加入侦察器舰队（或尚未完成检查）。直接说明这一点；不要继续寻找运行记录。引导用户前往 Signals 侦察器设置或 PostHog Code 入门页面，而不是凭空编造活动。

• 存在配置，但 enabled: false 全部如此 — 舰队已注册，但已暂停。当前没有任何运行。告知用户有哪些侦察器，并说明它们都已关闭。

• 至少有一个 enabled: true — 舰队已注册，且该侦察器已获准运行。对每个启用的侦察器，注明其 run_interval_minutes（运行间隔）、emit（false = 试运行，会运行，但不会向收件箱写入任何内容）和 last_run_at。在报告“正在运行”之前，需注意一点：运行受 signals-scout 功能标志控制，而不是受 enabled 控制。项目曾加入该标志、后来又被移出时，会保留 enabled: true 的记录，但协调器不再为其安排运行——因此，启用的侦察器的 last_run_at 过时或为 null，通常表示项目已不再加入该标志，而不是侦察器处于空闲状态。

  last_run_at 是_调度_时间戳，不能证明运行已执行。 对于到期的侦察器，协调器会在为其加入子工作流队列的那一刻更新该值——此时工作进程尚未接手运行。子任务的调度采用即发即弃方式，因此，如果工作进程已满负荷或处于停机状态，子任务只会排队，永远不会实际运行，但每次轮询时 last_run_at 仍会不断更新。因此，last_run_at 较新只表示“本轮已调度”，不表示“确实正在运行”。权威的运行状态信号是 signals-scout-runs-list 中最新的实际运行记录，而不是配置时间戳。请交叉核对：如果 last_run_at 是刚更新的（几分钟前），但在远超其 run_interval_minutes 的时间内都没有出现该侦察器的运行记录，说明舰队有调度，但未运行——工作进程积压或停机，或者运行任务被困住了。这是真实的可靠性问题，并不代表侦察器正在运行。不要仅凭 last_run_at 就报告“正在运行”。

enabled: true 但 emit: false 的侦察器，最常引发“我的侦察器什么也没做”的困惑：它_确实_会在每个运行周期执行并推理，只是尚未获准发布发现结果。报告侦察器情况时，务必说明 emit 状态。

有关配置、运行和暂存区条目的所有字段、运行状态值及各部分之间的关联方式，请参阅 references/scout-data-model.md。

工作流：检查舰队

“我有哪些侦察器／它们在做什么？”——先查看 config-list，再补充每个侦察器最近的运行记录，让用户了解运行状态，而不只是配置情况。

1. signals-scout-config-list — 获取侦察器列表。
2. 对每个已启用的侦察器，调用 signals-scout-runs-list，并选择 skill_name 匹配的最新运行记录（整个舰队的运行记录按时间从新到旧返回，因此通常一次调用就能覆盖所有侦察器）。报告 status 和距上次运行的时间。

将结果整理成便于浏览的表格，列出侦察器、运行间隔、状态、上次运行和上次结果，并指出任何异常情况（从未运行、上次运行出错、长期处于试运行模式）。

工作流：从头到尾了解一个 scout

“我的错误追踪 scout 是如何工作的？表现如何？”

1. 读取其配置——在 config-list 中找到 signals-scout-error-tracking 对应的行： schedule、posture、last run。
2. 读取其正文——posthog:llma-skill-get {"skill_name": "signals-scout-error-tracking"} 会返回团队实际使用的指令集（可能是规范默认值，也可能是经过修改的、手动编辑过的行）。这就是 Agent 每次运行时接到的指令——包括它区分信号与噪声的标准、探索模式和排除条件。要了解 scout 为何 会有这样的表现，请阅读其正文。
3. 读取其近期运行记录——使用 runs-list，将 text 设为该技能的领域，或者直接浏览最新的运行记录并筛选其 skill_name。每条运行记录末尾的 summary 都是 scout 对其查看内容和判断结果的自述。
4. 读取其记忆内容——使用 scratchpad-search（见下文）。scout 写入的记忆条目会揭示它对这个项目形成的基准认知和噪声认知。

工作流：查看近期运行记录

signals-scout-runs-list 会按时间倒序返回整个团队中最近的运行记录（最多 100 条）。用它来回答“最近发生了什么？”

• 限定时间范围：使用 date_from / date_to（ISO-8601 格式；在 created_at 上，下界包含，上界不包含）。通过传入更早的 date_to，逐步向前查看。
• 搜索摘要：使用 text——对每条运行记录末尾的 summary 进行不区分大小写的子字符串匹配。无头 scout 会用这种方式去重；要查找“是否已有运行记录查看过结账错误激增的问题？”，也可以用这种方式。
• 按是否有发现筛选：使用 emitted——emitted=true 只返回至少报告了一条发现的运行记录，emitted=false 只返回未报告发现的运行记录。无需解析文本，即可直接回答“哪些运行记录实际报告了内容？”

每行摘要都包含 run_id、skill_name、skill_version、status、started_at、completed_at、emitted_count（该次运行报告的发现数量）、emitted_finding_ids（这些发现的 ID）、task_url（Tasks 界面的深层链接，可查看完整记录）以及 summary 文本。向用户讲述时，应以 summary 为主——这是 scout 用通俗语言写下的结语——并始终提供 task_url，以便查看完整推理过程。

工作流：深入查看单次运行

当用户想了解某次运行的完整情况（或粘贴了运行 ID / Tasks URL）时：

signals-scout-runs-retrieve
{ "id": "<uuid>" }

注意字段名称的变化：runs-list 将每次运行的 ID 返回为 run_id，而 runs-retrieve 接收的字段是 id。将 run_id 的值作为 id 传入。

返回完整的运行信息：status、started_at / completed_at（根据这两个字段计算持续时间）、skill_name / skill_version（运行了什么，以及使用的正文版本）、运行结束时的 summary、emitted_count / emitted_finding_ids，以及 task_url。记录运行过程的转录——实际的工具调用和推理过程——位于 task_url 对应的 Tasks UI 中，不在此负载内；用户想查看每一步时，把该链接发给他们。失败的运行会返回空的 summary，且没有 error 字段——该负载看起来与列表行相同，因此要了解失败的_原因_，需要查看转录。

无需打开 UI：tasks-runs-session-logs-retrieve 会将运行的会话日志（每次工具调用、消息和推理步骤）作为数据返回——在诊断故障或想追踪运行具体操作、又不想离开当前对话时很有用。将运行行中的 task_run_id 作为 id 传入，同时传入其 task_id。

原始数据流很大（数百 KB 到数 MB），无法直接内联显示，因此使用 call --json 获取，并将其写入文件，然后使用 scripts/render_run_report.py 处理，而不要手动解析。

⚠️ 不要使用 exclude_types: "tool_call_update,…" 来精简数据。 这样做看似诱人——数据流主要由增量 tool_call_update 片段构成——但每个工具的实际输入只存在于这些片段中：基础 tool_call 事件中的 rawInput 为空，而流式更新会逐个 token 地构建输入（以及最终的 rawOutput）。排除这些片段后，你只能看到工具_名称_，却不知道侦察器实际查询了什么。获取完整日志，让脚本重新组装每次调用（按 toolCallId 分组，保留内容最完整的 rawInput，并附上完成事件中的 rawOutput / status）。

运行是否产生结果由一个一等字段标示：emitted_count。 emitted_count > 0 表示运行发现了相应数量的结果；emitted_count: 0 表示运行结束时没有结果。此后无需再解析 summary 中的文字——像“已产生 P1 … 未再次产生”这样的说法描述的是_之前_的运行，因此通过在 summary 中匹配“emitted”子字符串并不可靠，而 emitted_count 才是权威计数。emitted_finding_ids 按产生顺序列出该计数对应的 finding_id；每个 ID 都映射到一个 Signal，其 source_id = run:<run_id>:finding:<finding_id>，从而可靠地建立运行 → 发现结果的关联。有关运行与发现结果的关联，以及产生的发现结果如何经过分组并进入 source_product: "signals_scout" 收件箱筛选器，请参阅 references/scout-data-model.md。

status 为 complete 且摘要表明没有结果（“surface at baseline, nothing to emit”）的运行，是一种正常结果，而非失败——大多数运行都应该以无结果结束。持续出现无结果的结束状态，说明整套系统正在正常工作，而不是出了问题。

工作流：查看团队学到了什么

scratchpad 是团队持久化的专属记忆库——由侦察器编写的文本条目，可让后续运行更智能、更少噪声。阅读它可以了解团队对这个项目的认知。

signals-scout-scratchpad-search
{ "text": "error_tracking" }

结果按时间倒序返回条目（最多 100 条）；text 会以不区分大小写的方式匹配 content 和 key。省略 text 即可浏览所有条目。每个条目的 key 都带有类别前缀，说明它属于_哪种_学习内容：

前缀	含义
pattern:	基线——该团队的数据通常如何变化
watch:	正在跟踪但尚未达到发出标准的实时问题
noise:	团队决定忽略的模式（仅限开发环境、单个用户……）
addressed:	团队已修复或不再关注的事项
dedupe:	防止再次发出特定问题 / 指纹 / 发现的门控规则
allowlist:	已审核、永不重新出现的实体
not-in-use:	该团队未使用的产品 / 界面（结案备忘录）
mcp-gap:	侦察器发现、值得稍后提出的工具缺口

这些是通用词汇，并非封闭集合——侦察器会根据需要自创前缀和 <domain> 标签（例如，当前团队大量使用 watch:），因此应将不熟悉的前缀视为另一个类别。条目通过 [[key]] 维基链接相互引用。键的格式为 <prefix>:<domain>:<entity>（例如 dedupe:error_tracking:019e8375-…）。

当用户询问“为什么我的侦察器不再标记 X 了？”，请搜索 scratchpad 中的 noise:、addressed:、dedupe: 和 allowlist: 条目——团队可能已主动学习并抑制了该内容。规范的前缀词汇以及团队用于推理的四状态去重分类器，记录在 authoring-signals-scouts 技能的 references/dedupe-and-memory.md 中。

工作流：列出侦察器实际发出的内容

“团队最近发出了什么 / 展示侦察器生成的所有发现。”运行记录中没有发出标志或发现数量，文本 summary 只是启发式信息，而收件箱筛选器（如下）会丢失信息，因为分组会将侦察器发现合并到来源混杂的集群中。权威的逐条发现记录，就是发出的信号本身，存储在 document_embeddings 表中——可通过 execute-sql（通用路径）查询任意团队。侦察器发出信号时，emit_signal 会写入一个 source_product="signals_scout" 的信号；侦察器的归属信息（skill_name、finding_id、severity、confidence）存入 metadata.extra，而 weight 和 source_id 则位于顶层。

使用 execute-sql 获取数据，并用 scripts/emitted_signals.py 格式化——准确的查询语句位于该脚本的头部。每条发现对应一行，并且可以按任意侦察器组合筛选：

#   call --json execute-sql { "truncate": false, "query": "<the emitted-signals query>" }  -> emitted.txt
python scripts/emitted_signals.py --signals emitted.txt --now <ISO> [--skill mcp-feedback,general]

这里的每一行都代表发现确已持久化的事实依据——它通过了所有发出门控。解释数据缺失时，反过来的情况同样重要：侦察器可能在 summary 中写道“EMITTED ...”，但发出操作仍可能被预检门控静默丢弃（当时处于试运行状态、组织尚未批准 AI 处理，或 signals_scout 来源已停用），也可能发出失败。这些情况都不会进入此表，因此，声称已发出但实际缺失的发现本身就是诊断线索，而非脚本错误。每行记录背后的发出契约（weight 与置信度标准、严重程度、去重）记录在 authoring-signals-scouts 技能的 references/emit-contract.md 中；运行到发现的关联方式及其限制见 references/scout-data-model.md。

工作流：查看侦察器发现了什么

侦察器的发现会以收件箱报告的形式送达用户。按侦察器来源筛选收件箱：

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

这是查找侦察器支持的报告的直接方式。每条发现都会以 source_product="signals_scout" 发出，该标签会在分组过程中保留，并进入报告的信号元数据； 收件箱筛选器会保留其贡献信号中包含 signals_scout 的任何报告，因此 结果就是整个侦察器集群发现的报告。

结果为空意味着集群尚未发出（目前还没有），而不是筛选器出错。侦察器的门槛很高——大多数运行结束时都不会发出发现——因此对于安静或新加入的项目，没有侦察器支持的报告是正常且符合预期的状态。若要查看每次运行发出了什么，请从运行记录入手：signals-scout-runs-list?emitted=true 会列出每次有发出的运行，而每次运行的 emitted_count / emitted_finding_ids 会告诉你它产生了多少条发现，以及具体是哪些发现（每个 finding_id 都映射到一个 Signal，其 source_id = run:<run_id>:finding:<finding_id>）。若要更广泛地浏览 收件箱，请使用 inbox-exploration 技能（查看状态、建议的审核者，以及深入查看报告的底层信号）。每条发现背后的发出约定——权重、置信度、严重性和描述文字——记录在 authoring-signals-scouts 技能的 references/emit-contract.md 中。

工作流：评估健康状况和性能

“我的侦察器是否真的在工作／物有所值？”没有单一指标——应结合一段时间内的多次运行来评估侦察器。获取运行记录（使用带 date_from 的 runs-list），然后根据以下维度进行判断。完整的操作指南（包括如何解读各项信号和常见故障模式）见 references/assessing-performance.md。

• 运行频率是否符合预期——运行是否大致按 run_interval_minutes 的间隔进行？间隔过大意味着协调器跳过了它（已禁用、已从标志中移除，或在繁忙时段达到上限）——_或者_它虽已派发，但运行记录并未生成。可通过 last_run_at 区分这两种情况：如果配置中的 last_run_at 也已过时，说明协调器已停止为其安排运行；如果 last_run_at 是最新的，但最新的运行记录已是几小时前，则是上述派发与执行不一致的情况（工作进程积压／宕机，或运行被搁置），仅靠 runs-list 无法看出这一点。
• 成功率——有多少次运行以正常的 status 结束，而不是报错？连续报错意味着侦察器故障了，而不是没有发现。
• 发出率——有多少比例的运行发出了发现，又有多少以空结果结束？直接查看每次运行的 emitted_count（或使用 runs-list?emitted=true / ?emitted=false 拆分时间范围）。 对于仍在活跃运行的界面，长期接近零可能意味着判别条件过于严格（也可能是界面确实很安静）；接近 100% 通常意味着噪声太多。大多数健康的侦察器很少发出发现。
• 信噪比——发出的内容中，有多少转化成了可操作的收件箱报告，又有多少被抑制了？利用每次有发出的运行的 emitted_finding_ids 将运行与对应的 Signal 记录关联起来，并与 inbox-reports-list 中的报告状态交叉核对。
• 记忆增长——健康的侦察器会随时间积累 pattern: / noise: / dedupe: 条目。运行多次后暂存区仍为空的侦察器并没有在学习。

辅助脚本

该技能在 scripts/ 下打包了四个纯格式化工具，用于处理最常见的请求。 它们不会进行网络 I/O——这是“Agent 获取数据，脚本负责格式化”流程的后半部分。 流程始终相同：

1. 使用 MCP，通过 call --json（原始 JSON，而非美化后的文本格式）获取每个数据包， 并将其保存到文件中。对于较大的数据包（runs-list、tasks-runs-session-logs-retrieve）， 这一步本来就是必需的——它们会超出内联显示限制，并溢出到文件中，供脚本读取。
2. 使用脚本处理这些文件。

这四个脚本都仅依赖 Python 3.11+ 标准库，并将纯文本输出到 stdout（或 --out）——专为在终端中清晰易读而设计，因此请将输出保存为 .txt 文件。

scripts/render_run_report.py — 深入检查单次运行

生成检查单次运行时所需的详细报告：标题信息（状态、时长、执行姿态）、按时间顺序叙述的时间线，其中交错呈现 Agent 的说明、每次工具调用及其实际输入、运行结束摘要，以及任何便笺记忆。

# fetch (note --json), saving each to a file:
#   call --json signals-scout-runs-retrieve { "id": "<run_id>" }            -> run.json
#   call --json tasks-runs-session-logs-retrieve { "id": "<task_run_id>", "task_id": "<task_id>", "offset": 0 }  -> log.json   (FULL — no exclude_types)
#   (optional) call --json signals-scout-scratchpad-search { ... }          -> mem.json
#   (optional) call --json signals-scout-config-list {}                     -> cfg.json
python scripts/render_run_report.py --run run.json --log log.json \
    --scratchpad mem.json --config cfg.json --out report.txt

模式（--mode，默认为 detailed）：

模式	内容	需要 --log？
summary	标题信息 + 执行姿态 + 收尾说明	否
detailed	+ 叙述式时间线（含工具输入）+ 工具调用统计 + 便笺记忆	是
full	+ 内联显示每次工具调用的（截断后）输出	是

其他标志：--show-output（在 detailed 模式下输出内容）、--input-width / --output-width （截断宽度）、--no-art（跳过刺猬横幅）、--base-url（默认为 us.posthog.com）。

scripts/fleet_survey.py — 调查整个 Agent 集群

生成一张便于快速浏览的表格，列出 scout、是否启用、执行姿态、运行频率、上次运行和上次结果，并附带“值得关注”部分，标记从未运行、停滞在 dry-run 状态以及上次运行失败的 scout。

#   call --json signals-scout-config-list {}                 -> cfg.json
#   (optional) call --json signals-scout-runs-list { "limit": 30 }  -> runs.json   (small limit!)
python scripts/fleet_survey.py --config cfg.json --runs runs.json --now <current-ISO-time>

传入 --now（当前时间，采用 ISO-8601 格式）可显示相对时间的“多久之前”列；emit/quiet 列是基于每次运行摘要文本的启发式判断——请先对照摘要确认，再采信结果。

scripts/assess_health.py — 评估一段时间内的运行健康状况

实现上述“评估健康状况和性能”工作流：按 scout 列出运行次数、成功率、emit 百分比、频率与间隔的差值、遵循情况、中位时长、记忆增长情况，并附带“值得关注”部分，标记全部失败的 scout、疑似超时的失败、运行频率停滞、数据过时以及空白便笺。

#   call --json signals-scout-runs-list { "limit": 100, "date_from": "<ISO>" }  -> runs.json
#   (optional) call --json signals-scout-config-list {}                          -> cfg.json
#   (optional) call --json signals-scout-scratchpad-search {}                    -> mem.json
python scripts/assess_health.py --runs runs.json --config cfg.json \
    --scratchpad mem.json --now <current-ISO-time> [--skill signals-scout-general]

--config 用于评估运行频率是否符合预期间隔，以及判断数据是否过时（以权威的 last_run_at 为准；窗口内的运行记录可能会因 100 行上限而截断最新记录）。如果没有 --scratchpad，记忆列会显示 n/a，也不会触发任何记忆相关标记。emit 百分比使用相同的摘要文本启发式判断——请通过 inbox-reports-list 交叉核对信噪比。

scripts/emitted_signals.py — 车队实际发出的每条发现

实现“列出侦察器实际发出的内容”工作流：权威的逐条发现表（时间、侦察器、严重性、权重、置信度、finding_id、一句话假设）以及按侦察器汇总的结果（发出次数、严重性分布、权重范围、最近一次发出时间）。与 assess_health 的发出 %（一种文字启发式指标）不同，此脚本直接读取已发出的信号，因此结果精确。

其输入不是 signals-scout-* 工具，而是针对 document_embeddings 的 execute-sql 结果（通用的任意团队路径）。完整查询位于脚本头部——请原样复制。execute-sql 返回以竖线分隔的文本表格（即使在 call --json 下，这段文本也会被包装在 JSON 字符串中），因此脚本会解析这段文本；查询特意只选择可安全用于竖线分隔的标量列（不包含多行的 description，并会清理 hypothesis）。

#   call --json execute-sql { "truncate": false, "query": "<emitted-signals query from the header>" }  -> emitted.txt
python scripts/emitted_signals.py --signals emitted.txt --now <current-ISO-time> \
    [--skill mcp-feedback,general] [--severity P0,P1,P2] [--since <ISO>] [--sort weight] [--wide]

--skill 接受以逗号分隔的集合（signals-scout- 前缀可选）。--wide 会添加 scout_run_id，让你可以直接接着调用 render_run_report.py，查看发出某条发现的那次运行。请记住覆盖范围方面的注意事项：此处列出的是已持久化的信号——运行摘要声称存在、但此处没有的发现，可能是被拦截了（试运行／未批准 AI 处理／来源已停用），也可能是执行失败。

提示

• 始终说明 emit 状态。 用户认为侦察器出了问题、但实际并非如此时，最常见的原因就是“正在运行，但处于试运行模式”。
• 没有发现也算成功。 大多数运行应该一无所获。不要把一连串结果正常、没有发现的运行报告成问题。
• 发出与静默是运行记录中的一等字段。 直接用 runs-list?emitted=true 筛选运行（或读取每次运行的 emitted_count），即可找到有发出内容的运行，无需解析文字形式的 summary。source_product: "signals_scout" 收件箱筛选器会列出车队呈现的_报告_；如果结果为空，说明它还没有发出内容（侦察器的门槛较高），而不是筛选器出了问题。
• 运行约 30 分钟后显示 failed，通常是超时，而不是侦察器出了问题。 已完成的运行通常只需几分钟。最常见的情况是侦察器调查过度，耗尽了全部预算（车队会通过写入“紧凑运行方案”的便笺条目来自我纠正）——但也有一些是假超时：侦察器实际上几分钟内就完成了，随后却因收尾消息丢失而挂起。会话日志（见上文）可以区分两者：真正调查过度时，直到超时前都能看到工具调用；假超时时，工具调用会早早停止。不要仅凭运行时长就认定是调查过度。
• 先展示运行的 summary，再提供 task_url 以查看完整记录——不要把原始运行记录一股脑丢给用户。
• last_run_at: null 表示侦察器从未运行过——继续调查之前，先检查它是否已启用，以及项目是否已加入。
• 要解释侦察器为何保持静默，请读取项目配置文件。 signals-scout-project-profile-get 会显示它监控的对象是否正在使用——如果项目没有日志，日志侦察器自然无事可做。
• 此技能为只读。 要更改侦察器的计划、状态或内容，请转交给 authoring-signals-scouts 技能——该技能涵盖 signals-scout-config-update 和技能存储的编辑路径。