昨晚心血来潮，阅读了一下 skills 的更多细节内容，发现 Anthropic 给出的 skills 存在这些问题：

• 只能传入文本，无法动态的决定传入的 tools 工具
• skill 在被 ai 调用后，其内容部分会持久的记录在上下文里
• mcp 和 skills 是割裂的两个系统，Anthropic 没有给出直接的转换或者兼容工具
• skills 工具本身没有强制判断参数是否可用

追其根本，是因为 Anthropic 在 claude code 实现 skills 时是下面这样实现的

• 首先定义了一个 skills 工具，然后你定义的 skills 描述会作为 skills 外层的工具整体描述传入进去
• 没有给 skills 工具的获取 skill 内容参数传入定义的 skills 的名称作为 enum 可选项，这导致 ai 输出 skills 工具时，可能会传入不存在的参数
• skills 文件结构里，虽然定义了一个 allowed_tools 参数，但是 Anthropic 在实现时有点问题，他这里指的是该 skills 可以用的工具，但是是在现有的 tools 基础上的，而且只是作为一个提示词提示 ai，类似于：你可以使用 xxx 工具。而不是说会动态的根据该 skills 注册新工具
• ai 要阅读某个 skills 时，会调用 skills 工具，然后 cc 会把这个 skills 内容作为工具结果发给 ai，然后后续即便该任务完成了，这个 skills 的内容也不会从上下文里删除。这会导致：如果 ai 使用了多个 skills，会导致这些 skills 的内容同时影响着 ai，即便你不需要某个 skills。而一个 skills 往往又有几百行内容，很吃 ai 的注意力和上下文

那么我们该怎么优化上述系统呢，其实只需要使用动态系统提示词 + 动态 tools 列表即可
具体工作机制如下：

• 首先在系统提示词里专门划开两个部分，其中一个是各种 skills 的描述，另一个是某某 skills 的内容部分，这两个实际上可以合并到一个里面，或者分开也行。描述总是会加到系统提示词里，内容会根据 ai 需要动态加载
• 各种 skills 的描述放在系统提示词里，而不再放在 skills 工具定义描述里
• ai 使用 skills 工具获取描述时，历史上下文里只会记录：你调用了 xxx skills。然后应用此时会把该 skills 的内容加到系统提示词里的内容部分
• 后续对话就会是 ai 已经掌握了该 skills 的内容前提下进行，如果 ai 需要，可以继续阅读更多的 skills
• 当 ai 认为某个任务结束后，可以主动调用 skills 工具，关闭该 skills，这样一个 skills 的完整生命周期就完成了
• 用户当然可以主动手动关闭或者添加某个 skills，因为 skills 是直接写入系统提示词里的，会很方便配置

mcp 工具在 skills 的前提下，也会变成动态的，而不再是固定：

• 如果某个 skills 绑定了 mcp 工具（同样通过 allowed_tools），那么该工具不会被直接添加到调用 api 时的 tools 参数里
• 当 ai 决定读取某个 skills，而该 skills 又定义了某些 tools，应用应该先检查是否已经注册了这些工具，会在 tools 参数里加上没有启用的 mcp 工具，采取合并的策略，动态的维护一个 tools 列表
• 当 ai 决定不再需要某个 skills 时，也会动态的根据配置项来关闭这些工具，不再添加到 tools 列表里发给 ai，具体是这样的：如果该工具不再固定工具里，且不在任何一个启用的 skills 里，那么就注销，采用一种最最小的减法
• 用户当然依旧可以自己维护一个固定的工具列表，以便让 ai 总能使用到某些工具，比如常用的 bash，read 等工具

感觉上面这些方式才会是我想象的 skills 升级版 + mcp 的结合方式
目前 skills 更像是给一堆文档添加了一个文字摘要库，ai 需要时就阅读文档，而不是说根据需求动态的维护自身 skills

话说这种方式应该很早就有人想到了才对，也没见有火起来，反而是更次一级的 skills 火了。。。

后续我会给我自己的插件加上上面的功能试试水
话说目前有什么 ide 或者插件已经实现了这些功能的吗？