前沿科技洞见 · 2026-08-06

Meta Muse Code 把长周期编程的胜负手从模型智力移到可恢复运行时

正在发生的事很多，这件帮你看过了

2026-08-06

一、触发新闻与一句话定义

Meta 在 2026 年 8 月 5 日发布终端编程智能体 Muse Code 测试版，并同步推出与其协同训练的 Muse Spark 1.2；系统以持久子智能体、追加式本地事件日志和可恢复执行，处理最长 24 小时、超过 1,000 次工具调用的 GPU 内核优化任务。

Muse Code 是一个面向长周期软件工程的本地终端运行时：Muse Spark 1.2 负责推理与生成，事件日志、隔离工作树、后台子智能体、审批和验证机制负责让工作跨越上下文压缩、进程崩溃与人工中断后仍能继续。

今天最容易被记住的是「24 小时」和「1,000 次工具调用」。但这两个数字并不是一场新的模型耐力表演。真正值得追的是另一件事：Meta 没有把长任务描述成一次超长对话，而是把它改造成一串可以落盘、回放、检查和接续的事件。

这一区别很小，也很大。上下文窗口解决的是模型此刻能看见多少；可恢复运行时解决的是一个软件工程任务能否在现实世界里活得足够久。

二、从诞生到当下：Meta 编程智能体的技术演进

1. 2019—2022：在生成代码之前，Meta 先学会在巨型代码库里找路

Muse Code 的起点并不是 2026 年，也不完全是大语言模型。

2019 年，Meta 公开了 Aroma。它不是聊天机器人，而是一套代码到代码的搜索与推荐系统：工程师给出一段代码，Aroma 从大规模代码库中找出结构相似的惯用写法。它被部署到 Meta 内部的 Hack、JavaScript、Python 和 Java 代码库。这个阶段的核心问题很朴素：大型组织不是缺少代码，而是代码太多、约定太散，工程师不知道正确范例藏在哪里。

这个问题后来换了外衣，却从未消失。今天的编程智能体也会写代码，但它在大型仓库中失败，往往不是不会写某个函数，而是不知道哪个模块才是修改入口、哪些“已废弃”枚举仍承担兼容责任、哪条构建命令才符合内部约定。

随后，Meta 把自动化从「推荐」推进到「修改」。2023 年公开的 SCARF 与 CodemodService 已经能在公司级代码库里执行结构化变更。SCARF 五年累计分析数亿行代码，自动删除超过 1 亿行死代码，形成 37 万多个变更请求。它不靠一个智能体自由探索，而是先证明代码确实无用，再按依赖顺序执行修改，最后把带有人类可读解释的变更交给工程师审查。

这段历史给 Muse Code 留下了三个遗产。

第一，自动写代码不能脱离变更管理。代码必须进入 diff、审查和测试，而不是停在聊天窗口里。第二，大规模修改要有可追踪的中间状态；当一次迁移横跨成百上千个目标，失败后从头再跑代价太高。第三，人在回路中并非临时补丁，而是软件交付的边界条件：机器可以执行，合并与上线仍需要明确责任人。

2. 2023—2024：Code Llama 证明模型会写，LLM Compiler 开始追问它能否优化

2023 年 8 月，Meta 发布 Code Llama。它基于 Llama 2，分为基础版、Python 专用版和指令版，提供 7B、13B、34B，后来又增加 70B。首批模型以 16K 序列训练，并展示了处理最长约 100K 输入的能力；7B 和 13B 版本还支持根据前后代码做 infilling。

Code Llama 代表当时主流的答案：把代码能力训练进模型，再让外部工具围绕模型搭建产品。HumanEval、MBPP、MultiPL-E 这类基准衡量的是一次生成能否通过测试。它们很重要，却把任务切得很短。模型做对一道题，和它在一个陌生仓库里连续工作一天，中间经历依赖安装失败、测试超时、方案回退和需求修订，是两种不同的能力。

2024 年 6 月，Meta 发布 LLM Compiler，方向开始变窄，也更贴近真正昂贵的工程问题。模型在 Code Llama 基础上继续学习 5460 亿个 LLVM IR 与汇编 token，专门处理编译器优化、反汇编和代码尺寸问题。Meta 报告称，它达到自动调优搜索约 77% 的优化潜力，x86_64 与 ARM 汇编回转到 LLVM IR 的成功率为 45%，其中 14% 完全匹配。

