HyperProbe：让AI在产线静默调试
Launch HN: HyperProbe (YC S26) – Agents that do read-only debugging in prod
你的工程师不该沦为On-call救火队员。HyperProbe是YC S26孵化的AI On-Call Agent，能在生产环境自动执行只读调试。当PagerDuty或Datadog触发警报时，它无需重新部署或重启服务，直接在运行中的代码行放置虚拟断点，捕捉日志中缺失的变量状态。从警报到确认根因，HyperProbe将数小时的排查压缩至10分钟内，让资深工程师从重复的War Room中解放，回归构建产品本身。无论是静默失败、竞态条件还是第三方接口漂移，它都能在不影响用户请求的前提下，提供确凿的证据链。
你的工程师加入公司不是为了On-call，他们在War Room里度过的每一小时，都是本该用于构建产品的时间。
HN 评论区
52- doublerebel
HyperProbe 与现有的 AppSignal、Rollbar 和 Embrace 等工具有何不同？市面上已经存在非常成熟的工具，它们能自动埋点、从调用栈收集变量并精准定位错误原因。
> 每个日志和追踪工具都是把已有的数据交给代理，让它反向推理“可能”发生了什么
如果应用使用了不错的埋点工具，数据展示的是“实际”发生了什么，而不是“可能”发生了什么。
> “结账接口返回 200，但部分用户订单失败，找出原因。”
这个工具难道只是为了弥补糟糕的系统设计而存在的吗？在我工作过的任何电商公司（无论大小），订单失败都是巨大的红色警报。通常这是最早被记录和追踪的动作之一（与注册/登录并列），并且指标会被主动监控。对失败请求返回 200 且未捕获该错误，是非常糟糕的 API 设计。
同样，让工程师处于必须访问未知数量的实时敏感客户数据才能调试的境地，通常也被视为不良实践（尽管现实中经常发生）——在急于调试时，很容易遗漏某个属性本应被脱敏；等到发现时，敏感数据已经泄露，为时已晚。此外，在大多数高并发系统中，追踪数据的体量之大，让人无法逐一检查和搜索。这就是为什么 Rollbar 等工具会聚合错误和捕获的数据以识别模式，然后才由人类（或代理、或工具）介入 […]
- manos-saratsis
一针见血，很好地补充了合并前（pre-merge）那半部分的问题。静默逻辑错误往往在代码差异“看起来没问题”时溜过去——你们构建的东西能在它们上线后捕获这些错误。
- anshulmotwani
恭喜发布！将这款产品定位为现有可观测性工具之上的 AI 驱动调试层非常合理，针对静默故障的只读探针感觉是一种实用的方法，能在不将每个事件都变成另一次“打日志 + 重新部署”循环的情况下获取运行时证据。肯定会试试看！
- tizerluo
在将其指向关键服务之前，我有两点想知道：(1) 开销预算——当探针落在热点路径上时，捕获是采样还是按次限制？在负载下你们测量的 p99 延迟增量是多少？(2) 故障隔离——如果探针评估本身抛出异常（对象形状怪异、带有副作用的 getter、需要序列化的捕获值过大），是否能被隔离，确保不会把正在观察的请求搞挂？进程内代理的生死存亡取决于在最坏情况下能否保持“平淡无奇”。
- vitorbaptistaa
恭喜发布！看起来非常棒。
对于像我这样没有这些精致可观测性工具的人，我一直在使用 https://shellshare.net（声明：这是我做的）。
这是一个单命令工具，用于通过端到端加密实时共享终端。最初它是为了教学或帮助同事设计的，但对代理也很有帮助。我 SSH 进入生产环境并运行：
> npx shellshare exec --json -- tail /var/log/my-app.log
这会生成一个 URL，然后我可以告诉任何代理：
> monitor <URL>, instructions in https://shellshare.net/llms.txt
它们可以看到实时输出。无需在代理机器上安装任何东西。在下一个 shellshare 版本中，只需输入 "monitor <URL>"，代理的指令将直接包含在 URL 中。
虽然远不及你们做的东西，但对我很有帮助。祝你们的创业顺利！