Sec Review Bot 简历与面试准备

1. 项目真实能力总结

这个项目可以定位成一个面向 GitHub 仓库的多阶段 AI Agent 安全审查系统。它不是单纯让一个大模型直接改代码，而是把安全审查拆成 discovery、triage、analysis、mitigation、verification、CVSS scoring、delivery planning / patch synthesis 等阶段，每个阶段都有明确输入输出和可落盘的结构化 artifact。

工程上，项目由 TypeScript GitHub 集成层和 Python 后端执行服务两部分组成。前者负责接收仓库事件、准备审查 workspace、触发审查任务，并把结果发布回 GitHub，包括评论和可提交的修复草稿；Python 侧负责多阶段 Agent 调度、工具/技能挂载、模型配置、文件系统边界、artifact 管理和本地/Temporal 执行。Temporal 链路已经跑通过，但在面试里建议被问到再讲，把它说成“长任务和 retry 的运行编排”即可。

论文侧的核心问题不是“多阶段一定比单 Agent 强很多”，而是：把安全审查拆成可检查、可比较、可交付的阶段，是否能让漏洞分析、修复和交付更可靠。实验结果显示，多阶段在 PatchEval 230 个 CVE 修复任务上比单 Agent 多修复 5 个严格通过样本，但代价是更高 token 和成本；仓库级案例里，Agent discovery + triage 对跨文件、业务逻辑、鉴权、token/session、配置暴露这类问题的覆盖率明显高于 CodeQL / Semgrep / ZAP。

2. 简历描述

Sec Review Bot：多阶段 AI Agent 代码安全审查与修复系统

硕士论文项目：Agentic AI Framework for Web Vulnerability Detection, Mitigation and Patching

Python / LangGraph / GitHub App

构建面向 GitHub 仓库的多阶段 AI Agent 安全审查与修复系统，支持全仓扫描、Issue 审计和 PR 审计，将安全审查拆成发现问题、确认漏洞并收集证据、生成补丁、独立复查、整理并合并交付内容等阶段。
设计可审计的多阶段 workflow，结合安全审查 Skills 与 CodeGraph MCP 辅助代码结构查询，保留各阶段分析结果、补丁和验证输出，并加入补丁导出约束处理换行不一致、声明变更与实际 diff 不一致、工作区污染等 Agent 工程问题。
实现记忆机制：从运行记录中获取并总结可复用经验，整理成类 Skills 的文档目录供 Agent 使用，并支持定期整理以减少碎片、去重和消解矛盾。
论文实验显示，Default multi-stage + DeepSeek V4 Pro 在 PatchEval 230 个 CVE 修复任务 strict oracle 下达到 78/230，接近 ClaudeCode + GPT-5 的 79/230，并在仓库级案例中覆盖更多传统扫描器难以发现的跨文件和业务逻辑类漏洞。

3. 面试问答文档

Q0：做这个项目的背景是什么？

我会从“安全问题不只是写 patch”这个点开始讲。

一个很简单的演进路线可以这样画：

传统扫描器
  -> 传统 APR
  -> 学习式 / 深度学习 APR
  -> 直接用 LLM 生成修复
  -> Coding Agent / Repair Agent
  -> 多阶段 Agent 安全审查系统

对应到问题边界，就是：

发现告警
  -> 生成补丁
  -> 基于历史数据学习补丁
  -> LLM 根据上下文写补丁
  -> Agent 读仓库、改代码、跑反馈
  -> discovery + triage + analysis + mitigation + verification + delivery

传统扫描器，比如 CodeQL、Semgrep、ZAP，很适合发现一些模式明确的问题，像 SQL 注入、命令注入、路径穿越、SSRF 这类。但它们大多停在 alert：告诉你这里可疑，却不一定能把根因、影响范围、怎么修、修完怎么验证、最后怎么交付给 reviewer 都串起来。尤其是 Web 应用里的鉴权、对象所有权、token/session、配置默认值这些问题，经常要跨路由、中间件、model、前端假设和配置一起看。

