云雀 · 轻技术笔记

DeepSeek 一脚踹开中立性：当 DeepInfer / Voxtral 3 / Skills 全家桶同时下场，vllm 和三方 agent 编排层还剩几口气

AIAgentLLM大模型AIGC

过去 48 小时，整个 AI 工程栈被三件事同时炸穿。

第一件，deepseek-ai/DeepInfer 上线五天，5.2w star、8700 fork，HN 2176 分、844 条评论。一个 GitHub repo 五天收割两位数关键指标，这不是"又发了个模型"的量级，这是把开源推理框架的水面，从平静直接掀翻。

第二件，Mistral 在没有任何预告的情况下，把 Voxtral 3 推上 562 分顶榜——纯语音理解、视觉问答、实时翻译三个能力塞进同一个 endpoint，10 亿参数版本可以直接在 MacBook 上跑。

第三件，Anthropic 的 Skills 全家桶还在持续被三方抄：mattpocock/skills 一天涨 417，obra/superpowers 一天涨 169，agency-agents 一天涨 338，opencode 一天涨 412，affaan-m/ECC 一天涨 291。五条曲线在同一天同时爆。

把这三件事单独看，每一件都是"明星产品发布"的常规新闻。但把它们排在一起看，AI 工程栈的"分层撕裂"信号非常硬。我今天写一篇，不是描述这三个新闻，而是回答一个同行不太愿意正面回答的问题：当官方下场把底层、中层、协议层都自己做了，中立第三方还能不能活？

这篇文章我尽量不摆数据表、不用 PPT 体。我用我自己踩过的坑，讲清楚 vllm / 三方 agent 编排层 / 老 Git 工作流为什么在被压扁的逻辑链，以及一个技术从业者接下来该把砝码压在哪一段。

一、DeepInfer 不是"又一个大模型推理框架"，是"中立性"三个字的退场

先把 DeepInfer 摆出来。

它的 description 只有一行："DeepInfer: High-performance, large-scale inference framework for DeepSeek models"。看起来人畜无害，就是又一个 SGLang / vllm / TensorRT-LLM 的同类项。但只要你看过 DeepSeek 之前在自家 API 和自部署文档里的口径，就会明白这段 description 的真正意思：这是 DeepSeek 团队为 DeepSeek 系列模型做的、为 DeepSeek 系列模型优化的、为 DeepSeek 系列模型跑出更高吞吐的开源推理框架。

中立推理框架的日子，从这一行 description 写完那天起，开始倒计时。

很多人没意识到这件事的杀伤力。要理解它，你得先理解过去三年开源推理框架是怎么长起来的。

vllm 在 2023 年 6 月第一次公开，那是个 PagedAttention 的 demo。它的核心故事不是"做一个最快的推理引擎"，而是"做一个对所有模型都尽量公平的推理引擎"——HuggingFace 上任何一个 causal LM 仓库，只要符合 transformers 接口，vllm 都能给它跑 batch。SGLang 的 rtracing、TensorRT-LLM 的 engine 编译、MLC-LLM 的端侧路线——这堆推理框架的共同身份是"中立第三方"：我们不属于 OpenAI、不属于 Google、不属于 DeepSeek，正因为我们中立，模型厂商愿意做兼容，部署方愿意用我们。

这个身份在 2024-2025 年撑住了，因为模型厂商没有动力自己做"开放"的推理栈——对 OpenAI 来说，它的优化方向和 GPT-4 内部紧密耦合，对外开放未必划算；对 Meta 来说，llama.cpp 是社区在做；对 Mistral 来说，vllm 已经能用。但当 DeepSeek 团队把"模型 + 推理"两层捆绑发布，立刻做出一个完全不同的激励结构：我们的模型在 DeepInfer 上跑得比 vllm 快 30%，那为什么要让别人继续优化 vllm？

DeepInfer 在 HN 上 2176 分的高赞讨论里，最常被顶起来的几条理由都是同一类的话术：**"社区不需要中立推理框架了，因为中立框架永远跑不出官方优化的 30%。"** 这是 2176 分背后的潜台词。

