SecFusionAgent 需求基线

English | 中文

交互视图：Requirements 视图（模块分层与数据流） — 中文 · English

改动产品行为、技术设计或评测口径之前先读本文。本文定义 SecFusionAgent 的拆解依据、模块划分、数据语义与验收口径。需求评审于 2026-09-25 完成，本文件作为冻结需求基线；改变 M1–M8、C1–C3、验收口径或四类风险边界的设计变更需要重新进入 Requirements Review。评分表、交付物清单与赛程时间由赛题九原文持有；技术架构、组件选型、模型、数据库与接口属于 Technical Design Review。

当前实现逐项验收见 验收台账。需求基线不随完成状态改写，也不表示所有验收条件已经通过。

拆解依据

命题标准给的是三项能力，它们的模块边界按数据流阶段划分：监测、富化、问答读写同一份安全情报，各自回答一个阶段的问题——材料从哪里来、不同材料说的是不是同一个对象、围绕一个问题还缺什么、已有证据能支持什么结论。一个功能页可以并行暴露多个模块，一个模块也可以被多个页面消费。

性能指标与功能指标一一对应：监测时效性属于监测，富化准确率与召回率属于富化，问答准确率、推理深度与响应速度属于问答。每个模块持有自己的指标、评测集与回归，跨模块比较使用分层指标，避免均值掩盖单模块退化。

命题标准给出指标而未给出统一测试集与 gold standard（人工裁定真值），因此评测作为产品模块（M7）与功能模块并行开发：评测集固定问题文本与当时可见的证据，人工裁定记录依据，官方口径明确前它是唯一的比较基线。

命题标准的四类风险混合了两个维度：AI 基础设施、AI 应用与 Agent、供应链描述风险发生的对象或生命周期位置，提示词注入、系统提示词泄漏、数据投毒描述攻击方式。情报条目按对象、攻击方式、影响三个字段分别记录，一条事件可以落入多个对象类别；分类服务于研判与覆盖统计。四类全部进入范围，深度按样本可得性与证据可得性分配。

系统处理公开情报及其中的证据关系。公开 PoC、0day 报道与真实攻击事件作为分析材料进入情报链路，用于分析影响、版本、修复与证据关系；对真实互联网资产的利用动作留在客户环境，告警聚合与企业资产运营由既有 SOC/SIEM 承担，多租户运营属于商业化阶段的范围。

模块结构

层	模块	职责	主要交付
情报获取	M1 情报监测	发现新增情报，记录来源与时间	采集记录、来源健康
情报获取	M2 证据留存与规范化	保存原文并统一事件标识	原始证据、去重后的情报条目
情报加工	M3 情报富化与关联	补齐支持研判的字段与跨来源关系	富化字段及其来源证据
情报加工	M4 调查上下文	维护一个事件或漏洞的已确认事实、冲突与未知项	可读写、可追溯的上下文
调查交付	M5 Agent 调查	面向复杂问题执行多步调查与工具调用	调查轨迹、新增证据
调查交付	M6 研判与问答	形成结论并回答，标注未确认项	结论、引用、回答
支撑	M7 评测	固定评测集、回归与安全测试	指标结果、对抗样本集
支撑	M8 工程与运行	部署、可观测、异常恢复	运行链、告警与恢复记录

三条横切约束作用于全部模块，具体实现与验证落在括号中的模块：C1 证据可追溯（每项结论可定位来源，M2/M3/M6）、C2 外部内容不可信（系统规则、工具权限与允许执行的动作由配置与策略决定，外部材料改变的是系统可见的证据，M2/M5/M7）、C3 有界执行（任务有明确终态与重试上限，M5/M8）。

数据流：M1 产生采集记录，M2 产出情报条目与原始证据，M3 在其上富化并关联，三者的结果共同构成 M4 的上下文；M5 读写 M4 完成调查，M6 基于 M4 产出结论与回答，M7 对 M1 至 M6 逐模块评测，M8 承载全部模块的运行。

风险分类

风险分类是内容的维度，与模块正交：每个模块都处理四类风险，每类风险的样本由评测集按比例抽取。

AI 基础设施 / 推理框架