再往自动修复方向看，早期 APR 很多是 generate-and-validate，靠测试来筛 patch。问题是测试过了不等于语义真的对，安全修复里尤其危险，因为 patch 既要挡住攻击，也不能破坏正常行为。

后来有学习式 APR / 深度学习修复，比如从历史 bug-fix 数据里学修复模式。这一层的限制更像是：要构建数据集、依赖训练数据和预处理，通常还依赖比较准确的 fault localization，而且上下文经常是局部的。放到 Web 安全漏洞里就会吃亏，因为漏洞不一定在一个函数里，可能跨路由、中间件、模板、数据库 model、配置和权限逻辑。

再往前一步，直接用 LLM 生成 patch 确实降低了 fine-tuning 和专门数据集的门槛，给足上下文时也能写出看起来合理的修复。但直接 LLM 也有问题：会 hallucination，会过度自信，也可能生成一个看起来合理但连基本验证都过不了的 patch。所以 agentic system 的意义是让模型能读仓库、搜代码、改代码、跑命令，用工具和反馈减少这种盲修。

已有 AVR / repair agent 工作已经很接近这个方向，但边界还是不一样。比如 VulRepair 这类更偏 localized vulnerable function；PatchAgent 更 agentic，但论文里主要针对 C/C++ memory-safety 或局部漏洞实例。很多 coding agent 也默认有一个比较明确的 issue 或漏洞描述作为起点，重点是“从问题到 patch”。我这个项目想扩一下这个边界：不只是给定问题后修复，还包括仓库级 discovery、triage、analysis、mitigation、verification，最后把结果打包成 reviewer 能看的交付单元。

所以项目背景不是“为了用多 Agent 而多 Agent”，而是安全审查本身就有多个角色：发现线索、判断真假、确认修复边界、写补丁、独立验证、组织交付。把这些阶段拆开，目的是让过程更可检查，也让论文能分别评估：多阶段修复有没有帮助、Agent discovery 和传统扫描器覆盖有什么差异、生成的修复能不能变成人能 review 的交付物。

Q1：这个项目的亮点是什么？为什么说它有产品形态？

我觉得背景讲完之后，很自然就会来到亮点，因为这个项目不是只验证一个算法点，而是把“安全审查这件事”做成了一个接近产品的闭环。

从使用者视角看，它不是一个离线脚本，也不是只输出一段模型回答。它可以接入 GitHub 仓库事件，把仓库内容准备成审查 workspace，后台跑多阶段 Agent，最后把审查结论、证据、补丁和验证意见组织成 reviewer 能看的结果，甚至生成可提交的修复草稿。也就是说，它覆盖的是“发现问题之后，人怎么理解、怎么修、怎么 review”这整段流程。

从 Agent 设计看，它也不是一个 Agent 从头想到尾。系统把 discovery、triage、analysis、mitigation、verification、delivery 拆开，每一步都有自己的责任和产物。这样好处是过程可检查：你能知道一个漏洞是哪里被发现的，为什么被保留，Analyzer 的证据是什么，Mitigator 改了什么，Verifier 还担心什么。

从工程实现看，它不是只把模型 API 包一层。项目里做了 GitHub 集成、后端执行服务、Docker sandbox、Temporal worker、artifact 落盘、patch 导出约束、GitHub 发布和评测适配。尤其是 patch 这块，我做了执行与补丁导出的 guardrails，比如 newline-tolerant edit、declaredChangedFiles 双向约束和 fresh-baseline git apply --check，这些都是 Agent 真正改仓库时会遇到的工程问题。

所以我会把它定位成“研究导向，但产品形态很完整的 Agent 安全审查系统”。论文上，它能评估多阶段 workflow 到底有没有帮助；工程上，它也跑通了从仓库触发、Agent 审查、生成补丁到交付给 reviewer 的完整链路。

