豆包 Seed Evolving 周更模型实测：跨 40 万字找错误、跑 80 条资料入库、7 分钟做个能玩的游戏

实测豆包 Seed Evolving：1M 上下文 + 长程稳定，国产模型能扛真活了

豆包发了一张“永远最新”的模型卡片，我拿三个真实任务帮你测了测

1M 上下文 + 周级迭代，豆包 Evolving 想做 Coding & Agent 圈的“永远最新版”

不跑分跑真活：我用 Evolving 干了三件事，结果有点超出预期

豆包 Seed Evolving 周更模型实测：跨 40 万字找错误、跑 80 条资料入库、7 分钟做个能玩的游戏

---

国产大模型，到底能不能真的帮你干活？

不是写个文案、解个题、做个 PPT 那种“轻活”，是那种你工作里真会遇到的，比如读几十个 G 的文档找矛盾、整理几百条链接建资料库、从零做个能跑能用的小产品。

这种活，以前我的答案基本是“还是得 GPT 或者 Claude”，国产模型能聊，但干重活总差点意思。

所以前段时间豆包发 Doubao-Seed-Evolving 的时候，我一开始没太当回事。

但它有一句话让我多看了两眼：一张永远最新的模型卡片。

意思是这个模型不搞版本号了，就一个 Model ID，背后按周级别持续升级，你接一次，后面自动用上最新能力，不用迁 Endpoint、不用改代码，Coding 和 Agent 场景专门优化。

这话说得挺满。等于在说：别纠结版本了，我每周都变强，你用就完了。

我决定拿它干点真活试试。

这几天我没拿它跑跑分题，也没让它写“10 个优点 10 个缺点”那种水文。

我在 WorkBuddy 里给它派了三件我手头真要干的活：读我写完的 11 篇系列文章 + 草稿 + 研报做校审、整理 80 条参考链接建白皮书资料库、照着一张小时候玩的拼板玩具照片做一个手机能玩的 H5 小游戏。

三件事分别对应它宣传的三个升级点：1M 超长上下文、长程任务稳定、Coding & Agent 能力。

前面两个案例我还特意拉了上一代 Doubao-Seed-2.1-pro 跑了一遍同样的任务，看看这次升级到底“升”在哪。

先说说 Evolving 是什么

在看实测之前，先花两分钟讲清楚 Evolving 这个模型的逻辑。

过去大模型的发布节奏是“大版本”，出个 2.0、3.0，性能飙一截，开发者跟着切 Model ID、测兼容、迁接口。

火山引擎这次换了个思路：Doubao-Seed-Evolving 不搞版本号，就一张卡片，统一 Model ID，周级迭代，你一次接入，新版本自动生效。

说白了就是：它把模型当 SaaS 做，不是当软件做。

这次首发主要升级三件事：

• 1M 超长上下文。单次任务能塞 100 万 token，大概就是 70-80 万中文字、大型代码仓库、跨几十上百个文件的资料库。
• 长程任务更稳定。官方说在 Claude Code、Hermes、OpenClaw 这些 Agent 框架的开发者盲评里，长程任务质量评分超过了上一代 2.1-pro。
• Token 效率更高。比 2.1-pro 吃得少、工具轮次更简洁，整体推理成本下降。

方向很明确：专注 Coding 和 Agent 场景。不是全科生，是个专门帮你写代码、跑流程、干长活的“打工模型”。

具体是不是这么回事，下面三个案例是我这两周真刀真枪跑出来的。

案例1：跨30个markdown文件找口径矛盾

最近几个月，我写了Agentic ERP系列文章，目前已经更新了11篇，基本每篇都是万字长文。在写文章的时候，也参阅了的大量研报、网页登资料，这些文章正文、草稿、研报等资料都散落在以日期+文件命名的一个个文件夹中。

我想把这些内容归纳总结到一起。初步用AI提炼了包括11篇文章在内的31个makedown文件，这些文件总量超过1.5m，至少也有40万字。我不是简单整理文章，还有通过13个需要长回复的问题来把关注的点整理起来以及系统化，保存为md文件，为后面将其整理为知识库以及撰写白皮书而做前置准备。

