用 PostHog Self-driving 为 claude-mem 构建 AI 可观测性：信号源、Scout 侦察队与盲区治理复盘

本文是一份基于仓库内真实生成报告的工程实践解读。claude-mem（posthog-self-driving-report.md，2026-07-14 生成）将 PostHog Self-driving 应用于自己的可观测性体系：启用了 Error Tracking（三种触发器）、Session Replay、GitHub Issues 与 Support ticket 四类信号源，并把 scout（侦察队）调优为 3 个启用、23 个禁用，精准对齐该项目“包一层 Claude/Anthropic API、本身就是一个 MCP 服务器”这两个核心技术表面。读完本文，你将掌握 Self-driving 的信号源模型、scout 的启用/禁用判定逻辑、自定义 scout 的提出与干跑（dry-run）机制，以及如何用仓库源码验证每个决策背后的真实事件流。

---

这份报告在讲什么：Self-driving 配置的“决策留痕”

PostHog Self-driving 是 PostHog 的自动化洞察模块：它不依赖人工配置仪表盘，而是由一组“scout”（信号侦察单元）与“native signal source”（产品内置信号源）持续扫描产品事件与外部数据源，把值得关注的问题（错误回归、LLM 成本激增、支持工单、仓库 Issue 活动）以报告形式投递到 Self-driving inbox，甚至可直接转成编码任务。

claude-mem 的这份报告的价值不在于“我点了几个开关”，而在于它为每个决策都留下了理由——为什么启用某 scout、为什么禁用另外 23 个、为什么两条自定义 scout 提案被否决、哪些能力被原生信号源覆盖。这种“决策留痕”恰好可以反向验证 claude-mem 自身的可观测性埋点是否名实相符。仓库中的 docs/public/telemetry.mdx 与 src/services/telemetry/ 提供了全部事件定义与发送实现，是本报告最直接的源码证据面。

前置条件：AI 数据处理许可

报告中明确记录：Organization-level AI data processing consent 在本次配置运行前已批准（Approved）。这是启用任何会用到 AI 分析能力的信号源（如 session_analysis_cluster、scout 的跨源关联）的前提。如果你的组织要复刻这套配置，第一步不是在 PostHog 里点产品开关，而是先确认这一组织级 AI 数据许可已就绪，否则部分信号源即使“启用”也无法产出洞察。

---

数据源接入现状：GitHub 已打通，其余按需选配

GitHub 集成

报告显示 GitHub App 集成（thedotmack，integration ID 175967）在配置时已经连接（2026-06-10 连接），当前同步一个仓库：thedotmack/claude-mem。因此本次配置没有重做授权，而是直接复用了既有数据管道。

信号源（Signal sources）清单

本次配置在信号源层完成了 6 项操作，其中 4 项为新启用，1 项为默认开启，2 项被显式跳过：

source_product	source_type	Action
error_tracking	issue_created	Enabled（新建，ID 019f6318-32fa-73a9-914f-55617f6800de）
error_tracking	issue_reopened	Enabled（新建，ID 019f6318-3775-7090-a2e5-d98f893734d0）
error_tracking	issue_spiking	Enabled（新建，ID 019f6318-39b6-7161-8bce-8e03a206d92b）
session_replay	session_analysis_cluster	Enabled（新建，ID 019f6318-3dd1-7dae-b4a0-36eba57cb746；默认 10% 采样率）
conversations	ticket	Enabled（新建，ID 019f6318-4047-764c-94fc-ee62a511a9b2；在接入 inbound channel 前保持休眠）
signals_scout	cross_source_issue	默认开启——无需配置行，scout 发现自动进入 inbox
llm_analytics	evaluation_report	Skipped——内部专用 responder，非用户可见面
logs	—	Skipped——不属于 v1 responder 范畴