Q2：这个项目一句话是做什么的？

我会把它概括成一个多阶段 AI Agent 安全审查系统。它面向 GitHub 仓库，目标不是只让模型写一个 patch，而是把安全审查拆成发现、分诊、分析、修复、验证和交付几个阶段。每个阶段都会留下结构化结果，所以最后 reviewer 不只看到一段 diff，还能看到这个问题为什么被保留、证据是什么、补丁修了什么、验证阶段还担心什么。

Q3：为什么要做多阶段，不直接让一个 Agent 从头到尾修？

单 Agent 的优点是简单，成本也低一点。但安全修复里有几个角色其实很不一样：有人要判断问题是不是真的，有人要决定修复边界，有人要写 patch，还有人要挑刺看 patch 有没有漏。全部塞给一个 Agent，它可能一边生成结论，一边验证自己的结论，过程比较黑盒。

所以我把它拆成阶段。Analyzer 先判断这个问题到底真不真，如果是真的，就把证据收集到足够支撑一条漏洞叙事；Mitigator 更像执行者，沿着 analyzer 给出的结论和修复边界去写 patch；Verifier 则是单独拉出来挑刺的角色，它拿到的是有限输入，尽量不要被前面 analyzer 的结论带偏。实验里多阶段不是碾压单 Agent，PatchEval 上严格通过数是 78/230，对照单 Agent 是 73/230，提升不大但是真实存在。更重要的是，它会改变修复策略，而且中间过程能被检查。

Q4：论文的研究问题到底是什么？

口语化讲就是三个问题。

第一，多阶段 Agent 在已经给出漏洞描述的修复任务上，相比单 Agent 到底有没有帮助。

第二，如果不先给漏洞，而是让系统自己扫一个仓库，它和 CodeQL、Semgrep、ZAP 这类传统工具相比，能不能覆盖更多类型的问题。

第三，Agent 生成的东西能不能变成 reviewer 真正能看的交付物，而不是一堆散乱告警或者一大段没人敢合的 patch。

所以论文不是想证明“多 Agent 神奇地解决安全”，更像是在研究安全审查这个流程能不能被拆成更可控、更可审计的 Agent workflow。

Q5：核心技术路线是什么？

核心路线是 repository-grounded agent workflow。也就是 Agent 不只看题目描述，而是能进入真实仓库，读文件、搜索代码、运行必要检查、生成 patch，然后把结果保存成结构化 artifact。

Issue 和 PR 场景从 analysis 开始，因为输入已经给了一个具体对象。仓库扫描场景更完整，会先 discovery 扫文件找候选，再 triage 把候选过滤和合并成 case，然后进入 analysis、mitigation、verification、delivery。

这个设计的重点不是发明一个新模型，而是把模型、工具、仓库上下文、结构化输出和交付流程组织起来。

Q6：各个 Agent 阶段分别做什么？

Discovery 更像召回阶段，它按文件找可疑安全线索，不要求证明漏洞。

Triage 是把 discovery 的候选压缩成更少的 case，过滤弱信号，合并重复或相关线索。

Analysis 负责深挖一个 case。它第一步不是急着修，而是判断“这个描述的问题在代码里到底存不存在”。如果存在，它要把证据补齐，包括相关代码位置、触发路径、为什么现有保护不够、修复边界应该在哪里。

Mitigation 更像执行者。它不重新发明一套漏洞叙事，而是根据 analyzer 已经确认的结论和边界，在可写 workspace 里生成补丁。

Verification 是独立审查 patch。为了避免它被 analyzer 的判断牵着走，系统会限制它拿到的输入，让它主要站在 patch reviewer 的角度看：补丁有没有覆盖目标漏洞，有没有残留绕过路径，有没有引入回归风险。

