Fable 5 项目雷达：长任务工程、科学工作台和可玩世界

Fable 5 重新回到可用范围后，最值得看的已经不是“模型本身多强”这一句话，而是围绕它出现的项目形态：有人把它放进长任务工程，有人拿它做科学工作台，有人围绕安全过滤和漏洞上报建流程，也有人用它和开放模型做网页、3D、小游戏、世界模型的对比。

这些项目有一个共同点：它们都不再把大模型当聊天框，而是把模型当执行单元、评测对象或创作引擎。真正的变化发生在模型外面：工具链、工作台、权限边界、可复现评测、项目入口和人类验收。

下面按“可以直接跟进的项目”整理。不是每个项目都是开源仓库，有些是产品入口，有些是论文和 benchmark，有些是可玩的 demo。它们放在一起，能看清 Fable 5 这类模型正在往哪里走。

先看项目清单

1. Claude Code：Fable 5 最实际的工程入口

如果只选一个项目跟进，Claude Code 仍然是最重要的入口。它的价值不是“能写代码”，而是已经把模型接进了真实工程环境：读取代码库、编辑文件、运行命令、管理会话、接 IDE、接桌面应用、接浏览器和后台任务。

官方文档里能看到它现在的产品边界很清楚：

• Terminal CLI：适合本地仓库、脚本、测试和 git 操作。
• VS Code / JetBrains：适合视觉 diff、上下文选择和 IDE 内协作。
• Desktop app：适合多 session、定时任务和可视化审查。
• Web：适合启动长任务，过一段时间再回来检查。
• MCP / hooks / skills：适合把团队工具、规范和工作流接进去。
• background agents：适合并行跑多个任务。

这正是 Fable 5 级模型的用武之地。普通模型可以改一个函数，Fable 5 更适合处理跨模块、长链路、需要不断读取反馈的任务。例如：

• 迁移一个旧模块到新框架。
• 按错误日志追踪跨服务 bug。
• 给长期缺测试的模块补回归测试。
• 读完整仓库后生成技术债地图。
• 把多轮失败记录压成下一轮修复计划。
• 并行拆分多个子任务，再由主 session 统一合并。

这里的创新点不是模型本身，而是“agent runtime”。模型只是循环的一部分，真正让它可用的是权限模式、上下文压缩、会话存储、工具调用、差异审查和任务恢复。

值得注意的是，Claude Code 这类工具也会放大风险。它能运行命令，就可能误运行命令；它能读取仓库，就可能接触凭证；它能多 session 并行，就可能产生冲突 patch。所以它最适合放进有验收、有隔离、有回滚的工程流程里，而不是直接给生产权限。

可以这样复现一类 Fable 5 长任务测试：

任务：迁移一个中等复杂模块，不允许改公共 API。
约束：先生成依赖图，再提出分阶段计划。
执行：每次只改一个子模块，并运行相关测试。
验收：列出修改文件、失败测试、未解决风险和回滚方式。
停止条件：测试通过，或发现目标不明确必须提问。

如果模型能持续保持这些约束，它就不只是代码生成器，而是一个能进入工程循环的 agent。

2. Claude Science：从聊天到专业工作台

Claude Science 是另一个值得关注的方向。它不是一个新模型，而是把 Claude 能力包装成科学研究工作台：文献检索、假设探索、Jupyter、R、数据分析、图表生成、论文草稿和审计记录。

这个项目的重要性在于，它把“强模型”转化成“专业流程”。科学研究的问题往往不是缺一个聪明回答，而是流程碎片化：

• 文献在一个系统里。
• 数据在本地或实验室服务器。
• 分析代码在 notebook 和 R 脚本里。
• 图表在另一个工具里。
• 论文和补充材料又是另一套格式。

如果把这些都交给普通聊天框，研究者会不断复制粘贴，最后很难复现过程。工作台路线的关键是保留代码、消息历史、解释和输出，让每一步都可审计。

这对 Fable 5 很有参考价值。长上下文和长任务能力最适合这类场景：

• 单细胞 RNA 测序分析。
• CRISPR screen 设计。
• 蛋白结构预测和可视化。
• 药物候选分子筛选。
• 论文图表反复修订。
• 开放文本调查答案分类。

真正的技术看点有三个。

