第一部分：被忽略的洞察

Claude Skills的发布，无疑是2025年AI Agent领域的一颗重磅炸弹。尽管Anthropic的有些主张颇受指责，但你可以永远相信这个团队在LLM以及Agent领域的思考和实践，在模型之外的引领是远超于OpenAI。Claude Skills则是他们在MCP之后推出的又一个新范式。

那么，什么是Claude Skills？ 简单来说，它是一种Agent能力扩展机制，通过将指令、脚本和资源组织成文件夹（即一个Skill目录），让Agent能够动态发现和加载这些专业知识，从而将通用Agent转化为特定任务的专家。每个Skill的核心是一个SKILL.md文件，其中包含YAML frontmatter定义的元数据（如名称、描述），Agent在启动时会预加载这些元数据作为第一层信息。当Agent判断某个Skill相关时，会按需加载完整的SKILL.md内容作为第二层信息。例如：

---
name: PDFdescription: Manipulate PDF documents, fill forms
---# 以下是PDF Skill的详细指令和使用说明（核心内容，约2000 tokens）
## 功能
- 填写PDF表单
- 提取PDF文本
...

对于更复杂的场景，Skill目录内还可以包含其他引用文件，作为第三层（或更多层）的详细信息，供Agent按需查阅。这种渐进式的信息披露是其高效的关键。

很多人都在讨论Claude Skills用自然语言定义复杂工作流的强大能力，惊叹于它将Markdown作为“技能SDK”的简洁优雅，以及巧妙利用文件系统和grep等CLI工具的返璞歸真。这些设计确实令人振奋，它们共同提升了Agent的构建效率和可扩展性。

然而，在这些显性优势之下，潜藏着一个更深刻、更普适，却被大多数人所忽略的核心设计哲学。我们认为，这才是 Claude Skills 真正为所有 Agent 开发者带来的、可以被广泛借鉴的关键突破。

这个核心思想就是——信息分层设计哲学。正是它，让 Claude Skills 在Token效率上实现了惊人的飞跃，不仅节省了高达95%的Token，更显著提升了Agent的决策质量和响应速度。

这个‘信息分层’的概念听上去颇有些学术，但它的核心思想，你几乎每天都在电子游戏中体验。从早期的《反恐精英（CS）》，到如今的《塞尔达传说》，几乎所有3D游戏都离不开这项核心技术。

第二部分：深入海拉鲁：游戏世界的设计智慧

《塞尔达传说》那广袤而无缝的世界之所以能在 Switch 几乎可以说是孱弱的硬件上流畅运行，其秘诀就藏在两大设计智慧之中：细节分层 (LOD) 与 按需加载。它们共同构成了我们所要探讨的核心——一种普适的“信息分层设计哲学”。

2.1 核心智慧一：细节分层 (LOD) - 远近皆宜的视觉魔法

LOD (Level of Detail)，即“细节层次”，是3D游戏渲染中的一项核心技术。它的基本思想是：一个物体离你越远，展示的细节就应该越少。

想象一下，你正从高处眺望并逐渐接近一个怪物营地：

• • 极远处：你首先注意到的，可能只是地平线上一个冒着烟的、模糊的岩石轮廓。游戏此时只为你渲染了一个低多边形模型（Low-Poly Model），它仅由少量几何面构成，只为勾勒出物体的基本轮廓，因此几乎不消耗计算资源，却提供了最关键的元信息：“那里有一个值得探索的地点”。

• • 这就像Agent启动时，只看到每个Skill的名称和一句话描述，知道“它在哪儿”。

• • 中距离：当你飞近一些，现在无需任何特殊工具，就能看清营地的木制哨塔、篝火、敌人的大致数量和类型，甚至能分辨出显眼的红色爆炸桶。这些核心信息足以让你制定一个完整的战术计划。

• • 这恰好对应Agent读取一个Skill的核心文档，足以支撑它制定出完整的行动计划。

