dsh-blast-radius
DeepSeek Harness plugin: semantic blast radius for agent code edits — who calls what the agent just changed, and which of those callers have no test
- Stars
- 0
- Language
- TypeScript
- Created
- Aug 20, 2026
- Updated
- Aug 20, 2026
Introduction
dsh-blast-radius
DeepSeek Harness 插件:agent 改了代码,这次改动会波及什么?
diff 告诉你改了 5 行。它不会告诉你这 5 行在一个被另外 3 个文件调用的函数里, 而那些调用点一个测试都没有。前者是文本视角,后者是风险视角。
用真实的 TypeScript 语义分析(tsserver)回答后者:改动落在哪个符号上、谁依赖这个
符号、那些依赖里有多少受测试保护。
[高] applyDiscount src/money.ts
3 处生产调用点,且该符号没有任何测试引用
影响 2 个其他文件:src/cart.ts、src/pricing.ts
↳ src/cart.ts:6 const total = applyDiscount(subtotal, discountPct)
↳ src/pricing.ts:10 return applyDiscount(cents, 10)
↳ src/pricing.ts:19 return applyDiscount(this.cents, pct)
两条不会妥协的原则
这两条决定了插件的所有行为,也决定了默认配置:
1. 分析失败永不阻断 agent。 TypeScript 没装、tsserver 崩了、查询超时 —— 全部放行。
即使 enforce: true 也一样。一个会因为子进程死掉就卡住 agent 的质量工具,比没有这个
工具更糟。
2. 「不知道」永不伪装成「安全」。 分析不出结论时明确说出来,而不是渲染成一条干净
的结果。这也是 enforce 默认关闭的原因:一个第一天就开始拦你写入的插件,会在赢得
信任之前先被卸载。
功能
- 语义影响面:
tsserver的references+navtree,按符号(不是行号)归因 - 测试覆盖缺口:区分生产调用点与测试引用 —— 这是最值钱的信号
- 风险分级:
低 / 中 / 高,规则确定可复现(不用模型判断) - 写入前拦截:
tools/pre-executewaterfall,超阈值走ask - 仪表盘:
shell.overlay角落面板,4s 轮询 - 零额外安装:
typescript包自带tsserver.js,优先用被分析项目自己的版本
安装
dsh plugin --profile web add dsh-blast-radius
默认 report-only:只记录、只显示,不拒绝任何写入。
配置
见 cordis.patch.yml。关键项:
| 键 | 默认 | 含义 |
|---|---|---|
enforce | false | 超阈值时是否要求确认。默认只报告 |
enforceAtRisk | high | 触发确认的风险等级:medium | high |
timeoutMs | 3000 | 单次语义查询预算,超时降级为「未分析」并放行 |
highProductionRefs | 12 | 调用点超过此数即为高风险(即使有测试) |
testPatterns | [] | 追加的测试路径正则(内置已覆盖 *.test.* / test/ / __tests__/) |
maxProjectFiles | 2000 | 无 tsconfig 时扫描上限,触顶会明确报告 |
verbose | false | 每次分析打一行日志,调阈值时有用 |
风险分级规则
| 条件 | 等级 |
|---|---|
| 无人引用 / 仅被测试引用 / 仅被导入未调用 | 低 |
| 有生产调用点,无测试引用,且跨文件 | 高 |
| 有生产调用点,无测试引用,但都在本文件内 | 中 |
有生产调用点且有测试引用,调用面 ≥ highProductionRefs | 高 |
| 有生产调用点且有测试引用 | 中 |
排序刻意如此:「跨文件且完全没有测试」排在「调用点很多」之前,因为前者是改错了会 静默上线的情形,后者至少有测试兜着。
设计取舍
这些取舍都是在真实仓库上跑出来的,不是设计阶段想出来的。
只分析符号,不分析行
变更行 → navtree 定位所属符号 → 查该符号引用。变更区间用前后缀剪裁计算,分散编辑
会连带包含中间范围。刻意选这个方向:多分析几个符号只是多花几毫秒,漏掉符号就是漏掉
了插件存在的理由。
局部变量不参与分析
第一次在真实文件上跑,30 条结果里大部分是噪音 —— splitSentences.start 报告"2 处生产
调用点",那是个循环变量。
按 kind 过滤不够:模块级 const 和函数内 let 在 tsserver 里 kind 相同。真正的判据是
是否在可调用体内 —— 模块常量能被任何地方读,局部变量跑不出它所在的函数体。修完
30 条降到 6 条真实符号。
import 不算调用点
import { applyDiscount } from './money.ts' 引用了符号,但不依赖它的行为。算进去会让
影响面虚高一倍(fixture 里 3 处真实调用被报成 5 处)。
import 仍计入「波及文件」 —— 依赖关系是真的,只是不是"使用"。
测试文件不算「波及范围」
测试引用一个符号是保护,不是风险传播。算进去会让"测试写得好的符号"看起来比裸符号 更危险,正好反了。
补丁式编辑明确拒绝分析
str_replace_editor 表达的是"把 A 换成 B",不是"文件最终长这样"。要还原结果就得重新
实现一遍该工具的语义,而还原错了的话,下游每条结论都在描述一个不存在的文件。
所以报告为「未分析」、放行、且不记入已审查记录 —— 免得让人以为这次改动被看过了。
无 tsconfig 的项目:合成项目范围,但不落盘
没有 tsconfig.json 时,tsserver 退化成 inferred project,只知道显式打开的那个文件。
实测后果(在一个真实仓库上):
inferred project: 1 refs -> src/segmenter.ts ← 假的「没有引用」
declared project: 4 refs -> src/segmenter.ts, src/index.ts ✓
用 openExternalProject 在内存里声明项目范围,刻意不写 tsconfig.json 到用户仓库
—— 那会出现在 git status 里、可能被它正在监视的 agent 提交进去、还可能改变项目真实
构建行为。有测试断言分析前后 readdir 结果一致。
代价是范围靠扫描推断,可能漏文件。所以结果带 approximate 标记,且 enforce 时
推断范围的结论不参与拦截 —— 低估风险在"报告"里可以接受,作为"打断别人工作的理由"
则不行。
架构
tools/pre-execute waterfall
└── extract.ts 工具调用 → 待写入内容(认不出的明确报 opaque)
└── radius.ts 变更行 → 符号 → 引用 → 分桶 → 分级
└── lsp.ts tsserver 长驻会话(超时/崩溃/未就绪全部降级)
└── discover.ts 无 tsconfig 时的有界文件扫描
GET /dsh-blast-radius-api/status → { records, enforce, enforceAtRisk, projectRoot }
| 文件 | 职责 |
|---|---|
src/lsp.ts | tsserver 会话:帧解析、超时降级、崩溃重启、pending 内容同步 |
src/radius.ts | 纯逻辑:符号定位、引用分桶、风险分级(不碰子进程) |
src/discover.ts | 无 tsconfig 时的项目文件发现(有界) |
src/extract.ts | 从工具调用还原待写入内容 |
src/index.ts | 插件入口:配置、闸门、status 路由 |
src/client.tsx | 仪表盘面板 |
性能
在一个真实仓库上实测:
| 指标 | 数值 |
|---|---|
| tsserver 冷启动 + 项目加载 | ~450ms(每会话一次) |
| 单符号引用查询 | 1–20ms |
| 一个文件(含多符号) | 40–120ms |
会话长驻、跨编辑复用。冷启动只付一次,所以不会把 0.5s 摊到每次写入上。
测试
npm test # 166 用例
npm run typecheck
| 套件 | 用例 | 说明 |
|---|---|---|
src/radius.test.ts | 65 | 纯逻辑,不碰子进程 |
src/extract.test.ts | 28 | 工具调用识别与 opaque 判定 |
src/client.test.tsx | 18 | 面板(jsdom) |
src/discover.test.ts | 16 | 文件发现的边界与截断 |
tests/lsp.spec.ts | 19 | 真实 tsserver,含无 tsconfig 场景 |
tests/plugin.spec.ts | 20 | 真实 cordis,闸门与 status 路由 |
LSP 层刻意不 mock:它是唯一有真实失败模式的组件(子进程、帧协议、项目加载), mock 掉就等于没测到唯一的难点。
原型工具
仓库里带一个 probe 脚本,可以在任意真实仓库上直接跑分析、打印结果 —— 用来判断信号 质量、调阈值,不需要先装成插件。只在源码仓库里可用(未随 npm 包发布):
git clone https://github.com/haoku123/dsh-blast-radius
cd dsh-blast-radius && npm install --legacy-peer-deps
node scripts/probe.ts ~/your-project src/some-file.ts [symbolName]
需要 Node ≥ 22.6(原生运行 TypeScript)。输出示例见本文开头。
限制
- 只支持 TypeScript / JavaScript。Python 需要另装 pyright,选型与降级策略完全不同, 架构上留了 provider 接口但 v1 不做。
references拿不到动态调用:反射、字符串索引、eval、跨语言边界。- 补丁式编辑工具无法分析(见上)。
- 无 tsconfig 时项目范围是推断的,可能漏掉调用点。
- 不做「AI 判断风险」。全部基于确定性事实 —— 一个会给出不可复现结论的质量门是 负资产。
License
MIT