【2026 最新】HyperProbe 是什麼？讓 Coding Agent 用唯讀 Runtime Evidence 除錯 Production（實戰教學）

HyperProbe 是什麼？想像你的 Production checkout 沒有報錯、trace 也是綠的，卻有一批 Gold 會員拿不到折扣。Logs 只告訴你「預期 20%、實際 0%」，Coding Agent 看完程式後猜是下游 timeout；真正缺少的，可能只是某一行的 rawTier 當下多了一個空白。

HyperProbe 想補的就是這塊空白：先把 Runtime Agent 裝進服務，再讓 Coding Agent 經 MCP 提議一個短效、受限的 probe，讀回特定程式行的變數證據。2026 年 8 月 10 日查詢時，它的 Launch HN 討論顯示 68 points、53 comments；高密度留言問的不是「好不好用」而已，而是 side effect、PII、p99 latency、audit 與單一 snapshot 會不會誤導。

這篇專為第一次接觸 Production debugging 的讀者寫。我們不把官網的安全與效能用語當結論，而是先在 staging 建一個可重現 bug，依序比較 metrics、logs、trace 與 runtime snapshot，再用 PII、權限、audit、Agent 正確率與 overhead 五道 gate，決定它能不能碰 Production。

先說結論：Runtime Evidence 不是「把 Production 全交給 AI」

🔎 記憶把手：Production 除錯＝Metrics 找範圍＋Trace 找路徑＋Logs 看事件＋Runtime Probe 驗證變數＋Human Gate 批准改動。
Agent 可以提議最小 probe、讀取通過 allowlist／redaction canary gate 的 evidence、更新假設；它不需要 host shell、production write、ptrace 或可自行放行的控制面憑證。

一句更短的版本是：Runtime Evidence＝在正確時間、正確程式行，取得一組有界、帶時間與 scope 的局部狀態證據。它用來證偽一個具體猜測；可追溯性要另外通過 audit gate。它不是取代既有的 Agent observability，更不是讓 AI 直接登入 Production。

HyperProbe 是什麼？一句話看懂產品定位

HyperProbe 是一套面向 Coding Agent 的 dynamic runtime instrumentation 工具。白話說，它像一支事先裝在服務裡、平常收起來的「遠端探針」：事故發生時，工程師或 Agent 指定檔案、行號與條件；真實請求跑到該處，探針擷取受限的 local variables、watch 與 call stack，再經 broker 回傳。

依 HyperProbe 官方架構文件，整體由三層組成：VS Code／MCP 客戶端、broker 控制面，以及服務內的 SDK／Agent。Node.js 走 V8 Inspector，Java 走 runtime bytecode instrumentation，Python 3.12+ 使用 sys.monitoring；probe 命中後的 telemetry 先進 bounded queue，再非同步批次送出。

這類能力並非 HyperProbe 才出現；Datadog Dynamic Instrumentation、Lightrun 與其他 live-debugging 產品也能動態收集狀態。HyperProbe 的差異化主張，是把 probe lifecycle 暴露給 MCP，讓 Coding Agent 把「讀 code → 提假設 → 收 runtime evidence → 更新判斷」串成一條流程。這是產品定位，不等於它已證明比所有既有工具安全或更準。

Logs、Trace 與 Runtime Probe 差在哪？

最常見的誤解，是把 runtime probe 當成「比較進階的 log」。其實四種訊號回答不同問題：metrics 是隨時間記錄、常按時間窗聚合的數值測量，trace 是單一請求走過的路徑，log 是程式預先選擇記下的事件；runtime snapshot 的特色則是事件發生後，仍能按條件、按程式行取得 on-demand 的局部值。

比喻成查一台突然變慢的物流車：metrics 告訴你哪個城市開始塞車；trace 告訴你車走過哪些站、卡在哪一站；logs 是司機事先寫進行車紀錄的事件；runtime probe 則像在指定路口拍一張限時照片，看「當時車上那個包裹標籤究竟寫什麼」。照片更接近當下的局部狀態，但不一定更接近 root cause，也不一定具代表性；它同時更接近敏感資料，所以權限門檻必須更高。

