--- title: 'Fable 5 被禁:首个工程师不需要的模型,以及 Agentic 工程的新算账方式' video_id: D1BHGv4gB6c url: https://youtu.be/D1BHGv4gB6c title_en: "Claude Fable 5 BANNED: The First Model Agentic Engineers DON'T NEED" channel: IndyDevDan published: 2026-06-15 duration: "31:24" topics: [Agent 工程, 多 Agent 协作, 模型与能力] noted: 2026-07-07 value: A views: '1.8万' --- [![封面](https://i.ytimg.com/vi/D1BHGv4gB6c/maxresdefault.jpg)](https://youtu.be/D1BHGv4gB6c) > IndyDevDan · 31:24 · 发布 2026-06-15 · 1.8 万次观看(截至抓取) · [观看原视频](https://youtu.be/D1BHGv4gB6c) ## 主旨 IndyDevDan 在 Claude Fable 5(及 Mythos 5)因联邦出口管制令被全网下架的背景下,从 15 个 sandbox 的真实 benchmark 出发,提出三个主张用于校准 agentic 工程对前沿模型的预期与用法:用「每智能体小时价格」替代「每 token 价格」做决策、把 Fable 5 当 orchestrator/principal engineer 用、80% 工程师用 Opus 4.8 已足够,并以「更多规划、更少审阅」重塑工作流以逼近零接触工程。 ## 核心论点 1. **每 token 价格已死,真正可比的是每智能体小时价格**——Fable 5 跑了 100 万 token、花 $200,比 Opus 多花一倍、token 多 40%,但完成时间少 20%,价值锚点在时间而非 token。([[#2-观察一每智能体小时价格取代每-token-价格-0413|→ 详解2]]) 2. **Fable 5 的角色是 orchestrator/principal engineer 而非 worker**——单实例可同时编排 15 个 sandbox、Anthropic system card 专章验证「更多 agent + 强 orchestrator = 更准更快」,它只在小变更或单一子任务上才显浪费。([[#3-观察二fable-5-是-orchestrator-而非-worker-0920|→ 详解3]]) 3. **80% 工程师不需要 Fable 5,Opus 4.8 已能给出 85–90% 同等结果**——能否写出 100/200/500 行级别 spec 是关键的「需不需要」分水岭,该升级才升级。([[#4-观察三首个工程师不需要的模型-1824|→ 详解4]]) 4. **State-of-the-art 模型同时抬升地板与抬高天花板**——简单的更简单、难的更难,prompting 风格差被进一步放大,这一观察同时是乐观与警告。([[#3-观察二fable-5-是-orchestrator-而非-worker-0920|→ 详解3]]) 5. **Agentic 工程的北星是 ZTE(零接触工程)**——把规划/构建/测试/审阅/部署交给同一份好 spec,人由操作者退到只下目标与判断产出的「CEO」,「更多规划、更少审阅」是该路径的第一步。([[#5-我用-fable-5-做-agentic-工程的工作流-2243|→ 详解5]]) ## 知识点详解 ### 1. Fable 5 与 Mythos 5 的下架背景 [00:00](https://youtu.be/D1BHGv4gB6c?t=0) 铺垫上下文:Anthropic 在 6 月 23 日先把 Fable 5 从 Pro/Max/Team 订阅中下架,又在 6 月 12 日因联邦出口管制令被整体拉下,理由是发现一类 jailbreak 技术可绕过安全护栏。 作者把这一外部风波降为噪音,主张「暂时性,会回」。对 agentic 工程师有实际意义的是:Fable 5 已经在系统卡片与公开 benchmark 中暴露了关键能力指标——这是后面三条观察所依赖的实测基线,即便模型暂不可用,后续同档 Mythos 级模型必然遵循相同边界。 ### 2. 观察一:每智能体小时价格取代每 token 价格 [04:13](https://youtu.be/D1BHGv4gB6c?t=253) 这是全片第一个数字驱动的观测。同一份 5 个 spec、15 个 sandbox 的 benchmark 中,Sonnet 跑 $55 token、Opus 跑 $91、Fable 跑 $200,但 Fable 的完成时间少约 20%。如果只看每 token 价格,Fable 完败;如果看每智能体小时价格,Fable 反赢。 这背后是新算账框架的切换:在 agentic 工程里,真正的稀缺资源是 agent 时间而非 token。花 100 万 Fable token「治好癌症」比花 100 万 token「居中一个 div」划算得多——前者完成了高价值工作,后者只是给 Anthropic 捐款。[07:52](https://youtu.be/D1BHGv4gB6c?t=472) 这也是对「每 token 智能」思维的告别:前沿模型就是用更多 token 解决更难任务的,token 数上升不是浪费而是能力的物质形态。 适用范围被明确限定:任务越大、越复杂、价值越高,Fable 的相对收益才越大;普通前后端小改、迁移文件、配环境这类任务用 Fable 是浪费,[05:54](https://youtu.be/D1BHGv4gB6c?t=354) 与「更多规划、更少审阅」的省钱观一致——但同样也意味着选型策略是从工作复杂度反推模型选择,而不是从「用最好的」开始倒推。 ### 3. 观察二:Fable 5 是 orchestrator 而非 worker [09:20](https://youtu.be/D1BHGv4gB6c?t=560) 作者把 Fable 5 的角色类比到 principal engineer:它既能自己写完整段实现,真正的优势在于拆任务、委派子 agent、协调长链路执行。这一点在 Anthropic 自己的系统卡片里有专门章节验证——用同一份最强基座模型,分别在 1、3、5、10 个 async sub-agent 配置下做 multi-agent 协作 benchmark,清晰显示「agent 数翻上去,准确率提升、每任务延迟下降」。[10:14](https://youtu.be/D1BHGv4gB6c?t=614) 在实操层,作者拿单个 Fable 5 实例启动全部 15 个 sandbox(5 个 Fable + 5 个 Opus + 5 个 Sonnet)同步执行同一份 5 项 spec,并把它们各自产出的端到端应用发布到公网 URL。完成该任务,自身 session 上下文用到 600K tokens、累计 token 总量超过 200 万——若不让 Fable 委派子 agent,这些工作靠单个模型做不下来。[14:52](https://youtu.be/D1BHGv4gB6c?t=892) 这也回应了前置概念 [[Context Rot]]:无论上下文窗口多大,真正卡上限的仍是同上下文塞太多异质任务,委派是最直接的解。 这里要注意一个反直觉的细节:多 agent 编排并不总是更快,跨 agent 的 token 传递会额外吃掉时间;但「更准且更便宜地完成更复杂的任务」是确定的获胜条件。这里的三角权衡被作者点名为「performance / speed / cost trade-off triangle」:[11:25](https://youtu.be/D1BHGv4gB6c?t=685) 任何 agent 都只能选两项,前沿模型若给齐三项的前提是 harness 把任务拆得合理。 最后,作者给出一个长期成立的心智模型:「amplify compute to amplify impact」[30:40](https://youtu.be/D1BHGv4gB6c?t=1840)——更高一档的能力配更大规模的算力,得到的不是局部加速,而是天花板被重塑。这与 Meta Harness 主张的「分强项、分 harness、并行跑」在结构上对应,但本片强调的是上游 orchestrator 模型的硬实力,而不是 harness 层的设计。 ### 4. 观察三:首个工程师不需要的模型 [18:24](https://youtu.be/D1BHGv4gB6c?t=1104) 第三个观察最具实操意义,也是与营销叙事冲突最明显的一个:Fable 5 不再是「不升级就掉队」的前沿,而是「升级须有理由」的奢侈品。具体测下来,Opus 4.8 在 benchmark 跑分饱和的多数 agentic 任务上给出 Fable 85–90% 等价产出,但价格低一档、性能差距不显著。[20:41](https://youtu.be/D1BHGv4gB6c?t=1241) 作者给出升级判据的具体形态:能写 100–500 行级别的 spec、HTML 富文本带图、带验证测试步骤的那种任务,才到 Fable 的甜区;否则就是为「用最新」而多花两三倍的钱,对自家工程效率没有正向贡献。这一判据被反复用同一组 benchmark 印证——LLM 价格指数页、Hacker News 克隆、scikit-learn 模型生成器、Pi 文档问答这几类「信息复述」任务,Sonnet/Opus 都做到「不能区分 Fable 与 Opus」的程度,只有「multi-agent chat app 这种 agent-on-agent」的复杂任务,Opus 才显吃力。 更宏观的一面:State-of-the-art 模型同时是「地板推手」和「天花板推手」——能写极简单 spec 的工程师可用 Opus/Sonnet 直接推走琐事;而正在做 meta-agentic、build systems that build systems 的工程师,Fable 把天花板从「一个 1000 行 monorepo 写好」抬到「15 个 sandbox 并发编排 + 公网发布」。两者都不必原地踏步,但路径完全不同。这与上一段中的「amplify compute」一脉相承:难的任务越来越难、简单的任务越来越简单,差距由 spec 质量和 harness 投入决定,而非由模型选型单一变量决定。 ### 5. 我用 Fable 5 做 Agentic 工程的工作流 [22:43](https://youtu.be/D1BHGv4gB6c?t=1363) 收尾给出工作流骨架,核心是「plan more, review less」的方向切换:[23:46](https://youtu.be/D1BHGv4gB6c?t=1426) 不再花时间盯每一步的产物是否对,而是把所有决策前置到一份长 spec(包含 UI 细节、验证步骤、review 节点)。规划做完后,agent 自己跑规划/构建/测试/审阅/文档/部署全链。 这条路径的北星是 ZTE(Zero Touch Engineering,严格说应叫 one-touch):[28:55](https://youtu.be/D1BHGv4gB6c?t=1735) 一个 prompt 让 agent 自走完全流程并把变更推到生产。作者承认当前的多数任务并没有到此状态,但把 ZTE 当作北星会让 spec 质量与 harness 工程持续改进——这是「scale compute to scale impact」在个人工作流层面的应用,而不是临时为某次发布做工程。 作者同时也强调这是阶段性主张:典型 open-source README 改一句小错误,单 prompt 直接推到生产并不值得骄傲,真正的「agentic engineering skill」是用一份足够好的 spec 让 zte 在复杂任务上稳定重现。读到这里,[[forward-goal]] 的逻辑闭环被收紧:目标定得越清晰、规格写得更细,模型自主推进的距离就越长、可靠性就越高。 ## 可执行步骤 - [ ] 把你的 agent 任务按 spec 行数(100/200/500+)粗分档,简单档强制走 Opus/Sonnet,只有复杂档才申请 Fable 或同级模型。 - [ ] 写一份任务清单:你手头所有 agentic 任务里,「时间」是否比「token」更稀缺——若答案为是,在选模型时把「每智能体小时价格」纳入主要决策轴。 - [ ] 试着把你的下一个长任务(>200 行 spec)用「rich HTML + 步骤验证 + review 节点」写一份完整 spec,交给 single Fable 实例或对应的最强模型,观察 plan adherence 的稳定性。 - [ ] 在你的 agent harness 里加一层「主 agent 编排 + async sub-agent 执行」的结构,即便暂时只跑 Sonnet/Opus,先把通信信道建起来,避免后续切换到 Fable 时还要重构。 ## 关联 - 印证:[[2026-06-29-GLM-5.2对比MiniMax-M3：Opus迎来真正对手（模型堆叠）]] 主张的「不要选单一模型,要选一套 model stack」——本片把同一思路压实为「80% 工程师 Opus 够用」,两份笔记从不同方向收敛到同一结论:前沿模型升级要按任务复杂度反推、有意识地把不同价位模型组织成一栈。 - 印证:[[2026-07-06-CMUX实测终端复用器解决多智能体编排三大痛点]] 点出的「scale compute to scale impact」——本片从 orchestrator 模型侧给出证据(Fable 单实例跑 15 sandbox、200 万 token 工作量由 sub-agent 协作),CMUX 那篇给出的是终端/编程式访问的工具侧证据,二者共同支撑「扩算力=扩产出」这一概括。 - 印证:[[Harness]] 提示的「harness 占 90%、模型只占 10%」——本片通过 spec 长度的清晰门槛(100/200/500 行)反向印证:同一 Fable 模型,在差 spec 下是「捐款」、在好 spec 下是「principal engineer」,输出差距几乎完全由 harness 决定。 ## 一手来源与延伸 - [Fable 5 announcement](https://www.anthropic.com/news/claude-fable-5-mythos-5):Anthropic 发布 Fable 5 / Mythos 5 的官方公告,提供模型层级、Mythos 级定位与获取条件等关键信息。 - [Fable 5 system card](https://www-cdn.anthropic.com/d00db56fa754a1b115b6dd7cb2e3c342ee809620.pdf):Anthropic 官方系统卡片,视频中 multi-agent 编排章节的实测数据与 sub-agent 配置来自此 PDF。 - [Fable & Mythos access update](https://www.anthropic.com/news/fable-mythos-access):Anthropic 关于下架/访问变化的官方说明,用于核对 6 月 23 日订阅下架与 6 月 12 日联邦出口管制两段事件的具体表述。 ## 术语 - Mythos 级模型(Anthropic 自家分级):位于 Opus 之上的新档位,具备 orchestrator 级别能力与对应价格档,本视频用此标签称呼 Fable 5/Mythos 5。 - 每智能体小时价格:用单次端到端任务的总花费除以任务完成时长,作为「时间稀缺」场景下的可比指标,替代传统「每 token 价格」。 - 性能/速度/成本三角(performance/speed/cost trade-off triangle):作者给出的 agent 选型基本约束,三项至多同时满足两项,完全满足需用 harness 拆任务而非单一模型硬扛。 - 零接触工程(ZTE / Zero Touch Engineering):agentic 工程的北星状态,一个 prompt 让 agent 自走规划/构建/测试/审阅/部署全链并推到生产,作者称严格应叫 one-touch。 - Principal engineer 比喻:把 Fable 5 类比到能独立交付并懂得向下委派的资深工程师,是判断「何时该用 Fable 5」的角色心智模型。 ## 金句 > "If you can cure cancer with a million Fable tokens, $10 per million is nothing. If you're centering a div, you're making a donation to Anthropic." → 一句话把「每智能体小时价格」和「每 token 价格」两套算账方式的差距讲到极致。 > "Cloud Fable 5 is not a worker, it's a leader." → 该模型的角色定位翻盘——决定它是「奢侈品」还是「必需品」的不是能力本身,而是你交给它的任务规模。 ## 立场与利益 视频 description 末尾附有作者课程链接 `agenticengineer.com/tactical-agentic-coding?y=D1BHGv4gB6c`,带 `?y=` 后缀——这是独立创作者常见的引流归因参数,用于把 YouTube 引流关联到具体视频。因此「Fable 5 是必备的 principal engineer」「放大算力=放大产出」「Fable 改变我的 agentic 工作流」系列主张与作者自家课程「Tactical Agentic Coding」的卖点天然耦合,观看时建议把这些课程相关论断与通用共识(例如 multi-agent 编排的可观测结果、Opus 4.8 已能完成多数任务等)区分看待。同时,「Fable 5 不再是必须升级」这条结论与作者课程卖点反向,反倒是相对独立的观察、可信度更高。 ## 价值定位 适合已经在用 Claude Code 或类似 tool 写 agentic 工程、并准备升级/切换到 Fable 级模型或 Mythos 级模型的实践者——视频不重复 benchmark 跑分,而是把数字结果压成「你该不该付这个钱」的决策框架(每智能体小时价格、任务复杂度门槛、principal engineer 角色定位),并给出一份可立刻套用的 spec 写作方向。认知增量明确,但视频里没复现 benchmark 的可重现步骤,具体比例数字(20% / 200 / 600K)需自行核对再套用。重叠内容方面,与本频道 [[2026-06-29-GLM-5.2对比MiniMax-M3：Opus迎来真正对手（模型堆叠）]] 在「模型栈」思路上一致、与 [[2026-07-06-CMUX实测终端复用器解决多智能体编排三大痛点]] 在多 agent 编排的算力/工具两侧互相补完,推荐三篇交叉读以形成完整的工作流视角。 ## 自检问题 1. 作者为什么把「每 token 价格」判作已死,而改用「每智能体小时价格」做新决策轴? **答案**:Fable 5 跑完同一份 5 项 spec 用 100 万 token、花 $200,token 量和金钱都比 Opus 多,但完成时间少约 20%;若只看 token 单价会得出 Fable 完败,而在 agentic 工程里时间才是稀缺资源,因此新的可比单位是「单位时间内完成的端到端工作」。见详解2。[04:15](https://youtu.be/D1BHGv4gB6c?t=255) [04:21](https://youtu.be/D1BHGv4gB6c?t=261) 2. 为什么单 Fable 5 实例能顶下 15 个 sandbox 的端到端 benchmark,而单个 Opus/Sonnet 做不到? **答案**:Fable 5 的角色定位是 orchestrator/principal engineer——拆任务、派活、协调子 agent;真实运行的 session 把 600K token 占满、累计 200 万+ token 才完成,根本方式是把工作拆到 sub-agent 而不是单实例硬扛,这也是系统卡片「multi-agent 一章」用实验数据的命题。见详解3。[10:14](https://youtu.be/D1BHGv4gB6c?t=614) [14:52](https://youtu.be/D1BHGv4gB6c?t=892) 3. 视频给出的「不需要升级到 Fable 5」判据是什么? **答案**:能否写出 100–500 行级别、含 HTML/图片/验证步骤的长 spec——能,才到 Fable 的甜区;否则用 Opus 4.8 即可在多数任务上拿到 85–90% 等价产出,只为「跟上」而升级是把钱直接送给模型厂商。见详解4。[20:41](https://youtu.be/D1BHGv4gB6c?t=1241)