40W字的资料，对大模型的上下文是个很大的考验，自然想到了1M超长上下文的 Doubao-Seed-Evolving模型。

操作也很简单，就是让它读取全部MD文件后，回答问题清单中的问题，并为每个问题的答案生成单独的MD文件。

这个任务总共跑了27分27秒， Doubao-Seed-Evolving成功完了13 个问题的深度分析，共生成 14 个 markdown 文件（q1-q13 + summary），找出了 8 组数字打架

，发现了 2 处事实错误，揪出了 14 处内部引用错误，识别出了一些“孤儿概念”，并给第 12 篇终章规划了完整 10 章结构。

这个结果，可以算是资深主编 + 研究助理级别的跨文档校审，而在效率上只用了27分钟。

我顺便让 Doubao-Seed-2.1-pro也跑了一下这个任务。开始任务后，2.1-pro一直对Q1-Q3这3个问题进行推理和分析。

14分钟后，开始对3个问题进行解答和创建回答文件。

可以看到，2.1-pro是分配进行分析和解答并生成文件的，每次3个问题。不像Doubao-Seed-Evolving，13个问题同时分析与解答。从开始读取文件到完成头3个问题的分析、回答与生成文件，大概用时20分钟左右。

在25分钟左右完成的Q4-Q6解答，每完成3个问题大概需要5分钟左右。到27分27秒，任然是完成了6个问题的解答，Q7-Q9仍然在分析中，还没有生成文件。到35分钟，问题Q8的回答文件生成。到第38分钟，Q9生成。第39分钟，开始分析Q10-Q13。token还在在疯狂燃烧，时间问题，后面我就不继续测试了。预计完成全部问题的回答与生成文件，任务总体时间需要50分钟-1小时，甚至更长的时间。

两个模型主要表现对比如下：

关键指标对比

指标	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 次（更多开销）

除此之外，文章中的几处硬伤，Seed 2.1-pro也没能看出来。

总结一下。

同样 40 万 token 的跨文档任务，2.1-pro 用了更长时间、调用了更多工具、做了更长的表格，但在“真正的价值”上反而落后：它没找到事实错误，不敢判断对错，只会罗列数据。

Evolving更像一个资深主编，有判断、有结论、能指出“这个日期写错了”等多种错误。

Evolving 一次并行处理全部 13 题，而且还能用 5 个子agent并行加速（5 个 Agent 同时读不同文件批），2.1-pro 也用了 4 个子代理，但明显协调效率差。

2.1-pro 做不到 13 题同时在脑中规划，只能分批，这是一种策略性失败。选择“每批 3 题”，把长任务拆碎，恰恰暴露了长程能力短板。

案例2 ：链接资料入库全链路

我平时写文章，会有很多参考资料，一般每篇文章会有一个参考资料扩展阅读包。时间久了，这些资料会散落在每个文件夹。把这些链接合并到一起很容易，但要整理出高质量链接用于以后的白皮书构建，还是有些困难的。

需要从几十上百条链接里筛选、分类、评分、去重、建资料库，就有困难了。涉及到抓取、判断、排序、脚本生成多个环节，后一步依赖前一步结果。并且链接中途死链、低质源、类别缺失都是常态。

这个工作虽然看起来简单，还是蛮考验大模型的真实业务工作流中的长程任务稳定性。所以，我也用Doubao-Seed-Evolving来跑一下试试。

任务要求没写多具体，就是大体让它把80条链接按要求整理出来。

Evolving整理了一个7步流水线，写了python脚本，很快就把流水线跑通了，然后开始跑任务。

最终交付了Agentic ERP 80条参考资料完整入库产出，包含总报告、A/B级精选、主题/关键词/中文/死链索引、CSV与JSON全量数据等，任务总耗时10分35秒。

顺便也来试试Seed 2.1-pro，开新聊天窗口，把同样的任务要求交给Seed 2.1-pro。

在一番思考和分析之后，Seed 2.1-pro规划了一个任务列表，写了流水线python脚本，然后执行任务。

