毕业设计调研:基于 Agent 的智能代码审查与重构建议系统

课题见毕业设计;harness 侧背景见 Pi 与 DeepSeek Harness 的扩展架构,评测方法见 Agent Harness 评测。调研时间:2026-10-17。标注 ✅ = 直接抓取一手来源(官方文档 / GitHub API / raw 源码 / arXiv abs 页)并按原文核对;📄 = 来自本次调研的详细报告(带 URL,未逐条回原文);⚠ = 仅经代理/二手渠道取回,引用前必须再核。所有 star 数为当日精确值,半年后打印前需复查。

0. 一句话结论

选题成立,而且差异化位置已经被生态自己腾出来了:

现有 pi / dsh 的代码评审扩展全部是”交互式、会话内”的(supi、pi-review 面板、pi-review-loop…),没有任何一个做成”服务端 webhook 形态、评审结果贴回 PR/SARIF”。而独立开源评审器(pr-agent 13.4k★、alibaba/open-code-review 47.5k★、kodus、reviewdog)又都不是 harness 扩展。→ 论文的定位:“把自动代码评审重构成 agent harness 扩展,并带上服务端 webhook 模式” 正好落在两边交叉的空档。
技术路线有工业+学术双重背书:“确定性管线夹住 LLM”(Meta RADAR ✅ 2605.30208、阿里 OCR ✅)是被验证过的形态;RepBench ✅(AST+PDG 83.2% vs 源码 53.5%)+ “LLM 自己做程序分析很差” ✅(2505.12118)构成”AST 只是原料、LLM 只能在结构化表示之上做仲裁”的完整论证链——这直接支撑课题技术栈里”AST 分析 + 静态工具 + LLM”的选型,比厂商宣称硬得多。
提升空间有公开量化锚点,不用自己造 benchmark:c-CRAB ✅ 现有评审 agent 合计仅解决 ~40%;SWE-PRBench ✅ 只检出人标问题的 15–31%。评测集(MCR-Bench / SWR-Bench / SWE-PRBench / MetaLint / SecCodeBench-V2)全部现成可跑。

1. 生态图谱:pi / dsh 扩展这条路线的现状

✅ pi(earendil-works/pi,本地 HEAD 4954d76)的 headless 与扩展面已核实:

pi --print、git diff | pi --print "Review this change"、--mode json|rpc、--tools read,grep,find,ls(只读白名单)——服务端模式的官方原语齐全(docs/cli.md:25-27, 45-48, 114)。
Node SDK createAgentSession() + SessionManager.inMemory() → 可以起无头会话;pi.on('tool_call') 拦截、registerTool/Command/Provider/McpServer。
examples/extensions 里已有 git-checkpoint、subagent、plan-mode、sandbox 等范式可抄。

现有扩展	形态	与毕设的差异
✅ `mrclrchtr/supi`(~100★)	pi 扩展:冻结 Git 工作区里跑并行、只读评审;`review_run`/`review_output`/`review_audit`;LSP+AST 代码智能(`supi-code-intelligence`,模型可调用)	交互式/会话内,无服务端 webhook,无 SARIF/forge 贴回
✅ `ZephyrDeng/pi-review`	评审面板(correctness/security/testing 多角色并行,报 model/token/cost),`PI_REVIEW_META_JSON`,exit code 0/1/3/4	同上;exit code 设计可直接借鉴给 CI gate
✅ `earendil-works/pi-review-loop`(167★)	评审-修复循环	会话内循环,非 PR 事件驱动
✅ dsh 侧(deepseek-ai/deepseek-harness + awesome-dsh-plugin 122 条目)	profile→bundle→patch YAML 树,`ctx.tools/agentLoop/skills/fs/process` 缝,`ctx.effect` 可逆	alpha 期破坏性变更频繁——不建议当毕设主线;可作”同构方案在另一 harness 上的可移植性”讨论一节
✅ pi2dsh(cities 的桥)	把 pi 扩展搬到 dsh	说明”扩展=可搬运的能力单元”这一论点成立