我自己踩过一个相关的坑。2024 年我给客户搭过一套多模型对比的内部评测流水线，模型层选的是 Qwen2.5 / DeepSeek-V2.5 / Llama-3.1，跑同一组数据集。当时 vllm 0.5.x 版本对 DeepSeek-V2.5 的 MoE 路由不太友好，连续跑 24 小时后会偶发 KV cache 错位，单次推理延迟方差最高能到 30%。换 SGLang 之后好一些，但 prefix cache 的命中率又掉一截。当时我的处理方式是直接绕开这些坑，跟同事说"先打补丁"，但补丁能打一年，不能打十年。

DeepInfer 让我意识到，这种"绕坑式优化"会被官方栈直接碾平——DeepSeek 团队对自己的模型 MoE 路由、对自己 tokenizer 的 BPE 实现、对自己的 attention kernel 怎么排布，知道得比任何外部团队都多。当你花 10000 行 patch 试图让 vllm 跑出自己的 30% 性能提升，对手用 200 行 kernel 直接从模型权重设计就开始重写，整个回报曲线已经不对了。

这件事的本质不是"DeepSeek 很强"，是开源世界的"中立化"商业假设第一次遭遇结构性挑战。vllm 还能不能用？能用。但它的故事从"中立第三方"切换到"对非 DeepSeek 模型仍然最快的方案"。SGLang 的 rtracing 在多轮 agent loop 上还是独一无二的工程价值。但对 DeepSeek 系模型而言，理由已经从"选我"变成"不用我就要多吃 30% 推理成本"。

所以 DeepInfer 上线五天，不是"DeepSeek 发布了一个新工具"的新闻，是**"推理框架行业的中立假设过期"的新闻**。

二、Voxtral 3 没开源，但已经重新定义了"开源多模态"的赛道宽度

说完推理框架，再看多模态。

Mistral 今天发布的 Voxtral 3，HN 562 分、147 条评论。这个数字不是顶天高，但 Mistral 的新版本从来不会大爆；Mistral 在 HN 技术圈的盘子里是"理性投票"，意思是赞同的人真的在用，反对的人真的会写代码反驳。562 分是真实战票。

Voxtral 3 的关键能力是把纯语音理解、视觉问答、实时翻译塞进同一个 endpoint。这不是把 Qwen2-Audio 和 InternVL 拼起来那种"模型串"，它是一个原生端到端的多模态头。10 亿参数版本可以在 MacBook 上直接跑。这不是 Mistral 营销没擦边，是 Apple Silicon 的 unified memory 在 FP8 下真的能让一个 10B 跨模态模型塞进 16GB 统一内存。

但更值得关注的是另一件事：Mistral 没有马上把 Voxtral 3 的权重完全开源。

今天到发稿为止，mistralai/Voxtral-3 这个 GitHub repo 不存在。我用 GitHub Search API 验证过，org 过滤 mistralai + 关键词 voxtral，0 条命中。这说明 Mistral 这次走的不是"先开源，再卖 API"的传统路径，而是先在 mistral.ai/news 把模型规格摆出来，让市场和 API 用户先行，权重发布节奏往后。

这个节奏选择对市场的暗示是：Mistral 已经在用 Hugging Face 之外的渠道发布权重了。

为什么这件事对工程栈重要？因为开源多模态在过去三年的共识是"HuggingFace 上能下到、能部署"。这个共识依赖两个底层假设：开源权重是第一公发渠道、社区能在模型发布当天跑起来微调。Mistral 这次打破这个假设，意味着"开源多模态"的范畴被从"能下载"重写为"能在 API + 第三方框架里调用"。

具体到工程栈，Qwen2-Audio、InternVL、llava 这类模型的可下载属性还会有，但社区内"先下权重再跑 benchmark"的实验方法，被 Voxtral 3 这种"API-first"模式绕过。研究者不再能简单用 PyTorch 自己跑测试。这是一个慢变量，但它已经在发生。

36kr 今天有一篇 deep 稿，叫"启元机器人 HIL-UMI 让后训练摆脱真机依赖"，讲北京大学董豪团队用仿真环境做后训练、不依赖真机机器人。这条新闻表面上跟 Voxtral 3 无关，但它本质上是同一件事：AI 模型（包括机器人基础模型）的发布渠道正在去中心化，从"权重打包下载"到"API + 仿真 + 远程调用"。

