PostHog 的 Django 启动时间优化实践：五大机制、回归守卫与全套踩坑指南

PostHog 的 Django 启动时间优化实践：五大机制、回归守卫与全套踩坑指南

【免费下载链接】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

导读

django.setup()是 PostHog 后端每一个进程的必经之路——Web、Celery、Temporal、migrate、manage.py shell，以及每一个 CI 任务都要完整执行一次。任何被拖进这条路径的重量级 import，都会被所有这些进程在每次启动时共同买单。这篇技术指南基于仓库内部文档 docs/internal/django-startup-time.md，结合 posthog/ 的真实源码，完整讲解 PostHog 如何通过懒 API 路由、模型注册收敛、信号接收器迁移、GC 启动窗口、生成式 schema 剥离这五大机制把启动路径压到最薄，如何用双回归守卫在 CI 中锁定成果，以及多年来反复踩坑沉淀出的十二类陷阱。读完你将掌握一套可直接复用的 Django 大型项目启动性能治理方法论：从"怎么改"到"怎么量"，再到"怎么防止改回去"。

问题的本质：成本几乎全是模块导入

启动慢的根源几乎全部是模块导入（module imports），而不是运行时工作。一条急切的 import 链只要触及以下任意一个子系统，就会增加数百毫秒：

• AI core（ee.hogai下的 agent 核心）
• batch-export 的 Temporal 框架
• 内嵌 ClickHouse（chdb）
• scipy
• Stripe SDK

解决办法始终是同一个：把 import 变懒（lazy），让它只在实际运行到相关代码时才加载。PostHog 对这条路径的治理中，最大的单一杠杆是懒 API 路由（lazy API router），其余工作则是对单个重量级 import 的逐个延后。

五大机制详解

1. 懒 API 路由：从包导入期搬到首个请求

DRF 路由聚合器（router 构建 + 约 200 个 viewset import）曾经在posthog.api的**包导入（package import）**阶段运行。现在它被移到了 posthog/api/rest_router.py，而 posthog/api/init.py 变成了一个极薄的 PEP 562__getattr__shim：

def __getattr__(name: str) -> Any: # 真实子模块——直接导入，不构建聚合器 if importlib.util.find_spec(f"{__name__}.{name}") is not None: return importlib.import_module(f"{__name__}.{name}") # 否则是聚合器定义或再导出的名字（router 对象等）——懒构建并委托 from posthog.api import rest_router # noqa: PLC0415 try: return getattr(rest_router, name) except AttributeError: raise AttributeError(f"module {__name__!r} has no attribute {name!r}") from None

关键点在于：posthog.api.monitoring、.file_system等真实子模块能直接解析而不触发聚合器构建，所以一次朴素的django.setup()（shell、migrate、celery、CI）始终廉价。这正是 Django 本身预期的惰性：URLconf 才是入口点，非 Web 进程永远不会去解析它。

Web 是例外，需要急切构建：posthog/wsgi.py 和 posthog/asgi.py 在 import 时（pre-fork、GC 窗口内）就解析 URLconf——因为 k8s 探针/_livez、/_readyz由短路中间件直接响应、从不解析 URL，如果不在启动时构建，每个 worker 都会在第一个存活请求上才构建 router（实测每次部署后每个 worker 要多花数秒）。pre-build 把 router 在 worker 启动时放入冻结堆（frozen heap），正好恢复了懒路由改造前 Web 进程的行为，而其他所有进程则保留收益。测试 test_web_entrypoint_prebuilds_the_router 固定了这一行为；gunicorn--preload+ 4 worker 的 prefork 冒烟测试验证了 worker 能继承已构建的 router 并直接服务冷请求。

2. 模型注册：必须从models/__init__.py收敛

导入一个 viewset 模块过去会顺带注册一些模型（导入模型类会触发ModelBase.__new__→apps.register_model）。router 变懒之后，一个只能通过 viewset import 触达的模型会在 setup 时从apps.get_models()中悄然消失。因此每个模型都必须在其所属 app 的models/__init__.py（或models.py）中被导入，使其在 app-population 阶段注册——与 router 完全解耦。

3. 信号接收器：从 viewset 副作用迁移到AppConfig.ready()

