# 掃描方法與成本控制

> 這份記錄「怎麼跑掃描、花多少、踩過什麼坑」，讓後續批次不必重新摸索。

## 工具

Claude Code 官方 plugin `claude-security@claude-plugins-official` v0.10.2.3。

啟動方式是 `/claude-security` 開選單，選 Scan codebase。
它實際跑的是 `claude-security:scan` workflow，會派出一群 subagent 分工。

## 掃描設定

第一批用的參數：

| 項目 | 值 |
|------|-----|
| 掃描根目錄 | `~/Projects/Jedicogy/module/jedi-python-package` |
| scope | `jedi-common,jedi-iam`（453 個 tracked 檔） |
| effort | `medium` |
| focus | `attack-surface`（tests/dist/docs 只當背景參考，不當稽核目標） |

## effort 等級與成本

這是踩坑重點。四個等級的差別**全在研究階段派多少 agent**，驗證面板固定三人。

| 等級 | 研究規模 | 實際 agent 數（約） |
|------|---------|------------------|
| low | 單一 researcher 掃完整個 scope | 5 到 6 |
| medium | 每個「元件 × 弱點類別」各一位，再加一輪 breadth sweep | 40 以上 |
| high | 每格兩位、兩輪 sweep、更細的元件切分 | 80 以上 |
| max | high 再加紅隊逐條反駁 | 更多 |

**medium 為什麼這麼貴**：它先把套件切成 N 個元件，然後展開成矩陣派工。
每個 agent 都從零開始讀檔、沒有共用 context，所以同一支 `ldap_adapter.py`
被至少 8 個 researcher 各讀了一遍——這也是為什麼 32 筆原始發現去重後只剩 19 條。
重複的發現就是重複的 token。

再加上 researcher 與 verifier 的設定是 `effort: xhigh`、`model: inherit`，
等於一百多次前沿模型的高強度推理。

## 實際發生的事（2026-09-05）

1. **第一輪 medium**：跑約 40 分鐘，派出 40 個 agent，研究階段收到 32 筆候選發現。
   因為成本明顯失控，在面板驗證開始前手動停掉。
   **這 32 筆就是 batch1 清單的來源**，屬未驗證的原始宣稱。

2. **第二輪 low**（只掃 jedi-iam）：想驗證 low 是否真的便宜。
   確實只派了 2 個 researcher（一個主掃、一個 secrets pass），
   但跑了 2 小時 15 分後**全部 agent 因 session 額度用盡而失敗**，零產出。
   工具重試了 4 次都撞同一道牆。

## 給下一批的建議

- **用 low**，除非有特別理由。從第一輪的結果看，medium 多出來的 30 幾個 agent
  主要產出的是重複發現，不是新發現。
- **一次只掃一支套件**。453 個檔已經讓 low 跑了兩小時以上。
- **確認額度充足再開始**。掃描是 all-or-nothing——中途沒額度就整輪報廢，
  已經跑完的 agent 結果拿不到正式報告（雖然還能從 journal.jsonl 手動撈）。
- **主 session 可以先切便宜模型再啟動**，subagent 會繼承主 session 的模型。

## 撈中斷結果的方法

掃描中止時，正式報告不會產生，但每個 agent 的回傳都寫在 workflow 的 journal：

```
~/.claude/projects/<專案>/<session>/subagents/workflows/<run-id>/journal.jsonl
```

每行是一個 JSON，`{"type":"result", "result":{"findings":[...]}}` 就是該 agent 的發現。
用 Python 逐行解析、按 `file` + `title` 去重即可還原清單。

第一輪的 run id 是 `wf_442f835c-ddf`。