Delivery 则是把多个已验证 case 组织成 reviewer 能看的交付单元，比如哪些应该合并到一个 PR，哪些应该分开。

Q7：为什么不让一个 Agent 拿全仓自由找漏洞？

这个问题可以直接回答：因为 repository discovery 这一阶段，我更希望它像传统扫描器一样，先稳定地“扫一遍”，而不是让 Agent 自由发挥。

现在的 discovery 基本形状是按文件遍历，让 Agent 看文件内容，产出候选安全线索。这个设计有点像 scanner：不要求它马上证明漏洞，也不要求它理解完整业务，只要求它尽量覆盖代码库，把可疑点先捞出来。这样做的好处是覆盖率和评估口径比较清楚：哪些文件扫过、哪些候选被发现、哪些后来被 triage 保留，都能追踪。

如果换成一个自由探索 Agent，哪怕给它 CodeGraph 之类的工具，让它知道项目里有哪些主要 route，也不代表它真的会系统性扫完整个仓库。它可能沿着自己觉得重要的路径查得很深，但漏掉一些不显眼的文件或边缘功能。最后结果会更依赖模型当次的探索策略，覆盖率反而不稳定。

所以 discovery 不是为了“聪明地一次性理解整个系统”，而是为了做高召回、可追踪的候选生成。后面再交给 triage 去压缩和去重，交给 analysis 去做真正跨文件、业务逻辑、修复边界的深分析。

面试里我会强调这个取舍：自由探索可能看起来更像“智能审计”，但不一定带来稳定覆盖；scanner-like 的 discovery 更笨一点，但它能保证仓库被系统性扫过，也更容易和 CodeQL、Semgrep、ZAP 这种传统扫描器做公平对比。

Q8：Triage 为什么要做两遍？

仓库扫描会产生很多候选。如果全部塞进一个 Agent prompt，容易超上下文，也容易分组不稳定。

所以第一遍按 batch 分开处理，先做粗粒度 keep、suppress、group。这样速度和稳定性更好。第二遍再做 refinement，专门看第一遍留下来的结果，处理跨 batch 的重复和合并问题。

这个设计不是为了复杂而复杂，而是为了处理“候选太多时，单次 Agent 分诊不可靠”的问题。

Q9：Verifier 为什么有用？它又有什么局限？

Verifier 的价值是独立视角。Mitigator 自己写 patch 后做 self-check，多少会有“我觉得我修好了”的偏差。Verifier 站在 patch reviewer 的角度，看补丁是不是只修了一个局部点，有没有绕过路径，是否破坏正常行为。这个角色单独分出来之后，系统也可以做 feedback loop：Verifier 挑出阻塞问题，Mitigator 再针对这个反馈改一轮。

但 Verifier 不是隐藏测试 oracle。它不知道 PatchEval 的 PoC 和单元测试到底检查什么，所以它的反馈有时能把失败 patch 改成成功，也可能把已经能过 benchmark 的 patch 改得更“语义完整”但反而不符合 benchmark。论文里 46 个触发 retry 的样本里，3 个从 fail 到 pass，1 个从 pass 到 fail，说明 feedback loop 有价值，但不能把它说成自动收敛保证。

Q10：为什么不用 Semgrep / CodeQL / ZAP 直接扫？

我不认为 Agent 应该替代它们。Semgrep、CodeQL、ZAP 的优势是便宜、稳定、规则明确，特别适合 SQL 注入、命令注入、路径穿越、XSS 这类有明显 sink 或模式的问题。

但它们通常停留在 alert。很多安全问题要理解路由、鉴权中间件、对象所有权、前后端假设、配置默认值，甚至多个文件组合起来才是漏洞。这个时候 Agent 的优势是能把线索组织成“安全 case”，再往后做分析、修复和验证。

