暗无天日

=============>DarkSun的个人博客

读:超越对话——用 Skills 和 Agents 工程化上下文

把 Claude 当聊天框用,问一句答一句,这是大多数人的用法。但 DZone 上 Ioan Tinca 的 这篇文章 给了一个不同的视角:Claude 不只是一个对话界面,它是一个可以嵌入系统的推理引擎。当你从"对话"切换到"上下文工程"的思维模式,Claude 就从被动助手变成了开发工作流里的活跃组件。

这个转变的起点,是一个简单约束,但大多数人没意识到它的分量。

Token 税:上下文是有限资源

Claude 按 token 运转。现代模型虽然支持超大上下文窗口,但这个空间终究是有限的。你塞进去的每条指令、每个文件、每条历史消息都在抢模型的注意力。原文把这叫做"token 税":上下文越多,模型要筛选的信息就越多,响应变慢、成本上升。更隐蔽的问题是,无关信息混进来会拉低输出质量。上下文不管理就会变噪声,噪声导致错误。

所以关键不是"给更多信息",而是"在正确的时间给正确的信息"。Skills 和 Subagents 就是干这个的。

Skills:用到时才注入

Skill 是把知识和能力模块化的机制。每个 Skill 有一个简短描述和一套详细指令。大多数时候,模型只看到描述。详细的指令在任务真正触发这个 Skill 时才注入上下文。

效果很直接:上下文保持精瘦,token 用量下降,行为也更可预测。你不再需要维护一个又长又脆的 prompt,取而代之的是一个可组合的能力库。

用我自己的例子。 url2blog 这个 Skill 平时只占一行描述:"从 URL 读取内容,生成经过实际执行验证的 Org-mode 博文"。只有当我真的贴了一个 URL 并输入 /url2blog 时,完整的流程指令(分层读取、内容评估、格式规范、人味儿去 AI 味、子代理审查、代码验证等十几个步骤)才会展开。 = 人味儿= skill 也一样:平时一行描述,调用时才把六类 AI 写作指纹的诊断标准注入上下文。

这些指令如果常年挂在系统 prompt 里,每次对话都要消耗几百行 token。但它们 99% 的时间用不上。Skills 的设计让它们只在用到时才出现。

原文把 Skills 分了两类。一类简单:格式化输出、约束代码风格、注入领域知识。另一类更像外部工具的接口,模型生成指令,独立的系统去执行。不管是哪类,核心思想一样:别扛着你暂时不需要的知识。

Subagents:用新上下文隔离问题

Skills 控制往上下文里放什么。Subagents 控制用几个上下文。

一个任务太大、太杂的时候,硬塞进一个会话会让上下文迅速膨胀。Subagent 的解法是另起炉灶:给它一个干净的上下文窗口,让它独立工作,不受主会话的干扰。完成后只返回精炼结果。

这跟软件工程的模块化原则一样。你不会把所有逻辑塞进一个函数。你会拆模块、设边界、让组件独立工作。Subagents 把这个原则搬到了 LLM 工作流里。

我的博客工作流里就有这个模式。博文草稿写完后,我会启动一个子代理做独立审查。它带着全新的上下文窗口读博文,检查格式、逻辑、代码、翻译腔。因为它没看过我写草稿时的纠结过程,不会被中间讨论带偏,能发现我陷在主上下文里看不到的问题。审完只返回一个修改清单,不把审查过程的所有中间推理塞回主会话。

更复杂的场景里,多个 Subagents 可以并行跑,把一个大问题拆成几个小问题同时解决。也可以给 Subagent 配外部存储,让它持久化结果或在上次运行的基础上继续。

原文强调了一点:这些行为不是模型自己长出来的,是你围绕模型构建的系统赋予它的。

组合:Skills 做契约,Agents 做执行

单独用 Skills 或 Subagents 都有用,但组合起来效果完全不同。

在这个模式里,Skill 不只是注入上下文,它还负责校验输入、约束结构、决定是否需要委托。如果一切就绪,它触发 Subagent 去干重活。Skill 是契约,定义任务怎么执行;Subagent 是执行者,在独立空间里完成工作。

这种分离解决了一个常见问题:LLM 天然倾向啰嗦和松散的结构。通过 Skill 收敛入口,你可以强制特定的输出格式、约束行为范围、阻止不必要的计算。同时把昂贵的操作(大上下文窗口、多步推理)限制在真正需要的时候才触发。

url2blog 为例。这个 Skill 定义了博文生成的完整契约:URL 安全验证、内容深度评估的五个测试、子代理审查、Org-mode 格式规范、危险模式检测等等。但具体执行时,像子代理审查这一步,Skill 只定义了审查标准和输出格式,实际的审查工作委托给一个独立的 Subagent 在干净上下文里完成。

从简单开始,逐步扩展

直接跳到复杂的 Agent 架构很有诱惑力,但原文的建议是克制。

大多数工作流的起点是一个 prompt。如果一条简单指令能稳定工作,就没必要加复杂度。当某些模式开始反复出现,比如你发现自己在重复类似的格式化要求、反复强调同样的约束,这就是引入 Skill 的时机。只有当任务大到上下文装不下、或者需要隔离执行时,才上 Subagents。

Prompt → Skill → Agent 这个递进路线,保持了系统的可理解和可维护。

这个建议很务实。我自己用 Claude Code 的过程就是这样演进的:一开始是简单的中文问答,后来发现每次写博文都要重复交代格式规范,就有了 url2blog skill。再后来发现草稿写完自己审不出问题,就加了子代理审查步骤。每一步都是被实际痛点推着走的,没有预先规划好的架构。

从使用者到设计者

把这些拼在一起,心智模型就变了。你不再是在"跟 Claude 聊天",而是在设计上下文怎么在系统中流动。你决定模型看到什么、什么时候看到、工作怎么分工。

这就是"用 LLM"和"工程化 LLM"的区别。

claude-code : skills : subagents : llm : context-engineering