• • 近距离：当你潜行到营地边缘，现在能看清每个敌人手中武器的具体样式、篝火上烤肉的纹理、以及它们盔甲上的划痕。游戏为你加载了最高精度的模型，以支持你最精准的操作。

• • 这便是Agent在需要精准执行时，按需查阅的、最详尽的原始信息。

LOD技术通过“在需要时才提供必要信息”，极大地节省了硬件资源，使得在有限的机能上呈现广阔无垠的世界成为可能。

2.2 核心智慧二：按需加载 - 无缝世界的基石

LOD决定了“加载什么精度”的信息，而按需加载（On-demand Loading）则解决了“在哪个时刻”加载这些信息的问题。

最好的例子，莫过于进入一座古代神庙：

• • 门外：当你站在神庙外，游戏为你渲染了精美的外部结构，但神庙内部复杂的谜题和机关，对系统来说是完全“不存在”的。引擎没有为这个你“可能不会进入”的地方浪费一丝一毫的内存。

• • 进入：在你与大门互动，确认“进入”的那一刻，游戏执行了一次“按需加载”。屏幕上出现短暂的过渡动画，在此期间，引擎将神庙内部全新的、完整的场景数据调入内存，同时“卸载”掉暂时看不见的外部世界数据。

• • 这个“进入”的动作，就如同Agent在决策后，发出指令去加载某个Skill的完整细节，实现了上下文的精准控制。

按需加载避免了一次性将整个世界（包括所有神庙的内部）都塞进内存，从而实现了高效的资源管理和无缝的场景切换。

2.3 关键洞察：从游戏优化到Agent设计

《塞尔达传说》的流畅体验，正是建立在这两大智慧之上：LOD负责管理信息的精度，按需加载负责管理信息的时机。

这种“在需要时才提供必要信息”的设计哲学，不仅是游戏优化的关键，也正是我们在构建高效AI Agent时所要遵循的核心原则。它告诉我们，一个优秀的Agent系统，不应该在启动时就背负所有知识的重量，而应该学会如何快速浏览摘要，按需加载细节，从而在广阔的“问题世界”中，实现轻盈而精准的探索。

第三部分：三层架构：从海拉鲁到AI Agent

游戏世界的直观体验，为我们揭示了一套强大的设计哲学。现在，让我们将其正式化，提炼出一个所有Agent开发者都能直接应用的经典模型——信息分层三层架构。这套架构由信息层级和访问工具共同组成，两者深度耦合，缺一不可。

LOD-0：摘要层（最抽象）

• • 目的：让Agent知道它存在。这是全局的索引，用于快速浏览和判断相关性。

• • 对应《塞尔达》：这就是远方神庙的发光轮廓，或怪物营地的一缕青烟。

• • 内容：最精简的元信息，如名称、一句话描述、核心特征。

• • 示例：

• • Skill: pdf.fillForm - 填写PDF表单字段

• • 数据: 2025_Q1_sales.xlsx - 一季度销售数据，10k行

• • 加载时机：总是在Agent启动时预加载，构建全局认知。

• • Token消耗：极低（每个约20-50 tokens）。

LOD-1：核心层（开箱即用）

• • 目的：让Agent可以直接开始工作。

• • 对应《塞尔达》：这就是神庙的完整外部结构，或怪物营地的哨塔与敌人布局。

• • 内容：足以完成80-90%常规任务的核心信息，如完整的函数签名、参数说明、使用示例、数据表的统计摘要和样本。

• • 示例：

• • Skill: 完整的SKILL.md，包含所有参数、返回值和常用示例。

• • 数据: 表结构 + 统计摘要（总额、均值、分布）+ 前5行样本。

• • 加载时机：当Agent根据LOD-0判断某个资源相关时，按需加载。

• • Token消耗：中等（约1-3k tokens）。

LOD-2：原始层 / 按需层（完整信息）

• • 目的：支持深挖细节和精确访问，处理剩余10-20%的复杂或特殊场景。

• • 对应《塞尔达》：这就是神庙内部的完整谜题，或敌人手中武器的精确纹理。