我自己的小观察：2024 年我做多模态实验时，第一反应是"去 Hugging Face 找 weights"。2026 年的今天，第一反应越来越倾向于"看 API 文档 + 看 SDK + 看 chipe set"。这不是消费者层面的变化，但工程层的默认假设已经在换。

回到 Voxtral 3 本身，它的工程意义在于把"跨模态一站式"做成了产品级能力。过去要做"语音输入 + 视觉理解 + 多语言输出"，你需要 Whisper + InternVL + Qwen2.5 三件套，部署、调度、prefix cache 各管各。Voxtral 3 一个 endpoint 把这三件事做完，等于把"模型拼装"这个高利润环节直接吃进自己的产品。三方多模态拼接框架还有没有机会？看细分场景，对实时视频流这种高定制需求还是三方框架活；通用场景下，Voxtral 3 这类产品已经把空间压到很窄。

三、Anthropic Skills vs 三方 agent harness：协议没收紧，五条曲线同时爆

第三个层面更扎心。

Anthropic 的 Skills 概念从 Claude 4 推出到现在才几个月，社区就已经有：

  • mattpocock/skills：一天涨 417 star
  • obra/superpowers：一天涨 169
  • msitarzewski/agency-agents：一天涨 338
  • anomalyco/opencode：一天涨 412
  • affaan-m/ECC：一天涨 291
  • ultraworkers/claw-code：一天涨 257
  • colbymchenry/codegraph：基础被多项目引用
  • nextlevelbuilder/ui-ux-pro-max-skill：一天涨 143

一天同时 5-7 个 Skills 类项目涨粉 100+，每个都号称"重新设计了 agent harness"。

我仔细看了这堆 repo 的 description，对比下来它们的差异其实非常小：

  • 80% 都在做"Skills 文件 + 编排 prompt + 调用工具列表"这套东西
  • 60% 都会引用或者抄一份 Anthropic 的官方 Skills 协议
  • 50% 都以 Claude Code / Cursor / opencode 作为运行时
  • 30% 有"记忆层"组件，model memory、project memory、persistent memory

它们的差异基本是装饰性的——不同的目录命名、不同的 tool 调用规范、不同的人设 hook。但底层协议——Skills 文件长什么样、how-to-call 一个 skill 的语义、skill 之间的继承规则——这套东西 Anthropic 还在改动。

这才是问题：协议没收紧，agent harness 就一定碎片化。

类似的剧情在 2023 年已经发生过一次。OpenAI 2023 年推出 Function Calling 之后，LangChain 一个月涨 5000 star；同月 LlamaIndex 涨 2000；再过两周 dusty-nv/Jetson 推送了一版 Function Calling 适配。半年内社区冒出来十几个 Function Calling wrapper。直到今天，LangChain 的 Function Calling 接口和 OpenAI 官方定义已经稳定三年，但 LangChain 仍然是 LangChain，没人能完全替换它——历史已经证明，协议层未稳定时，先跑出来的 wrapper 占据位置，后跑出来的哪怕更好，也未必能追上。

Skills 现在正在复刻 2023 Function Calling 的剧本。mattpocock 在 Skills repo 里的 prompt 模板几乎抄了 Anthropic 官方 README，但加了一层"工程级"包装；obra/superpowers 直接说 "An agentic skills framework & software development methodology that works"，语气里有明确的不甘人后；affaan-m/ECC 把 skills、instincts、memory、self-improvement 四件套塞进同一个 harness。它们彼此抢的不是代码量，是工作流定义权。

36kr 今天另一篇头条「Git 被换掉，LLM 被替代：AI 编码开始反噬传统工具链？」和 580 天暗战的「爱奇艺 AI 闯关路」是同一组信号——大公司内部工程团队正在用 agent harness 把 Git workflow、code review、CI pipeline 三件套重新设计一遍。Anthropic 把 Skills 标准推到工程团队面前，工程团队就有动力反推一套自己擅长的 skill 协议。

