- 实测豆包 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。
以前觉得"国产模型差一点所以得用国外的"，现在发现省下来的折腾时间，比那点模型差距值钱多了。
模型终究是工具，好不好用，拿它干点真活就知道了。
看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，也可以给个星标，你的支持就是我的动力。
热门跟贴