企业官网建设流程全解析

AI Agent 的测试一直是工程化过程中最模糊的环节。传统单元测试覆盖函数逻辑，集成测试覆盖系统交互，但 Agent 的决策过程可能涉及多轮工具调用、外部环境反馈和约束遵循，错误往往要埋在很深的调用链里才会暴露。Lucin 这类项目提供了一条不同思路：用静态分析去看 Agent 的可执行逻辑，并主动公开一个假阴性列表，让使用者明白当前分析器哪些问题能抓到、哪些抓不到。这种做法比单纯宣称“检测准确率高”更有工程价值，也值得单独拆开讲清楚。

这篇文章会围绕 AI Agent 静态分析，讲清楚为什么需要静态分析、假阴性列表在评估体系里处于什么位置、如何用最小可复现案例搭建一个“规则 + 测试集 + 报告”的评估闭环，以及在实际项目中怎么排查分析结果不准确的问题。文中示例使用 Python 标准库实现，不依赖重型框架，便于在本地跑通后迁移到自己的项目。

1. 理解 AI Agent 静态分析要解决什么问题

1.1 Agent 代码与传统代码的静态分析差异

传统静态分析面对的是确定性的程序行为。代码里写了subprocess.run，静态分析器就能在语法和调用关系层面看到这个调用，再根据参数来源判断是否存在风险。这类分析不运行程序，只分析源码、字节码或中间表示，所以效率高、结果可复现。

到了 AI Agent 场景，行为分成两层。一层是确定性代码，包括工具函数、状态机、权限判断、日志逻辑；另一层是模型决策，也就是 LLM 根据用户输入和上下文选择调用哪个工具、生成什么参数。后者在静态分析阶段只能看到它可能调用的工具定义和约束，看不到它最终会生成哪条调用链。Lucin 这类工具不试图预测模型输出，而是把可以静态化的一方拆出来做检查：工具定义是否泄漏了危险能力、工具参数是否使用了不可信输入、权限边界是否存在逻辑漏洞、密钥是否硬编码在代码里。

所以不要期待静态分析能抓住所有 Agent 故障。它能做的是把确定性问题提前暴露，把动态问题留给运行时评估。理解了这层边界，后续的假阴性列表才有意义。

1.2 静态分析可以覆盖哪些 Agent 缺陷

从实际经验看，Agent 项目里至少有以下几类问题适合静态分析：

举一个最小例子。某个 Agent 暴露了一个“删除文件”工具，用户发起对话后模型决定调用该工具。模型是否真的调用，静态分析管不了，但工具是否存在必要的最小权限校验、是否校验参数落在白名单目录，是完全可以从代码层检查的。Lucin 这类工具的价值就在这里：把 Agent 自身可控的安全边界先守住。

1.3 为什么假阴性列表是关键设计

假设你开发了一个 Agent 静态分析器，怎么证明它有用？常见做法是给一个检测率数字。但数字很容易被数据集选择影响：如果测试集里全是容易发现的硬编码密钥，检测率自然很高。真实环境里的问题往往被漏掉，而且你根本不知道它被漏掉了。

Lucin 的做法是公布一个假阴性列表，也就是明确指出当前分析器有哪些已知缺陷没有检测出来。这是一件反直觉但很正确的事。它产生三个直接效果：

第一，用户知道工具的边界，不会因为“静态分析过了”而产生虚假安全感。第二，维护者有了明确的迭代路线，每个假阴性都可以从列表变成新的测试用例，防止同一个漏报再次发生。第三，评估过程变得可审计，工具做得怎么样不是一句宣传语，而是一份可以逐条核对的清单。

对工程团队来说，假阴性列表就是一个风险登记册。它记录的不仅是工具的不足，也是 Agent 系统当前仍存在的、未覆盖的安全或正确性风险。

2. 用“假阴性列表”倒逼评估体系

2.1 先明确评估指标

建立假阴性列表之前，先要把评估指标说清楚。静态分析结果和人工标注对比后，会出现四种情况：

基于这四类值，通常计算三个指标：

• 精确率 Precision = TP / (TP + FP)：报出的问题里有多少是真问题。这个指标低，说明误报多。
• 召回率 Recall = TP / (TP + FN)：真实问题里有多少被找出来了。这个指标低，说明漏报多。
• F1 = 2 * Precision * Recall / (Precision + Recall)：综合分数，避免只看单边。

