PostHog Signals Scout：observability gaps 可观测性缺口扫描器全解析

PostHog Signals Scout：observability gaps 可观测性缺口扫描器全解析

【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog

PostHog Signals 中的signals-scout-observability-gaps是一个专注于可观测性缺口的自动化侦察 Agent（scout）：它持续对比"团队正在产生的事件"与"团队已经建立的观测手段"（洞察、看板、告警），在缺口越过阈值时直接向 inbox 撰写推荐报告。本文基于仓库中该 scout 的完整技能定义（SKILL.md），并结合报告通道合约（report-contract.md）、去重与记忆约定（dedupe-and-memory.md）以及项目画像构建源码（builders.py），系统讲解它的设计哲学、六类缺口探查方法、报告决策流程与底层实现机制。读完你可以完整理解这类"推荐型"侦察 Agent 的判别逻辑，并掌握如何在 PostHog 中阅读与维护它产出的报告。

Scout 的角色定位：推荐，而非告警

observability gaps scout 与其他专业 scout（错误追踪、告警、异常检测等）在形态上有一个本质区别：它的产出是推荐（recommendations），而不是问题（problems）。它发现的是"事件产出"与"观测覆盖"之间的结构性差距，并在差距达标后推荐新的洞察（insight）、看板（dashboard）增量或告警（alert）配置。

正因为是推荐，它的门槛更高：一个嘈杂的"你应该追踪 X"的推荐流会摧毁 inbox 的信噪比。因此该 scout 的核心理念是：

宁可少而精，不可多而噪。推荐一些团队已经有了的东西，或为噪声事件推荐覆盖，比什么都不推荐更糟。

这一点也决定了它的运行姿态：空跑是真实且有价值的产出。它直接通过报告通道（scout-emit-report/scout-edit-report）撰写报告，一条推荐从研究到成稿 1:1 端到端负责，而不是发出弱信号等待流水线聚合。如果 inbox 已有推荐、只是证据（volume、reach）发生了变化，那是一次edit而非新报告。

技能文件的 frontmatter 定义了它的运行边界（来自 SKILL.md）：

name: signals-scout-observability-gaps scout-display-name: Observability gaps compatibility: > PostHog Signals agent (Claude sandbox). Read-only analytics + signal_scout_internal:write (scratchpad) + signal_scout_report:write (report channel), plus the analytics and entity tools in the MCP tools section (read-data-schema, query-trends, query-paths, execute-sql over system.* tables, event-definitions-list, alerts-list, dashboards-get-all). allowed_tools: - emit_report - edit_report metadata: owner_team: signals scope: observability_gaps

快速关闭（Quick close-out）：两条低成本的退出路径

路径一：团队太小，无缺口可查

如果项目画像中的top_events为 null，或少于约 5 个事件以 100/天以上的频率触发，这个项目就太安静了，缺口分析无法产生真正的推荐。

关键陷阱：windowed 而非 lifetime。每个top_events行都携带window_days字段，计数是滚动窗口统计而非全生命周期统计。一个近期采集（capture）中断的项目，与一个从未有流量的项目，读起来完全一样。因此在基于"稀薄"下结论前，必须先排除采集缺口：如果计数对于一个看起来活跃的团队（已配置集成、有已保存洞察、近期有活动）可疑地偏薄，应直接用execute-sql在更长窗口（如 30 天）上确认，而不是轻信画像快照——临时性缺口是另一个 surface 的采集问题，而非真实的量能缺失。

只有当低量能在更宽窗口内持续成立时，才写入一条 scratchpad 记录并空跑收尾：

• key：not-applicable:observability_gaps:team{team_id}
• content：简要说明（"checked at {timestamp}, top_events count <5 above 100/day, too quiet for gap analysis"）

后续的 observability-gaps 运行会冷读这条记录并在几秒内短路退出。用相同 key 重跑会幂等地刷新时间戳——该记录会一直保留，直到团队成长出有意义的量能，届时下一次运行会重写或删除它。

路径二：团队已饱和

成熟项目（数千个洞察、数百条告警）会在几次运行后确认整族缺口已饱和：每个高量事件都有密集覆盖，新涌现的事件几天内就会被覆盖。此时应将其记录为持久记忆，而不是每次运行都重新发现：

