今天是一期硬核的话题讨论：Coding Agent评测。AI编程能力进步飞速，在国外御三家和国产中厂四杰的努力下，AI编程基准SWE-bench的分数从年初的30%硬生生拉到了年底的70%+。2025年用AI写代码成了日常，我在X上看到有开发者说：“我发布的有些代码自己从未读过”。这恐怕就是现在Vibe Coding的常态——AI写代码，AI跑测试，人类就负责点确认。

但是，AI写的代码测试都通过了，就真的没有问题了吗？

如果你关注模型榜单，就会知道AI编程的主流评测基准大致有：SWE-bench系列（最流行）、HumanEval/MBPP/LiveCodeBench系列，以及AgentBench/Aider/Terminal-Bench等其他Benchmark。这些主流的Coding Agent Benchmark的核心指标是Pass@k（k次尝试中通过测试的比例），只要最终patch通过测试，无论过程如何都算成功。

但是，Coding Agent的过程对了吗？比如：有没有改不该改的文件？有没有违反开发规范？是不是用低效的方式完成？这些过程中的“违规操作”，SWE-bench都看不见。

更关键的是，真实的Coding agent需要同时处理System Prompt全局指令、用户查询的具体需求、Memory中的历史上下文、Tool Schemas的工具规范，以及配置文件（如.cursorrules、claude.md、skill.md）的额外约束。这是一个优先级排序和冲突解决的复杂博弈，但传统benchmark对此完全失明，只关注「能不能解决问题」，不关注「在多重约束下能不能正确解决问题」。而这，恰恰是Agentic AI时代的核心需求。

我们能造出完成任务的Agent，但不知道它们是怎么完成的，不知道它们在什么情况下会失败。Sourcegraph研究员Stephanie Jarmak说出了一个真相——我们构建Agent的能力，已经远远甩开了我们评估Agent的能力。

昨天，我看到前不久上市的MiniMax开源了一个新基准—OctoCodingBench（传送门：huggingface.co/datasets/MiniMaxAI/OctoCodingBench）。我觉得这个事儿还挺有意义的：一是做评测基准这种又苦又累不讨好的事儿，企业很少会主动涉足；二是它精准瞄准了行业盲区，能把SWE-bench看不见的“编程过程违规”揪出来，并且量化成可衡量的指标。

它首次引入了“过程评估”的核心逻辑，不只关注任务的解决率，还会严格核查Agent在解决过程中是否遵循指令和规则。其核心思路是不再把Coding Agent当成「会做题的模型」，而是当成「要上生产的队友」来考核。它不像传统题库那样局限于“填空题”形式，而是直接拉起Docker容器，开展全链路的仿真测试，具体分为三个核心环节：

1. 环境仿真，注入真实项目约束

每个测试用例都会创建一个模拟的代码仓库，里面包含两类关键约束：一是Repo Specific Rules，类似CLAUDE.md的项目级规范文件，明确界定哪些文件不能动、哪些操作属于危险操作、团队的命名规范是什么；二是Skills&Tools，即预定义的工具和技能清单，要求Agent必须按规范调用指定工具，而非随意发挥。

2. 压力测试：多重指令冲突与记忆干扰

这是OctoCodingBench最具创新性的部分——它会主动给Agent“挖坑”，测试智能体对7种不同指令来源的合规性。具体包括系统约束（System Prompt中的全局指令，模拟真实AI产品使用环境）、Memory模块注入的跨会话记忆干扰（植入过时项目规范、插入矛盾历史指令），以及Conflict模块制造的指令优先级冲突（比如System Prompt要求“永远不要删除配置文件”，User Query却要求“清理所有.bak文件”，CLAUDE.md又规定“删除前必须先备份”）。当这些相互冲突的指令同时出现，Agent能否做出正确判断和处理，成为核心考验。

3. 轨迹收集与LLM-as-Judge