对 Agent 安全分析来说，精确率和召回率都重要，但场景不同，侧重点不一样。如果分析器在 CI 里每次提交都跑，误报太多会让开发者把结果当成噪声忽略，最终形同虚设。如果分析器用于上线前安全审计，漏报比误报更致命，因为漏报意味着真实风险被静默放过。

这里要引入一个关键数字：假阴性率 = FN / (FN + TP)。它和召回率互补，召回率 = 1 - 假阴性率。假阴性列表本质上就是所有 FN 样本的持续记录。

2.2 测试集怎么设计

要让假阴性列表有说服力，测试集不能偷懒。常见的错误是把所有样本都设成“有明显问题的代码”，因为这样只考验分析器能不能发现，不考验它会不会误判。

推荐把测试集分成两类：

• 正样本：包含真实缺陷的 Agent 代码片段，每条都有缺陷类型、缺陷位置、期望命中规则。
• 负样本：功能上等价、但已经修复或使用安全写法的代码，期望分析器不报警。

正样本负责评估召回率和假阴性率，负样本负责评估精确率。只有两边都有，指标才完整。

更接近真实场景的做法是再增加第三类：历史回归样本。把曾经漏报过的问题、曾经误报过的场景都固化到测试集里。这样每次规则更新，都可以通过跑一遍测试集知道有没有变好、有没有把原来的正确结果弄坏。

2.3 假阴性列表的格式和审计流

假阴性列表建议结构化存储，而不是写在 release notes 的散文段落里。每个条目至少包含这些字段：

• case_id：唯一标识，方便在测试集中关联。
• sample_path：对应哪个样本文件。
• rule_id：哪条规则应该命中但没命中。
• defect_type：缺陷类型，例如“路径穿越”“命令注入”。
• reason：当前为什么漏报，例如“缺少数据流分析，无法跟踪跨函数参数”。
• status：open / fixed / accepted_risk。
• created_at、updated_at：时间信息，方便审计。

格式可以用 JSON 或 YAML。YAML 看起来更接近人工维护，JSON 更容易被工具读取。Lucin 项目公开假阴性列表的内核就是这种审计流：规则更新后重跑测试集，重新生成列表，逐条确认哪些新增、哪些关闭、哪些仍然接受风险。列表不是一次性的，而是持续产物。

3. 从零搭建一个最小可复现的 Agent 静态分析评估案例

3.1 环境准备

这里用 Python 从零实现一个最小静态分析规则和评估器，目的是把“规则 + 测试集 + 假阴性报告”的最小闭环跑通。选 Python 是因为ast标准库足够处理语法树，不需要额外安装解析器。

学习环境建议：

这个组合在 Windows、macOS、Linux 上都能跑。如果你要分析的是 Java、TypeScript 或其他语言的 Agent 项目，思路一样，只需要把解析层换成对应语言的 AST 工具。下面示例的重点是评估闭环，不是语法解析本身。

生产环境还需要额外考虑几件事：分析任务的并发调度、仓库级增量扫描、与 CI 平台集成、报告基线存储、权限控制。这些放到第 5 和第 6 节讨论。

3.2 示例 Agent 代码结构

先构造两个样本。一个是有缺陷的 Agent 工具函数，另一个是修复后的安全版本。

sample_agent/unsafe_agent.py：

import subprocess from typing import Dict def handle_delete_request(request: Dict[str, str]) -> str: file_path = request.get("file_path", "") # 直接执行用户提供的路径，存在路径穿越和任意文件删除风险 result = subprocess.run( ["rm", "-rf", file_path], capture_output=True, text=True, check=False, ) return result.stdout

这个函数的问题在于：file_path直接来自外部 request，没有校验它是否存在于允许删除的目录，也没有校验路径是否包含..或绝对路径。规则应该把subprocess.run的参数来源识别出来。

sample_agent/safe_agent.py：

import os import subprocess from typing import Dict ALLOWED_BASE_DIR = "/srv/agent_data" def _safe_path(relative_path: str) -> str: target = os.path.abspath(os.path.join(ALLOWED_BASE_DIR, relative_path)) if os.path.commonpath([target, ALLOWED_BASE_DIR]) != ALLOWED_BASE_DIR: raise ValueError("invalid path") return target def handle_delete_request_safe(request: Dict[str, str]) -> str: relative_path = request.get("file_path", "") file_path = _safe_path(relative_path) if not os.path.exists(file_path): return "file not found" result = subprocess.run( ["rm", "-rf", file_path], capture_output=True, text=True, check=False, ) return result.stdout

