能上生产才是硬道理，Coding Agent 评测，终于开始关注过程了

本文来自微信公众号： 夕小瑶科技说 ，作者：夕小瑶编辑部，原文标题：《能上生产才是硬道理！Coding Agent 评测，终于开始关注过程了》

今天是一期硬核的话题讨论：

Coding Agent评测。

AI编程能力进步飞速，在国外御三家和国产中厂四杰的努力下，AI编程基准SWE-bench的分数从年初的30%硬生生拉到了年底的70%+。

2025年用AI写代码成了日常，我在X上看到有开发者说：“我发布的有些代码自己从未读过”。

这恐怕就是现在Vibe Coding的常态。AI写代码，AI跑测试，人类就负责点确认。

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

如果你关注模型榜单，就会知道AI编程的主流评测基准大致有：

这些主流的Coding Agent Benchmark的核心指标是：Pass@k（k次尝试中通过测试的比例）。

只要最终patch通过测试，无论过程如何都算成功。

但是，Coding Agent的过程对了吗？

比如：

这些过程中的“违规操作”，SWE-bench都看不见。

更关键的是，真实的Coding agent需要同时处理：

这是一个优先级排序和冲突解决的复杂博弈，但传统benchmark对此完全失明，只关注「能不能解决问题」，不关注「在多重约束下能不能正确解决问题」。

而这，恰恰是Agentic AI时代的核心需求。

我们能造出完成任务的Agent，但不知道它们是怎么完成的，不知道它们在什么情况下会失败。

Sourcegraph研究员Stephanie Jarmak说出了一个真相—

我们构建Agent的能力，已经远远甩开了我们评估Agent的能力。

昨天，我看到前不久上市的MiniMax开源了一个新基准—OctoCodingBench。

传送门：

huggingface.co/datasets/MiniMaxAI/OctoCodingBench

我觉得这个事儿还挺有意义的。

一是做评测基准这种又苦又累不讨好的事儿，企业很少会做；二是瞄准了行业盲区，可以把SWE-bench看不见的“编程过程违规”，揪出来并且量化成指标。

它首次引入了—过程评估。不只关注任务的解决率，还会关注Agent在解决过程中是否遵循指令和规则。

它的核心思路是不再把Coding Agent当成「会做题的模型」，而是当成「要上生产的队友」来考核。

它不像传统题库那样做“填空题”，而是直接拉起Docker容器，进行全链路的仿真测试：

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

每个测试用例都会创建一个模拟的代码仓库，里面包含:

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

这是OctoCodingBench最创新的部分——它会主动给Agent挖坑。

OctoCodingBench测试智能体对7种不同指令来源的合规性——

这些指令同时出现，Agent能正确处理吗？

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

传统benchmark只看最终diff，OctoCodingBench收集完整的交互轨迹：

然后用LLM作为裁判，逐条检查是否有违规操作。

目前包含72个精心设计的测试用例，覆盖Python、Java、C++等多语言。每个用例都针对一个特定的「过程遵循」场景，类别分布如下：

检查Agent在执行过程中是否遵循了所有约束条件：

任务是否最终正确完成且无违规。这里有个关键设计：「单违规即失败」机制。

即使最终结果正确，只要过程中违反任何一个约束，整个任务就判定为失败。听起来很严格，但这才是企业级开发的真实要求啊！

测试结果

MiniMax公布的测试结果，给当下的Coding Agent泼了一盆冷水，也给了一点惊喜。

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

几乎所有模型的CSR指数都能达到80%以上，说明模型大概懂规则。但ISR出现了断崖式下跌。

即便是地表最强的Claude 4.5 Opus，任务通过率也只有36.2%。

这意味着，在接近2/3的任务中，即使是目前的绝对强者，也会在某个细微的规范上“违规。

发现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随对话轮数的变化趋势，横轴是对话轮次，纵轴是解决率。

可以看到，随着对话轮次的增加，绝大多数模型开始震荡或下滑，指令遵循能力逐渐下降。“过程合规”在长流程任务中非常脆弱，模型聊着聊着就忘了规则。

所以，长时程的复杂任务的过程监督非常有必要，AI写代码也需要code review。

而且，这些中间过程的反馈信号，对模型训练至关重要，可以在RLHF阶段给予更精准的奖励信号。

结语

很多家人们可能会问：我们真的要用起来这样的基准测试吗？

我的答案是：不仅需要，而且早该有了。

关注我的老朋友都知道，我一直对“评估”这件事有执念——AI写的代码怎么评？

坦白讲，在AI写代码已经成为日常的2026年，建立系统化的评估意识，不是锦上添花，而是保命刚需。

MiniMax这次开源的这个Bench，说明他们在做深coding生产力场景。未来的模型必须具备更细腻的颗粒度：不仅要会写代码，更要懂规则。

Andrej Karpathy说AI编程工具就像“没有说明书的外星技术”——能用，很强。

OctoCodingBench的出现，某种意义上就是在为这个"外星技术"编写说明书。

在AI写代码已经成为日常的今天，下一个阶段一定是过程监督和精细对齐，才是「AI进入生产环境」的第一门槛。

毕竟，能上生产的AI，才是真正有用的AI。

• SWE-bench系列（最流行）

  
  

• HumanEval/MBPP/LiveCodeBench系列

  
  

• 其他Benchmark（AgentBench/Aider/Terminal-Bench）

  
  

• 有没有改不该改的文件？

  
  

• 有没有违反开发规范？

  
  

• 是不是用低效的方式完成？

  
  

• System Prompt全局指令

  
  

• 用户查询的具体需求

  
  

• Memory中的历史上下文

  
  

• Tool Schemas的工具规范

  
  

• 配置文件（如.cursorrules、claude.md、skill.md）的额外约束

  
  

• Repo Specific Rules：类似CLAUDE.md的项目级规范文件，定义了哪些文件不能动、哪些操作是危险的、团队的命名规范是什么。

  
  

• Skills&Tools：预定义的工具和技能清单，要求Agent必须按规范调用指定的工具，而不是随意发挥。

  
  

• 系统约束：System Prompt中的全局指令，模拟真实AI产品的使用环境。

  
  

• Memory模块注入跨会话的记忆干扰：植入过时的项目规范、插入矛盾的历史指令。

  
  

• Conflict模块制造指令优先级冲突：System Prompt说“永远不要删除配置文件”，User Query说“清理所有.bak文件”，CLAUDE.md说“删除前必须先备份”。

  
  

• Agent调用了哪些工具

  
  

• 读取了哪些文件

  
  

• 修改的顺序是什么

  
  

• 是否遵循了每一条约束

  
  

1. Check-level Success Rate（CSR）—过程规范性

   
   

• 文件修改权限：是否改了不该改的文件？

  
  

• 工具使用规范：是否用了指定的工具？

  
  

• 执行顺序要求：是否按规定先备份再删除？

  
  

• 编码规范遵循：是否符合团队的命名规范？

  
  

1. Instance-level Success Rate（ISR）—综合成功率