gap 陈述(论文开题直接可用):“目前没有以 agent harness 扩展形式实现、由 forge webhook 驱动、产出结构化报告(review API + SARIF)的自动代码评审系统;现有 harness 扩展均为交互式,现有独立评审器均与 harness 解耦。” 注意措辞纪律:别说”服务端 webhook 评审是空白”——独立工具早做了;空白是”作为 harness 扩展交付的服务端评审”。

2. 独立开源评审器:四个可对比/可复用的基线

✅ 全部经 GitHub API + raw 源码核实(2026-10-17):

项目	体量/许可	关键事实(核对过的)
`The-PR-Agent/pr-agent`	13,424★ MIT,v0.48.0,push 10-16	org 已改名(qodo-ai/Codium-ai 均 301 重定向)。全仓 0 个 tree_sitter/semgrep/SARIF/ast-grep 命中——确定性体现在流程工程而非语法分析。不用 `response_format`(0 hits):prompt 要求”合法 YAML + `\|` block scalar”,配 ~250 行防御解析(`load_yaml`/`try_fix_yaml`,algo/utils.py:987-1003)。`/reflect` 独立命令已消失,反思强制内嵌于 /improve(0–10 打分+反膨胀规则,pr_code_suggestions.py:~1071)。✅ 有 finding 生命周期:`review_finding_state.py` 以 HTML comment 状态块跨 push 持久 ACTIVE/RESOLVED——harness 扩展都没有这个
`alibaba/open-code-review`	47,524★ Apache-2.0,Go	体量最大的 AI 评审器;确定性前置 + LLM 中段 + 确定性收尾的混合形态(其”deterministic”指流程,不是跑 linter)。有 SARIF 发射器(`cmd/opencodereview/sarif.go`,`ocrFinding/v1` 指纹)但不贴回 forge——贴回靠 `action.yml` + `scripts/github-actions/post-review-comments.js`
`reviewdog/reviewdog`	9,671★ MIT	报告层的事实标准:14 种 reporter;Diagnostic 格式(RDF/rdjson/rdjsonl/SARIF);`-filter-mode=added` 为默认(CI Action 的 input 名才是下划线 `filter_mode`);FNV-64a 指纹去重。→ 毕设复用它做贴回,不要重写
`kodustech/kodus-ai`	~1.5k★,AGPL-3.0+商业 EE(open-core)	开源 CodeRabbit 替代,18 阶段管线,GitHub/GitLab/Bitbucket/Azure DevOps/Forgejo;SARIF 只读(parseAnalyzerSarif),不写 SARIF

周边小参考:✅ hyhmrright/brooks-lint(1,530★,SARIF 2.1.0 + CI gates,“Symptom→Source→Consequence→Remedy” 四段结构);✅ mavam/pi-prs(pi 扩展,持有 GitHub PR 状态——与 gap 最接近的东西,仍是会话内)。

结论(工程决策):报告/贴回层 = reviewdog(+SARIF upload),别自己写 GitHub API 胶水;LLM 评审层 = pi extension(差异化所在);静态层 = 下一节工具栈。

3. 静态分析 / AST 工具链:核实过的一学期规模装配

✅ 全部命令 flag 从 —help/官网/README 实录核对(版本会漂,答辩附录务必钉版本):

substrate   tree-sitter(27.2k★ MIT;CST≠AST:含全部 token 节点、错误恢复可解析半成品——
            正好用于"LLM 提议的编辑未必合法"场景)
规则层      ast-grep(16.3k★ MIT)`run` vs `scan`,`scan --format=sarif` 直出标准格式;
            规则配置 sgconfig 用 camelCase;官方 ast-grep-mcp(479★)已把 AST 搜索暴露给 agent
            Semgrep CE(17.1k★ LGPL)安全/正确性规则,--sarif;⚠ 跨文件 taint 在专有 Pro 二进制里
每语言补    Ruff --output-format sarif / ESLint+@microsoft/eslint-formatter-sarif / PMD / Bandit(按目标语言取)
指标层      lizard(无 --json,用 Python 库 API;Sonar 认知复杂度实现)+ jscpd(kucherenko/jscpd,v5 Rust 引擎)
SCA         OSV-Scanner v2:`scan source -r --format sarif`;pip-audit
交换格式    SARIF 只在边界用;内部统一自定义 Finding 记录
CodeQL      只当对照组:queries 仓 MIT,engine CLI 单独条款——"perform academic research" 对开源合法,
            私有仓 CI 不行;输出 `--format=sarifv2.1.0`(没有 sarif-2.1.0 这种写法)