实验里也能看到这个差异。三个仓库案例里，Agent workflow 的 answer-key recall 明显高于 CodeQL、Semgrep 和 ZAP，尤其是 access control、account-state、token/session、missing controls 这类传统扫描器不太擅长的问题。所以我会说是互补关系：扫描器给高信号局部线索，Agent 做仓库级语义审查和后续修复。

Q11：PatchEval 结果应该怎么讲？

我会讲得短一点：在 PatchEval 230 个 runtime-validated CVE 修复任务上，我们的 Default multi-stage + Deepseek V4 Pro 是 78/230。放在 leaderboard 参考里，它低于 OpenHands + GPT-5 的 83/230，接近 ClaudeCode + GPT-5 的 79/230，高于 SWE-agent + GPT-5 的 76/230。这个位置说明结果接近第一梯队，但我不会说它“超过所有系统”，因为模型和 agent 框架都不一样。

第二层再讲自己的 ablation，用来归因 workflow 设计。在同一个 Deepseek V4 Pro 模型下，Default 是 78/230，Single-Agent 是 73/230；No-Verifier 是 76/230，Deep-Self-Check 是 73/230。这个结果说明多阶段有帮助，但不是巨大提升。它的价值还体现在 case-level difference：Default 和 Single-Agent 有不同的成功集合，说明多阶段不是简单“多跑几步”，而是真的会改变漏洞边界理解和修复策略。

同时我会主动说成本更高。Default 的 token 和价格都高于 Single-Agent，所以这是一个效果、可审计性和成本之间的 tradeoff。

Q12：Repository benchmark 结果怎么讲？

仓库级评测更贴近“安全审查系统”的目标。我们用了 Book Shop、Raddit、WorldPress 三个有 answer key 的 web app。最好的 Agent run 在 Book Shop 覆盖 19/19，Raddit 覆盖 21/22，WorldPress 覆盖 20/21。

对比传统扫描器，CodeQL、Semgrep、ZAP 的覆盖率低很多，但它们的发现通常更稳定、更便宜。所以结论不是“扫描器没用”，而是 Agent 能补上跨文件和业务逻辑类漏洞，并且能继续往修复和交付走。

如果只准备一个仓库级例子，我会讲 Raddit。Raddit 有 22 个 answer-key 漏洞，最好的一次 Agent run 覆盖 21/22；Semgrep 是 8/22，CodeQL 是 7/22，ZAP 是 3/22。扫描器主要抓到了 SQL 注入、命令注入、SSRF、部分 XSS 这类局部 sink；Agent 多覆盖的是 IDOR、JWT 配置、用户 role 提权、CSRF、敏感字段暴露这类需要跨路由、中间件、handler、model 和配置一起看的问题。

Q13：这个系统里最像 AI Agent 开发的难点是什么？

我觉得难点不是“调一个模型接口”，而是怎么让 Agent 在复杂仓库里稳定地产生可消费的中间结果。

比如 analyzer 输出不能只是“我觉得有漏洞”，它要留下判断、假设、证据、代码位置和修复边界。Mitigator 不能随便改，要能说清楚改了哪些文件、为什么这么改、还有什么残留风险。Verifier 不能只说“看起来不错”，要明确补丁覆盖了什么、哪里还有缺口、有没有回归风险。只有这些阶段记录稳定，后面的 workflow 才能继续跑。

另一个难点是上下文控制。安全审查需要足够上下文，但上下文太多会让模型迷路。所以系统用阶段边界、artifact、技能材料、sandbox workspace 和必要的摘要来控制上下文。

Q14：Temporal 在项目里是什么角色？

如果面试官不问，我不会主动展开 Temporal。被问到时，我会说它在项目里主要解决长任务和 retry 的问题：安全审查不是一次短 HTTP 请求能完成的，所以 GitHub 集成层把任务交给后端执行服务，再通过 Temporal worker 执行。

我会讲到 workflow、activity、worker、timeout、retry 和状态查询这一层。再往 Temporal 内部实现追，我会明确说它不是论文核心贡献；项目重点还是 Agent workflow 的阶段拆分、证据流和评测。

