社区

MiniMax正式开源首个面向CodingAgent的系统性评测集OctoCodingBench。评测结果显示，部分开源模型在过程合规指标上已快速逼近甚至超越部分闭源模型，反映出在Agent时代，“数据与评测范式”的重要性正在上升为新的竞争要素。 MiniMax 官方发文： 在CodingAgent的实际应用中，我们观察到一个反复出现，却常被忽略的的现象：用户对Agent的不满，往往不是因为它“做不到”，而是因为它“做得不好”。 通过整理用户体感反馈，我们发现最高频的抱怨集中在：Agent不遵循明确给出的指令。比如用户在系统提示中明确要求“不要使用emoji”，Agent却在代码注释里加上笑脸；用户要求“先备份再修改”，Agent直接[rm-rf]删除文件；用户在项目文档中规定了命名规范，Agent却自行其是。 这些问题的共同特征是：任务最终可能完成了，但过程违反了规范。用户要的不只是“能跑的代码”，还有“符合团队协作规范的代码”。 01为什么CodingAgent 需要新的Bench 如果我们认为，遵循过程规范的CodingAgent，才能被放心地引入真实的软件工程流程中。那么目前主流CodeAgent的评估体系就出现了明显的盲区。随着ClaudeCode、Codex、Cursor、Windsurf等Agent产品的普及，社区正在形成一套面向Agent的仓库协议体系。项目不再只是一堆代码，同时也包含了多层次协作模式的说明： [CLAUDE.md]/[AGENTS.md]：告诉Agent“这个项目怎么玩”——命名约定、测试流程、禁用的危险操作等 Skills：封装可复用的工作流(如“生成API文档”)，Agent需要正确识别触发时机并按规范调用 Memory：跨会话保存用户偏好和任务进度，Agent需要基于历史状态继续工作，而非从头开始 这些机制的出现，本质上是在构建一个多层级的指令系统。举个例子，当用户说“帮我重构这个模块”时，Agent需要同时满足多个层级的约束：系统层面的安全规则（不能直接删代码）、当前用户的即时指令（重构到什么程度）、仓库中明确写下的工程规范，以及历史记忆中已经做出的决策（延续还是推翻）。更复杂的情况是，这些指令源之间可能冲突。用户临时说“这次就先不写测试了”，但[AGENTS.md]里明确要求“每次提交必须有测试覆盖”——Agent该听谁的? 然而一个尴尬的问题是，当前的学术榜单，无论是SWE-benchverified，还是各类基于terminal环境的测试，其核心理念几乎都是Outcome-basedMetrics(结果导向指标)：测试是否通过?Bug是否修复？这种结果导向的评估方式，根本无法刻画模型在沙盒环境下的输出过程，更不用说复杂现实场景的真实交互体验，最终导致了评估和真实使用场景的错位。 02 OctoCodingBench：面向工程可靠性的过程评估 要解决这个问题，评估范式本身需要发生根本性转变——需要关注输出过程本身。 基于这一动机，我们引入了OctoCodingBench，从Check-level准确率(CSR)、Instance-level成功率(ISR)两个维度来进行评估，旨在充分观测模型的完成任务时出现的过程指令不遵循问题，以尽可能接近真实用户体验。 其中，CSR用来衡量CodingAgent遵循了多大比例的规则，ISR则用来衡量CodingAgent是否遵循了每条规则。 一个合格的CodingAgent，需要在完成任务的同时遵循： SystemPrompt中的全局约束(语言、格式、安全规则) UserQuery的多轮指令更新 SystemReminder提供的脚手架指令 Repository规范文件(如[CLAUDE.md]/[AGENTS.md])中的代码风格、提交规范 Skills文档的正确调用流程 Memory/Preferences中记录的用户偏好和项目状态 基于该评测集，我们针对现有的开源闭源模型进行了广泛的评估，发现了一些很有启发性的实验结果： 所有模型的Check-level准确率(CSR)可以达到80%+，但Instance-level成功率(ISR)只有10%-30%。换句话说，模型在单项约束上表现不错，但一旦要求“全部规则同时满足”，成功率就断崖式下跌。 绝大模型模型的指令遵循能力会随着轮次的变多逐渐下降。这印证了“过程合规”在长流程任务中的脆弱性。 不同交互轮次下ISR的变化 现阶段模型表现普遍未能达到生产级要求，过程合规仍是盲区： 从榜单数据来看，即便是表现最强劲的Claude4.5Opus，其Instance-level成功率（ISR）也仅为36.2%。这意味着，在近三分之二的任务中，模型虽然可能写出了能跑的代码，但在过程规范上依然存在违规。这一低分现状明确揭示了一个事实：CodingAgent的“过程规范遵循”尚未被业界充分关注和优化，目前的模型严重偏科于“结果正确”，而忽视了“过程正确”。 开源模型正在快速追赶闭源模型： 观察榜单可以发现，MiniMaxM2.1和DeepSeekV3.2的ISR分别达到了26.1%和26%，已经超过了公认强大的闭源模型Claude4.5Sonnet(22.8%)和Gemini3Pro(22.9%)，开源模型已经展现出了极强的竞争力。 03 未来的研究方向 我们认为，下一代CodingAgent的训练，需要引入ProcessSupervision(过程监督)： 细粒度的过程监督：不只监督模型的“测试通过”，还要监督模型“遵循命名规范”、“正确使用Skills”、“没有泄露System信息”等； 层级化的指令遵循：在训练数据中标注指令冲突场景，让模型学会在冲突情况下如何遵从指令层次的优先级行动； 可验证的Checklist：把“指令遵循”从模糊的整体印象，拆解成可自动化检查的原子约束，既能用于评估，也能用于RL信号构建。 CodingAgent的能力边界，正在从“能否写出能跑的代码”，转向“能否在复杂约束下协作式地完成任务”。这也映产品哲学的深层转变：Agent不是要替代人类开发者，而是要成为懂规矩、守纪律的团队成员。 因此，过程规范（ProcessSpecification）才是CodingAgent进化的核心命题。 当我们开始关注过程而非仅仅结果，当我们让评估体系能够捕捉“违规但成功”的危险模式，CodingAgent才能真正从Demo走向生产环境。 OctoCodingBench是一次基础设施层面的尝试，我们期待与社区一起，沿着这个方向继续向前推进。 $MINIMAX-WP(00100)$