开发者自研CLI工具mdtopdf：支持Obsidian语法，专为优化AI Agent文档输入设计

前沿哨所

• 即梦AI实战教程：利用DeepSeek与多模态大模型从零创作AI短片

  近日，Linux.do社区发布了一套名为“Ai短片创作-从零基础到实战落地”的综合性视频教程资源，该资源汇集了50余个教学视频，系统地展示了当前国产AI工具在视频生成与创作领域的全流程应用。该教程不仅涵盖了基础的“即梦AI”界面操作与提示词工程，还深入解析了智能画布、图生图等高阶功能。课程内容极具实操性，包含《山海经》异兽变身、萌宠做饭、特工营救等具体案例的制作过程，特别强调了在创作中植入DeepSeek大模型以及Agent模式的应用，展示了从剧本、绘图、配音到最终剪辑的完整商业短剧制作闭环。此外，教程还涉及了即梦AI 3.0至4.0版本的更新迭代对比，详细讲解了多模态大模型在视频生成中的角色一致性保持及对口型技术。这套资源为开发者及创作者提供了利用国产工具链进行低成本、高质量AI影视制作的详细路径。

  事件分析

  这套教程的发布标志着AI视频生成领域正在从单一的模型调用向系统化的工作流协作转变。从技术层面看，教程中涉及的DeepSeek植入与Agent模式解析，反映了业界正在尝试利用强大的推理模型来弥补纯视觉模型在叙事逻辑上的不足，即通过LLM（大语言模型）与CV（计算机视觉）模型的协同，实现更精准的画面控制和复杂的剧情编排。从产业视角来看，通过即梦AI等国产工具，配合AI音乐生成、智能画布等插件化能力，已经能够实现商业级TVC广告、古风短剧及绘本视频的批量生产。这意味着影视制作的门槛正在被技术极大地降低，未来的竞争核心将不再是软件操作，而是提示词编排能力与对多模态模型组合的深刻理解。国产多模态模型在视频领域的快速迭代，正在加速AIGC技术从娱乐化向专业生产力工具的进化。

  💡 核心观点：AI视频制作已进入“Agent+多模态”协同的新阶段，国产工具链的成熟正推动影视内容生产向标准化、流程化及低成本方向快速演进。

  原文链接：Linux.do

  5小时前

• 国产大模型套餐横评：MiniMax、DeepSeek、Kimi 与 GLM 的性价比深度对比

  本文针对国内主流大模型厂商的付费套餐进行了详细对比分析，旨在为开发者和个人用户提供购买建议。评测涵盖了 MiniMax、GLM（智谱）、DeepSeek、Kimi（月之暗面）及 MIMO 五家厂商。在性价比方面，MiniMax 被认为是首选，其 Plus 套餐周额度高达 4 亿 token，Max 套餐更是提供了约 12 亿 token 的海量额度，且搜索功能仅消耗 token 不额外计费，支持多模态生成，非常适合长时间 coding 和多模态开发。GLM 模型编程能力强，但 Lite 套餐额度偏低，且高峰期消耗三倍额度，视觉功能依赖 MCP 转述存在精度损失。DeepSeek 在 API 价格上优势明显，但在套餐模式下，若缓存命中率不高，实际成本并不便宜，且暂不支持视觉。Kimi 被指出额度体验较差，计费规则不透明，不适合作为主力 coding 工具。MIMO 则存在积分换算陷阱，实际可用额度需仔细折算。综合建议是：追求稳定大量使用选 MiniMax，特定强编码场景考虑 GLM，API 调用首选 DeepSeek。

  事件分析

  此次评测反映了国产大模型在商业化落地过程中从“API 价格战”向“订阅服务体系”的转型。厂商们正试图通过打包 token、多模态能力（图像、语音）及搜索功能来构建差异化竞争壁垒。技术层面上，各家在长文本处理和代码生成能力上已趋同，但在多模态交互的稳定性（如 GLM 的视觉转述精度）和高峰期服务调度（如 GLM 的三倍消耗）上仍存在明显差异。DeepSeek 的缓存机制和 MiniMax 的全功能整合策略表明，未来的竞争将不仅是模型能力的比拼，更是资源调度效率和生态整合能力的较量。对于开发者而言，混合使用不同模型以应对不同场景（如代码、多模态、搜索）将成为提升效率的最优解。

  💡 核心观点：大模型订阅制的核心竞争力已从单纯的低价转向高并发下的稳定性与多模态调用的灵活性，单一模型已难以覆盖全场景需求。

  原文链接：Linux.do

  5小时前

• AI Agent接管运维：开源项目Server Security Init实现服务器安全自动化

  针对新手用户在拿到服务器后不知如何进行安全配置的痛点，一项名为“Server Security Init Skill”的开源项目近日在社区发布。该项目旨在利用AI Agent的能力，自动完成Ubuntu/Debian服务器的全流程安全加固与初始化。该项目不仅是一个脚本工具，更被设计为一个AI Agent技能，可以直接将GitHub链接提供给具备Agent能力的AI（如Claude或OpenAI系列），由AI自主读取代码并执行安装。其功能涵盖了服务器安全初始化的完整闭环：首先是身份认证的安全加固，能够自动生成本地SSH密钥对，引导用户完成公钥上传，并验证登录可用性；随后创建具备免密sudo权限的非root用户，并修改SSH端口，彻底禁止不安全的root登录和密码登录方式。在网络防御层面，该Skill会自动配置UFW（Uncomplicated Firewall）防火墙策略，仅保留必要端口的放行规则，并部署Fail2ban防暴力破解工具，同时支持将管理员IP加入白名单以防误封。最后，它还能智能更新本地的SSH config配置文件，实现通过服务器别名直接连接。该项目已在GitHub完全开源，标志着AI技术在DevOps和基础设施自动化领域的实际落地，为开发者提供了一种无需手动编写脚本即可完成复杂系统配置的全新范式。

  事件分析

  该项目的核心价值在于验证了AI Agent从“信息处理”向“系统操作”转型的可行性。与传统的Shell脚本或Ansible Playbook不同，Agent Skill模式将操作逻辑封装为AI可理解、可调用的能力单元。这意味着大模型不再仅仅局限于生成代码片段，而是可以直接作为执行者，介入并控制底层Linux系统的关键配置。从技术角度看，这种模式体现了“意图驱动计算”的趋势：用户只需表达“初始化并加固服务器”的高层意图，Agent便能拆解任务并精准执行chmod、ufw、iptables等底层指令。这降低了服务器安全运维的门槛，同时也引发了对AI操作权限与系统风险的思考。随着此类垂直领域开源技能的积累，Agent生态正在从单纯的对话模型演变为具备复杂工程能力的自动化操作系统，未来有望重构开发与运维的工作流。

  💡 核心观点：AI Agent正从对话助手进化为系统级执行代理，标准化开源技能的涌现标志着运维自动化迈入意图驱动的新阶段。

  原文链接：Linux.do

  5小时前