这里需要理解 PostHog Self-driving 的“native source”与“scout”分工：error_tracking、session_replay、conversations 是产品内建信号源，它们跟随产品事件实时触发（event-triggered），而 signals_scout / cross_source_issue 走的是 scout 定期扫描模型。claude-mem 的配置哲学在 scout 章节会进一步放大：凡是 native source 能覆盖的，就关闭对应 scout，避免重复告警。

Connected tools：只接真正会读的表

Tool	Status
GitHub Issues	已连接——Github warehouse source（ID 019eb017-8f11-0000-8ce2-d7bed20cb960）已存在；截至 2026-07-14 已同步 1,766 个 issues。Responder（github / issue，ID 019f6324-8a46-71ab-ad0b-8cea5b4fb795）已启用
Linear	未使用——未选择
Zendesk	未使用——未选择
pganalyze	未使用——未选择

报告中特别备注了一个数据源健康细节：GitHub warehouse source 在 stargazers 表上有 token 报错（Access forbidden），但 responder 实际读取的 issues 表同步正常——因此该 token 问题不阻塞 Self-driving responder，但可能影响其他 warehouse 查询。这是一个很典型的“部分表失败不阻塞主链路”案例，也在 follow-ups 中被列为待办。

---

产品使能矩阵：Error Tracking 与 Session Replay 已就位，Support 需手动补

Product	Status	Notes
Session Replay	Already active	录制流来自 cmem.ai 站点；该部署中无 products-enable API——通过在线录制确认服务器状态
Error Tracking	Already active	1.1M+ 事件经由 posthog-node 且开启 enableExceptionAutocapture；products-enable API 不可用
Support (Conversations)	需人工跟进	无法通过 API 启用（工具不可用）；见 follow-ups 的手动步骤

这段信息对理解 claude-mem 的埋点架构至关重要，并且可以直接在源码中得到印证：

• 后端走 posthog-node，而非浏览器端的 posthog-js。claude-mem 的主体是一个常驻 Node/Bun 后台 worker，src/services/telemetry/telemetry.ts 顶部 import { PostHog } from 'posthog-node'，客户端构造时显式传入 enableExceptionAutocapture、before_send、disableGeoip: false 等选项。报告注明“不需要检查 posthog.init override”，正是因为该项目从未在前端初始化 PostHog JS SDK。
• Session Replay 适用于 web 前端，而不是 Node worker。报告判断前端录制来自独立仓库或独立 snippet；这一判断与仓库文档口径一致——docs/public/telemetry.mdx 明确说明：claude-mem 的 Node worker“没有浏览器表面，无 DOM 可回放”，因此回放在该 Node 端永远不会被启用，Session Replay 只覆盖 cmem.ai 的 web 前端。这解释了为何报告对 Session Replay 采用“already active + 来自外部站点”的定性，而非在本仓库内部开启。

关于 Error Tracking 的“already active”，源码给出了完整实现证据：claude-mem 通过 posthog-node 的 enableExceptionAutocapture 捕获未捕获异常，但autocapture 不是裸奔的——telemetry.ts 中 enableAutocapture 由“worker 进程标记 + 错误 kill-switch + 遥测同意”三者共同决定，且所有 $exception 都会经过 before_send 挂接的 errorBeforeSend 过滤器；即便是 SDK 自动捕获的异常，也会被剥掉 posthog-node 从磁盘读取的源码上下文（context_line/pre_context/post_context），文件名一律缩到 basename。

---

Scout 侦察队调优：3 启用、23 禁用，理由逐条可查

这是整份报告含金量最高的部分。scout 是 PostHog Self-driving 的定期扫描单元（默认运行节奏见文末），相比实时触发的 native source，它的价值是跨产品做相关性扫描。claude-mem 的调优原则是：scout 只保留与自身产品表面直接相关的 specialist，其余要么被 native source 覆盖、要么当前没有数据支撑、要么项目规模用不上。

启用的 3 个 scout

