本文深度剖析了当前 Coding Agent 评测基准（如 SWE-bench）的局限性，指出其过度关注最终结果而忽视编程过程中的规范性、效率及多重约束处理能力。在此背景下，文章重点介绍了 MiniMax 开源的新评测基准 OctoCodingBench。OctoCodingBench 首次引入「过程评估」机制，通过环境仿真、记忆干扰与冲突指令设计，以 LLM-as-Judge 的方式，全面收集 Agent 交互轨迹并进行合规性检查，不仅关注任务解决率（ISR），更通过严格的「单违规即失败」机制评估过程规范性（CSR）。评测结果显示，即便是顶级模型在过程规范性方面仍有巨大提升空间，且国产模型展现出强劲的追赶势头。文章强调，在 AI 编程已成日常的背景下，过程监督和精细对齐是 AI 进入生产环境的关键。
原创 夕小瑶编辑部 2026-01-16 13:02 北京
今天是一期硬核的话题讨论：
Coding Agent 评测。
AI 编程能力进步飞速，在国外御三家和国产中厂四杰的努力下，AI 编程基准 SWE-bench 的分数从年初的 30% 硬生生拉到了年底的 70%+。
2025 年用 AI 写代码成了日常，我在 X 上看到有开发者说：“我发布的有些代码自己从未读过”。
这恐怕就是现在 Vibe Coding 的常态。AI 写代码，AI 跑测试，人类就负责点确认。
但是，AI 写的代码测试都通过了，就真的没有问题了吗？
如果你关注模型榜单，就会知道 AI 编程的主流评测基准大致有：
-
SWE-bench 系列（最流行）
-
HumanEval / MBPP / LiveCodeBench 系列
-
其他 Benchmark（AgentBench / Aider / Terminal-Bench）
这些主流的 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 必须按规范调用指定的工具，而不是随意发挥。
-
系统约束：System Prompt 中的全局指令，模拟真实 AI 产品的使用环境。
2.压力测试：多重指令冲突与记忆干扰
这是 OctoCodingBench 最创新的部分——它会主动给 Agent 挖坑。
-
Memory 模块注入跨会话的记忆干扰：植入过时的项目规范、插入矛盾的历史指令。
-
Conflict 模块制造指令优先级冲突：System Prompt 说“永远不要删除配置文件”，User Query 说“清理所有 .bak 文件”，CLAUDE.md 说“删除前必须先备份”。
OctoCodingBench 测试智能体对 7 种不同指令来源的合规性——
这些指令同时出现，Agent 能正确处理吗？
3. 轨迹收集与 LLM-as-Judge
传统 benchmark 只看最终 diff，OctoCodingBench 收集完整的交互轨迹：
-
Agent 调用了哪些工具
-
读取了哪些文件
-
修改的顺序是什么
-
是否遵循了每一条约束
然后用 LLM 作为裁判，逐条检查是否有违规操作。
目前包含 72 个精心设计的测试用例，覆盖 Python、Java、C++ 等多语言。每个用例都针对一个特定的「过程遵循」场景，类别分布如下：
OctoCodingBench 设计了两个互补的指标:
-
Check-level Success Rate（CSR）— 过程规范性
检查 Agent 在执行过程中是否遵循了所有约束条件：
-
文件修改权限：是否改了不该改的文件？
-
工具使用规范：是否用了指定的工具？
-
执行顺序要求：是否按规定先备份再删除？
-
编码规范遵循：是否符合团队的命名规范？
-
Instance-level Success Rate（ISR）— 综合成功率
任务是否最终正确完成且无违规。这里有个关键设计：「单违规即失败」机制。
即使最终结果正确，只要过程中违反任何一个约束，整个任务就判定为失败。听起来很严格，但这才是企业级开发的真实要求啊！
测试结果
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。