关于agent的skill，一大堆的粗浅科普讲来讲去越讲越绕。。。我的理解是这样：

茹初见

关于agent的skill，一大堆的粗浅科普讲来讲去越讲越绕。。。我的理解是这样：

1、它只需要一个运行命令行的tool，接收的参数是命令行（不严谨，第6条再详解），和一个load skill详情的tool，接受skill的名称作为参数。

2、skill文件是一个标准化的md文档，由“简介”和“详情”两部分组成，简介会组成prompt的一部分，告诉agent有这些skill可用，当agent收到用户请求时，会判断要调用哪个skill。

3、调用skill分两步，第一步是load skill的详情，所谓skill的详情，其实也是一个prompt，详细说明了什么情况下使用什么命令行。于是agent就知道遇到这个skill领域的问题时，该生成什么命令行参数去调用命令行tool了。

4、通过将skill分成“简介”和“详情”两部分，达到了“两步懒加载prompt”的目的，从而控制住了context的大小。

5、skill不只是冲击了mcp，同样也冲击了multi-agent架构，一个subagent完全可以由一个skill平替，架构更扁平更可控。

6、skill只是文档，它并没有执行代码的能力，执行仍然依赖tool，问题来了：自研的skill是可以自己定义tool，和skill里描述的执行部分对应上。但三方的skill怎么办？它没办法帮我的LLM bind上tool，对吧？所以我们需要1中提到的那个万能tool - 运行命令行的tool，它就是个万能适配器。但这只能是临时解决方案，因为动态生成命令行并命行，实在太危险了，比SQL注入危险100倍。为了解决这个问题，未来我们需要一套agent通用tool的标准，这个标准不像function call和prompt cache那样，发生在LLM层，因为它要调agent宿主环境去执行具体指令，看起来最好是在操作系统层，也就是linux、windows、mac os这一层，bash powershell什么的，出个针对skill的沙箱。或者，在agent框架层，在runtime层面出套通用tools，把安全检测给做了。skill发展这么快，这个通用tools应该很快会出标准。