文章摘要
文章对国产大模型Evolving进行长程任务全场景能力实测。该模型以SaaS服务思路开发,周更能力,聚焦1M超长上下文、长程任务稳定性提升和更高Token使用效率。通过跨文档校审、参考链接整理两案例与上一代对比,展现其在处理复杂工作上的优势。

国产大模型到底能不能真正帮你搞定工作里的硬活?不是写文案、解习题、做PPT这类轻量任务,而是像通读几十GB文档找逻辑矛盾、整理数百条链接搭建专业资料库、从零开发一个可上线的小产品这种实打实的业务工作。

过去我对国产大模型的评价基本是「能聊天,但干重活总差点意思」,直到体验了这款新推出的模型,才彻底改变了想法。

这款模型最吸引我的点是「永远最新的模型卡片」:它不再通过版本号迭代,而是用统一的Model ID持续周更,用户只需要接入一次,就能自动用上最新的能力,不用切换接口、不用修改代码,专门针对编码和智能体场景做了优化。

我没有用跑分题或者八股文来测试它,而是布置了三件真实工作中的任务,还特意用上一代模型做了对照,看看这次升级到底带来了哪些实打实的提升。

这款模型的核心设计思路

传统大模型的发布节奏是大版本迭代,比如推出2.0、3.0版本,性能跳变一次,开发者就需要切换模型ID、适配接口、测试兼容性。而这款模型换了一种思路:它把大模型当成SaaS服务来做,不再设置版本号,只用一张统一的模型卡片和固定的Model ID,每周自动更新能力,用户只需要接入一次,后续就能自动获得最新的优化效果,完全不用折腾迁移工作。

这次首发的升级主要聚焦三个核心方向:

  • 1M超长上下文:单次任务可以容纳100万token,大约对应70-80万中文字,能够轻松处理大型代码仓库、跨数百个文件的资料库内容
  • 长程任务稳定性提升:官方数据显示,在Claude Code、Hermes、OpenClaw等智能体框架的开发者盲评中,长程任务的质量评分超过了上一代的2.1-pro版本
  • 更高的Token使用效率:相比2.1-pro,它的Token消耗更少,工具调用的轮次更简洁,整体推理成本有所降低

可以看出,这款模型的定位非常清晰:它不是全能型的通用模型,而是专门针对编码和智能体场景打造的「工作助手」,专注于帮用户完成复杂的长周期工作。

案例一:跨31份文档的口径校审

最近我在整理Agentic ERP相关的系列内容,已经更新了11篇万字长文,同时还参考了大量研报和公开资料,这些内容分散在以日期命名的文件夹中,总共31个Markdown文件,总字数超过40万,文件总大小1.5MB以上。

我的需求不是简单的内容汇总,而是通过13个针对性问题,把所有资料系统化整理,生成独立的Markdown文件,为后续搭建知识库和撰写白皮书做准备。这对大模型的上下文窗口是极大的考验,正好可以测试这款模型的1M超长上下文能力。

我让模型读取所有31份文件后,针对13个问题生成深度分析报告,每个问题对应一个独立的Markdown文件,最后再生成汇总文件。

这款模型的处理效率非常高,它将13个问题和汇总任务拆分为6个步骤,并行处理所有问题,最终只用了27分27秒就完成了全部任务:

  • 完成了13个问题的深度分析,生成了14个Markdown文件(包含13个问题答案和1个汇总文件)
  • 找出了8组数字矛盾、2处事实错误、14处内部引用错误
  • 识别出了多个孤立的未明确概念,还为第12篇终章规划了完整的10章结构

这个成果相当于资深主编加上研究助理的跨文档校审工作,而且只用了不到30分钟的时间。

为了对比差异,我同时用上一代的Doubao-Seed-2.1-pro跑了同样的任务。2.1-pro的处理方式是分批处理,每次只处理3个问题,从开始读取文件到完成前3个问题的分析和生成文件就用了20分钟左右。

到27分27秒时,2.1-pro只完成了6个问题的解答,第7-9个问题还在分析中,直到35分钟才完成第8个问题的文件生成,38分钟完成第9个,第39分钟才开始处理第10-13个问题。按照这个节奏,完成全部13个问题预计需要50到60分钟,甚至更长时间。

两者的详细对比如下:

指标 Seed Evolving Seed 2.1-pro
完成全部13题 ✅ 27分27秒 ❌ 40分钟只完成9/13题(预计总耗时50-60分钟)
分批处理 ❌ 无需分批,一次并行处理31份文件 ✅ 分5批,每批3题
产出文件数 14个(q1-q13 + summary) 已完成9个(40分钟时)
回答总字数 ~4万字(单篇2100-4000字) ~6万字(表格庞大但密度低)
回答风格 叙述+分析+证据链,详细标注来源 以大表格为主,缺乏分析深度
来源标注 ✅ 每个结论标注具体文件名+版本 ❌ 表格有来源文件名列,但正文叙述不引用
事实错误检出 ✅ 检出EU AI Act日期错误、高盛报告翻译硬伤(60 quadrillion误译) ❌ 未检出这两处硬伤
主代理工具调用次数 44次 约12次(依赖4个子代理)
含子代理总调用估算 ~75-80次 ~150-170次(更多开销)