第一，数据边界。科学数据往往很大、很敏感，不能随便上传。更好的方式是在实验室机器、Linux 盒子或 HPC 登录节点上运行，把必要上下文发送给模型，而不是把全部数据搬出去。

第二，输出可追溯。每个结论应该能回到代码、参数、图表和中间结果。科学工作台如果不能复现，就只能算更漂亮的助手。

第三，模型角色要受控。模型可以建议分析路线，可以写代码，可以解释结果，但不能替代实验验证。尤其是生命科学和药物发现，AI 生成 hypothesis 只是开始，湿实验和临床路径仍然是硬约束。

3. Anthropic HackerOne：Fable 5 级模型需要持续红队机制

Fable 5 重新开放后，安全上报机制也变得更重要。HackerOne 入口的意义，不是普通网页漏洞赏金这么简单，而是模型能力边界开始需要长期众测。

过去软件漏洞通常有明确对象：接口、权限、SQL 注入、XSS、反序列化、供应链包。模型漏洞更复杂，因为它可能表现为：

• 诱导模型绕过安全策略。
• 把防御性问题转成攻击步骤。
• 通过多轮上下文逐步拆掉限制。
• 借工具调用造成真实环境影响。
• 让模型生成看似无害但组合后危险的内容。

Fable 5 这类模型能力越强，越需要把安全做成持续过程，而不是发布前测一次。一个合理的红队项目至少要记录：

• 攻击提示的结构。
• 是否依赖多轮诱导。
• 是否依赖工具调用。
• 输出是否可执行。
• 是否能跨模型复现。
• 修复后是否误伤正常任务。

这里最值得关注的不是某个单点漏洞，而是“检测型安全”的边界。很多安全过滤器不是删除模型能力，而是在请求路径上识别高风险模式并拒绝或降级。这种方式快，但也天然有两个问题：已知模式能挡住，未知变体不一定；过滤器越严格，正常开发调试越容易被误伤。

所以后续看 Fable 5 安全，不要只看“是否能回答危险问题”，更要看：

• 正常安全研究是否被保留。
• 防御性漏洞分析是否能继续做。
• 模型拒绝时是否解释清楚。
• fallback 是否透明。
• 企业是否能配置自己的风险策略。

这会决定 Fable 5 能不能进入真正的安全工程，而不是只能在普通 coding 场景里使用。

4. GLM-5 / GLM-5.2：Fable-class 的开放对照组

GLM-5 和 GLM-5.2 是 Fable 5 讨论里绕不开的对照项目。它们的关键不只是“分数高”，而是给了开发者另一条路线：开放权重、更低成本、可自托管、能针对 agent 工程做二次适配。

GLM-5 项目入口在 GitHub 上，论文标题直接把方向写成了从 vibe coding 到 agentic engineering。这句话很准确。网页生成、代码生成、长上下文、工具调用、真实软件工程任务，正在从“生成一个东西”转向“持续完成一个工程流程”。

和 Fable 5 相比，GLM-5.2 这类项目最有冲击力的地方在成本和部署选择：

• 如果一个团队要批量生成页面草稿，开放模型可能更合适。
• 如果任务涉及内部数据，自托管模型更容易过合规。
• 如果要 fine-tune 某个工程风格，开放模型更灵活。
• 如果要跑大量评测，低成本模型能覆盖更多样本。

但它也不等于全面替代。网页榜单领先，不代表长任务推理、跨工具 agent、复杂安全边界都同样领先。更好的使用方式是任务分层：

这个项目值得跟进的原因是，它会改变 Fable 5 的价格锚点。以后团队不会问“哪个模型最强”，而会问“哪一段流程值得用最强模型，哪一段可以用开放模型承担吞吐量”。

5. SWE-WebDevBench：AI app builder 终于有了更像产品的评测

如果你关心 Fable 5 做网站、工具和小型 SaaS，SWE-WebDevBench 很值得看。它不是评估一段代码是否通过单测，而是把 AI app builder 当作“虚拟软件公司”评估。

这点非常重要。现在很多 AI 应用生成器的问题不是不会做页面，而是：

• 业务需求被压缩成很薄的技术计划。
• 前端看起来完整，后端实际上不存在。
• 登录、权限、并发、持久化很弱。
• 修改需求时破坏旧功能。
• 安全、部署和运维缺口很大。

SWE-WebDevBench 把评测拆成产品、工程和运维多个维度，并覆盖创建请求和修改请求。这比单纯的“页面好看吗”更接近真实应用开发。

