Hermes Agent vs OpenClaw：2026 年两个最火开源 AI Agent 的终极对比

Hermes Agent vs OpenClaw：2026 年两个最火开源 AI Agent 的终极对比

2026 年的开源 AI Agent 圈子，有两个项目你必须知道。 一个是 OpenClaw——2026 年 3 月超越 React 成为 GitHub 最高星标项目，目前 350k+ Stars，从一个个人副项目变成了现象级开源基础设施。 另一个是 Hermes Agent——Nous Research 出品，167k Stars，自称「唯一内置学习循环的 Agent」，核心卖点是越用越聪明。 如果你正在犹豫该用哪个（或者两个都想试试），这篇文章帮你把核心差异讲清楚。一句话定位 它们不是竞品，而是两条完全不同的路线：OpenClaw Hermes Agent一句话 让你定义规则，让 AI 执行 让 AI 自己学会做事代表路线 广度连接——接入最多的平台 深度进化——越用越懂你核心角色 执行者（Doer） 学习者（Learner）比喻 万能遥控器 会成长的徒弟五大维度深度对比 1. 架构与安全：CVE 教会了我们什么？ 这是两个项目最根本的设计分歧。 OpenClaw 采用单进程架构——工具、集成、平台适配器全部运行在同一个地址空间。这种设计带来的好处是启动快、部署简单、资源占用低。但代价也在 2026 年 2 月暴露了：CVE-2026-25253：未认证的远程代码执行（RCE），CVSS 评分 8.8（高危），数万个未打补丁的实例被入侵。之后 OpenClaw 引入了 AgentWard（eBPF 探针监控）、SkillFortify（技能形式化验证）、Raypher（硬件身份认证）等安全组件，但本质上是在修补一个默认不隔离的架构。 Hermes Agent 从第一天起就是分层隔离架构： 平台适配器 → 网关进程 → Agent 运行时（受控接口）→ 工具执行（沙盒）平台网关无法直接访问 Agent 运行时，工具执行默认在沙盒内。截至 2026 年 5 月，Hermes Agent 没有已知的 CVE。💡 安全总结：OpenClaw 靠补丁堆砌安全，Hermes Agent 靠架构从源头限制爆炸半径。2. 记忆系统：谁记得更牢？ 记忆系统是 AI Agent 的「大脑」。 OpenClaw 的记忆以 Markdown 文件为基础载体（SOUL.md、AGENTS.md 等），通过 Dinobase 提供生产级持久化存储。高级记忆功能（向量检索、知识图谱）需要额外安装插件。整体来说，手动可控，但需要深度定制。 Hermes Agent 的记忆是架构级原生设计：会话历史存储在 SQLite，支持 FTS5 全文检索 每次对话前自动加载相关记忆和技能 内置用户建模系统（集成 Honcho），持续积累你的沟通风格和偏好 零人工维护，全自动沉淀💡 记忆总结：Hermes 是懒人友好型——你什么都不用做，它自己记；OpenClaw 是控制狂友好型——你想让它记什么，它就记什么。3. 技能机制：最核心的差异 这是两者最本质的区别。 OpenClaw 的技能是人工编写 + 社区下载的。你需要去 ClawHub 技能市场搜索、安装、管理插件。生态成熟，技能数量丰富，但每次执行相同任务，Agent 都需要重新规划。 Hermes Agent 的技能是自动生成 + 自我进化的： 解决任务 → 记录技能文档 → 下次遇到类似任务 → 直接调用缓存技能 → 跳过规划阶段完成一个复杂任务后，Agent 会自动调用 skill_manage 工具生成一份标准技能文档，记录解决方法、遇到的陷阱、边界情况。使用过程中发现问题，还会通过 patch 动作精准优化。 Nous Research 内部基准测试显示，经过数周技能积累后，研究任务完成速度提升约 40%。💡 技能总结：OpenClaw 是「用现成技能」，Hermes 是「自己造技能」。短期 OpenClaw 更快（生态成熟），长期 Hermes 的复利效应更明显。4. 平台覆盖：25+ vs 7 这是 OpenClaw 的绝对主场。 OpenClaw 覆盖 25+ 消息平台：WhatsApp、Telegram、Slack、Discord、Signal、Email、iMessage、Microsoft Teams、Google Chat、Matrix、飞书、微信、LINE、IRC、Twitch……而且所有渠道共享同一个 Agent 和本地记忆。 Hermes Agent 目前支持 7 个平台：Telegram、Discord、Slack、WhatsApp、Signal、Email、CLI。能力 OpenClaw Hermes Agent消息平台 25+ 7语音模式 支持 不支持伴侣 App macOS + iOS + Android 无浏览器控制 支持 通过 MCPiMessage 独占 不支持💡 覆盖总结：如果你需要接入微信、飞书、iMessage 等平台，OpenClaw 目前没有对手。5. 成本与部署 两者的软件本身都免费开源。 主要成本在 LLM API 调用。如果你搭配 Ollama + 本地开源模型，两者都可以实现零 API 成本。维度 OpenClaw Hermes Agent安装 npm install -g openclaw 一键脚本（curl | bash）配置复杂度 简单上手，深度配置需学习 稍复杂，但后续自进化降低长期成本运行环境 Node.js（轻量） Python（稍重）Serverless 支持 无 Modal / Daytona（空闲时近乎零成本）💡 成本总结：两者都可以用最低 5$/月的 VPS 跑起来。Hermes 的 Serverless 后端是一个额外优势——不干活时不花钱。综合评分对比维度 OpenClaw Hermes Agent 胜出渠道覆盖 25+ 平台 7 平台 OpenClaw设备集成 语音/App/设备控制 CLI 为主 OpenClaw安全架构 补丁堆砌 分层隔离，零 CVE Hermes自我进化 不支持 闭环学习，+40% 效率 Hermes跨会话记忆 插件依赖，手动维护 FTS5 原生，全自动 Hermes技能生态 成熟丰富，即装即用 自动生成，复利增长 平手数据主权 本地优先，完全可控 未特别强调 OpenClaw安装便捷 一行 npm 命令 一键脚本 平手你该怎么选？ 选 OpenClaw 的场景你是个人用户，需要接入微信、飞书、iMessage 等平台 你需要语音交互或 macOS/iOS/Android 伴侣 App 你重视数据主权，所有数据留在本地 你已经有成熟的技能工作流，不需要 Agent 自己学选 Hermes Agent 的场景你希望 Agent 越用越聪明，自动积累经验 你处理高重复度工作流（定期报告、代码审查、数据清洗） 你运行敏感工作流，需要默认沙盒保护 你是开发者或研究者，需要技能的复利效应组合方案 两者并非对立，可以搭配使用：Hermes Agent 做指挥中心（记忆沉淀、技能生成、任务规划），OpenClaw 做执行端（利用多平台能力完成具体操作），实现自动成长 + 高效执行的能力互补。迁移指南 如果你已经在用 OpenClaw 想迁移到 Hermes Agent，好消息是 Hermes 内置了专用迁移工具： # 预览将迁移的内容 hermes claw migrate --dry-run# 执行迁移 hermes claw migrate迁移内容包括人格文件（SOUL.md）、记忆、技能、消息设置、API 密钥等。⚠️ 注意：OpenClaw 的 25+ 渠道中只有 7 个能迁移到 Hermes。如果依赖 iMessage、飞书、微信等独占渠道，建议两者并存。写在最后 2026 年的 AI Agent 赛道，OpenClaw 和 Hermes Agent 代表了两种截然不同的设计哲学：OpenClaw 相信「人是决策中心」——你定义规则，AI 执行 Hermes Agent 相信「AI 可以自己进化」——你给机会，AI 成长没有绝对的对错，只有是否匹配你的需求。但有一点是确定的：AI Agent 的未来，一定是这两条路线的融合——既要有 OpenClaw 的广度连接能力，也要有 Hermes 的深度进化能力。 现在，你想让 AI 做你的遥控器，还是做你的学徒？参考来源：Nous Research GitHub、OpenClaw 官方文档及社区对比分析

