Workflow 原型
固定执行"页面识别 → 数据分析 → 法规检索 → 合规裁决"，适合验证闭环，但容易产生冗余调用和上下文过长。
系统的技术路线并非一开始就确定为多智能体系统，而是围绕"用户如何理解 App 正在收集哪些隐私信息、这些行为是否与政策一致、系统如何给出可解释答案"逐步演进。经历了固定 Workflow → 单 Agent → 多 Agent 协同三个阶段。
| 维度 | Before（初版） | After（当前版本） | |
|---|---|---|---|
| 系统架构 | 固定 Workflow 串联，冗余调用多 | → | 多 Agent 协同，MasterAgent 动态调度 |
| 页面理解 | OCR + 图标分类，缺少上下文语义 | → | MLLM 多模态理解，GUI → 场景 → 意图映射 |
| 政策检索 | Word2Vec 词向量，Top5 Recall 42% | → | BM25 + 领域微调 Reranker，Top5 Recall 85% |
| 代码分析 | 敏感 API 规则匹配，仅检测出现 | → | FlowDroid 污点分析，Source → Sink 路径追踪 |
| 答案质量 | 无引用、无验证，幻觉率高 | → | CoT + Self-Verification，带条款引用的可解释结论 |
| 多轮对话 | 无上下文记忆，指代词混乱 | → | 指代消解 + 结构化上下文压缩 |
选择不同类型的用户问题，观察 MasterAgent 如何进行意图识别、任务规划，并调度对应的 Agent 完成证据收集与裁决。
系统涉及多模态理解、静态程序分析、信息检索与大模型推理四个技术领域，以下是各模块使用的核心技术与工具。
UIAgent 的目标是识别当前 App 页面可能涉及哪些个人信息类型。迭代核心是从"识别页面文字"升级为"理解页面正在发生什么"。
手机号，但它可能是注册输入框、账号绑定入口，也可能只是客服电话。多模态模型可以结合输入框、按钮和页面标题判断其真实语义。
RAGAgent 的迭代重点是让系统从"找到相似段落"升级为"召回能支撑回答的证据条款"。基于 OPP-115 Taxonomy（隐私政策标注框架，将政策文本分为数据类型、收集目的、共享对象等 115 个类别）设计分层切块策略。
| 阶段 | 技术方案 | Top5 Recall | MRR | 迭代原因 |
|---|---|---|---|---|
| V1 | Word2Vec + Cosine Similarity | 42% | 0.28 | 存在 OOV 问题，难以表达"设备标识符、第三方 SDK"等领域语义 |
| V2 | BGE / SimCSE / E5 向量检索 | 61% | 0.42 | 句向量语义召回提升，但"定位""注销"等短 Query 仍不稳定 |
| V3 | 关键词检索 + 向量检索 | 68% | 0.48 | 短 Query、专有词和法规术语更适合关键词召回 |
| V4 | BM25 + 向量混合检索 | 73% | 0.53 | BM25 更适合长文档和条款级检索 |
| V5 | 混合检索 + 通用 Reranker | 71% ↓ | 0.50 | 通用重排模型与领域分布不一致，偏向表面语义相关而非证据充分性 |
| V6 | 混合检索 + 领域微调 Reranker | 80% | 0.61 | 用隐私政策正负样本训练"能支撑回答"的排序能力 |
| V7 | Query Rewrite + HyDE + 问题分解 | 85% | 0.68 | 解决口语化、模糊指代和复杂问题拆解 |
这个能不能不给？用户是否可以拒绝提供精确位置信息？它会传给别人吗？该 App 是否会向第三方共享设备标识符？注销后数据保留多久？会不会把定位给别人？不给会怎样？CodeAgent 负责回答"代码里是否真的采集或上传了这些数据"。从简单的敏感 API 匹配迭代到基于 FlowDroid 的 Source-Sink 数据流追踪。
MasterAgent 是系统的大脑。它根据用户 Query 判断需要哪些证据，按 ReAct 模式调用对应 Agent，再用 CoT 与 Self-Verification 生成证据约束答案。
这个页面为什么要我的精确位置？不授权会怎样？用户经常连续追问"它会给谁""这个能不能不给""拒绝后还能用吗"。系统需要把指代词恢复成明确对象，并把对话历史压缩成结构化记忆，以支持稳定的多轮交互。
系统在 50 款 Android 应用的测试中，交互问答准确率达 76%、隐私敏感操作识别准确率达 91%，API 调用关联正确率达 82%。在人工构建的合规问答评测集上，基于 RAGAS 框架评估，引入领域微调与重排机制后，Top5 召回率由 65% 提升至 85%，MRR 提升至 0.68。
单 Agent 在早期验证阶段是可以工作的，但随着系统复杂度增加，暴露出几个问题：
1）上下文过长：UI 分析、代码分析、法规检索结果全部塞给一个 Agent，容易超过上下文窗口限制。
2）职责过重：一个 Agent 同时负责规划、感知、检索、分析和裁决，Prompt 维护成本高，调试困难。
3）输出不稳定：不同类型任务混在一起，容易产生推理跳跃。
多 Agent 架构让每个 Agent 专注一类证据，MasterAgent 只负责调度和裁决，边界更清晰，也更容易独立优化每个模块。
FlowDroid 的主要局限：
1）Source/Sink 定义依赖人工：需要维护敏感 API 列表，新增 SDK 或 API 时需要手动补充。
2）对反射和动态加载支持有限：部分 App 使用反射调用敏感 API，FlowDroid 可能漏检。
3）路径爆炸：复杂 App 的调用图可能非常大，分析时间长。
我们的处理方式：结合 SuSi 官方列表 + Android Dangerous Permissions + 第三方 SDK 上报接口进行补充；对反射调用做简单的模式匹配兜底；限制分析深度控制时间成本。
1）领域适配：通用 LLM 对隐私政策的专业术语（如"设备标识符""个性化推荐""第三方 SDK"）理解不够精准，需要领域微调的 Embedding 和 Reranker。
2）可溯源性：合规场景要求答案必须有条款引用，自建检索链路可以精确控制证据来源和引用格式。
3）成本控制：隐私政策文档量大（3000+），每次都让 LLM 全文理解成本太高，检索后只传相关段落更经济。
4）可控迭代：自建链路可以针对 bad case 逐步优化（比如 V5 的重排下降问题），黑盒 API 无法做到这种精细调优。
OPP-115 是 Carnegie Mellon 大学提出的隐私政策标注框架，包含 115 个细粒度类别，覆盖数据类型（如地理位置、联系人）、收集目的（如广告、分析）、共享对象（如第三方、关联公司）、用户权利（如删除、撤回同意）等维度。
我们用它来设计分层切块策略：按 OPP-115 的类别对政策文本进行元数据标注，检索时可以根据问题意图限定检索范围（比如"数据共享类"问题只在共享相关段落中检索），提升检索精度。
RAGAS 主要评估 RAG 系统的检索和生成质量，核心指标包括：
1）Faithfulness：生成答案是否忠实于检索到的证据，是否有幻觉。
2）Answer Relevancy：生成答案是否与问题相关。
3）Context Precision：检索到的上下文中，真正相关的比例。
4）Context Recall：回答问题所需的信息是否都被检索到了。
我们主要关注 Context Recall（对应 Top5 Recall）和 Faithfulness（对应答案 groundedness），这两个指标最能反映合规场景的核心需求。
1）动态分析：目前 CodeAgent 只做静态分析，如果能结合 Frida 或 Xposed 做运行时 hook，可以捕获反射调用和动态加载的敏感 API。
2）政策版本对比：很多 App 会更新隐私政策，可以加入政策版本 diff 功能，检测政策变更是否涉及新的数据收集行为。
3）自动化测试：目前的 50 款 App 测试是半自动的，可以接入 UI 自动化框架（如 UIAutomator）实现全自动遍历和检测。
4）法规知识库：当前 RAGAgent 主要检索 App 自身的隐私政策，如果能接入 GDPR、个保法等法规条文，可以做更全面的合规判断。