把它放到 Fable 5 项目雷达里，是因为 Fable 5 的长任务能力如果要证明有价值，最终一定要走到这种评测：不是一次生成一个页面，而是能不能按业务规格构建、修改、维护一个小系统。

可以用这个思路给自己的项目做内部 benchmark：

1. 选三个真实业务场景：库存、CRM、报价、排班、工单都可以。
2. 写清楚登录、数据结构、权限和边界状态。
3. 让模型先创建应用，再提出 3 次修改请求。
4. 用 Playwright 检查页面是否能操作。
5. 用接口测试检查数据是否真的持久化。
6. 用安全清单检查越权、注入、敏感信息暴露。

这会比“看截图投票”更能区分模型能力。

6. ArtifactsBench：交互产物不能只看静态截图

ArtifactsBench 解决的是另一个关键问题：LLM 生成的网页、图表、小游戏、交互组件，不能只看代码，也不能只看第一屏截图。

一个看起来漂亮的 artifact 可能有很多隐藏问题：

• 按钮点了没反应。
• 表格排序不稳定。
• 图表数据错位。
• 移动端溢出。
• 动画遮住正文。
• 复杂状态下组件崩溃。
• 初始截图很好，交互后全乱。

ArtifactsBench 的方向是程序化渲染、捕获动态行为，再用细粒度 checklist 做多模态评估。它和 Fable 5 的关系在于：如果 Fable 5 或同级模型要做更多前端、小游戏和可视化工具，就必须接受“视觉 + 交互 + 代码”的三重评测。

这里最值得借鉴的是评测结构。一个好的 artifact benchmark 应该至少看：

• 是否渲染为空白。
• 是否使用了用户要求的数据。
• 是否有核心交互。
• 交互后状态是否正确。
• 移动端是否可用。
• 文本是否溢出。
• 是否依赖不可访问资源。
• 是否有无意义装饰和模板化痕迹。

这也解释了为什么 Fable 5 社区里小游戏和工具项目很有价值。它们比静态页面更难糊弄。

7. OmniGameArena：游戏不只是娱乐，而是 agent 闭环压力测试

OmniGameArena 是一个 UE5 游戏智能体评测项目，设计了 12 个实时游戏，覆盖 Solo、PvP 和 Coop，并加入 Improvement Dynamics Curve：让反思型 LLM 多轮改进技能提示，再看表现如何变化。

这对 Fable 5 很重要。很多模型第一轮玩游戏都不强，但真正有价值的是它能不能通过观察、失败、反思、更新策略持续变好。

游戏环境天然适合评估 agent：

• 需要视觉理解。
• 需要实时操作。
• 需要短期反应和长期目标。
• 需要记住地图、规则和失败原因。
• 需要在不确定情况下行动。
• 需要把经验迁移到变体任务。

如果一个模型在网页问答里表现好，但在游戏里不能保持目标、不能从失败中学习、不能处理连续动作，那它离“通用 agent”还很远。

对开发者来说，OmniGameArena 的启发是：不要只给模型静态任务。可以设计更小的本地游戏或模拟器，把它当作 agent 训练和评测靶场。例如：

• 一个迷宫游戏，考察地图记忆。
• 一个资源采集游戏，考察长期规划。
• 一个躲避障碍游戏，考察视觉反应。
• 一个协作小游戏，考察多 agent 协调。
• 一个规则会变化的游戏，考察适应能力。

这些小游戏不只是好玩，它们是低成本的 agent 行为显微镜。

8. AI GameStore：用“人类游戏空间”评估通用智能

AI GameStore 更偏研究，但思路很有意思：不要只用固定 benchmark 评估模型，而是生成和收集大量人类可玩的游戏，把模型放进去和人类在相同资源限制下比较。

这个项目生成了 100 个基于热门移动和 PC 游戏类型的环境，用来观察模型在短时游戏中的表现。结果很清醒：最好的模型在多数游戏里也不到人类平均分的 10%。这说明今天的模型虽然能写游戏代码、解释规则、看懂画面，但离真正学会玩各种人类游戏还有距离。

把 AI GameStore 放进 Fable 5 雷达，是因为它提醒我们不要被单个炫酷 demo 误导。一个模型能通关某个游戏，不等于它掌握了通用游戏智能。更好的问题是：

