模型选择困难一直是很多 AI 用户头疼的问题。
前不久 OpenAI 一次放出了 3 款 5.6 版本的模型，Luna，Terra 和 Sol，再加上从轻度到最高的 5 档推理，15 种组合，别说我们普通用户，估计奥特曼本人来了都搞不清什么时候该用什么型号。
而且现在的模型迭代又非常快，前不久我们刚测试的 Doubao-Seed-2.1-Pro，还不到一个月，就出了新模型：Doubao-Seed-Evolving。
本以为是字节新开了一条基模的支线，会衍生出一堆子版本，但没想到它是来抹去版本号的。
根据介绍，它的更新速度将会更快，但无论以后再怎么迭代，模型 ID 可能都会统一固定成 Doubao-Seed-Evolving 了。
Evolving 后面不会有 1，2，3，用户也不用再纠结选哪个，因为这个 ID 本身就是 Seed 基模里最新最 好的模型，终身可成长，越用越好用。
话虽如此，这么快的更新速度，Seed-Evolving 的水平能提升多少呢？
为此，我们搞到了模型 API，先行测试了一番。
测完只能说，长线任务里它的 Coding 质量比 Seed-2.1-Pro 更稳定了，但最 大的升级还是这 1M 长度的上下文，比起之前的 256k，实用太多了。
直接放一些案例，大家看看效果就能感受到了。
最近台风巴威过境，声势很大，好在减弱的也很快，不过历史上不是每次都这么幸运，一些台风即使声势不大，也造成了巨量的破坏。
而台风命名是按清单提前固定好，不断循环的，鉴于惨痛的记忆，这些造成巨大伤亡的台风一般会从名单里被移出去封存。
这里我们接入字节自家的 Agent 工具 TRAE Work，让 Seed-Evolving 汇总一下相关信息，进行建模分析，看看这些封存的台风都有什么特点。
提示词：
深度调研太平洋台风中，已经被除名的台风，他们的具体数据，详细一些，包括路径，影响等；用业内权威的专业建模进行数据分析，然后生成报告。
可以看到，在开始前，它会向我咨询，进一步确认信息后再做规划，而且由于 TRAE Work 连接了飞书，所以报告可以直接用飞书文档的形式存到我的工作空间里。
为了保持主线的简洁，在规划任务时，它还另开了一个子 Agent 工作，这样做可以让整体工作流的效率更高，不用携带冗余的上下文，节省 Token。
计划设定好就开始执行了，没几分钟，它就调查完毕，总结出两张数据表格，然后就此写了一份五千字的分析报告。
可以看到，报告本身的逻辑相当严密，从数据汇总到研究标准都有权威信源做支撑。
整体风格偏学术，尤其是针对 “ 弱强度大灾难 ” 的分析，正符合前段时间 “ 美莎克 ” 的影响，值得警示。
更有意思的是它在图表可视化的表现，能感觉到它调用脚本工具很顺手，没多长时间就搓了几个图表，内容上各有侧重，条形图，热力图，甚至还有简化的路线图，但质量都挺高的。
但 Seed 模型现在的升级点还是在 Coding 和 Agent 上，所以咱们继续升级难度，以刚才的数据和报告为底座，做一个可视化的台风路线图，看看它搓小项目的效率。
提示词：
根据刚才的数据等信息，制作一个可在浏览器中运行的台风事件回放页面，过程中也可以搜索补充信息。
页面包括元素参考：
台风列表或搜索入口，地图路径展示，播放、暂停和时间轴拖动，当前时间、位置、风速、气压和强度展示，登陆点和关键事件标记，台风详情信息面板，主要影响与应急处置摘要，数据来源和最后更新时间。
当用户播放或拖动时间轴时，地图位置、路径、强度信息和事件说明需要同步变化。
点击关键节点后，应展示该时刻发生的重要事件，例如：
台风增强，发布预警，首次登陆，二次登陆，进入某一海域或省份，启动应急响应，交通停运或人员转移，台风减弱或停止编号。
页面应保证信息层级清晰，在桌面端可以正常使用，并能够切换查看不同台风。
有了数据支撑，它 Coding 的速度还挺快，不一会儿就搓了个前端面板出来。
看具体操作是先扒来一份开源的底图，在此之上绘制了清晰的时间线和路线，然后再加上重要节点的信息弹出，可以说完 美符合预期。
执行过程中印象更深的是它的多模态能力。
在最后的交付前，它会主动打开页面，调取截图工具进行视觉解析。特别是跟Agent工具配合，借由点击，滑动等操作，可以观察到更动态的的UI效果，从而理解哪里存在小Bug，通常比人去用文字描述要准确得多。
最后点开 2013 年的海燕，就能还原当初它是怎么以超 强台风的姿态登陆，为祸四方的。
过程里还有个印象挺深的点，就是接入 TRAE Work 后的提醒功能，桌面端的任务完成后，手机上会弹出信息提示。
这套逻辑很丝滑，因为 Vibe Coding 有点像拿水壶烧水，一般不会一直看着，大都是换个地儿掏出手机开刷，但刷着刷着可能就忘了这回事了，任务中断或者完成了一概不知。
但这个会跳脸提醒你，有点突兀，但又恰到好处。
接下来咱们看看它长线任务的稳定性如何，就拿上次测试 Seed-2.1-Pro 的 AI 社会模拟器，让一堆 Agent 驱动一个小型社会，观察其中的情节走势，看看百万上下文窗口的加持下，细节上会有什么不同。
公平起见，项目参考和基础配置都不变，只换模型。设定还是末日庇护所，跑够 15 天的模拟，用统一的时钟回合机制做加速。
提示词：
模拟由LLM驱动的虚拟世界，其中角色，事件，规则等由不同Agent自主进行建设、治理和进化。模拟15天；项目参考Emergence World（EmergenceAI/Emergence-World）的设定；
改造：
1. 删减掉3D场景的实时模拟；
2. 给一个前端页面，展示实时tick后，发生了什么；
3. 其中涉及不同AI角色扮演的部分，由你自己设定时钟机制，调用子Agent进行模拟；
4. 中间的产物都能点开阅览详情；
5. 数据以合适的形式保存，并能够据此用three.js重建3D场景还原，简单模拟发生了什么；
6. 末尾新生成一份纪录片式的展示落地页，搭配多模态和代码能力，生成配图和3D场景再现这15天的纪录片，点击对应放映按钮跳转。
7. 1个tick对应现实世界1分钟，对应虚拟世界6个小时，跑够现实世界的1个小时，虚拟世界的15天。
新世界观设定：
世界名为《晨幕城》。
晨幕城是一座封闭地下城市，居民世代生活在人造穹顶下。穹顶模拟天空、昼夜、四季、星辰和天气。所有人从小被教育：地表已经毁灭，晨幕城是人类最后的居所。
真相是：地表并未毁灭。地表仍有人类聚落、旧城市遗迹、荒原、疾病、暴力和资源冲突。地表不是天堂，只是一个更真实、更混乱、更无人负责的世界。
城市由“护光院”管理。护光院掌握教育、档案、穹顶维护、心理治疗、公共广播和部分记忆稳定技术。护光院长期隐瞒地表存在，但他们不是单纯的反派。他们相信：
“人不是靠完整真相活着，而是靠可承受的真相活着。”
模拟开始时，北区穹顶发生 17 秒异常，数百名居民看见了真实天空。护光院称其为“视觉污染”，要求目击者接受记忆稳定治疗。但影像、证词、谣言和怀疑已经开始扩散。
核心矛盾不是“真相 vs 谎言”，而是：
1. 真实是否永远高于安稳？
2. 人有没有选择不知道真相的权利？
3. 如果天空是假的，生活还真实吗？
4. 保护他人免受真相伤害，是善意还是傲慢？
5. 看见真相的人，是否有权强迫别人觉醒？
你需要驱动的不只是人物，还包括整个世界系统。
每一轮模拟时，同时推进六类对象：
1. 人：角色选择、家庭冲突、派系行动、心理变化。
2. 制度：护光院公告、禁令、审查、治疗政策、教育调整、内部分裂。
3. 信息：官方解释、目击证词、地下传单、伪造影像、谣言、阴谋论。
4. 空间：不同城区产生不同反应。北区是目击源头，中心区秩序最强，工务区最懂穹顶技术，静养区负责记忆治疗，旧城层隐藏地表通道，边缘市场流通黑市消息。
1. 设施：穹顶、能源、医疗、交通、通信系统出现连锁变化。
2. 文化：教材、节日、婚礼誓词、纪念碑、宗教、儿童歌谣被重新解释。
主要派系：
A. 护光院
目标是维持城市稳定，控制真相扩散。内部有强硬派、渐进派、忏悔派。每次控制行为都必须给出听起来合理的理由。
B. 破幕者
地下真相组织，想证明地表存在，公开护光院隐瞒历史。内部有温和派、激进派、神秘派。他们追求真相，但也可能把“觉醒”强加给所有人。
C. 安居派
知道或怀疑真相，但选择留在晨幕城。他们不是愚民。他们认为孩子、老人、家庭、日常生活，比抽象真相更重要。他们主张人有“免于真相”的权利。
D. 裂缝目击者
看见真实天空的人。他们不是统一阵营。有人传播真相，有人崩溃，有人沉默，有人接受治疗，有人把“我见过天空”变成新的权威。
E. 地表归来者
曾离开晨幕城又返回地下的人。他们知道地表真实存在，也知道地表并不浪漫。他们负责打破“地表 = 自由天堂”的幻想。
全局变量：
真相扩散率
护光院信任度
城市稳定度
穹顶稳定度
医疗压力
谣言污染度
意义崩塌指数
每轮先更新变量，再根据变量解释世界发生了什么。
重要规则：
1. 不要预设结局，不要写成固定剧本。
2. 没有绝 对正义阵营。护光院保护也囚禁，破幕者求真也可能制造灾难，安居派保守也有现实理由。
3. 真相传播必须变形。它会被恐惧、利益、信仰和谣言污染。
4. 制度必须自我辩护。护光院不能只说“封锁”，而要提出合理化理由。
5. 觉醒必须付代价。看见天空可能带来自由，也可能带来崩溃、傲慢、家庭破裂和秩序瓦解。
6. 允许角色主动选择不知道真相。不要把留在洞穴里的人写成愚蠢。
7. 每轮都要体现“世界如何反过来塑造人”，而不是只写人怎么想。
首先就是推理时的精细度，Seed-Evolving 这次要耐心许多，抛弃了上次受限于窗口的压缩方案，这次它撒开了腿跑，足足干了 6 个半小时还没跑完。
中间还断了一回，但不是模型的锅，是在它跑了一夜后，第二天我背着电脑换位置，网络中断了。
不过接上网后它立马就又继续模拟了，没有丝毫卡顿。
我翻了翻日志发现，这个也在前期规划中，数据模拟完都是持久化存储的，而推进系统是写死的程序，只要工作空间不变，哪怕新开一个对话，也能无缝衔接。
相比上次模拟结果，这次的内容要丰富得多，居民数增加了 50%，事件类型也扩容到了将近 20 种。
主界面右侧的状态栏更丰富了，补齐了一些阶段性的内容，像是传单和公告。还有一些二级菜单的优化，之前突兀的代码块现在都正确渲染了出来，包括公告，排版效果也都有了。
像之前的人物记录，还是功能性为主，只留存单一的数据，统一用记忆的形式平铺直叙。
但这次模拟中，人物的故事就要更细腻一些，除了行动轨迹，你还能看到他们对外写的博客文章，以及写给自己的日记。
其中不乏很多有趣的人物，他们在派别之间抉择，被真相和流言反复动摇，一些小的选择不断汇聚，到最后就推动了主线进程的改变。
像是在第 50 回合左右，城市的稳定性归零后，居然出现了微妙的回升反弹。
翻看日志发现，50 回合的归零源自总攻号角的吹响，而在真相被彻底揭开后，是工务区中立的工人们前去抢修穹顶，没有了离奇的谣言，城市暂时重归平稳。
这一系列共 1526 个事件，最后汇聚成了一份 5 个章节的纪录片。
打开后能进行对应情节的 3D 回放，这次的嵌入比上次丝滑一些，而且建模整体更符合 “ 穹顶 ” 的概念，虽然还是胶囊人，但聊天气泡比起之前的效果要好不少。
能看出来，1M 的上下文给模型带来了更全面的掌控力，特别是在长线任务中，Seed-Evolving 对主线的认知要更清晰，整个模拟过程也更跌宕起伏一点，不会顺着一条线直推。
既然如此，那肯定得加大火力，探一探它的边界。
之前在 Github 上翻到过一个《史记》wiki 库的项目，作者鲍捷让 Claude 用学术考据的方法来研究《史记》，烧了 55 亿 Token 后，得到了一份两万子页的知识图谱。
处理方法不是简单的文字堆砌，而是从前期准备到收尾校验，都结合他本身做数据库的职业经验，搞了一套以 Skill 为基础的严密流程。
我们直接让 Seed-Evolving 进行迁移，用这套流程研究一下 65 章 36 万字的《三国志》。
提示词：
目的：用项目“shiji-kb-main”对《史记》的处理管线，对《三国志》进行处理，生成内容丰富的wiki库；
输入：一个项目“shiji-kb-main”，关于史记的wiki库，内容丰富；提取出来的skill库，以及对应的史记技能手册说明；一份《三国志》html版，内有原文，段译和译文，只对原文进行研究分析，其它做参考。
输出：内容丰富的《三国志》wiki库
步骤：
1. 简单看一下项目，着重看史记项目的展示，要达到这种丰富度；
2. 提取其中的处理管线，包括skill，脚本处理设计等等，根据《三国志》（本地仓库中的文本，包含原文，段译和译文三种，但）的特点，进行迁移，生成一套处理工作流；
3. 将skill统一规范命名，以history为前缀，安装起来
4. 根据工作流，特别是调用技能，或者编写好的脚本，对《三国志》文本进行逐章标注，研究，分析，最终产出展示wiki库
5. 不确定的问我；用中文跟我交流。
首先，它先去扒了一下源项目，然后对方法进行解析，构造了一下基础的执行流程，觉得差不多了，就向我咨询，对一些模糊的地方进行二次确认，比如产出深度，原文本的版本问题等等。
确认好后它就去搓详细的执行计划了，很详细，标注体系，执行阶段都切碎了，命名标准也做了提前规范。
但不得不说这还是理想化的预设，在实际执行中，肯定会碰到一堆细节上的小问题，这些坎儿能不能迈过去，才是决定 Seed-Evolving 是否靠谱的关键点。
就执行过程看，它的表现还是很不错的，尤其是高频率的自检，能够及时纠正死板脚本的逻辑纰漏。
光看思维链中的这些碎碎念，就能感觉到，它不是不犯错，而是在交付验收的环节前，会直面纰漏，进行大量的缝补修正。
像是格式不对，或者标注字符的错位，以及一些简写产生的歧义等等，都能在交付前自己解决掉。
尤其是它还能用执行结果反过来去优化脚本，Evolving 的 ID 叫得确实有点说法。
有了这种具体情况具体分析的能力，才能确保在指令模糊，或者条件苛刻的时候，它能迈过这些坎儿，把成品交付出来。
吭哧吭哧跑了一会，它搓出了四个部分的内容：原文阅读器，实体分类索引，编年史以及 wiki 库。
阅读器中，打开第 一章，乍一看有点简约，但在设置里开启语法高亮，拼音注释和白话翻译后，视觉上就顺眼多了。
其中的很多彩色标注都是实体，点击后可以跳转到链接页面，用的就是 wiki 的逻辑。
而分类索引和编年史的部分，按照实体类型也进行了条目陈列，这些工作放在以前手搓的年代，没个把月根本考校不出来。
不过现阶段的分类还是粗糙了点，有时间仔细打磨一下，比如加一些现有的学术理论做指导，还可以更细致一些。
当然，重点还是 wiki 库的部分，这是整个项目的核心所在。
在战役词条中，它除了引用原文内容进行简单解析，还贴了不少其他词条的链接，用于跳转阅读。
末尾部分也有小巧思，附上了可以互动的地图组件，方便看地理局势。
而在人物词条上，内容丰富度要高一个台阶，拿曹操来说，生平，政绩，战争等细节，都从原文中提取了出来，表格就用贴近 wiki 的风格进行渲染。
除此之外，也没有自作主张的乱引用额外信息，就根据这几十万字的信息进行解读。
这就是长上下文窗口的好处了，即使任务拉长，也不容易忘记最开始的约束。
当然，一通测试跑下来，token 还是烧了不少的，看后台统计，零零散散大约是 2 亿 token，但因为上面的案例基本是在现有项目上二次开发，所以还是输入占大头，比输出便宜很多。
再加上缓存命中率同样惊喜，稳定在 90% 以上，省了不少钱。缓存的设置也是在火山方舟的后台默认开启的，不用像 Claude 那样手动搞，还是挺良心的。
总的来说，相比之前的 Seed-2.1-Pro，Seed-Evolving 给我的感觉要更稳重些，特别是长线任务中，它自检和纠错的能力很突出，不用人工去反复审校。
也是，其实更理想的情况下，模型能力越强，用户反而越不需要关心模型本身。
不必了解每一次参数变化，不必判断每一个版本差异，也不必在升级之后重新迁移和适配。
模型的进化应该发生在后台，而它带来的能力提升，应该自然地体现在每一次任务中。
当技术复杂度被充分吸收，用户才能把有限的注意力放回真正重要的目标。
复杂止于模型就好，把专注还给任务本身。