• key：pattern:observability_gaps:<family>-saturated（或跨家族的单一coverage-saturated记录）
• content：探测了什么、发现的覆盖计数，以及一个触发线（tripwire）——家族值得重新探测的具体条件（例如"一个全新的广达事件类（7 天内 >~1 万去重用户）、零覆盖、属于离散的业务/功能指标而非环境遥测"）。

一旦饱和被记录，默认运行形态就变了：对照最新画像检查触发线，然后最多跑一次全新探测——一个此前任何运行都没覆盖的角度——以此赢得收尾而非继承收尾。如果触发线未触发且探测结果干净，几分钟内即可空跑收尾。不要重跑几小时前刚验证过的覆盖 SQL——那是重复劳动，不是尽职。

一个必须内化的不对称性：覆盖类家族（1、3、4、5、6）在成熟团队上是永久饱和的——每个高量事件都已有密集覆盖——但洞察漂移（家族 2）不会饱和。漂移随产品重命名和停用事件而持续产生，因此在一个其他方面已饱和的团队上，它是唯一持续多产的角度。应以它为先，并把覆盖类家族视为继承饱和，除非它们的触发线被触发。

当存在多个探测角度（新事件涌现、告警覆盖、洞察漂移）时，要轮换（rotate）：每次运行挑选最久未被触碰的角度，并继承其他角度的近期读数。轮换让每个 tick 都产生真正新鲜的收尾，而不必每小时重跑相同的 SQL。

一次运行的完整工作流

运行在以下动作间循环：跳过无用的，回访有用的。

定向（Get oriented）：四次低成本冷启动读取

1. scout-scratchpad-search（text=gap或text=observability）——来自既往 observability 运行的持久团队导航。带有pattern:、noise:、addressed:、dedupe:、watch:、report:、reviewer:key 前缀的记录告诉你：什么是常态、什么已浮现、什么该跳过、哪些缺口被暂存、哪份报告覆盖了哪条推荐、谁拥有这个 surface。这里至关重要，因为同一个缺口绝不能被跨运行重复报告。
2. scout-runs-list（最近 14 天）——既往 observability-gap scout 发现了什么、排除了什么。先浏览摘要；只有当摘要提到你正在考虑的推荐时才拉取scout-runs-retrieve。
3. scout-project-profile-get——top_events提供量能与触达，popular_insights提供已保存的洞察，recent_dashboards提供在用的看板，existing_inbox_reports提供 inbox 中已有的报告。这一次读取就能告诉你检测缺口所需的大部分信息。从源码看（builders.py），该画像由build_inventory()聚合生成，写入SignalProjectProfile.payloadjsonb 列，其中_top_events()对events表执行 HogQL 查询，按 7 天回看窗口（TOP_EVENTS_LOOKBACK_DAYS = 7）统计 count、uniq(person_id)触达、最近 24h 计数/触达与窗口内首末次出现时间，最多 50 个事件，查询超时上限 20 秒（TOP_EVENTS_MAX_EXECUTION_S），失败时返回None以区别于"团队无采集"（[]）。
4. inbox-reports-list（ordering=-updated_at，search=具体事件/洞察/看板名）——inbox 中已有的报告。注意：你自己通过报告通道产出的报告，其 backing signal 记录在source_product=signals_scout（不是observability_gaps），所以不要按 product 过滤——否则会漏掉你撰写过的每一份报告。之前已经提过的推荐是edit而非新报告；撰写前先用inbox-reports-retrieve拉取最接近的匹配项。

探查（Explore）：六类值得关注的缺口家族

以下六类家族按典型信号密度排序。没有一个是自动成立的——每一条都需要经过"量能 + 覆盖检查 + 去重"三重验证才能成为发现。

家族 1：高量自定义事件，无洞察覆盖

自定义事件（非$pageview/$identify这类$builtin）每天以有意义的量触发，但没有任何已保存洞察引用它。

直接调用：

• read-data-schema events——获取事件名 + 24h 量能。
• 针对system.insights执行execute-sql——查找在name、description或queryJSON 中提到该事件名的洞察。模式：query::text ILIKE '%{event_name}%'。
• 检查event-definitions-list的last_seen_at新近度和verified标志——团队是否已将其标记为值得追踪。