Q15：项目里用了哪些 MCP 和 skills？

我会先区分这两个东西。Skills 更像本地参考材料，MCP 更像可调用工具接口。

Skills 这边，项目里有一些内置 skills，比如 web-security、cwe、scanner-finding-triage、language-framework-security、ci-security。它们不是一个单独的安全扫描器，而是给 Agent 提供按需阅读的参考材料，比如常见 Web 漏洞怎么判断、CWE 怎么映射、scanner finding 怎么 triage、不同语言和框架有哪些安全注意点。不同阶段会声明自己需要哪些 skills，runner 再把允许的 skill view 挂给这个 agent。

MCP 这边要保守讲。项目里主要考虑的是 CodeGraph MCP，用来辅助符号、调用关系、跨文件跳转这类代码结构查询。它是可选能力，不是默认所有阶段都靠它。CodeGraph 能帮 Agent 更快找到调用关系，但它不能替代 discovery 的全量扫描，也不能自动证明漏洞。

还有一个容易被问到的是 OSV MCP。这个项目试过 OSV MCP，但后来移除了。原因不是协议接不起来，而是它对当前任务帮助有限：issue 里通常已经有 CVE 描述，OSV 返回的 affected range、fixed commit 之类信息容易把 Agent 带去追版本和 git history，反而不如直接看当前仓库代码证据。所以我不会把 OSV 说成系统默认能力。

总结起来，我会说：skills 提供安全知识和分类参考，MCP 提供可选代码结构工具；真正的核心还是阶段化 workflow 和 repository-grounded evidence，不是靠某个外部工具一键扫出来。

Q16：这些执行和补丁约束能叫 harness 吗？

这里我会把 harness 理解成 agent execution / patch harness：也就是让 Agent 在可控环境里读代码、改代码、运行少量命令、最后产出可交付 patch 的工程外壳。这个项目里确实有意识做了这一层。

第一块是 Docker sandbox。Agent 需要能读代码、改代码，有时还要跑命令验证，但不能让它直接在宿主机上随便执行。所以我把它放进受控 workspace 里，限制读写路径、命令执行、超时和输出大小。

第二块是文件编辑可靠性，尤其是 LF / CRLF。这个问题实际很烦，Claude Code、Codex 这类 coding agent 都容易遇到：模型看起来给了正确的 old string，但真实文件是 CRLF 或混合换行，结果连续 edit 失败；更糟的是 agent 往往不知道自己错在换行上，会开始怀疑路径、内容、上下文，越修越偏。项目里的 local 和 Docker filesystem backend 都做了 newline-tolerant edit：会推断文件原始换行，生成 LF / CRLF 的匹配变体，写回时也尽量保持一致。

第三块是 patch 导出。这里不能只相信 Agent，也不能只相信工作区 diff。

如果只相信 Agent 的声明，它可能说自己改了某个文件，但实际 workspace 里根本没有对应改动，最后交付一个空 patch 或错 patch。如果只相信整个 workspace diff，又可能把意外修改带出去，比如 agent 运行安装命令、生成 lockfile、缓存文件、临时测试文件，整个 diff 直接超出修复范围。

所以我做了一个双向约束：Agent 必须声明 declaredChangedFiles；系统再用 git 观察真实 workspace diff。声明了但没有真实改动，会打回；真实改了但没声明，不会进入可发布 patch。最后只按声明路径导出 scoped patch，并在 fresh baseline 上跑 git apply --check，确认 patch 能干净应用。

所以面试里我会说：这个项目里我确实做了 agent execution / patch harness，包括 Docker 隔离执行、newline-tolerant 文件编辑、workspace patch 导出、declaredChangedFiles 双向约束和 fresh-baseline patch apply check。它解决的不是“模型会不会想对”，而是 Agent 真的改仓库时，怎么让修改可控、可导出、可交付。