这里出现了后来 Muse Code 的第二条线索：复杂优化不是一次答题，而是搜索。候选代码要编译、运行、测量、与基线比较，再决定下一轮往哪里走。模型只负责提出候选，真正让结果变好的，是围绕它运转的实验循环。

3. 2025—2026 年初：编程智能体把瓶颈暴露在模型外面

到 2025 年，SWE-bench Verified 已经把 500 个经工程师确认可解的真实 GitHub 问题带进统一测试环境。它推动行业从代码补全转向仓库级修复。不过，同一模型换一套脚手架，成绩就可能明显变化。SWE-bench 官方后来专门加入 mini-SWE-agent 的「bash-only」排行，用相同的最小循环比较模型，原因正是完整排行榜混合了模型、工具、检索、重试和评审策略。

更难的 SWE-Bench Pro 把问题拉长到专业工程师可能需要数小时乃至数天完成的规模，包含多文件和大幅修改。论文报告，在统一脚手架下，当时最好的 Pass@1 仍低于 25%。短任务榜单逐渐饱和，长任务却很快坍塌。模型智力在进步，系统可靠性没有同比增长。

Meta 自己也碰到了相同的墙。2026 年 4 月，公司披露一项内部实践：面对横跨四个仓库、三种语言、4100 多个文件的数据流水线，通用编程智能体无法快速做出可靠修改。团队没有继续加长提示词，而是让 50 多个专用智能体预先阅读代码，产出 59 份精炼上下文文件，覆盖全部模块，并记录 50 多条不直观的工程约束。初步测试中，每项任务的智能体工具调用减少了 40%。

这不是「记忆越多越好」。它说明原始代码并不等于有效上下文。长任务需要一张会维护的地图：稳定规则放在外部知识层，眼前探索留在工作上下文，过期路径定期检查。2025 年末到 2026 年的多项研究也指向同一问题。CAT、ACM 等工作让智能体主动压缩、卸载和按需取回历史，因为把所有工具输出不断追加进窗口，会造成 token 压力、语义漂移和关键约束丢失。

4. 2026 年 2—4 月：Meta 把内部开发变成持续实验系统

2026 年 2 月，Meta 公开 JiTTesting：测试不再只是一套长期维护的固定用例，而是针对每次代码变更即时生成，用来捕捉该变更引入的回归。它把验证从任务末尾的一道闸，改成随修改生成的动态对手。

4 月公开的 KernelEvolve 更接近 Muse Code 的直接祖先。KernelEvolve 不让模型一次写出“最佳内核”，而是把优化形式化为树搜索。长任务运行器持续生成候选、编译、检查正确性、测性能、分析硬件利用率，再选择下一轮路径。每个搜索节点可以继承父节点经验、比较兄弟节点、合并历史，或者清空记忆重新探索。面向没有公开训练数据的 MTIA 芯片，它还会把内部架构文档和优化规则注入知识库。

这一设计很能说明 Meta 为什么拿 Hopper GPU 内核作为 Muse Code 的压力测试。内核优化拥有清晰的目标函数和严酷的验证条件：代码必须正确，速度必须可测，虚假改进很难靠文笔掩盖。它又天然需要大量迭代，适合暴露上下文膨胀、工具失败、状态丢失和局部最优。

Meta 同月公开的统一容量效率智能体平台，又补齐了组织层。平台把查询性能数据、读取实验结果、查看配置历史、搜索代码等能力拆成标准工具，再把资深工程师的判断写成可复用技能。系统据称帮助回收了数百兆瓦电力。这里的关键不是一个模型包办所有工作，而是模型、工具、技能和证据各有边界。

Muse Code 延续的正是这条线：让智能体长时间工作之前，先让工作可以被拆解、验证和恢复。

5. 2026 年 4—7 月：Muse Spark 从通用助手变成 Agent 模型

2026 年 4 月 8 日，Meta Superintelligence Labs 发布第一代 Muse Spark。官方称团队用九个月重建 AI 技术栈，模型从一开始就支持工具使用、多模态推理和多智能体编排。Meta AI 已能把一个请求分给多个并行子智能体。此时的产品重点仍是 Meta AI、社交应用和眼镜，开发者 API 只向少量伙伴预览。

