Anthropic 近日更新了 Claude 5.1，并一口气推出 Fable 5.1 与 Mythos 5.1 两个版本。尽管名称看似两档模型，二者底层实为同一套模型，区别在于 Anthropic 将能力开放范围单独拆分：Fable 5.1 负责通用编码、知识工作和 Agent 任务，Mythos 5.1 则面向经过验证的网络安全和生命科学研究场景，允许进入更深的工具调用和专业任务。这一分化标志着 Anthropic 正式将“智力”与“权限”物理剥离，也意味着模型能力与执行权限开始作为独立维度被控制。

在 Ramp 的一次测试中，Fable 5.1 无人值守运行了 38 小时，中途识别出实验中的 label artifact（标签伪影），重新处理数据，并行启动 6 组实验，并根据返回结果继续修改后续方案。38 小时本身并无太多技术含义，关键在于模型在这段时间内没有沿着一开始的计划机械执行——当实验条件发生变化，它能够修改已有判断并继续推进任务。这背后涉及长时 Agent 的核心挑战：状态一致性。

长时任务中，模型面临的上下文与真实环境可能发生严重偏差。代码可能已被修改多轮，实验条件瞬息万变，早先成立的判断可能被新结果推翻，而这些旧信息仍残留在上下文中。原有的“模型论”认为只要上下文够长 AI 就有记忆，但 Claude 5.1 的设计思路彻底否定了这一点：若不建立一套独立的、基于外部事实的状态失效机制，大模型只会守着一堆过时的“垃圾历史”一本正经地胡说八道。

例如，假设 Claude 在任务开始时读取过某个服务，并判断接口采用同步调用。几小时后，它已完成重构，接口换成新的执行路径，但最早那段分析仍保留在 conversation history 中。若后续推理再次引用旧结论，模型内部理解的任务状态就会偏离真实代码，这种偏差即 state drift（状态漂移）。单纯扩大 context window 并不能解决长期执行——上下文可以保存更多历史，却不会自动处理历史信息的有效期。

因此，真正稳定的 Agent 不能把聊天记录当作唯一状态来源。代码应重新从当前 repository 读取，实验结果应绑定具体 run ID、数据版本和配置，任务完成情况应进入单独的 task state。模型的自然语言记录可保留推理过程，但代码、实验和任务进度需各有明确的 source of truth。Ramp 那次 38 小时实验中，模型发现 label artifact 后，问题就不再是补充一句新结论——此前建立在旧数据上的结果已经失效，依赖这些结果的后续判断也需要重新处理。这涉及状态之间的依赖关系：若实验 B 建立在数据 A 上，A 被发现有问题后，B 就不能继续作为可靠依据。长任务因此需要支持 invalidation（失效机制）：某个前置状态失效时，依赖它的任务、结论和中间产物也要同步重新评估。

Claude 5.1 证明了 Agent 能熬过 38 小时，靠的不是记住所有废话，而是拥有随时清理“过时真相”的能力。一旦开始处理依赖关系，Agent 的任务状态就更接近一张动态任务图：有些节点已完成，有些在等待工具返回，有些因新结果需重新运行，有些已无继续执行必要。模型做的不是简单生成下一步，而是不断更新这张图。

但状态更新并不保证内容正确。模型生成的代码不一定能立刻成为后续任务基础，实验跑出的数字也不一定可信。若错误结果直接进入长期状态，后续所有步骤都会在错误基础上展开。因此 state management 后面必须接 verification（验证）：代码修改后需跑 compiler、unit test 或 integration test；系统诊断需看真实 runtime trace；数据处理需重新执行查询或统计检查；科研任务需读取实际实验结果。关键点在于验证信号尽量来自模型外部，否则容易产生 correlated error——模型最初理解错接口，再让它检查自己的代码，可能仍沿同一套错误假设判断。外部工具则直接给出环境反馈，编译失败、测试不过、实验结果偏离预期，这些信号不会因模型解释完整而消失。

长时 Agent 的执行由此形成循环：读取当前状态、产生动作、执行工具、读取反馈、验证结果、再决定是否写入稳定状态。只有通过验证的结果才进入后续任务依赖。这还影响恢复机制：运行几十小时的任务中，API 超时、tool process 崩溃或模型调用失败并不罕见。已通过验证的状态若未保存，一次局部异常就可能迫使任务重新解释大量历史。因此 checkpoint 的价值不是简单保存进度，而是保存一个可重新启动的可信状态：当前 task graph、workspace、已验证 artifact 及待处理任务。

当 Claude 能稳定维护长执行轨迹后，另一个问题浮现：模型判断下一步应执行某动作，与系统允许它执行该动作是两回事。Fable 5.1 与 Mythos 5.1 使用相同 underlying model，却拥有不同可执行范围，这比单纯发布更强版本更有意思——Anthropic 实际上把 model capability 与 execution permission 分开处理。模型内部可能已具备理解某类任务的能力，但某次执行能否调用该能力，还取决于任务类型、访问资格和允许使用的工具。

网络安全场景最能看清区别：Fable 可参与软件漏洞发现，但 penetration testing、exploit generation 或更深入的 binary analysis 会进入限制更严格的路径；经验证的研究人员则可访问 Mythos 对应能力范围。若 Claude 仍是聊天模型，控制相对简单——系统检查用户输入再决定是否回答即可。但长时 Agent 不同：任务开始时可能只是排查普通软件崩溃，执行几轮后开始读取 crash dump，再进入 binary analysis，任务性质可能持续变化。这意味着任务风险并非在第一个 prompt 时固定，而是随 execution trajectory 不断变化，权限判断也不能只发生在开始。