在 macOS 上用 oMLX 跑本地大模型：Apple Silicon 专属推理服务器完全指南

在 macOS 上用 oMLX 跑本地大模型：Apple Silicon 专属推理服务器完全指南

如果你在用 Apple Silicon 的 Mac（M1/M2/M3/M4），想跑本地大模型来辅助编程或写作，大概率试过 Ollama 或 LM Studio。它们能用，但都有同一个痛点：上下文一长，响应就慢得让人想放弃。 oMLX 就是为了解决这个问题而生的。oMLX 是什么？ oMLX 是一款专为 Apple Silicon Mac 优化的本地 LLM 推理服务器，基于 Apple 官方的 MLX 框架构建。它的核心亮点是 智能 SSD KV 缓存——把推理过程中的 KV 缓存持久化到磁盘，让 Claude Code、Cursor、OpenClaw 等 AI 编程工具在长上下文场景下的响应时间从 30–90 秒缩短到 5 秒以内。✅ 开源协议：Apache 2.0 ✅ 运行平台：Apple Silicon + macOS 15+ ✅ GitHub：https://github.com/jundot/omlx（15k+ Stars）核心特性 1. 分页 SSD KV 缓存（最核心的差异化功能） 这是 oMLX 区别于 Ollama / LM Studio 的根本原因。 传统推理服务器的 KV 缓存在内存中，一旦上下文变化或服务器重启，缓存全部丢失，需要重新计算。oMLX 将所有 KV 缓存块以 safetensors 格式持久化到 SSD，并通过 LRU 策略在内存热层和磁盘冷层之间智能调度： 热层（RAM）←→ 冷层（SSD，safetensors 格式）实际效果：即使你切换了对话话题、或者重启了服务器，之前算过的上下文前缀不需要重新计算，TTFT（首 Token 响应时间）从 30–90 秒降至 5 秒以内。 2. 连续批处理（高吞吐） 通过 mlx-lm 的 BatchGenerator 处理并发请求，不再因单个请求阻塞整个队列。 实测数据（M3 Ultra 512GB，Qwen3.5-122B-A10B-4bit）：并发数 Token/s 加速比1× 56.6 1.00×2× 92.1 1.63×4× 135.1 2.39×8× 190.2 3.36×Qwen3-Coder-Next-8bit 在 8× 并发下最高可达 4.14× 加速。 3. 原生 macOS 菜单栏应用oMLX 提供了一个非 Electron的原生 macOS 菜单栏应用（用 PyObjC 实现），可以从菜单栏直接启动/停止/监控服务器，无需开着终端窗口。 应用已签名并公证，支持应用内自动更新。 4. OpenAI + Anthropic 双协议兼容 这是 oMLX 对 AI 编程工作流最友好的地方：提供 /v1/chat/completions（OpenAI 兼容端点） 提供 /v1/messages（Anthropic 原生端点） 兼容 Claude Code、Cursor、OpenClaw 及所有 OpenAI 兼容客户端Web 仪表盘可以一键生成各工具的配置命令，直接复制粘贴即可使用。5. 多模型同时服务 可以同时加载 LLM、VLM（视觉语言模型）、Embedding、Reranker 多种模型。内存不足时自动按 LRU 策略淘汰，也可以手动固定常用模型始终保持加载。系统要求配置 最低要求 推荐配置芯片 Apple Silicon（M1 或更新） M 系列 Pro/Max系统 macOS 15.0+（Sequoia） macOS 15+内存 16GB RAM 64GB+存储 视模型大小而定（30GB+ 推荐） —安装方式 方式一：Homebrew（推荐，含 CLI） 如果你需要通过命令行启动服务，或者用 Claude Code 等工具集成，Homebrew 方式最方便： # 添加 tap brew tap jundot/omlx https://github.com/jundot/omlx# 安装 brew install omlx# 升级到最新版本 brew upgrade omlx安装完成后可以直接用 omlx 命令，也可以作为后台服务运行（崩溃自动重启）： # 启动为后台服务 brew services start omlx# 查看服务状态 brew services info omlx# 停止服务 brew services stop omlx服务日志位置：服务管理日志：$(brew --prefix)/var/log/omlx.log 服务器运行日志：~/.omlx/logs/server.log💡 如果需要 MCP 工具支持，额外执行： /opt/homebrew/opt/omlx/libexec/bin/pip install mcp方式二：macOS App（最适合非技术用户）前往 GitHub Releases 下载 .dmg 文件 拖拽到 Applications 文件夹 启动后，欢迎界面会引导你完成：设置模型目录 → 启动服务器 → 下载第一个模型⚠️ 注意：macOS App 版本不包含 omlx CLI 命令。如果需要命令行控制，请选择 Homebrew 或源码安装方式。方式三：从源码安装（开发者） git clone https://github.com/jundot/omlx.git cd omlx# 仅安装核心功能 pip install -e .# 含 MCP 支持 pip install -e ".[mcp]"快速开始：启动你的第一个本地模型 第一步：准备模型目录 oMLX 需要从 HuggingFace 下载 MLX 格式的模型。你可以：直接用 oMLX 内置的模型下载器（推荐） 手动下载后放到指定目录 直接复用 LM Studio 的模型目录（无需重新下载）模型目录结构示例： ~/models/ ├── Qwen3.5-122B-A10B-4bit/ ├── Qwen3-Coder-Next-8bit/ ├── Step-3.5-Flash-8bit/ └── bge-m3/ ← Embedding 模型第二步：启动服务 Homebrew / 源码安装方式： omlx serve --model-dir ~/models启动后：API 端点：http://localhost:8000/v1 管理仪表盘：http://localhost:8000/admin 内置聊天界面：http://localhost:8000/admin/chatmacOS App 方式： 直接从 Applications 启动 oMLX，菜单栏会出现图标，点击即可管理服务器状态。 第三步：下载模型 打开管理仪表盘（/admin），在模型下载器里搜索并下载你需要的模型：仪表盘支持搜索 HuggingFace 上的 MLX 模型，查看模型卡片和文件大小，一键下载。与 Claude Code / Cursor 集成 这是 oMLX 最有价值的使用场景。配置完成后，你的 Claude Code 或 Cursor 就可以直接调用本地模型，所有数据都在本地运行，完全不依赖外网。 一键生成配置打开 oMLX 管理仪表盘 选择你要使用的模型 点击「一键生成配置命令」 复制命令，粘贴到终端执行oMLX 支持一键配置以下工具：工具 说明OpenClaw 一键生成配置OpenCode 一键生成配置Codex 一键生成配置Hermes Agent 一键生成配置GitHub Copilot 一键生成配置Pi 一键生成配置手动配置示例 如果你需要手动配置，只需要将 API 端点指向本地： # OpenAI 兼容客户端 export OPENAI_API_BASE="http://localhost:8000/v1" export OPENAI_API_KEY="dummy" # oMLX 默认不需要 key# Anthropic 兼容客户端（Claude Code） export ANTHROPIC_API_KEY="dummy" export ANTHROPIC_BASE_URL="http://localhost:8000"支持的模型 oMLX 支持所有来自 HuggingFace 的 MLX 格式模型，包括：模型系列 说明Qwen 含 Qwen3.5 MoE、Qwen3-Coder，推荐日常使用LLaMA Meta 系列Mistral Mistral AI 系列Gemma Google 系列DeepSeek 自动处理 <think> 标签GLM 智谱系列MiniMax 自动处理 <think> 标签VLM 视觉语言模型（v0.2.0+ 支持，含 SSD 缓存）Embedding / Reranker 可同时加载，用于 RAG 场景💡 模型选择建议：如果你主要用本地模型辅助编程，优先选择 Qwen3-Coder 或 Qwen3.5 系列，工具调用支持最好，速度也最快。管理仪表盘详解 oMLX 的管理仪表盘（/admin）是一个功能完整的 Web UI，所有 CDN 依赖均已本地化，完全离线可用。主要功能：实时监控：Token/s、并发数、内存占用等实时指标 模型管理：加载/卸载模型、设置每模型参数、固定常用模型 内置聊天：支持对话历史、模型切换、深色模式、VLM 图像上传 基准测试：一键测试预填充和生成速度 配置生成器：为各工具生成配置命令 多语言支持：英语、中文、日语、韩语、法语、俄语进阶配置 启用 SSD KV 缓存 omlx serve \ --model-dir ~/models \ --paged-ssd-cache-dir ~/.omlx/cache \ --hot-cache-max-size 20%--paged-ssd-cache-dir：指定 SSD 缓存目录 --hot-cache-max-size：热缓存占系统 RAM 的最大比例限制内存使用 # 限制单个模型最大内存 omlx serve --model-dir ~/models --max-model-memory 32GB# 限制进程总内存（默认：系统 RAM - 8GB） omlx serve --model-dir ~/models --max-process-memory 80%调整并发数 # 最大并发请求数（默认 8） omlx serve --model-dir ~/models --max-concurrent-requests 16启用 MCP 工具 omlx serve --model-dir ~/models --mcp-config ~/mcp.jsonAPI 密钥认证 omlx serve --model-dir ~/models --api-key your-secret-keyoMLX vs Ollama vs LM Studio对比项 Ollama LM Studio oMLXKV 缓存存储 仅内存 仅内存 内存 + SSD 持久化缓存失效后 全量重新计算 全量重新计算 从 SSD 毫秒级恢复TTFT（长上下文） 30–90 秒 30–90 秒 < 5 秒并发处理 单请求队列 单请求队列 连续批处理Anthropic 端点 不支持 不支持 原生支持菜单栏管理 无 有 有（原生非 Electron）适合场景 简单推理 图形化交互 AI 编程工作流架构概览 如果你对技术架构感兴趣，oMLX 的核心设计如下： FastAPI Server (OpenAI / Anthropic API) │ ├── EnginePool（多模型、LRU 驱逐、TTL） │ ├── BatchedEngine（LLM，持续批处理） │ ├── VLMEngine（视觉语言模型） │ ├── EmbeddingEngine │ └── RerankerEngine │ └── Cache Stack ├── PagedCacheManager（GPU，基于块，CoW，前缀共享） ├── Hot Cache（内存热层） └── PagedSSDCacheManager（SSD 冷层）这套架构的核心思路是：把 KV 缓存当作操作系统的虚拟内存来管理——热块在 RAM，冷块在 SSD，按需换入换出，服务器重启后缓存不丢失。总结 如果你在用 Mac 做 AI 辅助编程，oMLX 是目前最值得尝试的本地模型方案。它的 SSD KV 缓存设计真正解决了长上下文场景下的实用性问题，而原生菜单栏应用和一键工具集成也让日常使用变得非常顺手。 最重要的是：数据完全本地，不需要联网，不需要 API Key，不需要担心隐私泄露。 获取方式：官网：https://omlx.ai GitHub：https://github.com/jundot/omlx Homebrew 一键安装：brew tap jundot/omlx && brew install omlx参考资料：oMLX 官方文档（https://omlx.ai）及 GitHub 仓库（https://github.com/jundot/omlx）