交付了资料处理报告、精选核心资料推荐等6个文件。最终任务耗时7分45秒，反而比Doubao-Seed-Evolving用时更少。

通过对比，Evolving与2.1-pro的工作风格完全不同。

• Evolving 像个资深研究助理：多花 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分（27+10=37条 A/B）	≥7分（52条）
评分体系	100 分制，4 维（40/25/20/15），7 层权威 T1-T7，ABCDF 等级	10 分制，4 维（4/3/2/1），7 类来源，无等级

另外，有几个细节需要提一下。

1、同样 80 条链接，Evolving 主动写了 4 个脚本（并发抓取、反爬挽救、输出重生成、关键词清洗），2.1-pro 只写了 1 个主流程脚本，说明 Evolving 更有“工程化思维”

2、反爬挽救机制：Evolving 发现 requests 被拦后，自动切换 WebFetch 补抓，多救回 4 条高价值链接，这是真正的“遇到问题自己解决”

3、2.1-pro 快出来的 3 分钟，代价是 32 条链接没分类来源，这个 trade-off 读者自己会算账。

这个案例只有了80条链接，如果是占用大上下文窗口几百条链接，显然Evolving更有优势，且运行稳定，产出更丰富，返工率低，价值是更大的。

总而言之，自发的工程化能力、 7 步流水线自设计、反爬兜底（遇错自处理）、分级评分体系、高专业度产物以及精准的数据，较好了体现了Evolving的长程任务能力。

案例3：coding一个魔板拼图 H5 小游戏

小到时候，玩过一款叫作智力拼板玩具。这种玩具把一张完整的动漫图片比如圣斗士星矢等等拆成15个自由滑动的滑块，玩的时候先通过滑动滑块把拼图打乱，然后再滑动滑块拼成完整图像，这种玩法类似于现在的华容道拼图。

如果把这种玩具复刻为手机版H5小游戏，那想象空间还是挺多的。比如可以生成各种动漫人物，可以让滑块让更多种排列，可以多人一起玩，可以搞个排行榜啥的，哈哈哈，脑洞真的好多。当然，主要是为了重温一下回忆，在手机上玩玩儿时玩具，既开心又治愈。

这个游戏看着简单，其实也比较考验模型的自主产品规划能力和长程任务能力。

完整版需要多个版本迭代，今天我们就来coding一个基础版。

打开一个新聊天窗口，上传这张图片作为参考，提交简单的任务要求。

Doubao-Seed-Evolving把任务拆成了几个执行步骤，开始运行。

全程无打扰，任务执行时间7分15秒，第一版智力拼板游戏完成。

构建游戏时生成AI图片用的是pollinations，由于网络不稳定，动漫图库没能生成图片。上传一张本地图片试一下，不错，可以畅玩了，滑块移动很丝滑。

我又追加了两条命令，迭代到第二版，图库加了动漫图片，并且部署到了codebuddy公网，已经支持多端试玩。微信中打开下面这个链接，就能在手机上玩了，感兴趣的朋友可以试玩一下。

https://7131ff18b15b430e8300d24dedd049b3.app.codebuddy.work

7 分 15 秒，不用任何干预，从一张实物照片 变成 一个有审美、有细节、手机直接能玩、真能发朋友圈的 H5 小游戏，这个案例展现出了Evolving模型的自主产品规划能力、长程 Coding 稳定性以及算法正确性。

尤其在长程 Coding 稳定性方面，从零到完整产品是个多步骤工程链路：

产品规划 → UI 设计 → HTML 结构 → CSS 样式 → JS 逻辑
→ 打乱算法 → 滑动交互 → 胜利判定 → 动画 → 本地存储
→ 响应式适配 → 启 http 服务 → 浏览器自测 → 修 bug → 交付

全程几十次工具调用，需要模型始终记得最初目标、不中途跑偏以及不半途简化，Evolving的表现，可圈可点。

游戏的实际功能如下表，很难想象实现这些功能只是一段简单的提示词。