导入 viewset 模块还会执行其中的@receiver装饰器，所以过去的急切 router 把一堆接收器作为django.setup()的副作用连接起来。router 变懒后，这些接收器只在 router 首次构建时才连接——任何不构建 router 的进程（celery、temporal、migrate、shell）都会静默丢失它们。正确做法是从所属 app 的AppConfig.ready()连接接收器，让它们在 setup 阶段就位。

4. 启动期延迟垃圾回收：gc.disable()→ 冻结 → 重新启用

启动期的分配几乎全是永久的——模块、类、注册表、生成的 pydantic schema——所以django.setup()运行期间循环 GC 几乎无可回收，但分配阈值仍会触发约470 次收集（约 300ms 停顿，单次 gen2 全收集最高约 100ms）。拥有 setup 的入口点（manage.py、posthog/wsgi.py、posthog/asgi.py）把它包裹在gc.disable()→ 启动 →gc.freeze()→gc.enable()之中。以 manage.py 为例：

if not any(arg.startswith(("--settings", "--pythonpath")) for arg in sys.argv): gc.disable() try: import django django.setup() finally: gc.freeze() gc.enable()

gc.freeze()把约 60 万个存活的启动对象移入永久代（permanent generation），从此被排除在每一次未来的全收集之外——这让启动后的工作（管理命令发现、首次 router 构建）几乎零成本收集。冻结前刻意不调用gc.collect()：对启动堆做一次全扫描约 210ms，却只能回收约 4% 的对象（几 MB），垃圾会和幸存者一起被冻结。

窗口必须总是关闭——长期进程中 GC 保持禁用意味着循环对象无界增长——所以有try/finally，并有守卫测试 test_boot_gc_window_reenables_and_freezes 断言manage.py启动后gc.isenabled()为真且冻结计数非零。

pytest 进程通过专用插件获得同样的窗口：pytest_boot_gc.py 在 pytest.ini 中以-p pytest_boot_gc注册。-p插件在 pytest-django 的load_initial_conftests钩子（即真正执行django.setup()的地方）之前加载，因此 disable 在 setup 的几百万次永久分配发生时已生效。根目录 conftest.py 中的_end_gc_boot_window在收集完成时负责关闭窗口（freeze、重新 enable、阈值调优），其自身的gc.disable()则作为未加载插件时的兜底。整体为每个测试进程节省约 0.2–0.4s。Celery 的django.setup()发生在其 Django fixup 内部，不在我们拥有的入口点里，所以 celery worker 暂时享受不到该窗口。

5. 生成式 schema 与查询层整体移出 setup

posthog.schema（生成的 pydantic 数据模型，导入约 2s）和 HogQL/query-runner 层过去因为几十个模型文件和ready()链在模块作用域导入它们，而随django.setup()一起加载。现在它们只在真正运行查询的进程中加载：Web pod 启动时仍会支付（wsgi/asgi 的 URLconf 预构建在 readiness 之后、pre-fork 完成），而 celery、temporal、migrate、shell 和 CI 都不再加载。两块保证成立：

• 枚举（约 270 个类）独立成模块：posthog/schema_enums.py 是单独的生成模块，导入只需约 20ms。bin/split-schema-enums.py 作为hogli build:schema的后处理步骤把枚举拆出，而posthog.schema会再导出全部名字，保持既有 import 兼容。
• 其余内容采用标准处理：仅需枚举的 import 改指向posthog.schema_enums；仅作注解的模型用法移到TYPE_CHECKING下用带引号注解；方法体内的使用改在调用时导入。

写模型文件或任何 setup 路径模块时的默认规则：枚举从posthog.schema_enums取；需要真正的 pydantic 模型时，在使用它的方法内部导入。Celery 任务图同理：posthog/tasks/init.py 急切导入每个任务模块以便 autodiscovery 注册，所以 setup 路径上任何模块级的from posthog.tasks...导入都会把它们全部拖进来——在调用点导入任务，并从容 posthog/celery_queues.py 取CeleryQueue（导入轻量，专为装饰器求值消费者设计）。

回归守卫：双保险把收益锁死在 CI

守卫一：命名清单 + 三向断言

posthog/test/repo_invariants/test_startup_import_budget.py 在干净子进程中启动一次裸django.setup()，针对每个机制断言一件事：