Scout	Reason
signals-scout-general	常开——扫描跨产品相关性，覆盖其他 specialist 都不管的领域
signals-scout-ai-observability	该产品包装了 Claude/Anthropic API——LLM 成本、延迟与错误回归直接命中产品核心
signals-scout-mcp-tool-calls	该产品本身就是一个 MCP 服务器——$mcp_tool_call 遥测覆盖工具失败率与“令人困惑的 schema”

这两个 specialist scout 的启用理由，恰好各自对应 claude-mem 的一条核心业务链路：

• ai-observability scout → 压缩（summarization）链路：claude-mem 在每次会话压缩时调用 LLM（Claude/Gemini/OpenRouter 多 provider 可选）。报告的“LLM cost、latency、error regressions 直接 on-product”并非泛泛而谈——docs/public/telemetry.mdx 的字段表里就有 compression_ms（压缩调用延迟）、tokens_input/tokens_output/cost_usd（真实 token 用量与 provider 上报成本）、abort_reason（idle/shutdown/overflow/restart_guard/quota/none 闭集）等按事件承载的成本/延迟/失败信号，error_occurred 事件在 worker 返回 HTTP 5xx 时上报。这些正是 ai-observability scout 判断“AI 是否回归”的数据来源。
• mcp-tool-calls scout → MCP 服务器表面：claude-mem 通过 MCP 向 Claude Code、OpenClaw、Codex 等宿主暴露记忆检索工具（如 src/servers/mcp-server.ts），工具的失败率与 schema 清晰度直接决定用户体验，因此 $mcp_tool_call 遥测是该项目专属的“产品表面信号”，由 specialist scout 盯着最合理。

禁用的 23 个 scout（及理由）

Scout	Reason
signals-scout-error-tracking	已被原生 error_tracking source 覆盖（上面三种 trigger 全部启用）
signals-scout-session-replay	已被上面启用的原生 session_replay source 覆盖
signals-scout-product-analytics	无已确认活跃的 funnel/retention 洞察——若日后搭建产品分析仪表盘再启用
signals-scout-web-analytics	本仓库未确认 UTM/referrer 跟踪——若给 cmem.ai 加 web analytics 再启用
signals-scout-feature-flags	未确认使用 feature flag——采用 flags 后再启用
signals-scout-surveys	0 个 survey 在用
signals-scout-revenue-analytics	未发现支付 SDK
signals-scout-logs	未确认使用 PostHog logs 产品
signals-scout-csp-violations	未配置 CSP reporting
signals-scout-experiments	无活跃 A/B 实验
signals-scout-customer-analytics	未确认 group/accounts 分析
signals-scout-data-pipelines	未发现 CDP destination 或 hog flows
signals-scout-replay-vision	未配置 Replay Vision 扫描器
signals-scout-apm	未发现 OpenTelemetry/APM 追踪
signals-scout-anomaly-detection	对该项目规模而言，general + specialist 已覆盖充分
signals-scout-observability-gaps	若日后事件覆盖出现缺口再启用
signals-scout-health-checks	若 setup 健康度成为顾虑再启用
signals-scout-inbox-validation	全新配置上无意义——还没有已上线的修复可供验证
signals-scout-ingestion-warnings	若出现 ingestion 错误再启用
signals-scout-insight-alerts	未发现已配置的 insight alert
signals-scout-skills-store	PostHog 内部技能卫生 scout（不适用于外部项目）
signals-scout-data-warehouse	GitHub source 的 stargazers 表存在 token 问题——见 follow-ups
signals-scout-web-vitals	未确认来自该仓库的 $web_vitals 事件

阅读这张禁用表，可以提炼出三条可迁移的 scout 决策规则：

1. 去重规则：凡被 native source（error_tracking 三类 trigger、session_replay 集群分析）覆盖的 scout 一律关闭，避免同一问题被实时信号与定期 scout 重复上报。
2. 证据规则：没有事件、没有埋点、没有配置就不开——surveys、feature flags、web vitals、CSP 的禁用理由全部是“0 使用/未确认/未配置”，而不是“不重要”。
3. 规模规则：anomaly-detection 与 observability-gaps 这类通用型 scout，对当前项目规模“由 general + specialist 覆盖即可”，但被保留为“未来可按需开启”的候选，而不是永久删除。