算法时代的生存指南：重读《你的降落伞是什么颜色》，寻找不被 AI 替代的底气

算法时代的生存指南：重读《你的降落伞是什么颜色》，寻找不被 AI 替代的底气

引言：2026 年的职场失语症 现在是 2026 年。 不管你承不承认，我们都患上了「AI 失语症」。 早上醒来，GPT-X 已经写好了你要的策划案，Midjourney 生成的图比设计总监还快，Sora 生成的视频让剪辑师感到窒息。曾经我们引以为傲的「硬技能」——无论是写代码、翻译、还是数据分析，在飞速迭代的大模型面前，似乎都变得不堪一击。 身边不断有人换赛道，有人「毕业」，更多的人在问同一个问题：「如果 AI 能做我现在 90% 的工作，那我存在的意义是什么？」 最近，我在整理旧书架时，翻出了一本「古董书」——理查德·尼尔森·波尔斯的《你的降落伞是什么颜色？》（What Color Is Your Parachute?）。 这本书初版于 1970 年。你可能会笑：「在这个满大街都是机器人的年代，一本半个世纪前的书还能教我怎么找工作？」 但我重读之后，惊出了一身冷汗。原来，它从来不是一本教你「怎么写简历」的书，而是一本教你「如何在动荡世界里定义自己」的生存手册。 在 2026 年的当下，这本书里的这三个观点，或许比任何 AI 工具书都更值得我们深读。第一点：从「名词」回归「动词」——哪怕赛道消失，你的能力永存 书中观点：可迁移技能（Transferable Skills）是职场的硬通货。 在 2026 年，我们最大的恐惧是「职位消失」。比如你是「翻译」，当翻译软件实时同传普及了，这个职位就没了。 但《降落伞》早就告诉我们：不要用「职位头衔（名词）」来定义自己，要用「技能（动词）」。你不是一个「文案编辑」（名词，容易被 AI 替代）； 你是一个「擅长用文字共情、能从复杂信息中提炼观点并说服他人的人」（动词，AI 很难完美做到）。AI 时代的启示 AI 擅长处理数据和逻辑，但它不懂「人味儿」。书里提到的「与人打交道的技能」、「综合与创造的技能」，在 2026 年反而成了奢侈品。 请重新盘点你的技能包：沟通、共情、甚至「在混乱中做决策」的能力。这些被称为「可迁移技能」，它们是你换赛道时的底气。赛道会死，但技能会随你迁徙。第二点：不要试图骗过算法，去连接「具体的人」 书中观点：求职的「数字游戏」效率极低，建立人际桥梁（The Bridge）才是王道。 2026 年的招聘有多绝望？HR 很少看简历了，第一轮筛选全交给了 AI。你的简历因为少写了几个关键词，直接被系统扔进了垃圾桶。 几十年前，波尔斯就痛斥过这种「撒网式」求职。他提出了「信息面试」（Informational Interviewing）的概念。 AI 时代的启示 当所有人都在用 AI 生成完美的简历去轰炸招聘网站时，「面对面」变得无比珍贵。 不要只盯着招聘启事（那是红海），去寻找你感兴趣的公司里的人。约他们喝杯咖啡（或者是线上的 VR 会议），不是去求职，而是去请教：「现在的行业变化这么快，您觉得核心挑战是什么？」 「如果我想进入这个领域，您建议我补足哪块短板？」在算法统治的世界里，只有「人」才能绕过算法，把机会给另一个「人」。回归线下的真实链接，是 2026 年最高级的求职黑客技术。第三点：那朵著名的「花」——在这个时代，你是谁比你会什么更重要 书中观点：花瓣练习（The Flower Exercise），全方位解构理想生活。 这是全书最经典的工具。作者让你画一朵花，填入你最喜欢的环境、最想服务的人群、最想发挥的特长、最重视的价值观等。 以前读这章，觉得太虚，只想搞钱。但到了 2026 年，当 AI 把枯燥的执行工作接管后，我们终于有时间面对那个终极问题：「我想过什么样的生活？」 AI 时代的启示 AI 没有价值观，没有偏好，它没有灵魂。 如果你不知道自己是谁，你就会成为 AI 的附庸。 现在的我们，更需要做一次彻底的「花瓣练习」。如果你讨厌现在的行业，不是因为你不行，可能是因为这个「环境」不适合你的「花瓣」。 你要找的不是一份「工作」，而是一个能让你这朵花盛开的「生态系统」。在 2026 年，只有个性鲜明、知道自己要什么的人，才不会被标准化的 AI 淹没。结语 2026 年，技术在狂飙，但人性的底层逻辑从未改变。 《你的降落伞是什么颜色》告诉我们：这世界上没有一份工作是「铁饭碗」，唯一的铁饭碗，是你对自己能力的认知，和对未来的掌控感。 当你在高空坠落，感到迷茫恐慌时，别指望 AI 能接住你。你需要打开那顶属于你自己的降落伞。 只要你知道自己是谁，要去向何方，你就永远不会被时代抛弃。