对象依据公开部署量、历史漏洞密度、公开 PoC、patch、版本信息与社区活跃度选定，这些量决定一个 repo 能否支撑富化与固定评测集。真实漏洞按原因分开记录：认证与暴露面、输入处理与代码执行、模型或插件加载、资源与租户隔离、配置、依赖与运行环境，各自的证据来源、影响对象与修复形式不同。目标 repo、L0–L5 功能层与 repo graph 由 01-Data-Sources-and-Processing 持有。

模型与数据层

模型与数据层按 Training / Fine-tuning Integrity、Model Artifact Integrity、Inference / Alignment Integrity、Confidentiality / Privacy、Retrieval / Embedding Integrity 五组组织；prompt injection 作为跨层 technique 连接模型行为、retrieval content 与 Agent/tool execution。分类体系、文献证据链、前沿情报监测和 residual risk 表达由 04-AI-Model-Data-and-Agent-Application-Security 持有。

AI 应用与 Agent

Agent/Application 以 goal/context、tool/action、身份/privilege、execution 边界、memory/state、inter-agent/工作流六类 trust 边界组织风险。模型决策与软件执行分别记录原因和控制位置；sandbox、network、credential、memory、MCP/tool 与 side effect 的安全语义由 04-AI-Model-Data-and-Agent-Application-Security 持有。

供应链

供应链覆盖上游开发引入、中游构建交付与下游运行分发，主要对象包括 dependency、package、产物、container image、model/data 产物、plugin/skill、build 和 distribution channel。depends-on、contains、built-from、published-as、distributed-as、deployed-with 等影响传播语义由 02-CTI-Baseline-Reuse-and-Ownership 持有。

模型窃取、隐私泄漏、memory poisoning、模型后门、算力滥用与多租户隔离均能落入上述对象类别，并按攻击方式、影响与控制边界继续细分。当前没有证据支持新增第五个并列风险域；出现无法由四类对象和现有 relation 表达的新问题时重新进入 Requirements Review。

M1 情报监测

职责：发现新发布或更新的情报，记录其来源、发布时间与采集时间，并暴露每个来源的健康状态。输入是公开来源，输出是采集记录与事件候选。价值判断属于 M6 与研判环节，字段富化属于 M3，事件合并属于 M2。

内部阶段：来源发现、抓取或订阅、发布时间解析、事件候选生成、健康上报。来源的发布机制与更新时间决定采集方式，CVE/NVD、厂商公告、GitHub、论文与博客各不相同；时效起点口径见验收口径。单个来源不可用时其余来源继续采集，恢复后按幂等写入继续。

验收：来源类别覆盖 ≥7；选定来源中的事件实际进入系统的比例按 coverage 统计；时效只对有可靠发布时间的样本计算；来源失败与恢复在状态记录中可观察。

M2 证据留存与规范化

职责：保存原文与其元数据，把同一事件在不同来源中的表示归并为一条情报条目。输入是 M1 的采集记录，输出是原始证据与统一标识的情报条目。这一层是全系统的证据来源，任何后续结论都能回溯到这里。

内部阶段：原文留存、字段抽取、时间与来源标注、同一性判定、去重。来源冲突时保留双方材料与各自时间，冲突本身作为上下文的一项记录；增量更新与全量重采的结果区分记录。字段取值来自材料，材料未提供时记为未知。

验收：原始证据与加工结果分离存放；重复来源内容完成归并且多来源关系保留；冲突来源的双向材料完整；duplicate 与 parser correctness 单独统计。

M3 情报富化与关联

职责：围绕一条情报条目补齐支持安全判断所需的信息，并建立跨来源关系。输入是情报条目与原始证据，输出是带来源证据的富化字段。富化的产出是字段与关系，结论由 M6 依据这些字段形成。

内部阶段：维度抽取、跨来源关联、实体对齐、证据挂接。维度包括影响对象与版本、漏洞类型、利用条件、公开利用证据、patch 或 workaround、相关研究、厂商说明；论文关联、受影响资产、PoC、CVSS 是赛题给出的维度示例。每项字段记录来源证据，材料正确但挂到错误版本、产品或漏洞的情况按 entity resolution（实体对齐）错误统计。

验收：按字段计算 precision 与 recall；entity resolution 与 evidence correctness 单独统计；字段值正确但引用材料不支持该值时按证据错误计入；两个来源讨论同一产品但版本或组件不对应时不判为关联成功。