同一個 Bug 實驗：讓 Agent 改正「下游 timeout」的錯誤假設

先做一個只含 synthetic data 的 staging 服務：gateway → checkout → loyalty。已知 Gold 會員應有 20% 折扣，但故意埋入一個尾端空白 bug：

const rawTier = loyaltyResponse.tier;       // "GOLD "
const normalizedTier = rawTier.toLowerCase(); // bug：漏了 trim()
const discountRate = discountMap[normalizedTier] ?? 0;

固定 container image、commit、traffic seed 與 scenario ID，再依序跑三個 evidence arms。每一組都開全新 Agent context，使用相同 model、prompt 與工具；先要求它提交前三個 root-cause hypotheses、信心分數，以及「最便宜的下一個辨識檢查」，避免看到答案後倒推一個看似聰明的故事。

Arm A｜只有 Metrics 與結構化 Logs

checkout_discount_mismatch_total 突然升高；log 有 trace_id、synthetic scenario_id、expected 20% 與 actual 0%，但刻意不記 customer payload。Agent 知道「算錯了」，仍可能把 latency 偏高的資料庫當成原因。這一步是在量現有可觀測性有多遠，不是故意讓 logs 變差。

Arm B｜加入 Trace

Trace 顯示 loyalty service 回 200、latency 正常，錯誤發生在 checkout 的折扣計算。Agent 應降低「下游 timeout」的信心，但 trace 沒有預先加入 rawTier，所以仍看不到字串尾端空白。這正是 runtime evidence 可能有增量價值的時刻。

Arm C｜加一個有界 Runtime Snapshot

先由人審批以下 probe contract。這是實驗規格，不是可直接貼進 HyperProbe 的 API；實際欄位要依當前 extension／MCP 版本確認。

environment: staging
source_revision: <exact-commit-sha>
location: checkout/discount.ts:42
condition: scenario_id == "tier-space"
requested_watch_expressions: [rawTier, normalizedTier, discountRate]
required_check: fail if snapshot returns extra locals
hit_limit: 10
ttl: 15m
instance_scope: 1 replica

Snapshot 得到 "GOLD " → "gold " → 0 後，Agent 必須明確指出哪個 evidence 推翻哪個舊假設，再提出 trim().toLowerCase() 的 staging patch，跑 hidden regression tests。一張 snapshot 只讓因果鏈變得更可信，不自動等於 root cause 已確認；至少再用第二個 discriminating capture 或回歸測試驗證。

HyperProbe 怎麼在 Staging 上手？先完成一次初始部署

以 Node.js 為例，先依 官方 Quickstart 建立 service，在 repo 根目錄放入只含 service UUID 的 .hprc，再安裝 SDK：

npm install @hyperprobe/node-sdk@1.2.23

import { HyperProbe } from '@hyperprobe/node-sdk';

HyperProbe.start({
  serviceId: '<staging-service-uuid>',
  environment: 'staging',
  brokerUrl: 'https://logger.app.hyperprobe.co',
  commitSha: process.env.GIT_COMMIT,
  distLocation: 'dist',
  sourceMapDir: './dist'
});

SDK 要在 entrypoint 很早啟動，部署時也要帶正確 commit SHA；TypeScript／bundled Node 需要 source map，否則程式行可能對不上。第一次加入 dependency、啟動設定與 source map 仍要部署或重啟；只有 Agent 已在服務內之後，新增 probe 才能免下一次 redeploy。

再依 官方 MCP 指南把 server 設在 workspace／repo 級，而非全系統：

{
  "mcpServers": {
    "hyperprobe": {
      "command": "npx",
      "args": ["-y", "@hyperprobe/mcp-server@1.2.23"],
      "env": { "BACKEND_URL": "https://app.hyperprobe.co" }
    }
  }
}

