Claude Opus 4.6 让多 Agent 工作更现实，但不会自动成功
Anthropic 的 Opus 4.6、百万 token 上下文和 Claude Code 智能体团队展示了多智能体工程的价值，也暴露了成本和协调这两道还没解决的坎。
概述
Claude Opus 4.6 值得认真读，不在于它把分数又往上推了一点，而在于它让人能清楚看到多智能体工程到底在哪些场景有用、又在哪些场景会塌掉。Anthropic 这次端出更强的 Opus，重点放在更稳的长任务表现、beta 阶段的百万 token 上下文窗口、更强的知识工作能力，以及 Claude Code 里的智能体团队。能力提升是表面，真正的题目是协调。
智能体团队之所以诱人，是因为它复刻了人处理复杂工作的方式：有人盯安全，有人盯性能，有人看架构，有人补测试，最后由某个人把结论拢到一起。但大模型智能体不是不要钱的员工。每开一个，就多一份上下文、一串工具调用、一批可能犯的错和一笔 token 预算。并行确实能压缩实际耗时，可它同样会把成本、合并冲突、重复劳动和”看起来很对其实没对”的虚假信心一起放大。
从 Opus 4.6 该读出的判断很具体：它没让多智能体写代码强到能替掉一支工程团队，但读多写少、能切分、能逐项审阅的活儿，现在确实能从并行的智能体工作流里捞到好处，前提是编排写清楚、范围卡得住。这个结论窄，却能直接指导你今天怎么用。
发生了什么
2026 年 2 月 5 日，Anthropic 发布 Claude Opus 4.6，称它是公司最聪明模型的又一次升级：编码更强、做计划更克制、能撑更久的自主任务、在大型代码库里更可靠，代码审查和调试也更稳。它还第一次给 Opus 这一档模型加上了 beta 阶段的百万 token 上下文窗口。
更新铺到了 Claude、Claude Code 和开发者平台三处。官方着重提了 Claude Code 的智能体团队、为长任务做的上下文压缩、自适应思考强度和可调的努力程度。模型同时被推向日常知识工作：财务分析、研究、文档、表格和演示稿。
社区的注意力几乎都落在智能体团队和上下文上。Reddit 上有人被多个 Claude 实例并行干活的画面吸引，下一句就在问成本。HN 的评论更不留情面：多个智能体一起跑很容易把 token 烧光，尤其当系统把它们当成永远待命的工人，而不是有明确任务边界的调查员。
发布前后还伴随一批更大胆的多智能体编程实验，包括让大量智能体协作啃下大型软件任务的压力测试。这些案例抓眼球，但它们的花销和那些没收拾干净的毛边，本来也是故事的一部分，只是常被略过。
为何重要
Opus 4.6 的意义在于，它把自主编程从”一个模型干完一件事”，挪到了”一个系统协调若干个各管一摊的工人”。这是真实的架构变化。单个智能体在大型代码库里容易迷路，因为它得同时揣太多目标；拆成多个，每个去探一条分支，再由领头的智能体或人把结论合起来，迷路的概率就低了。
这套打法对读多写少、天然能并行的活儿格外合适：代码审查拆成安全、正确性、性能、可访问性、可维护性几遍各看各的；排查缺陷按子系统分头进行；选型评估一个候选库配一个智能体；迁移规划让一个去画依赖图，另一个去找风险点。
可同一套打法一进入写密集的活儿就开始危险。几个智能体一旦编辑到重叠的文件，协调成本立刻飙升：重复改同一处、误读共享状态、产出彼此打架的补丁。人类团队靠规范、归属、开会和评审消化这些摩擦，智能体团队同样需要一套协议——任务边界、锁、收件箱式汇报、摘要、验收标准，以及一个说了算的合并裁决者。少了这层，协作就退化成混乱。
所以 Opus 4.6 重要，但不神奇。它把多智能体这条路修得更好走，却没替你把协调设计这道题做掉。
技术要点
落到工程上，第一件要认清的事：多智能体系统的可靠性来自明确的工作切分。最稳的模式从来不是”让五个智能体一起解同一道题”，而是给每个智能体一个边界清晰的小问题，限死它的写权限，要求它交回结构化的发现，等汇总完再去动共享状态。
长上下文同时改变了权衡。百万 token 窗口确实能少做一些对大代码库的粗暴总结，但不保证决策更好。要在很多文件间追踪依赖时，上下文越多越有用；要从一大堆长得差不多的细节里挑出几条关键事实时，上下文太多反而成了干扰源。所以该测的是模型在上下文里”做了什么”——检索、消歧、追依赖——而不是上下文有多大。
智能体团队还需要懂成本的调度。几个智能体并行，对某些调查可能比花人工时间便宜，但这绝不自动成立。系统得知道什么时候该铺开、什么时候该收手、什么时候一个答案已经够用；没有预算控制，并行只是让你花钱更快。一句话拢起来：拿对待并发进程的方式去对待智能体，它们各自需要划定好的输入、权限、输出契约、可被取消的能力，以及一个看得懂冲突的协调者。
对建设者的影响
先从只读的团队工作流起步。多视角审查是最好的第一个用例，因为它产出的是一摞结构化建议，而不是一堆互相打架的改动。让一个智能体盯安全假设，一个查测试覆盖，一个看性能，再由领头流程把发现拢成结论，这远比让所有智能体直接上手改代码安全。
进到写工作流，就必须强制归属：一个智能体只该拥有一个模块、一条分支或一项边界清楚的任务，除非重叠是你有意设计并审过的，否则系统要主动拦掉意外交叠。共享任务清单和收件箱式汇报有用，但前提仍是那个协调者能推理依赖、能认出还没解决的冲突。
成本的呈现方式同样要紧。智能体团队若藏在一个”开始”按钮后面，用户多半会被账单吓一跳。产品该明说这一跑要起几个智能体、各自领什么活、预算多少、什么条件会让它停，并让用户在单智能体、审查团队、实现团队几档之间自己选。
往产品策略上推一层：Opus 4.6 暗示下一代真正好用的智能体工具，长相会更接近一套编排环境，而不是聊天机器人。值钱的不只是那个模型，而是任务怎么拆、怎么并行执行、记忆怎么隔离、冲突怎么处理、最后怎么审。
对研究者的影响
多智能体编程带来的一批评估难题，是单智能体评测根本照不到的。一个系统跑分更好，可能只是因为它尝试了更多次、烧了更多 token、搜索得更分散，而不是每个智能体本身更聪明。所以报告里得带上成本、智能体数量、实际耗时、工具调用次数、合并失败次数和人工干预次数，少了这些分数没法读。
合理的评测还要把探索和实现分开看。一个系统可能很擅长揪出风险，却写不出可维护的代码；可能堆出一个能编译的大件，但没人看得懂；可能把任务做完了，却在符合规格上很弱。这几种能力混在一个分数里就看不清。
百万 token 上下文也要慎重评，应把检索、消歧、依赖追踪、综合、规划拆开来测。而且智能体团队还提供了另一条路：给每个智能体更小的局部上下文，反而可能比把所有文件一股脑塞进一个巨大窗口更稳，这个对比本身就值得做成基准。
社区信号
HN 和 Reddit 的反应有价值，正因为它们能穿过发布稿的包装。大家被智能体团队点燃，下一秒就在追问能不能用上、上下文上限多少、用量怎么限、要花多少钱。一派人把团队看成保持主线程干净、把探索甩出去的好办法；另一派则报告它很快就把 token 吃光，或者表现得像每个空着的智能体都非得被塞下一个任务。
这种掺着兴奋和警惕的反应恰恰是对的。藏在底下最强的信号是：用户要的是怎么用的指引，而不是又一项能力。他们想知道智能体团队什么时候真管用、什么时候会崩、怎么配才不浪费预算。这个缺口本身就是产品机会。
该忽略什么
别把智能体团队当成雇了一支虚拟工程队。真实的团队会跨项目带着上下文、判断、责任和品味走，这些智能体团队都给不了。它能替你扛下有边界的活，但替不掉人对结果负责这件事。
也别只看那些只晒成品、却对成本、重试、代码质量、可维护性和事后人工收尾只字不提的演示。一个体量很大的生成代码库，跟一份成功的工程交付之间，差的正是这些被略过的项。
最后，别指望百万 token 上下文能把协调问题解决掉。上下文窗口只对一部分任务有帮助，协调靠的是边界、归属和验证。Opus 4.6 让模式更容易上手，但围着它的那套运转机制仍得由你来设计。