1. 先把这个新闻拆开Grok 4.7 的“第三名”是怎么来的1.1 事件还原谁在说说了什么这几天 AI 圈被一条消息顶上了热搜马斯克公开表示xAI 的 Grok 4.7 在智能体编码agentic coding领域已经做到行业第三。我第一次看到这条消息时的反应不是跟着转帖喊“厉害了”而是先确认一个事——这个“第三”到底是哪来的口径。这里面有个非常容易被忽略的细节这句话出自 xAI 创始人之口属于公司自评不是某个第三方评测机构发布的正式榜单。自评和独立测评之间天然隔着一层信息差。老板可以说“我们仅次于前两名”但作为普通开发者和研究者我们真正要关心的是排名背后挂靠的是哪套基准、用了什么测试集、运行了多少任务、结果方差多大。这几点不搞清楚“第三”就只是一个营销数字。我把公开渠道能看到的材料捋了一遍对比对象基本锁定在 Anthropic、OpenAI、Google 这几家的旗舰模型上判断维度涉及真实仓库任务的成功率、多轮自主修复能力、工具调用稳定性这些硬指标。也就是说这里说的“智能体编码”和我们平时用 API 补几行代码完全是两码事。搞清楚这一点才算真正读懂了这条热搜。1.2 “智能体编码”和传统“写代码”的差别在哪先把概念对齐。传统意义上的 AI 编程是“人给模型一段上下文模型吐出代码片段”比如自动补全、单文件生成、代码解释。它的边界很清晰模型不负责跑环境、不负责看报错、不负责改完后再验证。这个模式里的“质检员”始终是人模型的职责止步于生产文本。智能体编码则完全换了一种玩法。它要求模型像一名初级工程师那样“驻场干活”拿到一个 GitHub issue自己去读仓库结构定位相关文件设计修改方案改完代码后主动执行测试看到失败再回头修直到测试通过。整个过程是一个“计划—执行—观察—修正”的闭环模型需要自己调用命令、读取输出、管理多个文件的状态。拿生活类比就是传统补全像你口述菜谱让助手记笔记智能体编码则是让助手自己进厨房、开火、炒菜、尝咸淡、翻车了自己重炒。难度完全不是一个量级。这也是为什么各家都把智能体编码当成旗舰模型能力的“试金石”——它兼顾长上下文、复杂推理和真实工具调用几乎没法靠背题或堆参数糊弄过去。1.3 为什么这个排名值得关注智能体编码不是一个小众玩法。它直接指向软件研发的自动化从修 bug、写单测、补文档到整个微服务的改造都能看到它的身影。企业选模型时问的第一句话早就不是“你懂多少语法”而是“你能不能自己把活干完”。这个转变在过去两年里特别明显我接触到的一些技术团队选型文档里已经把“agent 任务通过率”单独列成一栏权重比传统代码生成还高。所以当有消息说某家模型在这个领域进入前三市场的第一反应就是这家公司的模型已经从“聊天工具”升级成了“能接活的数字员工”。对 xAI 来说如果 Grok 4.7 真能稳住这个位置它在企业级市场的议价能力、人才吸引力、生态号召力都会跟着涨。这才是这条消息真正值钱的地方。当然值钱不等于已成定局后面的验证才是关键。2. 智能体编码到底考什么拆开主流评测基准2.1 从“会写”到“会干活”差在四个能力根据我这几年跑评测的体会一个能打的智能体编码模型至少要过四道关。首先是定位能力面对一个几千文件的仓库和一个含糊的 issue 描述模型要能准确找到改动点。这个环节就淘汰掉一大批“只会刷题”的模型因为现实中没有人会告诉你“改第 137 行”你得自己顺着调用关系摸过去。然后是规划能力找到文件之后怎么改才不动摇其他模块哪些改动可以并行哪些必须串行这考验的是对系统结构的理解。很多模型在这一步会犯“头痛医头”的毛病把报错的那一行改了却不管相邻模块的依赖关系结果修好一个 bug 引出三个新 bug。执行能力排在第三模型要能正确调用终端命令、包管理器、测试框架而不是只会输出代码块让人手动复制。最后是自愈能力测试挂了之后能不能根据报错信息定位问题、修正方案、再次验证。四道关环环相扣任何一个环节薄弱整体成功率都会断崖式下跌。实践中很多模型前两关看着还行一到自愈环节就原地打转耗时翻倍成功率还上不来。2.2 主流基准都在测什么目前各家公司引用最多的评测基准大致可以分成三类。第一类是真实 GitHub issue 修复类代表是 SWE-bench Verified。它从热门开源仓库里挑出真实 bug 报告要求模型修改代码让隐藏测试通过。因为是真实历史 issue考察的是端到端的工程能力而不是“标准答案背诵”。第二类是终端任务类代表是 Terminal-Bench。它把模型丢进一个虚拟 Linux 环境让它完成真实运维或开发任务比如配置服务、编写脚本、排查日志直接考验模型与真实环境的交互能力。第三类是编辑与多语言类比如 Aider 的多语言 polyglot 榜单考察模型在多种编程语言里的编辑准确度。还有 LiveCodeBench 这类“防泄露”比赛题专门用来暴击刷题背答案的模型。我把常用的几个基准的考察重点整理成一张表基准名称考察重点任务形态常见误区SWE-bench Verified端到端修 bug 能力真实 GitHub issue只看 pass1忽略修复时长Terminal-Bench真实终端环境交互虚拟 Linux 任务以为接近自然语言对话Aider polyglot多语言编辑准确度代码编辑测试把编辑题当生成题LiveCodeBench抗泄露、新题泛化实时新出的竞赛题拿旧题集硬套2.3 为什么大厂集体“卷”这个赛道道理很简单谁先在智能体编码上做到“成本可接受的可用”谁就能吃到软件行业自动化最大的红利。全球有数以百万计的工程师在做重复性增删改查哪怕只自动化其中三成也是一个巨大的市场想象空间。更关键的是智能体编码的能力上限恰恰反映了模型在长上下文理解、工具调用、多步推理上的综合上限。这几个指标几乎可以平移预测它在其他 agent 场景里的表现比如数据分析、文档处理、自动化测试。所以你看各家发布新模型时都喜欢拿 SWE-bench 这类榜单当封面数据不是没有原因的。它已经事实上成了“旗舰模型能力”的代名词。这也是为什么“Grok 4.7 位列第三”这条消息能瞬间引爆关注——大家真正读出来的潜台词是xAI 的综合 agent 能力已经进入第一梯队。这个判断如果成立接下来一个季度的企业级模型选型格局很可能会被重新洗牌。3. 横向对比第三名的含金量与看点3.1 第一梯队目前的主力选手按公开评测榜单和社区实测的综合印象智能体编码的头部位置这几年一直在 Anthropic 和 OpenAI 之间来回争夺。Anthropic 的 Claude 系列在“长任务自主执行”上口碑积累很深很多开发者社区的独立评测里它经常是默认基线。OpenAI 这边的 Codex 和 o 系列则胜在工具生态闭环完整从代码补全到 Agent 模式一条龙短期内很难被简单弯道超车。Google 的 Gemini 系列也在快速追赶尤其在多模态理解和超大上下文上有自己的优势。xAI 要在这堆老手里挤进前三意味着它至少要压过其中一家头部产品。如果“第三”的消息成立那对手大概率是 Google 或 OpenAI、Anthropic 中的某一档位。这里需要提醒一句不同榜单的排名经常“打架”因为测试集、运行轮数、超参都不一样所以这个“第三”更准确的说法是“在某套评测口径下的第三”。3.2 Grok 4.7 的相对优势与短板基于公开信息推测从公开信息看Grok 4.7 这一代按 xAI 历次大版本迭代的常见节奏推断应该是在三个方向上做了重点加强一是上下文窗口与长仓库理解二是工具调用的稳定性三是多轮任务中的状态记忆。这三个方向恰好都是智能体编码的命门。一个能稳定读完十万行代码、记住自己改过哪些地方、连续执行十几步不出错的模型即便推理深度不是最顶尖工程成功率也会很可观。长上下文对 agent 来说尤其致命早期很多模型前面改得挺好改到第三个文件就把第一个文件的改动忘了这种“失忆”直接让任务功亏一篑。不过短板同样明显。首先是生态xAI 在企业级 IDE 插件、内部代码库索引、CI/CD 集成方面比 Anthropic 和 OpenAI 起步晚工具链的成熟度还需要时间补。其次是成本与速度高阶 agent 任务要跑很多轮调用如果单轮延迟和价格下不来企业实际落地时会有压力。最后是社区信任相比 Claude 在开发者圈子里多年攒下的口碑Grok 系列的“程序员友好度”还需要更多独立评测来背书。这些都是比“排名第三”更值得冷静观察的地方。模型强不等于好用好用也不等于好落地中间隔着整整一条工具链的距离。3.3 这条消息对行业格局的实质影响我的判断是这条消息最重要的意义不在于“第三”本身而在于它把 xAI 正式摆上了“智能体三强”的牌桌。过去聊 agentic coding大家默认是 Claude 和 Codex 的二人转现在多了一个变量对使用方是好事——竞争会压价、会逼各家把文档和稳定性做好。对开发者来说这意味着选型时多了一个真正值得跑一轮评测的候选而不是凑数的备胎。从 xAI 的战略动作看我一直观察到一个信号它在开源权重模型和 API 价格上的打法越来越激进直接冲的就是“开发者心智”这个入口。如果能借“智能体编码前三”这个标签先把一批独立开发者和中型团队圈进来后续再向企业级扩展路径是通的。至于是不是真的稳坐第三我建议以未来两个季度的独立第三方评测为准。毕竟发布时的宣传和长期的口碑从来都是两回事。4. 如果你也想亲测一套可落地的智能体编程评估方案4.1 准备工作环境、数据、预算看完上面的分析肯定有朋友想自己跑一轮评测验证一下“第三”的真实成色。我自己跑过的评估不下十轮踩过的坑可以凑一本小册子。先说准备工作。第一步是准备一个干净的隔离环境我推荐用 Docker 容器把评估脚本、依赖、目标仓库全部装在里面跑完直接销毁避免污染宿主机器。别用自己日常开发的机器跑agent 会在里面乱装东西、乱改配置翻车是家常便饭。第二步是选数据集。如果只想快速验证SWE-bench Verified 的子集是最省事的选 50 到 100 个 issue 就够看出趋势不用一次性把全部 500 个跑完省时省力。第三步是算预算。按我的经验一个复杂 issue 的 agent 任务中间可能要调用模型十几轮甚至几十轮单任务成本很容易到一两美元以上。跑 100 个任务的完整评测烧掉几百美元很正常。一定要提前设好 API 上限别让账单失控。我见过不少团队兴致勃勃开跑跑到一半发现预算超了最后拿着残缺数据硬下结论这比不跑更坑。4.2 关键参数与运行细节我习惯用官方或社区维护的 bench harness 来跑不要自己手搓评测逻辑否则很容易引入不公平的变量。这里给一个示意性的流程具体命令以你用的 harness 官方文档为准# 示意克隆评测 harness 并准备环境 git clone https://github.com/swe-bench/swe-bench.git cd swe-bench python -m venv .venv source .venv/bin/activate pip install -e . # 示意跑一个小规模验证参数以官方文档为准 python -m swebench.run_evaluation \ --dataset_name principle/swe-bench-verified \ --split test \ --max_workers 4 \ --max_issue_count 50 \ --run_id my_grok_eval跑的时候有几个参数特别关键。一是并发数max_workers我建议从 4 开始调太小跑得慢太大容易触发 API 限流报错之后你还得花时间区分“是模型不行还是限流造成的”。二是超时设置一个任务超过 20 到 30 分钟就该判失败别让它无限烧 token 空转。三是随机种子影响模型抽样结果固定种子才能保证前后对比公平。我自己的习惯是同一模型同一数据集至少跑两遍对比结果的中位数而不是单次最好成绩。4.3 结果解读别被总分骗了评分出来之后重点看三件事。第一是 pass1也就是一次启动就成功的比例这代表模型开箱即用的真实水平。第二是“修复路径有效率”我见过不少模型靠反复重试把总分刷上来的情况掩盖了它一步到位能力弱的事实所以要单独看首轮成功率。第三是成本与耗时同样达到 40% 通过率一家花 200 美元、另一家花 500 美元落地选型时高下立判。现在很多供应商支持设置“最大尝试轮数”我建议分别跑 10 轮和 3 轮两个配置看看分数的衰减曲线这能直观看出模型是“一次想清楚”还是“瞎猫碰死耗子”。还有一个容易踩的坑别拿别人榜上的数字跟你本地跑的数字直接比。评测环境、模型版本、天气都可能影响结果。正确做法是同一个测试集、同一个环境、同一套参数把候选模型轮流各跑一遍横向对比。单项分数说明不了问题分布和稳定性才是真相。我们选型是为了在真实仓库里干活不是为了在榜单截图里争高低。5. 常见问题与避坑清单5.1 关于“第三名”的几个常见误解这几天我看到评论区有不少误解挑几个典型的说一下。首要误解是“第三 综合能力第三”。实际上智能体编码只是 AI 能力的一个切片推理、数学、创意写作、多模态各有各的榜单。一家模型可能在编码 agent 上排第三在纯数学上排第五在长文档理解上排第二都是正常的。选型要看你自己的场景不要被单一标签带节奏。另一个误解是“创始人说了就是官方定论”。商业公司创始人公开发言的背后有品牌诉求真实能力要靠第三方评测和你的实际任务验证。我不是说这句话一定不准而是说它需要被验证。这个验证成本并不高花几百美元跑一轮自己的评测比转发一百条热评都更有价值。还有人说“排名第三说明可以替代初级工程师了”这个跳跃太大了。即便是头部模型在真实业务仓库里的完全自主成功率通常也达不到“无需人看管”的程度现阶段更靠谱的定位是“能大幅提效的结对助手”而不是“马上就能裁员的替身”。5.2 实操中的典型问题与排查方法我把评测过程中最常遇到的几个问题和排查思路整理成一张速查表方便大家收藏备用。现象可能原因排查方法大量任务超时agent 陷入重复尝试调大单步超时但限制总步数查看日志里的循环模式任务失败但报错信息为空环境依赖安装不完整检查容器初始镜像提前跑仓库自带测试验证环境分数忽高忽低随机性与并发不稳定固定随机种子重复跑 2 到 3 次取中位数成本远超预期单任务轮数失控设置最大步数上限关闭不必要的长输出日志结果和官方榜对不上数据集版本或预处理不同确认 repo 版本、基础镜像、模型版本完全一致这套排查方法不仅对 Grok 适用对任何模型的 agent 评测都成立。我特别想强调最后一条很多人跑完发现分数比官方低第一反应是模型被高估了结果一查发现是基础 Docker 镜像里少了几个系统依赖导致大量任务死在同一阶段。这种系统性偏差不解决对比就毫无意义。5.3 结合公开资料我对“智能体编码选型”的几点经验最后聊聊我自己的实操倾向。如果团队想快速试水 agentic coding我建议不要只盯一家。先把 Claude、OpenAI 的旗舰和 Grok 4.7 都放到你自己的 3 到 5 个真实仓库任务里跑一遍看谁在你的代码风格、依赖体系、部署流程下最顺。公开榜单是起点不是终点。另外建议关注模型供应商的“评测污染”问题。热门基准数据集如果长期公开模型厂商可能通过训练数据悄悄“看过答案”。所以我每次选型都尽量带上几个自己团队的历史 issue 做盲测这部分数据是外部看不到的测出来的结果才最接近真实水平。再有一个细节优先选支持自定义工具接口的模型因为真实的研发环境里agent 要接的是你们自己的 CI、代码评审、上线流水线工具链适配能力比单点智商更值钱。我自己踩过最大的坑是早期只看一个榜单总分就定了选型结果在真实仓库里因为模型不熟悉内部脚手架首轮成功率直接掉了一半。从那以后我给自己定了个规矩任何宣传里的“排名”“领先”“第一梯队”一律先翻译成“某基准某版本某条件下的表现”再决定要不要信。这句习惯放到 Grok 4.7 的“第三”上也同样适用。消息本身值得高兴但真正能让团队受益的还是自己亲手跑出来的那份数据。 1. 先把这个新闻拆开Grok 4.7 的“第三名”是怎么来的1.1 事件还原谁在说说了什么这几天 AI 圈被一条消息顶上了热搜马斯克公开表示xAI 的 Grok 4.7 在智能体编码agentic coding领域已经做到行业第三。我第一次看到这条消息时的反应不是跟着转帖喊“厉害了”而是先确认一个事——这个“第三”到底是哪来的口径。这里面有个非常容易被忽略的细节这句话出自 xAI 创始人之口属于公司自评不是某个第三方评测机构发布的正式榜单。自评和独立测评之间天然隔着一层信息差。老板可以说“我们仅次于前两名”但作为普通开发者和研究者我们真正要关心的是排名背后挂靠的是哪套基准、用了什么测试集、运行了多少任务、结果方差多大。这几点不搞清楚“第三”就只是一个营销数字。我把公开渠道能看到的材料捋了一遍对比对象基本锁定在 Anthropic、OpenAI、Google 这几家的旗舰模型上判断维度涉及真实仓库任务的成功率、多轮自主修复能力、工具调用稳定性这些硬指标。也就是说这里说的“智能体编码”和我们平时用 API 补几行代码完全是两码事。搞清楚这一点才算真正读懂了这条热搜。1.2 “智能体编码”和传统“写代码”的差别在哪先把概念对齐。传统意义上的 AI 编程是“人给模型一段上下文模型吐出代码片段”比如自动补全、单文件生成、代码解释。它的边界很清晰模型不负责跑环境、不负责看报错、不负责改完后再验证。这个模式里的“质检员”始终是人模型的职责止步于生产文本。智能体编码则完全换了一种玩法。它要求模型像一名初级工程师那样“驻场干活”拿到一个 GitHub issue自己去读仓库结构定位相关文件设计修改方案改完代码后主动执行测试看到失败再回头修直到测试通过。整个过程是一个“计划—执行—观察—修正”的闭环模型需要自己调用命令、读取输出、管理多个文件的状态。拿生活类比就是传统补全像你口述菜谱让助手记笔记智能体编码则是让助手自己进厨房、开火、炒菜、尝咸淡、翻车了自己重炒。难度完全不是一个量级。这也是为什么各家都把智能体编码当成旗舰模型能力的“试金石”——它兼顾长上下文、复杂推理和真实工具调用几乎没法靠背题或堆参数糊弄过去。1.3 为什么这个排名值得关注智能体编码不是一个小众玩法。它直接指向软件研发的自动化从修 bug、写单测、补文档到整个微服务的改造都能看到它的身影。企业选模型时问的第一句话早就不是“你懂多少语法”而是“你能不能自己把活干完”。这个转变在过去两年里特别明显我接触到的一些技术团队选型文档里已经把“agent 任务通过率”单独列成一栏权重比传统代码生成还高。所以当有消息说某家模型在这个领域进入前三市场的第一反应就是这家公司的模型已经从“聊天工具”升级成了“能接活的数字员工”。对 xAI 来说如果 Grok 4.7 真能稳住这个位置它在企业级市场的议价能力、人才吸引力、生态号召力都会跟着涨。这才是这条消息真正值钱的地方。当然值钱不等于已成定局后面的验证才是关键。2. 智能体编码到底考什么拆开主流评测基准2.1 从“会写”到“会干活”差在四个能力根据我这几年跑评测的体会一个能打的智能体编码模型至少要过四道关。首先是定位能力面对一个几千文件的仓库和一个含糊的 issue 描述模型要能准确找到改动点。这个环节就淘汰掉一大批“只会刷题”的模型因为现实中没有人会告诉你“改第 137 行”你得自己顺着调用关系摸过去。然后是规划能力找到文件之后怎么改才不动摇其他模块哪些改动可以并行哪些必须串行这考验的是对系统结构的理解。很多模型在这一步会犯“头痛医头”的毛病把报错的那一行改了却不管相邻模块的依赖关系结果修好一个 bug 引出三个新 bug。执行能力排在第三模型要能正确调用终端命令、包管理器、测试框架而不是只会输出代码块让人手动复制。最后是自愈能力测试挂了之后能不能根据报错信息定位问题、修正方案、再次验证。四道关环环相扣任何一个环节薄弱整体成功率都会断崖式下跌。实践中很多模型前两关看着还行一到自愈环节就原地打转耗时翻倍成功率还上不来。2.2 主流基准都在测什么目前各家公司引用最多的评测基准大致可以分成三类。第一类是真实 GitHub issue 修复类代表是 SWE-bench Verified。它从热门开源仓库里挑出真实 bug 报告要求模型修改代码让隐藏测试通过。因为是真实历史 issue考察的是端到端的工程能力而不是“标准答案背诵”。第二类是终端任务类代表是 Terminal-Bench。它把模型丢进一个虚拟 Linux 环境让它完成真实运维或开发任务比如配置服务、编写脚本、排查日志直接考验模型与真实环境的交互能力。第三类是编辑与多语言类比如 Aider 的多语言 polyglot 榜单考察模型在多种编程语言里的编辑准确度。还有 LiveCodeBench 这类“防泄露”比赛题专门用来暴击刷题背答案的模型。我把常用的几个基准的考察重点整理成一张表基准名称考察重点任务形态常见误区SWE-bench Verified端到端修 bug 能力真实 GitHub issue只看 pass1忽略修复时长Terminal-Bench真实终端环境交互虚拟 Linux 任务以为接近自然语言对话Aider polyglot多语言编辑准确度代码编辑测试把编辑题当生成题LiveCodeBench抗泄露、新题泛化实时新出的竞赛题拿旧题集硬套2.3 为什么大厂集体“卷”这个赛道道理很简单谁先在智能体编码上做到“成本可接受的可用”谁就能吃到软件行业自动化最大的红利。全球有数以百万计的工程师在做重复性增删改查哪怕只自动化其中三成也是一个巨大的市场想象空间。更关键的是智能体编码的能力上限恰恰反映了模型在长上下文理解、工具调用、多步推理上的综合上限。这几个指标几乎可以平移预测它在其他 agent 场景里的表现比如数据分析、文档处理、自动化测试。所以你看各家发布新模型时都喜欢拿 SWE-bench 这类榜单当封面数据不是没有原因的。它已经事实上成了“旗舰模型能力”的代名词。这也是为什么“Grok 4.7 位列第三”这条消息能瞬间引爆关注——大家真正读出来的潜台词是xAI 的综合 agent 能力已经进入第一梯队。这个判断如果成立接下来一个季度的企业级模型选型格局很可能会被重新洗牌。3. 横向对比第三名的含金量与看点3.1 第一梯队目前的主力选手按公开评测榜单和社区实测的综合印象智能体编码的头部位置这几年一直在 Anthropic 和 OpenAI 之间来回争夺。Anthropic 的 Claude 系列在“长任务自主执行”上口碑积累很深很多开发者社区的独立评测里它经常是默认基线。OpenAI 这边的 Codex 和 o 系列则胜在工具生态闭环完整从代码补全到 Agent 模式一条龙短期内很难被简单弯道超车。Google 的 Gemini 系列也在快速追赶尤其在多模态理解和超大上下文上有自己的优势。xAI 要在这堆老手里挤进前三意味着它至少要压过其中一家头部产品。如果“第三”的消息成立那对手大概率是 Google 或 OpenAI、Anthropic 中的某一档位。这里需要提醒一句不同榜单的排名经常“打架”因为测试集、运行轮数、超参都不一样所以这个“第三”更准确的说法是“在某套评测口径下的第三”。3.2 Grok 4.7 的相对优势与短板基于公开信息推测从公开信息看Grok 4.7 这一代按 xAI 历次大版本迭代的常见节奏推断应该是在三个方向上做了重点加强一是上下文窗口与长仓库理解二是工具调用的稳定性三是多轮任务中的状态记忆。这三个方向恰好都是智能体编码的命门。一个能稳定读完十万行代码、记住自己改过哪些地方、连续执行十几步不出错的模型即便推理深度不是最顶尖工程成功率也会很可观。长上下文对 agent 来说尤其致命早期很多模型前面改得挺好改到第三个文件就把第一个文件的改动忘了这种“失忆”直接让任务功亏一篑。不过短板同样明显。首先是生态xAI 在企业级 IDE 插件、内部代码库索引、CI/CD 集成方面比 Anthropic 和 OpenAI 起步晚工具链的成熟度还需要时间补。其次是成本与速度高阶 agent 任务要跑很多轮调用如果单轮延迟和价格下不来企业实际落地时会有压力。最后是社区信任相比 Claude 在开发者圈子里多年攒下的口碑Grok 系列的“程序员友好度”还需要更多独立评测来背书。这些都是比“排名第三”更值得冷静观察的地方。模型强不等于好用好用也不等于好落地中间隔着整整一条工具链的距离。3.3 这条消息对行业格局的实质影响我的判断是这条消息最重要的意义不在于“第三”本身而在于它把 xAI 正式摆上了“智能体三强”的牌桌。过去聊 agentic coding大家默认是 Claude 和 Codex 的二人转现在多了一个变量对使用方是好事——竞争会压价、会逼各家把文档和稳定性做好。对开发者来说这意味着选型时多了一个真正值得跑一轮评测的候选而不是凑数的备胎。从 xAI 的战略动作看我一直观察到一个信号它在开源权重模型和 API 价格上的打法越来越激进直接冲的就是“开发者心智”这个入口。如果能借“智能体编码前三”这个标签先把一批独立开发者和中型团队圈进来后续再向企业级扩展路径是通的。至于是不是真的稳坐第三我建议以未来两个季度的独立第三方评测为准。毕竟发布时的宣传和长期的口碑从来都是两回事。4. 如果你也想亲测一套可落地的智能体编程评估方案4.1 准备工作环境、数据、预算看完上面的分析肯定有朋友想自己跑一轮评测验证一下“第三”的真实成色。我自己跑过的评估不下十轮踩过的坑可以凑一本小册子。先说准备工作。第一步是准备一个干净的隔离环境我推荐用 Docker 容器把评估脚本、依赖、目标仓库全部装在里面跑完直接销毁避免污染宿主机器。别用自己日常开发的机器跑agent 会在里面乱装东西、乱改配置翻车是家常便饭。第二步是选数据集。如果只想快速验证SWE-bench Verified 的子集是最省事的选 50 到 100 个 issue 就够看出趋势不用一次性把全部 500 个跑完省时省力。第三步是算预算。按我的经验一个复杂 issue 的 agent 任务中间可能要调用模型十几轮甚至几十轮单任务成本很容易到一两美元以上。跑 100 个任务的完整评测烧掉几百美元很正常。一定要提前设好 API 上限别让账单失控。我见过不少团队兴致勃勃开跑跑到一半发现预算超了最后拿着残缺数据硬下结论这比不跑更坑。4.2 关键参数与运行细节我习惯用官方或社区维护的 bench harness 来跑不要自己手搓评测逻辑否则很容易引入不公平的变量。这里给一个示意性的流程具体命令以你用的 harness 官方文档为准# 示意克隆评测 harness 并准备环境 git clone https://github.com/swe-bench/swe-bench.git cd swe-bench python -m venv .venv source .venv/bin/activate pip install -e . # 示意跑一个小规模验证参数以官方文档为准 python -m swebench.run_evaluation \ --dataset_name principle/swe-bench-verified \ --split test \ --max_workers 4 \ --max_issue_count 50 \ --run_id my_grok_eval跑的时候有几个参数特别关键。一是并发数max_workers我建议从 4 开始调太小跑得慢太大容易触发 API 限流报错之后你还得花时间区分“是模型不行还是限流造成的”。二是超时设置一个任务超过 20 到 30 分钟就该判失败别让它无限烧 token 空转。三是随机种子影响模型抽样结果固定种子才能保证前后对比公平。我自己的习惯是同一模型同一数据集至少跑两遍对比结果的中位数而不是单次最好成绩。4.3 结果解读别被总分骗了评分出来之后重点看三件事。第一是 pass1也就是一次启动就成功的比例这代表模型开箱即用的真实水平。第二是“修复路径有效率”我见过不少模型靠反复重试把总分刷上来的情况掩盖了它一步到位能力弱的事实所以要单独看首轮成功率。第三是成本与耗时同样达到 40% 通过率一家花 200 美元、另一家花 500 美元落地选型时高下立判。现在很多供应商支持设置“最大尝试轮数”我建议分别跑 10 轮和 3 轮两个配置看看分数的衰减曲线这能直观看出模型是“一次想清楚”还是“瞎猫碰死耗子”。还有一个容易踩的坑别拿别人榜上的数字跟你本地跑的数字直接比。评测环境、模型版本、天气都可能影响结果。正确做法是同一个测试集、同一个环境、同一套参数把候选模型轮流各跑一遍横向对比。单项分数说明不了问题分布和稳定性才是真相。我们选型是为了在真实仓库里干活不是为了在榜单截图里争高低。5. 常见问题与避坑清单5.1 关于“第三名”的几个常见误解这几天我看到评论区有不少误解挑几个典型的说一下。首要误解是“第三 综合能力第三”。实际上智能体编码只是 AI 能力的一个切片推理、数学、创意写作、多模态各有各的榜单。一家模型可能在编码 agent 上排第三在纯数学上排第五在长文档理解上排第二都是正常的。选型要看你自己的场景不要被单一标签带节奏。另一个误解是“创始人说了就是官方定论”。商业公司创始人公开发言的背后有品牌诉求真实能力要靠第三方评测和你的实际任务验证。我不是说这句话一定不准而是说它需要被验证。这个验证成本并不高花几百美元跑一轮自己的评测比转发一百条热评都更有价值。还有人说“排名第三说明可以替代初级工程师了”这个跳跃太大了。即便是头部模型在真实业务仓库里的完全自主成功率通常也达不到“无需人看管”的程度现阶段更靠谱的定位是“能大幅提效的结对助手”而不是“马上就能裁员的替身”。5.2 实操中的典型问题与排查方法我把评测过程中最常遇到的几个问题和排查思路整理成一张速查表方便大家收藏备用。现象可能原因排查方法大量任务超时agent 陷入重复尝试调大单步超时但限制总步数查看日志里的循环模式任务失败但报错信息为空环境依赖安装不完整检查容器初始镜像提前跑仓库自带测试验证环境分数忽高忽低随机性与并发不稳定固定随机种子重复跑 2 到 3 次取中位数成本远超预期单任务轮数失控设置最大步数上限关闭不必要的长输出日志结果和官方榜对不上数据集版本或预处理不同确认 repo 版本、基础镜像、模型版本完全一致这套排查方法不仅对 Grok 适用对任何模型的 agent 评测都成立。我特别想强调最后一条很多人跑完发现分数比官方低第一反应是模型被高估了结果一查发现是基础 Docker 镜像里少了几个系统依赖导致大量任务死在同一阶段。这种系统性偏差不解决对比就毫无意义。5.3 结合公开资料我对“智能体编码选型”的几点经验最后聊聊我自己的实操倾向。如果团队想快速试水 agentic coding我建议不要只盯一家。先把 Claude、OpenAI 的旗舰和 Grok 4.7 都放到你自己的 3 到 5 个真实仓库任务里跑一遍看谁在你的代码风格、依赖体系、部署流程下最顺。公开榜单是起点不是终点。另外建议关注模型供应商的“评测污染”问题。热门基准数据集如果长期公开模型厂商可能通过训练数据悄悄“看过答案”。所以我每次选型都尽量带上几个自己团队的历史 issue 做盲测这部分数据是外部看不到的测出来的结果才最接近真实水平。再有一个细节优先选支持自定义工具接口的模型因为真实的研发环境里agent 要接的是你们自己的 CI、代码评审、上线流水线工具链适配能力比单点智商更值钱。我自己踩过最大的坑是早期只看一个榜单总分就定了选型结果在真实仓库里因为模型不熟悉内部脚手架首轮成功率直接掉了一半。从那以后我给自己定了个规矩任何宣传里的“排名”“领先”“第一梯队”一律先翻译成“某基准某版本某条件下的表现”再决定要不要信。这句习惯放到 Grok 4.7 的“第三”上也同样适用。消息本身值得高兴但真正能让团队受益的还是自己亲手跑出来的那份数据。