HNローンチ: HyperProbe (YC S26) – 本番環境で読み取り専用デバッグを行うエージェント

HNの皆さん、ShailendraとKaranです。私たちは、コーディングエージェントが本番環境でライブデバッグを行うための、高速かつ安全な方法を構築しています。 本番環境で問題が発生した場合、CursorやClaudeなどのエージェントが、ログにはない正確な変数値を抽出するために、実行中のコードに仮想ブレークポイントやプローブを安全に設定できます。 これらすべてにより、ログやトレースを掘り下げたり、原因を見つけるまでconsole.logやprint文を追加して再デプロイしたりする手間を省くことができます。 この説明ビデオへのリンクはこちらです: https://www.youtube.com/watch?v=ivV7I--ta5c エージェントは現在、私たちのコードの大部分を生成しています。これにより、エンジニアがAIによって書かれたコードをデバッグするために必要な有用なコンテキストが縮小されますが、これはAIが同じコードに追加する限定的なテレメトリでは助けになりません。 そのため、本番環境で問題が発生した場合、エンジニアの最初の本能はログを開くか、エージェントにログを渡すことです。しかし、探している行がログにない場合、エージェントは存在しないデータに基づいて根本原因を推測し始め、ログを追加して再デプロイすることを余儀なくされます。 既存のデータに対するエージェントのこの分析推論ループは、多くのトークンを消費するため、安価ではありません。また、ログの追加と再デプロイのサイクルは非常に遅く苦痛であるため、エンジニアはオンコールを嫌うようになります。 私たちの方法は、エージェントが障害の正確な瞬間と時点でオンデマンドでテレメトリをキャプチャできるようにし、ログ・再デプロイのサイクルを排除し、より少ないトークンで最も正確なRCA（根本原因分析）を取得します。 明らかな問題は、それを実行中のサービスで機能させることです。ラップトップのデバッガを一時停止するのと同じように、ライブサービスを一時停止することはできません。スレッドを一時停止したりホストを遅くしたりすることなく、実行中のプロセスから安全に値を取得することが課題です。私たちはこれを実現しています。 これ以前は、100人規模のチームでエンジニアリングを率いていました。その後、Karanと私はHyperTestというテストツールに3年間取り組みました。 HyperTestでは、OpenTelemetryを使用して本番トラフィックをインテグレーションテストに変換しました。それも本番環境のインストルメンテーションでした。壊すことなく実行中のサービスから実際のランタイム状態を引き出すことの難しい部分は、私たちがまとめることを学んだ難しい部分でした。 私たちは他にもいくつかの教訓を苦労して学びました。HyperTestはより良いテストでバグを防ごうとしましたが、導入は常に戦いでした。チームが本番環境の火消しに追われていたため、コールはキャンセルされ続けました。テストは衛生（当たり前）でしたが、壊れた本番環境は火事（緊急事態）でした。これにより、私たちは優先順位がどこにあるかを見ることができました。 これは、真に自律的なオンコールエージェント、つまりアラートを受け取り、プローブを設定し、診断し、数分で修正するエージェントを構築するという考えの種となりました。しかし、現在の仕組みは次のとおりです。 あなたは、いつものようにコーディングエージェントと対話します。「チェックアウトは200を返すが、一部のユーザーは注文が失敗しているのを見ている。原因を調べてほしい」と伝えます。エージェントはローカルコード内の行を特定し、MCP経由で私たちに接続し、実行中のサービス上のその行にプローブを設定します。プローブは読み取り専用で、実際のトラフィックがヒットするまでアイドル状態のままです。ヒットすると、その正確な瞬間にコールスタックの各フレームでのローカル変数をキャプチャします。そして、エージェントにそれを渡し、エージェントは実際のデータで診断します。 2つの部分があります。サービス内で実行されるSDKと、コーディングエージェントが話すMCPサーバーです。SDKは、再デプロイなしでプローブ（仮想ブレークポイント、ログまたはメトリック）を設定できるようにするものです。NodeとPythonではインプロセスでフックします。JavaではJVMエージェントとしてアタッチし、バイトコードレベルでインストルメントします。いずれにしても、サービスは実行を続け、トラフィックを提供します。何も一時停止しません。 エージェントが特定の行を確認したい場合、MCPサーバーを呼び出し、MCPサーバーはSDKにそこにプローブを配置するように指示します。リクエストがその行にヒットすると、SDKはプローブが要求したものをキャプチャし、インプロセスでサニタイズし、MCP経由でエージェントにストリーミングします。 これは本番環境で実行できるため、プローブは変数内にある任意の値を読み取ることができます。パスワード、トークン、認証、SSN、クレジットカードなどのキーはデフォルトで赤化され、独自のキーを追加できます。赤化はインプロセスで、コンテナ自体のメモリ内で行われることを保証します。これは、何もワイヤーに出る前に行われます。 また、プローブは読み取るだけで書き込みは行いません。キャプチャされた状態がネットワークを離れることを望まない場合は、サーバー、ブローカー、さらにはデータベースをインフラストラクチャ内にセルフホストすることもできます。 オーバーヘッドについて：アイドル状態の場合、SDKはメモリをほとんど追加せず、スループットと応答時間には実質的に何も影響しません。プローブはアクティブにキャプチャしている間のみコストがかかります。キャプチャも制限されています。別のモニターがリアルタイムで監視し、オーバーヘッドが急増した場合はすべてのアクティブなプローブを停止します。 すべてのログ・トレースツールは、エージェントに既に存在するデータを渡し、何が起こった可能性が高いかを推測するように求めます。私たちは、エージェントに実行中のコードへの目と耳を与え、障害のまさにその時点で、必要なものを必要なときにキャプチャできるようにする方が有用だと考えています。 これは、本番インシデントをデバッグするための最もシンプルで最速の方法のように思えます。 コミュニティが、コーディングエージェントとチャットするだけで、既知または未知の問題をデバッグするために、あらゆる環境でこれを試してくれることを願っています。そして、これを真に自律的なオンコールエージェントにするために、さらにどのような機能が必要か教えてください。 サポートされているプラットフォーム: NodeJs, Java, Python。