跳过        SonarQube(server+DB+scanner 不是一个学期)、Semgrep Pro、Trivy/Grype、jQAssistant

三个设计级要点:

Semgrep CE 的边界 = 论文卖点:社区引擎只做函数内/单文件,跨文件 taint 属 Pro。诚实框定为”Agent 在 OSS 引擎做不了的过程间推理层做仲裁”,这是可辩护的贡献,不是缺陷。
severity 映射是脏活,可直接写成”统一 Finding 模型”小节:词表互不保序——Semgrep ERROR/WARNING/INFO、ast-grep 默认 hint、PMD priority 1 才是最严重(反的)、Bandit 是 severity×confidence 二维要塌成一维、CodeQL 三档 @problem.severity + 0–10 @security-severity,而 SARIF level 只有 none|note|warning|error——recommendation/hint 映射不当就静默消失于 GitHub 的 High/Medium 分诊视图。内部 Finding:tool/ruleId/severity_raw/file/line/endLine/message/cwe/autofix? + 双射映射表 + properties 透传。
许可与坑:真规则库是 semgrep/semgrep-rules(Semgrep Rules License,非 LGPL;semgrep-community org 不存在),打包进毕设要单独声明;pyan3 是 GPL-2.0(--text,README 原话就是给 AI agent 用);madge 作者是 pahen、flag 是 --circular(没有 --detectCircular);sarif-tools 调用名就叫 sarif,子命令 codeclimate;gitleaks 的 detect 已废弃→git/dir/stdin;trufflehog 用 --results=verified,unknown;没有 canonical 的 tree-sitter call graph,要自己搭;snakeviz 是 runtime profiler 不是静态调用图。

4. 平台集成:GitHub Actions 有一个必须改设计的日期

✅ docs.github.com 全 200 核实(2026 文档大重组,老路径 301 到新结构):

⚠ GitHub 默认策略封锁公开仓库的 pull_request_target,2026-11-02 起强制执行(现为 evaluate 模式;私有/内部仓不受影响)。→ 毕设主路径必须设计成官方两段式:pull_request(不可信、只读 token、无 secret;clone+diff+跑 pi 评审)upload-artifact → workflow_run(可信、可写;下载 artifact 贴 review / 传 SARIF)。文档自带完整示例 YAML;跨 run 下载 artifact 要 run-id: ${{ github.event.workflow_run.id }} + github-token + actions: read。答辩演示放自己的私有仓最省事。
细节约束:workflow_run 的工作流文件必须在默认分支、workflows: 过滤匹配 name 不是文件名;链式最多 3 层;fork PR 的 pull_request payload 为空;check runs 建在 PR commit 上要 head_sha: github.event.pull_request.head.sha;Checks API 对 fork push 的 pull_requests 数组为空;annotations 50/请求、1000 同名 check run 上限;permissions: code-quality 已存在(键名清单核实)。
SARIF 上传:POST code-scanning/sarifs,body 只有 commit_sha/ref/sarif/checkout_uri/started_at/tool_name/validate——旧博客的 start_sha/validate-urls/tool-names 已不存在;gzip+base64;10MB gzip 上限、单 run 25k results 只留按 severity 排序的前 5000;202 异步要轮询 sarif_id;github/codeql-action/upload-sarif@v4(现值 v4),输入名下划线 sarif_file,多文件必须给 category;ref/sha 对 fork PR 一律忽略→必须可信 workflow 传。PR 内显示条件(官方原文):告警标识的全部行都在 diff 内、且属于新增/修改行。
gh pr review -a/-c/-r/-b/--body-file 核实存在;github-script 现 @v9、方法挂 github.rest.*、防注入=值走 env: 不进脚本插值;“dummy commit 贴 status”是社区都市传说,官方无文档,论文别写。

✅ GitLab 侧(前轮纠错,原文再记一遍):