强信号：事件 > 1000/天、无洞察引用、verified=true。弱信号：事件 < 100/天、未类型化、零星触发。

量能排名的盲区：一个刚诞生、触达广但人均频率低的事件，可能永远排不进按 count 排序的top_events；而 7 天查询窗口会截断min(timestamp)，无法区分新旧事件。因此要用宽窗口直接探测涌现：events 表、最近 60 天、event NOT LIKE '$%'、按事件分组，只保留min(timestamp) >= now() - 14d（真正的新事件）且最近 7 天去重用户超过触达下限（~500+）的组，按触达排序。每个命中都是 top-events 镜头结构性看不见的候选者；对它运行与其他候选者相同的覆盖检查和排除项。

家族 2：洞察漂移——已保存洞察指向零量事件

已有洞察过滤事件 X，但 X 在过去 7 天触发次数为 0（或接近 0）。通常是以下原因：

• 事件被重命名（如signed_up→sign_up_completed），洞察未更新。
• 事件被停用（产品变更弃用），洞察已过期。
• 上游采集损坏（这是另一个镜头——让 error-tracking scout 负责）。

直接调用：

• 对system.insights执行execute-sql，抽取每个洞察过滤的事件序列。
• 用query-trends测量这些事件的近期量能。
• 对零量事件，搜索event-definitions-list中名称相似的事件（Levenshtein 相近、相同前缀、相同属性形状），提示可能的重命名。

强信号：洞察仍"活着"（近期last_modified_at，或通过system.dashboard_tiles钉在活跃看板上）且其主事件 7 天内 0 触发且名称相似的事件 > 100/天。注意：system.insights暴露last_modified_at但没有last_viewed_at列——"活着"只能通过修改新近度或活跃看板 tile 来证明，不能用查看新近度。

家族 3：关键事件，无告警配置

有些事件自报家门——payment_failed、signup_failed、*_error、*_blocked。只要它们有触发且没有告警，就是缺口。使用项目自身的模式：在事件词汇表中搜索failed、error、blocked、denied、rejected、timeout、crashed等词。

直接调用：

• 按名称模式（failed、error等）过滤read-data-schema events。
• alerts-list——现有告警及其目标。
• query-trends确认量能非平凡（不是一次性偶发）。

强信号：事件名暗示失败语义、触发 > 10/天、零告警覆盖。弱信号：名称含error但实为良性开发者遥测。

家族 4：看板范围缺口

某个主题已存在看板（名称 + 描述匹配"Onboarding""Revenue""Conversion"等领域），但与该主题相关的高量事件不在看板的任何洞察上。

直接调用：

• dashboards-get-all——现有看板 + 标签 + 描述。
• 对每个看板，通过 dashboard tile 端点或system.insights WHERE id IN (dashboard.insight_ids)列出洞察。
• 通过名称重叠将领域主题事件与看板匹配。

强信号：看板明确以领域命名、> 5 个事件匹配该领域且各自 > 1000/天、但全部不在看板上。弱信号：任意关键词重叠。

家族 5：漏斗候选——有序序列事件模式，无漏斗洞察

三个或更多事件在用户会话中频繁以固定顺序共现，且没有漏斗洞察追踪该序列。通常是 onboarding 流程、注册流程、结账流程等。

直接调用：

• query-paths（一次调用）探查热门去重事件，浮现常见序列。
• 对system.insights WHERE filters::text ILIKE '%FunnelsQuery%'执行execute-sql，查找现有漏斗。
• 检查序列长度与留存（各步骤完成用户百分比）。

强信号：3 步序列、> 1000 用户完成第 1 步、> 50% 到达第 2 步、无现有漏斗覆盖该序列。此处的门槛很高，因为漏斗是主观的——常见序列不一定是有效漏斗。

家族 6：属性基数 / 缺失的 breakdown

高量事件上有高基数属性，而现有追踪该事件的洞察都不使用 breakdown——团队正在因聚合而丢失维度。

直接调用：

• read-data-schema event_property_values——查看某属性的去重取值。
• 对该事件执行system.insights上的execute-sql——抽取breakdownFilter形状。
• 比较属性基数与是否有洞察按它 breakdown。

强信号：属性有 5–50 个去重取值（非无界）、事件 > 5000/天、无洞察按它 breakdown。弱信号：属性有 1000+ 去重取值（会撑爆图表）或 ≤ 2 个取值（不增加信息）。