安全版本增加了_safe_path白名单校验。即使到达subprocess.run，路径也已经被限制在允许目录内。这个样本是负样本，期望规则不报警。

这里要注意一点：安全的代码不是绝对不能调用危险函数，而是调用之前有足够强的边界校验。静态分析规则如果只是看到subprocess.run就报警，就会把安全版本也标记成缺陷，产生误报。

3.3 编写静态分析规则：用 AST 检查工具函数中的危险调用

现在写一条最小规则：检查函数体内是否调用subprocess.run，并检查调用参数中是否有变量来源于函数入参，同时没有经过白名单校验。

为了保持示例简短，这里用一种相对保守的策略：函数体内如果出现调用subprocess.run且该函数参数直接出现在调用处附近的变量名中，就报警。这个策略在真实场景里过于粗糙，但它足以演示 AST 如何工作，也足以让后面出现一个假阴性样本。

rules/subprocess_rule.py：

import ast from typing import List, Tuple class SubprocessRule: rule_id = "agent-tool-subprocess-001" danger_funcs = {"subprocess.run", "subprocess.call", "os.system"} def check_file(self, code: str) -> List[Tuple[int, str]]: findings = [] tree = ast.parse(code) for node in ast.walk(tree): if not isinstance(node, ast.Call): continue func_name = self._full_func_name(node.func) if func_name not in self.danger_funcs: continue arg_names = self._collect_arg_names(node) # 如果危险调用的参数里包含函数入参变量，则报告 func_def = self._enclosing_function(node) if func_def is None: continue params = {arg.arg for arg in func_def.args.args} if params & arg_names: findings.append((node.lineno, f"危险调用 {func_name} 的输入可能来自未校验参数")) return findings def _full_func_name(self, node: ast.AST) -> str: if isinstance(node, ast.Attribute): parts = [node.attr] current = node.value while isinstance(current, ast.Attribute): parts.append(current.attr) current = current.value if isinstance(current, ast.Name): parts.append(current.id) return ".".join(reversed(parts)) if isinstance(node, ast.Name): return node.id return "" def _collect_arg_names(self, node: ast.Call) -> set: names = set() for arg in node.args: if isinstance(arg, ast.Name): names.add(arg.id) for kw in node.keywords: if isinstance(kw.value, ast.Name): names.add(kw.value.id) return names def _enclosing_function(self, node: ast.AST): for parent in ast.walk(node): pass # 简化实现：向上查找第一个 FunctionDef current = node while hasattr(current, "parent"): current = current.parent return self._find_function_def(node) def _find_function_def(self, node: ast.AST): # 为示例简单处理，实际项目需要维护 parent 引用 return None

上面示例里_find_function_def没有真正实现，因为标准库 ast 默认不维护 parent 引用。为了让规则可用，需要先给 AST 节点补充 parent 关系。下面给出可运行的合并版本。

analysis/mini_analyzer.py：

import ast from dataclasses import dataclass @dataclass class Finding: rule_id: str line: int message: str class ParentCollector(ast.NodeVisitor): def __init__(self): self.parent_map = {} def visit(self, node): for child in ast.iter_child_nodes(node): self.parent_map[child] = node self.visit(child) def build_parent_map(tree): collector = ParentCollector() collector.visit(tree) return collector.parent_map def enclosing_function(node, parent_map): current = node while current in parent_map: parent = parent_map[current] if isinstance(parent, ast.FunctionDef): return parent current = parent return None def check_subprocess_with_unchecked_params(code_text): tree = ast.parse(code_text) parent_map = build_parent_map(tree) findings = [] for node in ast.walk(tree): if not isinstance(node, ast.Call): continue func_name = "" if isinstance(node.func, ast.Attribute): func_name = node.func.attr if func_name not in {"run", "call"}: continue func_def = enclosing_function(node, parent_map) if func_def is None: continue params = {arg.arg for arg in func_def.args.args} call_arg_names = set() for arg in node.args: if isinstance(arg, ast.Name): call_arg_names.add(arg.id) for kw in node.keywords: if isinstance(kw.value, ast.Name): call_arg_names.add(kw.value.id) if params & call_arg_names: findings.append( Finding( rule_id="agent-tool-subprocess-001", line=node.lineno, message="subprocess 调用参数可能来自未校验的函数入参", ) ) return findings