1. 无重模块混入：FORBIDDEN_AT_SETUP清单中的重模块（懒路由聚合器、生成的posthog.schema、query-runner 层、AI core、chdb、scipy等）不得出现在sys.modules中。当前清单见 test_startup_import_budget.py，涵盖了posthog.api.rest_router、posthog.temporal.ai、scipy、stripe、pandas、pyarrow、numpy、openai、anthropic、temporalio等 30 余项。
2. 模型都在 app-population 注册：导入 router 不应新增任何模型。
3. 信号接收器都在 setup 连接：构建 router 不应新增任何接收器。

该测试在repo-checksCI 作业中对每个触及后端的 PR 运行，与测试选择无关——因为纯 products 的 diff 会完全跳过 Django 套件。

守卫失败时，修 import，不要扩清单。延后违规的 import、补上缺失的models/__init__导入、或把接收器接到ready()。删掉一个条目来让测试通过，等于重新打开守卫原本要关上的门。清单是双向的：当你有意把某个重量级库移出启动路径时，把它加进FORBIDDEN_AT_SETUP，让收益无法静默回退。先确认该模块在裸django.setup()下确实缺席，再加。

守卫二：前瞻性守卫，拦住"还没人点名"的新重 import

FORBIDDEN_AT_SETUP只能抓住已被点名的模块；test_no_new_heavy_imports_at_setup 抓的是还没有人点名的新重 import。它用python -X importtime捕获裸 setup（GC 已禁用，防止迁移中的 gen2 停顿伪装成某模块的成本），第三方包按顶层包聚合（SDK 分散在多个子模块，包总量才是有效数字）、一方代码按模块计，当某个不在setup_import_baseline.txt 中的名字成本 ≥100ms时测试失败。

设计上没有逐条时间预算——绝对计时在 CI 中会抖动——时间只是"新来者"的重要度闸门：已知名字从不计时，新来者则是确定性的（引入该 import 的 PR 就是引入它的那一次）。执行两次捕获取每条的最小值，因为冷启动首次运行要付页缓存未命中，可能让包的表观成本翻倍。基线文件只记录 setup 真正需要的包（settings、models、celery app 等），并明确警告"这不是重 import 的批准清单"。

当它触发时：延后该 import（失败消息自带操作手册）；只有当每个进程确实在 setup 期间都需要该包时，才能将其加入基线，并附上理由注释。

正确做法，以及如何长期保持

启动路径是没有天然背压的共享资源：加一个普通 import 看起来毫不昂贵，而成本落在你本地根本不会运行的进程上。新增后端代码时把这些当作默认：

新增产品或 app

• 每个模型都从models/__init__.py注册。
• 信号接收器从AppConfig.ready()连接，而不是作为导入 viewset 的副作用。
• 保持ready()轻量——它在每个进程中运行，绝不能导入重子系统。

新增信号接收器

• 放在 setup 时就能连接的地方：所属 app 的AppConfig.ready()。
• 如果承载接收器的模块在模块作用域还导入了重东西，不要从ready()直接导入该模块——要么把重 import 延后到使用它的函数内部，要么把接收器移入轻量模块（signals.py、activity_logging.py）再从ready()导入那个轻量模块。
• 检验标准很简单：从ready()接线的模块只应拖入轻量依赖。
• 即使承载模块今天看起来轻量，也优先专用的轻量模块——API/viewset 模块会累积模块级 import，ready()会悄悄继承它们新增的一切。batch-exports 的ready()曾以"模块很轻"为由经 API 模块接线，后来该模块引入了直达每个目标 vendor SDK 的 import，django.setup()悄悄涨了约 1.6s。

新增重依赖（vendor SDK、Temporal/AI/ClickHouse 路径、任何拖入 pandas/pyarrow/scipy 的东西）

• 只在一条代码路径上使用，就在那条路径上函数级导入，带# noqa: PLC0415，而不是模块级导入。
• 模块级导入写起来"免费"，却要让每个传递导入该模块的进程永久付费。

新增 viewset 或路由

