文章核心观点 - Anthropic发布新一代旗舰模型Claude Opus 4.6，此次升级并非常规性能修补，而是围绕长任务、复杂工作及智能体（agent）如何真正干活展开的系统性升级 [2] - 新模型在编程能力上已从单纯代码生成，扩展到更前置的任务规划以及更后置的代码审查与调试流程，使其能在大型代码库中更稳定地工作，并持续参与多阶段、长周期的工程任务 [12] - 公司通过一项为期约两周、成本约2万美元的实验，让Opus 4.6从零开始用Rust编写了一个约10万行代码的C编译器，该编译器能编译Linux内核等大型项目，展示了其在长时间运行的自治智能体团队方面的工程能力 [4][25][38] 模型性能与基准测试 - 在终端agentic编程能力（Agentic terminal coding）上，Opus 4.6得分65.4%，略高于GPT-5.2的64.7%，明显领先Gemini 3 Pro的56.2%和Sonnet 4.5的51.0% [13] - 在SWE-bench Verified（Agentic coding）上，Opus 4.6得分80.8%，与Opus 4.5的80.9%及GPT-5.2的80.0%基本处于同一水平，表明在标准化软件工程任务上能力趋同 [13][14] - 在电脑操作（OSWorld, Agentic computer use）上，Opus 4.6达到72.7%，相比Opus 4.5的66.3%有明显提升，Sonnet 4.5为61.4% [13][15] - 在Agentic search（BrowseComp）上，Opus 4.6以84.0%的得分明显领先于GPT-5.2 Pro的77.9%和Opus 4.5的67.8%，表明其在真实开放网络中定位、筛选和组合信息的能力领先 [13][16] - 在新问题解决（ARC AGI 2, Novel problem-solving）上，Opus 4.6得分68.8%，显著高于GPT-5.2 Pro的54.2%和Gemini 3 Pro的45.1%，反映其更强的泛化推理能力 [13][16] - 在长上下文信息检索（MRCR v2测试）中，Opus 4.6得分为76%，远高于Sonnet 4.5的18.5%，有效缓解了“上下文腐烂”问题，提升了在超长文本中稳定检索并利用信息的能力 [19] 技术特性与工程实践 - Opus 4.6在Beta阶段提供100万token的上下文长度，适合处理更大型的代码库和更长文档的分析 [17] - 新模型在大规模文档中检索关键信息的能力显著增强，可以在数十万token范围里持续跟踪信息，偏差更小，更容易捕捉深层细节 [18] - 长上下文的稳定性直接影响模型胜任复杂代码分析与故障诊断（如根因分析）的能力 [21] - 最醒目的新增功能是“智能体团队”，由多个智能体组成小队，可将大任务拆分成独立的子任务并行推进，目前以研究预览形式向API用户与订阅用户开放 [24] - 在为期约两周的编译器构建实验中，累计运行了近两千次Claude Code会话，消耗约20亿输入token、生成约1.4亿输出token [38] - 实验总API成本约为2万美元，该成本被认为远低于由单人甚至完整人类团队完成同等工作的成本 [4][38] 智能体团队的方法论与发现 - 实验目标是消除对“人类在线”的依赖，让Claude在无人监督下持续推进长期任务，其核心是构建一个简单的循环程序，让Claude每完成一个任务就立刻进入下一个，而非等待用户 [26] - 并行运行多个Claude实例可以缓解单一智能体的弱点：一次会话只能做一件事，以及实现分工协作 [27][28] - 并行是否有效取决于问题是否“好拆”，当任务高度耦合（如编译Linux内核）时，并行无法带来实质进展，需引入GCC作为在线对照编译器来拆分问题 [34][35] - 并行运行带来了角色分工的可能，例如有专门负责扫描合并重复代码、提升编译器性能、改进生成代码效率、审视项目设计以及维护文档的智能体 [35][36] - 系统设计必须围绕语言模型的固有限制，重点应对了“上下文窗口污染”和“时间盲”两类限制，通过优化测试框架输出和提供快速测试选项来解决 [31][32] - 团队使用简单的同步算法（通过在Git仓库中锁定文件）来避免多个智能体尝试解决同一问题，多数情况下由Claude自行决定下一步行动 [29][33] 成果评估与能力边界 - 最终产出的编译器规模约10万行代码，能够在x86、ARM和RISC-V架构上构建可启动的Linux 6.9，并可编译FFmpeg、Redis、PostgreSQL、QEMU等项目 [4][38] - 该编译器通过了GCC自身99%的torture test，并能够成功编译并运行Doom游戏 [4][38] - 编译器是一次完全的clean-room实现，开发过程中Claude未获得互联网访问权限，仅依赖Rust标准库 [38] - 整体实现已接近Opus的能力上限，新增功能或修复bug时常会破坏已有功能 [40] - 当前能力边界包括：缺乏启动Linux所需的16位x86编译能力（real mode阶段调用GCC），尚未拥有稳定可用的assembler与linker，不能完全替代真正的编译器，生成的代码效率不高（低于禁用所有优化的GCC），Rust代码质量不及专家级程序员 [40][42] - 该编译器的源码已在GitHub公开，截至统计时已获得329个star和16个fork [41]