M4 调查上下文

职责：维护一个安全事件或漏洞的当前状态——已确认事实、来源冲突、未知项，以及支撑它们各自的证据。输入是 M1 至 M3 的产出与 M5 调查新增的证据，输出是 M5 与 M6 共用的可读写上下文。上下文是系统的中心对象：问答与调查从它的当前状态继续，已完成的检索与步骤在其中复用。

内部阶段：条目建立、事实写入与修正、冲突登记、未知项登记、证据索引。原始证据为只读层，加工事实与研判结果写入各自的层，后写入的结果可以修正先前判断。上下文对每次写入保留来源与时间，使结论可复核。

验收：给定一个事件可从上下文列出已确认事实、冲突与未知项；每项事实可定位到 M2 的原文；同一问题重复提问复用已有检索结果；上下文在并发写入下保持一致。

M5 Agent 调查

职责：面向无法由现有证据直接回答的问题执行多步调查——拆解目标、选择工具、读取外部材料、把新增证据写回 M4。输入是调查任务与 M4 的上下文，输出是调查轨迹与新增证据。Agent 处理调查过程中的不确定性与分支；采集、字段校验、去重与指标计算保持确定性。

内部阶段：任务拆解、工具选择与调用、结果评估、失败处理、终止判定。任务状态是开始、进行、成功、失败、超时、取消；执行记录覆盖任务拆解、工具调用与参数、工具结果、失败与重试、结束原因。工具失败、超时、部分结果与来源不可用改变后续动作；重试以幂等写入为前提，同一事实在重复执行下保持单条。工具权限、secret 与 sandbox 同外部内容之间保持边界。

验收：task success、tool selection、tool arguments、trajectory、recovery、timeout、latency 与 cost 分别统计；模型、prompt、tool policy、检索与解析逻辑变更后在同一批样例上回归；每个任务在有限步数与时限内到达终态。

M6 研判与问答

职责：把上下文中已验证的证据组织成结论与回答，并标明未确认项。输入是 M4 的上下文，输出是结论、引用与回答。简单问题由现有证据直接回答；复杂问题（某漏洞是否影响某部署版本、公开 PoC 是否适用于该版本、厂商修复是否覆盖某利用路径）触发 M5 调查，新增证据回到 M4 后完成回答。

内部阶段：意图解析、证据选取、跨来源组合、多跳关联、结论标注。回答保持事实、加工事实与研判三层分离；用户围绕同一漏洞追问时保持对象、版本与已确认条件一致。证据不足、来源冲突或关键事实无法确认时，回答标明未确认项与已找到的相关证据。

验收：accuracy 看最终答案，groundedness（结论有据）看结论的证据覆盖，citation correctness（引用正确性）看引用是否支持对应说法，多跳题额外检查中间关系；普通交互式 QA 与需联网继续调查的长任务分别统计 latency。

M7 评测

职责：为 M1 至 M6 各自提供可重复的质量结论，并维护面向 AI 与 Agent 的安全测试。输入是各模块的产出与评测集，输出是指标结果与对抗样本集。评测与功能模块同时开发，指标结果随模块交付一同产出。

内部阶段：评测集维护、人工裁定、指标计算、回归执行、故障注入、对抗测试。固定评测集 固定版本与时间截面，问题文本与当时可见的证据一并保存；可由结构化字段或规则判定的内容走确定性判定，需要安全研判的内容走人工复核或模型辅助评审。adversarial set（对抗样本集） 覆盖 direct 与 indirect prompt injection、poisoned source、malicious tool output、hallucinated evidence、tool misuse、privilege violation，以及 Web、后端与存储层的传统攻击面。

验收：每个模块有对应指标与冻结样例集；模型、prompt、tool policy、检索或解析逻辑变更后回归可比；故障注入验证失败隔离、重试与有界终止；比赛用的演示案例从评测集中选取，包含完整证据、调查轨迹与 failure/recovery 过程。

M8 工程与运行

职责：承载 M1 至 M7 的部署、可观测与恢复。输入是各模块的运行产物，输出是运行链、日志、指标、告警与恢复记录。凭据、token 与敏感配置保存在部署环境的密钥管理中，Agent 读取外部内容时通过引用使用。