官方範例使用 floating latest；本文把 2026 年 8 月 10 日驗證的 Node SDK 與 MCP server 都 pin 在 1.2.23。未來升級時先在 staging 重跑 canary、side-effect 與 overhead gates，再改 lockfile。Workspace isolation 只能降低跨 repo 誤用，不能取代 Production RBAC。正式實驗前，先把 Agent 權限限制成「讀 logs／traces、提議 staging probe、讀通過 canary gate 的 evidence」；Production probe create、raw evidence view 與 export 應是分離權限。

「唯讀」不是零副作用：一定要拆成四層

下面四層是本文用來驗收工具的安全定義，不是對當期 HyperProbe 每個 runtime、每種 condition／watch 都已實現的功能保證。

1. 功能唯讀：不允許 assignment、寫 application memory、執行 shell，並限制 method／getter 等可能有副作用的 expression。
2. 時序副作用：condition、object traversal、redaction、serialization 與 network export 仍消耗 CPU、記憶體與時間，可能擾動 race 或 tail latency。
3. 控制面副作用：能把 instrumentation 動態放進 running process，本身就是高權限能力；憑證被濫用，影響範圍不會因為資料「只讀」就消失。
4. 資料副作用：runtime value 被複製出 process 後，會新增 PII、retention、viewer、export 與 LLM data-flow 風險。

因此最安全的說法是：唯讀表示設計上不應修改 application state，不代表零 overhead、零時序擾動，也不代表擷取出的資料沒有安全風險。甚至成熟工具對「read-only expression」的邊界也不同：Datadog 禁止 method call，Lightrun Java 則允許部分通過 static read-only analysis 的方法。名稱相同，不代表安全語意相同。

Staging 還要放一個 side-effect canary：讓 getter 分別增加 counter、模擬 DB write、取得 lock、throw 與 sleep，再用 condition／watch 嘗試讀它。只要任何 canary 被觸發，就代表這個 runtime／版本的 expression 邊界不符合你的「功能唯讀」定義，不能進 Production。

安全 Gate：PII、Approval、Audit、Scope 要怎麼驗？

1. PII：Allowlist 優先，Redaction 只是第二層

在 synthetic payload 種入 password、token、email、JWT、信用卡 canary，也要把秘密塞進模糊名稱 payload、nested array、URL query 與大小寫變體。接著逐層搜 SDK output、broker ingress／storage、MCP response、UI 與 deletion 後的 audit；任一 raw canary 出現就是 fail。

OpenTelemetry 的敏感資料指引也強調應避免一開始就收集、再談刪除。對 runtime probe 最實用的落地方式，是只允許三個已審核欄位，並把 PRESENT／REDACTED／TRUNCATED／UNAVAILABLE 分開；否則 Agent 可能把被遮蔽或截斷的值誤判成 null。

2. Approval 與 RBAC：把「能放 probe」和「能看原值」拆開

最低權限至少分成：讀 probe 設定、staging create、production create、capture variables、view raw、export、管理 redaction，以及 JIT／break-glass。Agent 可以產出 probe proposal；production arming 由不同的人與短效憑證批准，並鎖定 service、env、revision、instance、欄位、hit limit 與 TTL。

這是本文的 go／no-go requirement，不代表每個方案都已具備。HyperProbe 當前定價頁把 RBAC 列在 Professional 以上，把 approval gates 與 custom PII rules 列在 Enterprise；實際 entitlement 與 MCP 是否能繞過審批，仍要用低權限帳號做負向測試。

3. Audit：不要只看 Probe CRUD

Audit 測試要涵蓋 request／approve／deny、create／modify／arm／expire／delete、view／search／download／export、failed access，以及 RBAC／redaction／kill-switch 變更。每筆要有 actor、approver、ticket、source revision、scope、結果與時間，但 audit 本身不應再保存 raw captured value。

這裡有一個不能略過的版本矛盾：截至 2026 年 8 月 10 日，HyperProbe 官網把 immutable audit trail 寫成現有能力；但 Launch HN 當天，創辦人仍回覆 audit trail 在 roadmap。數天內可能已上線，也可能只是頁面先更新；因此上線前仍應現場建立、查看、刪除 snapshot，再驗證 audit 是否完整、不可改，且刪除資料後仍保留 lifecycle 記錄。