这个简化规则存在一个明显问题：它只检查参数名是否直接等于函数入参名。安全样本里file_path经过_safe_path处理后传入，但变量名仍然叫file_path，所以规则会误报。这正是规则设计里常见的权衡。要降低误报，就需要识别参数是否经过校验函数。后面会说明如何改进。

3.4 编写测试集运行器和报告生成器

评估闭环需要比较规则输出和人工标注。人工标注放在golden.yaml里，格式如下：

version: 1 cases: unsafe_agent.py: expected: true defect: path traversal safe_agent.py: expected: false defect: none

然后把规则输出转成 case 级别的“是否报警”，再与 expected 对比，生成 TP、FP、FN、TN 和假阴性列表。

analyze_repo.py：

import argparse import ast import json import sys from pathlib import Path import yaml from analysis.mini_analyzer import check_subprocess_with_unchecked_params def analyze_file(file_path: Path): code_text = file_path.read_text(encoding="utf-8") findings = check_subprocess_with_unchecked_params(code_text) return findings def main(): parser = argparse.ArgumentParser() parser.add_argument("--code-dir", required=True) parser.add_argument("--golden", required=True) parser.add_argument("--output", required=True) args = parser.parse_args() with open(args.golden, encoding="utf-8") as fp: golden = yaml.safe_load(fp) tp = [] fp = [] tn = [] fn = [] for code_file in sorted(Path(args.code_dir).glob("*.py")): findings = analyze_file(code_file) actual = bool(findings) expected = golden["cases"][code_file.name]["expected"] if actual and expected: tp.append({"file": code_file.name, "findings": [f.__dict__ for f in findings]}) elif actual and not expected: fp.append({"file": code_file.name, "findings": [f.__dict__ for f in findings]}) elif not actual and not expected: tn.append({"file": code_file.name}) else: fn.append( { "file": code_file.name, "expected_defect": golden["cases"][code_file.name].get("defect"), } ) precision = len(tp) / (len(tp) + len(fp)) if tp or fp else 0 recall = len(tp) / (len(tp) + len(fn)) if tp or fn else 0 f1 = 2 * precision * recall / (precision + recall) if precision + recall else 0 fn_rate = len(fn) / (len(tp) + len(fn)) if tp or fn else 0 report = { "summary": { "true_positive": len(tp), "false_positive": len(fp), "true_negative": len(tn), "false_negative": len(fn), "precision": precision, "recall": recall, "f1": f1, "false_negative_rate": fn_rate, }, "tp": tp, "fp": fp, "tn": tn, "fn": fn, } with open(args.output, "w", encoding="utf-8") as fp: json.dump(report, fp, ensure_ascii=False, indent=2) print(f"分析完成，报告已生成：{args.output}") print(json.dumps(report["summary"], ensure_ascii=False, indent=2)) if fn: print("\n当前假阴性列表：") for case in fn: print(f"- {case['file']}: {case['expected_defect']}") if __name__ == "__main__": sys.exit(main())

这里引入pyyaml作为 YAML 解析依赖。如果不想安装额外依赖，也可以把 golden 文件改成 JSON。关键是结构化的标注文件必须存在，它是评估闭环的“标准答案”。

4. 运行验证和报告解读

4.1 运行结果预期

在项目根目录执行：

python analyze_repo.py \ --code-dir sample_agent \ --golden golden.yaml \ --output report.json

由于当前规则把安全样本也当成报警，预期输出会包含一个 False Positive：

{ "summary": { "true_positive": 1, "false_positive": 1, "true_negative": 0, "false_negative": 0, "precision": 0.5, "recall": 1.0, "f1": 0.6666666666666666, "false_negative_rate": 0.0 } }

这说明一个问题：召回率是 100%，但精确率只有 50%。规则把安全版本误判成了风险代码。在实际工程里，这种结果虽然不会漏掉风险，但会让开发者在大量误报中失去耐心。

接下来给测试集增加一个真正会漏报的样本unsafe_agent_indirect.py：

import subprocess from typing import Dict def handle_delete_request_indirect(request: Dict[str, str]) -> str: file_path = request.get("file_path", "") command = ["rm", "-rf", file_path] result = subprocess.run(command, capture_output=True, text=True) return result.stdout

