写在前面

事情是这样的。我手头攒了 57 个 Skill 文件，就是那种告诉 AI“遇到什么情况该怎么做”的 Markdown 说明书。有人拿来写公众号，有人拿来做图，我拿来模拟特定角色的思维方式。

这 57 个文件是我的资产，没错吧？

换到 DeepSeek 的 Agent 工具上，我本打算咬着牙做一轮适配。结果你猜怎么着？零配置，它直接给我端走了。一个不少，一行不改。

爽是真爽。但当我看到 6,242 个 Token 的开机费时，眉头一皱。

这钱，烧得值不值？咱们今天掰扯清楚。

DeepSeek Skills 自动扫描路径详解：6 个位置的加载顺序

DeepSeek 的做法相当粗暴，却也极其有效。装上之后，什么都不用配置，它会自动、按顺序扫描以下 6 个位置：

1. 项目级目录：./agents/skills
2. 项目级隐藏目录：./.agents/skills
3. 用户级配置目录：~/.dsh/skills
4. 自定义路径：在配置文件中另行指定
5. 公共抽屉：~/.agents/skills
6. 随包自带的 Skill

这里的第 5 个位置，~/.agents/skills，是重头戏。

它是几家主流 Agent 产品约定俗成的一个“公共抽屉”。我那 57 个 Skill 就放在那儿。DeepSeek 的扫描器扫到它，直接全量读取，原样塞进自己的上下文窗口。

换句人话说：你的 Skill 是行业标准，我认。你不需要为我做任何适配。

这种霸气的潜台词，对开发者来说，体验拉满。但代价，我们马上聊。

6,242 Token 开机费踩坑：渐近式披露为什么是必选项

这里有个巨坑，听我一句劝。

那 57 个 Skill 的目录清单，一旦被全量塞进上下文，就是 6,242 个 Token 的开机费。

这意味什么？意味着每次新开一个会话，6,242 Token 先烧掉。每次 Agent 内部派生一个子代理去执行任务，这 6,242 Token 再烧一次。哪怕你这次的任务跟那 57 个 Skill 半毛钱关系没有，钱，照付。

DeepSeek 的工程师显然不是傻子。他们用了一个非常聪明的设计来对冲这个成本：渐进式披露。

模型平时在上下文里看到的 Skill 目录，只有两样东西：

• 名字
• 描述（还被截断，默认上限 500 字符）

正文、路径、来源这些详细信息，统统不给。模型必须得主动、明确地调用一次，才能拿到某个 Skill 的完整正文。

翻译成人话就是：先给模型看菜单，它点了菜再上菜，而不是把整个厨房、冰箱、冷库全搬到它面前。

这个设计直接砍掉了一大半的开机成本。菜单很便宜，正文很贵。绝大多数对话，用户根本用不到 Skill 正文，模型只看菜单就够用了。

我自己的 GEO Agent 也独立想到了这个思路，只是没他们做得这么极致。我的 Skill 描述是从 SKILL.md 第一段提取的，一般不超过一百字。模型要详细内容，得调 read_skill_file 工具。

效果差不多。但我的动机更多是为了安全和可控，他们的动机更多是为了省钱。同一个设计，两种理由。

自研 GEO Agent 封闭式 Skill 架构设计原理

我的 GEO Agent 走了另一个极端。它的 Skill 系统是自己打造的，目录结构、说明书格式、脚本白名单，全是自定标准。

你放一堆 Claude Code 的 Skill 在我门口，我一个都不认。想用我的 Agent，就得按我的规矩来写 Skill。

听起来很霸道，对吧？但我有我的理由。

这是我们的 Skill 目录结构：

skills/
  geo-seo/
    _meta.json          # 元信息（名称、描述、图标）
    SKILL.md            # 给 AI 看的说明书
    geo-audit.md        # 参考文件：审计指南
    geo-citability.md   # 参考文件：可引用性指南
    scripts/            # 可执行脚本（.mjs/.sh/.py）
  excel-xlsx/
    _meta.json
    SKILL.md
  image/
    _meta.json
    accessibility.md
    branding.md
    ...

加载器的核心逻辑如下：

1. 扫描 SKILL_DIRS 环境变量指定的目录
2. 在每个子目录里寻找 SKILL.md
3. 解析其 Frontmatter，提取 name、description 等元信息
4. 扫描 scripts/ 目录，进行白名单过滤（仅允许 .mjs、.js、.sh、.py）
5. 收集参考文件列表（.md 文件，不含 SKILL.md 本身）
6. 将所有信息注册到内存缓存

这套设计背后的核心考量有三点：

第一，Skill 不只是说明书，还带可执行脚本。
AI 在运行时会真的去执行它们。这种情况下，格式必须严格可控。随便什么外来的文件都放进来跑，这跟开“后门”没区别。

第二，Skill 是严格分层的。
说明书（SKILL.md）里只有一段概述。详细内容全在单独的参考文件里。模型平时只看到名字和一句话描述，需要时主动调 read_skill_file 工具。上下文里永远只浮着一层薄薄的目录。

第三，这是给企业客户用的产品。
Skill 的来源必须可信。宁可让用户多配一步，也不能图省事，搞一个“自动读取未知文件”的机制。企业环境里，安全性和可控性压倒一切。

总结：两种工程哲学的终极抉择

说白了就是，你是在做一个给极客玩的玩具，还是在做一个给企业用的生产力工具？这个问题的答案，直接决定了你该选哪种哲学。

DeepSeek 的做法，是典型的“开源式插拔”。它通过兼容已有标准，想借别人的生态快速滚动起来。对个人开发者和爱好者极度友好，体验丝滑。

我的做法，是典型的“企业级产品”。自己定标准，把自己的生态控制权牢牢握在手里。对开发者来说，有一点迁移成本，但换来了可控性和安全性。

没有谁对谁错，只有场景是否匹配。

唯一能确定的是：Skill 正在变成 Agent 时代的“插件标准”。谁的标准被更多人接受，谁的生态就会像雪球一样越滚越大。这场仗，才刚开始。

---

本文作者来自 Adgine 团队，提供 GEO 服务（让品牌被 AI 推荐）