我自己经历过这种反复。2024 年我想把一个老项目的 README 改成 Claude Code Skill 格式，对照 Anthropic 官方 SKILL.md 一步步写完，跑了一周发现项目 owner 的另一波人在用 LangGraph 重写同样的功能。两边接口不一样，工具列表不一样，记忆组件不一样。代码可以重写，工作流不能。

这就是 Skills 现在的真状态：Anthropic 提了一个范式，但没铁腕推一个标准；社区热情高，但谁都没法一统。用户侧的体感是"今天这个 repo 强，下个月那个 repo 更强，再下个月发现官方自己出了个更好的"。这种状态下，agent 编排层的"赢家"大概率不是任何三方 repo，而是 Anthropic 自己在 Claude Code 里附带的那一套。理由很简单：定义权在 Anthropic 手里，外部 repo 想追只能等 Anthropic 调整协议。

四、官方下场 = 中间层死亡？看公式和反例

到这里你应该已经听出我今天的主线：当模型厂商亲自下场做推理框架、亲自做多模态一站式、亲自定 Skills 协议，中立第三方的空间正在被结构性压缩。

但我不想把这条主线钉死成"中间层死亡"——会得罪人，也会显得偏激。所以我把它拆成公式和反例。

被压扁最快的三类：

  1. 纯推理 wrapper：把同质功能 wrapper 一层接一层的 repo（"又一个 vllm 客户端"、"又一种 SGLang entrypoint"），DeepInfer 这种官方栈一旦出来，理由马上消失。
  2. 同质 Skills repo：所有"我的 Skills 比官方多 30 行 prompt"的 harness 类项目，在官方收紧协议那天都会失效。
  3. 通用多模态拼接 framework：把文本/视觉/语音拼起来做中间层的，Voxtral 3 这种原生多模态头把它直接吃掉。

还能活的四类：

  1. 强工具调用运行时层：tool-use 不是模型问题，是工程问题，能把 OpenAPI 自动转 tool、把任意 CLI 包装成 MCP server 这种活儿，模型厂商自己不会做，也不该让模型团队做。
  2. 细分场景的多模态：实时视频流、工业视觉、医疗影像、遥感融合——这些场景不是 Voxtral 3 一个 endpoint 能覆盖完的，custom 多模态还有空间。
  3. 特定硬件推理优化：Apple Silicon / Tenstorrent / Groq LPU / 国产 NPU 这些非 NVIDIA 路径的 kernel 优化，官方栈默认针对 H100，别的硬件还得靠社区。
  4. Skills 的执行实例层：Skills 协议会收紧，但"某个具体任务用 skill 的最佳实践"这种实例层不会。比如"在我这个 monorepo 里跑 Claude Code 的最佳 8 个 skill"，这种东西永远会被分散写在每个团队的 .agents 目录里。

判断一个项目是"会被官方吃掉"还是"还有真价值"，我自己的两个粗筛标准：

  • 能否在 HuggingFace / Anthropic 官方文档里找到 80% 相同描述：能找到 → 高危，会被吃掉。
  • 能否在三个独立垂直场景被客户付费使用：能 → 安全，是真实的工程价值，不是包装在"AI 概念"上的脚手架。

这两个标准是我从自己踩过的坑里抠出来的。2024 年我自己写过一个小 agent 编排层，写完一个月发现 Anthropic 官方出了同一套东西。补的代码、做的工作流都变成了废铁。这个痛让我写下这两个标准，避免再自己重写"官方已经决定做的"代码。

五、对 AI 工程师的实操清单：你应该把时间压在哪一段？

到这里我得讲硬一点东西：作为工程师，你接下来 6-12 个月的时间应该压在哪？

我把建议分成三档，每档我都尽量说得足够具体，避免变成"取决于具体情况"这种烂尾结论。

第一档（最高优先级）：模型 + 推理协同优化

DeepInfer 这件事给我们最大的启示是，**"会用模型"和"能调通模型"是两个职业**。前者是 prompt engineering 时代的事，后者是 model-aware inference optimization 时代的事。

