智猩猩AI整理
上个月刚测完Doubao-Seed-2.1-Pro豆包Seed 2.1 Pro实测：一句话复刻吸血鬼幸存者页游！它已经摸到了能进真实工作流的门槛。
给它一句"做一个类似吸血鬼幸存者的网页游戏"，没有设计稿也没有玩法规则，它自己拆出了一份开发计划，分模块跑通、验证、再往下推进。
追加一句"让它更像完整游戏产品"，界面和交互立刻跟着重做了一版。
然而，此次字节又更新了。
原以为字节要另起一条基模支线，接下来还得记住一堆子版本、灰度版、实验版。
但官方给它的定位是一张永远最新的模型卡片：
Seed-Evolving是面向Agent与Coding场景打造的Seed系列模型，具备复杂任务编排、长程规划、代码生成与工具调用能力。统一调用Model ID doubao-seed-evolving，无需关注版本切换，即可持续获得最新模型能力。
别的模型是"1.0→2.0→3.0"这样迭代，每次换模型ID，API都要改。
但是字节这个模型Model ID永远不变，就叫Doubao-Seed-Evolving，但背后的能力会悄悄升级。
有点像Docker里的latest标签，你锁定的不是某个版本，是最新。
Doubao-Seed-Evolving后面不会有1、2、3，让它始终等于Seed系列里当下最强的那个模型。
字节直接把版本号从开发者的世界里藏了起来。
01
字节跳动Seed系列
开启动态迭代时代
Doubao-Seed-Evolving用的是一套动态迭代机制，每周至少发一次更新。
但这个过程开发者感觉不到，不用切接口、不用迁移端点、不用重新调Prompt。
升级这件事，第一次从开发者的待办清单里被拿掉了。
在定价上，Doubao-Seed-Evolving延续了2.1 Pro的标准：输入6元/百万tokens，输出30元/百万tokens。
这套机制之上，官方公布了三条具体升级：
（一）上下文窗口从256K跳到了1M
三周前，Seed 2.1 Pro的模型卡片还写着上下文窗口262,144 tokens。三周后，Doubao-Seed-Evolving直接把这个数字顶到了1,000,000，接近4倍的跨越。
这个升级意味着可以把一整个大型代码仓库、一份长篇文档，或者跨文件的完整资料一次性喂给模型，不用再做痛苦的分段和检索拼接。
（二）长程任务能力增强
在持续时间更长、步骤更多、依赖关系更复杂的任务里，官方称这次的表现比Seed 2.1 Pro更稳定，在开发者众测的质量评分中已经反超后者。
Seed 2.1 Pro在上一轮还是字节自家最强的旗舰，Doubao-Seed-Evolving现在对标的是自己人。
（三）Tokens效率提升
完成同样的任务，消耗的tokens更少，工具调用轮次也更简洁。
这一条不会出现在跑分榜单的显眼位置，但对要付调用账单的企业用户来说，可能是三条里最实在的一条。
02
从复刻游戏到拆解全书，
1M到底能扛多大事？
上一轮测Seed 2.1 Pro时，给的是一句“做一个类似吸血鬼幸存者的网页游戏”。
官方说Doubao-Seed-Evolving的1M上下文可以把一整个大型代码仓库、长篇文档一次性喂给模型。
所以，这次为了验证三项核心升级能力的综合表现，这次并没有沿用Seed 2.1 Pro的简单任务.
而是同时向Seed 2.1 Pro和Doubao-Seed-Evolving提供了一份网页游戏PRD，要求模型完成从需求理解、方案设计到代码实现与调试的全流程开发。
在我们的测试环境中，Seed 2.1 Pro在第一步读取响应正文时触发客户端超时，任务未能继续推进。
对于中等规模项目而言，256K上下文通常已经足够。
但面对这份包含完整玩法、系统设计和交互要求的PRD，模型仍需要开发者额外介入。
而Doubao-Seed-Evolving则凭借1M上下文窗口，完整跑通了整个任务。
它一次性读取并理解全部PRD内容，随后完成需求拆解、架构设计、模块开发、功能调试和最终交付。
全程耗时约17分钟，输入约4,800Token，输出约24,200Token，总计约29,000Token，最终生成了一份超过1,900行的完整游戏HTML。
29,000 Token是什么概念？
相当于模型一口气读完一篇约2万字的短篇小说后，立刻从零开始写出近2,000行可运行代码。
跑完PRD任务，Doubao-Seed-Evolving的表现符合预期，1M窗口下处理中等规模项目确实比256K从容不少。
但能处理PRD和能扛住真正的大项目之间还有一段距离。
PRD再复杂，也是结构化的需求文档，有明确边界。
真实世界里的Agent任务，往往没有边界，可能要一次性处理几十个文件、跨章节追溯信息、在几万字里找一条矛盾的线索。
我需要一个更极限的测试。
于是有了第二轮：用cangjie-skill把《甄嬛传》这本书蒸馏成一套Agent Skill。
简单说，就是扔给AI一本150万字的小说，让它从中提取主角甄嬛的认知上下文。
可以看到这本书已经有接近3M。
这类任务同时考验模型的长上下文理解、任务规划能力以及持续执行能力，比单纯测试代码生成更接近真实Agent工作场景。
EPUB本质上是ZIP压缩包，先用Python脚本解压，提取所有HTML章节文件，解析出纯文本。
一份可以被AI加载、用甄嬛的视角来分析问题的认知Skill文件。
任务刚启动时，Doubao-Seed-Evolving和Seed-2.1-Pro看不出区别，都在拆需求、列计划、分模块。
真正的差距在执行环节。
cangjie-skill的蒸馏流程要求提取方法论之后，回到原文做交叉印证。
Doubao-Seed-Evolving则可以在1M窗口下同时对照全书不同章节，遇到前后说法不一致会主动回查原文，而不是复述一遍交差。
全程保持精准引用，才是256K到1M最本质的跨越。
03
字节首个取消版本号的大模型，
解决了升级焦虑，却带来了新问题
目前主流海外厂商，包括OpenAI、Anthropic、Google，依然采用版本号体系，通过数字和代号区分不同阶段的模型能力。
字节则成为大型模型厂商中较早明确提出取消版本号的企业。
版本号体系最大的价值在于可追踪、可比较，也方便开发者进行版本回退。
但另一面是，随着模型迭代速度加快，开发者需要不断判断哪个版本更适合当前业务，选择成本和迁移成本也随之增加。
Doubao-Seed-Evolving采用了另一种思路，固定模型ID，让模型能力持续演进。
对于开发者来说，不需要频繁切换模型版本，只需要关注模型是否能够持续满足业务需求。
但问题也随之出现，当模型不再通过版本号区分时，开发者如何确认一次更新没有带来能力下降？
过去，如果新版本出现问题，开发者可以明确知道是哪个版本导致，并回退到旧版本。
而在持续更新模式下，一旦模型表现出现波动，问题定位、效果复现以及版本管理都会变得更加复杂。
目前，Doubao-Seed-Evolving并没有公开完整的更新日志或详细变更记录，第三方平台能够看到的信息也主要停留在当前模型与Seed 2.1 Pro的简单对应关系。
这也是持续演进模式需要进一步解决的问题，它降低了模型升级的操作成本，但如何建立一套透明、可追踪的迭代机制，仍然是开发者是否愿意长期采用的关键。
不过从这一轮实际体验来看，Doubao-Seed-Evolving的表现仍然比较扎实。
无论是更长上下文处理能力、复杂任务稳定性，还是对第三方工具链的适配，都体现出它正在尝试减少开发者在模型选择和维护上的额外投入。
END
关注+星标，获取AI前沿进展与优质开源项目