Overhead 實測：別拿「<1%」直接換成 Production 通行證

官網目前宣稱在 3,000 RPS 下 overhead 低於 1%；HN 創辦人回覆的 active-probe path latency 則是 Node 約 7–10ms、Python 約 4–9ms、Java 約 1–2ms。兩者測的是不同指標；截至 2026 年 8 月 10 日，我們檢查的官方首頁與該 HN 回覆未提供硬體、payload、p99、GC、樣本數或可重跑 harness，因此本文把兩組數字都視為供應商自測，不能直接互相驗證，也不能外推到你的 hot path。

用同一 binary、config、traffic seed 與獨立 load generator，交錯跑六種狀態：B0 無 Agent、B1 Agent idle、B2 probe armed 但 condition false、B3 命中三個短值、B4 逐步增加 depth／frames／hit rate、B5 刪除 probe 後再測。每輪先 warm-up，再隨機或 ABBA 交錯重複；量 p50／p95／p99、throughput、5xx、CPU、RSS／heap、GC、event-loop lag、egress bytes、queue drop 與 hit-to-evidence latency。

門檻不要抄產品頁，可先用服務 headroom 建一個內部 gate。下面只是可操作示例，不是業界標準：

latency_headroom = SLO_p99 - baseline_p99
probe_p99_budget = 10% * latency_headroom

GO only if:
delta_p99 <= probe_p99_budget
raw_canary_leaks == 0
unauthorized_create_view_export == 0
audit_lifecycle_coverage == 100%

若 baseline 已沒有 SLO headroom，直接 NO-GO。剛開始即使通過，也只開一個 instance、極短 TTL、低 hit cap 與 synthetic condition；kill switch 要能撤權、移除 probe、封 broker egress，不能只依賴會自動恢復的 cooldown。

怎麼驗證 Runtime Evidence 真的讓 Agent 更準？

不要只展示一段成功 demo。把相同模型與設定隨機分成 E0＝metrics＋logs＋trace、E1＝E0＋runtime snapshot，每次使用 fresh context 與同構但不同表面的 bugs。若資源允許，每組至少跑 30 次，再看分布而不是挑一個漂亮案例；這是本文建議的實驗下限，不是正式標準。實驗 broker 也應替每筆證據加上 ID、環境、revision、probe、hit index、時間與值狀態，讓 Agent 的引用能被重播。

• 診斷品質：正確 root cause 排名、錯誤假設信心是否下降、unsupported assertions 數。
• 證據紀律：是否引用正確 evidence_id、是否把 REDACTED／TRUNCATED 當成已知值。
• 最小權限：用了幾個 probes、擷取多少 bytes、是否要求多餘 PII 或更廣 scope。
• 修正結果：staging patch 能否通過未公開 regression tests，並對缺證據的案例回答 Inconclusive。

如果想把這套評分做成可重複流程，可接著看〈AI Evals 實戰方法〉；需要管理 Agent 工具邊界，則可搭配〈用 AGENTS.md 建規則與 Gate〉。兩者一起用，才有機會分辨「Agent 因證據變準」和「這次剛好猜中」。

什麼時候不該讓 Coding Agent 取得 Production Runtime Evidence？

• 服務處理醫療、金融、身分或大量不可匿名資料，卻只能 denylist、不能 field allowlist。
• production create、raw view、export 共用同一角色，或 Agent 自己能批准自己的 probe。
• audit 只記 CRUD，沒有 approval、view／export、failed access 與 policy change。
• baseline 已貼近 latency／CPU／error SLO，或 hot path、race、serverless 對時序特別敏感。
• 問題很可能在 process 外：Kubernetes 調度、network、noisy neighbor、DB lock。此時 runtime local variables 可能只製造更有說服力的錯誤故事。
• 團隊無法在一鍵 kill、版本對齊、source map、redaction canary 與 retention deletion 上給出可重複證據。

