状态校验、权限路由、异步调度，撑起一套可以持续执行的运行时。刚刚，Anthropic 更新了 Claude 5.1，一次推出 Fable 5.1 和 Mythos 5.1。
这两个名字看起来像两档模型，实际底层用的是同一套模型。区别在于 Anthropic 把能力开放范围单独拆了出来：Fable 负责通用编码、知识工作和 Agent 任务；Mythos 面向经过验证的网络安全和生命科学研究场景，允许进入更深的工具调用和专业任务。Fable 与 Mythos 的分化，标志着 Anthropic 正式把「智力」与「权限」物理剥离。
此次更新里，另一个变化也很明显。Ramp 的一次测试中，Fable 5.1 无人值守运行了 38 小时：中途识别出实验数据中的 label artifact，重新处理数据，并行启动 6 组实验，再依据返回结果继续修改后续方案。
38 小时这个数字本身没有太多技术含义，关键在于模型没有沿着一开始的计划机械执行。实验条件变化之后，它能够修改已有判断，再继续推进任务。
这就把问题带到了长时 Agent 更基础的一层：执行时间拉长以后，系统必须持续判断，之前留下来的信息还有多少仍然有效。
01 长时 Agent 解决状态一致性
短任务里，模型看到的上下文和真实环境通常不会偏差太大。进入几个小时甚至几十小时以后，情况会完全不同。
代码可能已经被改过几轮，实验条件也可能随时变化。在 38 小时的长任务中，模型要处理的核心问题就是状态漂移：数据版本变了，早先成立的判断可能被新结果推翻；与此同时，这些旧信息仍留在上下文里。
原有的「模型论」认为，只要上下文够长，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 能够稳定维护一条越来越长的执行轨迹后，另一个问题出现了：模型判断下一步该执行某个动作，和系统允许它执行这个动作，是两件不同的事。
02 能力和执行权限被拆开
Fable 5.1 和 Mythos 5.1 使用相同的底层模型，却拥有不同的可执行范围。
这一点比单纯再发布一个更强版本更有意思，因为 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 都会被卡住。
因此，更适合 Agent 的权限系统需要做增量判断。它要保留已经确认的任务性质、现有授权范围、资源边界和历史 action，并在出现新行为时更新风险状态，而不是每次只看一个孤立请求。
这也解释了为什么 execution trace 会逐渐变成重要数据。单独看一个文件读取动作，很难判断任务性质；把文件读取、二进制分析、后续工具调用连起来，系统才能知道 Agent 实际正在推进什么任务。
从这个角度看，Fable 和 Mythos 代表的并不只是两个产品名称，而是 Anthropic 开始把 capability profile 做成 Runtime 中可以独立控制的一层。
一旦能力范围可以按任务、身份和执行状态被细分，Claude 就可以接入更专业的工具，而不需要把同样的执行权限开放给所有场景。这也是为什么 Claude 5.1 这次的科研案例会显得格外重要。
因为接下来真正复杂的，已经不是单个工具有没有能力，而是这么多专业工具怎么被组织进同一个任务。
03 科研 Agent 开始变成工作流编排
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 去描述这种系统，信息就会明显不够。
04 从回答变成完整任务
Claude 5.1 这次比较明显的一条变化，是模型成绩和 Agent 成绩开始不再是一回事。
一个任务失败，可能是模型判断错了，也可能是旧状态没有及时失效、工具调用失败、权限系统误判，或者并行任务调度出现问题。
这些原因最后可能都表现成任务没有完成，但它们对应的是完全不同的技术瓶颈。所以，Agent evaluation 需要开始分析完整 trajectory。
任务完成率依然重要，但还需要知道错误是在什么阶段出现的，出现以后能否恢复，多少 tool call 属于无效重试，多少中间结果未经验证就进入后续流程，以及完整任务消耗多少时间和计算资源。
Fable 和 Mythos 使用同一个底层模型，却因为不同 capability profile 在部分任务中产生不同表现，这本身已经说明：单独看 underlying model，很难解释最终结果。
以后即使模型权重完全不动，只修改状态管理、验证机制、权限路由或者 scheduler，Agent 完成复杂任务的能力也可能发生明显变化。这也是 Claude 5.1 这次更新中足以打破「模型论」迷信的更深一层变化。
模型负责推理，Runtime 负责让这份推理在长时间执行中保持有效；权限系统控制下一步能不能执行，工具和 scheduler 决定任务怎样推进，验证结果再反过来修改后续计划。
当这些环节真正连接起来之后，Agent 才开始具备连续承担复杂任务的基础。这或许也是云栈社区持续关注长时 Agent 工程化落地的原因。
发表于 4 天前
|
查看: 6|
回复: 0