MCP 与 Skill：搞清楚 AI 能力扩展的两个核心概念

MCP 与 Skill：搞清楚 AI 能力扩展的两个核心概念

在 AI 和智能体（Agent）开发领域，MCP（Model Context Protocol，模型上下文协议） 和 Skill虽然都与「扩展 AI 的能力」有关，但它们处于完全不同的架构层级。 简单来说：MCP 是「接口标准」，而 Skill 是具体的「功能实现」。 就像 MCP 是电脑上的 USB 接口协议，而 Skill 则是插在这个接口上的 U 盘、鼠标或打印机。核心概念对比 MCP (Model Context Protocol) MCP 是由 Anthropic 开源的一种标准化通信协议。它解决的是「AI 模型如何安全、统一地连接外部数据源和工具」的问题。本质： 一套 Client-Server 架构的底层基础设施。 作用： 过去，开发者要让 AI 查数据库、读本地文件、调用外部 API，需要为每个平台写定制化的集成代码。MCP 提供了一套通用标准，只要数据源封装成了「MCP Server」，任何支持 MCP 的 AI 客户端（如 Claude Desktop、Cursor、各类 IDE 插件）都可以无缝接入，读取上下文或调用工具。 关注点： 安全性、连接性、标准化、跨平台。Skill (技能) Skill 通常指的是 AI Agent 能够执行的具体任务或业务逻辑。这个概念在 AI 行业存在已久（比如 Amazon Alexa Skills，或者智能体框架中的 Tools/Actions）。本质： 封装好的业务能力。 作用： 赋予 AI 完成特定指令的能力。例如：「搜索网络」、「查询天气」、「总结指定的本地 PDF 代码库」、「在 Jira 中创建一个 Bug 工单」。 关注点： 业务逻辑、Prompt 设计、输入输出的处理。详细区别 {% table %}维度 MCP (模型上下文协议) Skill (技能)层级定位 底层/架构层 (Infrastructure) 上层/应用层 (Application/Logic)核心问题 AI 如何与外部世界建立标准化的连接？ AI 能够为用户完成什么具体任务？通用性 极高。跨平台、跨模型通用。 较低。通常依赖具体的提示词或特定的 AI 框架。开发对象 开发「MCP Server」，定义资源（Resources）和工具（Tools）的暴露方式。 编写代码逻辑或 Prompt，定义输入参数、执行动作和输出结果。 {% /table %}它们是如何协同工作的？ 在现代的 AI 架构中，MCP 往往是实现 Skill 的底层通道。 假设你正在为运维团队开发一个基于 RAG（检索增强生成）的企业知识库系统： 没有 MCP 之前开发 Skill： 你需要写一个大长串的 Python 脚本，直接把 AI 的 API 和公司内部的 Confluence API 绑死在一起。这个「查文档」的 Skill 只能在你的代码库里运行。 使用 MCP 之后开发 Skill：你开发一个连接 Confluence 的 MCP Server。 这个 Server 向外暴露了一个叫 search_internal_docs 的 Skill（或 Tool）。 现在，不仅是你自己写的代码，团队里的开发者用 Cursor 写代码时，或者用 Claude 客户端聊天时，只要连接了这个 MCP Server，他们的 AI 就瞬间具备了「查询公司内部运维文档」的 Skill。总结：你可以通过 MCP 协议，将各种强大的 Skill 标准化地分发给不同的 AI 应用。有了 MCP，为什么还到处是 Skill？ 这是一个很敏锐的问题。你可能会觉得：「既然已经有了一个统一的底层协议（MCP），为什么还要反复强调或者大量去写上层的 Skill 呢？」 其实，MCP 的出现不仅没有消灭 Skill，反而直接促成了 Skill 的「大爆发」。像 Claude、Cursor 现在之所以大量依赖 Skill，正是因为 MCP 把开发和接入 Skill 的门槛降到了前所未有的低。 1. 模型本质上是「缸中之脑」，它永远需要手和眼 无论是多么强大的大语言模型（Claude 3.5 Sonnet、GPT-4o），它们的本质都只是一个「文本预测引擎」。如果没有任何外部工具，它们既不知道现在是几点，也无法读取你 MacBook 上的本地文件，更无法帮你执行终端命令。Skill 就是 AI 的手和眼睛（例如：读取本地文件、执行终端命令、搜索网页）。 MCP 是连接大脑（AI）和手眼（Skill）的神经系统。神经系统再好，没有手眼也干不了活。因此，要想让 AI 真正帮你干活，依然需要大量具体的 Skill。 2. 「解耦」带来了类似 App Store 的效应 在 MCP 出现之前，如果 AI 厂商想让 AI 拥有一个新 Skill（比如「读取本地代码库」），他们必须亲自在自己的客户端里硬编码写死这套逻辑。这导致 AI 能干的事情非常受限。 有了 MCP 之后，发生了类似「苹果推出 App Store」的效应：以前： Claude 团队自己吭哧吭哧写几百个集成逻辑。 现在： Claude 只需要说「我支持 MCP 协议」。然后，全世界的开发者就可以用几行代码写出一个「读取本地 Git 仓库」的 Skill，或者「查询 Jira 状态」的 Skill，封装成 MCP Server 喂给 Claude。正因为 MCP 提供了一个标准的「插座」，现在任何开发者都可以轻松地把成千上万个 Skill（U盘）插到 Claude 这个主机上。 3. 具体到代码开发场景 假设你在本地 macOS 环境下进行开发，遇到了依赖管理或编译报错的问题，AI 需要帮你排查。AI 要真正解决问题，它可能需要调用以下几个 Skill：read_file：读取你本地的配置文件 execute_command：在你的终端跑一下相关的环境检查命令 search_internal_knowledge：去你们公司的内部运维知识库检索在这个过程中，MCP 和 Skill 是如何配合的？Claude/Cursor 客户端 会通过 MCP 协议 与你本地机器上的服务建立安全连接。 通过这个连接，AI 会发现你暴露给了它上述三个 Skill（工具）。 AI 大脑经过思考后决定：「为了排查这个依赖报错，我需要调用 execute_command 这个 Skill。」一句话总结 MCP 是修好的高速公路，而 Skill 是跑在上面的货车。 正因为高速公路（MCP）修通了且标准统一了，你才会看到现在马路上跑着比以前多得多的货车（Skill），去帮你运送数据、执行任务。 未来，随着企业知识库、自动化工作流的普及，这种原子化的 Skill 只会越来越多。搞清楚这两个层级的关系，是理解 AI 工程化、构建真正有用的 AI Agent 系统的关键第一步。

