免费POC, 零成本试错
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


我要投稿

Skills底层实现原理与上下文工程

发布日期:2026-01-22 12:22:55 浏览次数: 1587
作者:AI技术立文

微信搜一搜,关注“AI技术立文”

推荐语

揭秘Agent工程师如何高效管理Skills,解决工具爆炸与Token消耗难题。

核心内容:
1. 元工具模式与渐进式披露技术优化上下文管理
2. 三级加载机制实现精准Token控制
3. 动态存储方案与实时更新策略

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
最近 Skills 这个概念很火,但对于 Agent 工程师来说,一个好的 Skills 机制,不只是能用,更要好管理、高效、一致。它需要解决一系列实际的工程问题:比如工具列表爆炸怎么办?LLM 上下文窗口有限怎么省 Token?Skills 怎么实时更新?Agent Loop过程中,到底怎么加载Skills的?
那么,在工程上,究竟如何实现Skills? 今天,我们就来聊聊一套成熟的 Skills 机制背后,那 10 个核心的底层设计

第一部分:架构基石与上下文优化

1. 元工具模式(Meta-Tool Pattern):从 100 个工具到 1 个

如果你有 100 个 Skills,难道就要给 LLM 喂 100 个工具定义吗?显然不行。

核心概念: 通过单一的 Skill 工具管理所有 Skills。

不是: 100 个 Skills = 100 个工具 

而是: 100 个 Skills = 1 个 Skill 工具(元工具)

这个“元工具”就像一个Skills 的总开关。LLM 只需要知道怎么调用这个总开关,然后告诉它想用哪个具体的 Skill(比如 pdf-analysis),以及传入什么参数。

优势: 避免工具列表爆炸,统一管理,实现动态加载。

2. 渐进式披露(Progressive Disclosure):三级加载机制

LLM 的上下文窗口是昂贵的资源,我们必须精打细算。一个 Skill 的定义可能包含几 KB 的说明文档和几十 KB 的脚本代码,如果全塞进去,Token 消耗会非常大。

解决方案是:按需、分级加载

级别
内容
大小
加载时机
用途
Level 1元数据 (Metadata)
:Skill 名称 + 简短描述
~100B/skill
系统启动时
让 LLM 知道“有哪些” Skills 可用
Level 2完整指令 (SKILL.md)
:完整的使用说明
~2-5KB/skill
LLM 调用 Skill 工具时
让 LLM 知道“如何使用”这个 Skill
Level 3资源文件 (Scripts)
:脚本、配置等文件
~10-100KB/skill
LLM 执行脚本时
实际执行 Skill 的代码逻辑

3. 脚本执行流程:代码不进上下文

这是渐进式披露的延伸,也是最关键的 Token 优化点:脚本代码不进入 LLM 上下文。

为什么?

  1. 脚本代码太长,浪费 Token。
  2. LLM 只需要知道“如何调用”,不需要知道“如何实现”。

完整流程: Skill 工具 → 加载 SKILL.md (Level 2) → 注入 LLM 上下文 → LLM 推理 → 调用 Bash 工具 → 加载脚本 (Level 3) 到 Sandbox → 执行脚本。


第二部分:基础设施与动态管理

4. 存储方案:Redis(推荐)

Skills 的元数据和文件内容需要一个存储系统。在追求实时性、高性能和分布式的 Agent 架构中,我们推荐使用 Redis

为什么选 Redis?

  • 极快的读写速度: 内存存储,确保 Level 1/2/3 的加载不会拖慢 Agent Loop。
  • 天然的分布式支持: 易于多 Agent 节点共享和扩展。
  • 简单直接: 无需复杂表结构,直接用 Hash 存储文件内容。
  • 内置 Pub/Sub: 完美支持 Skills 的实时更新机制。

数据结构示例:

# Skills 文件内容(Hash)skills:{skill_name}:{version}  ├─ SKILL.md: "..."  └─ scripts/extract.py: "..."
# 当前版本号(String)skills:{skill_name}:current_version → "4"

5. 更新机制:Redis Pub/Sub(推送模式)

我们放弃了传统的轮询(Polling)模式,采用 Redis Pub/Sub 的推送(Push)模式,实现 Skills 的实时更新。

更新流程: 开发者修改 Skills → 更新管理器写入 Redis → 发布消息到 Pub/Sub → 各节点收到消息,清除缓存。 

延迟: < 10ms,基本实现实时更新。

6. 加载时机:与 Agent Run Loop 的深度结合

Skills 的加载必须是按需的,并且与 Agent 的 Run Loop 紧密结合。

关键点:不要在每轮 Agent loop 中重新加载!一旦 Level 2/3 文件被加载,它们应该被缓存起来。

7. 版本锁定:保证对话一致性

核心原则: 一个对话使用一致的 Skills 版本。

对话开始 → 锁定版本(如 v4)→ Run Loop(始终用 v4)→ 对话结束

  • 当前对话: 即使中途 Skills 更新到 v5,当前对话仍使用 v4,保证行为可预测。
  • 新对话: 新开启的对话则会使用最新的 v5。

为什么? 保证一致性,行为可预测,易于调试。

8. 动态新增 Skills:Run Loop 中的即时扩展

一个成熟的 Agent 框架应该支持在 Run Loop 的任何时候加载新的 Skill。

  • T1: 加载 excel-analysis
  • T5: 加载 pdf-generation(动态新增)
  • T10: 加载 image-processing(再次新增)

特性: 完全动态,无需预知;按需加载,节省资源;自动去重,不重复加载。


第三部分:性能与工程实践

9. 批量加载:性能提升的秘密

当需要用到多个 Skills 时,批量加载比单个加载效率更高。


# 单个加载Skill(skill_name="pdf-processing")
# 批量加载(推荐)Skill(skill_names=["excel-analysis"                   "image-processing",                   "pdf-generation"])

在底层,批量加载可以利用 Redis 的 MGET 或 HMGET 等命令,实现并行加载,性能提升往往能达到 3 倍以上,极大地优化了用户体验。

10. 文件系统策略:挂载 vs 复制

Skills 的脚本文件最终要在 Sandbox 中执行。这里有一个关于文件系统策略的选择题:挂载(Mount)还是复制(Copy)

策略
适用环境
优势
劣势
挂载 (Mount)
Docker Sandbox(开发环境)
共享文件,实时修改,方便调试。
隔离性差,不适合生产环境。
复制 (Copy)
E2B Sandbox 或生产环境
隔离性强
,每个 Sandbox 拥有独立的 Skills 副本。
每次启动都需要复制,有微小延迟。

策略模式: 成熟的 Agent 平台会根据 Sandbox 的类型自动选择最合适的策略。在生产环境中,复制是主流选择,以确保每个 Agent 任务的隔离性安全性


总结

Skills 机制不是简单的“插件系统”,它是一套针对大模型特性优化的上下文工程

通过 Meta-Tool 架构 解决规模问题,通过 渐进式加载 解决成本问题,再通过 Redis + 版本锁定 解决工程稳定性问题。只有把这些底层细节打磨好,Agent 才能在复杂的业务场景中跑得稳、跑得快。

希望这 10 个底层设计细节,能为你构建自己的 Agent 平台提供一些实用的思路。

53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询