鱼在水的心里抵
01-14
组织效率和技术变现路径非常清晰。这种极高的确定性在现在的环境下太难得了
$MINIMAX-WP(00100)$
@ME調研:
MiniMax 开源新评测集:定义Coding Agent 的生产级标准
免责声明:上述内容仅代表发帖人个人观点,不构成本平台的任何投资建议。
分享至
微信
复制链接
精彩评论
我们需要你的真知灼见来填补这片空白
打开APP,发表看法
APP内打开
发表看法
1
{"i18n":{"language":"zh_CN"},"detailType":1,"isChannel":false,"data":{"magic":2,"id":521666566116744,"tweetId":"521666566116744","gmtCreate":1768377156693,"gmtModify":1768377862684,"author":{"id":3557141636292900,"idStr":"3557141636292900","authorId":3557141636292900,"authorIdStr":"3557141636292900","name":"鱼在水的心里抵","avatar":"https://static.tigerbbs.com/1c448006ab47a170c3a3edf2bba4649f","vip":1,"userType":1,"introduction":"","boolIsFan":false,"boolIsHead":false,"crmLevel":1,"crmLevelSwitch":0,"individualDisplayBadges":[],"fanSize":0,"starInvestorFlag":false},"themes":[],"images":[],"coverImages":[],"title":"","html":"<html><head></head><body>组织效率和技术变现路径非常清晰。这种极高的确定性在现在的环境下太难得了<a target=\"_blank\" href=\"https://laohu8.com/S/00100\">$MINIMAX-WP(00100)$ </a>\n<br></body></html>","htmlText":"<html><head></head><body>组织效率和技术变现路径非常清晰。这种极高的确定性在现在的环境下太难得了<a target=\"_blank\" href=\"https://laohu8.com/S/00100\">$MINIMAX-WP(00100)$ </a>\n<br></body></html>","text":"组织效率和技术变现路径非常清晰。这种极高的确定性在现在的环境下太难得了$MINIMAX-WP(00100)$","highlighted":1,"essential":1,"paper":1,"likeSize":1,"commentSize":0,"repostSize":0,"favoriteSize":0,"link":"https://laohu8.com/post/521666566116744","repostId":521646947549944,"repostType":1,"repost":{"magic":2,"id":521646947549944,"tweetId":"521646947549944","gmtCreate":1768372298167,"gmtModify":1768372827745,"author":{"id":4090740655034770,"idStr":"4090740655034770","authorId":4090740655034770,"authorIdStr":"4090740655034770","name":"ME調研","avatar":"https://static.tigerbbs.com/2482ed1743c03e69f9f03f89ae480fbd","vip":1,"userType":1,"introduction":"","boolIsFan":false,"boolIsHead":false,"crmLevel":1,"crmLevelSwitch":0,"individualDisplayBadges":[],"fanSize":1,"starInvestorFlag":false},"themes":[],"images":[{"img":"https://static.tigerbbs.com/9df83ecf04267b7be150f33532adbec6","width":"1080","height":"365"}],"coverImages":[{"img":"https://static.tigerbbs.com/9df83ecf04267b7be150f33532adbec6","width":"1080","height":"365"}],"title":"MiniMax 开源新评测集:定义Coding Agent 的生产级标准","html":"<html><head></head><body><p>MiniMax正式开源首个面向CodingAgent的系统性评测集OctoCodingBench。评测结果显示,部分开源模型在过程合规指标上已快速逼近甚至超越部分闭源模型,反映出在Agent时代,“数据与评测范式”的重要性正在上升为新的竞争要素。</p>\n<p style=\"text-align: justify;\"><strong>MiniMax 官方发文:</strong></p>\n<p style=\"text-align: justify;\">在CodingAgent的实际应用中,我们观察到一个反复出现,却常被忽略的的现象:<strong>用户对Agent的不满,往往不是因为它“做不到”,而是因为它“做得不好”。</strong></p>\n<p style=\"text-align: justify;\">通过整理用户体感反馈,我们发现最高频的抱怨集中在:<strong>Agent不遵循明确给出的指令</strong>。比如用户在系统提示中明确要求“不要使用emoji”,Agent却在代码注释里加上笑脸;用户要求“先备份再修改”,Agent直接[rm-rf]删除文件;用户在项目文档中规定了命名规范,Agent却自行其是。</p>\n<p style=\"text-align: justify;\">这些问题的共同特征是:<strong>任务最终可能完成了,但过程违反了规范</strong>。用户要的不只是“能跑的代码”,还有“符合团队协作规范的代码”。</p>\n<p style=\"text-align: justify;\"><strong>01为什么CodingAgent 需要新的Bench</strong></p>\n<p style=\"text-align: justify;\">如果我们认为,遵循过程规范的CodingAgent,才能被放心地引入真实的软件工程流程中。那么目前主流CodeAgent的评估体系就出现了明显的盲区。随着ClaudeCode、Codex、Cursor、Windsurf等Agent产品的普及,社区正在形成一套<strong>面向Agent的仓库协议体系。</strong>项目不再只是一堆代码,同时也包含了多层次协作模式的说明:</p>\n<p style=\"text-align: justify;\"><strong>[CLAUDE.md]/[AGENTS.md]</strong>:告诉Agent“这个项目怎么玩”——命名约定、测试流程、禁用的危险操作等</p>\n<p style=\"text-align: justify;\"><strong>Skills</strong>:封装可复用的工作流(如“生成API文档”),Agent需要正确识别触发时机并按规范调用</p>\n<p style=\"text-align: justify;\"><strong>Memory</strong>:跨会话保存用户偏好和任务进度,Agent需要基于历史状态继续工作,而非从头开始</p>\n<p style=\"text-align: justify;\">这些机制的出现,本质上是在构建一个<strong>多层级的指令系统</strong>。举个例子,当用户说“帮我重构这个模块”时,Agent需要同时满足多个层级的约束:系统层面的安全规则(不能直接删代码)、当前用户的即时指令(重构到什么程度)、仓库中明确写下的工程规范,以及历史记忆中已经做出的决策(延续还是推翻)。更复杂的情况是,<strong>这些指令源之间可能冲突</strong>。用户临时说“这次就先不写测试了”,但[AGENTS.md]里明确要求“每次提交必须有测试覆盖”——Agent该听谁的?</p>\n<p style=\"text-align: justify;\">然而一个尴尬的问题是,当前的学术榜单,无论是SWE-benchverified,还是各类基于terminal环境的测试,其核心理念几乎都是<strong>Outcome-basedMetrics</strong>(结果导向指标):测试是否通过?Bug是否修复?这种结果导向的评估方式,根本无法刻画模型在沙盒环境下的输出过程,更不用说复杂现实场景的真实交互体验,最终导致了评估和真实使用场景的错位。</p>\n<p style=\"text-align: justify;\"><strong>02 OctoCodingBench:面向工程可靠性的过程评估</strong></p>\n<p style=\"text-align: justify;\">要解决这个问题,评估范式本身需要发生根本性转变——<strong>需要关注输出过程本身。</strong> <strong>基于这一动机,我们引入了OctoCodingBench,从Check-level准确率(CSR)、Instance-level成功率(ISR)两个维度来进行评估,旨在充分观测模型的完成任务时出现的过程指令不遵循问题,以尽可能接近真实用户体验。</strong></p>\n<p style=\"text-align: justify;\">其中,CSR用来衡量CodingAgent遵循了多大比例的规则,ISR则用来衡量CodingAgent是否遵循了每条规则。</p>\n<p></p>\n<p style=\"text-align: justify;\">一个合格的CodingAgent,需要在完成任务的同时遵循:</p>\n<p style=\"text-align: justify;\"><strong>SystemPrompt</strong>中的全局约束(语言、格式、安全规则)</p>\n<p style=\"text-align: justify;\"><strong>UserQuery</strong>的多轮指令更新</p>\n<p style=\"text-align: justify;\"><strong>SystemReminder</strong>提供的脚手架指令</p>\n<p style=\"text-align: justify;\"><strong>Repository规范文件</strong>(如[CLAUDE.md]/[AGENTS.md])中的代码风格、提交规范</p>\n<p style=\"text-align: justify;\"><strong>Skills文档</strong>的正确调用流程</p>\n<p style=\"text-align: justify;\"><strong>Memory/Preferences</strong>中记录的用户偏好和项目状态</p>\n<p style=\"text-align: justify;\">基于该评测集,我们针对现有的开源闭源模型进行了广泛的评估,发现了一些很有启发性的实验结果:</p>\n<p style=\"text-align: justify;\"><strong>所有模型的Check-level准确率(CSR)可以达到80%+,但Instance-level成功率(ISR)只有10%-30%</strong>。换句话说,模型在单项约束上表现不错,但一旦要求“全部规则同时满足”,成功率就断崖式下跌。</p>\n<p style=\"text-align: justify;\"><strong>绝大模型模型的指令遵循能力会随着轮次的变多逐渐下降。</strong>这印证了“过程合规”在长流程任务中的脆弱性。</p>\n<p></p>\n<p style=\"text-align: center;\">不同交互轮次下ISR的变化</p>\n<p style=\"text-align: justify;\"><strong>现阶段模型表现普遍未能达到生产级要求,过程合规仍是盲区:</strong> 从榜单数据来看,即便是表现最强劲的Claude4.5Opus,其Instance-level成功率(ISR)也仅为36.2%。这意味着,在近三分之二的任务中,模型虽然可能写出了能跑的代码,但在过程规范上依然存在违规。这一低分现状明确揭示了一个事实:<strong>CodingAgent的“过程规范遵循”尚未被业界充分关注和优化</strong>,目前的模型严重偏科于“结果正确”,而忽视了“过程正确”。</p>\n<p style=\"text-align: justify;\"><strong>开源模型正在快速追赶闭源模型:</strong> 观察榜单可以发现,MiniMaxM2.1和DeepSeekV3.2的ISR分别达到了26.1%和26%,已经超过了公认强大的闭源模型Claude4.5Sonnet(22.8%)和Gemini3Pro(22.9%),开源模型已经展现出了极强的竞争力。</p>\n<p class=\"t-img-caption\"><img src=\"https://static.tigerbbs.com/9df83ecf04267b7be150f33532adbec6\" tg-width=\"1080\" tg-height=\"365\"></p>\n<p style=\"text-align: justify;\"><strong>03 未来的研究方向</strong></p>\n<p style=\"text-align: justify;\">我们认为,下一代CodingAgent的训练,需要引入<strong>ProcessSupervision(过程监督):</strong></p>\n<p style=\"text-align: justify;\"><strong>细粒度的过程监督</strong>:不只监督模型的“测试通过”,还要监督模型“遵循命名规范”、“正确使用Skills”、“没有泄露System信息”等;</p>\n<p style=\"text-align: justify;\"><strong>层级化的指令遵循</strong>:在训练数据中标注指令冲突场景,让模型学会在冲突情况下如何遵从指令层次的优先级行动;</p>\n<p style=\"text-align: justify;\"><strong>可验证的Checklist</strong>:把“指令遵循”从模糊的整体印象,拆解成可自动化检查的原子约束,既能用于评估,也能用于RL信号构建。</p>\n<p style=\"text-align: justify;\">CodingAgent的能力边界,正在从“能否写出能跑的代码”,转向“能否在复杂约束下协作式地完成任务”。这也映产品哲学的深层转变:Agent不是要替代人类开发者,而是要成为懂规矩、守纪律的团队成员。</p>\n<p style=\"text-align: justify;\">因此,<strong>过程规范(ProcessSpecification)才是CodingAgent进化的核心命题</strong>。</p>\n<p style=\"text-align: justify;\">当我们开始关注过程而非仅仅结果,当我们让评估体系能够捕捉“违规但成功”的危险模式,CodingAgent才能真正从Demo走向生产环境。</p>\n<p style=\"text-align: justify;\"><strong>OctoCodingBench是一次基础设施层面的尝试,我们期待与社区一起,沿着这个方向继续向前推进。</strong> <a href=\"https://laohu8.com/S/00100\">$MINIMAX-WP(00100)$</a></p></body></html>","htmlText":"<html><head></head><body><p>MiniMax正式开源首个面向CodingAgent的系统性评测集OctoCodingBench。评测结果显示,部分开源模型在过程合规指标上已快速逼近甚至超越部分闭源模型,反映出在Agent时代,“数据与评测范式”的重要性正在上升为新的竞争要素。</p>\n<p style=\"text-align: justify;\"><strong>MiniMax 官方发文:</strong></p>\n<p style=\"text-align: justify;\">在CodingAgent的实际应用中,我们观察到一个反复出现,却常被忽略的的现象:<strong>用户对Agent的不满,往往不是因为它“做不到”,而是因为它“做得不好”。</strong></p>\n<p style=\"text-align: justify;\">通过整理用户体感反馈,我们发现最高频的抱怨集中在:<strong>Agent不遵循明确给出的指令</strong>。比如用户在系统提示中明确要求“不要使用emoji”,Agent却在代码注释里加上笑脸;用户要求“先备份再修改”,Agent直接[rm-rf]删除文件;用户在项目文档中规定了命名规范,Agent却自行其是。</p>\n<p style=\"text-align: justify;\">这些问题的共同特征是:<strong>任务最终可能完成了,但过程违反了规范</strong>。用户要的不只是“能跑的代码”,还有“符合团队协作规范的代码”。</p>\n<p style=\"text-align: justify;\"><strong>01为什么CodingAgent 需要新的Bench</strong></p>\n<p style=\"text-align: justify;\">如果我们认为,遵循过程规范的CodingAgent,才能被放心地引入真实的软件工程流程中。那么目前主流CodeAgent的评估体系就出现了明显的盲区。随着ClaudeCode、Codex、Cursor、Windsurf等Agent产品的普及,社区正在形成一套<strong>面向Agent的仓库协议体系。</strong>项目不再只是一堆代码,同时也包含了多层次协作模式的说明:</p>\n<p style=\"text-align: justify;\"><strong>[CLAUDE.md]/[AGENTS.md]</strong>:告诉Agent“这个项目怎么玩”——命名约定、测试流程、禁用的危险操作等</p>\n<p style=\"text-align: justify;\"><strong>Skills</strong>:封装可复用的工作流(如“生成API文档”),Agent需要正确识别触发时机并按规范调用</p>\n<p style=\"text-align: justify;\"><strong>Memory</strong>:跨会话保存用户偏好和任务进度,Agent需要基于历史状态继续工作,而非从头开始</p>\n<p style=\"text-align: justify;\">这些机制的出现,本质上是在构建一个<strong>多层级的指令系统</strong>。举个例子,当用户说“帮我重构这个模块”时,Agent需要同时满足多个层级的约束:系统层面的安全规则(不能直接删代码)、当前用户的即时指令(重构到什么程度)、仓库中明确写下的工程规范,以及历史记忆中已经做出的决策(延续还是推翻)。更复杂的情况是,<strong>这些指令源之间可能冲突</strong>。用户临时说“这次就先不写测试了”,但[AGENTS.md]里明确要求“每次提交必须有测试覆盖”——Agent该听谁的?</p>\n<p style=\"text-align: justify;\">然而一个尴尬的问题是,当前的学术榜单,无论是SWE-benchverified,还是各类基于terminal环境的测试,其核心理念几乎都是<strong>Outcome-basedMetrics</strong>(结果导向指标):测试是否通过?Bug是否修复?这种结果导向的评估方式,根本无法刻画模型在沙盒环境下的输出过程,更不用说复杂现实场景的真实交互体验,最终导致了评估和真实使用场景的错位。</p>\n<p style=\"text-align: justify;\"><strong>02 OctoCodingBench:面向工程可靠性的过程评估</strong></p>\n<p style=\"text-align: justify;\">要解决这个问题,评估范式本身需要发生根本性转变——<strong>需要关注输出过程本身。</strong> <strong>基于这一动机,我们引入了OctoCodingBench,从Check-level准确率(CSR)、Instance-level成功率(ISR)两个维度来进行评估,旨在充分观测模型的完成任务时出现的过程指令不遵循问题,以尽可能接近真实用户体验。</strong></p>\n<p style=\"text-align: justify;\">其中,CSR用来衡量CodingAgent遵循了多大比例的规则,ISR则用来衡量CodingAgent是否遵循了每条规则。</p>\n<p></p>\n<p style=\"text-align: justify;\">一个合格的CodingAgent,需要在完成任务的同时遵循:</p>\n<p style=\"text-align: justify;\"><strong>SystemPrompt</strong>中的全局约束(语言、格式、安全规则)</p>\n<p style=\"text-align: justify;\"><strong>UserQuery</strong>的多轮指令更新</p>\n<p style=\"text-align: justify;\"><strong>SystemReminder</strong>提供的脚手架指令</p>\n<p style=\"text-align: justify;\"><strong>Repository规范文件</strong>(如[CLAUDE.md]/[AGENTS.md])中的代码风格、提交规范</p>\n<p style=\"text-align: justify;\"><strong>Skills文档</strong>的正确调用流程</p>\n<p style=\"text-align: justify;\"><strong>Memory/Preferences</strong>中记录的用户偏好和项目状态</p>\n<p style=\"text-align: justify;\">基于该评测集,我们针对现有的开源闭源模型进行了广泛的评估,发现了一些很有启发性的实验结果:</p>\n<p style=\"text-align: justify;\"><strong>所有模型的Check-level准确率(CSR)可以达到80%+,但Instance-level成功率(ISR)只有10%-30%</strong>。换句话说,模型在单项约束上表现不错,但一旦要求“全部规则同时满足”,成功率就断崖式下跌。</p>\n<p style=\"text-align: justify;\"><strong>绝大模型模型的指令遵循能力会随着轮次的变多逐渐下降。</strong>这印证了“过程合规”在长流程任务中的脆弱性。</p>\n<p></p>\n<p style=\"text-align: center;\">不同交互轮次下ISR的变化</p>\n<p style=\"text-align: justify;\"><strong>现阶段模型表现普遍未能达到生产级要求,过程合规仍是盲区:</strong> 从榜单数据来看,即便是表现最强劲的Claude4.5Opus,其Instance-level成功率(ISR)也仅为36.2%。这意味着,在近三分之二的任务中,模型虽然可能写出了能跑的代码,但在过程规范上依然存在违规。这一低分现状明确揭示了一个事实:<strong>CodingAgent的“过程规范遵循”尚未被业界充分关注和优化</strong>,目前的模型严重偏科于“结果正确”,而忽视了“过程正确”。</p>\n<p style=\"text-align: justify;\"><strong>开源模型正在快速追赶闭源模型:</strong> 观察榜单可以发现,MiniMaxM2.1和DeepSeekV3.2的ISR分别达到了26.1%和26%,已经超过了公认强大的闭源模型Claude4.5Sonnet(22.8%)和Gemini3Pro(22.9%),开源模型已经展现出了极强的竞争力。</p>\n<p class=\"t-img-caption\"><img src=\"https://static.tigerbbs.com/9df83ecf04267b7be150f33532adbec6\" tg-width=\"1080\" tg-height=\"365\"></p>\n<p style=\"text-align: justify;\"><strong>03 未来的研究方向</strong></p>\n<p style=\"text-align: justify;\">我们认为,下一代CodingAgent的训练,需要引入<strong>ProcessSupervision(过程监督):</strong></p>\n<p style=\"text-align: justify;\"><strong>细粒度的过程监督</strong>:不只监督模型的“测试通过”,还要监督模型“遵循命名规范”、“正确使用Skills”、“没有泄露System信息”等;</p>\n<p style=\"text-align: justify;\"><strong>层级化的指令遵循</strong>:在训练数据中标注指令冲突场景,让模型学会在冲突情况下如何遵从指令层次的优先级行动;</p>\n<p style=\"text-align: justify;\"><strong>可验证的Checklist</strong>:把“指令遵循”从模糊的整体印象,拆解成可自动化检查的原子约束,既能用于评估,也能用于RL信号构建。</p>\n<p style=\"text-align: justify;\">CodingAgent的能力边界,正在从“能否写出能跑的代码”,转向“能否在复杂约束下协作式地完成任务”。这也映产品哲学的深层转变:Agent不是要替代人类开发者,而是要成为懂规矩、守纪律的团队成员。</p>\n<p style=\"text-align: justify;\">因此,<strong>过程规范(ProcessSpecification)才是CodingAgent进化的核心命题</strong>。</p>\n<p style=\"text-align: justify;\">当我们开始关注过程而非仅仅结果,当我们让评估体系能够捕捉“违规但成功”的危险模式,CodingAgent才能真正从Demo走向生产环境。</p>\n<p style=\"text-align: justify;\"><strong>OctoCodingBench是一次基础设施层面的尝试,我们期待与社区一起,沿着这个方向继续向前推进。</strong> <a href=\"https://laohu8.com/S/00100\">$MINIMAX-WP(00100)$</a></p></body></html>","text":"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)$","highlighted":1,"essential":1,"paper":2,"link":"https://laohu8.com/post/521646947549944","repostId":0,"isVote":1,"tweetType":1,"commentLimit":10,"symbols":["00100"],"verified":2,"subType":0,"readableState":1,"langContent":"CN","currentLanguage":"CN","warmUpFlag":false,"orderFlag":false,"shareable":true,"causeOfNotShareable":"","featuresForAnalytics":[],"commentAndTweetFlag":false,"andRepostAutoSelectedFlag":false,"upFlag":false,"length":4390,"optionInvolvedFlag":false,"xxTargetLangEnum":"ZH_CN"},"isVote":1,"tweetType":1,"viewCount":653,"commentLimit":10,"likeStatus":false,"favoriteStatus":false,"reportStatus":false,"symbols":["00100"],"verified":2,"subType":0,"readableState":1,"langContent":"CN","currentLanguage":"CN","warmUpFlag":false,"orderFlag":false,"shareable":true,"causeOfNotShareable":"","featuresForAnalytics":[],"commentAndTweetFlag":false,"andRepostAutoSelectedFlag":false,"upFlag":false,"length":88,"optionInvolvedFlag":false,"xxTargetLangEnum":"ZH_CN"},"commentList":[],"isCommentEnd":true,"isTiger":false,"isWeiXinMini":false,"url":"/m/post/521666566116744"}
精彩评论