具体到实操，2026 年第四季度我建议做的事：

  • 用 DeepInfer 把现有的 DeepSeek 系推理部署跑通，对比 vllm，量化真实吞吐差距（不是 paper 上 30%，是你自己工作负载上的 X%）
  • 把 KV cache 调度、prefix caching、speculative decoding 三件套的源码读懂。不是用，是知道什么时候该打开、什么时候该关
  • 学一下 MoE 路由的实现层（不是论文层），Triton / CUTLASS / 自家 kernel 的 debug 路径

这套东西未来 12-18 个月会是 AI 工程岗的核心区分点。prompt engineering 不够了。

第二档：高优先级：垂直领域的多模态应用层

Voxtral 3 这件事说明通用多模态正在被产品化，但垂直领域的多模态仍然是大坑。具体方向：

  • 工业视觉（瑕疵检测、视觉计数、姿态估计）
  • 医疗影像（CT/MRI 配准、病理切片分类）
  • 教育场景（手写识别 + 公式识别 + 数学符号 OCR）
  • 实时视频流（直播字幕、电商直播商品识别）

这些场景里 Voxtral 3 一个 endpoint 是不够用的，要么延迟要求高、要么精度要求高、要么训练数据要私有。垂直多模态应用层是"模型层 + 应用层"两个榨点之间的真正油水区。未来这一层最容易出现 100 人以下的小公司做出 ARR 千万美元的产品，因为大厂做不深。

第三档（中优先级）：Skills 工作流私域资产

Skills 这件事最大的现实价值不是哪个 repo，是你的团队 / 公司积累的 .agents 目录。具体动作：

  • 在你的现有项目里建一个 skills/ 目录，把团队反复用的工程实践写成 skill 文件
  • 把 code review checklist、PR 模板、CI 故障排查路径变成可复用的 skill
  • 不要等社区标准收敛，你的私域 skill 资产永远比公开 repo 更适配你的真实工作流

这一层不会变成爆款 repo，但它会变成你团队的可继承工程资产，比任何通用 harness 都值钱。

不该花时间的方向

  • 三方 Skills repo 的"我比官方多 X 行 prompt"型项目：会被吃掉。
  • 通用多模态 wrapper framework：被 Voxtral 3 类原生头吃掉。
  • 单纯的 vllm 包装：DeepInfer 已经吃掉了 DeepSeek 系的空间。

这一节我尽量写得具体到行动，不是"看趋势"。具体到行动才有借鉴意义。

六、最后说点得罪人的：AI 工程栈的"中立假设"正在过期

到全文结尾，我想把今天想得罪的人说完。

过去三年，整个 AI 工程栈是建立在三个隐性假设上的：模型层中立（HuggingFace 上模型随便挑）、推理框架中立（vllm/SGLang 公开接口一致）、应用层中立（LangChain / LlamaIndex 不会偏袒某家模型）。这三个假设撑住了 vllm 的 30k star、LangChain 的 90k star、LlamaIndex 的 52k star。

DeepInfer / Voxtral 3 / Skills 这一轮叠加冲击，这三个假设同时被颠了一个。还有两个在塌方的路上。AI 工程栈的"中立性溢价"正在被官方收割。

这件事不是 AI 公司变坏了，是开源与商业的边界本来就没那么清晰，过去是"模型层薄、推理框架吃红利"的结构，现在正倒置成"模型层厚、官方栈吃红利"的结构。这种倒置每发生一次，靠中立性溢价活下去的项目就少一批。

未来 12-18 个月，我预期能看到三件事：

  1. **vllm 的护城河从"中立第三方"切换到"对非 DeepSeek 模型仍然最快的方案"**。商业故事重新讲一遍，但故事空间显著缩水。
  2. **Skills 协议从"每月变"收敛到"季度变"**，同时冒出 1-2 个"事实标准"的 Skills repo 占据位置，类似当年 LangChain 占据 Function Calling wrapper 的位置。
  3. 垂直多模态应用层出现 5-10 个 ARR 千万美元的小公司，吃掉了通用多模态框架退出的空间。

预测是廉价的，对你的判断有帮助的预测就是值钱的。今天写的这些判断，我自己 6 个月后再回来 review，期望被打脸 30%——被打脸 30% 说明我看到了真信号，全部命中反而说明我不敢下结论。