• • 内容：完整的、未经删减的原始信息。

• • 示例：

• • Skills: SKILL.md中引用的扩展文档（如forms.md, examples/）。

• • 数据: 完整的10,000行原始数据，通过SQL或脚本按需查询。

• • 加载时机：当Agent发现LOD-1的信息不足以解决问题时，按需加载或查询。

• • Token消耗：按需（可能为0，也可能数万tokens）。

三者关系：一个直观的对比

三层协作流程

这三层结构共同构成了一个高效的决策流程：

Agent收到任务
    ↓
1. 扫描所有资源的【LOD-0】，快速了解全局能力
    ↓
2. 识别出3-5个可能相关的资源
    ↓
3. 按需加载这些资源的【LOD-1】，制定核心计划
    ↓
4. 在LOD-1层面完成大部分任务（80-90%）
    ↓
5. 仅在需要时，通过工具从【LOD-2】按需获取精确数据（10-20%）

两层还是三层？一个重要的工程决策

三层架构如此强大，是否意味着所有信息都需要被分为三层？并非如此。实际上，绝大多数我们日常接触的信息体，都是天然的“两层系统”。

• • 两层系统：由 “元信息”（LOD-0）和“完整内容”（LOD-1） 构成。

• • LOD-0：文件名、文章标题、函数名。

• • LOD-1：文件内容、文章正文、函数实现。

• • 适用场景：适用于那些 “小到可以一次性读完” 的信息体，通常是小于5k Token的单个文件、短文档或代码片段。对于这些信息，Agent可以直接加载完整内容进行处理，无需一个额外的“核心摘要层”。

三层系统，是专门为解决“大到无法一次性读完”的复杂信息体而设计的。

• • 判断标准：当一个信息体（如大型数据表、代码仓库、API集合）大到必须通过过滤、查询或聚合才能有效使用时，三层架构就变得至关重要。它通过引入一个高质量的LOD-1“核心摘要层”，避免了Agent在面对海量原始数据时“溺水”。

理解这一点，可以帮助我们避免过度设计，在合适的场景选择合适的架构。

工具：连接层级的桥梁

值得注意的是，这套三层架构并非孤立存在，它的高效运作离不开与之深度耦合的工具系统。工具是Agent访问和利用不同信息层级的唯一途径。

• • LOD-0 -> LOD-1的工具：通常是简单的文件读取或元数据查询工具。例如，Agent通过cat SKILL.md的指令来加载核心文档。

• • LOD-1 -> LOD-2的工具：这是体现架构优势的关键，通常是具备过滤和查询能力的工具。例如，Agent通过SQL查询从数据库中精确获取所需数据，或通过grep从代码文件中定位特定函数实现。

核心原则：信息的组织方式，必须为查询工具服务。

这也解释了为什么Claude Skills的SKILL.md设计得如此巧妙：它不仅是一个Markdown文档，更是一个为grep等CLI工具优化过的、行协议式的信息结构。因此，在设计你自己的信息分层系统时，必须将信息如何组织与Agent如何访问作为一个整体来系统性地思考。

第四部分：实战案例：分析公司季度业绩

理论终须实践。让我们通过一个Agent在实际工作中面临的场景——分析公司季度业绩——来亲身体验信息分层架构的巨大威力。

想象一下，你的Agent被部署在一个大型企业的数据环境中。这里有销售数据、客户数据、产品库存、市场活动记录等等，信息量庞大且分散。

LOD-0：全局概览 - 知道它存在（约50 tokens）

Agent首先接触到的，是公司数据资产的极简目录。这就像图书馆的卡片索引，只提供最基础的“书名”和“主题”，让你知道有哪些书，但不会告诉你书里具体写了什么。

数据资产目录：
- sales_2025_Q1.xlsx: 2025年一季度销售数据
- customer_profiles.db: 客户画像数据库
- product_inventory.csv: 产品库存清单
- marketing_campaigns.json: 市场活动记录

