Fable 5 与 GPT-5.6 Sol 工作流将氛围编程变成持续 17 小时的智能体运行

据报道，Fable 5 与 GPT-5.6 Sol 如今已成为一种 AI 开发工作流的核心，该工作流围绕每天 16 小时的编程工作和异常漫长的自主运行构建。根据一名中国开发者的说法，Fable 5 起草计划，GPT-5.6 Sol 对其提出质疑，而 Codex 则执行修订后的规范。据称，其中一次 Codex 会话持续了 17 小时。

这一说法呈现了氛围编程的一种更鲜明形态。氛围编程指的是通过自然语言指令和 AI 生成的代码来构建软件。该开发者并未要求一个模型处理整个项目，而是将架构规划、对抗式审查和实施工作分配给不同的系统。

这种分工才是真正值得关注的地方。前沿模型提供商日益将其产品宣传为完整的协作者，但这名开发者却将每个模型视为各有可预测弱点的专家。Fable 5 与 GPT-5.6 Sol 工作流假设，更好的结果来自结构化的分歧，而不是对某一个模型的忠诚。

这些数字需要谨慎看待。据报道的每天 16 小时工作和持续 17 小时的 Codex 运行，来自一个人的工作流记录，而非经过独立复现的研究。这些数字描述的是耐力和个人实践，而不是经验证的生产力或软件质量。

不过，这一说法出现得正是时候。Anthropic 于 2026 年 6 月发布了 Claude Fable 5，而 OpenAI 则于 7 月 9 日全面推出 GPT-5.6 Sol。OpenAI 还为 Codex 引入了目标模式，让开发者能够以正式方式为更长时间的智能体任务定义成果与成功标准。

这些发布共同改变了竞争问题。开发者不再需要追问哪个模型在每个类别中都能胜出。他们可以转而思考：哪个模型应该负责规划，哪个应该负责批评，以及哪个环境应该在初始提示之后继续工作。

Fable 5 与 GPT-5.6 Sol 工作流将一项工作拆分为三个阶段

据报道，该工作流将软件开发视为一个三阶段系统，每个阶段分别由不同的模型负责。

第一阶段属于 Fable 5。该开发者称，Anthropic 的模型在为大型复杂项目制定初始设计方面能力尤为出色。这种设计可以包括架构、实施阶段、依赖项选择、风险区域和验收标准。

这不只是要求模型列出编程任务。一个实用的项目计划必须维持整个系统中各部分之间的关系。它必须将产品需求与数据结构、接口、测试、迁移和运行约束联系起来。

Anthropic 将 Fable 5 定位为一种优势会随着工作时间延长和复杂度增加而增强的模型。其最初的 Fable 5 发布公告重点介绍了软件工程、科学研究、视觉和知识工作。这些是公司的说法，但与这名开发者为该模型分配的角色相符。

第二阶段交给 GPT-5.6 Sol。该开发者并未立即开始实施，而是要求 Sol 检查 Fable 5 的方案是否存在错误。据称，Sol 会找出薄弱的假设、遗漏的情况和低效的选择，然后返回一个改进版本。

这一审查步骤将一连串提示转变为一个初步的质量控制闭环。第二个模型无须重新创建整个计划。它的任务是攻击第一个模型的推理，并迫使尚未解决的问题浮现出来。

这种区别很重要，因为流畅的计划往往会在真正具备操作可行性之前显得十分完整。一个方案可能使用令人信服的术语，同时却忽略身份验证边界、故障恢复、测试覆盖率或迁移行为。另一个模型可以提供全新的上下文和不同的错误特征。

第三阶段在 Codex 内完成。经过审查的计划成为执行规范，而目标模式则为智能体提供目标和明确的成功条件。OpenAI 将目标模式描述为一种让 Codex 能够在更长任务中持续朝某个成果推进的方式。

据报道，持续 17 小时的会话是这一说法中最引人注目的部分。它表明，该开发者相信这一环境能够在无须持续提示的情况下继续浏览文件、运行命令、评估结果并修订自身工作。

然而，仅凭运行时长几乎无法说明是否成功。漫长的智能体会话可能反映出有价值的坚持、过度探索、反复失败，或三者兼而有之。原始记录并未提供公开代码仓库、完整事件日志或独立代码审查。

因此，这一工作流应被理解为一种据报道的操作模式。它不是基准测试，也不能证明每位开发者都应该复现相同的流程。