三个月后，Muse Spark 1.1 把方向明确转向 agentic tasks。它提供 100 万 token 上下文，训练模型在主智能体角色中规划和分派，在子智能体角色中遵守边界并知道何时回报；同时支持主动压缩上下文。Meta 还强调它能适配不同 harness，而不是只在自家聊天界面里工作。7 月 9 日上线的 Meta Model API，是 Muse 家族第一次公开按量收费。

这个月度节奏很值得看。4 月是模型，7 月是开发者 API，8 月是模型与运行时共同发布。Meta 很快发现，只把模型交给 OpenCode、Cline 等外部脚手架，能扩大分发，却无法控制长任务体验。模型在训练时见到的任务结构、工具语义和压缩策略，若与实际运行时不同，能力会在交付环节损耗。

6. 2026 年 8 月：Muse Code 把「过程」提升为产品

Muse Code 的主循环刻意保持简单，复杂度被移到一组持续存在的后台子智能体和事件流中。子智能体不是每接到一个小问题就冷启动；它们在隔离工作树中保持活动，自主推进后续步骤，并在合适时机向主智能体汇报。这样做既减少重复检索，也让主上下文不必承载所有细节。

更关键的是追加式本地事件日志。每次模型调用、工具运行、审批和编辑都成为一个不可覆盖的事件。运行时把这条日志当作事实来源，通过回放重建状态。进程崩溃不再等于推理历史消失；暂停也不再要求用户第二天重新解释整个任务。

这与普通的聊天记录不同。聊天记录保存人和模型说过什么，事件日志还要保存系统做过什么、依据什么批准、哪个文件在哪一步被改过。前者服务于“继续对话”，后者服务于“继续执行”和“事后问责”。

Muse Code 内置 /plan、/grill 和 /goal 等工作方式：先生成需要批准的计划，再主动找计划漏洞，随后围绕目标持续运行。Muse Spark 1.2 的训练则加入运行轨迹的拒绝采样，并针对目标保持、上下文压缩和子智能体协作优化。模型与 harness 不再是两个独立产品，而是一对共同训练的系统。

在官方案例中，Muse Code 针对 NVIDIA Hopper 上的 KDA 与 MLA 内核进行迭代，单次运行最长 24 小时，工具调用超过 1,000 次。MLA 任务中，它构造了一个双内核 Triton 流水线，让共享 KV latent 同时承担 K 和 V。这里仍缺少独立复现实验，不能把官方压力测试直接写成通用生产能力。但它至少把评测单位从「一个 issue 是否修好」推到了「一个实验循环能否稳定存活」。

这也是 Muse Code 当前最强与最脆弱的地方。它把过程完整保存下来，却仍是测试版；外部用户对 24 小时运行、精确回放和内核优化收益的规模化复现尚未形成。Meta 还要求零数据留存另行申请，企业能否在审计便利与代码隐私之间得到清晰承诺，将决定这套本地日志设计能否进入高敏感代码库。

三、竞争图谱：Muse Code 与五大编程智能体的对比

这是一个竞品充分的市场，但大家其实在回答不同问题。OpenAI Codex 强在多智能体调度与云端任务，Anthropic Claude Code 强在交互式终端与可控回退，Cursor 强在完整远程开发机，Google Jules 与 GitHub Copilot coding agent 强在从 issue 到 pull request 的异步委派。Muse Code 选择的窄缝，是本地终端里的持久进程与事件溯源。

系统	主要执行位置	长任务组织方式	恢复与审计	人工控制	当前生态位
Meta Muse Code	本地终端，子智能体使用隔离工作树	持久后台子智能体，模型与 harness 协同训练	追加式事件日志，可回放、可重启	计划审批、目标与验证命令	把长任务运行时做成核心产品
OpenAI Codex	本地 CLI/IDE 与云沙箱，桌面端统一调度	多线程、多智能体并行、技能与自动化	会话历史、终端日志、测试结果、diff	沙箱权限、审查与接管	面向团队的智能体控制台
Anthropic Claude Code	本地终端，也有云端执行	主循环、后台任务、可恢复子智能体	会话恢复、JSONL 子智能体记录、checkpoint/rewind	细粒度权限、plan mode、hooks	高交互密度的终端搭档
Cursor cloud agents	隔离云 VM 或企业自托管机器	每个智能体独占开发机，可并行、离线继续	状态、分支、日志和演示产物	远程桌面接管、PR 审查	环境能力最完整的云开发者
Jules / GitHub Copilot coding agent	Google Cloud VM / GitHub Actions	从仓库 issue 异步执行并产出 diff 或 PR	计划、会话日志、提交与 PR	合并前审查，CI/CD 需额外批准	与代码托管工作流结合最紧