---

自定义 scout：两条提案为何被拒？——盲区分析（Gap Analysis）

除了官方 scout，配置方还提出过两条针对 claude-mem 专有事件的 custom scout，最终都被用户驳回：

Proposed scout	Surface	Why declined
Memory pipeline health	observer_turn_rollup → context_injected_rollup 的量/比例劣化	用户驳回了该提案
Install-to-first-memory funnel	install_completed → worker_started → 首次 observation	用户驳回了该提案

提案的技术质量很高——它们瞄准的正是 claude-mem 遥测体系里最重要的两条事件链，在 docs/public/telemetry.mdx 的事件表中均有完整定义：

• observer_turn_rollup：按 session 聚合的累积器。一个会话内每次压缩先折叠进同一个 rollup，仅在会话结束时发送一次（替代原先每轮一个 session_compressed 事件），携带 rollup_reason（session_end/worker_shutdown/safety_flush）与 window_seq 部分冲刷计数。它的实现位置也能精确落在源码上：会话删除路径会触发一次 flushSession(sessionDbId, 'session_end')，见 src/services/worker/SessionManager.ts。
• context_injected_rollup：按 5 分钟时间窗聚合“记忆注入新会话”事件，携带 count、total_tokens、total_tokens_saved_vs_naive 等字段。

observer_turn_rollup → context_injected_rollup 这条链正是“记忆被压缩写入、又被检索注入”的闭环主干——第一条提案想监控的“静默劣化”（压缩产出量下降但注入量不变，或反之）在字面上就对应这两类事件；而 install_completed → worker_started → first observation 则是完整的新用户首跑转化漏斗，install_completed/worker_started/install_failed 事件在 telemetry.mdx 的 Events 表中都能找到定义。用户虽然驳回了这两条提案（可能出于配置初期收敛范围考虑），但它们被原样保留进了 follow-ups，作为“项目成长后可重新开启”的候选。

盲区分析（Gap Analysis）裁掉的一项同样值得注意：Chroma 依赖健康度（ChromaUnavailableError）被判定为无需新增 scout，因为原生 error_tracking source 已覆盖——ChromaUnavailableError 是该仓库的主导性错误。这条判断在源码里是真实的：ChromaUnavailableError 定义于 src/services/worker/search/errors.ts，由 Chroma MCP 管理器在连接退避、初始化失败、移除失败等路径上抛出（见 src/services/sync/ChromaMcpManager.ts 中的多处 throw new ChromaUnavailableError(...)），错误文本会被采集为 $exception 事件进入 Error Tracking——所以“error_tracking native source 已经覆盖主导错误”是有实现支撑的结论，而不是拍脑袋。

噪音逃生舱（Noise escape hatch）：报告给出了一个重要的运维旋钮——若想把任意 scout 变成干跑（dry-run）模式（照常运行并记录，但不向 inbox 产出任何内容），只需在 PostHog > Self-driving settings 中把该 scout 配置的 emit 设为 false。这是新 scout 上线前的标准灰度路径：先 emit: false 观察它是否误报，确认稳定后再放开。

---

后续行动清单：一份可以照抄的落地模板

报告末尾的 follow-ups 既有“本次配置的遗留项”，也有“未来扩容建议”，逐条可执行：