它的价值在于职责分离。规划、批评和执行分别拥有明确的负责人，与在单一而庞杂的对话中工作相比，这使故障更容易定位。

为什么模型专业化如今比模型忠诚更重要

该工作流对单模型开发方式构成了压力，因为它假定任何前沿模型都不应控制每个阶段。

AI 编程产品通常鼓励用户留在一家提供商的环境中。模型会收集上下文、提出计划、编辑文件、运行测试并解释结果。这种安排减少了摩擦，但也会将所有错误集中在同一条推理链中。

如果模型误解了早期需求，后续步骤可能会进一步强化同一个错误。生成的测试可能验证的是模型的解释，而不是用户的真实意图。最终一份润色精美的说明甚至可能掩盖最初的错误。

Fable 5 与 GPT-5.6 Sol 工作流在实施开始之前打断了这一循环。Fable 5 提出架构，但它没有最终决定权。在 Codex 将方案转化为变更之前，Sol 会从另一个模型家族的角度对其进行审查。

这类似于工程师之间的设计审查，不过这种类比存在局限。人类审查者拥有组织知识、问责意识以及处理以往故障的经验。由于两个模型都从存在重叠的公开资料中学习，它们仍可能具有相似的盲点。

这一时机也反映了前沿模型的快速变化。OpenAI 表示，GPT-5.6 Sol 在编程、知识工作、网络安全、科学、计算机使用和设计方面均有所提升。其 GPT-5.6 发布公告还引入了一种 ultra 设置，可协调多个智能体在并行工作流中协作。

Anthropic 则提出了不同的能力主张。该公司表示，随着任务变得更长、更复杂，Fable 5 的表现尤其出色。它还将该模型集成到 Claude Code 中，而在这一环境里，代码仓库上下文和工具访问能力与纯粹的对话能力同样重要。

该开发者的说法并未回答哪家公司拥有更强的编程模型。它绕过了这场竞争，根据观察到的行为分配不同职责。

这种选择给两家提供商都带来了压力。Anthropic 必须证明 Claude Code 能够像 Fable 5 进行规划那样可靠地执行任务。OpenAI 则必须证明，Sol 构建大型项目结构的能力可以与其审查和实施能力同样出色。

它还迫使开发者成为工作流设计师。选择模型不再是最终的技术决策。用户必须决定何时在系统之间转移上下文、如何表示计划，以及哪些检查必须阻止执行。

跨模型工作会带来额外开销。在将需求从一个界面复制到另一个界面时，细微差别可能会丢失。文件上下文可能不会随计划一起转移。不同工具可能会以相互冲突的方式解释同一个验收标准。

严谨的交接会有所帮助。计划应明确期望成果、受影响的组件、约束条件、验证命令，以及需要人工审查的条件。它还应区分已确认的事实与尚未解决的选择。

该文档会成为模型之间的共享接口。如果没有它，该工作流可能会变成三场彼此割裂的对话，而不是可靠的开发流程。

知识管理正是在这里进入编程闭环。架构决策、模型批评、测试证据和人工修正都需要一个持久的存放位置。可搜索的工程知识库可以在任何单次智能体会话之外保存这些决策。

结构化分歧才是机制，而不是更长的提示

该工作流的核心机制，是在授权自主智能体采取行动之前，让模型之间产生有意设计的分歧。

许多 AI 开发失败都始于过早执行。开发者描述所需功能，智能体形成不完整的理解，而在任何一方明确成功标准之前，代码变更就已经开始。

更长的提示并不会自动解决这一问题。详细的提示可能包含矛盾、无关背景或未经任何人检验的假设。更多上下文可能增加信心，却不一定提高正确性。

据报道的流程在设计与实施之间插入了一个审查关卡。Fable 5 创建一个连贯的初始方案。随后，GPT-5.6 Sol 接到一个范围更窄的任务：找出该方案中的缺陷并加以改进。

良好的对抗式审查应检查多个层面。它应检验架构是否满足产品需求、接口能否保持稳定，以及计划是否处理了故障状态。它还应识别安全、数据迁移和可观测性方面的缺口。

模型多样性有利于这种分工。不同的模型家族可能以不同方式确定证据的优先级并分解任务。第二个模型可能会发现某项模糊需求，因为它没有共享第一个模型的对话历史。

不过，使用两个品牌并不能保证判断的独立性。两个系统都可能偏爱熟悉的框架、重复常见的编程模式，或忽视需要私有业务上下文才能发现的问题。模型之间达成一致只能证明结果具有一致性，并不能证明其正确。

