ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

从单 Agent 到跨 Agent 的 Skills 管理

从单 Agent 到跨 Agent 的 Skills 管理 Skill 是什么、怎么写这篇文章不准备展开介绍。这里聊的是另一件事当跨 agent 工作越来越常见工具转换间沉淀的 skill 怎么办。以我自己为例同时用 Claude Code、Codex 和 Cursor 三个 agent之前还有 Gemini CLI并在它们各自的 skill 目录里积累了几十个 skill 之后发生了什么以及我的应对之策。全文导航1为什么突然要管理 skill2快速回顾Skill vs Prompt vs MCP3单 Agent 下Skill 怎么写算好4跨 Agent 的 Skills 管理5未来可能的问题Skill Rot 与 Context Rot6Skill 是终极解决方案吗7回到开头8参考资料为什么突然要管理 skill不少其他作者说要管理 skill是为了防治上下文腐败。他们安装了太多的 skill以致于在决定召回用哪个 skill 时出现打架冲突、召回准确率下降以及影响正文内容表现的事。我这边装的不多没遇到过 skill 失灵的情况。更多遇到的是如标题所言的在多个工作工具来回切换时skill 咋整的问题。典型情况就是 skill 没有全局安装换了一个 agent 就看不到要重装一遍。比如我在 Claude Code 里装了一个 grill-me skill动手前让 AI 先把方案问透的技巧用着顺手切到 Codex 想用的时候发现它没挂在 Codex需要重装。这种情形本质上其实是Claude Code、Codex、Cursor 现在都支持 skill但各家支持不等于保持同步。每个 agent 有自己的 skill 目录、自己的 discovery 规则。你在一个地方改了 skill默认不会同步到其他 agent 下面。Skill 从效率工具变成了需要跨工具治理的资产是这篇文章要讨论的。快速回顾Skill vs Prompt vs MCP首先我们快速回顾下什么是 skill以及之前的相似概念Prompt、MCP。Skill 不是 prompt 模板的简单升级。核心区别在渐进式披露skill 是按需加载的agent 判断当前任务需要某个 skill 才会去读而 system prompt 是开局就全塞进 context不管用不用得上都占着窗口。当你有几十个 skill 的时候这个差异决定了 context 会否被无关信息稀释。总的来说Prompt 是一次性指令用完即弃MCP 管连接能够得到外部工具和数据Skill 管知识知道该怎么用、遵守什么规范。单 Agent 下Skill 怎么写算好虽然当下大家用 skill 都像安装软件一样看到有人推荐效果好就安装了。再不济也是让大模型直接生成基本不会有人头铁自己写。但了解设计规范能够帮我们识别优质 skill 和改进效果不佳的 skill也是 AI 时代不可或缺的能力。一个 skill 只做一件事。这点和写代码的单职责原则完全一样。举个例子我的 ref-options-strategies skill 只负责有哪些期权策略、构成是什么、盈亏怎么算而当前 IV 环境该买还是该卖、止盈止损怎么设是另一个 skillbook-options的事。两者在 description 里写清楚分工边界agent 自己就能分流。Description 要写得push一点。如果 description 太保守agent 在判断要不要加载这个 skill的时候会 under-trigger。我的 content-matrix skill 把选题“不知道写什么”“一鱼多吃”“内容复用”“还能写什么”延伸方向这些触发词全列进了 description让 agent 在用户说出相关意图时能主动命中。但 SKILL.md 正文要克制别什么都往里塞。从结果出发多写多调。没有一步到位的 skill。我的 content-matrix 从最初一坨规则收敛到现在的3x3 矩阵定位 延伸方向结构经历了好几轮迭代。ref-options-strategies 从一开始试图在一个文件里覆盖 58 个策略到后来拆成决策矩阵 references 卡片 盈亏计算脚本三层。写得好不好从结果看agent 能不能稳定触发、输出是否符合预期。效果不满意的时候回头把 Anthropic 和 Claude 的官方 skill 编写指南再多读读。上面这些也不是我自己想出来的也是看他们官方说明文档提倡然后应用发现哎效果确实不错。跨 Agent 的 Skills 管理问题定义Claude Code 的~/.claude/skills/、Codex 的~/.codex/skills/、Cursor 的~/.cursor/skills/三家都原生支持 skill 目录放进去就能识别。问题是怎么让改动同步下发、怎么避免挂载失败。回到开头那个场景我的问题不是 skill 失灵是重复安装。根因在于三家 agent 各有自己的路径并不倾向于做大统一中间仓库也不会去读别人的路径。若无额外配置默认情况下在 Claude Code 里更新的 skill 的 descriptionCodex 和 Cursor 里并不会生效。市面上三条路线为了搞清楚大家都怎么做的我还在 V 站发了帖子咨询其他大佬。调研下来目前社区里大致有三种做法路线 A符号链接路线 BGUI 管理器路线 C单一源 薄适配核心思路一个 repo 存 skill 源文件ln -s软链到各 agent 目录桌面应用全局/项目双层作用域批量操作不追求自动同步每个 agent 一层薄适配器改一次同步改源文件全 agent 立刻生效在 GUI 里操作工具自动分发源文件改完适配器按需手动更新优点轻量开发者友好零依赖非命令行用户友好可视化管理承认各 agent 差异不强求统一缺点没有 GUI没有版本管理界面引入额外工具依赖同步仍需人工介入适合谁重度终端用户偏好图形界面的用户对 agent 差异敏感的团队路线 C 认为不同 agent 的 discovery 规则本来就不一样试图完全自动同步反而危险。但对于个人用户来说我认为路线 A 的投入产出比最高。我自己的方案我目前用的是路线 A 为主路线 C 的理念做补充。路线 A 体现在共享层。我有两个 skill 源仓库git 管理一个是读书/管理类27 个 skill另一个是量化/金融类5 个 skill。这 32 个 skill 通过ln -s软链到~/.agents/skills/。这个目录是跨 agent 的共享约定Claude Code、Codex、Cursor 三家都会读取改一次源文件全 agent 生效。各家 agent 默认安装 skill 时走的是自己的路径~/.claude/、~/.codex/、~/.cursor/但只要你手动放到~/.agents/就不需要再给每家单独挂一份。路线 C 体现在专属层。不是所有 skill 都应该同步。Cursor 专攻写作场景content-matrix、review-zh-blog 等Codex 专攻量化回测quant-trading 等Claude Code 相对全能。这些 skill 只在对应 agent 下才有意义硬同步到其他 agent 反而增加 discovery 时的噪音。这就是路线 C 说的承认差异不强求统一。此外Cursor 的 Figma、Notion、Stripe 插件自带 skill由插件系统自动管理不额外手动介入。总量共享 32 个 各 agent 专属约 20 个 插件自带若干整体 60。一个容易混淆的点共享目录不等于版本管理。~/.agents/skills/解决的是分发让所有 agent 发现同一批 skill。但分发和版本管理是两码事。我的 book-skills 仓库是 git 管理的有提交历史可以做分支。skill 源仓库管有没有版本记录~/.agents/管谁能看到两者解决的不是同一层问题。实际遇到的问题目前这种方式还是没法规避换设备的场景比如切到服务器上本地的 symlink 全部失效。不过这个场景在我这边出现不多仅涉及模型和数据任务需要在服务器紧急 debug手动同步对应 skill 即可。另外skill 被调用多少次这种观测性指标目前只能通过少数第三方工具实现。若想要原生排除用得少的、过时的 skill目前还做不到。未来可能的问题Skill Rot 与 Context Rot单个 skill 写得好不等于多个 skill 一起用也好。有人把这也归类为context rot。有论点认为生产环境里 agent 往往同时加载 5-15 个 skill单独测试没问题的 skill 叠加起来会造成 context 被稀释、准确率下降。“臃肿的 skill 文件正在制造它要解决的问题”。我目前 60 个 skill 同时挂着ref-options-strategies、content-matrix、review-zh-blog、grill-me 这些职责完全不同的 skill 并存没遇到过互相打架或触发混乱的情况。为什么我猜有几个原因。一是我的 skill 各自职责足够单一description 的区分度够高期权策略和内容矩阵和博客审阅之间几乎不存在歧义agent 不会搞混。二是渐进式披露机制本身在起作用agent 不会把 60 个 skill 的内容全塞进 context只在判断需要时才加载。三是也许我还没碰到真正的边界毕竟我的 skill 数量在个人用户里算多的但离有人做到 345 个的规模还差得远。但这不代表 context rot 不是一个真问题。如果 skill 扩展了、写得臃肿、description 重叠度高、或者同一个 agent 下堆了太多模糊的指令完全有可能错误触发或者不触发。Skill 是终极解决方案吗目前来看大多数讨论的结论是skill MCP subagent 三不可缺这是正确的和稀泥。Skill 解决的是复用问题让你把反复要交代的知识固化下来agent 按需取用。我在上一篇 ( /posts/use-codex-goal-build-products/ )里提到的 grill-me skill 就是一个例子。但 skill 不解决多个能力叠加后的上下文治理问题。当你的 skill 规模从两位数增长到三位数谁先加载、谁的指令优先级更高、两个 skill 的 description 重叠时 agent 怎么选这些问题我现在还未看到成熟解决方案。往前看skill 生态可能会往类似 python 管理包的方向走版本管理、依赖声明、发布与安装分离。现在已经有人在做 skill 聚合平台也有人做 GUI 管理器使用量都不小了。目前对个人用户来说路线 Asymlink 中心仓库是投入最小的务实选择路线 C“单一源 薄适配器”的思路可以作为补充。回到开头开头说的那个场景换一个 agent 就要重装 skill用 symlink 到 agent 目录下基本解决了。32 个共享 skill 改一次源文件Claude Code 和通用 agent 目录同步生效。剩下的 agent 专属 skill接受它们分散在各自目录里不强求统一。如果你单纯想省事让各个工具把 skill 都统一安装到~/.agents/也行。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
返回列表