ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 15px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: inherit;color: rgb(146, 97, 126);">TL;DRingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 15px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">在最近研究Claude Skills的过程中，它的运作机制对我的触动很大，而它的主要设计思路，是对上下文管理(Context Engineering)的精心打磨。结合自己在以前一些文章的积累，对ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: inherit;color: rgb(146, 97, 126);">上下文这个概念有了一些更深的认识。ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 15px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">在本文中，简单梳理了一下Claude Skills的运作机制和Claude全家桶全面的上下文管理思路。这部分有点技术化，但是思考的方式非常有意思，感兴趣的朋友可以看看。ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 15px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">最后一段是想借上下文这个主题分享自己的一些想法，希望能带来一些启发和帮助。对技术不感兴趣的朋友可以直接去看最后一段！ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 15px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">让我们开始吧！
ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 15px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">刚接触AI的时候，最常听到的就是：Gabage in, gabage out。ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 15px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">那时的热点还是提示(Prompt)。于是有各种技巧写Prompt，可以让AI生成更好的回答。ingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 15px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">在写Prompt的时候，需要按结构写Role、Background、Skills、Workflow、Initialization等等，因为这样写可以限定Prompt的范围，提供必要的背景信息。在做API接口开发的时候，则会按各个LLM的要求，在多轮对话时要汇总所有的前面对话的信息，按User、Assistant排列好，这样LLM就能有一定的记忆，做更好的回答。 那时，知道它们都叫上下文，但是并没有现在这样深刻的认知！ 最近把Claude相关的文档大致看了一遍，包括Claude Developer Guide、Claude Code Guide、Claude Engineering Articles等，愿意是想深入了解一下Claude Code相关的能力，如Sub Agents、Slash Command(/斜杠命令)，还有最新发布的Claude Skills等。 特别是，Claude Skills，对于它管理知识的方式，对我而言，有种豁然开朗的感觉。 Claude Skills的运作机制原来在做系统开发时，对于复杂的系统，会通过拆分成子系统来降低单模块的复杂度，而Claude Skills所使用的方法是相同的思路。 它采用渐进式展开（progressive disclosure）的方式，将复杂的功能，逐步拆解，按需加载，从而尽可能降低Token数量，增加上下文信息的有效性。 下图是Claude Skills的架构图： 它采用目录的方式管理Skills: pdf-skill/
├── SKILL.md (主指令文件)
├── forms.md (表单填写指南)
├── reference.md (详细的API参考)
└── scripts/
└── fill_form.py (实用工具脚本)
第一级：元数据(Metadata，始终加载)每个Skills都有一个SKILL.md文件，在它的头部，使用frontmatter 提供了用于发现（discovery）的信息： ---
name DF处理
description:从PDF文件中提取文本和表格、填写表单、合并文档。当处理PDF文件或当用户提到PDF、表单或文档提取时使用此技能。
---
这里面会最重要的就是上面的两个元素：name和description。 Claude 在启动时加载这些元数据，并将其包含在系统提示(System Instructions)中。这种轻量级的方法意味着你可以安装许多技能而不会产生上下文成本；Claude 仅仅知道每个技能的存在以及何时使用它。
第二级：指令（Instructions，触发时加载）在SKILL.md的正文中包含了各种程序性知识：工作流程、最佳实践和操作指南等： # PDF 处理
## 快速入门
使用`pdfplumber`从PDF中提取文本：
``\`python
import pdfplumber
with pdfplumber.open("document.pdf") as pdf:
text = pdf.pages.extract_text()
``\`
关于高级表单填写，请参见 FORMS.md。
只有当Claude识别到用户需要使用当前的Skill时，才会真正加载SKILL.md的正文部分，而只有在这里，这部分内容才会进入上下文窗口。 第三级：资源与代码（Resources，按需加载）对于理复杂的功能，如果全部写在SKILL.md中，会使SKILL.md的内容非常长，而很多功能并不会在当次讲求中就使用到，这时，可以将不同的功能分别放在不同的文件或脚本中，如上面文件结构图中的forms.md,reference.md以及scripts/fill_form.py等文件。  这包含以下三种类别的信息：- •指令：额外的 Markdown 文件（
forms.md,reference.md），包含专门的指南和工作流程。 - •代码：可执行脚本（
fill_form.py,validate.py），Claude 通过 bash 来运行它们；这些脚本提供确定性的操作，而不会消耗上下文。 - •资源：参考材料，如数据库结构（schema）、API 文档、模板或示例。
通过渐进式展开（progressive disclosure）的方式，这些内容只有在必要时才会添加到上下文中。 Claude全家桶的上下文管理Claude全家桶指的是： - 1. Claude.ai。即官方的网站，由于众所周知的原因，访问这个网站会有非常多的麻烦，先按下不表。
- 2. Claude API。即官方API，基于相同的原因，要直接访问也会有相同的麻烦，虽然可能通过一些代理进行访问，但是很多Claude的特色功能就没有办法支持了。
- 3. Claude APP。由于账号的原因，我没有使用过，但是它是Claude体系的重要成员。
- 4. Claude Code。作为Coding Agent，借助国内的LLM，如GLM、Kimi等，基本可以使用它的完整功能。
- 5. Claude Agent SDK。这个是将Claude Code内核的支撑部分单独发布出来，可以供用户自己开发自己的Agent。
在所有的这些工具中，都使用了差不多相同的上下文机制。为了避开那些不必要的麻烦，我想从Claude Code和Claude Agent SDK这两个工具作为分析的主体，主要是Claude Code。 先回顾一下，上下文的类型大致分为： - • 系统提示(System Instruction)
- • 其他Skills的元数据(Skills meta data)
所有这些东西都是要放在与LLM通信的API接口中的Messages属性，参见《一文读懂上下文工程(ContextEngineering)》。 在Claude code中，有这样几种与上下文相关连的元素： - 1.CLAUDE.md。项目的基础设定，基本上每次调用都会放在上下文中。
- 2.
/命令（即扩展的Command)。严格上来说，它并不是一种上下文技术，只是可以把各种工作整理成方便的命令，以便快速执行。 - 3.各种工具（包括本地的工具，或以MCP封装的工具）。工具的返回信息，也会放在上下文窗口中。而如何有效设计工具可以参见《Anthropic:为智能体编写高效工具—与智能体协作》一文（链接见评论）。
- 4.Sub Agent。这是一种
上下文分离的方法，对于完成特定工作的Sub Agent，只要了解它自己需要的上下文信息即可，而它的输出经过整理，也可以更高效地提供给调试的主Agent。 - 5. 下来就是新推出的这个
Skills了。它将一些功能（可能是Instruction，也可能是一些在本地执行的代码），按需求添加到上下文窗口中（即前面的渐进式展开progressive disclosure方式）
下图是，Claude对几种方式的评估：  随着Claude Skills的引入，为Claude体系的上下文提供了更好的管理方式。根据上面这张图，可以看到它的做法有很强的借鉴价值。所有一切都是上下文在这个研究过程中，越来越发现，LLM就在那里，能不能让它发挥更大的作用，就在于你给它准备了什么内容(上下文)。 而Claude的所有工作，都在说明一个问题：上下文是需要精心维护的，也是值得精心维护的。 反思自己的经历，其实有何尝不是这样！ 对于个人来讲，学习过程、工作经验、生活经验的积累，其实就是自己的上下文管理。 比如，一个产品经理，原来的技能可能主要是挖掘产品需求，写产品文档，画产品原型等等，但是现在要想利用AI Coding工具做一些产品实现，虽然这些工具已经很强大了，但是如果你的上下文中没有相关的知识，可能只能任由大模型帮你选择。而适当扩展一下自己的边界，就可能找到更适合的方法，用更高效的方式达到更好的效果。 以我自己的情况，我写了好多篇建筑与AI的结合，核心还是我自己有一些建筑行业的从业经历，也非常了解在我经历的那些场景下存在怎样的痛苦。 对于企业来说，业务领域的知识、经验，其实就是企业的上下文管理。 我有两个朋友，可以说是两个极端： 第一个，在行业有深厚的积累（上下文非常丰富），但是没有基于自身的情况，去打理好自己的上下文，一味去探索未知的领域，勇气确实可佳，但是结果也非常可叹！最主要的问题，是觉得在本行业积累的经验和知识，到其他行业也能适用，但是忽略了自己的"上下文"是经过那么多年打拼来的，到了一个新的领域，哪有那么简单。 第二个，除了关系没有太多的行业和技术积累（上下文比较少），结果沉不能沉下去，越来越没有心境去打造自己的上下文；而关系拿下后，又需要靠自己的能力(上下文)去兑换，结果没有办法兑现或只能以很低的价值兑现，一直处于在低水平不断重复的状态。这种情况的本质是没有用心去打造自己的"上下文"，形成有效的积累。 说是感悟，其实道理非常简单。 对于个人也好，对于企业也好，自己真正掌握的东西，是所有发展前面的那个1，而利用任何手段（包括AI工具），不断扩展、挖掘、实践、总结、提炼等等等等，只有有意识地精心维护，才能在那个1后面不断添加更多的0。这也就是成长的过程。 在AI时代（起码是现在的LLM为主导的情况），还是那点，没有输入就没有输出，Gabage In，Gabage Out。
|