开发者仍有责任决定哪些批评应该改变计划。如果 Sol 提出的修正与产品的真实约束相冲突，经过润色的修订版可能会比原方案更糟。

这一流程最可靠的版本会在执行前保留人工审批关卡。这个关卡并不要求审查生成的每一行代码，而是需要检查设计中不可逆的决策、数据影响、安全边界和验收测试。

计划获得批准后，目标模式会改变执行动态。OpenAI 的 Codex 发布说明将该功能描述为一种定义目标和成功标准，然后让 Codex 朝该成果推进的方式。

目标模式非常重要，因为长时间运行的智能体所需的不只是一条初始指令。它们需要一个持久的完成定义，能够经受住中间错误、上下文变化和反复工具调用。

一个实用的目标可以要求测试通过、生成的产物符合某个模式，以及指定的用户流程正常运行。它还可以要求智能体在遇到凭据缺失、破坏性迁移或相互冲突的需求时停止。

这是一种更可控的氛围编程形式。用户仍然主要通过自然语言进行交流，但这种语言不再是即兴请求，而是变成了一份契约。

这次长达 17 小时的运行既体现了这种契约的吸引力，也揭示了它的危险。如果标准足够精确，代理就能在开发者专注于其他事务时继续解决问题。如果标准含糊不清，代理可能会花费数小时优化错误的结果。

长时间自主工作也需要检查点。代码代理应创建可供审查的阶段性里程碑、保留命令输出、总结发生变化的假设，并呈现测试失败。否则，最终差异会变得过于庞大，无法进行有意义的人工检查。

代码仓库的安全措施仍然至关重要。开发者应在独立分支上隔离工作、限制凭据权限、保护生产系统，并要求在执行破坏性操作前进行确认。自主运行时间的延长绝不意味着可以获得不受限制的权限。

因此，这套工作流并不像其广为传播的概述所暗示的那样依赖某种神奇的模型组合。它真正的机制是分阶段授权：一个系统提出方案，另一个系统提出质疑，第三个系统则在明确的边界内采取行动。

17 小时的 Codex 运行证明的是持久性，而不是质量

这一案例证明长时间自主执行具有可行性，但并不能证明最终生成的软件是正确或高效的。

原始报告给出了两个令人印象深刻的数字：每天进行约 16 小时的氛围编程，以及一项持续了 17 小时的 Codex 任务。这两个数字描述的都是行为，却都没有对产出进行受控衡量。

要证明生产力提升，就需要更清晰的基准。读者需要了解项目规模、开发者经验、被采纳的代码量、缺陷率以及审查所需的时间。这些变量均未被公开记录。

运行时长也可能产生误导。代理可能因为探索替代方案、反复修复测试或等待外部操作而耗费更多时间。另一个代理则可能通过缩小范围或悄然跳过困难要求而更快完成任务。

这种不确定性并不意味着该案例毫无价值。它告诉开发者，在将自主运行时长视为成功指标之前，应检查哪些方面。

首要衡量指标应是验收测试表现。系统是否通过了由实现代理之外的主体独立编写的测试？仅由模型生成的测试可能会编码与模型生成代码相同的误解。

第二个衡量指标应是审查负担。如果一次 17 小时的运行所产生的变更需要花费数天才能重新梳理清楚，那么表面上的时间节省就会荡然无存。一个有用的代理应减少人类理解和验证结果所需的工作量。

第三个衡量指标应是回归行为。大规模自主编辑可能会在请求的功能之外改变接口、依赖项和性能特征。通过范围狭窄的测试套件并不能揭示所有下游影响。

安全性带来了另一个问题。Fable 5 和 GPT-5.6 Sol 发布时，网络安全能力与安全防护都受到了高度关注。Anthropic 曾因一项政府指令而暂时暂停 Fable 5，随后在更新分类器后恢复了访问。

Anthropic 表示，其修订后的分类器能够在超过 99% 的案例中阻止一种已被报告的绕过方式。该公司也承认，更严格的防护措施可能会更频繁地将无害的编码和调试请求标记出来。其重新部署声明直接描述了这一权衡。

OpenAI 同样表示，GPT-5.6 对潜在有害的网络活动采用了更严格的控制措施。这类安全防护可能会中断合法工作，尤其是在代理涉及身份验证、漏洞研究或网络工具时。

长时间运行的工作流必须妥善处理这些中断，而不能将其掩盖。如果所选模型发生回退、拒绝任务或改变行为，最终报告就应记录这一事件。否则，开发者可能会错误地将完成的工作归因于某一个模型。