Agent接到任务：“请分析公司一季度的销售业绩。”通过这个LOD-0概览，它能迅速判断出sales_2025_Q1.xlsx这个文件是最相关的。

LOD-1：核心信息 - 可以直接工作（约2,000 tokens）

Agent在LOD-0层面识别出sales_2025_Q1.xlsx后，并不会直接加载这个文件全部的原始数据（假设它有10,000行）。相反，它会按需加载一份预先生成的高质量摘要——LOD-1信息：

{
"file":"2025_Q1_sales.xlsx",
"size":"10,000行 × 15列",
"date_range":"2025-01-01 至 2025-03-31",
"summary":{
"总销售额":"¥5,234万",
"同比增长":"+15%",
"订单数":10000,
"平均订单额":"¥5,234"
},
"key_insights":{
"Top 5客户占比":"60%",
"最佳销售月":"3月（¥2,100万）"
},
"region_breakdown":{
"华东":"¥2,200万 (42%)",
"华南":"¥1,500万 (29%)",
"其他":"¥1,534万 (29%)"
},
"sample_orders":[
["2025-01-05","客户A","华东","¥12,500"],
["2025-01-05","客户B","华南","¥8,300"]
]
}

构建成本与价值：这份高质量的LOD-1摘要并非凭空而来。它需要我们预先编写分析脚本（用Pandas或SQL）来从原始数据中提炼。这就像游戏开发时，美术师需要投入精力去制作低多边形模型一样。这是一种典型的“计算换Token”策略：我们用一次性的、廉价的计算资源，换取了后续每一次Agent调用时昂贵的Token消耗和推理时间节省。

有了这份摘要，Agent可以轻松回答80-90%的常规问题，例如：“一季度业绩如何？”、“哪个区域表现最好？”。

LOD-2：原始层 / 按需层 - 深挖细节（按需查询）

现在，我们提出一个更深入的任务：“分析华东区高价值客户的复购行为”。

这个任务，LOD-1的摘要信息已经无法满足。此时，Agent需要深入LOD-2的原始数据。但它不会加载全部10,000行，而是通过工具进行按需查询：

SELECT customer, order_date, amount
FROM sales
WHERE region ='华东'AND amount >10000
ORDERBY customer, order_date;

这个查询可能只会返回几百行相关数据，而不是全部。Agent只在需要时，才精确地获取它完成任务所需的最少信息。

效果对比

正如数据所示，信息分层架构不仅极大地降低了成本，更重要的是，它通过提供结构化、高密度的信息，帮助Agent摆脱了“数据海洋”，能够更快速、更准确地进行分析和决策。

第五部分：挑战与权衡：海拉鲁并非一日建成

信息分层架构如此强大，是否意味着它是一颗“银弹”？答案是否定的。正如海拉鲁的宏大世界并非一日建成，这套架构的高效同样来自于对复杂性的精心管理和巨大的前期投入。在实践中，我们需要像游戏开发者一样，清醒地认识并权衡其“代价”。

1. “美术师”的汗水：高质量LOD-1的构建成本

游戏中最核心的低多边形模型（LOD-1），并非由高精度模型（LOD-2）自动、完美地生成。它需要专业的3D美术师投入大量时间和精力，手动进行“拓扑优化”，以最少的面数还原出模型的关键特征。

同样，我们的LOD-1摘要层也需要 “工程师”的汗水。无论是需要领域专家去精心撰写一份“开箱即用”的SKILL.md，还是需要数据工程师开发复杂的脚本来生成一份高质量的统计摘要，这都构成了高昂的初始构建成本。

2. “版本更新”的噩梦：信息同步的维护成本

游戏开发者最头疼的问题之一，就是在更新游戏内容后，忘记更新相关的低模版本，导致玩家在远处看到的是旧的山脉，飞近了才“突然”变成新的。