1. Codex：把并行智能体放进一个控制台

OpenAI 在 2025 年 5 月发布 Codex 云端智能体时，已经允许多个任务在各自预装仓库的沙箱中并行运行。2026 年 2 月的 Codex app 更进一步：每个智能体使用隔离工作树，用户在多个线程间切换、查看 diff、评论并接管。OpenAI把瓶颈定义为「人如何监督许多跨小时、天甚至周的任务」，所以产品中心是调度台，而非单个终端进程。

这条路线的优势是规模。OpenAI 公开数据称，到 2026 年 6 月，内部最重度的 1% 用户每天会产生超过 60 小时的 Codex agent turns，显然来自多个智能体并行，而不是一个人等待 60 小时。Codex SDK、Slack、IDE、GitHub 与云端把委派入口铺得很广。

Muse Code 与它的差异不在「有没有并行」，而在状态的权威来源。Codex 提供会话、日志、测试与 diff；Muse Code 把追加式事件流直接声明为运行时事实来源，并以回放实现恢复。前者更像多智能体操作台，后者更像带 event sourcing 的任务进程。对大量独立小任务，Codex 的调度面更成熟；对一个必须经历上千次工具调用、又要在中断后接着跑的单一实验，Muse Code 的设计更聚焦。

2. Claude Code：最接近的终端对手，恢复语义却不同

Claude Code 同样以终端为主，也有 subagents、background tasks、plan mode、hooks 和 checkpoint。用户可以通过 /resume 继续历史会话，通过 /rewind 同时回退代码、对话或两者。后台子智能体并行工作，完成后保留 agent ID；恢复时能带着既有上下文继续，子智能体轨迹保存为 JSONL。

从用户体验看，Claude Code 的强项是人在场时的高频协作。权限请求、计划审阅、hooks 和随时打断，把它做成一个可持续纠正的结对伙伴。它的 checkpoint 强调「回到先前状态」，适合试错；Muse Code 的事件回放强调「从已确认状态继续」，适合耐久执行。一个面向撤销，一个面向重建。

两者也共享同一限制：只要智能体能够运行命令、读取密钥并访问网络，错误就不再只是生成一段坏代码。Claude Code 对后台子智能体采用已授予权限，遇到需要新审批的动作会自动拒绝；这降低了无人值守任务越权的风险，也会让任务在缺少权限时静默受阻。Muse Code 若要证明自己更适合长时间无人看守，除了精确回放，还需公开权限继承、密钥边界和失败升级的细节。

3. Cursor：让每个智能体拥有一台真正的电脑

Cursor 把背景智能体放在隔离 Ubuntu VM 中，允许联网和安装依赖。2026 年的 cloud agents 又加入浏览器、完整桌面、截图、视频与日志，用户可以远程接管机器直接操作。企业还可将执行节点放回自己的网络，让代码、缓存、依赖和构建产物不出边界。

这是环境优先路线。很多软件任务失败，不是推理不够强，而是智能体看不到程序实际界面、无法复现交互、缺少内部依赖。Cursor 给智能体完整开发机，解决的是「它有没有手和眼」。Muse Code 的本地终端更轻、更靠近现有环境，也避免为每个任务启动完整 VM；代价是隔离质量、依赖污染和资源竞争更多落在用户机器及工作树机制上。

真实用户对云智能体的评价也揭示了另一层摩擦：异步听起来诱人，但若智能体没有主动跑类型检查和测试，最后只会交回一个需要人返工的 PR；另一方面，隔离 VM 正是一些用户愿意采用云智能体的原因，因为失败不会碰到主工作状态。Muse Code 必须用其验证技能与事件证据证明，本地便利不会换来更高的验收成本。

4. Jules 与 GitHub Copilot coding agent：把 Agent 变成一个 issue assignee

Google Jules 在安全的 Google Cloud VM 中克隆仓库，异步写测试、修 bug、升级依赖，结束时给出计划、说明和 diff。2025 年 8 月结束公测时，Google 称测试期间已产生超过 14 万项公开代码改进。GitHub Copilot coding agent 则更直接：把 issue 指派给 Copilot，它在 GitHub Actions 环境工作，持续把提交推到 draft PR；分支保护照常生效，智能体 PR 触发 CI/CD 前还需要人类批准。