模型身份和配置也很重要。推理设置、工具权限、上下文限制、代码仓库指令和重试策略都可能显著改变结果。仅仅声称“Sol 纠正了 Fable”，忽略了塑造两个模型输出的周边运行框架。

公开比较已经显示出结果对任务设计的敏感程度。一位独立开发者向两个模型提供了相同的提示，要求它们构建一个交互式知识图谱。最终产生的正面对比项目提供了一个具体的比较案例，但单个项目仍然无法证明谁是普遍意义上的赢家。

因此，应将所报告的工作流作为一种流程进行复现，而不应将其当作模型排名来接受。团队可以让同一个项目采用多种规划和审查组合运行，然后比较缺陷发现情况、实现成功率和人工审查时间。

他们还应加入对照组。一次运行可由单一模型在没有跨模型审查的情况下完成规划和执行，另一次运行则采用完整的三阶段流程。这种比较可以显示额外的交接是否真正改善了结果。

尚未解决的最大问题涉及人类注意力。每天编程 16 小时可能源于热情、截止日期压力，或快速生成所形成的令人上瘾的反馈循环。它并不是适用于所有开发者的可持续生产力标准。

AI 代理可以减少打字工作量，但也可能增加监督需求。开发者仍然需要理解系统行为、评估风险，并判断代理的信心何时超出了其证据所能支持的范围。

当这套工作流让这些责任清晰可见时，它最具可信度。当长时间运行或大量输出被视为工程判断的替代品时，它就会变得危险。

三个信号将表明这套 AI 开发工作流能否长久延续

接下来的考验是这套工作流能否在不同项目中带来可重复的收益，而不是另一个代理能否运行得更久。

第一个信号是独立复现。开发者应关注那些公开保存原始计划、Sol 的批评意见、Codex 活动日志和最终审查结果的代码仓库。可复现的产物将进一步佐证结构化模型交接能够改善实际工作的说法。

复现应比较结果，而非主观印象。有用的衡量指标包括被接受的任务完成情况、独立编写的测试表现、审查期间发现的缺陷、部署后的回归问题以及人工干预总量。

如果多个项目都显示相同流程能够带来更好的结果，那么 Fable 5 和 GPT-5.6 Sol 工作流就会更像一种可持续的模式。如果结果差异很大，原始案例仍将只是一种有趣的个人方法。

第二个信号是对跨模型审查提供更深入的支持。目前，在不同提供商之间转移计划通常需要手动复制或编写自定义脚本。这个过程可能会丢失代码仓库上下文，并掩盖每项决策究竟由哪个模型更改。

开发环境可以让交接过程变得明确。它们可以保存结构化计划、请求独立批评、展示分歧，并要求在代理开始编辑前获得批准。

这类功能会将模型路由转变为一种产品能力，也能让团队跨提供商一致地应用访问控制和审计策略。

原生支持将强化这套工作流的核心主张，即专业分工至关重要。如果采用率不足，则可能表明大多数开发者更看重简洁性，而非跨模型检查。

第三个信号是长时间目标模式会话产生的证据。OpenAI 已经广泛开放了这一功能，但真正相关的问题是长时间运行下的完成质量。

应关注检查点、回滚、测试解读和透明停止条件方面的改进。这些功能比最长运行时间更重要，因为它们决定了人类能否信任并检查相关工作。

更清晰的执行轨迹将增强人们对通宵运行或持续一个工作日的代理任务的信心。关于无效循环、过大差异和隐藏假设的持续报告则会削弱这种信心。

开发者无需等待完美证据出现后再开始尝试。他们应从一个边界明确的功能入手，在执行前定义测试，并保护敏感系统。随后，他们可以将单模型运行与经过审查的跨模型运行进行比较。

最有价值的启示并不是每个人都应该编程 16 小时，或让 Codex 持续运行 17 小时，而是当规划、批评和权限彼此分离时，自主执行会变得更加安全。

Fable 5 和 GPT-5.6 Sol 工作流为这种分离提供了一种看似可行的蓝图。其吸睛的数字仍然只是个人陈述，但其底层设计值得接受受控测试。

选择一个范围明确的项目，记录每一次交接，并衡量被接受的结果，而不是生成的输出。第二个模型能否发现足够多的规划错误，从而证明增加的复杂性物有所值？还是说，这套流程只是让氛围编程显得更加严谨？