• 它不会再在django.setup()时加载。不要依赖导入它产生任何副作用（模型注册、接收器接线、monkeypatching）——这些必须放在 setup 时加载的地方。
• 新路由写进 posthog/api/rest_router.py（或产品的register_routes），永远不要再放回__init__.pyshim。

不确定某物是否重时

• 直接测量（见下一节）。一次 30 秒的importtime就能定论，猜测不行。

长期如何维持

• 守卫在 CI 上每个 PR 都运行，回归在评审时被抓到，而不是在生产环境。
• 守卫变红时的常备规则永远是"延后，不要扩宽"——清单是棘轮（ratchet），每条走错方向的条目都会永久让出一块收益。
• 即使守卫是绿的也要偶尔重新 profile：守卫只抓它点名的具体重模块，而基线会随代码库增长而上浮。当基线爬升后，杠杆还是老样子——找到最重的、setup 其实不需要的累积 import，延后它。

测量方法论

• 墙钟时间：在进程内部用time.perf_counter()包住django.setup()。不要给 shell 包装层计时——环境激活不属于这个数字。
• 设置TEST=1 DEBUG=1：让ready()跳过 redis/运行时 I/O。你要的是 import 成本，它在测试模式下与生产一致，而不是依赖环境的网络往返。
• 导入成本分解：python -X importtime+tuna查看树。叶子成本按模块**自身时间（self time）排序，子树成本按累积时间（cumulative）**排序。不要用 pyinstrument——它会把 import 成本抹散到importlib._bootstrap的帧里。
• importtime 的自身时间可能撒谎：GC 停顿会计到恰好正在执行的模块头上。约 100ms 的 gen2 收集在分配计数越过阈值处触发，importtime把它记为那个模块的自身时间——一个 400 行、全是字典字面量的模块曾显示 117ms，而且这个幽灵会在导入顺序变化时在模块间迁移（同一代码跑两次，归因到两个不同模块）。延后一个可疑昂贵的模块前先做 sanity check：无重导入的纯 Python 模块应只花微秒。决定性测试是前置gc.disable()重新捕获——如果成本消失，模块无辜，问题在 GC 而非导入。
• 找到重加载的触发器：monkeypatchbuiltins.__import__在目标模块首次导入时打印调用栈。profile 只能显示成本，无法说明它是否可移除——用 A/B 确认，因为模块常有多条可达路径，砍一条未必有效。
• 导入结构（当延后被阻塞时）：grimp构建模块导入图。有时你不能简单地延后某个重 import，因为它在循环导入中是承重墙——延后一条边只是搬移了循环。grimp的nominate_cycle_breakers会排序该砍哪条边，真正的工作变成先把所属包的循环解开，重 import 才能离开启动路径。

陷阱清单（每一个都引发过后续修复）

ready()把重子系统重新拖回启动路径——最常见的回归。你在AppConfig.ready()里通过导入承载模块来接线接收器，但那个模块在模块作用域导入了重依赖（billing/Stripe 客户端、Temporal 框架、AI core）。接收器连上了，重 import 也跟着连上了，前功尽弃。修复：把重 import 延后到使用它的方法内部（# noqa: PLC0415），或把接收器抽到ready()导入的轻量模块。务必重新测量——接线接收器和削减启动时间很容易做反。

静默的接收器丢失——接收器停止连接时没有任何报错，症状在下游且悄无声息（缓存停止失效、后台写时清理不再运行）。Web 服务器的冒烟测试不会暴露它，因为 Web 服务器会构建 router。在不构建 router 的进程中复现：manage.py shell、celery worker、migrate。

从注册表消失的模型——只能经 viewset import 触达的模型在 setup 时消失。失败是间接的：makemigrations看不到它、admin 丢掉它、django-stubs mypy 插件（通过django.setup()构建模型注册表）报"type[X]" has no attribute "objects"。把模型加进所属 app 的models/__init__.py。

注册变更后的过期dmypy——django-stubs mypy 插件把django.setup()快照缓存在守护进程中。更改 setup 时的注册内容后，先dmypy stop再重跑，否则你会追着旧模型注册表产生的幻影错误。