决策（Decide）：author 还是 edit 一份报告

这里的发现是推荐一个行动，而非暴露一个问题。通用的报告机制——先搜索 inbox（通过report:observability_gaps:<gap>指针，或对缺口的_具体_实体做inbox-reports-list搜索，而非gap这样的宽泛词）、edit-vs-author、状态规则、评审者路由、非幂等去重、priority/repository/actionability 字段——都位于 harness prompt 和 report-contract.md 中，不需要在此重新推导。本 scout 只在其上叠加 observability-gaps 的专属判断。

每份报告的必需元素：

• 具体的事件/洞察/看板——实体 ID 进入证据列表，让人类可以一键直达。
• 量能 + 触达数字——缺口之所以重要，是因为N个事件影响了M个用户；两者都要引用。
• 建议行动——"在事件 X 上创建 trends 洞察"/"更新洞察 Y 指向事件 Z"/"把洞察 A 加到看板 B"/"为事件 C 配置告警"。具体优于抽象。
• 为什么是现在——如果这个缺口已存在数周，为什么现在浮现？因为量能刚跨过阈值？因为新事件类涌现？量能 + 新近度是去重键。

门槛的权衡（bar）：

• 量能阈值——缺口只有在规模上才结构性地有趣。低于 100/天，推荐就是噪声。
• 稳定而非偶发（Stable-not-spurious）——缺口必须在项目时区中持续存在至少7 个完整天。避免标记昨天刚出现的事件；部分当前天或部署日峰值可能伪装成稳定。
• 无既有覆盖——author 前搜索popular_insights和existing_inbox_reports。如果之前某次运行已推荐过该缺口，选择 edit 或跳过。

然后，对每个跨过门槛的候选者：

• Edit：当一份仍然活跃的报告已推荐该缺口、且其证据只是数字移动了（量能进一步攀升、触达扩大）时——用append_evidence追加新数字，而不是铸造一份近乎重复的报告。
• Author 全新报告：仅当没有任何活跃报告覆盖该缺口时。推荐是调查而非代码修复，因此actionability=requires_human_input+repository=NO_REPO。优先级几乎总是P3（一条建议）；关键失败语义事件（家族 3——payment_failed、*_error、*_blocked）在零告警覆盖下触发时是P2。
• Remember / Park：通过下面的 watch 生命周期暂存低于门槛的候选者。
• Skip：如果noise:/addressed:/dedupe:记录或现有 inbox 报告已覆盖它，写一行说明跳过。

兄弟协作礼貌：上游采集损坏（事件停止触发）属于 error-tracking scout；已配置但触发未命中的告警属于 insight-alerts scout；被查看洞察自身的异常属于 anomaly-detection scout。你独特的角度永远是结构性的覆盖缺口，而不是其之上的异常。

暂存再 author：watch 生命周期

大多数好推荐不是在发现的当次运行就被提交的——它们被暂存，直到稳定性门槛跨过。生命周期如下：

1. Park（暂存）——写入watch:observability_gaps:<gap>记录，携带判别条件（使这成为真实缺口的确切检查）、迄今的量能证据，以及最早提交时间（第 7 个完整项目时区天结束时）。未来运行继承该候选者，而不是重新推导。
2. Re-verify live, then author（现场复核后再 author）——跨过门槛的那次运行必须在 author 前对每条判别条件用实时数据重新检查（覆盖可能已出现、量能可能已崩坍）。绝不能仅凭 watch 记录提交。
3. Guard（守卫）——author 后，用report_id和约 30 天的去重期更新 watch 记录：除非出现实质性新角度，否则在此之前不重复报告。写入report:observability_gaps:<gap>指针，让下次运行 edit 而非重复；并在reviewer:observability_gaps:<area>下缓存已解析的负责人。
4. Retire（退役）——记录不会永远存在。当覆盖出现（推荐已被执行）时删除记录（或转为addressed:）。若约 30 天过去仍无人建立覆盖，说明"已推荐但被忽略"——转为noise:跳过记录，而不是重复报告。

收尾（Close out）

总结本次运行——一段话：你看了什么、author/edited 了哪些报告、记住了什么、排除了什么及原因。harness 将总结写入运行行作为可搜索的散文；未来运行通过scout-runs-list读取它。不要单独写"运行元数据"scratchpad 记录——运行总结已承担该角色。