若你的 Agent 仍需要 host shell、production write 或完整 memory dump 才能工作，那已不是本文的 brokered read-only evidence 模型。先用〈AI Agent 秘密與憑證安全〉縮小 blast radius，再談 runtime access。

HyperProbe 是什麼成熟度？目前適合 POC，不適合盲信

Y Combinator 公司頁把 HyperProbe 列為 2026 年成立、S26 團隊。截至 2026 年 8 月 10 日，npm registry 的 Node SDK 1.2.23 metadata 標為 UNLICENSED 且未提供 repository 欄位；Python agent 1.2.24 標示 Hyperprobe Proprietary License。因此「可公開安裝」不能直接當成 open-source core；Self-host 代表部署位置可控，也不等於原始碼開放。

更值得注意的是文件與 artifact 還有早期產品常見的落差：2026 年 8 月 10 日查核時，Safety 文件列 200KB/s、50ms lag、20ms pause budget 與包含 ssn／creditCard 的預設 redaction keys；npm latest Node SDK 1.2.23 發行物則是 1024KB/s、80ms、30ms，預設 keys 未含後兩項，連部分環境變數名稱也不同。官網對 audit 的說法也和 Launch HN 回覆衝突。因此實務結論不是「不能用」，而是pin 住 runtime 與版本、印出實際設定、用 canary 與負向權限測試驗收，不從行銷頁推導 Production 保證。

HyperProbe FAQ

1. HyperProbe 會取代 Logs 與 Trace 嗎？

不會。Logs 與 trace 是長期基線，也是定位 probe 的前置證據；runtime snapshot 只在缺少某個關鍵 local value 時短暫補洞。

2. Read-only 是否代表零風險？

不是。它最多限制 application state 的寫入；instrumentation、expression evaluation、資料序列化與傳輸仍有時序、資源、控制面與資料風險。

3. 可以讓 Coding Agent 全自動在 Production 放 Probe 嗎？

新手不該從全自動開始。先讓 Agent 只提議，人工核准 service、revision、line、condition、allowlist、TTL 與 hit cap；累積可靠 audit 與 overhead 數據後再逐步放權。

4. HyperProbe 完全不需要部署嗎？

第一次仍需要。你要先整合 SDK／Java Agent、設定 commit SHA 與 source map 並部署；完成後，新增 probe 才不必為每一條 log 再走一次 deployment。

5. 目前有哪些 Runtime 有完整整合文件？

官方目前提供 Node.js 18+、Java 17+ 與 Python 3.12+ 專屬頁面，TypeScript 經 Node SDK 搭配 source map。其他語言或 serverless 環境不要只看首頁列表，應用你的 framework 與 runtime 版本做 staging 驗證。

6. 一次 Snapshot 就能證明 Root Cause 嗎？

不能。它是受條件、抽樣、截斷與單一時點影響的證據。用第二個能區分競爭假設的 capture、回歸測試或受控重播確認。

7. Self-host 就等於 Open Source 嗎？

不等於。Self-host 描述軟體跑在哪裡；open source 描述原始碼與授權能否公開檢查、修改與散布。兩項必須分開審核。

8. 完全沒有 SLO Headroom，還能用很低的 Hit Limit 嗎？

不建議。低 hit limit 會降低事件總量，卻不能保證單次命中不影響 tail latency 或 race；先改善 headroom，或在隔離 replica／重播環境取證。

給新手的 5 個重點

1. 先用 metrics、logs、trace 縮小問題，再問「只差哪一個值能證偽猜測」。
2. 把 read-only 拆成功能、時序、控制面、資料四層，不把名稱當安全證明。
3. 在 staging 用 synthetic bug、PII canary、負向 RBAC 與 audit lifecycle 測試。
4. 分開量 Agent idle、probe armed、實際命中與刪除後恢復，門檻綁自己的 SLO。
5. Agent 只拿 brokered evidence；Production arming、raw view、export 與寫 code 分權處理。