内部阶段：构建与部署、日志与指标采集、告警、异常恢复、版本标注。每次变更自动执行确定性测试与关键评测集并生成可识别版本；部署出现 source failure、错误关联、错误回答或安全测试失败时从日志与任务记录定位，并把真实 failure 转为新的 regression case。来源之间相互隔离，单个来源失败时其余来源继续采集；工具超时与重试有明确上限，持续故障进入告警。

验收：容器化部署可重复执行；CI/CD、日志、监控与告警在运行中得到验证；失败可定位到任务与来源；每个模块的设计取舍、评测方法与失败处理由团队成员讲清并用实验复现，代码在使用 AI 辅助后逐段复核。

开发顺序是 SPEC → 需求评审 → DESIGN → 技术评审 → PROBE → 模块实现 → 集成测试 / 系统评测 → Release → Deploy → Operate → Incident / Feedback → 下一轮迭代。探针 只回答高风险技术问题：某来源能否稳定采集、某类 repo 的漏洞样本是否支撑评测集、某评测方法能否区分好坏。探针结论回到正式设计。

M1–M3 Review Addendum — 2026-09-26

本次 Requirements Review Addendum 不改变 M1–M8、C1–C3 或赛题优秀档目标，只把 M1–M3 之前未固定的 coverage denominator、证据质量和富化 P/R 计算对象落成可重复口径。赛题初赛的富化性能只规定准确率阈值，决赛同时规定准确率与召回率；本项目继续按决赛优秀档 precision ≥95%、recall ≥95% 开发，初赛报告直接复用同一评测集的 precision。

M1 coverage 与时效

产品数据源 taxonomy 固定为八类：vulnerability、development、academic、vendor、independent、normative、assets、incidents。这八类全部进入 source-category coverage；比赛要求是覆盖 ≥7 类，因此产品当前目标高于最低优秀/功能门槛。assets 的生命周期属于 M3 on-demand enrichment side path，但处理方式不改变它作为第七类数据源的 taxonomy 身份。某类别只有在 source inventory 中存在 coverage=owned 的 fixed/grouped executable owner，且 runtime adapter 可以构造时才算 supported；partial、dynamic_resolution 和某次 live reachability 不增加类别数。

category_coverage 与 source_delivery_coverage 分开统计。前者是上述 supported category 数；后者在固定 source/window 中，以预先冻结的 SourceDeliveryKey(source_id, external_object_id, external_revision | content_hash) gold key 为分母，统计进入对应 M1/M2 accepted lifecycle 的唯一 revision 比例，同时报告 missed 与 unexpected key。unexpected item 不进入 coverage 分子。

监测 latency 的单样本定义为可靠 published_at → M2 available_at/committed_at。没有可靠发布时间的样本不进入 latency 数值分母，但必须同时报告 latency_evaluable_coverage；固定评测报告保存逐样本结果，内部回归同时报告 p50 / p95 / max / ≤6h pass-rate。live source probe 继续作为时点 reachability report，不承担 coverage 或 latency correctness 的验收职责。

M2 identity 与 evidence quality

Cross-source identity 优先使用强标识：CVE/GHSA/OSV/CNVD/CNNVD、DOI/arXiv、GitHub repo full name、package PURL 或 ecosystem+name、commit SHA。不同 namespace 只有在来源明确 cross-reference 或确定性 mapping 能证明同一对象时才自动合并；名称相似不足以触发 object merge。

accepted claim/relation 必须能解析到 Observation / Artifact 与 locator。structured mapping 的 locator 必须支持该字段或关系；semantic extraction 还要求引用文本真实存在于固定 source revision。M7 单独统计 parser field accuracy、entity-resolution precision/recall、evidence correctness、replay suppression 与 conflict preservation，这些 diagnostic metric 不混入比赛的 M3 enrichment P/R。

M3 closed set 与 M7 enrichment metric

M3 vocabulary 分为 canonical / source_specific / exploratory。canonical term 只有在注册的 subject/target shape 同样匹配且标记为 benchmarked 时才进入正式 enrichment P/R；provider 原始字段继续保存为 source-specific state。semantic extraction 如果使用 canonical 名称但 shape 不满足 canonical contract，结果保留为 evidence-backed exploratory state；deterministic/source-asserted 的 shape 违规直接拒绝。未注册 semantic term 同样保持 exploratory，经过 vocabulary review 后才能进入新的 canonical revision。