可以看到,同样处理40万token的跨文档任务,2.1-pro虽然花费了更长时间、调用了更多工具、生成了更庞大的表格,但在核心价值上反而落后:它无法识别事实错误,不敢做出明确判断,只能单纯罗列数据。而这款新模型更像资深主编,能够做出判断、给出结论,直接指出「这个日期写错了」这类具体问题。

新模型可以并行处理全部13个问题,还能通过5个子代理同时读取不同的文件批次加速任务,而2.1-pro虽然也使用了4个子代理,但协调效率明显不足,只能分批处理,暴露了长程任务能力的短板。

案例二:80条参考链接的全链路入库整理

我平时撰写文章时会积累大量参考资料,每篇文章都会附带扩展阅读包,时间久了这些资料会散落在不同的文件夹中。虽然把所有链接汇总起来很容易,但要筛选出高质量内容、分类整理、评分去重,最终搭建出可供白皮书使用的专业资料库,就不是简单的工作了。

这个任务涉及抓取、判断、排序、脚本生成等多个环节,每个步骤都依赖前一步的结果,还会遇到死链、低质源、分类缺失等常见问题,非常考验大模型在真实业务流程中的长程任务稳定性。

我给新模型的任务是整理80条参考链接,生成专业的资料库。它很快规划了7步流水线,编写了Python脚本,顺利跑通整个流程,最终交付的成果包括总报告、A/B级精选内容、主题/关键词/中文/死链索引,以及CSV和JSON格式的全量数据,整个任务耗时10分35秒。

我同样用2.1-pro做了对照测试,它也规划了任务列表并编写了流水线脚本,但最终交付的只有6个文件,耗时7分45秒,比新模型快了26%。

两者的工作风格差异非常明显:

  • 新模型更像资深研究助理:虽然多花了3分钟,但产出质量更高,包含反向关键词索引、主动反爬挽救、细致的低质内容甄别、独立的死链和中文源报告,交付的成果基本不需要返工
  • 2.1-pro更像快节奏的实习生:上手快、交付整洁、框架正确,但细节粗糙,40%的链接没有识别来源,低质内容漏标了一半,看起来完整的成果需要后续再次检查

详细对比如下:

维度 Seed Evolving Seed 2.1-pro
总耗时 10分35秒 7分45秒(快26%)
文件数 12个 6个
总产出量 628 KB 524 KB
自发步骤 7步流水线 8步流水线(多一步「安装依赖/建venv」)
编写脚本数量 4个Python脚本(pipeline/patch_salvage/regenerate/clean_keywords) 1个Python脚本
可用链接数 70条 76条(更宽松,多6条)
真死链数 5条(含Reuters 401错误) 4条(更保守,未标记Reuters死链)
反爬标记数 5条(McKinsey×4 + DZone) 5条
低质标记数 21条LOW_QUALITY_SOURCE 11条
高质量阈值 A级≥90分 / B级≥75分(37条A/B级) ≥7分(52条)
评分体系 100分制,4维权重(40/25/20/15),7层权威等级T1-T7,ABCDF评级 10分制,4维权重(4/3/2/1),7类来源,无等级

这个测试中有几个细节值得关注:

  • 同样处理80条链接,新模型主动编写了4个脚本,涵盖并发抓取、反爬挽救、输出重生成、关键词清洗,而2.1-pro只写了1个主流程脚本,体现了更强的工程化思维
  • 新模型具备反爬挽救机制:当发现requests请求被拦截后,会自动切换到WebFetch方式补抓,多救回了4条高价值链接,真正做到了遇到问题自主解决
  • 2.1-pro快出来的3分钟,代价是32条链接没有分类来源,这个取舍需要使用者根据需求自行判断

如果任务规模扩大到数百条链接,新模型的优势会更加明显,它的运行更稳定、产出更丰富、返工率更低,整体价值更高。

案例三:开发一款手机版拼板H5小游戏

我小时候玩过一种智力拼板玩具,将完整的动漫图片拆成15个可自由滑动的滑块,玩法类似华容道:先打乱滑块顺序,再通过滑动将图片恢复完整。如果把这种玩具复刻为手机版H5小游戏,既有怀旧意义,也有不错的实用场景。

这个任务看似简单,但非常考验模型的自主产品规划能力和长程任务稳定性,需要从需求分析到最终交付完成完整的工程链路。我只上传了拼板玩具的照片,给出了简单的任务要求,就让新模型开始开发。

新模型将任务拆分为多个执行步骤,全程没有中断,只用了7分15秒就完成了第一版游戏。后续我又追加了两条命令,迭代到第二版,添加了动漫图片图库,并部署到了服务器,支持多端试玩。