这就是信息分层的维护成本。如果LOD-2的原始信息发生了变化（例如，底层代码更新、数据库结构变更），而LOD-1和LOD-0没有及时同步，就会产生“信息漂移”。Agent拿着过时的“地图”（SKILL.md或数据摘要），去探索一个全新的世界，必然会导致错误和失败。这需要我们建立自动化的更新机制或严格的同步规范来应对。

3. “关卡设计师”的巧思：从“一本道”到“开放世界”的设计复杂度

设计一个线性的、一本道的游戏关卡相对简单，但设计一个像海拉鲁这样，既能让玩家自由探索，又能通过不同层次的引导给予方向的开放世界，其设计复杂度是指数级增长的。

信息分层架构本质上也是用更高的设计复杂度，来换取更低的运行时成本。 它要求设计者从一个系统性的、全局的视角出发，具备很强的抽象能力，来界定每一层信息的边界和内容，并系统性地思考信息组织与查询工具的深度耦合。对于简单、不常访问的信息，强行分层反而会得不偿失，导致“为了分层而分层”的过度设计。

因此，决定是否采用信息分层架构，需要我们像一个真正的游戏制作人那样去思考：评估信息的规模、变化频率和访问模式，权衡“开发成本”与“玩家体验”（Token效率），最终做出明智的决策。

第六部分：通用原则与扩展：超越Claude Skills

现在，我们已经深入剖析了信息分层架构的原理、实践与挑战。是时候将这些洞察提炼为更普适的通用原则，并思考它们在更广阔的Agent设计领域中的应用。

1. 用元信息替代完整信息（LOD分层）

这是信息分层架构的核心思想之一。它告诉我们，在Agent的决策初期，绝大多数情况下，Agent并不需要完整的、原始的信息。相反，一个精心设计的元信息（Metadata）或摘要信息，就能提供足够的上下文来做出初步判断和规划。

• • 数据分析：Agent无需加载整个数据库，只需查看表头、字段类型、统计摘要（均值、方差、分布）和少量样本数据，就能理解数据结构和内容。

• • API文档：Agent无需阅读所有API的详细实现，只需查看API列表、每个Endpoint的简要功能描述和核心参数，就能判断哪个API是当前任务所需的。

• • 代码仓库：Agent无需阅读所有代码文件，只需通过目录树、文件命名约定和关键文件的注释，就能快速定位到相关模块。

2. 按需加载而非预加载

第二个核心原则是关于信息的加载时机。它强调，只有当Agent明确需要某个特定信息来推进任务时，才去加载它。这避免了不必要的Token消耗和信息过载。

• • 数据：Agent不会一次性加载所有数据，而是通过SQL查询、数据过滤等工具，只获取与当前分析任务相关的子集。

• • 文档：Agent不会一次性加载所有文档，而是根据任务需求，精确地读取某个文档的特定章节或段落。

• • 代码：Agent不会一次性加载所有代码文件，而是通过代码搜索工具（如grep），按需定位到特定函数或类的实现细节。

深度挖掘：文件系统与Anthropic的巧思

这两个原则结合起来，最经典的体现就是文件系统，这也是Anthropic选择它作为Skills核心基础设施的重要原因。

文件系统本身就是一个天然的嵌套二层系统。一个文件名（LOD-0）和一个文件内容（LOD-1）构成了最基础的信息单元。一个好的文件名，如user_authentication_service.py，本身就是最好的LOD-0，它清晰地告诉Agent这个文件的核心职责。

然而，当面临大量技能（例如20个Skills）时，一个纯粹的二层系统会让Agent陷入“冷启动困境”：

• • 方案A（盲目）：Agent启动时只看到20个文件名（pdf.md, excel.md...），但文件名本身过于抽象，Agent无法知道每个技能的具体能力，难以做出有效决策。

• • 方案B（沉重）：Agent启动时加载所有20个SKILL.md的完整内容，但这会消耗巨量的启动Token（例如 20 * 2k = 40k tokens），而任务可能只需要其中一两个技能。