enrichment-v1 固定十二个 dimension：identity、severity、weakness、product/package、version applicability、fix/remediation、exploit state、exploit likelihood、advisory/reference、asset exposure、research/paper、incident context。比赛点名的 CVSS、PoC、受影响互联网资产、论文关联都在该闭集内。PoC gold 使用 canonical Vulnerability --has-poc→ ExploitArtifact relation，poc_available 只作为派生便利投影；论文关联 v1 评测 ResearchWork/Document --discusses-vulnerability→ Vulnerability，更开放的 research relation 在 object model 与 gold protocol 冻结前不进入正式 P/R。产品/版本适用状态固定为 affected / not_affected / fixed / under_investigation / unknown，并通过 scoped Vulnerability --applicability-status→ Product|Package|SoftwareVersion relation 表达；qualifier 至少包含 state 与 source_semantics。query miss 或不可比较版本只能得到 unknown，not_affected 必须有结构化状态、规则或 VEX justification 支撑。workaround / mitigation / attack_condition 等开放文本在 v1 可以作为 canonical、evidence-backed knowledge 保存，但在形成 normalized schema 前标记 benchmarked=False，不进入 closed-set P/R。

正式 gold 的最小单元是 EnrichmentFactKey(stable root object key/type, vocabulary revision, dimension, claim|relation kind, predicate/relation, normalized value/target, target object type, qualifier keys + normalized qualifier, temporal scope)。TP 要求 tuple、实体/版本 scope 与 EvidenceRef 同时正确；错值、错实体、错版本、错 relation、把 unknown 推成 not_affected、无证据 accepted fact 都计 FP，gold 缺失计 FN。gold 本身必须通过同一 vocabulary 的 subject/target shape 与 required qualifier 校验。主报告给出 micro precision/recall 以对齐赛题阈值，同时给出 dimension-macro P/R 防止高频简单字段掩盖 PoC、asset、paper relation 等维度。

M3→M4 的 storage/read handoff 已通过 executable gate；本 addendum 冻结 semantic enrichment handoff 的输入语义：M3 能报告 canonical dimension 的 resolved/conflict/unknown/missing 状态。M4 如何把这些 gap 转成 Task / Tool / Policy 属于 Technical Design 2 的后续评审，不改变 M3 的 vocabulary 与 gold definition。

验收口径

优秀档数字是本阶段目标：数据源覆盖 ≥7 类；监测延迟 ≤6h；富化 precision 与 recall 均 ≥95%；QA accuracy ≥95%，含多跳推理与关键证据关系解释；普通交互式 QA ≤5s。每个数字与固定评测集、人工裁定真值、计算方法、原始结果一同提交。

时效从来源首次公开计到 M2 形成可用记录，计算范围限定在有可靠发布时间的样本。命题标准的分值结构决定投入顺序：初赛的功能指标与优化指标合计 70 分，性能指标合计 15 分；决赛的功能指标与优化指标合计 55 分，性能指标 20 分而问答质量独占 10 分。初赛富化准确率达到 95% 进入优秀档；决赛要求 enrichment precision 与 recall 均达到 95%。超过评分阈值后的继续提升体现为情报质量增益；智能体架构从“基本使用 Agent 框架”到“Agent 多角色协作与自主编排”值 6 分，系统自动化从“含异常处理”到“含自愈”值 2 分。分值明细与交付物清单见赛题九原文。

命题标准覆盖

下表把命题标准的评分项映射到本文模块，需求评审按此表检查覆盖，分值明细见赛题九原文。

评分项	承担模块
情报监测功能完整性	M1 情报监测
情报富化功能完整性	M3 情报富化与关联
情报问答功能完整性	M6 研判与问答
监测时效性与稳定性	M1 情报监测；M8 工程与运行
富化准确率与召回率	M3 情报富化与关联
问答深度与准确率	M6 研判与问答；M7 评测
智能体架构设计 / 智能体运用水平	M5 Agent 调查
系统自动化程度 / 系统自动化与工程化	M8 工程与运行
文档质量	赛题九原文 的报告内容项
演示效果	M7 评测 演示案例
创新性、系统性、实用性、团队协作	拆解依据；模块结构；M8 工程与运行