这个样本同样有风险，但危险调用的参数是command，不是直接来自入参file_path的变量。当前规则只检查直接参数名，因此会漏掉。把它加入golden.yaml后，再跑一次：

python analyze_repo.py \ --code-dir sample_agent \ --golden golden.yaml \ --output report.json

结果会多出一个 False Negative，即假阴性。report.json的fn列表会包含：

{ "file": "unsafe_agent_indirect.py", "expected_defect": "command injection via path" }

假阴性率也会变成非零值。到这里，你已经把 Lucin 公布假阴性列表的核心机制跑通：不是隐藏漏报，而是把它明确输出，纳入审计。

4.2 指标解读要结合场景

一组数字不能说明所有问题。实际使用时要回答三个问题：

针对上面示例，要同时消除误报和漏报，需要升级规则：跟踪变量赋值关系，识别command是从file_path构造出来的；同时识别_safe_path这类校验函数对参数的净化。这已经不是 50 行代码能做的，需要引入数据流分析和校验函数模型，也就是真实静态分析工具的核心工作。

4.3 学习环境与生产环境的差异

本地跑通的最小案例只能说明思路。生产环境要做的事情更多：

从零开始搭这类系统，不建议一开始就把目标定成“全量复杂分析”。先跑通一个规则、一份标注、一个报告，再逐步增加规则和样本。Lucin 公开假阴性列表的意义也在这里：它能让你清楚看到每一步改进到底解决了哪些漏报，又新增了哪些新的盲区。

5. 常见问题与排查链路

5.1 修复了规则，假阴性列表为什么没有变化

现象：修改了mini_analyzer.py中的规则，重新运行后发现假阴性列表和上次一模一样。

排查顺序：

1. 确认命令是否重新执行，而不是读取旧的report.json。
2. 确认样本文件路径是否正确，glob("*.py")只扫描code-dir根目录，不递归子目录。
3. 确认 golden 标注文件里是否新增了对应样本。
4. 确认规则的过滤条件是否生效。例如func_name只取attr，对于import subprocess后直接写subprocess.run(...)的场景，node.func.attr是run，可以命中；但如果写的是run(...)，规则可能命不中。
5. 在规则里加临时打印，输出 AST 节点结构，确认新样本被遍历到了。

如果规则确实命中了新样本，但假阴性列表仍然存在，那么很可能是因为新样本同时被判定为“确实有缺陷，但规则没有命中”，也就是旧的规则更新只解决了部分路径，没有覆盖新增的调用模式。这时候要回到样本，逐个调用点分析。

表格整理排查链路：

5.2 结果里大量误报怎么办

现象：规则把大量安全代码标记为风险代码。这在静态分析工具落地时最常见，原因通常是检测条件太宽。

举例来说，只要看到subprocess.run就报警，等于没做分析。真实规则必须回答三个问题：

1. 参数是否来自不可信入口。
2. 参数路径上是否经过校验函数。
3. 校验函数是否能保证参数安全。

调整方向：

• 提高触发条件：只有危险函数参数与函数入参存在数据流关联时才报警。
• 引入校验函数知识库：把_safe_path、sanitize_input、escape_shell这类函数标记为净化节点。
• 用负样本测试集验证：每减少一次误报，都要确认召回率没有下降。

不要把误报率压到零作为目标。完全消灭误报的结果往往是规则过弱，真正的问题也发现不了。合理做法是设置阈值：关键规则允许少量误报，但必须保持在可解释、可快速关闭的范围内。

5.3 Agent 的动态行为无法被静态分析怎么办

现象：某些缺陷依赖 LLM 的运行时决策。例如模型在特定 prompt 下选择了危险工具，这在代码里根本看不到。

这不是静态分析的失败，而是评估手段错位。正确补充方式有两类：

• 运行时回放评估：记录模型接收到的输入、工具调用序列、返回结果，检查是否符合预期。
• 模拟工具失败：在评估环境中让某个工具返回异常，观察 Agent 是否进入错误分支。

静态分析负责可静态化的部分，运行时评估负责动态行为，两者合起来才是一个完整的 Agent 评测体系。Lucin 的假阴性列表如果出现在运行时评估中，也会非常有用：它可以让团队知道哪些交互序列没有被测试覆盖。

5.4 如何确认分析器没有“作弊”