• [ ] 启用 Support/Conversations 产品——该 PostHog 部署中 products-enable API 不可用。请到 Project settings > Products 手动确认 Session Replay、Error Tracking、Conversations 均已开启。
• [ ] 接入 Support inbound channel——conversations/ticket 信号源已启用并在等待。连接 email、inbox 或 Slack 渠道后，支持工单才会开始进入 inbox。
• [ ] 修复 GitHub token 权限——stargazers 表持续报 Access forbidden / rate limits。检查 GitHub App token 的 scope；issues 表同步正常，因此不阻塞 Self-driving responder，但可能影响其他 warehouse 查询。
• [ ] 考虑启用 signals-scout-memory-pipeline（自定义）——监视 observer_turn_rollup / context_injected_rollup 的量与比例劣化，可在用户感知到记忆质量变差前抓住静默管道故障。
• [ ] 考虑启用 signals-scout-install-funnel（自定义）——监视 install_completed → worker_started → 首次 observation，可抓住损坏的首跑流程与平台特定回归；当安装转化成为核心指标时再创建。

这三类待办也对应三类典型 Self-driving 运维动作：补齐产品开关（手动）、接入数据渠道（等待态信号源激活）、修复数据源权限（部分表失败）。其中“ticket 信号源已启用但 dormant，直到渠道接入”这个状态模型值得记住——PostHog 允许先建好信号源、后接渠道，期间不会产生误报。

---

运行节奏与“接下来会发生什么”

报告最后给出了 Self-driving 的时间模型，这决定了上文所有决策的实际生效速度：

• scout coordinator 约 30 分钟内拾取新配置；
• scout 以**每天一次（1,440 分钟间隔）**的频率运行，把发现作为报告投递进 Self-driving inbox；
• Error Tracking 与 Session Replay 的信号更快——它们是事件驱动的，单个事件落地即触发；
• 可从 inbox 直接把“立即可行动的报告”转成编码任务，形成“发现 → 修复”闭环。

对 claude-mem 这类以“后台 worker + 事件日志”为主要产品形态的工具，这套节奏意味着：定期 scout 负责“跨天跨产品的趋势性扫描”（如 LLM 成本周回归），事件驱动的 native source 负责“秒级/分钟级的错误响应”（如 ChromaUnavailableError 突发），两层互补。

---

复盘：claude-mem 配置方法论的可迁移清单

把整份报告折叠成方法论，任何项目接入 PostHog Self-driving 时都可以按这个顺序决策：

1. 先批准 AI 数据处理许可，再谈配置（否则 AI 分析类信号源形同虚设）。
2. 盘点既有集成：GitHub App/warehouse 是否已连接、哪个仓库在同步、哪张表有 token 问题——能复用的绝不再建。
3. 激活 native source 优先：Error Tracking 三类 trigger + Session Replay 集群分析全部开启，用实时信号覆盖“错误与回放”两个基本盘。
4. 再调 scout：先开 general（常开兜底），再开与自身产品表面强相关的 specialist——判断标准是“我的产品是什么”，claude-mem 的答案（包 LLM API + 是 MCP 服务器）直接映射到 ai-observability 与 mcp-tool-calls。
5. 关闭冗余 scout：凡被 native source 覆盖、无对应埋点/使用证据、规模暂不需要的，逐条写明理由后禁用（保留“未来可开启”备注）。
6. 对专有事件做 gap analysis：把项目最核心的事件链（如 observer_turn_rollup → context_injected_rollup）与官方 scout 清单比对，缺口处提出 custom scout，并用 emit: false 干跑验证。
7. 遗留项全部落成 follow-up 清单，并明确运行节奏（30 分钟拾取配置、daily scout、事件级实时触发）。

如果你想从代码层面进一步核验这份报告的数据基础，推荐按此顺序阅读：事件定义与白名单全表见 docs/public/telemetry.mdx；worker 端 posthog-node 客户端、异常自动捕获与 $exception 限流/脱敏实现见 src/services/telemetry/telemetry.ts 与 src/services/telemetry/error-scrub.ts；person profile 与生命周期事件的公共属性见 src/services/telemetry/common.ts；rollup 在会话结束点的真实触发见 src/services/worker/SessionManager.ts。这份报告本身（posthog-self-driving-report.md）连同其“逐条理由”的记录风格，正是可观测性配置工程化最值得借鉴的部分——可观测性配置也应该像代码一样留下评审过的理由，而不是一串无人能解释的开关。