这次字节重点说了豆包 Seed 2.1 和 Seedance2.5，也介绍了下新的图像和音频模型。做了个图大家可以了解下。
这次主力模型豆包大模型 2.1，引起了不少关注。
有一个细节点不知道大家是否关注，在之前的豆包大模型 1.6、 1.8、2.0，是没放过多的主流评测的基准测试，这次放了不少，而且表现都还挺亮眼。
所以，以前，豆包大模型在 Coding 和 Agent 上的能力表现，可以说比较一般，和顶流模型之间差距还是有不少的。但豆包大模型 2.1 看起来有些不一样，看了发布会上的 case，有个还挺强的，豆包 2.1 Pro 模型搭建 3 D 虚拟城市场景，可实现 500 余个智能 Agent 同步协作，完成上千轮工具调用，生成超百栋建筑。价格方面，豆包 2.1 Pro 每百万 Tokens 输入价格为 6 元、输出价格为 30 元，缓存命中价格仅 1.2 元，较 Claude Opus 4.6 降低近 80%。
我也没闲着，第一时间对豆包 2.1 Pro 做了测试，一些 demo 我就不放了，我想看看它在实际复杂工程中的表现，其 Agent Coding 能力表现。大家都知道，我整了个开源项目 WeSight，还是收获了不少用户的喜欢，今天 Cherry Studio 业务负责人还发消息来说好几个客户都推荐 WeSight 了。
非常开心能被喜欢。除了在开发 WeSight 桌面端 Agent ，我同步在开发的还有 WeSight 的 Obsidian 插件和 WeSight Cli。其中 WeSight 的 Obsidian 插件，之前用 feble 5 整了一个初版，目前，勉强可用，但能力上还需要迭代。就比如它现有的配置是这样子的。
在插件页面，实际上会只展示 local cli，模型供应商和模型的展示和选择都很不智能，下拉效果很差。
WeSight 的客户端版本效果就很 nice，选择引擎后可自由切换配置选择。
确定是本机配置或者 WeSight 配置后，选择对应的模型供应商可选择对应的模型。
我打算用豆包 2.1 Pro 来重新开发这个功能。首先，我先在 WeSight 中选择 wesight-obsidian 这个插件项目工程文件夹，然后选择 Claude Code 引擎，选择我配置的最新 doubao-seed-2-1-pro-260628 模型。
这里大家只需要把自己的火山引擎 API Key 复制过来就好了，WeSight 已经做了适配。
我把在 WeSight 的客户端的截图效果丢进去给豆包 2.1 Pro，然后输入如下指令：
在插件选择对应的引擎后我希望有二级选择框，可以选择是本机配置还是交给wesight配置。具体UIJ交互效果参考给你的截图。先改 claude code 这个引擎
doubao-seed-2-1-pro 拿到截图后，并没有急着动手写代码，而是先对截图做了视觉理解，提取 UI 的布局结构、交互层级和组件关系。
这一步体现的是 VLM（视觉语言模型）能力。它能直接把截图中的 UI 元素映射为具体的前端组件结构，理解下拉框的层级嵌套、配置项的数据流向。紧接着，它开始主动探索项目的代码结构，定位到模型选择器的核心逻辑文件，逐步阅读上下游依赖，理解现有的数据模型和状态管理方式。
说实话这个「先读后写」的工作流，和一个靠谱的开发者拿到需求后的行为模式是一样的。先搞清楚现有架构，再决定怎么改，上来就糊代码的毛病它没有。在实际修改代码的过程中，doubao-seed-2-1-pro 展现出了不错的自主 debug 能力。它会在写完一段逻辑后主动做推理验证，预判潜在的类型错误和边界条件，发现问题就自行回退修复，不需要人工干预。
不过也不是完全不翻车，中间有一处配置项的状态同步逻辑，它第一次写的时候没考虑到异步加载的时序问题，导致初始渲染时下拉框是空的。好在它自己跑了一遍逻辑推演，发现了这个 race condition，然后加了一层 fallback 处理。几分钟后，第一个任务完成。
打开 Obsidian 验证一下，引擎选择器已经支持二级配置切换了。本地模式对应 Claude Code 本机环境配置，切到 WeSight 模式后，就能直接走 WeSight 的统一配置管理，不用再到处翻配置文件。
好，第一步搞定了，接下来要做更复杂的部分：选择不同配置源后，需要动态渲染对应的模型供应商列表，并支持二级展开选择具体模型。这涉及到多层级联动、异步数据拉取和状态持久化，复杂度比第一个任务高不少。继续在 WeSight 里给 doubao-seed-2-1-pro 下指令：
选择完本机配置或者wesight配置后，需要展示当前所属的供应商，然后二级菜单展开可选择供应商对应的模型，可以自行选择，交互参考截图。
这次 doubao-seed-2-1-pro 的处理思路依然很清晰：先分析截图中的交互层级，再对照现有代码做增量开发。比较值得一提的是，它在开发过程中发现了原有配置源逻辑的一个 bug，配置切换后供应商列表没有正确刷新。它没有绕过去，而是顺手把这个存量问题也修了。
这种「修路的时候顺便把旁边的坑也填了」的行为，对于 Agent Coding 来说是个加分项。很多模型在遇到已有代码的问题时，要么直接忽略，要么报错退出，能主动识别并修复上下文中的存量缺陷，说明它的代码理解深度是够的。整个第二轮任务完成。
打开 WeSight 的实时监控面板，可以看到这轮任务从接收指令到代码修改完成，实际耗时 2.5 分钟。
加起来任务耗时 1 个小时，跑完一个涉及多级联动选择器、异步数据源切换、状态持久化的完整功能开发，这个速度对于 Agent Coding 场景来说，属于国内第一梯队的水平。重启 Obsidian 验证，模型服务商和模型的路由切换完全正常。
而且最终呈现的交互效果和 WeSight 客户端几乎一致，说明 doubao-seed-2-1-pro 的多模态理解已经超越了「识别文字」的层面，真正把截图中的视觉信息转化为了可执行的前端逻辑，包括组件层级、交互状态、数据流转这些。当然，客观说一句，整个过程中它的 token 消耗并不算少，推理过程偶尔会有一些冗余的探索步骤，比如重复读取已经分析过的文件。这方面和 Claude Opus 4. 8 相比还有一定的优化空间。但综合来看，在复杂工程场景下的 Agent Coding 表现，确实比之前的豆包模型有了质的飞跃。写在最后用了一整天，说说我对豆包 2.1 Pro 的真实感受。先说值得肯定的地方。VLM 能力确实可以，给一张截图就能还原出对应的前端交互逻辑，这个在实际开发中太实用了。Agent 工作流也比较成熟，「读代码 → 理解架构 → 增量开发 → 自主 debug」这一套跑下来很流畅，中间基本不需要人工纠偏。再加上价格只有 Claude Opus 4.8 的五分之一左右，性价比摆在这里。再说说不足。token 效率还有提升空间，同样的任务，它的推理路径会比 Claude Opus 4.8 绕一些，偶尔会重复探索已经分析过的文件。另外在一些边界场景下，比如复杂的异步状态管理，第一次生成的代码质量还不够稳，需要靠自身 debug 能力来兜底。能兜住说明能力在线，但如果一次就写对，体验会更好。总的来说，豆包 2.1 Pro 让我看到了国产模型在 Agent Coding 这个方向上的实质性进步。以前说实话，豆包做 Coding Agent 我基本不会考虑，和海外顶流差距太大。但这次实测下来，至少在中等复杂度的工程任务上，豆包 2.1 Pro 已经能打了。AI Coding 这条赛道，卷起来了。对了，文中涉及到的 WeSight 完全开源，感兴趣的可以去 GitHub 搜 WeSight 体验一下，如果觉得好用，帮我点个 Star 就是最大的支持。你觉得国产模型做 Coding Agent 还差什么？欢迎评论区聊聊。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