Anthropic的巧思在于，他们利用Markdown已有的YAML frontmatter特性，零成本地在文件系统的二层结构之上，构建了一个轻量级的LOD-0全局索引。

---
name: PDFdescription: Manipulate PDF documents, fill forms
---# [2000 tokens的详细LOD-1内容...]

通过在启动时只提取所有技能的name和description，Agent可以用极低的成本（20 * 20 = 400 tokens）构建一个完整的全局能力视图，完美地解决了信息发现（Discovery）的难题。这就像为一座只有书架的图书馆，配备了一套完整的“卡片目录系统”，让找书的效率发生了质的飞跃。

为什么有人说“就这”？—— 从直觉到洞见

当我们第一次看到Claude Skills的设计时，很多人的第一反应确实是：“这不就是Markdown文件和懒加载吗？有什么特别的？”这种直观的看法抓住了技术实现的一部分表象，非常合理。

但它的真正威力在于，Anthropic将这些看似简单的技术，系统化、范式化成了一套高效的信息架构哲学。就像乐高积木本身很简单，但用它来构建复杂的城堡就是一种系统工程。Skills的创新不在于发明了新的“积木”，而在于提供了一套优雅的“城堡图纸”，将这些基础组件以最高效的方式组织起来，从而在Agent领域实现了革命性的Token效率和决策质量提升。

分形思想：可递归嵌套的架构

最后，一个更深层次的洞察是，这套三层架构并非是扁平的，而是可以递归嵌套的，形成一种分形结构。

• • 向下看（展开）：一个LOD-2的原始信息体，其内部可能又是一个完整的三层系统。

• • 向上看（收起）：一个完整的三层系统，对更高层的观察者来说，可以被抽象成一个简单的LOD-0元素。

想象一下Agent在探索一个庞大的公司数据系统：

【公司级】
├─ LOD-0: "公司有销售、财务、库存三个数据库"
└─ LOD-2: 访问【销售数据库】
    │
    └─【数据库级】
       ├─ LOD-0: "销售库有订单表、客户表"
       └─ LOD-2: 访问【订单表】
           │
           └─【表级】
              ├─ LOD-0: "订单表 - 1000万行"
              ├─ LOD-1: 统计摘要 + Schema
              └─ LOD-2: 完整的1000万行数据

Agent就像一个在信息世界中不断“推门而入”的探索者，每一扇门（LOD-2）背后，都可能是一个全新的、同样遵循三层架构的“房间”。这种分形特性，使得这套看似简单的架构，能够优雅地扩展到管理任意复杂度的信息系统。

第七部分：总结与展望

核心总结

Claude Skills为我们揭示了构建高效AI Agent的两个核心智慧：

1. 1. 用元信息替代完整信息：像游戏渲染中的LOD，根据“距离”提供不同精度的信息。

2. 2. 按需加载而非预加载：像游戏中的场景切换，只在需要时才加载必要的信息。

这两个原则，源自游戏开发的智慧，却普适于所有信息密集型系统。遵循信息分层设计哲学，你将能构建出更高效、更经济、更智能的Agent。

下篇预告

本文从理论到实践，深入探讨了信息分层设计的道与术。但理论的价值最终体现在广泛的实践中。考虑到篇幅，我们无法将所有精彩的案例一一呈现。

因此，在下一篇文章中，我们将完全聚焦于实战，为你带来一套常见且强大的分层设计案例集，包括：

• • 面对从GB到TB不同规模的日志数据，如何权衡成本与查询速度，选择合适的工具（从grep到DuckDB），并设计一套从实时概览到深度回溯的分层查询策略？

• • 当Agent需要与外部API交互时，如何设计一套符合分层思想的RESTful接口（从集合端点到详情端点），在降低网络负载的同时，也让Agent的探索式调用更高效？

• • 如何为一个复杂的代码仓库提供超越文件列表的抽象层次？我们将展示如何利用领域驱动设计（DDD）和UML，为Agent构建从“业务上下文”到“类接口”的认知地图，使其在修改代码前，先理解架构。

敬请期待。