Launch HN: HyperProbe (YC S26) – 在生产环境中进行只读调试的智能体

# HyperProbe — 你的 24/7 AI 值班代理 来源：https://www.hyperprobe.co/ HyperProbe (https://www.hyperprobe.co/)Y 由 Y Combinator 支持 · AI 值班代理 02:47 AM · order-service · 847 次失败 / 10 分钟 · @priya 收到呼叫 已触发 ## 你的工程师不是为了*值班*才加入公司的。 他们在作战室度过的每一小时，都是没有在构建产品的一小时。HyperProbe 替他们处理事件，在他们打开笔记本电脑之前，就已经从告警推进到确认根因。 Node.js · TypeScript · Java · Python · 兼容 Cursor、Claude Code、Codex、Opencode 01 ### 你最优秀的工程师在值班，产品路线图却在滑步。 事件不只是搞垮生产环境，它们还会搞垮你的路线图。你最优秀的工程师变成了你的值班团队，每花一小时调试，就少一小时构建。 02 ### 你“修复”了事件，却完全不知道原因。 热修复只是有根据的猜测。没人确认到底是什么导致了问题。如果下周出现同样的条件，同样的事件会再次触发。 03 ### 修复只需 10 分钟，找到问题却要花几个小时。 事件每多持续一分钟，代价就多一分。修复只需要几分钟，但找到问题却要几小时，因为能解释失败的那个值，从来不会被记录。 解决方案 ## 这个 AI 负责处理事件，你的工程师不必亲力亲为。 HyperProbe 让你的编码代理在生产环境出问题的确切代码行上放置一个只读探针。它能捕获你的日志没有的数据，无需重新部署或重启服务。 其他所有工具都是在你已有的数据上拼命推理。HyperProbe 捕获的是确凿证据。 3 到 4 小时 → <10 分钟 —— 定位根因时间 3 到 4 → 0 —— 每次事件的重新部署次数 2 到 3 → 0 —— 参与调查的高级工程师人数 “同步问题以前要花好几天才能本地复现。HyperProbe 第一次就抓住了生产环境中的静默数据不匹配。” “在流量高峰期，我们的列表服务把失败完全黑盒化了。HyperProbe 让我们在流量尖峰时检查实时内存状态。我们在同一小时内就修复了竞态条件。” Bhagwan Bansal SDE，Housing.com 工作原理 ## 事件触发时会发生什么。 01 告警 自动从 PagerDuty、Datadog 或 Slack 接收告警。 02 规划 读取日志和链路追踪，自动定位有问题的文件和代码行，并规划调试流程。 03 探针 日志不够用？在可疑代码行上放置一个只读虚拟断点。无需重新部署。 04 捕获 断点在实时流量上触发。捕获该代码行处的精确变量状态。 05 确认 根据真实证据验证诊断结果。交付已确认的 RCA。 什么是探针？ 探针是运行中服务在特定代码行处的**只读、非阻塞的实时变量状态快照**。它会在真实流量上触发，捕获当时的精确值，捕获后即消失。你的服务永不暂停，对用户零影响。 #### 始终只读。 代理只捕获状态，不能写入内存或执行代码。每个探针都会记录在不可篡改的审计日志中。在你信任它之前，需要审批授权。 #### 运行在你的基础设施内部。 自托管或私有 VPC。任何数据都不会离开你的环境。PII 在捕获之前于代理端脱敏。你的安全团队定义哪些内容可以被观测。 #### 零线程暂停。 断点异步触发。请求以全速完成，用户毫无感知。在 3,000 RPS 下开销小于 1%。 我们覆盖的场景 ## 有些故障永远不会呼叫你。 没有异常，没有告警。即使是最难找的问题，HyperProbe 也能出色应对。 #### 静默失败 返回 200 但响应内容错误。链路追踪全部绿色。那个值从未被记录。 #### 异常离真正原因很远 堆栈跟踪指向第 82 行。真正原因在第 18 行，或者在另一个文件里。 #### 行为错误，却没有任何异常抛出 异常被捕获并被吞掉。没有告警，没有报错，只是业务指标发生变化。 #### 竞态与重复处理 需要重叠发生那一刻的线程状态。没有任何日志会记录这个。 #### 第三方契约漂移 供应商新增了字段或状态值，你的解析器没有对应的处理分支。 #### 业务指标下降 支付失败、订单减少。堆栈中任何地方都没有异常。 本月上线：内存泄漏诊断 · OOM 根因 · CPU 尖峰隔离 · 延迟尖峰追踪 一次真实事件，从头到尾 ## 从告警到根因，无需作战室。 这不是功能演示。这就是 HyperProbe 替你处理事件时实际发生的全过程。 02:47 AM 告警触发 ### 订单状态错误率升高，23% 的请求失败。 PagerDuty 触发告警。GET /api/orders/{id}/status 对近四分之一的请求返回 500。最近 10 分钟有 847 次失败。日志中没有异常。 PagerDuty 告警 高错误率 · order-service GET /api/orders/{id}/status · 500 · 23% 错误率 847 次失败 / 10 分钟 · 超过阈值 02:48 AM 侦察 ### HyperProbe 跟随链路追踪，发现上游一次静默写入失败。 HyperProbe 读取分布式链路追踪并跟随失败链路。订单服务正常。下游支付服务返回 404。支付在支付网关中存在，但在系统中不存在。 失败请求的链路追踪 GET /api/orders/{id}/status 500 └── GET payment-service/api/getPaymentsByOrder/{orderId} 404 支付在支付网关中存在，在系统中却找不到。某次写入在上游某个位置静默失败了。 02:49 AM 探针放置 ### HyperProbe 在 webhook 处理器上放置了一个虚拟断点。 HyperProbe 发现支付是在支付网关调用 webhook 时被记录的。在 /src/api/webhooks.ts 第 78 行的 webhook 处理器上放置了一个虚拟断点。无需重新部署，服务持续运行。 探针已激活 POST /api/webhooks/payments 文件：/src/api/webhooks.ts · 第 78 行 非阻塞 · 只读 · 无需重新部署 02:50 AM 发现 Bug ### 快照在 webhook 触发的精确时刻捕获了实时请求。 网关正在发送 PENDING。代码中没有处理这个状态的分支。幂等检查在确认状态之前就把支付标记为已处理。支付从未写入数据库。没有任何异常触发。 实时快照 · webhooks.ts:78 · 捕获于 02:50:14 UTC status="PENDING" ← 支付网关发送了这个值，但没有任何处理器 duplicate=null ← 首次出现，通过了检查 db.insert → 从未被调用 redis.set → 仍然被调用，支付被永久锁定 支付网关开始发送 PENDING——你的代码从未处理过的状态。幂等键在状态被检查之前就已写入。支付被标记为已处理，却从未被记录。 02:52 AM 修复建议 ### 根因已确认，修复方案就绪。距离告警仅 5 分钟。 支付网关开始发送 PENDING——你的代码从未处理过的状态。幂等键在状态被检查之前就已写入。支付被标记为已处理，却从未被记录。 前后对比 ## 同一次事件，两种现实。 你最优秀的工程师不应该成为你的值班团队。HyperProbe 处理调查工作，让他们回去构建产品。 没有 HyperProbe 02:47 AM 告警触发，工程师被呼叫。 02:50 AM 堆栈跟踪指向第 82 行。但导致问题的变量是在上面几帧设置的，在另一个文件里。那里没有任何日志捕获它。 03:10 AM 定位到那一帧，但变量值不可见。添加一条日志来捕获它。 03:40 AM CI/CD 部署。30 分钟过去了。等待条件在生产环境重现。 04:15 AM 第一条日志可见，数据不完整。不够。再加一条日志。又一个 30 分钟的部署周期。 05:20 AM 经过 2 到 3 次重新部署周期后，根因确认。耗时 2 小时 33 分钟。 有 HyperProbe 02:47 AM 告警触发，HyperProbe 接管。 02:48 AM HyperProbe 使用你的编码代理定位探针应该放置的确切帧。全程在后台进行。 02:49 AM HyperProbe 在那一行激活一个虚拟断点。无需重新部署。 02:53 AM 断点在下一个请求时安全触发，精确的变量值被捕获。服务持续运行。 02:56 AM 根因确认。从告警到有证据支撑的诊断，仅 9 分钟。 03:00 AM 工程师提交修复。 定价 ## 按服务计费，绝不按工程师计费。 每个套餐的探针和捕获次数都不限。你不应该在事件处理中途撞上一堵墙。 免费版 $0 永久免费 1 个服务 · 托管云 当天下午即可安装 SDK 并看到一次真实捕获。 - 1 个服务 - 无限探针和捕获 - 通过单条代理提示即可安装 大多数团队 专业版 $99 每个服务每月 $79 按年计费 · 至少 3 个服务 适合运行真实生产流量、希望整个技术栈都被插桩而不只是一个服务的团队。 - 无限服务 - 30 天捕获历史 - 共享工作区和已保存的探针 立即试用 (https://docs.hyperprobe.co/quickstart) 企业版 自定义 年度合同 · 阶梯定价 适合安全审查必须先批准、之后才能接触生产环境的团队。 - 自托管或私有 VPC - RBAC 和审批门禁 - 自定义 PII 脱敏规则 联系我们 (https://calendly.com/shailendra-hyperprobe/30min) 我们与你一起处理的第一个事件免费 · 可随时取消 · 无席位数量 · 无主机数量 · 无捕获限制 查看完整定价和各套餐内容 → (https://www.hyperprobe.co/pricing) 这就是为你而生的 ## 你认得出下面这些场景。 如果你认不出，我们可能还不适合你。如果你认得出，那就聊聊吧。 ### 你上一次在作战室里花了 2-3 小时，结果发现只是一行代码的修复，是什么时候？ 如果你对那个夜晚记忆犹新，HyperProbe 就是为你而生的。你当时需要的数据从来就不在日志里。你 grep、猜测、重新部署、然后祈祷。事情不必非得这样。 ### 你最优秀的工程师是你的值班团队，而不是你的产品团队。 生产环境出问题时，你最昂贵的人力被呼叫去做一件机器应该做的事。每一个值班的夜晚，都是他们心生不满的夜晚。而你最优秀的人，从来不缺选择。 ### 同样的事件还会再次发生，因为没有任何东西确认过它第一次发生的原因。 没有失败时刻的精确变量状态，每一次修复都是猜测。猜测能撑住，直到撑不住。HyperProbe 确认根因，让修复是彻底的，而不是被推迟的。 开启 POC ## 让我们处理你技术栈中的一次*真实事件*。 30 分钟。你的服务。你的事件。通话结束前你会看到已确认的根因——否则就没有什么可谈的了。 Node.js · TypeScript · Java · Kotlin · 运行在你自己的基础设施中 · 15 分钟内启用