功能点	实现情况	细节
3×5 滑块变体	✅	准确理解非标准布局（不是经典 4×4），14 滑块+1 空格，3 列 5 行
打乱算法（可解性）	✅ 高级做法	不是随机打乱，而是从已完成态出发做 N*N*4=300 次反向合法滑动，并避免立即反向；这是行业标准做法，保证 100% 可解
拖拽 + 点击双操作	✅	手指拖拽整行列滑动（一次可推多个滑块），也支持点按滑动；阈值 35% 自动吸附，否则回弹
流畅滑动动画	✅	拖拽时实时跟手（关 transition），松手后用 CSS transition 缓动归位
计时 + 步数	✅	实时 mm:ss 计时，步数统计，自动开始/停止
胜利判定 + 动效	✅	胜利弹出卡片、时间/步数展示、三星评级（按步数）、彩带 confetti 粒子动画、再来一局按钮
右上角原图提示	✅	缩略图 + 全屏预览按钮（👁 图标）
长按预览原图	✅	长按 450ms 触发全屏预览，拖拽时自动取消
数字提示开关	✅	切换显示每块编号，卡关时辅助
6 张动漫主题图库	✅	pollinations AI 生图，圣斗士星矢/悟空/樱木花道/鸣人/路飞/炭治郎，画廊切换
自定义上传图片	✅	FileReader 读取本地图，自动加载
AI 实时生成图	✅	输入关键词点“生成”按钮，调用 pollinations 新图加入图库（按钮已写好）
localStorage 最佳成绩	✅	按网格大小 key 存最佳步数/时间
移动端完整适配	✅	viewport-fit=cover、safe-area-inset-bottom、100dvh、touch-action:none、-webkit-tap-highlight-color、iOS web-app meta
桌面端兼容	✅	mouse 事件同时支持 PC 浏览器拖拽
横竖屏/resize 自适应	✅	resize 时重算 tileSize
视觉风格	✅	复古国风：米黄面板+红木框+朱红印章色+楷体标题+阴影层次，呼应实物照片质感

我觉得Evolving做的滑块游戏，有几处都特别见功底。工程上它选了反向滑动的打乱算法，不用算逆序数，保证 100% 可解，还规避了无效来回操作，完全是资深开发者的思路。交互上支持拖拽带动整行整列滑块，手感接近原生 App。胜利彩带、离线降级兜底这些细节都是它主动加的，还精准还原了中式木质玩具的配色质感，审美和工程能力都在线。

后面有时间的话，就用Evolving继续迭代这个游戏的多种玩法，以后休闲时刻就可以畅玩自己做的游戏了。当然，说不定哪一天，你就能在小程序见到它了。

三个案例跑完，有几个感受挺深的。

第一，能不能做 和 能不能一次做到位 是两码事。 三个任务里，2.1-pro 不是完全做不到——它也能读文档、也能写脚本、也能写游戏。

但它做到一半会“松劲”：跨文档分析后半程就只列表格不判断了，80 条链接里 40% 没识别来源，游戏能跑但功能砍半。Evolving 从头到尾都没松劲，交过来的东西基本不用返工。干过活的人都知道，不用返工这四个字值多少钱。

第二，模型的差距不在 聪明，在 靠谱。 你看三个案例的对比，Evolving 不是答对了什么惊天难题，而是做对了一堆没人教它的小事：看到反爬拦了自动换 WebFetch 补抓、打乱拼图用反向滑动保证可解、跨文档找矛盾不只是罗列还敢说“这个日期写错了”、做游戏顺手加了个彩带粒子。

这些， prompt 里没有，是模型自己判断的“好的产物应该这样”。这种判断力，才是 Agent 时代真正的生产力。

第三，国产模型+国产 Agent 这套组合已经能闭环了。 我全程在 WorkBuddy 里跑，模型选 Evolving，自定义添加就行，不用折腾 API key、不用挂代理、不用算汇率。量大管饱，真遇到长任务跑几十分钟也不心疼 token。

以前觉得“国产模型差一点所以得用国外的”，现在发现省下来的折腾时间，比那点模型差距值钱多了。

模型终究是工具，好不好用，拿它干点真活就知道了。