# SecFusionAgent 需求基线

[English](Requirements-SPEC.en.md) | 中文

> 交互视图：**Requirements 视图（模块分层与数据流）** — [中文](https://jiale-li-orion.github.io/SecFusionAgent/requirements.html) · [English](https://jiale-li-orion.github.io/SecFusionAgent/requirements.html?lang=en)

改动产品行为、技术设计或评测口径之前先读本文。本文定义 SecFusionAgent 的拆解依据、模块划分、数据语义与验收口径。需求评审于 `2026-09-25` 完成，本文件作为冻结需求基线；改变 M1–M8、C1–C3、验收口径或四类风险边界的设计变更需要重新进入 Requirements Review。评分表、交付物清单与赛程时间由[赛题九原文](赛题：网信产业应用赛道‐智能体驱动的-AI-安全知识情报系统设计与实现)持有；技术架构、组件选型、模型、数据库与接口属于 Technical Design Review。

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

## 拆解依据

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

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

命题标准给出指标而未给出统一测试集与 `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](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](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](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](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 分。分值明细与交付物清单见[赛题九原文](赛题：网信产业应用赛道‐智能体驱动的-AI-安全知识情报系统设计与实现)。

## 命题标准覆盖

下表把命题标准的评分项映射到本文模块，需求评审按此表检查覆盖，分值明细见[赛题九原文](赛题：网信产业应用赛道‐智能体驱动的-AI-安全知识情报系统设计与实现)。

| 评分项 | 承担模块 |
|---|---|
| 情报监测功能完整性 | [M1 情报监测](#m1-情报监测) |
| 情报富化功能完整性 | [M3 情报富化与关联](#m3-情报富化与关联) |
| 情报问答功能完整性 | [M6 研判与问答](#m6-研判与问答) |
| 监测时效性与稳定性 | [M1 情报监测](#m1-情报监测)；[M8 工程与运行](#m8-工程与运行) |
| 富化准确率与召回率 | [M3 情报富化与关联](#m3-情报富化与关联) |
| 问答深度与准确率 | [M6 研判与问答](#m6-研判与问答)；[M7 评测](#m7-评测) |
| 智能体架构设计 / 智能体运用水平 | [M5 Agent 调查](#m5-agent-调查) |
| 系统自动化程度 / 系统自动化与工程化 | [M8 工程与运行](#m8-工程与运行) |
| 文档质量 | [赛题九原文](赛题：网信产业应用赛道‐智能体驱动的-AI-安全知识情报系统设计与实现) 的报告内容项 |
| 演示效果 | [M7 评测](#m7-评测) 演示案例 |
| 创新性、系统性、实用性、团队协作 | [拆解依据](#拆解依据)；[模块结构](#模块结构)；[M8 工程与运行](#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 运行要求；具体方案见[产品账户、会话与个性化](Product-Accounts-and-Personalization)。本节对真实产品入口的要求优先于上文早期“演示案例”措辞，评测能力仍留在工程侧。

- **身份与私有数据**：用户可注册、登录、退出，关闭页面后在有效会话内保持身份。服务端从可撤销会话推导身份；客户端自报 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 准确率/时延仍需用当前交付版本单独评测，不能由账户功能通过推断。