这是苍何的第 554 篇原创！
大家好，我是苍何。
这两天去参加了火山引擎 FORCE 原动力大会，一如既往，人超级多，去晚了，全程是站着听完了。
这次字节重点说了豆包 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 还差什么？欢迎评论区聊聊。
