背景
最近半年 Coding Agent 发展很快。SWE-Agent（普林斯顿大学开源的软件工程 Agent）、OpenHands（前身 OpenDevin，开源的自主编程 Agent 平台）、Devin（Cognition AI 推出的 AI 软件工程师）、Claude Code、Codex 这类工具，已经能在几分钟内产出一个可以跑测试的补丁。
这带来了一个很实际的问题：当一个团队每天面对的不是 10 个 PR，而是 1000 个 Agent 提交时，人类 Reviewer 就成了整个系统里最慢的一环。LGTM（Looks Good To Me）从一个判断行为退化成一个盖章行为。
在我看来，这里真正发生变化的不是“Code Review 怎么做得更快”，而是问题本身被重写了。我们都知道，传统 Code Review 建立在一个隐含前提上：代码是稀缺的、写代码本身是瓶颈，所以人有时间逐行看。这个前提在 AI Coding 时代正在崩塌。当代码被大规模、高速度地生成出来，核心矛盾就从 Generate Code 转移到了 Establish Trust（建立可信性）。
那么 Code Review 的未来到底是什么形态？这篇文章简单聊聊我的看法。
为什么说 Verification 比 Coding 更难
在讨论最终形态之前，先看看今天大家在做什么。
目前几乎所有 Coding Agent 的默认闭环都是同一个：
Issue
|
Coding Agent
|
生成 Patch
|
Run Test
|
失败则继续修改这里的 verifier（验证者）是 test，也就是“测试通过 = 改动正确”。这个闭环在 benchmark 场景里跑得通，但在真实工程里大概存在这么几个问题：
- 测试覆盖不全，很多路径根本没有对应用例。
- 隐藏的 bug、并发问题、内存泄漏、性能回退、安全漏洞，普通单测几乎不可能捕获。
- benchmark 本身的测试设计也可能有问题——需求描述不完整、断言过严或过松，都会导致 tests pass 并不能可靠地等价于 correctness（正确性）。
OpenAI 最近对 SWE-bench Pro 的审计发现大约 30% 的任务本身是坏的（过严测试、描述不全、低覆盖测试、误导性 prompt），这从另一个角度说明了一件事：在 Agent 时代，验证问题本身比生成问题更难。评测标准里潜藏的噪声，甚至可能让一个“变强的模型”看起来没有进步。
因此，Code Review 需要解决的核心问题从来都不是“更快地看 diff”，而是“用什么方法建立可信性”。这也直接决定了未来的形态不会是一个更聪明的 Reviewer 模型，而是一个由多层验证能力组成的系统。
几个正在发生的方向
业界还没有一个统一的名字（我倾向于叫它 Verification Agent），但多个研究方向已经在向同一个终点收敛。
Test-driven Verifier
这是当下最成熟，也最容易被误解为“已经解决”的方向。它把 Coding Agent 与测试框架绑成一个闭环：改代码、跑测试、失败再改，直到全部通过。前面提到的 SWE-Agent、OpenHands、Devin、Claude Code、Codex，本质都在做这件事。
优点是工程简单、可以做强化学习。缺点也很明确：它把“代码是否正确”等价于“测试是否通过”，把验证问题外包给了测试设计者。当测试不完整时，它会以极高的效率生产出一堆“测试通过但不解决问题”的补丁。
Multi-agent Review
第二类做法是把 Reviewer 也变成 Agent，让不同角色互相 challenge：
Coder Agent
|
Reviewer Agent
|
Critic Agent
|
Fix AgentReddit 上有人做过一个非严格的对比实验，在 SWE-bench Verified 的 100 个实例上，单 Agent（Claude Opus 4.5）解决率是 80%，加上一个 Reviewer Agent（GPT-5.2）之后提升到 90%，代价是平均耗时从 3.5 分钟增加到 7.8 分钟，大约 2.2 倍。这个实验样本量不大，不能直接推广，但它揭示了一个更基本的现象：Review 是可以带来独立信息量的，只要 Reviewer 不再和 Coder 共享同一个上下文与偏见。
当然，如果 Reviewer 只是用另一个 LLM 重新读一遍 diff，它仍然停留在“感觉合理”的层面。要往前走，Review 需要能调用工具、能形成证据，而不仅仅是重新表达一次自然语言判断。
Specification Verification
第三个方向是我个人觉得潜在价值最大、但目前几乎没有人做好的。
今天大部分验证做的是 Code -> Pass Test。真正应该做的是 Spec -> Implementation -> Equivalent?，也就是验证实现和规格说明是不是一致。举个例子，一个 PR 的需求可能是：
- 必须 backward compatible（向后兼容）。
- P99 延迟必须小于 200ms。
- 单实例内存必须小于 4GB。
Verification Agent 要做的不是跑一遍单测，而是自动证明：
- 公共 API 没有破坏性变更。
- Benchmark 结果满足 P99 阈值。
- 内存 profile 满足上限。
- 所有历史测试通过。
- 新功能测试通过。
这里被 review 的对象已经不再是代码本身，而是 Spec 是否被实现。这一步之所以难，是因为它要求需求本身是可验证的——这大概也意味着未来工程流程里，Spec 会重新变成一等公民。
Formal Verification 与 Explain + Verify
第四个方向来自更“硬核”的一侧。
近期有一篇论文叫 “The Prover Is the Judge”，尝试用 Ada / SPARK（一种面向高可靠系统的编程语言与验证工具集）和 GNATprove（SPARK 的形式化证明工具）让 AI 生成安全关键代码，再由证明器验证大量证明义务，形成“AI 写代码，证明器判决”的闭环。论文里报告 GNATprove 自动完成了 49,280 条证明义务，覆盖了密码学、TLS 1.3、IKEv2、X.509 等组件，但作者也坦率地指出：证明器能证明什么，取决于规格和验证器的表达能力，对于某些缺陷仍然需要 known-answer tests（已知答案测试）、互操作验证或人工审查。
与之并行的是 Explain + Verify 这条思路，代表性的评测是 ExplainBench（ASE 2026）。它的观察很朴素：一个 Agent 说“我改好了”并不足够，我们真正想知道的是“为什么这样改、影响哪些模块、为什么不会 break”。ExplainBench 的结果给出一个重要判断：解释质量与 Coding 能力是两个独立维度，一个补丁可能正确但解释错误，反之亦然；而且 Agent 经常错误地宣称补丁正确。论文里实现了一个 explanation audit agent（解释审计代理），通过额外运行测试来验证和修正解释，确实改善了所有被评估 Agent 的解释质量。
六层 Verification Stack
把上面这些方向叠加起来，我倾向于认为 AI Coding 时代的 Code Review 最终会长成一个分层的 Verification Stack，而不是任何单一模型或单一工具。下面简单介绍一下每一层。
Layer 1：Syntax
最底层，也是最容易被忽视的一层。编译、lint、格式化、类型检查在这一层完成。它保证“代码至少是一个合法的字符串”，任何上层验证都建立在这个前提之上。AI 在这一层的价值不大，现有工具已经足够。
Layer 2：Static Analysis
第二层负责结构性缺陷：死锁、竞态、资源泄漏、空指针、注入类漏洞等等。今天已经有 CodeQL（GitHub 的语义代码分析引擎）、Semgrep（轻量级静态分析工具）、Infer（Facebook 开源的静态分析器）等成熟工具。未来 LLM 的角色大概是统一调用与解释：根据改动特征选择合适的规则集，把工具产出翻译成可读的、能被 Verification Agent 引用的证据。
Layer 3：Behavioral Verification
第三层不再看代码，而是运行代码：unit test（单元测试）、integration test（集成测试）、e2e（端到端测试）、fuzz（模糊测试）、mutation test（变异测试，通过故意修改代码来检验测试用例的质量）。AI 在这一层最有价值的动作是自动补测试——针对 diff 与调用图，生成有针对性的用例，特别是补齐 mutation score（变异得分）较低的路径。它是 Test-driven Verifier 的自然升级。
Layer 4：Repository-level Reasoning
第四层是 LLM 相对于传统工具真正拉开差距的地方。它要回答的是仓库级问题：
- 这个 PR 影响哪些模块？
- 有没有引入重复实现？
- 有没有违反既定架构？
- 有没有造成 API drift（API 漂移）？
这一层需要基于代码图（调用图、依赖图、模块图）做推理，是 diff-only Reviewer 天然做不到的。它决定了 Verification Agent 能不能看到“小 PR 引发系统性风险”的场景。
Layer 5：Spec Verification
第五层是我认为价值最大、也最难的一层。它把需求变成一等公民：
Spec
|
读取代码
|
生成验证计划
|
执行验证
|
证明是否满足在这里被 review 的不再是 code，而是 intent（意图）。这一层的成熟度大概直接决定了未来能不能把 Coding Agent 真正规模化地交给系统而不是个人。
Layer 6：Runtime Verification
最后一层很多人会漏掉：不是所有问题都可以在合入前发现。内存泄漏、突发流量、少见的竞态、上线后的延迟回退，本质上都是运行时问题。未来的 Verification Agent 会延伸到 merge 之后：持续观察 metrics、logs、trace、crash、canary（金丝雀发布），判断某个指标漂移是不是某个 PR 引起，必要时触发自动回滚。
也就是说，Verification 不是一个 merge 前的门禁，而是覆盖整个软件生命周期的能力。
未来流程
如果把这些层组合起来，未来的流程大概会更像这样：
Spec
|
Coding Agent
|
Verification Agent
├── Static
├── Dynamic
├── Tests
├── Security
├── Performance
├── Spec Matching
├── Explanation Audit
└── Runtime Prediction
|
Risk Score
|
Human（仅高风险）对比今天的 Human -> Read Diff -> Approve，可以看到两个主要差别：
- Human Review 不消失，但被显式地留在高风险位置。绝大多数改动由 Verification Agent 直接通过或直接拒绝，人只在系统“拿不准”的时候进入。
- Verification 的输出从“同意 / 拒绝”变成“一个带有置信度的风险评分”，可以被后续系统消费。
这两个变化共同推翻了 Code Review 的旧范式：Reviewer 不再是一个决定权在自己手上的角色，而是整个可信性系统里的一环。
Evidence-based Verification
如果只让我押一个具体的研究方向，我会选一个几乎还没有名字的方向：Evidence-based Verification Agent（基于证据的验证代理）。
今天的 Reviewer（无论人还是 AI）给出的通常只是一个结论：
LGTM未来的 Verification Agent 应该给出的是一整条证据链：
Claim:
这个 PR 不会 break API。
Evidence:
- AST Analysis：公共接口签名未变。
- 142 Regression Tests：全部通过。
- Mutation Score：93%，覆盖新增分支。
- Call Graph：无新增循环依赖。
- Canary Prediction：预测风险 0.03。
Confidence:
98.7%这个方向和近几年 AI 领域强调的 reasoning trace（推理轨迹）有相似的气味，但对象完全不同：reasoning trace 是模型推理过程的可解释性，而 Evidence Chain（证据链）是软件可信性的可解释性。前者服务于“模型说了什么”，后者服务于“我们应不应该相信这次改动”。
顺着这个方向再往下想，有三个问题在我看来最值得投入：
- Spec-to-Evidence Verification：如何把自然语言需求自动转化为可验证的证据计划，而不仅仅是生成一些测试。
- Repository-scale Verification Graph：把整个仓库建模成依赖图、调用图与架构图，验证一次变更的系统级影响，而不是只看 PR diff。
- Evidence Aggregation：把静态分析、动态测试、LLM 推理、运行时监控、形式化验证等信号融合成一个可解释、可校准的风险评分，而不是简单的 Approve / Reject。
如果说 Coding Agent 的核心动作是 Generation（生成），那么 Verification Agent 的核心动作就应该是 Evidence（证据）。Code Review 这个名字大概率会保留下来，但它背后的东西会被彻底换掉——不是“怎么看代码”，而是“我们凭什么相信一段代码”。这大概也是 AI Coding 时代最值得做的一件事。
参考
- OpenAI, Separating Signal from Noise in Coding Evaluations（2026-07）：审计 SWE-Bench Pro 数据集，估计约 30% 的任务存在破坏性问题（过严测试、需求描述不全、低覆盖测试、误导性 prompt），从评测侧说明“tests pass 不等于 correctness”。
- Reddit 社区实验：I ran 100 SWE-bench tests comparing 1 agent vs 2 agents：SWE-bench Verified 100 例上，单 Agent 80% → 叠加 Reviewer 后 90%，耗时 2.2 倍。非严格学术结果，但说明 Review Agent 带来独立价值。
- Tobias Philipp, The Prover Is the Judge: Verified Security Software from AI Coding Agents in Ada/SPARK（arXiv:2607.14340, 2026-07）：AI 在 Ada / SPARK 中编写安全关键代码，GNATprove 完成 49,280 条证明义务；证明器无法覆盖的部分仍需测试、互操作验证或人工审查。
- Zhiyuan Pan et al., ExplainBench: Evaluating Code Explanations from Agents（ASE 2026, arXiv:2607.26451, 2026-07）：解释质量是独立于 SWE-bench Verified 的评估维度，Agent 经常错误地宣称补丁正确；explanation audit agent 可自动改善解释质量。
并且现在的网卡很多都是多队列的，每条队列和某个 CPU 进行绑定，由该 CPU 进行处理。因此如果这个软中断发生在 cadvisor 统计 memory cgroup，进行系统调用时，软中断的处理就可能因此而延迟。如果这个过程持续 1s+，那么引起的现象可能就是对端 tcp 出现重传。如果这个过程持续 2s+，那么因为服务本身读取 redis 的超时时间设置为 2s，就可能出现超时了。
不过我们也可以发现，这里的输出格式似乎和在终端里 
不过在 GUI 场景中，我们打开的终端并不是使用 tty，而是 pseudo-TTY(下文称之为 pty)。pty 也称为伪终端，也就是说它并不是真实的 tty 设备。引入了 pty 之后，终端的数量就不会再有限制了。我们可以打开任意多的 GUI 终端程序，每打开一个 GUI 终端，就会在 
这时候我们在回到 -t 参数，这里其实就是为容器内的 sh 进程分配了一个 pty slave。当 sh 感知到自己被分配了 pty slave 后，它会采用不同的工作模式。比如会在终端上输出提示符，对输出的格式进行调整，像 bash 之类的还是加上颜色等等。 
kubelet 会在 pod sync loop 中监听 PLEG Channel，从而针对状态变化执行相应的逻辑，来尽量保证 pod spec 和 status 的一致。
因为 Evented PLEG 和 Generic PLEG 会同时更新缓存，所以在更新时还会对比当前值和缓存值的时间戳，保证当前值是更新的状态，才会更新到缓存中。
如上图所示，数据包通过 port 进入交换机后，首先会匹配 table 0 中的流表项。如果流表项匹配到了，则会根据该流表项设定的 actions 进行操作。如果未匹配到，则会被丢弃。 数据包在不同的 table 中流转时，只能按照升序进行，也就是说可以从 table 0 → table10，但是不能从 table10 → table0。并且需要注意的是，在流表之间跳转需要使用 goto_table 或 resubmit 语句来将数据包 copy 一份转发到其他的流表中处理。如果没有指定跳转动作，是不会继续在其他 table 中进行匹配的。 
正常情况下，LVS nat 模式的流量不能做 SNAT，因为不会经过 POSTROUTING 链。需要增加下的配置来让 LVS 数据包经过 POSTROUTING
当 metrics-server 需要获取当前的 CPU 使用量时，cadvisor 会统计最近 60s 内（即60个采样数据）的累积 CPU 使用时间，并除以总采样时间(ns)，得到 CPU 使用量。 
因为 CPU 使用量的时间单位是精确到纳秒(ns)的，因此难免在计算上会有一定的误差，所以当 CPU 满载时出现统计出来的数据会稍大于 CPU 核心数也是正常情况了。