• Claude Desktop 中文使用指南: 安装、中文交互与 MCP 配置

  很多人搜「claude desktop 中文」，心里其实有两个并列的问题：一是想找一份能照着做的中文安装与使用教程，二是想知道这个桌面客户端到底能不能切成简体中文界面、能不能用中文跟它对话。

  这两件事的答案不一样，而且必须先讲清楚，否则你会在「设置里翻语言选项」这条死路上浪费时间。本文就围绕「用中文把 Claude Desktop 用顺」这个目标，从安装、登录、让它始终用中文回答、界面语言现状，一直讲到 MCP 配置和中文场景下的常见问题排查。

  Claude Desktop 是什么，能不能用中文

  先把结论用一段话讲完，赶时间的人看这一节就够。

  Claude Desktop 是 Anthropic 官方推出的桌面客户端，把网页版 Claude 装进了一个独立的应用窗口，支持 macOS 和 Windows。它的核心价值不只是「网页套个壳」：桌面版能读本地文件、能通过 MCP（Model Context Protocol）协议接外部工具，相当于把一个能调用工具的 AI 助手放在你的电脑上。

  关于「中文」，要分成两层来理解，这也是本文最关键的一个判断：

  • 界面语言：Claude Desktop 的官方界面目前以英文为主，菜单、按钮、设置项基本是英文。它没有一个「设置 → 语言 → 简体中文」这样的一键切换 UI。如果你打开设置在找语言选项，是找不到的——不是你没找到，是它本来就没有。这一点必须先认清，否则后面全是无用功。
  • 对话语言：这一层完全没问题。Claude 对中文的理解和生成能力很强，你直接用中文提问，它就用中文回答；你让它「以后都说中文」，它就会一直说中文。也就是说，「用中文」主要体现在对话交互上，而不是界面汉化上。

  所以「Claude Desktop 中文怎么用」的正确答案是：界面用英文，但你和它之间全程可以是中文。 英文界面只是几十个固定按钮，看一遍就记住了；真正高频的交互是对话框，那里你想用什么语言都行。

  如果你还在纠结桌面客户端、命令行工具、网页版到底怎么选，可以参考我们写过的 AI 编程工具现状：从 IDE 到 CLI，开发者如何在 Cursor 与 Claude 间抉择，里面把不同形态的取舍讲得比较细。

  安装与登录

  桌面版的安装本身很简单，门槛主要不在「装」，而在「能不能正常登录与联网」。

  下载客户端

  从 Anthropic 官网（claude.ai 相关的下载入口）获取对应平台的安装包：

  • macOS：下载后是一个 .dmg，打开把 Claude 拖进「应用程序」文件夹即可。首次打开如果系统提示「来自互联网的应用」，按 macOS 的常规授权流程允许打开。
  • Windows：下载安装程序双击安装，按引导走完即可。

  具体的版本号、安装包大小、菜单措辞，请以你下载到的客户端实际版本为准——这类细节官方会随版本更新，没必要背。

  登录账号

  打开应用后会要求登录 Anthropic 账号。这里有两个现实问题中文用户经常碰到：

  1. 网络可达性：客户端需要稳定连接 Anthropic 的服务。如果一直卡在登录页或提示连接失败，先排查网络环境是否能正常访问对应服务，而不是反复重装。
  2. 账号与额度：免费账号有用量限制，重度使用一般要订阅 Pro 或更高档位。如果你卡在「官方订阅要海外信用卡、价格也不低」这一步，社区里常见的替代路径是走中转/聚合服务，我们实测过其中一家，写在 AnyRouter 实测：模型路由、API 兼容与价格稳定性，可以作为了解这类方案利弊的参考——但要注意，桌面客户端官方登录走的是官方账号体系，中转方案更多适用于 API/命令行场景，两者别混为一谈。

  登录成功后，你就进入了主对话界面。这时候第一件该做的事，不是急着提问，而是先把语言习惯设好。

  让 Claude 始终用中文回答

  这是把「Claude Desktop 用成中文助手」的核心动作。既然没有界面汉化，那就让模型在对话层面始终说中文。有两种做法，建议两种都用。

  做法一：每次对话直接用中文问

  最朴素的办法：你用中文提问，Claude 默认就会用中文回答。对绝大多数日常使用，这就够了。Claude 会跟随你输入的语言，你说中文它回中文，你贴一段英文文档让它「用中文总结」，它也会用中文输出。

  这种做法的唯一缺点是：偶尔在长对话里、或你贴了大段英文资料后，模型可能「顺着英文语境」飘回英文。要彻底锁定，就要用做法二。

  做法二：用自定义指令 / 个人偏好把「说中文」写死

  Claude 提供了让你设置个人偏好 / 自定义指令的地方（在设置里，通常叫 Profile、Personalization 或 Custom Instructions 一类，具体措辞以你的客户端版本为准）。这相当于一段「常驻系统提示」，每次新对话都会自动生效。把语言偏好写进去，就不用每次手动叮嘱。

  下面这段中文指令模板可以直接复制进去：

  请始终用简体中文回答我，无论我用什么语言提问。
  保留专业术语、代码、API 名称、命令、文件路径的英文原文，不要硬翻译。
  代码注释用中文，变量名和函数名保持英文。
  回答先给结论，再给步骤或理由，不要绕弯子。
  不确定的地方明确说明，不要编造不存在的菜单、版本号或参数。
  

  如果你主要拿 Claude 写代码或做工程，可以再补一句偏好，让它的输出风格更贴合开发场景：

  涉及命令行操作时，给出可直接复制运行的完整命令，并标注它在哪个操作系统下有效。
  解释报错时，先定位根因，再给修复步骤，不要只贴一段「可能的原因」。
  

  设置完这段偏好后，新开一个对话试一句英文提问，看它是否仍用中文回复。如果生效，恭喜你，往后界面是英文、交互全中文的状态就稳定了。

  顺带一提，这套「把规则写进常驻指令、让模型每次都遵守」的思路，和命令行端的 Claude Code 用 CLAUDE.md 约束模型行为是同一个逻辑。想深入理解这套配置范式怎么显著影响输出质量，可以读 CLAUDE.md 怎么写：提升 Claude Code 准确率的最小有效配置——桌面版的个人偏好，本质上就是一个轻量版的常驻配置。

  界面语言现状与替代办法

  前面反复强调「没有官方中文 UI」，这里把替代办法摊开讲，免得你觉得「那英文界面是不是就只能硬扛」。

  先接受现状

  Claude Desktop 的界面目前以英文为主，没有官方提供的简体中文界面切换。任何教程如果告诉你「进设置点 Language 选中文」，那要么是把它和别的软件搞混了，要么是凭空编的。请相信你自己——设置里确实没有那个选项。

  替代办法一：英文界面其实只需记十几个词

  桌面客户端的界面元素是高度固定的：新建对话、发送、设置、个人资料、模型选择、文件上传、停止生成……翻译过来就十几个高频词。对照记一遍，之后看英文界面跟看中文没差别。真正承载信息量的是对话内容，而那部分你已经全程用中文了。

  替代办法二：用浏览器翻译看网页版

  如果你实在更习惯中文界面，可以退一步用网页版 Claude，配合浏览器自带的「翻译此页面」功能，把界面机翻成中文。代价是：浏览器翻译有时会误翻对话区里的代码或专有名词，且你会失去桌面版独有的本地文件访问和 MCP 能力。所以这条路适合「只想聊天、不需要工具」的轻量用户，重度用户还是建议留在桌面版、接受英文界面。

  替代办法三：让 Claude 自己当「界面翻译」

  遇到某个英文设置项不确定是什么意思，可以直接截图丢给 Claude，让它用中文解释这个选项是干嘛的。这是最省事的办法——你手里就有一个最强的翻译工具，没必要去别处找汉化包。顺便提醒：网上流传的第三方「Claude 汉化补丁/汉化版」要格外警惕，桌面客户端涉及你的账号和本地文件权限，来路不明的修改版有账号和数据安全风险，不建议碰。

  MCP 配置：claude_desktop_config.json 怎么写

  桌面版相对网页版最大的增量能力，是能通过 MCP（Model Context Protocol） 接入外部工具——让 Claude 能读你的本地文件、查数据库、调用各种服务。这部分配置是真实存在、可照做的，下面给一份能落地的说明。

  配置文件在哪

  MCP 的配置写在一个名为 claude_desktop_config.json 的文件里，位置在不同系统下分别是：

  • macOS：~/Library/Application Support/Claude/claude_desktop_config.json
  • Windows：%APPDATA%Claudeclaude_desktop_config.json

  最稳妥的打开方式不是手动去翻文件夹，而是在客户端里走 Settings → Developer → Edit Config（开发者设置里的「编辑配置」），它会直接帮你定位并打开这个文件。如果这个文件还不存在，新建一个、写入最小内容 {"mcpServers": {}} 即可。

  注意：这里走的是 Developer（开发者） 设置，不是语言设置——再次强调，设置里没有语言切换项，但有这个开发者配置入口。

  配置文件的基本结构

  整个文件是一个 JSON 对象，核心是 mcpServers 这个键，里面每一项就是一个你要接入的工具服务器，结构大致如下：

  {
    "mcpServers": {
      "服务器名称": {
        "command": "启动命令",
        "args": ["参数1", "参数2"]
      }
    }
  }
  

  举一个官方文档里常见的本地文件服务器为例（具体的包名、参数请以该服务器自己的官方文档为准，不同服务器写法不同，不要照搬别处的参数）：

  {
    "mcpServers": {
      "filesystem": {
        "command": "npx",
        "args": [
          "-y",
          "@modelcontextprotocol/server-filesystem",
          "/你想让 Claude 访问的目录路径"
        ]
      }
    }
  }
  

  这段配置的意思是：注册一个叫 filesystem 的工具，用 npx 启动一个能访问指定目录的文件服务器，之后 Claude 就能在对话里读写那个目录下的内容。

  三个最容易踩的坑

  写 MCP 配置时，下面三点几乎是新手必踩的：

  1. JSON 语法不能错：少一个逗号、多一个逗号、引号没闭合，整个配置就加载失败。改完先检查一遍语法，或者让 Claude 帮你核对这段 JSON。
  2. 改完必须完全重启客户端：MCP 配置是在客户端启动时加载的，你保存了文件但不重启，是不会生效的。要彻底退出 Claude Desktop（不是关窗口，是整个退出进程）再重新打开。
  3. command 最好写完整路径：客户端启动子进程时用的环境变量（PATH）往往很精简，导致 npx、docker 这类短命令在终端能跑、在这里却报「找不到命令」。稳妥做法是把可执行文件的完整路径填进去。

  如果你同时在桌面版、命令行、IDE 插件里都配了 MCP，配置文件散在好几个地方、各自为政，管理起来很烦。社区里已经有人做了聚合管理这类配置的开源工具，比如 开源工具 SMRmanager 发布 v0.2：聚合管理多客户端 MCP 协议，新增 WSL 支持，以及更早的介绍 开源工具 SMRmanager：一键统一管理 Claude、Cursor 等 AI 编程工具配置，多客户端混用的人可以了解一下。

  MCP 这套「让 AI 接外部工具」的能力，也是当下桌面客户端和编程 Agent 的共同方向。如果你想把本地知识库接进来，可以看 开源 AI 笔记工具 OpenKnowledge 登场：集成 Claude 和 Cursor，打造本地优先的知识库；想理解工具调用能力在不同模型间的差异，1M 上下文已经可用：Claude、Gemini 与编程 Agent 怎么选 也值得一读。

  中文场景常见问题排查

  把中文用户最常遇到的几类卡点集中处理一下，对照自查。

  它又开始说英文了怎么办

  如果中途模型飘回英文，多半是因为：你贴了大段英文资料、或者对话很长导致语境被英文主导。两个解法：一是回到上一节用「自定义指令」把中文锁死；二是当场补一句「请继续用中文回答」，模型会立刻切回来。把偏好设好之后，这种情况会大幅减少。

  中文输入法 / 快捷键冲突

  在英文界面下用中文输入法打字，偶尔会遇到回车键行为不符合预期（比如想换行却直接发送了，或者想发送却在输入法候选阶段被吞掉）。不同版本的发送键与换行键组合可能不一样，以你的客户端实际版本为准；通用排查思路是：先确认输入法处于「已上屏」状态再按回车，必要时用「换行的组合键」单独换行。

  中文文档上传后乱码或理解偏差

  上传中文文档（尤其是 PDF、老编码的 txt）时，如果 Claude 的理解出现明显偏差，先怀疑文件编码或解析问题，而不是模型能力问题。可以把关键段落直接粘贴进对话框作为对照，或者把文件转成 UTF-8 编码的纯文本再上传。

  中文场景下该用哪个模型

  桌面版通常允许在不同模型档位间切换。涉及中文写作、中文资料处理时，主流的 Claude 模型表现都不错；如果你做的是中文为主、且对成本和部署灵活度敏感的工程任务，也值得横向比一比国产模型，我们写过 GLM-5.2 vs GPT-5.5：架构、Agent 与部署取舍对比，里面专门谈到了中文场景的取舍。

  桌面版和命令行版怎么分工

  不少人同时在用 Claude Desktop 和命令行的 Claude Code，容易混淆。简单说：桌面版偏「对话 + 桌面工具」，命令行版偏「在仓库里直接读写代码、跑命令」。两者的配置思路（系统提示、MCP）相通，但使用场景不同。想搞清楚命令行端在长项目里怎么用，可以看 Claude Code 长项目踩坑：vibe coding 与 spec coding 何时切换。

  相关阅读

  把 Claude Desktop 用顺之后，下面这些站内文章能帮你把整套 AI 编程/对话工作流补全：

  • Claude Code vs Codex vs WorkBuddy vs Zcode：AI 编程 Agent 怎么选 —— 桌面对话之外，命令行 Agent 的横向选型。
  • 将 Vibe Coding 工程化：开源项目详解 AI 辅助编程的正规化工作流 —— 把随性提问升级成有规范的工作流。
  • 开源项目「知返」破解 Vibe Coding 困境：让 AI 编程回归知识获取 —— 别让 AI 只产代码，把知识也留下来。
  • 多仓库开发的 AI 困境：如何实现从设计稿到多库代码的全链路自动化 —— 当你的项目跨多个仓库时的进阶用法。
  • Claude Code 界面重现「Fable-5」选项，Anthropic 或推进新特性测试 —— 关注客户端的新特性动向。
  • AI 文档平台 Kyber 招募工程主管，要求熟练掌握 Cursor 与 Claude Code —— 从招聘需求侧看这套工具链的行业认可度。
  • Codex 磁盘占用异常：失控写盘的根因与排查清理 —— 桌面客户端同样会在用户目录留配置和缓存，了解一下排查思路。

  FAQ

  Q1：Claude Desktop 能切换成简体中文界面吗？
  不能。官方目前没有提供简体中文界面的一键切换，界面以英文为主。但你可以全程用中文跟它对话，并通过自定义指令让它始终用中文回答——「用中文」靠的是对话，不是界面汉化。

  Q2：我在设置里找不到语言选项，是不是版本太老？
  不是版本问题。Claude Desktop 本来就没有语言切换设置，再新的版本也找不到。设置里有的是账号、个人偏好、开发者（MCP 配置）等入口，但没有界面语言项。

  Q3：怎么让 Claude 每次都用中文，不用我反复提醒？
  在客户端的个人偏好 / 自定义指令里写一段常驻指令（本文第三节给了可复制模板），明确要求「始终用简体中文回答、保留术语英文原文」。设好后每个新对话都会自动生效。

  Q4：MCP 的 claude_desktop_config.json 改了不生效？
  最常见原因是没有完全重启客户端，或者 JSON 写错了。改完要彻底退出 Claude Desktop 再打开，并检查 JSON 语法；如果用 npx 这类命令报「找不到」，把命令换成完整路径。

  Q5：用第三方汉化补丁安全吗？
  不建议。桌面客户端涉及账号登录和本地文件权限，来路不明的汉化/修改版有账号和数据安全风险。需要中文界面的话，优先用「网页版 + 浏览器翻译」这种不改客户端本体的方式。

  结语

  「Claude Desktop 中文怎么用」这件事，最容易走的弯路就是去设置里找一个并不存在的语言开关。把这个预期先纠正过来，剩下的就顺了：界面是固定的十几个英文按钮，记一遍就行；真正的交互全程可以是中文，靠的是「直接用中文问」加「自定义指令锁定中文」。需要更强能力时，再通过 claude_desktop_config.json 接上 MCP 工具。

  一句话总结：Claude Desktop 没有中文 UI，但它完全是一个能用中文工作的助手。 把语言偏好设好、把 MCP 配明白，你就拥有了一个装在本地、说中文、还能调用工具的 AI。剩下的，交给对话框就好。

  6小时前