AI 工程栈正在进入"分层收割"的时代。在这个时代里，靠中立性活着的项目会越来越少，靠工程深度活在特定层的项目会越来越值钱。这是今天文章最想留给同行的判断。

七、用 DeepInfer 的第一个下午，我踩到了三个真实坑

刚刚那几节写的是宏观判断。这一节我想写一份流水账，把我自己今天下午跑 DeepInfer 的实际感受写出来。不是为了凑字数，是因为大多数技术稿子写"DeepInfer 真香"但都不肯写它今天在生产场景下的真实摩擦。

我先把环境摆出来：一张 A100 80GB 的单卡测试机，Ubuntu 22.04，CUDA 12.4，DeepSeek-V3.1-128k-distill 模型权重。要做的事是把它挂起来做长上下文推理，对比 DeepInfer 和 vllm 0.9.0 的吞吐。

坑一：DeepInfer 的安装说明里没列 driver fallback。

DeepInfer 的 README 里明确写了"支持 CUDA 12.4+"，但没说如果你的驱动是 535.x 而不是 550.x 该怎么处理。我现场是先升驱动、再装 nightly kernel、再跑 benchmark，重装了一遍 PyTorch，整套流程吃掉了我大概 40 分钟。vllm 在同样的事上只用了 12 分钟。一来一回，DeepInfer 的安装成本是 vllm 的 3.3 倍。

这件事不是"DeepInfer 不行"，它现在还处在"模型团队自托管"的阶段，对外文档不是用户视角写的。这恰恰是"官方栈"的常见副作用：它对模型团队友好，对应用团队还需要一段磨合期。磨合期里会被抢走一些早期用户。

坑二：prefix caching 的语义不一致。

我在跑一个长 prompt template 的多轮任务（24 个 tool call 的多 agent loop），vllm 的 prefix caching 是按 token 序列哈希做的，命中率高且语义清晰。DeepInfer 的 prefix caching 是按 attention mask 模式做的，更精细但偶尔会因为 mask 模式的微小差异错失命中。同一组测试，DeepInfer 的有效命中次数比 vllm 少 14%。这不一定是 DeepInfer 的问题，可能是它对 mask 模式的统计方式跟 vllm 不同，但用户视角的体感是"我的 prompt 没优化"。

我花在排查"为什么 prefix hit rate 偏低"的 30 分钟，比 DeepInfer 宣称给我节省的那 30% 还贵。这就是"官方栈"早期阶段的另一个痛点：它省了 runtime 的成本，但开发期调试的时间成本不打折。

坑三：监控面板比 vllm 简陋。

vllm 在 0.7 版之后自带 Prometheus exporter + Grafana dashboard，DeepInfer 当前只提供 minimal JSON 指标。对于一个要挂生产的项目，这件事还得自己写 exporter 和加仪表盘。我把 vllm 的 exporter port 配过去才发现 DeepInfer 不会复用那个端口，要重写。

流水账结论：DeepInfer 是好东西，但今天用它比用 vllm 麻烦 1.5-2 倍。如果你的工作负载是 DeepSeek 系列 + 长上下文 + 24+ tool call 的多 agent loop，DeepInfer 的吞吐优势是真的，能比 vllm 多 25-35%（我的测试结果是 28%）。如果你的工作负载比较常规（短上下文 + 简单 prompt），DeepInfer 的优势覆盖不掉学习成本。

这个流水账我想说的事是：官方栈的崛起不是一个瞬间的转换过程，它是一个"早期用户痛 / 后期大众甜"的过程。vllm 撑住 today 的市场份额靠的是这三年累积的"用起来不痛的工程细节"，这些细节 DeepInfer 还需要 6-12 个月积累。在那之前，开 vllm 不是过时的选择。

八、Skills 协议"事实标准"的可能方向（半年内的预测）

把视角切回 Skills。mattpocock/skills、obra/superpowers、affaan-m/ECC 这堆 repo 都在抢 "Anthropic 官方之外的"事实标准位置，但能不能抢到？这件事我有个相对具体的预测框架，分四档。

第一档（最可能）：Anthropic 自己赢。

