昨天半夜 Anthropic 放出了 Opus 4.7。本来已经躺下准备睡了，消息一出来就没睡成，起来装上试了试。
4.7 的体感
没有那种"我原本搞不定的事一次过"的奇迹时刻。手头正好缺一个能被攻下的硬骨头，所以也没法验证。但放到日常工作流里用了一天，几个点我印象挺深。
指令遵循比 4.6 好一截。文档里的要求、提示词里的指令，4.7 更愿意照字面办。Anthropic 官方公告里原话是 "takes the instructions literally"。你切过去用一阵就能感觉到。
之前那种"哈哈搞定了"、结果代码跑不通的情况也少了很多。4.6 动作快，但经常是虚快——太乐观地宣布完成，一跑还是不行。4.7 在交付之前会自己先验一遍。这点它 release note 里写了，"devise ways to verify its own outputs before reporting back"。
还有一个小变化我没预期到。我手边有一个之前用 4.6 加 Codex 来回收敛很多轮的中型项目，切到 4.7 让它过一遍说"看看当初有没有啥坑"，它挑出来几个挺严重但大家之前都没意识到的问题，然后就开始改。这种"回头看"的能力提升，从短时间体感看还挺明显的。
顺带说一下，4.7 并不是内部传说中的那个 Mythos。Mythos 被 Anthropic 因为安全顾虑锁在 Project Glasswing 联盟里，只给 Amazon、Apple、Google、Microsoft 这几家内部用。4.7 按官方说法是 "less broadly capable" 的版本，大概率是同代能力树上剪下来的一个更小、更安全的分支。具体怎么训的没公开，只能猜。
但从节奏看，让我有点感慨。Opus 4.6 是 2 月 5 号发布的，4.7 是 4 月 16 号，两个多月一代新模型。这比之前快。上一次有这种"卧槽怎么又来一代"的感觉，还是 2022 年底 ChatGPT 3.5 出来没多久，23 年 3 月就跟上了 GPT-4 的那阵子。
所以一个判断习惯得调一调：不要按"当前模型能做什么"去划问题的边界。你今天绕半天搞不定、以为这事儿没法做的问题，搁三个月，下一代出来同样的方法可能就跑通了。这不是说可以躺平等模型。只是说，卡住了可以先放一放，可以多让它试几次，没必要因为今天搞不定就给这事判死刑。
OpenClaude：第一次给一个外面的开源项目合入代码
前段时间 Claude Code 的源码泄漏过一次。朋友圈里很快有人开始琢磨，这个 CLI 的提示词界面、工作流都挺顺手，能不能魔改一下让它接多模型。
我一开始是想自己搞的。让 Codex 去 Claude Code 源码里扫了一遍，问它"把这层接口抽象成多 provider，工作量多大？"。它评估完告诉我要动的东西挺多，你确定要做吗。我想了想，算了，不折腾。
结果两天后朋友圈里就有人开源了这个项目，叫 OpenClaude，拿那套泄漏的源码做底，把多模型这件事支持上去了。我直接下载装上用了一下。
一用就是一堆问题。
第一个是模型的 effort 被写死了，锁在 high，没有 xhigh。我日常用 Codex 就是要 xhigh 的，一上来就卡。第二个是 agent 调用会失败，我这边有代理环境，它一调就挂。第三个是它要开 worktree 的时候动不动就死，fast mode 也没法开，而 Codex 的 xhigh effort 思考得又慢，一等就是十几分钟，团队里试的人直接劝退了。
就让 Codex 一个一个修。模型选择改成三级的 provider → model → effort 并持久化；agent 代理那段补了补；fast mode 给 xhigh 加了个开关。本地测通了，我说你给我提个 PR 吧。它整理了一下，一股脑把所有改动塞进一个 PR 就交上去了。
PR 被打回来了。先是 CI 红了几个，过一天又收到邮件——是作者那边接的 AI PR review。格式是很典型的那种 AI 风格，挺啰嗦的，但说的点是对的："东西可以，但你一个 PR 动了几十个文件，这样没法 review，拆开再提。"
我一想确实如此。晚上在手机上打开 codex，说按这些 comments 把之前那个 PR 拆成几个小的重新提。它咔咔拆成了四个，提上去。
又过了一天再收邮件，看了一下，三个合入主干了，一个还因为 CI conflict 在收尾。
这是我第一次有代码进到一个外面跑的开源项目里。我自己的项目里也有人提 PR，但那是自家地盘。这次是一个不属于我、也不归我团队的东西把我的东西收了，感觉挺奇妙的。
坦白说，这整个链路里面我技术上的判断做得并不多。方向是我定的，问题是我报的，但每一段代码都是 agent 写的，PR 描述、拆分策略也都是它按 review 意见重新整理的。我干的事就是对、不对、继续。
Strix Halo：一个非专业人士把 prefill 推到了接近 DGX Spark
另一条平行线跑的是 AMD Ryzen AI Max+ 395（代号 Strix Halo）这台盒子的性能优化。
背景稍微解释一下。我们团队在做 KTransformers，这是清华 MADSys 实验室和 Approaching.AI 合作的 SOSP'25 论文工作，专门给 MoE 模型做 CPU/GPU 异构推理。我一开始的想法很简单：把 KTransformers 适配到 395 这台机器上。
一查发现卡在上游。KTransformers 的 KT 分支是基于 SGLang 跑的，而 SGLang 在 Strix Halo 上几乎没怎么适配过。哪怕我把 CPU 算子那一半搞定了，接上一个在这台机器上本身就很差的 SGLang，最后异构加起来还是很差。这条路走不通。
那就换思路。让 Codex 把 vLLM、llama.cpp、SGLang 三个都装上，跑个 benchmark，先看看基线在哪。
模型选的是 Qwen3-30B-A3B 的 BF16 原精度版。30.5B 总参数，3.3B 激活参数的 MoE 模型，在 Strix Halo 128GB 统一内存上跑起来刚好合适。llama.cpp 不支持 safetensors 格式，只能用 GGUF，让它先转了一遍格式。
初始 baseline 跑出来，vLLM 最好，prefill 不到 1000 tps，decode 十几 tps。llama.cpp 次之，prefill 三四百 tps，比 vLLM 差一截但稳定。SGLang 连跑都跑不通，打了几个补丁勉强跑起来，还比 llama.cpp 差。
按常理这时候就该收摊了，毕竟没啥期望。但我那段时间手里有点空闲、也有 token，就跟 Codex 说继续优化 SGLang 吧，你自己跑实验，跑完给我报告，下一轮两个方向二选一我拍板。
就这么开始了。两三天，200 多轮实验，中间我干预很少，基本就是"继续"。我也不看它每一轮具体选哪个分支，很多技术细节我本来也看不太懂。
最后跑到的数字让我自己都有点意外。prefill 到了约 1,300 tps，比最初 vLLM 那个 baseline 还高出一大截。decode 稳在 20 tps 左右，这个 BF16 的 30B MoE 在这台机器上，内存带宽基本就决定了这个上限，不期待能突破。更关键的是，跟 NVIDIA DGX Spark（GB10 加 128GB 统一内存，那台要 4000 美金的小机箱）的性能贴得很近了。原本 Strix Halo 和 Spark 在这种模型上差距大概是 4 到 8 倍。现在 prefill 基本打平。
同事看到结果第一反应是"这么夸张？正确性对不对？"。又跑了一轮正确性验证，数字对得上。
让我有点震动的其实是过程。那 1,300 tps 只是表层。我没什么 AI infra 的技术背景，Strix Halo 本来也不是我计划要优化的机器，是因为原本要优化的另一台最近下线了，手里空出时间才顺手捡起来的。两三天下来，居然能做到接近顶尖研究员手工调优的水平。花的时间和成本都没有很夸张。
走到这一步我已经在认真考虑一个以前完全不敢想的问题：要不要整理一下给 SGLang 提个 PR。作为一个非专业人士，给一个主流推理引擎贡献代码。目前东西还没拆得足够清晰，整理到成熟状态还得花点工夫。但这个想法居然已经能被认真考虑，这本身就挺新鲜。
并行变得可能了
Human-in-the-loop 我还是觉得必要。这点我认同我同事的一个观点：人经过自然选择的筛选，有真实的生存压力，所以人定目标、做取舍是相对靠谱的。Agent 没有生存压力。它一条路走得很偏、目标定义很烂，它也不会有"我这是在浪费生命"的那种焦虑，它就继续往下做。很多时候 A 和 B 之间没有绝对的对错，就是一个取舍，这个取舍得人来做。
所以让 agent 纯自治、不带人、长期运作一个复杂项目，目前还搞不定。
但 agent 强到这个程度之后，"in the loop" 需要的时间量在显著下降。你不用全程盯着了，只要在关键节点出现、做判断、给方向就够。
而且这几件事里都有大段人参与不进去的时间。SGLang 的 benchmark，一次实验跑十几分钟到半小时，我根本搭不上手。OpenClaude 那个 PR，等 CI 跑完、等作者那边 AI review 回复，一等就是几个小时到一天。4.7 让它去翻老项目挑问题，它自己读代码、做判断，我坐旁边也没法帮忙。
这些等待窗口原本是天然浪费的。现在的变化是，如果几件事的等待窗口能错开，我就可以用空出来的时间去推进另一件事。SGLang 在跑实验的时候，我去看 OpenClaude 的 PR review；OpenClaude 在等 CI 的时候，4.7 正好读完代码等我拍板。几件事就这么交错着往前走，每件事好像都没怎么被耽误。
并行太多也不好，会串频。但 2 到 3 件事，每件事的推进速度其实没什么损耗。一个项目全天专注 8 小时，不如在 3 个项目之间切着做 8 小时——真正需要深度投入的窗口加起来也就 2、3 个小时，剩下的时间原本是在等的。
这个逻辑以前在人和人之间就存在。团队里一个人在等别人 review，顺手就做点别的。现在把"别人"换成了 agent，等的周期变短了，但窗口交错的逻辑是一样的。
所以我最近在调整一个老默认。以前总说"要专注做一件事，把它做好"。这个原则我现在也不反对，但它的前提是你的时间会被这件事大量占满。如果 agent 把你在一件事上真正重度投入的时间缩到三分之一，那你那些原本被压住的好奇心和想试的念头，其实是可以放出来的。
Strix Halo 这件事本身就是个例子。这事我们团队讨论过很多次，但一直没人认真做，因为评估下来投产比一般，不值当。是我前段时间有块空闲时间，出于好奇捡起来跑了一下，才跑出了不一样的结果。
过去一年我会觉得"专注于一件事"是某种默认美德。现在我还是觉得专注重要，但"只做一件事"已经不是它最好的表达方式了。几个你真感兴趣的方向如果能同时开着，总的产出反而可能更高。
前提是每件事你都是真的感兴趣。并行做三件你不在乎的事，效率还是不行——那就是干耗。
参考资料
- Introducing Claude Opus 4.7 — Anthropic — 2026 年 4 月 16 日发布，强调指令字面化遵循、长任务一致性、输出自校验
- Introducing Claude Opus 4.6 — Anthropic — 2026 年 2 月 5 日发布，两代之间只隔两个半月
- Claude Mythos Preview — red.anthropic.com — 仅向 Project Glasswing 联盟（Amazon、Apple、Google、Microsoft、Nvidia 等）开放，官方承认 4.7 "less broadly capable"
- GPT-4 — Wikipedia — 2023 年 3 月 14 日发布，距 ChatGPT 3.5 只有四个月
- OpenClaude — 社区基于 Claude Code 泄漏源码重做的多模型 agent 框架，文内修复的几个 PR 已进主干
- kvcache-ai/ktransformers — GitHub — 清华 MADSys 与 Approaching.AI 合作的 CPU/GPU 异构 MoE 推理框架
- KTransformers @ SOSP'25 — 论文原文，prefill 4.62–19.74x、decode 1.25–4.09x 加速
- Accelerating Hybrid Inference in SGLang with KTransformers CPU Kernels — LMSYS — SGLang 与 KTransformers 的集成说明
- Qwen3-30B-A3B — Hugging Face — 30.5B 总参数、3.3B 激活，128 experts 选 8，适合大内存小显存的异构推理
- AMD Ryzen AI Max+ 395 — AMD — 16 核 Zen 5、128GB LPDDR5X-8000、Radeon 8060S iGPU
- Strix Halo LLM 性能跟踪 — llm-tracker.info — 社区 benchmark 汇总，vLLM/llama.cpp/SGLang 在 395 上的基线状态
- NVIDIA DGX Spark — NVIDIA — GB10 Grace Blackwell + 128GB 统一内存，2025 年 10 月 15 日上市