系统需持续读取当前任务状态、已执行 action、正在请求的 tool 及准备访问的资源，再重新判断当前步骤应开放到什么程度，这就是 capability routing。它与简单 allow/deny 不同：有些任务可正常继续，有些可继续分析但禁止某类工具，有些动作需额外审批，有些任务可切换到更高权限的 capability profile。Fable 和 Mythos 可理解为该机制中两种不同执行范围，而非两套完全不同的智能。问题也随之从安全过滤变成 policy state。

假设任务开始时被判断为普通 debugging，运行 8 小时后已进入完全不同的分析阶段，若权限系统仍沿用 8 小时前的分类，控制就会滞后于执行状态。但若每个 action 都从零重新判断，又易产生大量 false positive。Anthropic 因此专门优化 safeguard 误触发——长时任务中一次错误阻断影响的不仅是当前步骤，若后续三个任务依赖该 tool call，整个 dependency chain 都会被卡住。更合适的权限系统需做增量判断：保留已确认的任务性质、现有授权范围、资源边界和历史 action，并在新行为出现时更新风险状态，而非每次只看孤立请求。这也解释了为何 execution trace 逐渐成为重要数据——单独看一个文件读取动作很难判断任务性质，但把文件读取、二进制分析、后续工具调用连起来，系统才能知道 Agent 实际在推进什么任务。

Fable 与 Mythos 代表的不仅是两个产品名称，而是 Anthropic 开始把 capability profile 做成 Runtime 中可独立控制的一层。一旦能力范围可按任务、身份和执行状态细分，Claude 就能接入更专业工具，而不必将同样执行权限开放给所有场景。这也是为何 Claude 5.1 的科研案例格外重要——接下来真正复杂的已不是单个工具有没有能力，而是众多专业工具如何被组织进同一任务。

Anthropic 展示了蛋白设计、金星地形重建和 GPU kernel 优化等科研任务。这些任务虽领域不同，但内部结构接近：Claude 不直接替代领域模型，而是负责组织多个专业工具完成连续工作流。以蛋白设计为例，Mythos 需先理解研究目标，再调用蛋白设计和结构工具生成候选方案，根据计算结果筛选，再进入实验验证。LLM 主要负责 task decomposition 和下一步决策，具体结构计算仍交给专业模型。

这种工作流比普通 tool calling 复杂之处首先在时间：很多科研工具不会立即返回结果。简单查询可能几秒完成，模型训练可能持续几小时，真实实验周期更长。若 Agent 每提交任务就停下等待，系统吞吐量会很低。因此长时科研任务天然需要 asynchronous execution：模型提交实验后，Runtime 保存 job ID 和依赖关系，继续处理其他可独立执行任务；实验返回后，系统再把结果挂回对应节点，由 Claude 决定后续任务。Ramp 同时启动 6 组实验就是这种执行结构的直接例子——任务已非严格线性 chain，而是不断变化的 DAG，有些 branch 可并行，有些须等待前置结果，有些可能因新证据提前取消。

这会引出 scheduler（调度器）：多个实验同时占用计算资源时先跑哪个；某实验已足够推翻当前假设，其他高成本未完成任务是否继续；两个结果冲突时下一轮计算预算投向何方。科研 Agent 不能只有 planner，还需调度。异步任务一多，结果来源问题也浮现：Agent 拿到实验输出时，必须知道它对应哪一版数据、哪个模型版本、什么代码 commit 和参数，否则几小时后上下文同时出现多组结果时，模型易把不同配置产生的 artifact 混在一起。这就是 provenance（来源追溯）——每个重要中间产物需绑定来源链，数据版本变化后哪些实验需重跑、代码更新后哪些结果不能直接复用，都依赖 provenance 判断。这与状态一致性是同一问题在科研环境的延伸，只是依赖关系扩展到了数据、模型、实验配置和计算结果。

GPU kernel 优化又带出新变化：若科研 workflow 需重复运行某领域模型几千次，真正拖慢任务的可能是底层计算而非 Claude 本身。Mythos 5.1 可进一步修改 GPU kernel、减少中间结果重复计算，说明 Agent 已开始观察整个 workflow 的性能瓶颈，而非只决定下一个工具调用，这属于 workflow optimization。模型需判断瓶颈在推理、外部工具还是计算资源，再把优化放到收益更高处。

Anthropic 调低 cache read 价格也与此相关：长时 Agent 会不断复用稳定上下文（system instruction、tool schema、代码背景、任务规则、已确认历史状态），每轮真正变化的只是一部分新 observation 和中间结果。若这些稳定内容每次调用都完整处理，执行时间越长重复计算越明显。Prompt caching 让稳定 prefix 被反复利用，新计算集中于变化部分。这使 Agent 成本计算方式变化：单看每百万 token 单价难以判断 Agent 贵不贵，更有意义的是任务完整跑完需要多少模型调用、工具重试、外部计算及无效分支。成本单位开始从单次 inference 变成整个 episode。当状态、权限、异步任务、工具和计算资源全部进入一条 execution trajectory 后，传统单轮 benchmark 已不足以描述这种系统。

Claude 5.1 较明显的变化是模型成绩与 Agent 成绩开始不再是一回事。任务失败可能是模型判断错、旧状态未及时失效、工具调用失败、权限系统误判或并行任务调度问题，这些原因都表现为任务未完成，却对应不同技术瓶颈。因此 Agent evaluation 需分析完整 trajectory，任务完成率仍重要，但还需知道错误发生在哪个阶段——是规划、状态更新、工具执行、权限判断还是调度决策。Anthropic 此次更新表明，长时 Agent 的可靠运行已不单靠模型智力，而依赖一套包含状态管理、权限路由、异步调度与验证机制的运行时，这或许正是“模型论”走向终结的信号。