Agent中skill和工具的关是什么

回复 Erfan： 简单说，工具（Tool）是 Agent 的「手脚」（原子执行能力），而 Skill 是教 Agent 怎么干活的「标准作业指导书（SOP）+ 专用脚本包」（上层业务能力封装）。 它们在 Agent 架构里是上下游和组合的关系，具体可以从四个维度来看： 1. 职责分工不同：Tool 解决「能不能做」，Skill 解决「怎么做好」 工具（包括 MCP）提供的是底层的、无状态的原子接口，比如读文件（read_file）、跑终端（bash）、查数据库。但光把这几个基础工具丢给模型，让它“做一个符合公司规范的 PPT”或者“做一次代码安全审计”，模型往往不知道先调哪个、参数怎么配、有哪些坑要避开。 Skill 就是把完成某类特定任务所需的「Prompt 流程指导 + 避坑指南 + 专用脚本 + 参考模板」打包成一个文件夹（核心是 SKILL.md）。它教模型遇到特定任务时，按什么顺序和规范去组合调用底层的 Tool。 2. 多对多的调用关系：一个 Skill 编排多个 Tool，一个 Tool 支撑多个 Skill Skill 本身不直接具备跳出沙盒的操作能力，它落地执行必须依赖底层 Tool。 比如一个「生成报表 Skill」，模型加载完它的 SKILL.md 后，会先调数据库 MCP 工具拉取数据，再调 bash 工具跑 Skill 自带的 Python 绘图脚本，最后调 write_file 工具生成文档。反过来，bash 和 read_file 这几个基础工具，会被几十个不同的 Skill 反复借用。 3. 实现层面的交集：Skill 的加载本身就是靠 Tool 实现的 就像上一条回答聊到的，为了做渐进式披露，框架层通常会把「获取 Skill 正文」这件事本身包装成一个伪工具（比如 Anthropic 的 Skill tool），或者直接让模型调原生的 read_file 工具去把 SKILL.md 读进上下文。也就是说，在运行机制上，模型是通过调用一个 Tool，把一份 Skill 说明书装进自己脑子里的。 4. 演进与生命周期管理：基础 Tool 追求少而稳，Skill 追求按需迭代与淘汰 现在主流 ca 的趋势是「底座工具极简化」——底层只需要 bash、读写文件等寥寥几个核心 Tool 就够了，尽量不搞成百上千个碎片的专用 Tool（工具太多模型反而选不准，哪怕配了 tool search 也有额外开销）。 复杂的业务能力全部上移做成 Skill。但要注意的是，Skill 也不是越多越好，它的管理是有生命周期的：随着团队塞进去的 Skill 变多，不同 Skill 的触发描述（description）之间很容易出现语义重复和冲突，维护成本也会变高；而且随着底层大模型基座能力更新换代，很多以前必须靠写复杂 Skill 掰着嘴喂给模型的流程，新模型原生就能做对了。所以实际工程里要定期随着模型升级做复测，把重复、冲突或者已经被模型内化而不再必要的旧 Skill 及时淘汰掉。