引言
一次 3 小时 32 分钟的长程 Agent 实测，以及一条留给未来版本的 baseline。
上一篇文章《Three.js 造模型，Anime.js 让它动：AI Agent 做 3D 动画的门槛低了》，讨论的是这套工具组合如何降低 3D 动画的制作门槛。写完之后，我很自然地想再往前走一步：如果把 Three.js 和 Anime.js 完整交给一个 AI Agent，只告诉它最终目标，它能不能独立跑完建模、动画、浏览器验证和视频导出？
后来我看到豆包推出了 Doubao-Seed-Evolving。它不是一个固定版本，而是一个持续更新、可以理解为“永远最新”的模型入口。我的第一反应不是只测一次“好不好用”，而是用同一道复杂任务长期复测，看看它下一次能快多少、少用多少 Token、成品又能提升多少——也就是观察它进化的能力和速度。
于是，我把 Doubao-Seed-Evolving 接入 WSL 环境下的 Claude Code，只给出一次完整提示词：从零设计一辆程序化 3D 超跑，制作零件飞入装配、成车展示、轮胎转动和驶向远方的动画，最后导出一段 60 秒 MP4。整个过程不追加技术提示，只处理必要权限。
最终，Doubao-Seed-Evolving 完成了从需求到成片的完整链路。这次结果也成为长期 baseline 的第一个数据点：以后保持同一份提示词、同一套环境和同一组验收标准，再看新版本能否更快、更省、更准确地完成同一件事。
一、Doubao-Seed-Evolving 到底是什么
Doubao-Seed-Evolving 是豆包面向 Coding 与 Agent 场景推出的持续更新模型。它最特别的地方，不在于名称本身，而在于模型入口的设计方式发生了变化：开发者持续调用同一个模型名称，背后的能力则按产品节奏滚动迭代。可以把它理解成一张始终指向最新能力的模型卡。
从目前的产品资料看，它有四个值得关注的特征：
固定入口，持续更新。 不需要每次能力升级都追着新版本号重新配置，模型入口保持不变，更新后的能力会继续由同一名称承接。
1M 超长上下文。 百万级上下文让模型可以容纳更大的代码库、更长的需求和更多工具调用历史，为数小时的连续任务提供更充足的上下文空间。
聚焦 Coding 与 Agent。 它关注的不只是生成一段代码，而是需求理解、任务拆解、文件修改、工具调用、调试验证和最终交付组成的完整链路。
可以接入现有编程工作流。 本次测试便通过兼容接口把它接入 Claude Code，让模型直接操作项目、终端和浏览器，而不是停留在聊天窗口里给建议。
这种“永远最新”的机制很方便，但也给评测带来一个新问题：同一个模型名称在不同时间调用，实际能力可能已经发生变化。因此，对 Doubao-Seed-Evolving 最有意义的观察方式，不是只留下一句“这次效果不错”，而是记录测试日期、固定任务和量化结果，长期追踪它究竟如何变化。
二、这不是一道普通的前端生成题
这次任务并不是“画一辆看起来像汽车的东西”，而是同时提出了六类相互关联的要求：
程序化建模： 车辆必须完全由代码创建，不使用现成 3D 模型、外部图片或在线素材；需要具备底盘、车身、座舱、玻璃、灯组、空气动力学部件和四套车轮，并由数十个有意义的零部件组成。
完整动画叙事： 60 秒内先建立夜间公路和零件爆炸图，再让底盘、车身、座舱、灯组和轮组分阶段飞入装配；随后展示成车、沿公路行驶，最后进入远景。
两套技术真实参与： Three.js 负责三维车辆和环境，Anime.js 负责装配、镜头、灯光与车辆运动的主要时间线，不能只是安装依赖而没有实际使用。
可控制、可跳转： 网页需要提供播放、暂停、重播和拖动时间轴功能；同一个时间点反复跳转，应得到一致画面，方便逐帧渲染。
真实浏览器验证： 模型必须在 Chrome 中检查多个关键时间点、测试播放控制并保留截图，而不是写完代码后直接宣告完成。
视频级最终交付： 生成 1800 张时间正确的画面，编码成 1920×1080、30 FPS、H.264、60 秒的 MP4，再独立核对分辨率、帧率、像素格式、帧数和时长。
这使它从一道前端题变成了一条完整的内容生产链：程序化建模、动画系统、浏览器自动化、离线渲染和视频编码缺一不可。任务越长，越能观察模型是否具备持续规划和自我修正能力。
三、测试方式：一次提示词，必要权限外不做技术辅导
测试在 Windows 的 Linux 子系统中运行 Claude Code，并连接 Doubao-Seed-Evolving API。模型在一个全新的空白项目中工作，可以安装项目依赖、编写代码、启动浏览器并生成产物。
为了保持测试结果清晰，我固定了四条规则：
-
完整提示词一次性给出，此后不追加技术方案； -
模型自行决定工程结构、建模方式、动画实现和渲染路线； -
人工只确认项目范围内的必要权限，不参与调试和代码修改； -
是否完成以实际文件和独立验证为准，而不是以模型的文字汇报为准。
这套设置主要想回答一个问题：只告诉模型目标，不在中途帮它解题，它能否自己把长链路走完？
从最终交付来看，答案是肯定的。
四、从程序化车辆到 60 秒 MP4，它交出了完整成品
模型最终完成了车辆、环境和主控制三个核心模块，共 1475 行代码。程序化汽车包含 66 个被标记和编组的主要对象；算上轮毂辐条、螺母、刹车盘、扩散器叶片和座椅等子结构，整体约有 120 个以上的三维网格对象。
车辆不是一个整体方盒，而是按底盘、车身、外饰、座舱、玻璃、灯光、轮组和细节分组装配。四套车轮均包含轮胎、轮毂、辐条、刹车盘、卡钳、轮芯和螺母。轮胎转角还会根据车辆行驶距离和轮胎半径计算，使行驶动画具备真实的运动关系。
环境部分包含 600 米公路、车道线、路肩、护栏、路灯、树木、山体、城市剪影、星空、月亮、雾和多组灯光。Anime.js 时间线则负责装配进度、镜头运动、车灯、城市灯光、行驶距离和最终淡出。
最终 MP4 大小约 13.3 MB，独立验证结果如下：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
下面这张 12 秒动图从完整成片中抽取了六个关键阶段，可以看到零件从不同方向聚合、车辆逐步成形、驶上公路并最终进入远景。
六个固定时间点的抽帧也分别对应爆炸图、装配中段、成车展示、开始行驶、公路追踪和远景收尾。
成片的不足也很直观：车辆整体外形略显粗糙，车身曲面和比例还没有达到高品质 3D 短片的精细度；部分车轮的朝向与旋转轴也没有完全匹配车辆的行驶方向。换句话说，Doubao-Seed-Evolving 已经能够建立完整的三维结构并驱动它运动，但在视觉自检、空间关系判断和细节校准上仍有提升空间。
这恰好为后续复测留下了清楚的观察指标：未来版本不仅要把动画做出来，还要更准确地发现车身比例、部件朝向和运动关系中的视觉问题，并主动修正。
至此，Doubao-Seed-Evolving 完成了从网页工程、三维场景、动画时间线到视频文件的完整闭环。对于一次没有中途技术提示的 one-shot 测试，这已经不是简单的代码生成，而是一次真正的端到端 Agent 交付。
五、3 小时 32 分钟，长程能力体现在持续推进中
整项任务从开始到最终交付约耗时 3 小时 32 分钟。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
耗时最长的部分不是写代码，而是在缺少硬件加速的浏览器环境中逐帧渲染。模型测得，一次“跳转时间点并截图”一度需要约 5.5 秒，其中场景更新与渲染约 3.17 秒，截图约 0.86 秒。
面对这一性能瓶颈，Doubao-Seed-Evolving 没有停留在等待状态，而是先进行性能测量，再尝试分批处理、补充缺失画面和断点续跑。第一轮渲染积累了 604 帧后，它保留已有结果，调整方案并继续完成剩余画面，最终得到连续的 1800 帧。
浏览器页面与开发服务之间也出现过状态不同步。模型通过重新确认当前页面、精确重启相关服务并再次检查关键时间点恢复执行，没有推翻已经完成的车辆和动画工程。
这段过程比最终成片更能说明长程 Agent 的特点：它不只需要生成代码，还要在数小时内面对性能、状态和工具链问题，保留已有进度并持续朝最终目标推进。
六、这次 one-shot 最值得肯定的三个能力
1. 能同时维护多条工作线
车辆结构、环境、动画时间线、播放控制、浏览器检查、逐帧导出和视频编码彼此关联。Doubao-Seed-Evolving 能在这些工作线之间切换，并在修改渲染方案时保留已经完成的建模与动画成果。
2. 具备产物意识，而不只停留在代码回答
除了最终 MP4，它还留下了依赖记录、源码、渲染工具、使用说明、最终报告、浏览器截图、视频抽帧和规格验证。对 Coding Agent 来说，可运行、可检查、可交付的文件比对话中的完成宣言更有价值。
3. 动画不是简单的视觉拼接
同一时间点重复跳转能够得到一致的车辆状态；代码也建立了车辆位移和轮胎转角之间的数学关系。装配顺序、镜头运动、灯光变化和公路行驶共同构成了完整叙事，而不是把几张静态画面拼成视频。
同时，代码中的运动逻辑成立，并不代表视觉结果已经完全准确。成片中部分车轮的空间朝向仍有偏差，这说明 Doubao-Seed-Evolving 已经具备组织复杂动画系统的能力，但视觉检查和三维部件校准仍是下一轮值得重点观察的方向。
七、Token 数据让这条 baseline 更完整
Claude Code 的会话统计显示，本次测试使用约 44.03 万输入 Token 和 10.30 万输出 Token，合计约 54.33 万新增输入输出；另外还有约 2550 万缓存读取 Token。
缓存读取与新增输入输出属于不同统计口径，因此本文将两项数据分别记录，不直接相加。后续版本复测时，再观察新增 Token 和缓存读取是否同步下降。
这些数据让本次测试不止有一段视频，还有一组可用于未来复测的效率基准。下一版模型如果能在保持完整交付的同时，减少重复工具往返、缩短渲染策略探索时间、降低 Token 消耗，就能更清晰地体现长程执行效率的提升。
八、不做主观排名，只记录第一条 baseline
由于这只是一次 one-shot 测试，给模型下一个通用能力分数并不严谨。更合适的做法，是把本次可核验数据完整记录下来，作为未来同题复测的起点。
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这张表比一个孤立分数更有价值。它没有把单次成功扩大成普遍结论，也没有忽略任务已经完成的事实。未来版本只需要在相同条件下重新执行，就可以直接比较时间、Token、工具轮次和成片效果。
九、如何理解这次 one-shot 的结果
一次 one-shot 只能代表这一次运行，不能直接推导出所有项目的成功率，也不能代替多轮统计测试。但它能够证明一个很重要的能力边界：在本次环境和提示词下，Doubao-Seed-Evolving 至少已经能够独立走通这样一条复杂、长周期、跨工具的生产链。
这也是为什么我认为它适合作为 baseline，而不是一次性的展示案例。
未来版本复测时，可以继续使用：
-
同一份完整提示词； -
同一套开发、浏览器和视频编码环境； -
同样从全新的空白项目开始； -
同样只确认权限，不提供技术提示； -
同样要求 1800 帧和 60 秒 MP4； -
同样记录耗时、Token、工具轮次和最终画面。
如果后续版本更快完成第一版可用页面，更早确定稳定的渲染路线，用更少上下文完成 1800 帧，并进一步提升车辆曲面、灯光、环境和镜头质感，那么“Doubao-Seed-Evolving”就会从产品名称变成一条可以持续观察的能力曲线。
结论
这次测试最直观的结果，是 Doubao-Seed-Evolving 在一次提示词、没有中途技术辅导的条件下，完成了一项同时涉及程序化建模、动画编排、浏览器调试、性能优化、逐帧渲染和视频编码的复杂任务。
它交付的不只是代码，而是一段经过独立验证的 60 秒 1080P 动画，以及支撑这段动画的完整工程与工具链。尤其是在软件渲染速度受限、逐帧任务耗时较长的情况下，它仍然能够保留进度、调整方案并完成最终交付，体现了长程 Agent 最关键的持续推进能力。
本次记录也为 Doubao-Seed-Evolving 留下了一个清晰起点：约 3 小时 32 分钟、约 54.33 万新增输入输出 Token，一次 one-shot 完成从需求到 MP4 的端到端交付。
下一次模型更新后，我们不需要重新设计一道更花哨的题。只需要让新版本在相同条件下再跑一次，看它能否更快、更省、更稳，并交出更成熟的视觉效果。这样的纵向比较，或许正是评估一款持续进化模型最合适的方式。
关于 AI 智能体研究
欢迎关注“AI 智能体研究”！这里聚焦 AI 智能体前沿成果，解析技术原理，探讨应用场景。无论是技术爱好者还是行业探索者，都能获取最新资讯与深度见解。一起探索 AI 智能体的无限可能，共赴科技未来！
如果这篇文章对您有帮助，欢迎：
🌟 点赞收藏：方便日后查阅参考
📤 转发分享：让更多同行获得有价值的信息
👀 关注我们：每日获取最新资讯，不错过关键动态
您的每一次互动，都是我们持续输出优质内容的动力。