懒路由上的语义合并冲突——把聚合器移入rest_router.py的长期分支持续与仍在编辑旧急切posthog/api/__init__.py的 master 冲突（产品迁移把 viewset 模块从posthog/api移入products/）。Git 把 master 的聚合器增量放进__init__.py冲突，但该分支上这个文件是 shim。处方：保留 shim（对__init__.py用--ours），diff 合并基与旧聚合器的新版本以拿到确切的 import + 路由注册增量，移植进rest_router.py。承载ready()接线接收器的模块迁移时，把接线改指新产品的AppConfig.ready()，并保持重 import 延后。任一方在模块作用域移动或重命名另一方引用的模块时，同样会咬人——文本上干净的合并，导入时断裂。

移除急切导入链会暴露潜在循环导入——过去的急切 router 在posthog/urls.py加载时、在 urls.py 到达自己的产品导入之前就导入了一条大链。那条链常把某模块完整地提前导入，意外掩盖了别处的循环导入——它只是因为导入顺序才碰巧工作。router 变懒后意外预导入消失，下一个导入 URLconf 的进程直接撞上循环。真实案例：slack_app.backend.api从posthog_code_slack_mention导入 workflow 类，而后者又在模块作用域（用# noqa: E402放在末尾——有人已经跟顺序搏斗过的痕迹）从slack_app.backend.api反向导入 helper。预导入消失后，Django 系统检查（check_custom_error_handlers会导入 URLconf，例如ensure_migration_defaults期间）抛出cannot import name ... from partially initialized module。这事的凶险在于：它出现在离改动很远的地方（某个 CI 作业的 migration-defaults 步骤，而不是懒路由文件），而且有问题的代码不是你的——容易甩锅给 master。不要臆断：决定性测试是在干净子进程中django.setup()后import_module("posthog.urls")，在分离的origin/masterworktree 和分支上各跑一次。只有分支失败，就是你揭开了它，也由你负责修复——把反向引用延后到其调用点来打破循环。

包__init__聚合子模块，让每次子模块导入都挨刀——面向 worker 的聚合器（temporal/__init__.py导入所有目的地以构建WORKFLOWS/ACTIVITIES）会让任何import <pkg>.<submodule>都执行整个聚合——Python 总是先跑父包__init__。从某个目的地导入一张常量表，加载了十三个 vendor SDK。修复：把聚合器移到子模块（workflows.py），把__init__变成 PEP 562__getattr__shim。这个 shim 有两个坑（都吃过亏）：在包自身的__getattr__里from <pkg> import workflows会无限递归（_handle_fromlist重入__getattr__）——要用importlib.import_module；以及 catch-all 的__getattr__是错的：from <pkg> import <anything>会先探测包属性，catch-all 会在每次这类探测时急切加载聚合器——包括子模块名，若任何被聚合的模块经包根导入兄弟模块就会死锁（record_batch_model导入sql正是如此，被急切 init 的导入顺序掩盖了多年）。用白名单放行公开名字（if name in __all__），其余抛AttributeError，让子模块导入回落到正常解析。

DRF serializer 字段 kwargs 在导入时求值——serializer 字段里的choices=sorted(SUPPORTED_THINGS)在类定义时运行，也就是模块导入时——你无法在函数内延后它依赖的 import。如果常量住在重模块里（Temporal 目的地、SDK 包装），把常量移到导入轻的模块，两边都从那里导入；用旧名再导出，保持既有 import 者可用。

延后只是搬移成本——先看它落在哪里再宣布胜利——延后 import 没有删除工作，只是把它移到首次使用处，而首次使用可能是实时请求。对任何延后都要问：*哪个进程现在付费、在什么路径上、那条路径对延迟敏感吗？*后台 worker 懒加载几乎总是没问题；Web worker 在首个请求上付费通常不行。当首次使用对延迟敏感时，用有针对性的、按进程的预热把成本刻意搬回去，而不是为所有人重新急切化。warehouse source 目录（每个 vendor SDK 都懒，经SourceRegistry）就有两处：跑数据导入同步队列的 temporal worker 在启动时调load_all_sources()；Web worker 在 posthog/wsgi.py 模块导入时（启动 GC 窗口内）调用 posthog/warehouse_source_prewarm.py 预热（ASGI 则在 lifespan 启动时），受PREWARM_WAREHOUSE_SOURCE_REGISTRY开关控制——部署配置只为专门服务 warehouse 查询的 Granian 部署开启它（共享 launcher 保持关闭）。两者都在进程开始服务前同步预热；预热失败只记录日志、让 worker 走懒路径，其他进程则一直走懒路径。