GitLab 没有 reviews endpoint——贴行内建议走 Draft Notes + bulk_publish 或 discussions+position;suggestion:-0+0 代码块 Tier: Free/Premium/Ultimate 全档可用(v19.5.0-ee raw 核实);webhook 10s 超时 + 连续 4 次失败自动禁用;CI_JOB_TOKEN 对 MR 只读(贴不了评论);MR diff 行内标注走 artifacts.reports.codequality(CodeClimate JSON,非 SARIF),reports.sarif 是 Ultimate 且只进 Vulnerability report/security dashboard。

商用侧印证(harness+指令文件已是标配):✅ Copilot code review 就跑在 GitHub Actions 上、读 AGENTS.md/copilot-instructions.md/CLAUDE.md/.github/skills/ 当审查指引、Lite/Balanced 两档、成本=AI credits+Actions minutes。⚠ Bugbot 默认增量评审(review.incremental: true、.cursor/config/bugbot.yaml)与”从团队活动自动生成规则”仅经代理取回,引用前回官方页复核。

5. 结构化输出层:方案里一个默认假设要改

✅ providers 官方文档当日核实:

“forced tool_choice 逼 JSON”正在被废弃:Claude Opus 5.5 / Sonnet 5.5 / Fable 5.1 上 tool_choice: any|tool 直接 400;官方替代 = structured outputs(output_config.format,已 GA、无需 beta header;旧 beta header 值现名 structured-outputs-2025-11-13,-09-24 查无实据别引)。⚠ Anthropic 的 enum 大小写不保证且无报错——severity 枚举必须大小写不敏感比较。语法编译有硬上限(20 strict tools / 24 optional params / 16 union)+ 180s 超时;grammar 缓存 24h,改 schema 结构=缓存失效+首请求延迟。
schema 子集互不兼容(这就是论文”跨 Provider 可移植性矩阵”素材):OpenAI 支持递归 $ref、minimum/maximum、minItems>1,但要求全字段 required + additionalProperties:false,不支持 allOf/not/if;Anthropic 不支持递归 schema 和数值边界,minItems 只认 0/1;Gemini additionalProperties 可给 schema(独家)。→ 数值约束放 Pydantic validator,不放 wire schema。
DeepSeek 官方只有 json_object,且自认”偶尔返回空 content” → dsh/国产模型路线必须配 retry-with-feedback(instructor 机制:ValidationError 文本回灌为 user 消息)或本地 constrained decoding(outlines 16k★ / guidance 21.8k★——两家现在都走 llguidance/outlines-core 语法编译,注意 model(prompt, Schema) 返回的是字符串,仍要 validate)。Qwen 百炼有 json_schema+strict(参数面核实,强制机制未核 ⚠)。
instructor 归属敲正:567-labs/instructor(14,026★,jxnl 重定向至此);推荐入口已是 instructor.from_provider("openai/…"),patch() 降为 advanced。json_repair canonical 是 mangiucugna/json_repair(5,118★;mariostoev/python-json-repair 404)。
pr-agent 的反面教材价值:最流行的开源评审器完全不用约束解码,靠 prompt+“事后修复”解析器——outlines README 点名的正是这种架构。论文对比表里一句就能立住。
失败模式清单(全部有文档出处,直接进论文 4.x):finish_reason=length/stop_reason=max_tokens 截断→先断后解析;```json 围栏→strip+repair;refusal(Anthropic stop_reason:"refusal" 200 且计费,要求模型解释推理会诱发 reasoning_extraction refusal——审查 Agent 报安全漏洞恰好踩这条,schema 备无 reasoning 变体);语义垃圾(Google 原话:“语法正确也要在应用层验证值”——用 instructor context= 做”引用行必须是 diff 真子串”校验,这正好是证据锚定的实现钩子)。“GPT-4o lazy” 无官方文档背书,只算从业者传闻,别当事实写。

6. 推荐架构(论文第 3–4 章的骨架)

GitHub/GitLab 事件(webhook 或 Actions 两段式)
  → clone + diff(只读、当数据处理)
① 确定性扫描    Semgrep CE / ast-grep / 每语言 linter / OSV-Scanner → SARIF/rdjson(统一 Finding)
② LLM 评审      pi extension headless(--print / --mode rpc,--tools read,grep,find,ls)
                证据注入(文件+调用关系+规则命中)→ 多角色 finder → 验证器 gate(要证据才留)
③ 融合          确定性优先 + FNV 指纹去重 + finding 生命周期状态机(ACTIVE/RESOLVED/SUPPRESSED)
④ 报告          reviewdog(14 reporters)+ SARIF upload + GitLab Draft Notes;CI gate 用 exit code

理论支柱(✅ 全部重验 ID):固定管线胜自主循环——Agentless(2407.01489,本地化→修复→验证,cents 级成本);分阶段评审工业范本——Sashiko 11 阶段(“证明不了就不报”的 FP gate);外部验证器必须存在——CoVe 2309.11495 / CRITIC 2305.11738 / Self-Debug 2304.05128,以及负结果 2310.01798(无外部反馈的”自我纠错”反而降准确率;常被误写为 2310.01796,那是 LILAC)。编排选型:固定 DAG 不上 LangGraph;首选 **Pydantic AI(21k★,output_type= 类型级校验)**或 asyncio+Pydantic 手搓状态机;LangGraph 写成”评估过、因不需要 resume/HITL 未采用”的论证段。AutoGen 已实质归档(README CAUTION;PyPI 冻在 0.7.5)→ 后继 Microsoft Agent Framework。MetaGPT ext/cr/ 有现成 points_cn.json 中文规范规则集,rule-grounded 审查可直接引(✅ 2308.00352)。

上下文注入与检索层(RAG,✅ 当日 HF config/GitHub API/arXiv 逐条核)

核心决策:PR 评审的上下文主体是”diff hunk + 外层函数 + 文件头”,不做整仓语义索引;跨文件影响分析用精确索引而非向量相似度。

依据一:最强的 OSS 评审器 pr-agent 根本没有 embedding 索引——extra_instructions + repo_context_files(自动读 AGENTS.md/CLAUDE.md,默认分支,repo_context_max_lines=500)+ dynamic context(hunk 向外扩到外层函数/class)。(⚠ 旧配置 max_score 在现仓已不存在,别写。)
依据二:Better Call Grep ✅ 2601.23254——免索引词法检索(ripgrep 式)在仓库级补全上与语义 RAG 打平,索引的构建/维护成本常常不值;SWE-bench 系任务由 agentic grep/Read 解决。
依据三(反向需求):跨文件要的是精确——LSP 3.17 的 references / callHierarchy(方法名 spec 核实)+ SCIP(✅ 精确索引、无需跑编译器;仓库已迁 scip-code/scip)。参考实现:aider repo map ✅(读源码核实:文件依赖图上 plain nx.pagerank + personalization(不是 personalized_pager),tree-sitter Query 抽 def/ref,当前码路不用 universal-ctags;--map-tokens=1000 预算内贪心填充)——“token 预算下的上下文选择器”就照这个做,是 ② 段的现成设计蓝本。
若仍配检索臂(消融用):✅ 组合 = **bge-m3(许可是 MIT!dense+sparse+ColBERT 三合一,8k)**或 Qwen3-Embedding-0.6B(Apache-2.0,32k,指令化);存储 sqlite-vec / LanceDB(嵌入式零服务器,笔记本毕设刚好;FAISS 是库不是 DB,别当向量数据库写);融合 RRF,k=60(SIGIR’09 Cormack et al. 原始文献 + ES rank: rrf);chunk 单位 = 函数体+类签名头+imports,embedding 缓存以 hash(chunk_text) 为键(只重嵌改动函数,Aider 的 TAGS_CACHE 同款做法);评测 CoIR ✅ 2407.02883(ACL’25,核心结论:文本 MTEB 分数预测不了代码检索)+ CrossCodeEval ✅ 2310.11248;chunking 方法直接引对照实验 ✅ 2605.04763(Function/Declaration/Sliding/cAST × 4 retriever × 5 generator,864 组)。
许可雷区(全部 ✅ HF frontmatter):jina-embeddings-v3 是 CC-BY-NC、v4 是 Qwen Research License(README 自述曾错标 cc-by-nc);nomic-embed-code 是 7B 模型(3584 维,last-token pooling,别当轻量件);Voyage 已被 MongoDB 收购,现行代码模型是 voyage-code-4(code-3 降为 older);code-gecko 已从 Vertex 列表消失(正式退役日期未核 ⚠)。
贡献框架白送:评测章加一组”上下文消融”(diff-only / +RRF 混合检索 / +LSP 精确上下文)——若结论是 PR 评审大头 diff+外层函数即够,这个负结论本身就是论文的有价值的发现(与 SWE-PRBench”加文件上下文反掉点”✅ 互相印证)。

7. 创新点候选 ×5(每个都带已发表锚点)

证据锚定 + 谄媚抑制:EGDP ✅ 2607.10411(决策翻转率 72%→12%、假一致 >90%→21%);HalluJudge ✅ 2601.19072(无参考判”审查是否落地”,F1 0.85、$0.009/条,Atlassian 数据)。差异化 = harness 内实现 + 用 provider 的 context=/validator 钩子做”引用行必须是 diff 子串”。
多角色跨家族共识:SWR-Bench ✅ 聚合 +43.67% F1;M2CVD ✅ 2406.05940;对抗审查 ✅ 2608.18167(记录 false-consensus 失败——角色要跨模型家族,别同 family 自洽)。
finding 生命周期状态机:MCR-Bench ✅ 2608.27442 点名”跨轮次时间错位+长程记忆不足”是主要失败驱动;pr-agent 有初版(HTML comment 状态块),harness 扩展全都没有;pi 的 JSONL 会话树/checkpoint 是天然存储。
评审 Agent 自身的对抗鲁棒性(防御侧几乎没人做——我认为是故事性最强的一条):SEVRA-BENCH ✅ 2606.13757(~1000 对抗 PR、15 种话术、8 个主流评审 agent 全部可被叙事操纵)、ALIBI ✅ 2607.24964(对抗注释 ASR>90%)、Familiar Pattern Attack ✅ 2508.17361(NDSS’26,跨厂商可迁移)、2603.18740(上下文偏差迭代精炼)。pi 的 tool_call 拦截 = 现成防御缝(注释消毒/指令-数据分离/不可信 diff 的分隔符处理+红队实验),工作量小、答辩演示效果极佳。
成本感知级联路由:当日官网锚点(⚠ 打印前再核)——Anthropic Haiku 5.5 $0.10/$ 0.50 ↔ Sonnet 5.5 $2/$ 10 ↔ Opus 5.5 $4/$ 20;OpenAI nano $0.05/$ 0.40 ↔ 旗舰 $10/$ 50(输出价差 100–500×);Gemini 3.8 Flash 输入 $2 (官网自己写明 11 - 30 后翻倍$ 4)。画 ** $/ K L o C \leftrightarrow rec a ll 曲线 * *; 旁证 : C o p i l o t L i t e / B a l an ce d 分档、 G re pt i l e B a se / Pl u s / A p e x 1/3/10 cre d i t s 、 p r - a g e n t ‘ m o d e l_{r} o u t in g ‘ 、 GPTS c an$ 0.01/KLoC ✅。

8. 评测方案(实验章直接照此装配)

语言选 Java 或 Python(数据集密度最高)。

用途	首选	关键数(✅)
端到端评审(生命周期)	MCR-Bench 2608.27442(ISSTA’26)	2,269 多轮任务、5 语言、缺陷跨轮状态标签;轮数越多越崩
端到端评审(FP/定位)	SWE-PRBench 2603.26130	350 PR 人标、κ=0.75 judge;仅检出人标问题 15–31%;加文件上下文反掉点(注意力稀释);2000-token 结构化摘要>2500-token 富化
评论生成聚合	SWR-Bench 2509.01494	1,000 人工校验 PR;judge 与人类 ~90% 一致;聚合 +43.67% F1
agent 总量基准	c-CRAB 2603.23448	人类评审+配套测试做真值;现有 agent 合计 ~40%
异味检测	MLCQ / DACOS(2303.08729,10,267 标注)/ SACS(2602.15342,三类各 >10k)	基线 MetaLint 2507.11687(✅ 代码+基准开源;lint=指令跟随,合成数据训练,Qwen3-4B F 25.9→70.4)
重构半边	SWE-Refactor 2602.03712(1,099 仓库级行为保持任务)、SmellBench 2605.07001	等价性检验:差分模糊测试查出 19–35% 自称等价的并不等价 ✅ 2602.15761
安全半边	CWE-Bench-Java(在 IRIS ✅ 2405.17238 内:CodeQL 检出 27 vs IRIS+GPT-4 检出 55)、SecCodeBench-V2 ✅ 2602.15485(Qwen,98 场景/22 CWE/5 语言,中文毕设最实用)	GPTScan ✅ 2308.03314
审查可信度判别	CRJudgeBench 2609.37216	1,199 实例+专家扰动负样本;验证器阶段单独可挂
可跑仓库	✅ aacr-bench(244★)、Martian code-review-benchmark(290★)、ReviewBench、CodeFuse-CR-Bench(601 Python)、ContextCRBench(67,910,hunk 级,字节上线 +61.98%)	ground truth 缺自己造时:CRBugBench 2610.13668 历史挖掘配方(“top-5 评论捕获 71.9%”)

指标口径(学术共识,✅ 综述 2602.13377 与 DeepCRCEval 2412.18291):检测类 P/R/F1 + KBI/FAR(2505.17928,ICML’25 Spotlight,专治”低 FP 怎么报”)+ FP 削减同行数(GPTScan 消 2/3、SAST-Genius −91%、AdaTaint −43.7%);定位类 hunk/行级 top-k;重构类可编译+测试通过+语义等价+不引入新异味;BLEU 已死(CRScore 2409.19801:“审查是一对多”,reference-free 也只有 Spearman 0.54——诚实写进论文;GradedReviews 2501.05176 把相关度从 0.22 提到 0.47)。LLM-judge 必须 κ 校准(SWE-PRBench 0.75 / SWR-Bench ~90%)。噪声纪律沿用 Agent Harness 评测:先测重跑噪声再谈效应、任务级配对。 工业 motivation 三件套:MetaMateCR ✅ 2507.13499(64k 评论-补丁对;ActionableToApplied 19.7%,+9.2pp over GPT-4o)、RovoDev ✅ 2601.01129(ICSE’26 SEIP;解决率 38.70%、周期 −30.8%、人工评论 −35.6%)、BitsAI-Fix ✅ 2508.03487(tree-sitter 扩上下文→search-replace 补丁→重扫 lint 复检;85% 修复率、5000 工程师)——最后这条就是你 ②③ 段的已发表工业版,引用即背书。

9. 勘误与禁引清单(防止从别处又抄回假引用)

本轮被推翻/修正的说法(含我自己此前的):

~~“服务端 webhook 评审没人做”~~ → 空白仅在”作为 harness 扩展交付”。
~~“商用产品不集成静态分析”~~ → CodeRabbit 集成约 50–60 个 linter+原生 ast-grep(⚠ 清单经代理取回,引用前回 docs.coderabbit.ai/tools/list 复核);Codacy 官网列名 ESLint/PMD/Ruff/Semgrep(已迁 OpenGrep)/Checkov 等 ✅。
~~“GitLab 用 reviews API”~~ → 无此端点;Draft Notes+bulk_publish / discussions+position;CI_JOB_TOKEN 只读;行内 codequality 免费档、SARIF 进 security dashboard 是 Ultimate。
pr-agent org 名 = The-PR-Agent(qodo/Codium 皆 301);Kodus 不写 SARIF(只读);OCR 的 deterministic ≠ 跑 linter;生命周期 gap 仅对 harness 扩展成立(pr-agent 自己有)。
CodeReviewQA 不是微软的(Lin et al., ACL 2025 Findings,✅ 2503.16167,900 题 9 语言)。

证伪,禁引:RefactoringBench、ReviewNet、CRMatch、VulBench、“CodeReviewGPT”作为论文、“Using LLMs to Fix Pylint Violations”(查无此文;猜测 ID 2302.08959=包管理攻击综述、2311.00825=量子金融)、Meta “SapioCite”(全站 0 命中)、CReT、Review2、PR-SelfReview、Copilot-eval-harness 仓、CodeGuru 全 EOS 日期、Bitbucket AI review 文档 URL、ProntoQA(2210.01240 是逻辑推理集,与评审无关)、Keshavarz 名下 “PPR/SWR 数据集”、ECORE、CRepoMiner、DevIgnition、CodeReviewNet、Aider polyglot/CodeSignal(无论文)、gnahz-boo/cr-gpt(404)、zeefnix/agentless(不存在,真名 OpenAutoCoder/Agentless 2.1k★)、ReviewPilot、AskingDiff、straydragon/crystal。敲正:TestGen-LLM = 2402.09171(75% 构建正确/57% 稳定通过/25% 提覆盖,73% 建议被采纳);Google eng-practices 路径是 review/developer/(无 author 目录),锚点 100/1000 行(没有 200 行限制这种说法),许可 CC-By 3.0;SWE-bench Verified=500 题人核子集(构造论文未核,别把 “SWE-bench Verified” 当论文引);CodeXGLUE 没有 code review 任务(最接近 Code Refinement)。 RAG 层敲正(均 ✅ 一手核):CrossCodeEval = 2310.11248(网传 2310.11216 是 Mott-Hubbard 物理论文)、SWE-bench = 2310.06770(2310.09614 是可视化论文);CodeT5+ 是 Salesforce 的(非微软非 Meta,且它是 encoder-decoder 骨干不是现成 embedding 模型);Meta 从未发布可下载的 code embedding 模型;LangChain ASTCodeSplitter 已从现行包消失(写”不再存在”,勿写”vX 弃用”——移除版本没查到);chromadb.utils.chunker.CodeChunker 不在现 chromadb 包里(code 拆分只在 cookbooks 示例/独立包);aider 仓库现名 Aider-AI/aider、repomap 用的是 plain pagerank 非 personalized_pager;MTEB 排行榜地址是 HF space mteb/leaderboard(mtef 404);bge-m3 许可 MIT(常被误标);tantivy 在 quickwit-oss/、SCIP 在 scip-code/(旧地址 404)。 工具假 flag 高发区:ast-grep 无 --language;madge --circular;CodeQL --format=sarifv2.1.0;sarif-tools 命令名 sarif;semgrep 无 --format/--json-stats;trufflehog/gitleaks 的新旧子命令。附录做法:从 --help 当日实录生成。

环境教训(与本次多路调研互相印证):本会话 WebSearch 会输出”像模像样的编造”(假 arXiv ID、假 200 行限制、假仓库)——所有引用必须经 arXiv abs 页 / GitHub API / 官方 raw 页直接核验;经代理取回的页面(部分 Copilot/Cursor/CodeRabbit 材料)全部标 ⚠。CodeRabbit 闭源无引擎(仅 awesome-coderabbit 等周边仓),其机制 claim 一律不写;行为参考可用 ✅ 2607.03316(“Is Agentic Code Review Helpful?” CodeRabbit 真实反馈挖掘)。CodeGuru Reviewer 已死(✅ 官方:2025-11-07 起不能新建 repo association)——对比表里作历史条目,别作现役方案引。

10. 遗留与下一步

模型价格当日均为官网 raw 值,打印进论文时重取一次并标”as of”。
⚠ 待复核项:Bugbot bugbot.yaml 键名、Copilot “13 premium requests/次”计费数字(两起仅经代理)、CodeRabbit tools/list、dsh 当前 breaking-change 面、chunking 对照研究 2605.04763 的 ID 真实性(2026 新 ID,提交前 abs 页再核一次)、Cognition “Don’t Build Multi-Agents” 与 Anthropic “search don’t retrieve” 两篇博客的 URL(本轮没能抓到可引用原文)、SPLADE 的 repo/arXiv ID。
下一步(实现期):① 定语言(倾向 Python:Ruff/Semgrep/pip-audit/DACOS/CodeFuse-CR-Bench 全链路顺)② 在私有仓搭 Actions 两段式最小闭环(webhook→OCR 式混合管线→reviewdog 贴回)③ 先在 MetaLint + SWE-PRBench 上跑通评测再谈创新点 ④ 创新点按”4 对抗鲁棒 > 1 证据锚定 > 3 生命周期 > 2 共识 > 5 成本级联”的性价比顺序做。

探索

Akiyama's blog

毕业设计 - 调研