需求评审结论与设计移交

Requirements Review 已完成。2026-09-26 的 M1–M3 addendum 进一步冻结监测/富化评测语义，不改变模块职责。原 T0–T4 均不再阻塞 Technical Design：

项目	冻结结论	后续归属
T0 评测集来源	选手自行构建数据集，测评阶段由评委使用	M7 设计固定评测集、人工裁定真值与回归版本
T1 受影响互联网资产	资产对象、证据语义和 Censys/Shodan/FOFA/ZoomEye 等 provider 类型已固定	具体 query、fingerprint 映射、地域过滤与验证方法进入 M3 Design / 探针
T2 AI Infra / 供应链	AI Infra target repo、功能层和 repo graph 已固定；供应链对象、制品与传播关系已进入基线	具体 connector、SBOM/来源链路处理和 graph execution 进入 M1–M3 Design
T3 模型与数据分类体系	五组 risk family 与跨层 prompt injection 语义已固定	评测集样本比例由 M7 按证据可得性和比赛覆盖目标设计，不改变需求分类
T4 其他 AI 风险	当前候选均可落入四类对象与现有攻击/影响维度	新风险无法表达时重新打开 Requirements Review

实时监测 没有统一轮询要求。M1 根据 source registry 的 update semantics 分别设计 delta、API、Git、RSS、页面 diff 与 on-demand schedule，并以 ≤6h 作为比赛验收目标。普通 QA 与长时 investigation 的路由阈值属于 M5/M6 Technical Design；该阈值不改变两模块的职责边界。

冻结后的实现顺序保持 M1/M2 → M3 → M4 → M5 → M6，M7 与 M8 横切推进。Technical Design 从 information intake / knowledge plane 开始，把已经固定的 source、证据、object、relation 与 retrieval contract 落成可执行的数据流和组件接口。

Product 追加需求：账户与个性化 — 2026-10-08

本节承接用户在 Product Web 收尾时追加的注册、登录态、个人关注、会话绑定要求。它补充 M6 问答功能中“个性化推荐”的决赛优秀档语义，以及 C1 可追溯、C3 权限边界和 M8 运行要求；具体方案见产品账户、会话与个性化。本节对真实产品入口的要求优先于上文早期“演示案例”措辞，评测能力仍留在工程侧。

• 身份与私有数据：用户可注册、登录、退出，关闭页面后在有效会话内保持身份。服务端从可撤销会话推导身份；客户端自报 principal 无权取得他人数据。个人提问、会话、Case、Decision、Task、关注、推荐反馈及其读/写/流式接口必须按账户隔离。公共来源、Evidence 与 canonical Knowledge 保持共享，不因用户偏好改变事实权威。
• 继续会话：START 可列出当前账户的近期会话并恢复持久 session/turn/target/Decision/Case 坐标。刷新页面和重新登录后继续真实会话；“新会话”清除旧结果和对象绑定。上一回合失败、等待和已经形成答案分别展示真实状态。
• 个性化推荐：用户明确输入关键词或关注对象后，系统从当前有证据且 accepted 的知识候选形成有理由的推荐；可打开来源、标记感兴趣或忽略并撤销。推荐不能冒充训练模型推断或把 missing/unknown 装饰为已验证事实。
• 安全与运行：密码不可明文保存；会话令牌不可进入前端持久存储或数据库明文；写操作校验同源和 CSRF；退出撤销服务端会话。生产入口需 HTTPS 与明确浏览器 Origin。公共的 system Case 只开放纯系统来源的只读引用，不授予取消或续写权。

验收以双账户真实浏览器/API 操作为准：注册/登录、偏好与反馈持久化、推荐理由到证据、提问/调查与会话恢复、退出拒绝私有读取，以及伪造身份头和跨账户 URL/SSE/A2A 访问失败。当前实现不含邮箱验证、密码找回与 OAuth；这些属于后续账户生命周期需求，不计入本轮登录与会话交付。决赛 QA 准确率/时延仍需用当前交付版本单独评测，不能由账户功能通过推断。