排除项（Disqualifiers）：这些必须跳过

• 无已保存洞察的内置事件——$pageview、$autocapture、$identify、$set、$opt_in、$groupidentify、$feature_flag_called通过 PostHog 产品视图（Web Analytics、Feature Flags）即可呈现，无需自定义洞察。不要推荐创建。
• 内部用户的测试事件——为已知内部 distinct_ids 钉一条noise:observability_gaps:internal-distinct-ids记录，并在量能统计中跳过它们。
• 已禁用 feature flag 的事件——若事件仅在 flag 禁用或极低 rollout 百分比时触发，量能是人为偏低的。
• 临时一次性看板上的事件——只有一个查看者的私有看板不算"已覆盖"。使用popular_insights的查看者数阈值。
• 环境型 app-shell 遥测——去重用户触达约等于$pageview的事件意味着它几乎为每个用户随 app shell 触发，而非离散的功能指标。其上零已保存洞察通常是刻意的；称其为缺口前先与$pageview对比触达。
• 刻意的工程 firehose——团队通过临时 SQL 或 notebook 消费的高量内部性能/遥测事件。宣布零覆盖前，检查 notebook 是否引用该事件——按选择覆盖不是缺口。
• 实验曝光事件——用于驱动实验指标的事件由实验本身覆盖。实验运行期间不要为它们推荐独立洞察。
• 每人一次的生命周期事件——onboarding、wizard、setup 事件每人触发一次；它们的量能只是注册流程的流转，很少值得独立洞察。
• 限时促销/营销活动事件——活动形态的事件按设计出现、飙升、结束。归于沉寂不是漂移，缺乏覆盖不是缺口，除非底层 surface（impressions + conversions）持续存在。
• 事件调查脚手架——事件期间创建的短期事件，通常附带事件命名的洞察。事件关闭后它们停止触发；把停止标记为漂移是误报。
• 一次性回填/部署峰值——新埋点事件可能在单次采集倾泻全部历史，伪装成高触达的"稳定"指标。信任量能前，按小时分桶（toStartOfHour）：如果几乎所有事件_和_去重用户都落在同一小时内，那是回填而非稳定指标——直接排除（无论原始触达多少，它都跨不过 7 完整天门槛）。
• 遗留事件名变体——故意将新旧事件名 union 起来保持历史连续性的洞察是维护良好的，而非漂移。宣布死亡事件"仍被引用"前，先读洞察的 query JSON。

有疑问时，写 scratchpad 记录而不是提交报告。推荐对任何观测 surface 的负责人都有很高的恐慌半径——误报会迅速侵蚀信任。

MCP 工具全览

直接调用（只读）

• read-data-schema——kind=events取量能；kind=event_properties/event_property_values取基数与 breakdown。
• query-trends——确认证据中引用的近期窗口量能 + 触达数字。
• query-paths——漏斗候选的序列检测。
• insights-list——分页洞察目录（慎用；SQL 更快）。
• dashboards-get-all——活跃看板 + 标签。
• event-definitions-list——事件定义元数据：verified标志、last_seen_at、created_at、自定义-vs-内置标记。
• alerts-list——现有告警配置及其目标事件。
• 对system.insights/system.dashboards/system.cohorts执行execute-sql——"是否有洞察引用事件 X"这类查询的快速路径。

Inbox 与评审者路由（机制见 report-contract.md）

• inbox-reports-list/inbox-reports-retrieve——inbox 中已有的报告；author 前先检查，以便 edit 而非重复（ordering=-updated_at）。
• inbox-report-artefacts-list——可比报告的 artefact 日志；评审者先例。
• scout-members-list——用于将suggested_reviewers路由到拥有该洞察/看板/产品 surface 的成员的运行内名册。

Harness 级