生成 schema 上的 Pydanticdefer_build：尝试过并回退了——让posthog.schema基于defer_build基类生成，每次 setup 能省约 400ms 的 core-schema 构建，round-trip 测试里 validation、model_dump、model_json_schema、TypeAdapter全都按需构建，看起来安全。两个失败杀死了它。其一，成本搬移（上文）：Web pod 中延后的构建落在每次部署后每个 worker 的首个/query上——过去在启动时、readiness 探针之后、pre-fork 且 COW 共享地支付，而明显的预热循环实测比急切类创建贵约 2.5 倍（model_rebuild()逐模型重解析命名空间）。其二，致命的：query runner直接构造响应模型（无验证，触发不了懒构建），随后model_dump()把一个延后子模型的 mock serializer 经多态字段喂给 pydantic-core——TypeError: 'MockValSer' object cannot be converted to 'SchemaSerializer'，任何进程里都是硬 500。单模型的 round-trip 测试抓不到它：对defer_build而言，序列化矩阵（构造后 dump、子类经父类、Any类型字段）才是测试面。schema 在导入时约 1.8s 的成本是真实且结构性的——最终靠把模块整体移出 setup（机制 5）解决，而不是延后构建。

消失的再导出——当模块不再在模块作用域导入某个名字（移入TYPE_CHECKING、延后到调用时、或重新生成时被丢弃），所有别处from that_module import name都会断掉——而消费方在导入前不可见，因为他们是在碰巧持有该名字的模块里顺带导入它的。本次剥离就撞上了测试文件里的from posthog.hogql.modifiers import HogQLQueryModifiers：好几年没事，modifiers 不再绑定该名字的那天 ImportError。解除绑定前，grep 每一种导入形式——包括from package import module和from ...schema import相对导入拼写（^from posthog\.schema import这种正则会漏）——并把消费方改指定义模块。

patch 模块属性的测试在 import 移到调用时后失效——@patch("some.module.helper")替换的是模块对象上的属性；函数在调用时做from elsewhere import helper永远不会读那个属性，所以 patch 静默失效，测试里跑的是真实代码。这曾在一周内引发三轮后续修复（conversations 的 person 查找和 groups 查找、LLM-gateway 的 policy 任务、subscription 的 free-tier 常量）。修测试，不要改延后：在名字被读取的地方 patch——定义模块（@patch("posthog.hogql.query.execute_hogql_query")），调用时的 import 会在 patch 就位后于调用时解析它。对经 PEP 562__getattr__解析的懒模块常量，用getattr(sys.modules[__name__], ...)读取而不是裸全局，这样被 patch 的属性仍会生效。

在坏合并之上重新生成共享快照——查询计数快照文件（.ambr）是生成的。两个分支都改了同一个时，任何一边的版本对合并后的代码都不正确——针对合并后的分支重新生成，而不是挑一边。重新生成后确认它没有掩盖回归：makemigrations --check干净、期望的列仍在、查询集合未变（大量的 "updated" 计数通常是某个查询移位引起的良性重编号）。

量的是包装层而不是工作本身——给先激活环境再执行的命令计时，会把激活成本折进数字里。在进程内部测量。另外，裸python /tmp/script.py找不到包时，是sys.path的问题（脚本目录而非仓库）——设PYTHONPATH，别得出"环境坏了"的结论。

结语：把启动路径当作需要守护的公共资源

PostHog 的经验表明，Django 大型代码库的启动性能不是一个一次性工程，而是一个需要机制 + 守卫 + 纪律三足支撑的长期治理过程：五大机制负责把重子系统搬下启动路径，双回归守卫在 CI 中锁住收益并拦截未知的新重导入，而"延后，不要扩宽"的棘轮纪律与本文的踩坑清单则让每个新加入的开发者都能在不破坏全局的前提下提交代码。对任何运行django.setup()的进程来说，每次启动节省的数百毫秒，乘以 Web、Celery、Temporal、迁移和每一次 CI 运行，就是整个平台每天实实在在省下的时间。

【免费下载链接】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