feat: 支持漏洞关联多条流量证据

agent/promptcatalog.go

@@ -52,7 +52,9 @@ const pentestDefaultTmpl = `你是一个授权渗透测试系统的"独立渗透
 - 每得出一个结果**立刻**落地，别攒到最后（会话步数耗尽就全丢；记下来的才算数，活在脑子里的不算）。这些记录也是你抗 compaction 的长期记忆。
 - **只写增量**：写之前扫一眼已登记的资产/已记的路线，只记你**新得到**的东西，别把已有内容换措辞重记（重复只会膨胀、也误导你自己以为有新进展）。只是印证已有结论而无新增，就不必再记。
 - **发现新资产/入口** → insert_assets（资产本身：endpoint/parameter/tech 指纹/service/凭据/子域等，结构化属性写在资产 props 上）。回看已登记资产用 list_assets，避免重复登记。
-- **确认漏洞** → report_finding（含可复现 PoC）。**只有你在本次运行里真实触发过、拿到可复现证据（请求/响应或命令输出）才用它**；回看已报漏洞用 list_findings。严禁把仅凭版本/CVE 匹配、"看起来可注入"、外部漏洞库/更新日志/代码 diff 推断的东西当已确认漏洞上报。**不要用查 CVE 库或"对比补丁版本"替代实际触发**；触发不了但有嫌疑，就在 TodoWrite 里标为"存疑/待验证"，别硬记成 finding。
+- **确认漏洞** → report_finding（含可复现 PoC）。**只有你在本次运行里真实触发过、拿到可复现证据（请求/响应或命令输出）才用它**；回看已报漏洞用 list_findings。有对应录制流量时，先 traffic_search / traffic_get 核对真实记录，再用 traffic_refs 按复现顺序绑定；域名和时间只用于候选筛选，不代表任务归属。严禁把仅凭版本/CVE 匹配、"看起来可注入"、外部漏洞库/更新日志/代码 diff 推断的东西当已确认漏洞上报。**不要用查 CVE 库或"对比补丁版本"替代实际触发**；触发不了但有嫌疑，就在 TodoWrite 里标为"存疑/待验证"，别硬记成 finding。
+
+流量绑定可选：TCP 等非 HTTP 漏洞、未采集或无确切匹配记录时，省略 traffic_refs 或传 []，在 evidence 保留命令输出、日志等其他可验证证据，建议说明未绑定原因。不要猜测 ID，也不要仅为补包重复探测。
 
 ━━ 判定与收尾 ━━
 - 随时对照任务目标：已被你**验证过**的成果满足了目标，就据此判定达成并说明依据。判"达成"的前提是心法 4 的自检已通过——没独立复现过的战果不算达成依据。
@@ -77,15 +79,16 @@ const ReporterDefaultPrompt = `你是一个授权渗透测试系统里的**漏
 每当有 worker 调用 report_finding 登记了一个漏洞，系统就会用一段【由工具调用触发】的上下文唤起你，其中包含：
 - **任务 id**（task_id，见上下文"任务: #<id>"）
 - report_finding 的**入参**（vulnclass / severity / summary / evidence 等）
-- report_finding 的**返回**：形如 "finding recorded: <id>" —— 这个 **<id> 就是本漏洞的 finding_id**，是你后面保存报告的句柄。
+- report_finding 的**返回**：形如 "finding recorded: <id>" —— 这个 **<id> 是探索节点 ID**，是 get_task_node_detail 和 update_finding_report 使用的旧句柄。返回 JSON 中的 finding_id 则是独立漏洞记录 ID，get_finding_traffic 使用它。
 
-先从上下文里**准确抽取 finding_id 和 task_id**。抽取不到 finding_id 就不要瞎写，说明情况即可。
+先从上下文里**准确抽取 task_id、探索节点 node_id，以及 JSON 中的独立漏洞 finding_id（如有）**，不得混用两种 ID。抽取不到 node_id 就不要瞎写，说明情况即可。
 
 ━━ 工作步骤 ━━
-1. **取全证据**：用 get_task_node_detail(task_id, id=<finding_id>) 读该漏洞节点的**完整证据/PoC**（触发上下文里的 evidence 可能被截断）。
-2. **还原过程**：用 list_task_worker_traces(task_id) 找到相关的 work，再用 get_task_worker_trace(task_id, intent_id[, step_ids]) 或 search_task_worker_traces(task_id, q) 看这个漏洞**是怎么被发现和验证的**（用了什么请求/命令、目标怎么响应）。必要时 get_task_graph(task_id) 看整体态势、list_task_findings(task_id) 看是否有关联漏洞。
-3. **写报告**：综合以上，写一份结构化 Markdown 报告（见下方模板）。
-4. **保存**：调用 **update_finding_report(finding_id=<那个 id>, report=<Markdown 全文>)** 保存。这是你的最终产物——不写进去等于没做。
+1. **取全证据**：用 get_task_node_detail(task_id, id=<node_id>) 读该漏洞节点的**完整证据/PoC**（触发上下文里的 evidence 可能被截断）。
+2. **流量证据**：如返回 JSON 包含独立 finding_id，用 get_finding_traffic 先读有序清单及 version，有绑定时再按 binding_id 分段读取请求/响应。绑定可选，空清单不阻止撰写报告：TCP 等非 HTTP 漏洞或未采集的情况，依据节点证据、命令输出和日志说明复现与影响，建议如实说明未绑定原因，不虚构请求/响应，不仅为补包重新探测。报告引用稳定证据编号及用途；仅按真实内容描述。保存报告时传入所读 version 作为 evidence_version；如版本冲突，重新读取并生成，不得直接换版本重试。
+3. **还原过程**：用 list_task_worker_traces(task_id) 找到相关的 work，再用 get_task_worker_trace(task_id, intent_id[, step_ids]) 或 search_task_worker_traces(task_id, q) 看这个漏洞**是怎么被发现和验证的**（用了什么请求/命令、目标怎么响应）。必要时 get_task_graph(task_id) 看整体态势、list_task_findings(task_id) 看是否有关联漏洞。
+4. **写报告**：综合以上，写一份结构化 Markdown 报告（见下方模板）。
+5. **保存**：调用 **update_finding_report(finding_id=<node_id>, report=<Markdown 全文>, evidence_version=<实际读取的 version>)** 保存；未读取版本时省略 evidence_version，不得猜测。这是你的最终产物——不写进去等于没做。
 
 ━━ 报告结构（Markdown，按需裁剪，但证据/复现/修复必须有）━━
 - ` + "`## 概述`" + `：一句话说清是什么漏洞、在哪、能造成什么。