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

• 实测豆包 Seed Evolving：1M 上下文 + 长程稳定，国产模型能扛真活了
• 1M 上下文 + 周级迭代，豆包 Evolving 想做 Coding & Agent 圈的"永远最新版"
• 不跑分跑真活：我用 Evolving 干了三件事，结果有点超出预期

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

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

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

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

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

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

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

我决定拿它干点真活试试。这几天我没拿它跑跑分题，也没让它写"10 个优点 10 个缺点"那种水文。

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

三件事分别对应它宣传的三个升级点：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篇，基本每篇都是万字长文。

扩展阅读：Agentic ERP与管理变革：AI Workforce 正在重构企业组织运行方式

在写文章的时候，也参阅了的大量研报、网页登资料，这些文章正文、草稿、研报等资料都散落在以日期+文件命名的一个个文件夹中。

我想把这些内容归纳总结到一起。初步用AI提炼了包括11篇文章在内的31个makedown文件，这些文件总量超过1.5m，至少也有40万字。

我不是简单整理文章，还有通过13个需要长回复的问题来把关注的点整理起来以及系统化，保存为md文件，为后面将其整理为知识库以及撰写白皮书而做前置准备。

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

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

Evolving读完31份文件后，把13个问题和一份汇总的任务拆分为6步，开始并行处理所有问题、解答并生成答案文件，已经最后进行汇总的文件。

这个任务总共跑了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。

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

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

看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，也可以给个星标，你的支持就是我的动力。