软件开发正迎来它的「印刷机时刻」

软件开发正迎来它的「印刷机时刻」

编程的「印刷机时刻」：当代码消失，软件开发的权力将归还给每一个人在人类文明史上，15世纪的古腾堡印刷术是一个转折点。在那之前，欧洲只有约10%的人掌握读写能力，他们是受雇于权贵的"专业人士"。印刷机的出现让书籍成本下降了100倍，在接下来的50年里，欧洲产出的文献超过了过去一千年。虽然普及教育用了几个世纪，但它最终让文字从精英手中的权杖，变成了人人都能使用的工具。 如今，Anthropic 的 Boris Cherny 提出了一个大胆的断言：软件开发正迎来它的「印刷机时刻」。 一、编程问题已经解决了 在最近的一次访谈中，Boris 向在座的开发者们抛出了一个扎心的问题："现在还有谁是100%手写代码的？"结果显示，现场已没有人坚持手动输入每一行代码。 Boris 透露，他自己已经一年多没写过一行代码了。 现在的 Claude 等最新模型已经能够100%接管代码编写。 在他看来，"编程问题已经解决了"（Coding is solved）。 这一变革的速度将远超当年的印刷机。Boris 认为，软件开发将从一种需要高度专业技能的"手艺"，迅速演变为一种像发短信一样普及的通用技能。 二、从「氛围编程」到「智能体工程」 硅谷技术大神 Andrej Karpathy 为这一变革提供了深层的理论支撑。他提出了**软件 3.0（Software 3.0）**的概念：软件 1.0：人类手写明确的规则（传统代码）。 软件 2.0：通过数据集训练神经网络。 软件 3.0：编程变成了提示词工程（Prompting）。上下文窗口就是我们的杠杆，通过它来驱动 LLM 这个「解释器」在数字空间中执行任务。Karpathy 观察到，自去年12月以来，模型的能力出现了质的飞跃。过去 AI 只能写代码片段，现在它能生成完整且正确的代码块，让人进入一种**「氛围编程」（Vibe Coding）**的状态——你只需要描述愿景，AI 负责实现细节。 但更高的境界是智能体工程（Agentic Engineering）。这不再仅仅是提高速度，而是在保持专业软件质量标准（安全性、健壮性）的同时，指挥一组智能体协同工作。 三、「循环」的力量：AI 正接管繁琐流程 如果说 100% 自动写代码是起点，那么**「循环」（Loops）**则是软件开发的未来形态。 Boris 分享了他的私人工作流：他在手机上运行着几百个甚至几千个智能体。通过一种简单的逻辑——让 AI 利用 Cron 等工具定时运行任务——他构建了无数个「循环」：有的循环在「监视」PR（拉取请求），自动修复 CI 错误； 有的循环在自动重构过时的测试代码； 有的循环每 30 分钟从社交媒体抓取反馈并自动归类。这种「大规模并行」的能力，让一个人就能发挥出过去一整个团队的效能。 四、跨学科通用型人才 在「印刷机时刻」之后，软件的价值将发生重心的偏移。 Boris 指出，当编程变得极其廉价且简单时，掌握**「领域知识」将比掌握「编程语言」**更重要。比如，开发一款会计软件的最佳人选，可能不再是资深工程师，而是一位精通业务的资深会计，因为 AI 让实现变得容易，而「定义问题」才是真正的门槛。 与此同时，我们将看到更多**「跨学科通用型人才」（Cross-disciplinary Generalists）**的崛起。他们既懂产品，又懂设计，还能指挥 AI 完成工程实现。这种人能够通过 AI 这种原生技术，从零开始构建出足以挑战巨头的小型公司。 五、外包思考，但不外包理解 面对 Intelligence 变得像水和电一样廉价的时代，人类还剩下什么？ Karpathy 引用了一句耐人寻味的话：「你可以外包你的思考，但你不能外包你的理解。」虽然 AI 可以替我们写代码、跑循环、做繁琐的执行，但审美、判断力和理解力依然是人类最后的堡垒。 结语 我们正站在软件开发历史上最令人兴奋的门槛上。正如印刷机终结了知识的垄断，AI 正在终结代码的垄断。软件的未来，不再属于那些会写代码的人，而属于那些有想法、有洞察、并懂得如何与机器协作的人。