• Agent Skill 跨工具复用: 目录结构、版本管理与团队共享

  TL;DR: 多工具时代, skill 不该各管各的

  如果你同时在用 Claude Code、Codex、openclaw、hermes 这类 agent 工具, 大概率已经踩进同一个坑: 同一套”让 agent 怎么提交代码””怎么写 commit message””怎么发布到 WordPress”的知识, 被你在四个工具里各写了一遍。改一处, 另外三处忘了同步; 半年后想不起来哪个版本是最新的; 换台机器又得手动拷一遍。

  这不是工具的问题, 是你把 skill 当成了”每个工具的私有配置”, 而不是”独立于工具存在的工程资产”。

  一句话结论: agent skill 本质是纯文本 + 脚本目录, 天然适合用 git 管理、用软链或子模块在多工具间共享一份源、用语义化版本号追踪演进。 把这三件事做对, 你维护的就从”四份会漂移的副本”变成”一份可 diff、可回滚、可团队协作的真相源”。

  下面按这个顺序拆: 先讲清楚 skill 到底是什么、为什么能跨工具复用; 再给标准化目录结构; 然后是一份源多工具复用的几种接法; 接着是 git 版本管理与变更记录; 最后是跨工具迁移的差异点和团队协作流程。

  读之前如果你对 agent 工具本身还没选定, 可以先看 Claude Code vs Codex vs WorkBuddy vs Zcode: AI 编程 Agent 怎么选 和 Codex vs Cursor 额度对比: 价格、限制与选型建议, 把工具盘子定下来再谈复用更有意义。

  一、Agent Skill 的本质: 为什么它能跨工具

  1.1 Skill 不是插件, 是”可被加载的专业知识包”

  很多人第一次接触 skill, 会下意识把它类比成浏览器插件或者 IDE 扩展——一个绑死在某个宿主里、调一套私有 API 的二进制。这个类比会把你带偏。

  以 Claude Code 的 Skill 范式为例, 一个 skill 的核心就是一个文件夹, 里面放一份 SKILL.md。这份 markdown 顶部有 YAML frontmatter, 只需要两个字段就能跑起来:

  ---
  name: commit
  description: 用规范化的 conventional commit 信息创建提交。当用户要求提交代码、写 commit message、整理变更时触发。
  ---
  
  # Commit Skill
  
  ## 何时使用
  当工作区有未提交改动, 且用户要求"提交""commit""存一下"时。
  
  ## 步骤
  1. 运行 `git status` 和 `git diff` 看清改了什么
  2. 按 conventional commit 规范归类: feat / fix / docs / chore ...
  3. 生成简洁的标题 + 必要的正文
  4. 提交前用 `git diff --staged` 复核
  

  注意它的形态: 没有一行宿主专属代码, 全是自然语言 + shell 命令。 这正是它能跨工具的根本原因——它描述的是”做这件事的方法”, 而方法本身不依赖某个特定 agent 的运行时。

  1.2 渐进式加载: description 是检索入口, 不是装饰

  Claude Code 的 skill 有一个关键机制叫渐进式披露 (progressive disclosure): 系统启动时, 并不会把每个 skill 的全文塞进上下文, 而是只加载 name 和 description 两个字段。模型根据当前任务语义匹配到某个 description, 才会去读那份 SKILL.md 的正文; 正文里再引用 references/ 或 scripts/ 时, 又是按需加载。

  这套机制对”复用”有两个直接含义:

  • description 写得好不好, 决定了 skill 能不能被正确触发。 它不是文档摘要, 是检索关键词。要把”什么时候用我”写清楚, 把用户可能说的触发词都覆盖到。
  • 正文和资源按需加载, 意味着一个 skill 可以很厚而不污染上下文。 你可以把长 checklist、模板、参考表都塞进 references/, 平时不占 token, 用到才拉。

  这种”薄入口 + 厚实现”的思路, 和 agent 工程里反复出现的一个判断是同构的: 复杂度应该沉淀进可复用的资产, 而不是困在一次性对话里。关于 harness 和 skill 谁轻谁重的取舍, Agent Harness 不是要安装的软件包 和 Loop Engineering 是 Harness 的局部命名 讲得比较透, 值得对照着读。

  1.3 为什么”纯文本 + 脚本目录”是可迁移的最大公约数

  再看 Codex、openclaw、hermes。它们各自的扩展机制在字段名、加载方式上肯定有差异——Codex 有自己的指令文件与自定义提示约定; openclaw、hermes 这类工具有各自的组织方式。但把它们抽象一层就会发现, 几乎所有 agent 工具的”能力扩展”都落在同一个最大公约数上:

  一段告诉 agent 怎么做某件事的自然语言提示, 加上一组它可以调用的脚本/命令。

  以 hermes 这类偏调度型的 agent 为例, 它的 skill 通常也是走 prompt 描述 + 脚本目录的组织方式; openclaw 这类工具同理。字段叫什么、放在哪个目录、用什么格式声明触发条件, 这些是表层差异; 而”提示 + 脚本”这个内核是共享的。

  这就是跨工具复用在工程上成立的前提: 你维护的真相源应该是这个内核, 而把各工具的表层差异留给一层薄薄的适配。下面所有方法论都建立在这个判断上。

  二、标准化目录结构: 一份 skill 长什么样

  复用的第一步是约定结构。如果每个 skill 的内部布局都不一样, 后面的软链、迁移、版本管理都无从下手。下面是一套被验证可用的标准布局——它向 Claude Code 的 skill 约定看齐, 同时刻意保持”任何工具都能消费”的中立性:

  skills/
  ├── commit/
  │   ├── SKILL.md            # 入口: frontmatter(name/description) + 正文
  │   ├── references/         # 按需加载的厚资料: 规范表、模板、checklist
  │   │   └── conventional-commit-spec.md
  │   └── scripts/            # 可执行脚本, 被正文引用
  │       └── gen-message.sh
  ├── blog-publish/
  │   ├── SKILL.md
  │   ├── references/
  │   │   ├── seo-title-rules.md
  │   │   └── frontmatter-template.md
  │   ├── scripts/
  │   │   ├── build-images.py
  │   │   └── publish.sh
  │   └── assets/             # 静态资源: 模板图、样式片段
  │       └── poster-base.svg
  └── code-review/
      ├── SKILL.md
      └── references/
          └── review-checklist.md
  

  几条约定值得明确:

  1. 一个 skill 一个目录, 目录名即 skill 名, 和 frontmatter 里的 name 保持一致。这样工具扫描目录就能建立索引。
  2. SKILL.md 是唯一入口, 正文尽量短, 把”何时用 / 怎么用 / 边界”讲清楚即可。详细规则下沉到 references/。
  3. scripts/ 放确定性逻辑。 agent 擅长决策, 不擅长精确执行重复步骤。能用脚本固化的(改文件名、调 API、跑校验), 就别让模型每次现写。这点和”把 agent 当决策者、把确定性留给代码”的工程直觉一致, 构建 Agent 和写软件, 是两种工程 对这个边界有专门的讨论。
  4. references/ 是按需加载区。 越厚越好, 因为平时不占上下文。SEO 清单、品牌规范、API 字段表, 都该放这里。
  5. assets/ 放二进制或静态模板, 和会频繁 diff 的文本分开, 避免污染 git 历史。

  这套结构的好处是关注点分离: 决策(SKILL.md)、知识(references)、执行(scripts)、资源(assets)各居其位。换工具时, 你迁移的是整个目录, 而不是从一坨混在一起的配置里抠。

  三、一份 skill 源, 多工具复用

  结构定了, 接下来是核心问题: 同一个 skill, 怎么让 Claude Code、Codex、openclaw、hermes 都能用上, 而只维护一份源?

  核心原则只有一句: 真相源 (source of truth) 唯一, 各工具的目录是它的投影。 不要在每个工具的配置目录里各放一份会各自演化的副本。下面是三种接法, 从轻到重。

  3.1 方案 A: 软链接 (symlink)——最轻, 适合单人多工具

  把所有 skill 集中放在一个独立仓库, 比如 ~/agent-skills/。然后在每个工具期望的目录位置, 用软链指过去:

  # 真相源
  ~/agent-skills/skills/commit/
  ~/agent-skills/skills/blog-publish/
  
  # 各工具消费点, 全部软链到同一份源
  ln -s ~/agent-skills/skills  ~/.claude/skills
  ln -s ~/agent-skills/skills  ~/.codex/skills
  ln -s ~/agent-skills/skills  ~/.config/openclaw/skills
  

  改一处, 处处生效, 因为它们物理上就是同一份文件。优点是零同步成本、改完立即可见; 缺点是软链对某些工具的扫描器不一定友好(有的工具不跟随符号链接), 跨机器要重新建链, Windows 下软链权限也更麻烦。

  适用场景: 单人、同一台开发机、多个工具。这是收益最高、成本最低的起点。本站把自营分站统一管理时也用过类似”一份源 + 多处指向”的思路。

  3.2 方案 B: git submodule——适合多仓库、需要钉版本

  如果 skill 要被多个项目仓库引用, 而且你希望每个项目能钉在某个 skill 版本上(不被上游改动随时影响), 用 git submodule:

  # 在项目仓库里把 skill 仓库挂为子模块
  cd my-project
  git submodule add [email protected]:me/agent-skills.git .agent/skills
  
  # 各工具再软链到子模块目录, 或工具直接读这个路径
  ln -s ../.agent/skills .claude/skills
  
  # 升级时显式拉取并锁定到新 commit
  cd .agent/skills && git pull origin main && cd -
  git add .agent/skills && git commit -m "chore: bump skills to latest"
  

  submodule 的关键价值是版本锁定: 子模块在父仓库里记录的是一个确定的 commit hash。这意味着 A 项目可以用 skill 的 v1.2, B 项目还停在 v1.0, 互不干扰, 升级是一次显式的、可在 PR 里 review 的动作。代价是 submodule 的心智负担确实存在(忘记 --recurse-submodules、游离 HEAD 等老问题), 团队得统一约定。

  3.3 方案 C: 同步脚本——工具不认软链时的兜底

  有些工具就是不跟随软链, 或者要求 skill 必须是真实文件。这时用一个幂等的同步脚本, 把真相源拷贝到各工具目录:

  #!/usr/bin/env bash
  # sync-skills.sh —— 把真相源同步到各工具消费目录
  set -euo pipefail
  SRC="$HOME/agent-skills/skills"
  
  for dst in 
    "$HOME/.claude/skills" 
    "$HOME/.codex/skills" 
    "$HOME/.config/openclaw/skills"
  do
    mkdir -p "$dst"
    rsync -a --delete "$SRC/" "$dst/"   # --delete 保证目标和源一致, 不留孤儿
    echo "synced -> $dst"
  done
  

  rsync --delete 保证目标目录和源完全一致, 不会留下已删 skill 的残骸。把这个脚本挂到 git 的 post-merge hook 或一条手动命令上, 每次更新源后跑一次即可。它比软链笨, 但最通用——任何工具都吃真实文件。

  三种方案不互斥: 常用工具走软链, 个别挑食的工具用同步脚本补齐, 跨项目引用上 submodule。判断标准就一条——永远只有一份会被编辑的源, 其余都是它的只读投影。 这和”不要重复造轮子、把基础设施收敛成一份”的工程主张是一回事, 告别重复造轮子: 为什么 AI Agent 创业不应自研基础设施 把这个取舍讲到了创业层面。

  四、版本管理: 用 git 把 skill 当代码养

  skill 是纯文本, 这意味着它能享受软件工程几十年积累的全部版本管理红利。别浪费这个优势。

  4.1 skill 仓库本身就该是个 git 仓库

  最基本的一步: ~/agent-skills/ 初始化成 git 仓库, 推到远端。这样你立刻获得三件事——历史可追溯(谁在什么时候改了哪条规则)、可回滚(某次改动让 skill 触发变差, 一个 git revert 回去)、可 diff(改动一目了然, 因为全是文本)。

  这正是”纯文本 + git”组合的核心价值。对比一下: 如果你的 skill 是埋在某个工具 GUI 里的配置项, 上面这三件事一件都做不到。

  4.2 语义化版本: 给 skill 打 tag

  当 skill 开始被多个项目、多个人引用时, 引入语义化版本 (SemVer) 就有意义了。约定:

  • MAJOR (2.0.0): 破坏性变更。比如改了 skill 的触发语义、删了某个被脚本依赖的字段、调整了输出格式, 老的调用方需要适配。
  • MINOR (1.3.0): 向后兼容地加能力。新增一个 reference、扩展触发词、加一个可选脚本。
  • PATCH (1.2.1): 修字。typo、措辞优化、修一个脚本 bug, 不改行为契约。

  打 tag 的操作:

  git tag -a v1.3.0 -m "blog-publish: 新增 SEO 标题硬规则 reference"
  git push origin v1.3.0
  

  submodule 引用时, 就可以钉到 v1.3.0 这个 tag 而非游动的 main, 升级变成”从 v1.3.0 到 v1.4.0″这种可读、可评审的动作。

  4.3 CHANGELOG: 让”为什么这么改”留痕

  git 历史记录了”改了什么”, 但”为什么改、改了之后触发效果有没有变好”需要单独留痕。在 skill 仓库根放一份 CHANGELOG.md:

  # Changelog
  
  ## [1.3.0] - 2026-06-26
  ### Added
  - blog-publish: 接入 SEO 标题硬规则 reference, 标题生成前强制过清单
  ### Changed
  - commit: description 补充"存一下""归档"等触发词, 提升命中率
  
  ## [1.2.1] - 2026-06-20
  ### Fixed
  - code-review: 修正 checklist 里一处误导性表述
  

  这件事在 agent 语境下尤其重要。skill 的好坏不像普通代码那样有确定的单元测试, 它的”对不对”体现在触发是否准、产出是否稳。 你改一版 description, 触发率可能上去也可能下去, 这本质是个需要观测的反馈过程。把每次改动和它的意图记下来, 才能在效果回退时定位是哪一次改坏的。

  关于”agent 的效果如何度量”这件事本身就是门学问, LLM 评测的下一步是一张二维矩阵 和 Prompt Learning 的两个反馈圈 提供了两套可以直接借用的视角: 前者讲怎么把评测组织成可读的矩阵, 后者讲提示迭代的反馈闭环, 都能套到”skill 改完怎么验证”上。

  五、跨工具迁移: 差异点在哪里, 怎么处理

  把内核标准化之后, 真正的工作量在处理各工具的表层差异。这里列出迁移时最常踩的几类差异和应对。

  5.1 frontmatter / 元数据格式差异

  不同工具对”这个 skill 叫什么、什么时候触发”的声明方式不一定相同。Claude Code 用 SKILL.md 顶部的 YAML frontmatter(name + description); 其他工具可能用别的文件名、别的字段、甚至别的格式。

  应对: 真相源用一套最表达力强的格式(推荐 Claude Code 的 frontmatter 约定), 迁移时用一个小转换脚本生成各工具要的形态。 不要反过来——不要为了迁就某个工具的弱格式, 把真相源也阉割了。

  5.2 触发机制差异: 自动检索 vs 显式调用

  这是最容易出问题的一类差异。有的工具像 Claude Code 那样靠 description 语义自动匹配触发 skill; 有的工具需要用户显式调用(比如打一个斜杠命令)。

  这两种机制对 description 的要求完全不同:
  – 自动匹配的工具, description 要写得像”检索关键词”, 把所有可能的触发说法都覆盖。
  – 显式调用的工具, description 更像”帮助文档”, 用户已经知道要调它了。

  应对: 把 description 写成自动匹配友好的版本(信息量大的那种总是兼容显式调用), 在迁移到显式调用工具时不需要改。反过来则会丢信息。

  5.3 脚本运行环境差异

  scripts/ 里的脚本依赖的解释器、环境变量、工作目录, 在不同工具下不一定一致。一个在 Claude Code 下 cwd 在项目根的脚本, 换个工具可能 cwd 在别处。

  应对三原则:
  – 脚本内部一律用绝对路径或相对脚本自身定位, 不假设 cwd。
  – 依赖通过环境变量注入, 不硬编码。尤其涉及密钥时, 走 bootstrap 读取, 绝不写死在脚本里。
  – 跨工具差异用一层适配 wrapper 吸收, 别让核心脚本里长出 if 工具==X 的分支。三个以上分支就是设计出问题的信号。

  跨模型/跨 SDK 调用时还有一类隐蔽差异是错误格式不统一, 同一个失败在不同链路下报得五花八门, AI_ProviderSpecificError 报错定位与修复: AI SDK 排错 是一个具体的踩坑样本, 迁移脚本前扫一眼能省时间。

  5.4 能力边界差异

  不是每个工具都给 skill 同等的权限。有的能跑任意 shell, 有的沙箱限制严格; 有的能联网, 有的不行。一个重度依赖 shell 的 skill 迁到受限工具里可能直接哑火。

  应对: 在 SKILL.md 里显式声明这个 skill 的依赖前提(需要 shell、需要网络、需要某个 CLI 已安装)。迁移时先核对目标工具是否满足, 不满足就降级或标记为不可用, 而不是让它在运行时静默失败。

  六、团队共享: 从个人资产到协作流程

  单人复用解决”我自己别重复劳动”; 团队共享要解决”全队用同一套规范, 且改动可控”。

  6.1 集中仓库 + PR 流程

  把 skill 仓库放团队可访问的 git 远端, 任何人改 skill 都走 branch + PR + review。这件事的价值在于: skill 是会直接影响 agent 行为的”准代码”, 一个人随手改了 commit skill 的规范, 全队的提交风格就变了。让它走 review, 和 review 代码同等对待。

  git checkout -b feat/blog-skill-seo-rules
  # 改 skills/blog-publish/references/seo-title-rules.md
  git add . && git commit -m "feat(blog-publish): 加入 SEO 标题硬规则"
  git push origin feat/blog-skill-seo-rules
  # 开 PR, 团队 review 触发效果与措辞后合并
  

  6.2 安全审查: skill 也是攻击面

  这一点必须单独强调。skill 里有 scripts/, 有命令, 有时还有凭据读取逻辑。一个被污染的 skill, 等于让 agent 在你机器上跑了一段你没仔细看的脚本。 团队共享放大了这个风险——一个人引入恶意或粗心的 skill, 影响全队。

  所以 skill 仓库的安全要求不能靠”感觉没问题”:
  – 脚本不硬编码密钥, 走 bootstrap / 环境变量。
  – review 时重点看 scripts/ 里有没有外发数据、有没有读敏感文件、有没有往临时目录写可执行文件。
  – 来源不明的第三方 skill, 先在隔离环境跑过再进主仓。

  “安全要的是证明而不是感觉”这个判断对 skill 同样成立, 安全不是氛围, 是证明 讲的虽然是 prompt 安全, 但”不能靠语义过滤器兜底, 要靠可验证的约束”这个内核, 直接适用于 skill 脚本审查。

  6.3 文档即接口: README + 触发词索引

  团队规模上来后, 别人不知道你这有哪些 skill、什么时候该用哪个。在仓库根维护一份索引, 列出每个 skill 的 name、description 摘要、依赖前提、维护人。这本质是把”文档即接口”落到实处: 一份能驱动别人正确调用 skill 的索引, 才算把这套资产建模完整了。

  6.4 复用的边界: 不是所有东西都该做成共享 skill

  最后一条反向提醒: 不要把什么都做成团队级 skill。高度个人化的工作习惯、一次性的探索脚本, 留在个人层就好。团队仓库里只放真正需要全队一致的东西(提交规范、发布流程、安全 checklist)。skill 太多太杂, 反而增加 description 之间的语义干扰, 让自动触发的工具选错。关于”什么该沉淀、什么该丢”, 选型层面的 AI Agent 框架全景: LangChain/LangGraph/n8n/Dify 等选型指南 给了一个可类比的取舍框架: 先定决策维度, 再决定收口到哪一层。

  七、相关阅读

  把这套方法论放进更大的 agent 工程图景里, 下面几篇可以接着读:

  • Claude Code vs Codex vs WorkBuddy vs Zcode: AI 编程 Agent 怎么选 —— 先把工具盘子定下来。
  • Agent Harness 不是要安装的软件包 —— harness 与 skill 的边界划分。
  • 构建 Agent 和写软件, 是两种工程 —— 为什么 skill 要把决策和确定性执行分开。
  • 把 Agent 送上生产: RAG、工程、安全、评测 —— skill 只是生产化拼图的一块。
  • 开源 AI Agent 调试器 HALO: 利用 RLM 技术实现本地化闭环优化 —— skill 改完后怎么观测闭环效果。
  • AI 信源指南: 收录 Karpathy、Sam Altman 等百余位顶级专家的 X 平台关注清单 —— 跟进 agent 工具演进的信息源。

  如果你是从零搭 agent 开发能力, 技术社区热议: AI Agent 开发的学习路径与资源盘点 适合作为更靠前的入门索引。

  八、FAQ

  Q1: skill 用 markdown 写, 不会因为太”软”而不可靠吗?

  可靠性不来自格式的”硬”, 来自结构和验证。把确定性逻辑沉到 scripts/(那部分是真代码, 可测), 把决策留给 SKILL.md(那部分本来就该是自然语言)。再配上 git 历史和 CHANGELOG, 你对每次改动的效果有迹可循。这比埋在 GUI 里、改了无从追溯的”硬配置”可靠得多。

  Q2: 我只用一个工具, 还有必要搞这套吗?

  值得做的是其中两件: git 版本化和标准化目录。这两件即使单工具、单人也立刻回本——你获得了回滚能力和清晰结构。软链/子模块/同步脚本那部分是多工具才需要的, 单工具可以先不碰, 等你哪天加第二个工具时再补, 成本也不高。

  Q3: openclaw、hermes 这类工具的 skill 格式和 Claude Code 不一样, 怎么共享?

  共享的是内核(提示 + 脚本目录), 不是表层格式。真相源用表达力最强的格式(推荐 Claude Code 的 frontmatter 约定)写一份, 各工具的具体格式用一层转换/适配脚本生成。具体差异在哪、怎么吸收, 见第五节”跨工具迁移”。核心是: 永远不要为了迁就某个工具的弱格式去阉割真相源。

  Q4: 软链、子模块、同步脚本, 到底用哪个?

  按场景: 单人单机多工具用软链(最轻); 跨项目引用、要钉版本用子模块(可锁 commit); 工具不认软链时用同步脚本(最通用)。三者可以混用, 唯一的铁律是——只有一份会被编辑的源, 其余都是只读投影。

  Q5: 团队里怎么防止有人引入有问题的 skill?

  把 skill 仓库当代码仓库管: 改动走 PR + review, 重点审 scripts/ 里的命令(有没有外发数据、读敏感文件、写可执行文件到临时目录), 密钥一律走 bootstrap 不硬编码, 第三方来源先隔离环境跑过再进主仓。详见第六节 6.2。

  九、结语

  agent 工具会一直增加, 这是确定趋势。如果你的 skill 跟着工具走, 每多一个工具就多一份要手动同步的副本, 维护成本是线性甚至超线性增长的。

  换个建模方式: 把 skill 当成独立于工具存在的工程资产——纯文本、可 diff、git 版本化、一份源多处投影。这样每多一个工具, 增加的只是一条软链或一段适配, 边际成本趋近于零。

  落地就三步, 今天就能起: 第一, 把散在各工具里的 skill 收进一个 git 仓库, 按标准目录结构摆好; 第二, 选软链或同步脚本, 让各工具指向这一份源; 第三, 给重要 skill 打上 tag、补上 CHANGELOG。从”四份会漂移的副本”到”一份可维护、可审计、可共享的真相源”, 差的不是工具, 是把它当资产来养的这套习惯。

  6小时前

