生产故障不是让 Agent 获得 shell：用 HyperProbe 把实时变量采样限制在可审计的只读探针里
线上排障最难的时刻，往往不是服务已经 500，而是接口仍然返回 200、链路也没有异常，却给了错误的业务结果。日志中缺少那一次请求的局部变量；把 console.log 加回去，需要提交、构建、发布，再等待问题重现。于是值班工程师只能在日志、猜测和临时热修之间来回切换。
HyperProbe 的思路不是给 AI 编码 Agent 一条生产环境 shell，也不是把整个堆转储交给模型，而是在已经运行的服务中放置一次性的只读探针（probe）。探针命中真实流量时采集指定代码行附近的变量、调用栈或观察表达式；采样完成即移除。它把“为了看一眼变量而发布一次调试代码”的过程，拆成了一个可设置边界的观测动作。
这是一种很值得团队讨论的生产 Agent 设计：Agent 可以帮助定位、提出采样计划和解释证据，但不能写入内存、执行任意命令或直接修改线上代码。对于要把 Claude Code、Cursor 或其他编码助手接入值班流程的团队，这条边界比“Agent 能不能自动修复”更应先被定义。
先区分：日志、追踪与探针各自回答什么问题
日志适合回答“发生了什么”；追踪擅长回答“请求经过哪里、耗时在哪里”；但它们都很依赖事先决定记录哪些字段。若支付状态的外部响应新增了一个字段，而某段解析逻辑把对象当成字符串处理，出错时的嵌套值可能从未进入日志。
HyperProbe 把目标放在这种“证据缺口”。官方流程是：从 PagerDuty、Datadog 或 Slack 的告警开始，读取日志和追踪以定位可疑文件及代码行，再在该处插入只读采样；当下一次真实请求命中时，采集变量状态，最后用采样结果确认根因。这里的关键不是让模型凭已有日志做更长的推理，而是补足一次可复核的运行时证据。
不过，探针并不取代可观测性三件套。没有基础指标和调用链，团队很难知道应该在哪条执行路径上采样；没有结构化日志，也难以确认异常发生的范围。更合理的分工是：指标负责发现，追踪负责缩小路径，日志提供上下文，探针用于验证一个高价值假设。
安装时最重要的是源码与线上版本对齐
以 Node.js 服务为例，官方 Quickstart 要求先在仓库根目录建立 .hprc，将本地工作区映射到后台服务，再安装 @hyperprobe/node-sdk。初始化必须尽早执行，并且显式传入当前部署的提交 SHA。下面是基于文档字段的最小化示例：
// src/hyperprobe.ts
import { HyperProbe } from '@hyperprobe/node-sdk';
HyperProbe.start({
serviceId: process.env.HYPERPROBE_SERVICE_ID!,
environment: process.env.NODE_ENV,
brokerUrl: 'https://logger.app.hyperprobe.co',
commitSha: process.env.GIT_COMMIT!,
distLocation: 'dist',
sourceMapDir: './dist',
});
// src/index.ts：在业务模块前尽早加载 import './hyperprobe.js'; import express from 'express'; const app = express();
commitSha 不是可有可无的元数据。官方文档说明，如果提交 SHA 缺失或为 unknown，Agent 会拒绝初始化，因为本地编辑器中的行号可能已无法对应正在运行的构建物。对 TypeScript/Babel 服务还应保留 source map；JVM 服务则要在构建产物中包含调试符号。否则，“在第 N 行采样”会变成对错误版本下探针，既得不到有效证据，也会制造安全风险。
在 CI 中，应该把当前 commit 写进环境变量，而不是让开发机的 Git 状态成为来源。例如：
export GIT_COMMIT="$(git rev-parse HEAD)"
export HYPERPROBE_SERVICE_ID="${HYPERPROBE_SERVICE_ID}"
export HYPERPROBE_ENVIRONMENT="production"
这里的变量只负责部署时的版本对齐和服务身份；生产密钥仍应由既有的 Secret 管理机制注入，不能写进仓库或交给聊天记录。
版本对齐还应落实到发布流程。一个常见失败模式是：工程师在 main 分支查看到代码，却把探针打到了仍在运行旧镜像的实例上；或者灰度环境中同一服务同时有两个 commit。此时即使采样结果“看起来合理”，也不能据此修改当前主干。实践中可将服务名、环境、commit SHA、镜像摘要和部署区域一起写入事故记录，并要求探针控制台显示这些标识。若无法确认唯一版本，就先缩小探针到指定实例池，或等版本收敛后再执行采样。
同样需要为采样对象设定数据最小化规则。对于订单排障，优先采集状态码、字段类型、长度、是否为空以及经过哈希或掩码处理的关联标识，而不是原始姓名、完整地址、会话 cookie。对于可能含有数组或大对象的局部变量，也应事先设定深度和大小上限。这样做会让一次采样少一些“方便阅读”的细节，却能显著降低把生产数据扩散到聊天窗口、第三方模型或事故工单的风险。
给 Agent 的不是“调试权”，而是一份受限采样计划
把 AI 接入后，建议将一次故障处理收敛为以下闭环：
- 人工确认告警范围。 先确认受影响的端点、时间窗口和业务指标，避免 Agent 因单条异常日志扩大探测范围。
- Agent 只生成计划。 它可以结合仓库、trace 和日志建议文件、代码行、变量白名单、触发条件与命中上限；计划进入人工审批，而非直接生效。
- 使用一次性 Snapshot Probe。 在 VS Code 中对可执行行选择
Insert a Snapshot，然后由受控流量或下一次真实请求触发。对含 PII 的对象，先缩小到必要字段，不能采集整个 request 或 user 对象。 - 证据与修复分离。 采样结果只用于形成根因判断；修复仍应走分支、测试、代码审查和发布流程。即使 Agent 给出补丁，也不要由探针通道直接写入生产。
- 复盘并删除残留配置。 记录为什么选这行、采到了什么、结论是否被后续测试验证。确认探针已过期或达到命中上限，避免临时观测成为永久权限。
HyperProbe 文档把探针描述为非阻塞、只读的运行时快照，并强调审计记录、审批门和本地脱敏。它还宣称 Node.js 通过 V8 Inspector API、JVM 通过字节码机制挂接，并设置冷却保护、有效期与命中上限。团队在采购或 POC 中不应把这些说法直接当作通用结论，而要用自己的服务压测验证：高峰 RPS 下的延迟分位数、CPU/内存变化、探针命中失败率、脱敏规则覆盖率，以及超时后探针是否确实撤销。
有价值的边界与不适用场景
探针方案还有一个容易被忽略的运维问题：采样本身会成为事故中的一项变更。即使它不改业务逻辑，也应像临时防火墙规则一样具备负责人、创建时间、自动过期时间与撤销路径；不要让一次深夜排障遗留的探针跨过下一次发布继续存在。针对高风险服务，可预先演练“探针无法撤销”“采样通道不可用”两种情况，确保关闭能力不依赖正在故障的同一控制面。
首先，探针捕获的是“下一次命中的现场”，并不能回到过去复原已经消失的请求。低频故障若迟迟不再出现，仍需要可回放的测试、审计事件或更完善的业务日志。其次，实时变量天然可能包含令牌、地址和订单信息；“本地脱敏”是重要能力，但字段分类、保留时间、导出权限和审计读取权限仍须由团队制定。第三，源码映射、部署提交和运行容器必须一致。灰度发布、多区域部署或混合版本期间，应把环境和 commit 当作探针计划的硬约束。
最终，HyperProbe 更适合那些根因藏在运行时状态、而重部署成本高的生产问题：偶发竞态、静默数据不一致、被吞掉的异常，以及第三方契约漂移。它不该成为绕过变更流程的借口。把 Agent 限制为“提出假设、请求一次受审计的只读观察、解释证据”，再把修复留在成熟的工程流水线里，才是把 AI 引入 on-call 而不扩大生产权限面的可持续方式。