Q17：这个项目是 demo 还是完整系统？

我会说它是研究导向但链路完整的可运行系统，不是只有 mock 的 demo。系统能从 GitHub 触发审查，经过后端执行服务、Temporal worker 和 Agent workflow，再把结果发布回 GitHub；同时也有 Docker Compose、本地 CLI、HTTP 接口、评测脚本和测试。

但它还不是成熟商业产品。模型效果、成本、运行时稳定性、真实部署治理、人类 review 体验都还有很多工程问题。所以我会把它定位成“论文验证过的可运行 Agent 系统”，而不是生产级安全平台。

Q18：你怎么处理 Agent 的安全边界？

主要有两层。

第一是输入和 workspace 边界。GitHub App 物化输入 bundle，清理 git remote、fetch metadata 和凭据相关信息，再把 workspace snapshot 给 runner。

第二是 Agent 执行边界。Python 侧有 Docker sandbox 和 local backend。Docker backend 做了路径绑定、读写前缀检查、命令超时、输出截断、可写目录控制等。Agent 能读写的东西尽量被限制在当前 workspace 和 artifact 范围内。

不过我不会说它是完美隔离。比如本地 Compose 为了让 worker 启动 Docker sandbox，会挂 Docker socket，这在本地实验里常见，但生产化需要更严格的隔离策略。

Q19：为什么要做 CVSS？

CVSS 不是用来证明漏洞存在的。它是在 analyzer 已经确认或认为可评分后，把漏洞事实映射到一个标准化严重性表达。

它的作用是帮助 reviewer 排优先级。比如一个 delivery 里有哪些高危问题、哪些中危问题，可以用 CVSS v4 score 和 rationale 辅助判断。但它不能替代业务风险评估，因为真实影响还和部署环境、资产价值、攻击者能力有关。

Q20：你对安全知识不算特别深，面试怎么说？

可以诚实但不要自毁。可以说：这个项目让我系统性接触了 web 安全漏洞类型，我现在能从代码审查角度理解 SQLi、XSS、SSRF、IDOR、路径穿越、JWT、CSRF 等常见问题，也知道 CWE 和 CVSS 在分类与报告里的作用。我的强项是把这些安全判断组织成 Agent workflow 和评测系统；对于更深的漏洞利用细节，我会结合具体代码和资料继续补。

这比说“我安全非常强”更可信，也更符合 AI Agent 开发岗。

Q21：这个项目当前最大的不足是什么？

我会讲三个。

第一，效果依赖模型能力。模型换了，discovery 召回、triage 合并、patch 质量和 delivery 组织都会变。

第二，成本不低。多阶段带来可审计性和一些成功率收益，但 token 和时间成本也上去了。

第三，自动验证不等于真实安全保证。Verifier 和测试都只能提供证据，最后是否可合并、是否符合业务语义，还是需要人类 review。

Q22：后续优化方向是什么？

我会优先做三件事。

第一，把传统扫描器作为输入信号接进 discovery / triage，而不是只做离线对比。

第二，优化 triage 和 delivery，减少重复 case 和碎片化 PR，因为这直接影响人类 review 成本。

第三，增强评测。现在 PatchEval 和三个仓库案例已经能说明问题，但还需要更多仓库、更多漏洞类型和更稳定的 repair benchmark，尤其是要避免 benchmark 只接受某一种 patch 形状。

Q23：如果面试官让你举一个具体 PatchEval case，讲哪个？

我建议讲 CVE-2021-21360。这个漏洞可以类比成：后台有个“导出站点配置备份”的功能，导出来的东西本来只该管理员看，但生成后权限没设好，匿名用户也能通过 URL 看到。所以它是信息泄露，CWE 是 CWE-200。

