在 PostHog 中通过 MCP 工具管理 Streamlit 应用完整生命周期实战指南【免费下载链接】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/posthogStreamlit 应用是运行在 PostHog 隔离沙箱中的 Python 数据应用它的创建、部署、启动、更新到分享的完整生命周期全部由streamlit-apps-*系列 MCP 工具驱动。本文以仓库中 managing-streamlit-apps 技能文档 为主体骨架结合 backend 源码 与 MCP 工具定义讲解如何用 Agent 或开发者快速创建一个 Streamlit 应用部署数据应用重启/停止应用排查应用未运行以及获取应用链接并深入剖析背后的版本机制、权限模型与资源配额原理。核心概念应用、版本与沙箱的三层模型在 PostHog 中一个 Streamlit 应用由三个相互独立、彼此解耦的实体构成理解这三者的关系是掌握全部管理操作的前提实体数据模型说明应用AppStreamlitApp应用元数据名称、描述、CPU/内存配置、short_id本身不携带代码版本VersionStreamlitAppVersion代码的不可变快照以 zip 形式存储每个应用同时只允许一个激活版本active_version沙箱SandboxStreamlitAppSandbox隔离的运行环境一个沙箱进程专门服务当前的激活版本上述映射关系可以在 数据模型文件 中直接确认StreamlitApp通过外键active_version指向StreamlitAppVersion并与StreamlitAppSandbox构成一对一关系。沙箱状态是一个明确的状态机只有五个取值starting— 沙箱正在创建/引导running— 沙箱正在服务激活版本stopping— 正在停止stopped— 已停止正常状态不是错误error— 启动失败或运行异常此时应读取last_error字段定位原因全流程速览create → set-source → start → share技能的快乐路径happy path是 Agent 创建并交付一个应用的标准操作序列每一步对应一个 MCP 工具streamlit-apps-create仅创建应用元数据。传入name必填可选description、cpu_cores0.25–8、memory_gb0.5–16。此刻应用存在但没有代码启动前必须先设置源码。streamlit-apps-set-source将完整的app.py源码作为一个字符串传入即可创建并激活版本 1。额外文件通过同一调用的两个映射参数携带files以项目相对路径映射纯文本辅助模块、CSV、JSONassets以项目相对路径映射 base64Parquet、图片。源码的编写规范遵循 writing-streamlit-apps 技能其中最关键的一条是读取 PostHog 数据必须使用posthog_apps.query()绝不能import posthog该模块在沙箱内不存在这是刻意的安全设计。streamlit-apps-start立即返回HTTP 202沙箱在后台异步引导无需同步等待。轮询streamlit-apps-status直到status变为running通常远小于一分钟。如果最终落到error读取last_error字段并参考下文故障排查。分享应用create/get/start 返回的_posthogUrl形如/streamlit-apps/{short_id}就是该应用在 PostHog 中的页面地址把它交给人类用户即可。应用没有公开 URL页面在需要登录的 iframe 中渲染查看者必须已登录 PostHog 且对该项目有访问权限。为什么 set-source 一步就能激活从源码看set-source底层走的是 create_version_from_source 门面函数它把source、files、assets统一打包成与 zip 上传完全相同的结构build_app_zip再复用upload_version的校验、存储、版本化与沙箱停止逻辑。因此文本源码、文件附件和 zip 上传最终走的是同一条验证与存储管线保证三种入口得到的产物等价。完整 MCP 工具清单与作用域以下工具全部定义于 MCP 工具清单统一挂在feature: streamlit_apps、URL 前缀/streamlit-apps下工具操作说明所需权限streamlit-apps-create创建应用仅元数据无代码streamlit_app:writestreamlit-apps-set-source从源码创建并激活版本文本源码 files/assetsstreamlit_app:writequery:readstreamlit-apps-start启动沙箱幂等异步引导streamlit_app:writequery:readstreamlit-apps-status查询沙箱状态starting/running/stopping/stopped/errorrestart_countlast_errorstreamlit_app:readstreamlit-apps-list列出项目内所有应用返回short_id、名称、描述、资源配置、沙箱状态streamlit_app:readstreamlit-apps-get获取单个应用含激活版本与实时沙箱状态streamlit_app:readstreamlit-apps-versions列出版本最新在前每个版本是代码的不可变快照streamlit_app:readstreamlit-apps-update更新元数据/规格名称、描述、cpu_cores、memory_gb仅更新传入字段streamlit_app:writestreamlit-apps-stop停止沙箱幂等不影响代码与版本streamlit_app:writestreamlit-apps-delete软删除应用先停止沙箱再软删除streamlit_app:write值得注意的细节set-source、start、restart等工具要求query:read与streamlit_app:write双重权限。这是因为沙箱桥接层会以激活版本作者的身份执行 HogQL 查询详见下文权限模型视图层代码 中的_QUERY_CAPABLE_WRITE_ACTIONS集合明确列出了upload_version、create_version_from_source、activate_version、start、restart这几类既能上传代码、又能让代码跑起来的动作防止仅有streamlit_app权限的令牌通过上传代码间接升级为 HogQL 数据读取权限。工具启用与灰度所有已启用的工具都挂在feature_flag: streamlit-apps之后如果所在组织的streamlit-apps功能开关未打开所有工具调用都会返回 403 Streamlit apps is not available.。这是发布灰度门属于平台侧配置不是代码错误Agent 遇到时应直接告知用户而不是反复重试。资源配置CPU 与内存的取值边界创建create与更新update工具都接受两个资源参数范围在 数据模型常量 中有硬编码约束参数最小值最大值默认值cpu_cores0.2580.5memory_gb0.5161默认配置0.5 CPU / 1 GB足以支撑典型的 dashboard 应用。门面层 _validate_resource_bounds 会拦截越界值并返回 400而在真正创建沙箱时app_runtime.py 的_build_sandbox_config还会用min(max(...))再次做夹取双保险确保配置落在合法区间。何时需要加大内存一个容易踩的误区加大memory_gb只在应用自身需要在内存中持有大型 DataFrame 时有意义。沙箱桥接查询HogQL bridge的 256 MB 内存上限是服务端侧限制不随沙箱规格变化——来自 bridge.py 的常量单次查询执行上限 30 秒、内存上限 256 MB、读取字节上限 5 GB。因此查询失败靠加大沙箱内存是修不好的正确的做法是收敛查询本身限定时间范围、加LIMIT、尽量在 HogQL 里聚合而不是把原始事件拉进 pandas。数据访问与权限模型应用读的是谁的数据这是整个功能最核心的安全语义必须准确理解应用内查询以激活版本作者version author的数据访问权限执行。也就是说设置源码的人是谁应用读到的数据范围就是谁的设置完源码后应用能读到的就是你能读到的。任何能查看该应用的人都会看到这些查询结果。因此发布一个应用等同于把这份数据分享给项目里的所有人——在把应用交给别人查看之前先确认查询结果中没有越权或敏感数据。如果激活版本的作者账号已被删除应用将无法启动这是确定性行为而非偶发故障。修复方式是上传一个新版本重新set-source新版本即新作者。从源码可以印证这一点app_runtime.py 的start_app在构建任何沙箱之前就检查version.created_by作者不存在则直接抛出AppRuntimeError而 bridge.py 的execute_bridge_query会把令牌签发用户作为 HogQL 查询的user上下文传入——仓库表/视图的 ACL 在没有用户上下文时会 fail-closed 全部拒绝这样既不会误放行也不会绕过表级 RBAC。更新代码版本机制、自动清理与无回滚设计更新应用代码同样调用streamlit-apps-set-source每次调用都会创建下一个版本号并激活它。由于每次调用携带的是完整应用files和assets必须原样再传一遍——一个版本只包含它自己那次调用所携带的内容不会与旧版本合并。正在运行的沙箱会被自动停止防止它继续服务旧代码随后需要调用streamlit-apps-start才能让新版本上线。这正是应用显示旧代码这类问题的根源漏掉了 set-source 之后的 start 步骤。版本的生命周期约束版本不可变但非永久streamlit-apps-versions最多列出最新的 50 个版本非激活版本在超过 30 天后连同其代码被删除。后台清理任务 prune_old_streamlit_app_versions 按created_at与_VERSION_RETENTION_DAYS 30筛选并删除过期 zip。没有回滚工具要回滚只能把旧版本的source、files、assets重新设置一遍。因此回滚必须事先保存完整 bundle 的副本——版本库里存的是 zip不提供内联源码视图所以副本只能来自会话记录或其他保存位置。顺带一提软删除应用的历史 zip 也有保留期7 天由 cleanup_deleted_streamlit_app_zips 负责硬删除避免对象存储无限膨胀。停止、空闲回收与删除streamlit-apps-stop停止沙箱进程代码与版本完全不受影响。之后随时可以再次启动成本很低。空闲自动回收沙箱在一段时间无活动后会被自动停止后台任务 stop_idle_streamlit_sandboxes 的_IDLE_TIMEOUT_MINUTES 30以last_activity_at或启动时间started_at中较新的为准。所以应用处于 stopped 状态是正常现象而非错误需要时重新 start 即可。此外每个沙箱本身还有 15 分钟的 TTLttl_seconds60 * 15见 app_runtime.py超时死亡后由 auto_restart_crashed_streamlit_sandboxes 依据MAX_RESTART_COUNT 3的上限自动重启应用级restart_count在健康运行 5 分钟后才归零防止崩溃循环绕过上限。streamlit-apps-delete停止任何运行中的沙箱然后软删除应用deletedTruedeleted_at见 facade/api.py 的 delete_app。删除是不可逆操作Agent 删除任何非本次会话中自己创建的应用之前必须先与用户确认。重命名与调整规格streamlit-apps-updatestreamlit-apps-update用于修改应用的名称、描述、cpu_cores0.25–8或memory_gb0.5–16只修改调用时显式传入的字段未传字段保持不变。两个关键行为新的规格在沙箱下一次启动时才生效因此对一个正在运行的应用调整规格后需要 stop start 才会应用新配置。代码变更不走这个工具一律通过streamlit-apps-set-source。故障排查速查表现象原因与处理status: errorlast_error为Start failed: ...沙箱供给或引导失败。先重试一次streamlit-apps-start若仍失败把last_error完整呈现给用户——这类供给失败通常是平台侧而非应用侧问题工具调用返回 403Streamlit apps is not available.组织未开启streamlit-apps功能开关。这是发布灰度门非代码错误告知用户即可应用在运行但应用内某个查询失败属于应用代码问题参考 writing-streamlit-apps 技能。桥接限制单查询 30 秒执行、256 MB 内存set-source 后应用仍显示旧代码跳过了set-source 之后 start这一步——沙箱已被停止需要重新启动深入原理一次启动背后发生了什么结合 app_runtime.pystreamlit-apps-start的立即返回 异步引导并非魔法而是由 Celery 生命周期任务 run_streamlit_app_lifecycle 驱动的一套可观测流程并发去重数据库行加锁若沙箱已处于running/starting则直接返回保证 start 幂等。冷启动 vs 热启动若激活版本已有snapshot_id此前冷启动生成的镜像快照直接复用镜像跳过文件上传否则把 zip 解包写入/app受 zip 校验器 约束zip 压缩包最大 10 MB、解压后最大 100 MB、最多 500 个文件、根目录必须有app.py并创建快照供后续热启动。安全引导写入桥接 bearer token/run/bridge_token权限 600仅 root 可读启动认证代理streamlit_auth_proxy.py端口 8080以非 root 的streamlit用户运行streamlit run /app/app.py --server.port 8501。双健康检查先轮询代理/healthz30 秒期限再轮询 Streamlit/_stcore/health60 秒期限两者都通过才把状态置为running任何一步失败都会把沙箱标记为error并写入last_error同时销毁已创建的沙箱实例。这套流程解释了原技能文档中启动异步、需轮询状态以及错误信息多以Start failed: ...开头的由来——last_error里承载的正是start_app抛出的运行时错误字符串。小结在 PostHog 中管理 Streamlit 应用本质上是围绕应用 / 版本 / 沙箱三模型用streamlit-apps-*MCP 工具完成创建 → 设源码 → 启动 → 轮询 → 分享的闭环。掌握版本不可变与 30 天清理、数据权限跟随版本作者、资源规格与桥接查询限额的边界就能稳定交付、更新与运维数据应用并快速定位绝大多数运行问题。建议继续阅读 writing-streamlit-apps 技能文档 学习应用内代码的最佳实践让部署的每个应用既好用又安全。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 在 PostHog 中通过 MCP 工具管理 Streamlit 应用：完整生命周期实战指南
在 PostHog 中通过 MCP 工具管理 Streamlit 应用完整生命周期实战指南【免费下载链接】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/posthogStreamlit 应用是运行在 PostHog 隔离沙箱中的 Python 数据应用它的创建、部署、启动、更新到分享的完整生命周期全部由streamlit-apps-*系列 MCP 工具驱动。本文以仓库中 managing-streamlit-apps 技能文档 为主体骨架结合 backend 源码 与 MCP 工具定义讲解如何用 Agent 或开发者快速创建一个 Streamlit 应用部署数据应用重启/停止应用排查应用未运行以及获取应用链接并深入剖析背后的版本机制、权限模型与资源配额原理。核心概念应用、版本与沙箱的三层模型在 PostHog 中一个 Streamlit 应用由三个相互独立、彼此解耦的实体构成理解这三者的关系是掌握全部管理操作的前提实体数据模型说明应用AppStreamlitApp应用元数据名称、描述、CPU/内存配置、short_id本身不携带代码版本VersionStreamlitAppVersion代码的不可变快照以 zip 形式存储每个应用同时只允许一个激活版本active_version沙箱SandboxStreamlitAppSandbox隔离的运行环境一个沙箱进程专门服务当前的激活版本上述映射关系可以在 数据模型文件 中直接确认StreamlitApp通过外键active_version指向StreamlitAppVersion并与StreamlitAppSandbox构成一对一关系。沙箱状态是一个明确的状态机只有五个取值starting— 沙箱正在创建/引导running— 沙箱正在服务激活版本stopping— 正在停止stopped— 已停止正常状态不是错误error— 启动失败或运行异常此时应读取last_error字段定位原因全流程速览create → set-source → start → share技能的快乐路径happy path是 Agent 创建并交付一个应用的标准操作序列每一步对应一个 MCP 工具streamlit-apps-create仅创建应用元数据。传入name必填可选description、cpu_cores0.25–8、memory_gb0.5–16。此刻应用存在但没有代码启动前必须先设置源码。streamlit-apps-set-source将完整的app.py源码作为一个字符串传入即可创建并激活版本 1。额外文件通过同一调用的两个映射参数携带files以项目相对路径映射纯文本辅助模块、CSV、JSONassets以项目相对路径映射 base64Parquet、图片。源码的编写规范遵循 writing-streamlit-apps 技能其中最关键的一条是读取 PostHog 数据必须使用posthog_apps.query()绝不能import posthog该模块在沙箱内不存在这是刻意的安全设计。streamlit-apps-start立即返回HTTP 202沙箱在后台异步引导无需同步等待。轮询streamlit-apps-status直到status变为running通常远小于一分钟。如果最终落到error读取last_error字段并参考下文故障排查。分享应用create/get/start 返回的_posthogUrl形如/streamlit-apps/{short_id}就是该应用在 PostHog 中的页面地址把它交给人类用户即可。应用没有公开 URL页面在需要登录的 iframe 中渲染查看者必须已登录 PostHog 且对该项目有访问权限。为什么 set-source 一步就能激活从源码看set-source底层走的是 create_version_from_source 门面函数它把source、files、assets统一打包成与 zip 上传完全相同的结构build_app_zip再复用upload_version的校验、存储、版本化与沙箱停止逻辑。因此文本源码、文件附件和 zip 上传最终走的是同一条验证与存储管线保证三种入口得到的产物等价。完整 MCP 工具清单与作用域以下工具全部定义于 MCP 工具清单统一挂在feature: streamlit_apps、URL 前缀/streamlit-apps下工具操作说明所需权限streamlit-apps-create创建应用仅元数据无代码streamlit_app:writestreamlit-apps-set-source从源码创建并激活版本文本源码 files/assetsstreamlit_app:writequery:readstreamlit-apps-start启动沙箱幂等异步引导streamlit_app:writequery:readstreamlit-apps-status查询沙箱状态starting/running/stopping/stopped/errorrestart_countlast_errorstreamlit_app:readstreamlit-apps-list列出项目内所有应用返回short_id、名称、描述、资源配置、沙箱状态streamlit_app:readstreamlit-apps-get获取单个应用含激活版本与实时沙箱状态streamlit_app:readstreamlit-apps-versions列出版本最新在前每个版本是代码的不可变快照streamlit_app:readstreamlit-apps-update更新元数据/规格名称、描述、cpu_cores、memory_gb仅更新传入字段streamlit_app:writestreamlit-apps-stop停止沙箱幂等不影响代码与版本streamlit_app:writestreamlit-apps-delete软删除应用先停止沙箱再软删除streamlit_app:write值得注意的细节set-source、start、restart等工具要求query:read与streamlit_app:write双重权限。这是因为沙箱桥接层会以激活版本作者的身份执行 HogQL 查询详见下文权限模型视图层代码 中的_QUERY_CAPABLE_WRITE_ACTIONS集合明确列出了upload_version、create_version_from_source、activate_version、start、restart这几类既能上传代码、又能让代码跑起来的动作防止仅有streamlit_app权限的令牌通过上传代码间接升级为 HogQL 数据读取权限。工具启用与灰度所有已启用的工具都挂在feature_flag: streamlit-apps之后如果所在组织的streamlit-apps功能开关未打开所有工具调用都会返回 403 Streamlit apps is not available.。这是发布灰度门属于平台侧配置不是代码错误Agent 遇到时应直接告知用户而不是反复重试。资源配置CPU 与内存的取值边界创建create与更新update工具都接受两个资源参数范围在 数据模型常量 中有硬编码约束参数最小值最大值默认值cpu_cores0.2580.5memory_gb0.5161默认配置0.5 CPU / 1 GB足以支撑典型的 dashboard 应用。门面层 _validate_resource_bounds 会拦截越界值并返回 400而在真正创建沙箱时app_runtime.py 的_build_sandbox_config还会用min(max(...))再次做夹取双保险确保配置落在合法区间。何时需要加大内存一个容易踩的误区加大memory_gb只在应用自身需要在内存中持有大型 DataFrame 时有意义。沙箱桥接查询HogQL bridge的 256 MB 内存上限是服务端侧限制不随沙箱规格变化——来自 bridge.py 的常量单次查询执行上限 30 秒、内存上限 256 MB、读取字节上限 5 GB。因此查询失败靠加大沙箱内存是修不好的正确的做法是收敛查询本身限定时间范围、加LIMIT、尽量在 HogQL 里聚合而不是把原始事件拉进 pandas。数据访问与权限模型应用读的是谁的数据这是整个功能最核心的安全语义必须准确理解应用内查询以激活版本作者version author的数据访问权限执行。也就是说设置源码的人是谁应用读到的数据范围就是谁的设置完源码后应用能读到的就是你能读到的。任何能查看该应用的人都会看到这些查询结果。因此发布一个应用等同于把这份数据分享给项目里的所有人——在把应用交给别人查看之前先确认查询结果中没有越权或敏感数据。如果激活版本的作者账号已被删除应用将无法启动这是确定性行为而非偶发故障。修复方式是上传一个新版本重新set-source新版本即新作者。从源码可以印证这一点app_runtime.py 的start_app在构建任何沙箱之前就检查version.created_by作者不存在则直接抛出AppRuntimeError而 bridge.py 的execute_bridge_query会把令牌签发用户作为 HogQL 查询的user上下文传入——仓库表/视图的 ACL 在没有用户上下文时会 fail-closed 全部拒绝这样既不会误放行也不会绕过表级 RBAC。更新代码版本机制、自动清理与无回滚设计更新应用代码同样调用streamlit-apps-set-source每次调用都会创建下一个版本号并激活它。由于每次调用携带的是完整应用files和assets必须原样再传一遍——一个版本只包含它自己那次调用所携带的内容不会与旧版本合并。正在运行的沙箱会被自动停止防止它继续服务旧代码随后需要调用streamlit-apps-start才能让新版本上线。这正是应用显示旧代码这类问题的根源漏掉了 set-source 之后的 start 步骤。版本的生命周期约束版本不可变但非永久streamlit-apps-versions最多列出最新的 50 个版本非激活版本在超过 30 天后连同其代码被删除。后台清理任务 prune_old_streamlit_app_versions 按created_at与_VERSION_RETENTION_DAYS 30筛选并删除过期 zip。没有回滚工具要回滚只能把旧版本的source、files、assets重新设置一遍。因此回滚必须事先保存完整 bundle 的副本——版本库里存的是 zip不提供内联源码视图所以副本只能来自会话记录或其他保存位置。顺带一提软删除应用的历史 zip 也有保留期7 天由 cleanup_deleted_streamlit_app_zips 负责硬删除避免对象存储无限膨胀。停止、空闲回收与删除streamlit-apps-stop停止沙箱进程代码与版本完全不受影响。之后随时可以再次启动成本很低。空闲自动回收沙箱在一段时间无活动后会被自动停止后台任务 stop_idle_streamlit_sandboxes 的_IDLE_TIMEOUT_MINUTES 30以last_activity_at或启动时间started_at中较新的为准。所以应用处于 stopped 状态是正常现象而非错误需要时重新 start 即可。此外每个沙箱本身还有 15 分钟的 TTLttl_seconds60 * 15见 app_runtime.py超时死亡后由 auto_restart_crashed_streamlit_sandboxes 依据MAX_RESTART_COUNT 3的上限自动重启应用级restart_count在健康运行 5 分钟后才归零防止崩溃循环绕过上限。streamlit-apps-delete停止任何运行中的沙箱然后软删除应用deletedTruedeleted_at见 facade/api.py 的 delete_app。删除是不可逆操作Agent 删除任何非本次会话中自己创建的应用之前必须先与用户确认。重命名与调整规格streamlit-apps-updatestreamlit-apps-update用于修改应用的名称、描述、cpu_cores0.25–8或memory_gb0.5–16只修改调用时显式传入的字段未传字段保持不变。两个关键行为新的规格在沙箱下一次启动时才生效因此对一个正在运行的应用调整规格后需要 stop start 才会应用新配置。代码变更不走这个工具一律通过streamlit-apps-set-source。故障排查速查表现象原因与处理status: errorlast_error为Start failed: ...沙箱供给或引导失败。先重试一次streamlit-apps-start若仍失败把last_error完整呈现给用户——这类供给失败通常是平台侧而非应用侧问题工具调用返回 403Streamlit apps is not available.组织未开启streamlit-apps功能开关。这是发布灰度门非代码错误告知用户即可应用在运行但应用内某个查询失败属于应用代码问题参考 writing-streamlit-apps 技能。桥接限制单查询 30 秒执行、256 MB 内存set-source 后应用仍显示旧代码跳过了set-source 之后 start这一步——沙箱已被停止需要重新启动深入原理一次启动背后发生了什么结合 app_runtime.pystreamlit-apps-start的立即返回 异步引导并非魔法而是由 Celery 生命周期任务 run_streamlit_app_lifecycle 驱动的一套可观测流程并发去重数据库行加锁若沙箱已处于running/starting则直接返回保证 start 幂等。冷启动 vs 热启动若激活版本已有snapshot_id此前冷启动生成的镜像快照直接复用镜像跳过文件上传否则把 zip 解包写入/app受 zip 校验器 约束zip 压缩包最大 10 MB、解压后最大 100 MB、最多 500 个文件、根目录必须有app.py并创建快照供后续热启动。安全引导写入桥接 bearer token/run/bridge_token权限 600仅 root 可读启动认证代理streamlit_auth_proxy.py端口 8080以非 root 的streamlit用户运行streamlit run /app/app.py --server.port 8501。双健康检查先轮询代理/healthz30 秒期限再轮询 Streamlit/_stcore/health60 秒期限两者都通过才把状态置为running任何一步失败都会把沙箱标记为error并写入last_error同时销毁已创建的沙箱实例。这套流程解释了原技能文档中启动异步、需轮询状态以及错误信息多以Start failed: ...开头的由来——last_error里承载的正是start_app抛出的运行时错误字符串。小结在 PostHog 中管理 Streamlit 应用本质上是围绕应用 / 版本 / 沙箱三模型用streamlit-apps-*MCP 工具完成创建 → 设源码 → 启动 → 轮询 → 分享的闭环。掌握版本不可变与 30 天清理、数据权限跟随版本作者、资源规格与桥接查询限额的边界就能稳定交付、更新与运维数据应用并快速定位绝大多数运行问题。建议继续阅读 writing-streamlit-apps 技能文档 学习应用内代码的最佳实践让部署的每个应用既好用又安全。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考