它们的核心产品单位是 PR。优势是组织流程天然清楚：任务从 issue 来，结果到 PR 去，责任边界与现有 GitHub 权限体系重合。缺点也来自同一设计。大量研究、性能调优和跨仓库工作并不天然收敛成一个 issue；当中间实验比最终 patch 更重要，PR 日志很难成为完整研究记录。

Muse Code 选择保存每一次模型、工具、审批和编辑事件，因而更适合需要解释「为什么走到这里」的实验型任务。可是 PR 生态已经拥有成熟的审查、身份和合规能力。Meta 若只停在本地日志文件，就会得到可观测性，却得不到团队级治理。下一步不是再加一种日志，而是让日志进入组织已经使用的权限、保留和审计系统。

5. Muse Code 的真实位置：不是跑得最久，而是把失败当正常事件

长周期编程产品大致形成三种形态：Claude Code 代表的交互式终端，Codex/Cursor 代表的多智能体云控制台，Jules/Copilot 代表的异步 PR 工人。Muse Code 横在三者之间：它保留终端的低摩擦，用持久子智能体获得并行，用事件流获得云任务常见的耐久性。

它当前没有证明模型能力全面领先，也没有证明云生态更成熟。公开社区在发布当天对 Muse Spark 1.2 的评价相当分裂：有人看重价格与 OpenCode 兼容，也有人质疑官方没有覆盖更多主流基准，并延续对 Meta 数据使用的戒心。测试版缺少长期用户样本，任何「口碑领先」结论都为时过早。

但 Muse Code 提出了一个更接近生产系统的问题：任务会崩、工具会超时、上下文会压缩、人会离开，怎样让这些事件不把工作抹掉？

四、深度洞察

1. Meta 的优势不是突然发明了持久智能体，而是早已习惯把代码变更当生产流水线

把纵轴与横轴叠在一起，Muse Code 今天的位置就不神秘了。Aroma 教会系统在大仓库里找惯用法，CodemodService 教会系统批量修改并交付审查，LLM Compiler 把优化变成候选搜索，KernelEvolve 把搜索变成长运行实验，JiTTesting 把验证嵌入每次修改，2026 年的知识地图又把隐性工程经验放到上下文之外。

所以追加式事件日志并不是一个孤立功能。它是这条历史的自然终点：当自动变更从几步扩展到上千步，系统必须能回答哪一步发生了什么、哪项结果经过验证、失败后该从哪里继续。Meta 把数据库和分布式系统中成熟的 event sourcing 思路带进智能体运行时，让「进程状态」不再只存在模型的临时上下文中。

同样，Muse Code 的弱点也能从历史里找到。Meta 过去的优势多建立在自有代码库、内部工具、专用知识和巨大基础设施上。KernelEvolve 可以读到 MTIA 私有文档，容量效率智能体可以查询内部 profiling 与配置历史。外部开发者拿到的 Muse Code 没有这些数据层，只剩通用工具与自己的仓库。内部成功能否迁移，取决于 Meta 能否把知识接入、权限治理和验证契约也产品化，而不只是开放一个强模型和终端程序。

2. 长任务的核心稀缺品从 token 变成「可证实的进度」

行业此前把长周期能力大多映射成更长上下文。Muse Spark 1.1 有 100 万 token，其他前沿模型也不断扩窗。但 CAT、ACM 和 Meta 自己的内部实践都指出，把所有历史塞在窗口里会增加噪声，压缩又可能丢掉任务约束。

事件日志给出另一种分工。模型上下文只保存当前决策所需的工作集；完整事实留在外部事件流，必要时检索或回放；代码状态交给版本控制与工作树；正确性由测试和基准确认。这样一来，“记住一切”不再是模型的责任。

我的判断是，下一阶段的编程智能体不会用最长单次运行时间决胜，而会用单位已验证进度的成本决胜。一个智能体跑了 24 小时并不天然有价值。更重要的指标包括：每次有效提交需要多少工具调用；崩溃恢复后是否重复工作；压缩前后关键约束是否保留；人工接管时能否在几分钟内看懂；最终改进能否由独立环境复现。

SWE-bench 的 pass rate 仍会存在，但它会成为底线。长任务评测需要同时测过程完整性、恢复正确性、权限合规和人工验收负担。Muse Code 的事件流天然适合作为这类评测证据。如果 Meta 愿意开放日志格式和回放接口，它甚至可能把自己的产品特征变成行业评测接口。