整个过程从一张实物照片,变成了一个具备完整功能、可在手机上直接运行的H5小游戏,甚至可以直接分享到朋友圈。这个案例充分展示了新模型的自主产品规划能力、长程编码稳定性和算法正确性。

从零开发完整的H5游戏是一个多步骤的工程链路,包括:产品规划、UI设计、HTML结构搭建、CSS样式编写、JS逻辑开发、打乱算法实现、滑动交互设计、胜利判定、动画效果、本地存储、响应式适配、启动服务、自测修复Bug直到最终交付。新模型在整个过程中完成了数十次工具调用,始终牢记最初的目标,没有中途跑偏或简化任务。

游戏的完整功能列表如下,很难想象这些功能只通过一段简单的提示词就能实现:

功能点 实现情况 细节
3×5滑块布局 准确理解非标准布局,14滑块+1空格,3列5行结构
可解打乱算法 高级做法 不使用随机打乱,而是从完成态出发执行N*N*4=300次反向合法滑动,避免立即反向操作,保证100%可解,符合行业标准
拖拽+点击双操作 支持手指拖拽整行列滑块(一次可推动多个滑块),也支持点按滑动;设置35%阈值自动吸附,未达到阈值则回弹
流畅滑动动画 拖拽时实时跟手(关闭transition),松手后用CSS transition实现缓动归位
计时+步数统计 实时显示mm:ss计时,统计滑动步数,自动开始/停止计时
胜利判定与动效 胜利时弹出卡片,显示时间和步数,根据步数给出三星评级,添加彩带confetti粒子动画,附带再来一局按钮
原图提示功能 右上角显示缩略图,附带全屏预览按钮
长按预览原图 长按450ms触发全屏预览,拖拽时自动取消预览
数字提示开关 可切换显示每块滑块的编号,辅助卡关时使用
动漫主题图库 通过pollinations AI生成6张动漫图片,包括圣斗士星矢、悟空、樱木花道等,支持画廊切换
自定义上传图片 通过FileReader读取本地图片,自动加载为游戏素材
AI实时生成图片 输入关键词点击生成按钮,调用pollinations生成新图片并加入图库
本地存储最佳成绩 按网格大小为key,存储最佳步数和时间
移动端完整适配 支持viewport-fit=cover、safe-area-inset-bottom、100dvh、touch-action:none等移动端适配规范
桌面端兼容 支持PC浏览器的mouse事件拖拽操作
横竖屏自适应 窗口resize时自动重新计算tileSize
视觉风格 复古国风设计,米黄面板+红木框+朱红印章色+楷体标题,搭配阴影层次,呼应实物玩具的质感

这个游戏的开发有几个细节特别能体现模型的功底:

  • 工程层面选择了反向滑动的打乱算法,无需计算逆序数,保证100%可解,还规避了无效的来回操作,完全是资深开发者的思路
  • 交互层面支持拖拽整行整列滑块,手感接近原生App,还主动添加了胜利彩带、离线降级兜底等细节,精准还原了中式木质玩具的配色质感,审美和工程能力都在线

后续我还可以继续迭代这个游戏,添加更多玩法和功能,相信这款由模型开发的小游戏会带来不少乐趣。

实测总结

通过三个真实任务的测试,我有三个很深的感受:

第一,完成任务和高质量完成任务是两回事。在三个任务中,2.1-pro并不是完全做不到,它也能读取文档、编写脚本、开发游戏,但往往会在中途「松劲」:跨文档分析后半程只罗列表格而不做判断,80条链接中有40%没有识别来源,游戏能跑但功能被砍半。而新模型从头到尾都保持了高水准,交付的成果基本不需要返工,对于职场人来说,「不用返工」这四个字的价值远超想象。

第二,模型的差距不在聪明,而在靠谱。三个案例的对比中,新模型并没有答对什么惊天难题,而是做对了一堆没人特意教它的小事:遇到反爬拦截自动切换抓取方式补救链接、打乱拼图用反向滑动保证可解、跨文档找矛盾时不仅罗列数据还敢明确指出错误、开发游戏时主动添加胜利彩带等细节。这些细节并没有在提示词中明确要求,而是模型自己判断「好的产物应该这样」,这种自主判断力才是智能体时代真正的生产力。

第三,国产模型+国产智能体的组合已经形成完整闭环。整个测试都是在常用的AI协作工具中完成的,直接选择新模型即可,不需要折腾API密钥、不需要挂代理、不需要计算汇率,量大管饱,即使是长任务跑几十分钟也不用担心Token成本。过去我总觉得「国产模型差一点,所以要用国外的」,但现在发现,省下来的折腾时间,比那点微小的模型差距要值钱得多。

模型终究只是工具,好不好用,只有拿它干过真活才知道。这次的测试让我确信,国产大模型已经能够扛起实打实的业务工作,不再只是「能聊天」的玩具。

以上内容不代表本平台立场,仅供读者参考