传统benchmark只关注最终代码diff，而OctoCodingBench会完整收集Agent的交互轨迹，包括调用了哪些工具、读取了哪些文件、修改顺序是什么、是否遵循每一条约束。随后用LLM作为裁判，逐条核查轨迹是否存在违规操作。

目前该基准包含72个精心设计的测试用例，覆盖Python、Java、C++等多语言，每个用例都针对一个特定的「过程遵循」场景，主要围绕四大维度检查Agent是否遵循所有约束条件：文件修改权限（是否改了不该改的文件）、工具使用规范（是否用了指定工具）、执行顺序要求（是否按规定先备份再删除）、编码规范遵循（是否符合团队命名规范）。

这里有个关键设计：「单违规即失败」机制。任务需最终正确完成且无任何违规，即便结果正确，只要过程中违反任意一条约束，整个任务就判定为失败。听起来极为严格，但这正是企业级开发的真实要求——生产环境中，过程合规与结果正确同等重要，甚至更为关键。

测试结果：冷水与惊喜并存

MiniMax公布的测试结果，既给当下的Coding Agent泼了一盆冷水，也带来了意外惊喜，三大核心发现值得关注：

发现1：过程合格率不足1/3

几乎所有模型的CSR（Check-level Success Rate，过程规范性）指数都能达到80%以上，说明模型对规则具备基本认知，但ISR（Instance-level Success Rate，综合成功率）却出现断崖式下跌。即便是当前地表最强的Claude 4.5 Opus，综合成功率也仅为36.2%，这意味着在接近2/3的任务中，即便强如Opus，也会在某个细微规范上出现“违规”，暴露了现有模型过程合规能力的短板。

发现2：国产模型追赶速度惊人

从榜单细节来看，开源和国产模型正快速逼近闭源巨头。其中MiniMax M2.1和DeepSeek V3.2的ISR分别达到26.1%和26%，不仅紧紧咬住头部梯队，甚至在部分指标上超过了公认强大的Claude 4.5 Sonnet（22.8%）和Gemini 3 Pro（22.9%）。这一成绩印证了一个重要趋势：在Coding这种强逻辑场景下，国产模型已具备极强的竞争力，打破了闭源巨头的垄断格局。

发现3：多轮交互后易“智商掉线”

从ISR随对话轮数的变化趋势图（横轴为对话轮次，纵轴为解决率）可以看出，随着交互轮次增加，绝大多数模型的ISR开始震荡或持续下滑，指令遵循能力逐渐衰减。“过程合规”在长流程任务中极为脆弱，模型容易聊着聊着就遗忘规则，这也凸显了长时程复杂任务中过程监督的必要性。

因此，AI写代码并非无需干预，反而更需要针对性的code review；同时，这些中间过程的反馈信号，对模型训练至关重要，可为RLHF阶段提供更精准的奖励信号，助力模型优化过程合规能力。

结语：过程合规是AI上生产的第一门槛

很多人可能会问：我们真的需要这样严苛的基准测试吗？我的答案是：不仅需要，而且早该有了。

关注我的老朋友都知道，我一直对“AI编程评估”这件事有执念——当AI写代码成为常态，我们该如何评判代码的价值与安全性？坦白讲，在AI写代码已融入日常的2026年，建立系统化的评估意识，不是锦上添花，而是保障生产安全的刚需。

MiniMax开源OctoCodingBench，足以说明其在coding生产力场景的深耕决心。未来的Coding Agent，不能只停留在“会写代码”的层面，更要做到“懂规则、守规范”，具备细腻的过程把控能力。

Andrej Karpathy曾说，AI编程工具就像“没有说明书的外星技术”——能用，且能力极强，但我们对其运行逻辑和风险点知之甚少。而OctoCodingBench的出现，某种意义上就是在为这个“外星技术”编写说明书，让我们看清AI编程的过程短板，找到优化方向。

在AI写代码成为日常的今天，AI编程的下一个阶段，必然是过程监督与精细对齐。唯有守住过程合规的底线，AI才能真正跨越“上生产”的门槛。毕竟，能上生产的AI，才是真正有用的AI。