3. 「精确回放」既是可靠性机制，也是治理机制

在传统软件里，日志主要帮助排障；在智能体软件里，日志还决定责任能否被还原。模型为何改了支付权限？哪个工具读取了生产密钥？某个危险命令是自动获批，还是继承了过宽权限？如果只有最终 diff，很多问题无法回答。

Muse Code 把模型调用、工具、审批和编辑统一写入事件流，理论上能复原因果链。这对金融、医疗和大型企业尤其重要。它们不只关心代码能否工作，还关心变更如何产生、谁批准了什么、证据保留多久。

但精确回放不等于自动合规。本地日志可能包含源代码、提示词、命令输出和秘密；日志越完整，泄露后的信息也越完整。若没有加密、脱敏、访问控制、保留期限和可验证删除，审计资产会变成新的敏感数据仓库。Meta 的零数据留存需要申请，也会加深企业对模型侧数据边界的追问。

它也不等于外部副作用可以安全重放。改一份尚未提交的文件，可以依靠版本控制恢复；发邮件、部署服务、删除云资源或调用付费接口，重放一次就可能执行两次。成熟的 durable execution 通常还需要工具调用的幂等键、事件序号、状态哈希、外部结果持久化和补偿动作。Muse Code 目前公开的是「可追踪、可重建」主张，还不足以证明所有工具都具备 exactly-once 语义。

因此，Muse Code 最重要的产品路线或许不是再加更多智能体，而是把事件日志做成有类型的证据系统：秘密在写入前过滤，高风险工具调用绑定审批身份，测试结果关联代码哈希，压缩摘要可追溯到原始事件，导出时支持组织保留策略。做到这一步，它才从「崩溃后能继续」走到「出事后说得清」。

4. 三个未来剧本

最可能的剧本：运行时能力迅速同质化，Muse Code 成为 Meta API 的高效分发层。

Claude Code 已有可恢复子智能体和 checkpoint，Codex 已有多智能体工作树与长期自动化，Cursor 已有自托管云智能体。追加日志、回放和后台 worker 并不存在无法复制的理论壁垒。未来一年，主流编程智能体都会补齐耐久执行。Muse Code 的差异将收缩到两点：与 Muse Spark 共同训练带来的轨迹效率，以及 Meta 用更低推理价格推动高工具调用任务。它能获得一批成本敏感、愿意在终端工作并接受 Meta API 的开发者，但未必改写市场排序。

最危险的剧本：官方长跑案例无法外部复现，隐私疑虑又抵消价格优势。

如果 24 小时内核优化依赖内部环境、精选任务或未公开基线，普通仓库中的 Muse Code 仍可能重复探索、压缩丢约束、生成难以验收的修改。长任务会放大每个小错误：单步 99.9% 可靠，连续 1,000 步仍可能只剩约 36.8% 的全程无错概率，何况现实工具调用远达不到独立同分布。与此同时，若开发者不清楚标准版、贡献者价格、训练数据使用与零留存之间的边界，完整事件日志反而会提醒他们代码暴露面有多大。结果可能是技术演示令人印象深刻，生产采用却停在试用。

最乐观的剧本：Meta 把事件流开放成跨模型的长任务协议。

Muse Spark 1.1 已强调适配不同 harness，Meta 的内部知识地图也被描述为模型无关。如果 Muse Code 进一步开放事件 schema、状态快照、审批凭证和回放接口，让 Claude、GPT、Gemini 或本地模型都能作为执行模型，那么它就不只是一条 Muse Spark 销售渠道，而会成为长周期智能体的运行底座。第三方可以在同一条事件流上接入评审模型、安全扫描器、成本路由和合规归档。Meta 过去用 PyTorch 和 Llama 获得生态影响力；这一次，真正有机会成为公共层的不是模型权重，而是「智能体工作如何被记录」的协议。

三种剧本的分水岭都不在更长时间。它在于 Meta 能否把一次 24 小时的成功，变成任何团队都能复现、审查和接管的日常工程过程。

Muse Code 开头那条追加式日志，因而也是全文的回环。我们原以为长周期智能体需要一颗永不疲倦的大脑。Meta 给出的答案更像工程史本身：可靠系统从不假设组件不会失败，它只确保失败发生后，事实还在，工作还能继续。

五、信息来源

内容由AI辅助生成，请谨慎甄别。资讯分享仅供参考，相关观点不代表主观立场，不构成任何形式的投资建议。