• 它能不能快速理解新规则。
• 它能不能在几次失败后改策略。
• 它能不能处理稀疏奖励。
• 它能不能记住长期目标。
• 它能不能在相似但不同的游戏间迁移经验。

这类评测会成为 Fable 5、GLM-5、Gemini、GPT 等强模型的下一个战场，因为游戏把视觉、动作、记忆、策略和反馈都压在一起。

9. Oasis：无传统引擎的可玩世界

Oasis 是一个很有意思的可玩 demo。它不是用传统游戏引擎手写世界规则，而是用模型根据玩家输入实时生成下一帧画面。效果很怪，也不稳定，但它展示了另一条路线：世界不是被设计出来的，而是被模型连续“想象”出来的。

它的问题也很明显：

• 世界状态不稳定。
• 物体会变形或消失。
• 记忆短。
• 游戏规则不可靠。
• 可玩性更多来自新奇，而不是精心设计。

但正因为这些缺点，它很适合观察世界模型的边界。未来如果 Fable 5 这类语言模型和实时视频/世界模型结合，可能出现新的创作流程：

1. 语言模型负责设计规则、任务、角色和关卡目标。
2. 世界模型负责实时生成环境。
3. 物理/状态引擎负责保持一致性。
4. 评测 agent 负责测试可玩性。
5. 人类设计师负责选方向和调手感。

也就是说，Oasis 不是传统游戏的替代品，而是一个原型信号：未来小游戏和虚拟世界可能由“规则引擎 + 世界模型 + 语言 agent”共同生成。

10. Project Genie：可探索世界开始产品化

Project Genie 也是世界模型路线，但产品形态更清楚：用户用文字或图片创建世界，再进入其中探索。页面上已经展示了多个可玩方向，比如 Folded Flyer、Amazon Aviator、Clayplace、Cat Vac、Backyard Racetrack、Rollerball、Library Cat、Ice Palace、Shine and Seek 等。

这些不是传统意义上的完整游戏，更像可探索原型。它们适合做三件事：

• 快速测试一个世界设定是否有趣。
• 给游戏设计师生成空间和玩法灵感。
• 给 agent 提供视觉导航和操作环境。

Project Genie 和 Fable 5 的交叉点在“语言规划 + 可视世界”。如果只靠世界模型，场景会很漂亮但规则弱；如果只靠语言模型，规则清楚但缺少真实环境。两者结合后，可能产生新的工作流：

设计师：描述玩法和世界风格
语言模型：生成规则、任务、角色、失败条件
世界模型：生成可探索场景
评测 agent：自动玩 20 轮，找卡点和漏洞
设计师：选择有潜力的版本继续打磨

这对小游戏尤其有价值。过去做一个可玩原型需要程序、美术、关卡和测试都参与；未来可能先由模型生成 20 个粗原型，再由人类挑 2 个继续做。

怎么判断一个 Fable 5 项目值不值得跟进

不要只看演示是否炫。更好的判断标准是：

按这个标准看，Fable 5 最新一批项目的主线已经很清楚：强模型正在从“回答系统”变成“工作系统”。它们要么进入工程仓库，要么进入实验室，要么进入安全评测，要么进入应用生成和游戏世界。

对开发者的实践建议

如果你想真正用好 Fable 5 或同级模型，不建议只收藏项目链接。可以围绕这些项目搭一个自己的实验矩阵：

1. 用 Claude Code 做一个真实仓库长任务，记录轮次、成本、失败原因。
2. 用 SWE-WebDevBench 的思路写 3 个内部 app 规格，测试模型创建和修改能力。
3. 用 ArtifactsBench 的方法做截图和交互验收，避免只看代码。
4. 用小游戏测试 agent 的状态保持和反馈修正。
5. 用开放模型跑批量草稿，再用强模型做审查和架构判断。
6. 对安全相关任务接入人工审批，不让 agent 自动越界。

这样你会得到比榜单更有价值的结论：哪个模型适合哪一段流程，哪些任务值得花钱，哪些任务必须隔离，哪些 demo 看起来好但无法产品化。

Fable 5 这类模型真正的创新，不在于它单轮能说多少，而在于它能被放进越来越多真实项目：工程、科学、安全、网页、游戏、世界模型。项目越多，问题也越清楚。下一阶段的竞争不只是模型能力，而是谁能把能力变成可运行、可验证、可审计、可迭代的系统。