当所有 Agent 都在抢「技能」和「插件」,垂直化的真问题才刚暴露当所有 Agent 都在抢「技能」和「插件」，垂直化的真问题才刚暴露2026 是 Agent 垂直化的元年。但大多数人盯着"又多了几个技能"，却没看清垂直化真正的墙在哪。2026 开年，AI Agent 赛道发生了一场静默的范式转移。Anthropic 把 Claude Skills 做成开放标准，GitHub 上社区 Skills 半年冲到 6 万+；字节 Coze 插件市场堆到 800+，2.0 还加了 Agent Skills 和 Agent Plan；Manus 直接走垂直场景深度定制（零售、金融、医疗）；Salesforce 的 Agentforce、SAP 的 Joule 把智能体焊死在自己的 CRM/ERP 里。但热闹之下，一个被多数人忽略的事实是——这一轮"垂直化"，绝大多数玩家还停留在两个很薄的东西上：技能（Skills）和插件（Plugins）。而垂直化真正难的部分，恰恰不在这两个词里。把 2026 的 Agent 生态摊开看，是一条清晰的四层栈：• 模型层：GPT、Claude、Gemini、DeepSeek、Qwen…… 这是 Agent 的"脑"。• 协议层：MCP（管工具）、A2A（管 Agent 间通信）、Skills（管"怎么想"）。这是"通用语言"。• 框架层：Dify、LangChain、OpenClaw…… 这是"脚手架"。• 应用层：客服、数据分析、医疗、法律、金融等垂直 Agent。这是用户真正用的东西。在这套叙事里，Skills 被定义为"Agent 的脑子"（知识、流程、最佳实践封装成 SKILL.md），Plugins/Tools 被定义为"Agent 的手"（调 API、连数据库）。Skills 本质是个"提示词包 + 脚本"，连 Anthropic 自己都承认：社区 Skills"没有中央审批、没有类 GPT Store 的收益分成，生态更乱但摩擦更低"。Plugins 本质是个"API 连接器"，把外部服务包一层接口。它们能解决"让 Agent 知道怎么写报销单""让 Agent 能查天气"，但解决不了垂直能力真正难的三件事：1真实垂直能力要带"重物"——3D 建模要带建模引擎，科研要带文献源与解析器，不是一段提示词能兜住的；2要能可靠地分发与校验——版本化、来源可信、下载不被篡改，而不是 GitHub 上一堆零散文件夹随便 clone；3要能持续运行、自我修复——引擎崩了、权重丢了，谁去管？用户不可能每次都手动排障。IDC 的调研很说明问题：2025 年中国企业级 Agent 市场 212 亿，2026 年预计跳到 449 亿，但 60% 的企业仍停在评估/试点，只有 18% 真正把 Agent 放进了核心业务流。 这中间的落差，很大一块就是"垂直能力太薄、太脆、太难规模化"——也就是行业里说的"试点陷阱"。二、Vermes 的回答：不堆技能，做"可插拔垂直模块闭环"我们做 Vermes 时，也走过"内置垂直模块"的路——把论文模块 ScholarForge（27 个工具）、3D 模块 mfgcad（13 个工具，已真出图 STEP/STL/3MF）直接打进出厂包。但很快遇到你也能想到的矛盾：垂直领域越做越多，出厂包会膨胀到离谱。 论文、3D、机器人、影视……每个都塞进去，用户装一个"通用 Agent"却要为所有垂直域买单。所以我们的解法不是"加更多技能"，而是把垂直能力抽成可插拔模块——一个模块 = 领域代码 + 工具集 + 前端界面 + 重资产（引擎/权重）+ 引擎自装逻辑，整体打包成一个完整能力包，按需从 GitHub 下载安装。这不是技能包，也不是插件。技能包只装"知识"，插件只装"接口"，而模块装的是"一整个能干活的能力"。更关键的是，我们把这件事做成了闭环，而不是"装一次就完事"：• 分发闭环：每个模块走 GitHub Release 发布，配 catalog.json 登记真实 SHA256。安装时下载→校验→解压，供应链可验证。这正好补上了社区 Skills"无审批、易篡改"的短板。• 自愈闭环：Agent 在运行时检测到"模块没装"或"重资产缺失"，会自己发起安装。mfg_setup_engine 发现 3D 引擎没装，自动建 venv、装依赖、验证；install_module_asset 发现重资产丢了，自动重新下载。用户只说"帮我建个笔筒"，引擎的事 Agent 自己办。• 生命周期闭环：从目录发现 → CLI/前端商店安装 → 热重载生效 → 版本更新，全链路打通。一句话区分：别人给 Agent 装"技能"和"插件"，我们给 Agent 一套"能自己长出垂直能力、还能自己疗伤"的模块化身体。把三者放到一起对比，差异一目了然（公众号不渲染表格，我用清单逐维度说清）：• Vermes 可插拔模块：GitHub Release + SHA256 供应链校验• Vermes 可插拔模块：Agent 自愈式自装• Vermes 可插拔模块：自带 UI（如 3D 工作室）这张清单也是我们对"垂直 Agent 之争"的判断：竞争焦点正在从"谁技能多"转移到"谁能把垂直能力做成可分发、可自愈、可规模化的闭环"。四、为什么这条路线对"垂直 Agent 之争"是护城河站在行业观察者视角，Vermes 这套打法有几个值得注意的结构性优势：1. 垂直扩张的边际成本趋近于零。 新垂直域 = 一个新的 GitHub 仓库，底座完全不动，出厂包零膨胀。当竞品靠"内置更多垂直"把包越做越大时，Vermes 靠"按需插拔"把扩张变成了近似零边际成本的事。这对长期规模化是关键。2. 模型无关 + 本地优先，天然适配高合规场景。 Vermes 不绑定任何模型厂商（DeepSeek / GLM / Claude / 自建都行），数据落在本地。在金融、政务、医疗这类"数据主权是前置准入"的赛道，"本地 + 垂直 + 可验证"反而是一片蓝海——这正是我们用 ScholarForge 切入的逻辑。3. Agent 本身就是分发渠道。 因为模块能"自愈式自装"，新模块的采纳不依赖用户手动去商店点安装，而是 Agent 在执行任务时顺手完成。自驱动分发（self-driving distribution） 意味着更低的模块 adoption 成本——这是传统"应用商店式"插件市场做不到的。4. 已验证，不是 PPT。 模块化体系 P0–P6 全部落地并已 push：真实 GitHub Release 下载（mfgcad 51KB / scholarforge 213KB，SHA 校验通过）、真实出图、真实热重载；agent 侧 + 垂直模块侧测试 122 passed / 0 failed，早期全量回归 189/238 亦零回归。我们不想把故事讲成"已经赢了"。对投资人和行业观察者，有几个真实约束必须摆上桌面：• 模块生态依赖持续产出。 目前只有 ScholarForge（论文）、mfgcad（3D）两个垂直打样，数量还少。闭环的价值要在"更多垂直域加入"时才完全释放，而生态建设本身就是最慢的一环。• 自愈闭环有前提。 它能自装的前提是"引擎/资产可程序化安装"。部分重资产（如大模型权重）仍需用户自备或另行授权，闭环在此处会优雅降级而非强行兜底。• 对比的是方向，不是体量。 我们是一个开源项目，体量和 Salesforce、字节、Anthropic 不在一个量级。这篇文章谈的是"路线差异"，不是"规模碾压"。2026 年 Agent 垂直化是确定性方向，这点没人怀疑。但赢家大概率不是"谁的技能多、插件多"，而是"谁把垂直能力做成了可分发、可自愈、可规模化的闭环"。全行业还在用"技能 + 插件"回答垂直化，Vermes 已经把问题往前推了一步：垂直能力不该是贴上去的薄片，而该是 Agent 自己能装卸、能疗伤、能扩展的模块化身体。这未必是唯一的答案，但我们认为，这是通向"真正能干活、能规模化、不被任何一家锁死"的 Agent 最稳的一条路。*Vermes 是基于开源 Hermes Agent 引擎（MIT 协议）构建、面向中文用户深度优化的开箱即用 AI Agent，融合可插拔垂直模块体系。项目已开源。*
夜雨聆风