• 大模型周刊 第 36 期：监管给前沿模型踩刹车，开源在 token 榜上接力

  作者：toy　|　覆盖周期：2026.06.20 – 2026.06.26

  这一周，OpenAI 有三件事砸在同一个窗口里：6 月 24 日和博通一起亮出第一颗自研芯片 Jalapeño，6 月 25 日被白宫要求把新模型 GPT-5.6 慢慢放、一个客户一个客户审批，6 月 26 日又传出可能把 IPO 推到 2027 年、只为守住万亿估值。一家公司一周里同时秀肌肉、被按头、和拖时间，挺少见。

  另一边，开源和中国队没闲着。DeepSeek 的 V4 Flash 把 OpenRouter 的 token 消耗榜冲到第一，Anthropic 则把”蒸馏”官司打到阿里巴巴头上。上周政府刚关停 Fable 5、智谱用 MIT 开源的 GLM-5.2 接住缺口，这周这条线继续往下走。

  我的判断是：前沿模型的瓶颈，正从”能不能做出来”转向”准不准放出来、放给谁”。监管第一次成了模型的产品参数，而这个参数，闭源大厂自己说了不算。

  一、OpenAI：芯片、刹车和延期，挤在同一周

  OpenAI 这周的三条新闻，方向完全相反，却指向同一件事。

  产品/动作清单：
  – 6 月 24 日，和博通联合发布首颗自研 AI 芯片 Jalapeño，专为推理优化，号称在自家模型帮助下 9 个月完成端到端设计，计划年底开始部署。
  – 6 月 25 日，白宫国家网络总监办公室和科技政策办公室出面，要求 GPT-5.6 只发给一小批伙伴，政府”逐个客户审批”放行。
  – 6 月 26 日，《纽约时报》报道 OpenAI 倾向把 IPO 推到 2027 年，CFO Sarah Friar 主推这个节奏，Altman 把”砍掉万亿估值换早上市”称作”想都别想”。

  先说芯片。自研一颗 AI 芯片通常要两三年，OpenAI 把周期压到 9 个月，靠的是让自家模型参与设计。听着很 OpenAI。但要泼盆冷水：Jalapeño 是推理芯片，不是训练芯片，短期内撼不动英伟达在训练侧的地盘。它解决的是”ChatGPT 跑起来太贵”，不是”我能不能训出下一代”。

  再说刹车。这是美国政府第一次在一个前沿模型公开发布之前就出手限制——以前管的是芯片和硬件，这次直接管模型本身。Altman 跟员工说这”不是我们想要的长期模式”。翻译过来：发布节奏第一次不归公司管了，政府点一个客户，你才能开通一个客户。

  市场/开发者反馈： 开发者圈对自研芯片乐见其成，少一层对英伟达的依赖就少一道卡脖子；但对”逐客户审批”普遍犯怵——一个产品发布要走政府审批流，等于把迭代速度交了出去。也有人翻旧账：Anthropic 上周刚被关停 Fable 5，这周轮到 OpenAI 被踩刹车，前沿玩家轮流挨管。

  我的判断： 三条新闻叠在一起看，OpenAI 正从”研究狂奔”切换成”基建玩家”——自己造芯片、守万亿估值、对政府服软。宁可等到 2027 也不肯把估值砍下来，说明它赌的是算力加企业的长线，而不是再靠一两个模型炸场。真正的变量是那只监管的手：当发布要审批、估值要看政策脸色，”快速迭代”这套叙事第一次不灵了。

  

  二、Anthropic：一边喊暂停，一边把蒸馏官司打到阿里

  Anthropic 这周没发新模型，但话题量不小。

  产品/动作清单：
  – 6 月 24 日，公开指控阿里巴巴”明目张胆、非法”地大规模套取 Claude 能力，把上半年那场”蒸馏”官司又往前推了一步。
  – 此前 2 月，它已点名 DeepSeek、Moonshot、MiniMax，称这三家用两万四千多个假账号、累计一千六百多万次对话来”蒸馏”Claude——其中 MiniMax 那轮最大，超过一千三百万次，集中在 agentic 编码上。
  – 月初（6 月 4 日）还通过 Anthropic Institute 发文，呼吁全球协调暂停前沿 AI，理由是模型快要能”自己造下一代”，递归自我改进会让人类失去控制。

  蒸馏是什么？简单说，就是拿强模型的输出当教材，喂给自己的弱模型，让它快速学会强模型的本事。行业里很常见，但几乎所有闭源厂商的条款都明令禁止——你买的是答案，不是拿去训练竞品的许可。Anthropic 给的数字够狠：两万四千个假账号不是”蹭用”，是工业化的批量套取。

  那”呼吁暂停”呢？这里有个不能忽略的时间点：这篇暂停倡议发出来，距离 Anthropic 自己秘密递交 IPO 没几天，公司估值已逼近万亿。一边说”大家慢点、危险”，一边自己冲刺上市——质疑者读出来的是”先把监管聚光灯打到前沿，自己接着跑”。

  市场/开发者反馈： 安全派给暂停倡议点赞，觉得递归自我改进的风险该认真谈；速度派则吐槽这是”用安全叙事做商业护城河”。Tom’s Hardware 干脆点破：呼吁暂停的潜台词，是”在失控之前得先囤够算力”。Anthropic 自己也承认，超过 80% 合入代码库的代码现在由 Claude 写，工程师季度产出是 2025 年前的约 8 倍——这既是它喊危险的证据，也是它自己在加速的证据。

  我的判断： “宪法 AI 加安全优先”在当下监管环境里确实更吃香，但这周这套组合拳暴露了一个矛盾：Anthropic 既是规则的呼吁者，又是规则的受益者。对全球开发者来说，更现实的影响是 Fable 5 还锁着，海外和中国用户用不上最强的 Claude——而每一道这样的墙，都是在给开源递刀子。

  

  三、Google：Gemini 3.5 进了默认位，但留不住人

  Google 这周的两条线，一条往上走，一条往下掉。

  产品/动作清单：
  – I/O 2026（5 月 19 日）之后，Gemini 3.5 Flash 已经是搜索 AI Mode 的全球默认模型，AI Mode 月活过了 10 亿，查询量每季度翻一倍多。
  – 3.5 Pro 在 I/O 上预览，进入内部测试，公开放出大约晚一个月。
  – 6 月 18 日，Gemini 联合负责人、Transformer 论文作者之一 Noam Shazeer 宣布离开 Google，加入 OpenAI。

  10 亿月活是什么概念？意味着 Google 已经把”搜索框”这个最赚钱的入口，整体换成了一个 agent 平台——能帮你订房间、临时搭个界面、在后台 24 小时跑信息代理。对做 SEO、靠搜索流量吃饭的人来说，这是地震：入口逻辑从”给你十条蓝链接”变成”我直接把答案做出来”。

  往下掉的是人。Shazeer 不是普通工程师，他是”Attention Is All You Need”的作者之一，2024 年 Google 花了约 27 亿美元、通过收购 Character.AI 把他请回来。不到两年，人又走了，去了 OpenAI。Altman 调侃说”想和他共事从 OpenAI 第一天就开始了，只是花了十年”。

  市场/开发者反馈： 开发者认可 Gemini 的 agent 工具链和多模态，但对搜索改默认这件事感情复杂——好用是好用，流量焦虑也是真的。Shazeer 走人则被普遍读成 Google DeepMind 的损失：27 亿请回来的核心架构师，说走就走。

  我的判断： Google 在”agent 操作系统”这层的布局其实最全——搜索、Workspace、Cloud 一条龙，10 亿月活是别人羡慕不来的分发优势。但执行偏保守，又留不住顶尖架构师。人才战打到现在，谁能留住写出范式的那几个人，谁就握住下一代的入场券——这一局，Google 输了一分。

  

  四、中国队：上周开源，这周接着抢地盘

  上周智谱用 MIT 开源的 GLM-5.2 接住了 Fable 5 留下的缺口，这周这条线没停。

  智谱（GLM-5.2 余波）： GLM-5.2 是 753B 参数的 MoE 模型，1M 上下文，6 月 13 日发布即 MIT 开源，还在华为昇腾上完成训练、Day 0 适配了一票国产算力。榜单上它在 Design Arena 的编码类目冲到全球第一（Elo 1360，险胜 Fable 5 的 1350），是第一个登顶这个人类盲测编码榜的开源模型；在 Code Arena 前端榜则是全球第二，仅次于 Fable 5。开源模型过去从没在编码人类盲测里压过闭源旗舰，这次破了。

  DeepSeek（本周真亮点）： V4 Flash 上周把 OpenRouter 的 token 消耗榜冲到第一，单周用量涨了 48%，DeepSeek 三款模型一周合计跑了将近 6 万亿 token。价格是它的核武器：V4 Flash 每百万 token 输入 0.09 美元、输出 0.18 美元，比 Claude、GPT 同档便宜一两个数量级。近 6 万亿 token 不是榜单刷分，是真实跑出来的用量——token 密集的场景（agent 长链、批处理、海量改写）现在几乎只剩它这一个理性选项。

  Moonshot： 6 月 8 日传出新一轮融资，寻求最高 20 亿美元、估值冲到 300 亿美元——这是它半年里第三轮，估值从去年底的 40 多亿美元翻了约 7 倍。Kimi K2.6 目前是 OpenRouter 上使用量第二的大模型。

  MiniMax： 1 月已在港股上市、首日翻倍（涨 109%），这周的消息是它在筹备国内（A 股）上市，给烧钱的模型研发再找一个钱袋子。

  市场/开发者反馈： 海外开发者用中国模型用得很活跃，理由朴素——又快又便宜还能自己部署。但”蒸馏”争议一直没断，Anthropic 这周又添了一把火。

  我的判断： 中国队这周是”开源、低价、融资”三件套同时发力，正好卡在海外限制的缝里。DeepSeek 的 token 榜首证明一件事：大规模落地拼的不是榜单第一名，是性价比——便宜两个数量级，用量自己就上来了。智谱拼的是”能自主可控地当主力用”，DeepSeek 拼的是”便宜到没有替代”，两条路都比”再炸一个 benchmark”更接地气。

  

  五、Agent 战场：Hermes 把 OpenClaw 拉下了第一

  模型之外，真正的战场在 agent 框架。

  产品/动作清单：
  – Hermes Agent（美国 Nous Research 出品）从 5 月 10 日起登上 OpenRouter 全球第一，目前每天跑 2240 亿 token，把 OpenClaw 的 1860 亿甩在身后，成了用量最大的开源 agent。
  – 两者路线分叉：Hermes 押”做—学—改”的自我改进环加三层记忆，OpenClaw 押更广的网关生态。OpenClaw 创始人 Peter Steinberger 2 月已加入 OpenAI，项目转给了独立开源基金会。

  这里要纠正一个常见误会：Hermes 不是中国队，Nous Research 是美国的开源团队；OpenClaw 也是社区项目，不是哪家国内大厂的壳。两者之争是”控制平面 vs 运行时”——谁来定义 agent 怎么被驱动、状态存在哪、出错怎么恢复。

  市场/开发者反馈： Hermes 的自学习环和多 agent 任务板受欢迎，社区夸它”能跨轮锁住目标、自己从幻觉里恢复”；OpenClaw 的生态更广、接入更多。争论集中在一个老问题：到底是控制平面值钱，还是运行时值钱。

  我的判断： agent 时代的核心从来不是单个模型，是编排（orchestration）。Hermes 和 OpenClaw 的分叉，是未来多 agent 体系的预演——记忆、技能、目标拼成的完整中枢，比”我接了哪个模型”重要得多。给企业的建议还是那句：按场景混用，别站队站死。模型可以随时换，编排层换起来才真疼。

  本周关键观察

  • 监管成了模型的产品参数。 GPT-5.6 被逐客户审批、Fable 5 还锁着——前沿模型第一次在”上线前”就被政府卡，发布节奏不再归公司管。
  • 闭源每立一道墙，开源就接一波量。 政府关停 Fable 5、限发 GPT-5.6 的同一时间窗里，GLM-5.2 登顶开源编码榜、DeepSeek V4 冲上 token 榜首。这不是巧合，是替代效应。
  • 性价比比榜单第一更能决定落地。 DeepSeek 不争 benchmark 头名，靠便宜两个数量级把一周近 6 万亿 token 的真实用量拿下。
  • 人才战决定下一代范式。 27 亿请回来的 Shazeer 两年后还是走了，核心架构师的流向比模型跑分更早预示风向。
  • 真正的护城河在编排层。 Hermes 超过 OpenClaw 说明：agent 时代谁定义运行时和记忆，谁就握住了换不掉的那一层。

  下周看点

  • GPT-5.6 的”逐客户审批”进展：会不会如 Altman 所说几周内扩大放开，还是继续卡着。
  • OpenAI IPO 时间表是否进一步明确（2027 还是提前），以及万亿估值能不能扛住政策变量。
  • Moonshot 那轮 300 亿美元估值的融资是否落地。
  • GLM-5.2 与各家 agent 生态（Hermes / OpenClaw 等）的实际接入案例。

  ---

  数据来源：CNBC、TechCrunch、Axios、CNN、《纽约时报》（经 Business Standard、Yahoo 转载）、Al Jazeera、Bloomberg、Fortune、Tom’s Hardware、VentureBeat、MarkTechPost、TechRadar、智谱 AI 开放文档、IT 之家，以及 OpenAI、Broadcom、Anthropic、Google 官方博客。

  6小时前