夜雨聆风5月27日，IBM软件创新实验室和Artificial Analysis联合发布了ITBench-AA。
这个榜单和我们熟悉的那些benchmark不一样。它不考问答，不考代码生成，不考你能不能写一篇漂亮的文章。它做了一件事：把模型扔进一个真实的服务器集群，系统已经出了故障，你来排查根因——像一个真正的运维工程师那样读日志、追链路、定位问题。评分极其严格，漏掉任何一个真实原因，整道题直接零分。
结果怎样？所有前沿模型得分均低于50%。Claude Opus 4.7领跑，47%。GPT-5.5紧随其后，46%。Qwen3.7-Max拿到42.5%，全球前三。
ITBench-AA榜单：所有前沿模型得分均低于50%
但这个榜单真正有意思的地方不在排名，而在一个反直觉的发现：
调查轮次越多的模型，成绩反而越差。
Gemini 3.1 Pro Preview平均每道题需要83轮交互，得分只有30%。GPT-5.5平均31轮，拿到46%。Qwen3.7-Max平均37.6轮，拿到42.5%。
不是越勤快越好。这个评测的计分方式很有意思：漏掉真正的故障原因，零分；但找对了原因、同时又多报了几个无关的，也要扣分。模型查得越多，越容易把"看起来可疑但其实没问题"的东西也报上去——就像一个过度紧张的医生，明明已经找到了病因，但非要把所有异常指标都写进诊断书，结果反而模糊了真正的结论。
这和我们日常使用AI的直觉相悖。我们总觉得，模型应该尽可能多想、多查、多试。但ITBench-AA告诉我们，真正重要的不是尝试的次数，而是每次尝试的判断力。
ITBench-AA各模型平均调查轮次
就在这个榜单发布的同一周，我用Qwen3.7-Max做了一件事，恰好从另一个角度验证了同样的道理。
两天，一个Chrome插件，和十几次碰壁
我平时在油管上看大量的视频——投资访谈、AI论文解读、技术讲座，一条视频动辄一两个小时，根本看不过来。而很多时候我只想快速知道这个视频在聊什么、有哪些关键观点，再决定要不要完整地看完。过去我一直用Glarity这个Chrome插件做视频摘要，短视频还凑合，但视频一超过十五分钟效果就断崖式下降。一个一小时的访谈，摘要只覆盖前20分钟，后面的内容全丢了。Glarity这个插件来自2023年，早就停更了。
这个痛点存在了快三年，我一直想自己做一个更好的，但浏览器插件开发门槛不低，所以这个想法就一直搁置着。
直到上周，5月20日我去参加了阿里云峰会，会上千问团队宣讲了当天刚发布的Qwen3.7-Max——专门面向Agent场景设计、百万级上下文窗口、支持长达35小时自主执行。听完觉得挺适合拿来试试真实项目，正好手上有这个搁置了三年的插件需求，就拿它试手了。
需求很明确：做一个Chrome插件，能给油管视频生成结构化摘要，特别是要解决长视频的问题。我最初的想法是在Glarity的基础上翻新，但Qwen3.7-Max帮我做了一轮调研之后否定了这个方案——它搜了市面上的同类工具和开源项目，扒了Glarity、BrainyAI、Read Frog等几个项目的代码，给出的结论是：Glarity代码太旧，改造成本不如直接基于一个现代基座叠加功能；Read Frog虽然是翻译插件，但技术栈最新，架构干净，直接拿它的代码做二次开发，工作量最小。
我接受了这个判断。最终的产品方案定下来：基于Read Frog做二次开发，在它的翻译引擎上叠加油管视频摘要和Google搜索增强两个核心功能。这个"站在别人肩膀上"的决策很重要，后面会看到它如何在关键时刻救了整个项目。
开发用的是OpenCode，一个开源的终端编码Agent，背后跑的就是Qwen3.7-Max。品牌和视觉设计交给了Claude Design，它定了一套深森绿加酸柠绿的配色，做了图标和整个组件样式体系，效果比我预期好很多。
Claude Design设计过程：品牌色与图标
组件风格与CSS变量
设计就位，接下来就是核心功能开发——也是整个项目最值得讲的部分。我开发用的是 OpenCode，一个开源的终端编码 Agent，背后跑的就是 Qwen3.7-Max。
在Opencode里面使用Qwen3.7-Max
获取字幕：6次碰壁之后，第7次它选择了"不做"
做油管视频摘要，第一步是拿到视频的字幕文本。听起来简单，但油管不提供公开的字幕接口，想拿到这些数据，得自己想办法。
这里要说一下开发模式：我给了Qwen3.7-Max操作浏览器的权限，它能自己打开Chrome、加载插件、访问油管页面、跑一遍流程看结果。写完代码自己测，测完不对自己改，不需要我传话。所以接下来的每一次"尝试→失败→换方案"，都是它自主完成的。
它先试了最直接的办法——直接请求油管的页面数据，提取字幕。结果被油管的登录验证挡回来了。然后它转向从浏览器内部想办法，试了好几种方式去读取页面上的字幕数据：先是被浏览器插件的安全隔离机制挡住（插件和网页之间有一道墙，互相看不到对方的数据），又被浏览器的安全策略拦截，再试着直接调用油管的内部接口，结果缺少一个验证令牌，请求被拒。
四种方案，四种不同的失败原因。但有一点让我印象很深：它从不在同一条路上反复"撞南墙"。每次失败后它都能判断出"这不是我代码写错了，是这条路本身走不通"，然后切到一条完全不同的思路。
到第五次尝试时，出现了一线希望——它找到了一种方式让插件和网页共享数据，短视频的字幕成功拿到了。但长视频仍然失败，因为油管对长视频有额外的验证机制。
第六次，它又想了一个很精巧的方案去截获页面数据，但稳定性不够，时灵时不灵。
六次尝试，每条路在逻辑上都合理，但每条路都撞上了油管或浏览器安全模型的某一道墙。而这几轮方案切换都发生在同一个Qwen3.7-Max的长会话里——它始终记得前几次失败的原因，不会重蹈覆辙。整个过程中，我只在"要不要继续这个方向"上做了确认。
然后，第七次，转折来了。
还记得前面说的"基于Read Frog做二次开发这个决策很重要"吗？模型在重新审视Read Frog的代码库时意识到一件事——Read Frog作为翻译插件，本身也有获取油管字幕的需求。也就是说，它已经有一套完整的、经过社区验证的字幕获取方案，前面六次碰到的每一个坑，这套方案全部解决过了。
模型的结论是：不应该自己重写，直接复用。
问题彻底解决。我们选择基于Read Frog做二次开发，本来是看中了它的技术栈作为基座。没想到它的字幕获取能力——一个翻译插件的"副产品"——最终成了整个项目的关键拼图。
回头看，七次迭代里最重要的不是前六次越来越精巧的技术方案，而是第七次那个"放弃自己写"的决定。最聪明的迭代不是"再想一种新方法"，而是"认识到不该自己做这件事"。
Qwen3.7-Max理解自己的错误
这让我想到ITBench-AA的那个发现。Gemini用了83轮交互——它很努力，但越查越乱。好的Agent不是那个永远不放弃的，是那个知道什么时候该停、什么时候该借力的。
摘要生成：优化了三轮之后，它把整个思路推翻了
字幕拿到了，接下来是怎么把它变成有用的摘要。
短视频的摘要其实不难——五到十分钟的视频，字幕也就几千字，整段丢给大模型，一次就能出一份不错的总结。
但长视频完全是另一回事。过去最大的问题是模型一次能读的文本量有限，一两个小时的视频字幕动辄十几万字，模型读不完只能截断，所以Glarity这类工具做出来的"长视频摘要"其实只覆盖了前20分钟，后面全丢了。现在模型能读的量够大了，一次读一百万字都不稀奇，但问题并没有因此解决——你把十几万字一股脑塞进去，模型确实能读完，但它不知道该重点挖什么。一个小时的投资访谈里有闲聊、有铺垫、有核心论点、有数据佐证，信息密度分布极不均匀，让模型一遍扫完就出摘要，结果往往是"看起来完整"但重点模糊，关键论据被稀释在大量上下文里。
说实话，长视频摘要是个挺小众的需求，Glarity早就停更了，市面上也没有其他工具认真做过。不是技术上完全不可能，而是投入产出比太低，没人愿意啃。一开始我们也掉进了同一个坑里。
Qwen3.7-Max最初的方案是把字幕一次性发给大模型生成摘要，但输出格式不稳定，不同语言返回的格式五花八门，经常解析失败。它很快判断出问题在格式不受控，于是切换到用结构化模板强制约束输出，格式问题解决了。但新的问题随之浮出来：字幕太长一次塞不完，一个小时的视频只能覆盖前20分钟。它又加了自适应逻辑，根据视频长短动态调整章节数量和层级结构，覆盖范围有所改善，但一个小时的访谈被硬塞进固定数量的章节里，每个章节只能分到一两句话的篇幅，重点和细节都被压没了。
三轮优化下来，每一轮都解决了上一轮的问题，但改善越来越小。因为这三轮都在同一个思路里打转——"让模型一次搞定"。不管是更好的提示词、更智能的模板还是更动态的参数，本质上都是在问同一个问题："怎么让一次调用处理更多内容？"
真正的突破发生在Qwen3.7-Max换了一个问题："为什么要坚持一次搞定？"
它提出了一个Two-pass（两遍扫描）的方案。第一遍做轻扫：把完整字幕交给模型，只要求它做一件事——识别视频的结构，把内容切成八到二十个时间段，标出每段的边界和标题，不做深度分析。第二遍做深挖：对每个时间段单独截取对应的字幕片段，独立生成摘要和带时间戳的要点，所有段落同时并行处理。
Qwen3.7-Max重新定义问题
效果是质的飞跃。同一个1小时22分钟的视频，Glarity只能产出一份笼统的摘要，覆盖不了完整时长；而Qwen3.7-Max采用的Two-pass（两遍扫描）方案产出了完整的结构化章节，每个章节有精确时间戳，点击直接跳转到视频对应位置。
Two-pass方案的实际产出：结构化章节 + 带时间戳的详细要点
这个过程和前面的字幕获取展示的是两种不同的迭代能力。字幕获取那六次碰壁，Qwen3.7-Max是在不同路径之间横向切换；摘要生成这里，它是在同一条路上纵向撞了三次天花板之后，选择了升维——不再优化"一次搞定"这个思路本身，而是跳出这个思路。
它真正做对的地方，不是一次写出最终方案，而是在几轮修补之后意识到：该换的不是参数，是整个框架。
好的Agent不只会换方案，还会在碰壁足够多次之后意识到：该换的不是方案，是思路。
回到ITBench-AA：判断力比执行力更重要
讲到这里，可以回到开头那个榜单了。
我做Skim AI的经历和ITBench-AA考察的场景，表面上完全不相干——一个是浏览器插件开发，一个是服务器集群故障排查。但底层考察的其实是同一种能力：在真实系统的约束下，面对一连串事先不知道的障碍，能不能自主推进下去。
服务器集群排障时，模型需要读日志、追踪服务之间的依赖、判断哪些异常是真正的根因。浏览器插件开发时，模型需要应对一个接一个的安全限制和环境约束。
两种场景里，障碍都不是模型事先知道的。都不可能靠"一次漂亮的推理"解决。都需要模型反复试探、准确判断失败原因、在正确的时机切换策略。
ITBench-AA从评测维度证明了"精准高效 > 盲目探索"——37轮拿42.5%好过83轮拿30%。Skim AI的开发过程从实践维度印证了同样的道理——最终解决字幕获取问题的不是第8种更聪明的方案，而是"复用已有代码"这个看似最不 "Agent" 的决定。
2026年，AI Agent正在从"帮你补全代码"变成"给了权限之后能自己跑一整条工作流的协作者"。但正因为权限在变大、自主性在变强，"判断力"就变得比"执行力"更关键。一个能自主操作浏览器、自主调用上千次工具的Agent，如果缺乏判断力，只会更快地走上错误的路。
这也是Qwen3.7-Max带给我惊喜的地方。它在ITBench-AA上用37.6轮拿到42.5%，在Skim AI开发中7次迭代字幕获取方案、最终选择复用而非重写，在官方的35小时内核优化测试中跑了30小时还在发现新的优化方向——这些表现指向的都不是"能力强"，而是"判断准"。更让我在意的是，我在OpenCode里用它、别人在Claude Code或Hermes里用它，表现高度一致。它学会的不是"怎么在某个特定工具链里解题"，而是"怎么解题"本身。
ITBench-AA这类评测的出现，标志着行业终于开始用对的标尺衡量对的能力。以前的benchmark考"你知不知道答案"，现在考"你能不能在真实系统里把事情查清楚、做完整"。
而一个Agent在真实系统里能走多远，最终取决的不是知识量或推理速度，是它碰壁之后的反应——能不能准确判断失败原因，能不能及时换路，能不能在对的时候停下来借力，能不能在调了三版参数之后意识到应该换架构。
最好的Agent不是最勤快的，是最会迭代的。
-END-
获取更多AI非共识！