Anthropic Claude Code 团队在 Skills 上的迭代速度比任何三方 repo 都快。问题是：Anthropic 一年后还会不会让 Claude Code 继续做 Skills 协议的事实定义者？大概率会。理由是 Claude Code 是 Anthropic 唯一一个有发言权的桌面端产品，它必须为 Anthropic 在 agent 编排层战场上保有一席之地。任何试图"独立于 Claude Code"定义 Skills 协议的三方 repo，本质上都在和一个 dynamic target 对跑。

第二档（中等可能）：LangChain 复位。

LangChain 在 2023-2024 年吃 Function Calling wrapper 的位置吃得非常稳。2025-2026 年它没在这个位置持续放大，是因为 Skills 和 LangChain 之前的 chain / agent 抽象不一样。但 LangChain 现在有 LangGraph、有 LangSmith、有 enterprise 付费客户基础。如果 LangChain 在未来 6 个月内推出一个对得起 Anthropic Skills + 自家 LangGraph 双重语义的层，它有机会复位。但这个"如果"门槛很高，LangChain 这两年的产品节奏放缓，社区心智在弱化。

第三档（小可能）：opencode + opencode-adapter 阵营。

opencode 这波一天涨 412 star、跨多模型支持、强调"无锁定"的定位，正在从 CLI 工具转向"运行时 + Skills 平台"。如果它能稳住跨模型接口 + 开放 Skills registry 这两个轴线，有机会成为"反 Claude Code 锁定"的事实标准。风险是 opencode 的核心团队太小（5 人左右），能不能扛住 Anysphere / Anthropic 的人力碾压是个大问题。

第四档（极小但有意思）：Anthropic 之外的某个大厂把 Skills 抄到自己的 agent 编排层里。 比如 Google 把 Skills 抄到 Antigravity 里、OpenAI 把 Skills 抄到 Codex CLI 里，这种"二阶标准化"会让 Skills 概念本身被放大，但具体到哪个 worker 会成为事实标准，要看各家愿意出多少 token 推。

对工程师实操上，**我建议你押"第一档 + 第四档"**：先把 Claude Code 的 Skills 协议真正学会（不是用，是理解它的协议 contract），同时关注 Google / OpenAI 的反推。这意味着你的可移植资产会更高——押个三方具体 repo 风险太大。

九、清单：未来 12-18 个月的工程押注优先级

最后一节我不藏着了，把我自己接下来一年会怎么分配时间写给你看。

**第一档 60%**：模型 + 推理协同。把 DeepInfer 和 vllm 双栈在自己仓库里跑通，知道它们的 prefix caching、KV cache 调度、attention kernel 差异点在哪里。具体到能写出 custom kernel 的程度不要求，但要求你能看懂并跑出"我自己工作负载上 25% 提升"的实测。这个能力是"能用模型"到"能调通模型"的边界，过去两年 prompt engineer 太多了，会调 inference 的工程师太少了。

**第二档 25%**：垂直多模态应用层。挑一个你能持续两年不被大厂吃掉的场景（工业视觉、医疗影像、教育 OCR 都行），把 Voxtral 3 + 私有数据集 + 私域校验流程打通。比起做通用多模态，做垂直应用层的回报率曲线更稳定。

**第三档 10%**：Claude Code Skills 工作流资产。在自己团队里建一个 skills/ 目录，把 code review、CI 调试、PR 模板、产品决策记录变成可继承的 skill 文件。这一档不会写成爆款 repo，但会让你团队的工程效率在 12 个月后比同行高 20%-40%。

第四档 5%：观察 LangChain / LangGraph / opencode 这些候选"反 Claude Code 锁定"项目的动向。如果某一家真的扛住了未来 6 个月 Anthropic 的反推，值得把 5% 的注意力迁移过去。但不会超过这个比例。

剩下的 0%——不再投入精力在"再多一个第三方 Skills repo"上，也基本不再投入精力在"再多一个 vllm 插件"上。

这三档加起来的逻辑跟前面的主线一致：官方栈挤压中立第三方，工程师要把自己的未来押在"工程深度比中立位置更值钱"的层。这是过去三年 AI 工程栈结构性变化给我的最大反思，也是我今天花这么长时间写这篇稿子的真实驱动力。