给分析器做评估时，最隐蔽的问题是数据泄漏。如果测试集样本文件名、函数名、注释里都写着“unsafe”，规则直接匹配路径或名称就能“猜对”，这种结果没有实际价值。

防范方式：

• 测试集不要固定放在规则可以硬编码路径的位置。
• 尽量混淆文件名，让规则只能通过真实语法特征判断。
• 在测试集里加入与文件名提示相反的样本，例如safe_looking_unsafe.py。
• 每次更新测试集时，不要只把旧报告复制到新版本，重新人工复核。

可以在报告里增加一个字段记录规则命中依据，例如命中的 AST 行号和表达式，方便审计。

6. 从 Lucin 的发布方式里能学到的最佳实践

6.1 假阴性列表的发布格式建议

公开的假阴性列表要做到可读、可跟踪、可争议。建议采用如下结构：

schema_version: "1.0" analyzer_version: "0.3.2" generated_at: "2025-06-15T10:00:00Z" summary: total_cases: 128 false_negative_count: 7 false_negative_rate: 0.054 cases: - id: FN-2025-001 sample_path: "tests/fixtures/agent_tool_path_confusion.py" rule_id: "agent-tool-subprocess-001" defect_type: "path traversal" reason: "规则只追踪直接调用参数，未处理中间列表变量" status: "open" created_at: "2025-06-10" - id: FN-2025-002 sample_path: "tests/fixtures/agent_tool_after_sanitizer_missed.py" rule_id: "agent-tool-subprocess-002" defect_type: "command injection" reason: "校验函数知识库缺少对 os.path.commonpath 的识别" status: "fixed" fixed_version: "0.4.0" updated_at: "2025-06-14"

额外要说明两点：一是status: accepted_risk的条目必须写明为什么接受风险，例如“该路径只能在本地开发环境触发，生产环境没有对应工具注册”；二是列表要能支持 diff，每次发布时给出新增和关闭的条目，否则大家只会看到总数字，看不到改进过程。

6.2 把假阴性清单接进 CI 质量门禁

假阴性列表不能只躺在仓库里，它应该成为 CI 的输入。一个可行的发布流程是：

1. 代码提交触发全量静态分析。
2. 分析结果与基线假阴性列表对比。
3. 只有满足条件才允许合并：没有新增已命中的严重问题；新增假阴性需要单独审批；修复旧假阴性的记录自动更新。
4. 每次发布都导出false_negatives.yaml作为构建产物。

这样做的效果是：每一条已知漏报都有负责人和关闭条件，不会无限积累成一本没人看的册子。对一个静态分析工具来说，持续维护假阴性列表比临时提高一个检测率数字更能建立信任。

6.3 静态分析与 Agent Evals 结合扩展

Lucin 关注的是静态分析，但它的方法论可以迁移到更广的 Agent 评估体系中。推荐从以下几个方向扩展：

• 把假阴性样本转成 eval 回归用例：漏报的代码样本可以变成自动化的单测，验证规则修复后行为符合预期。
• 把工具定义也纳入评估：不只分析代码，还要分析工具 schema 是否泄露了过强能力，是否缺少参数约束。
• 把 prompt 模板纳入静态检查：检查变量是否被插值进系统提示词，可能存在格式串注入。
• 运行时 evals 与静态分析结果映射：把静态报告中的函数和运行时 trace 中的工具调用关联，形成“代码风险到线上行为”的闭环。

真正有意义的 Agent 评测不是单一工具能完成的。静态分析给出静态边界，行为测试给出动态结果，假阴性列表把两者之间尚未解决的空白清楚地标记出来。

6.4 给团队落地时的最小清单

如果你要在团队里引入类似 Lucin 的实践，可以先做这六件事：

1. 选择一个真实 Agent 项目，列出它的工具函数清单。
2. 编写三条最关心的静态规则，优先覆盖硬编码密钥、危险工具参数、未校验外部输入。
3. 整理 20 到 30 个正样本和负样本，先小规模验证指标。
4. 定义假阴性列表的 YAML 格式，把第一轮漏报全部登记。
5. 把分析器接入 CI，并设置“新增假阴性需要审批”的门禁。
6. 每两周重跑测试集，更新列表，把修复记录同步到团队周会。

这套做法不需要一开始就做得很重。最小闭环的价值在于：它能让你在看到第一份假阴性列表时，立刻知道自己的 Agent 安全分析处在什么水平，哪些问题是规则能守住的，哪些必须用运行时评测补上。