具体到代码里，GenericSetup 会生成 log / report，也会生成 snapshot。log 文件创建后有明确的 View 权限限制，只给 Manager 和 Owner 看；但 snapshot 这边会先建 folder，再往里面写 data file，这两层没有同样收紧权限。单 Agent 容易只看到 folder 创建逻辑，于是只修 folder；多阶段 analyzer 会先把修复边界讲清楚：真正保存导出内容的 file 也要保护。这个例子能说明，多阶段的价值不是形式上多几个 Agent，而是先把安全问题边界说完整，再让修复 Agent 执行。

Q24：如果面试官追问仓库级案例，讲哪个？

我会讲 Raddit。它是 Go + React 的 Web 应用，有 22 个 answer-key 漏洞。最好的一次 Agent run 在 discovery/triage 层覆盖 21/22；对比下 Semgrep 是 8/22，CodeQL 是 7/22，ZAP 是 3/22。

这个例子好讲，因为扫描器并不是完全没用。它们抓到了 SQL 注入、命令注入、SSRF、部分 XSS 这类有明显危险点的问题。但 Raddit 里还有 IDOR 删除帖子、用户可控 role、JWT alg:none、弱 secret、CSRF、password hash 暴露、硬编码 admin 凭据等问题，这些通常要把路由、中间件、handler、model、配置和前端渲染连起来看。

我也会主动讲不足：Agent 漏掉了登录 rate limiting。这个是典型“缺失型控制”，不是某一行危险 API，所以比 SQL 拼接、shell command 这种局部 sink 更难发现。

Q25：Temporal 被追问时怎么防守？

我会先把它讲成工程编排，不把它包装成核心创新。这个项目里 GitHub 侧收到请求后，不在 webhook 进程里直接跑长任务，而是把任务交给后端执行服务；后端再通过 Temporal worker 执行 workflow。Temporal 负责长任务状态、activity 调度、超时、失败记录和 retry。

如果追到细节，我会讲到 workflow 是长流程，activity 是具体可重试的执行单元，worker 从 task queue 取任务执行。再往很底层的 Temporal 内部实现，比如 history service、matching service 这类，我不会硬装熟。我会说这块在项目里主要是工程运行载体，我更熟的是 Agent 阶段如何组织、artifact 如何传递、以及 GitHub 集成层到后端执行服务的边界。

4. 风险提醒：面试时不要说得太满

不要说“生产级系统”，说“研究导向但链路完整的可运行系统”更稳。
不要说“Agent 替代 CodeQL/Semgrep/ZAP”，说“互补，并且在案例中覆盖了更多跨文件和业务逻辑类问题”。
不要说“自动修复一定正确”，说“生成可审查 patch，并通过 verification 和 artifact 帮助人类判断”。
不要把 Temporal 说成核心创新，它是工程编排，不是论文贡献重点。
不要把 CodeGraph MCP、CWE-RAG、OSV MCP 都说成默认能力；CodeGraph 是可选，CWE skill 是内置参考，OSV 已移除。
不要把 PatchEval 78/230 说成“漏洞修复率 34%”，要说“在 PatchEval runtime subset 的 strict oracle 下 78/230 通过”。
不要说“超过 PatchEval leaderboard 第一名”。更稳的是“接近 leaderboard 第一梯队：低于 OpenHands + GPT-5 的 83/230，接近 ClaudeCode + GPT-5 的 79/230，高于 SWE-agent + GPT-5 的 76/230；同模型 ablation 再说明 workflow 贡献”。
不要说自己安全很强。更好的说法是“我能从代码审查角度解释常见 web 漏洞，强项是 Agent workflow 和评测，把安全专家判断流程工程化”。

5. 自检

简历描述没有把实验原型写成生产平台。
PatchEval 数字只作为 benchmark 结果，不泛化成真实世界修复率。
传统扫描器对比只说案例覆盖率，不说全面替代。
Temporal、CodeGraph、CVSS、CWE 都解释了作用和边界。
问答尽量用候选人口吻，没有写成论文摘要。