在我的系统里，本质上Skill 是一种自然语言接口的、并具有内置思考和智能能力的功能函数。

# Skill 函数的自我描述
Skill 函数对外提供自然语言的描述，这是做什么的，需要提供些什么输入。Skill可以动态的挂载给Agent（挂载了某个技能的Agent就有了这个能力，非常符合直觉，也非常灵活。 Agent可以共享一些基本的Skill，也可以完全不同）。同时Agent的system prompt会动态的被注入，告诉Agent有哪些skill存在（和function/tool的思想是类似的）。但是完全不需要操心JSON，因为我们希望Agent调用LLM的时候，不去花注意力（以及token)在JSON格式上，专注于解决要做的事情和问题。大模型的智能，会让他自然的在正确的时候选择用什么skill。这里有一些prompt engineering，但是并不需要特别具体和细节，只要告诉LLM，有哪些skill（他们带着自我描述），LLM会自己选择合适的skill。

Agent看到的是，我能做什么，不需要知道具体怎么做的。

# Skill 的调用过程

通常的Agent system要执行功能，需要让LLM 做function call or tool invoke。也就是让LLM思考，如果需要call，要根据tool定义，生成要call tool的JSON （本质目的是填好参数，让外面的python代码可以去实际的调用对应的函数/API。因为大语言如果只输出自然语言，是无法对应到python函数的，必须有一个自然语言意图到 API 映射。只有这一步是必须JSON格式的

在我的设计理念里，这个步骤应该拆成两个步骤，思考和执行。思考是LLM做的，它最大化的发挥他的智能，不去为了JSON格式（以及控制JSON格式的prompt）去消耗它的注意力和context window。执行由另一个小脑（便宜得多的LLM，甚至是免费的本地SLM）来做。它只做一件事情：把自然语言指令，填充到函数需要的参数里（生成JSON）。具体过程如下：

* （大脑）LLM 发出一个自然语言的动作指令，指向某个`skill`，其他参数（即这个动作的意图）都是以自然语言的形式给出的。——这对LLM非常自然
* （小脑）(也是LLM)，去理解这个动作指令，并map 到具体 `skill`, 并且把大脑的意图参数，转换成`skill`实际python 函数需要的参数。即把自然语言，翻译映射到 python 函数的参数上。在通常Agent系统里这就是function/tool call，需要LLM输出JSON格式文本。因为这个过程需要的智力不高，所以可以用比较便宜的LLM 来完成。这是唯一需要输出JSON的场景，其他绝大部分信息交互（包括Agent之间的交互），都是可以完全只用自然语言的。
*  (肌肉系统）Python程序体，得到要执行的skill和参数列表，调用具体的 skill 函数。
* 比一般设计的健壮性： 小脑和大脑都是有智能的。当小脑无法完成翻译工作（可能大脑输出有问题，参数不足，不具体等等），小脑会再去询问大脑：这个参数到底写什么，你这个什么意思，等等。大脑会根据上下文，给出合理的解释和补充。让小脑可以完成翻译。这个设计唯一缺点是（可能）更多的Token消耗。因为可能产生多轮对话。但是长期来看token会便宜的，而且质量和健壮性是第一位的。基本沟通下来，不会有搞不定的函数调用。比强制大脑输出JSON要好很多。一方面更健壮，不会有各种格式错误，第二，避免了大脑把注意力放在JSON格式上（虽然没有量化证据，但这很可能是对大脑发挥智能是更好的）
* 进一步兜底：参数正确的函数调用，仍然可能失败。这个失败同样由（小脑）向（大脑）反馈，即大脑可以得到一个动作失败的结果。基本上这就是大模型智能体的try and catch 的过程。

而且通过skill的外部描述(会成为prompt的一部份)，其实大脑一般是知道skill需要什么输入到，不太会需要多轮重复交互。python函数的定义是函数名+参数列表，自然语言函数其实是他的wrap，也有一个名字（以及描述他做什么），加上自然语言描述的所需要的输入。本质是同一种信息的不同表达。

# Skill 函数的内部
Skill 函数也是一个python函数。它内部可以完全没智能。例如`查看文件` skill。但也可以包装比较复杂的智能过程。例如`研究某个信息`,可能包装了从理解问题、到自动化话搜索、到理解页面、提取信息的过程。