• scout-project-profile-get——冷启动定向快照。已内置top_events、popular_insights[13]、recent_dashboards、existing_inbox_reports。其工具定义（tools.yaml）说明响应开头有紧凑的summary信封承载emit_eligibility（决定产出能否到达 inbox 的门，附一行remediation）与 inbox 报告计数；完整payload.inventory可长达数十 KB，所以要从summary读门，而非payload深处。
• scout-scratchpad-search/scout-scratchpad-remember/scout-scratchpad-forget——持久导航。从 scratchpad.py 的源码看，检索是对content和key的 ILIKE 匹配，key 最长为 300 字符（MAX_SCRATCHPAD_KEY_LENGTH），content 上限 5 万字符（MAX_SCRATCHPAD_CONTENT_LENGTH），remember以(team, key)幂等 upsert，expires_at是可选 TTL——过期记录退出搜索，每日 janitor 在过期两周后硬删除。
• scout-runs-list/scout-runs-retrieve——既往运行发现了什么。
• scout-emit-report/scout-edit-report——撰写推荐报告/编辑现有报告（报告通道合约在 harness prompt 中）。

如需更深的调查 playbook，sandbox 镜像内置了上游 PostHog 技能：posthog:querying-posthog-data（HogQL 语法 + system.* 搜索模式）和posthog:exploring-autocapture-events（自定义事件与 autocapture 的区别及各自适用场景）。

报告通道与记忆机制的底层支撑

author vs edit 的决策表

报告通道合约（report-contract.md）给出了清晰的决策表：

状态由"安全 × 可行动性"决定

observability-gaps 的推荐是调查而非代码修复，因此默认走requires_human_input路径（PENDING_INPUT出现在 inbox 供人类采纳），并配合NO_REPO与 P3 优先级；家族 3 的失败语义事件零告警覆盖时升为 P2。

去重与记忆的 key 前缀词汇表

记忆约定（dedupe-and-memory.md）规定 scratchpad 无标签，类别编码在 key 前缀中，格式为<prefix>:<domain>:<entity>。observability-gaps 使用的核心前缀包括：

好的记录是面向未来运行可行动的：带日期、命名实体 ID、给出明确条件（"仍在触发 → 升级；安静 → 跳过"）、以精确时间锚点限定，key 前缀使其可被找到。

报告撰写的关键约束（节选）

• evidence上限 50 条，每条{description, source_id}；超限在判定/持久化前即验证失败。
• 实体必须以 markdown 链接引用（复用工具返回的_posthogUrl，或用generate-app-url构建），而非裸 ID；title与 summary 首行保持纯文本（inbox 会将其提升为卡片标题）。
• actionability_explanation一句话论证可行动性判定；already_addressed默认false。
• 报告被写入时即使被SUPPRESSED也会返回report_id，以便后续 edit 或去重。
• 同类推荐不要重复提交：emit_report有幂等键覆盖传输重试；但跨运行去重是双向的、由 scout 自己负责——author 前inbox-reports-list查先例，author 后写report:<domain>:<entity>记录。
• 流水线可能日后重提升并重研究你的报告、覆盖你撰写的 title/summary——这是被接受的行为，不要假设你的措辞不可变；持久的"我提交过"凭证是report:scratchpad 记录与report_id，而非标题文本。

何时停止（When to stop）

• scratchpad + 近期运行 + 画像显示你考虑过的每个领域都已有覆盖或已被推荐 → 空跑收尾。
• 候选者匹配addressed:（推荐已执行）或noise:（已推荐但被忽略）前缀的 scratchpad 记录，或现有 inbox 报告 → 一行说明后 edit-or-skip。
• 你已验证 1–2 个高质量缺口并为其提交了报告 → 收尾，即使还有可看的。质量优先于数量——推荐是预算，不是目标。

"看了但没找到有意义的东西"是真实产出，不是失败。每一条没有发出去的推荐，都是少一个侵蚀 inbox 的误报。

相关资源

• 技能本体：products/signals/skills/signals-scout-observability-gaps/SKILL.md
• 报告通道合约：products/signals/skills/authoring-scouts/references/report-contract.md
• 去重与记忆约定：products/signals/skills/authoring-scouts/references/dedupe-and-memory.md
• 项目画像构建源码：products/signals/backend/scout_harness/profile/builders.py
• 记忆工具实现：products/signals/backend/scout_harness/tools/scratchpad.py
• MCP 工具定义：products/signals/mcp/tools.yaml
• Signals 架构总览：products/signals/ARCHITECTURE.md

【免费下载链接】posthog:hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools – AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more – capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.项目地址: https://gitcode.com/GitHub_Trending/po/posthog