企业用智能体,要分清这两笔投入:插件接能力,Skill教方法

给智能体装插件、写 Skill，看起来都能让它更好用。两者到底有什么区别？

一个给智能体接入功能，一个教智能体使用功能的方法。放进具体工作里，这个区别就很清楚了。

插件，是安装到智能体运行框架中的程序组件，可以扩展工具、连接外部服务，也可以增加按钮、设置面板等界面功能。

比如，一个语音合成插件接入了语音服务，智能体就可以通过它，把文字转换成音频文件。

模型可以写一段口播稿，但要真正生成音频，还得有执行语音合成的工具。插件可以负责把这项功能接进来。

当然，接入功能也有其他方式，例如已有工具、API或MCP连接。企业需要先检查现有能力，再决定是否开发插件。

Skill，是一套可以重复使用、供智能体按需读取的任务说明，通常以 SKILL.md 文件为入口。

它会告诉智能体：什么情况下使用这套方法，先做什么、后做什么，调用哪些工具，结果要符合什么要求。

比如，智能体已经能写稿、生成音频，但你希望它每次制作口播时，都先把长文改成短句，再检查读音，最后生成配音。这套做法就适合写成 Skill。

它和临时提示词的关系也很好理解：临时提示词是这次交代，Skill是把值得反复使用的交代整理保存，需要时再读取。

Skill还可以附带脚本、参考资料和模板。但它能不能执行，仍然取决于智能体有没有相应工具、权限和运行环境。写一句“生成音频”，不会凭空开通语音服务。

用户提出任务后，智能体需要理解要求、选择方法、调用工具，再整理结果。

在这个过程中，模型负责理解和组织任务；Skill提供任务方法；插件可以提供执行所需的工具和其他运行功能。

可以把它们理解为：

这是为了理解分工。实际产品中，一个插件也可能同时带有工具和Skill，两者可以打包在一起。

假设你对智能体说：“把这篇公众号文章做成一分钟左右的口播音频。”

这项任务里，插件和Skill分别做什么？

它连接语音服务，接收文本和声音参数，返回音频文件。

例如，这份Skill约定：

只有语音工具，原文也许能被读出来，但读出来是否啰嗦、是否适合听，还需要处理。

只有Skill，智能体可以准备好口播稿；如果没有可用的语音工具，就无法完成音频生成。

如果智能体缺少某项功能，比如无法连接内部系统、调用语音服务，就先解决能力接入。已有工具够用，直接使用；确有缺口，再考虑插件或其他集成方式。

如果工具已经齐了，只是每次都要重新解释步骤、反复修改输出，就适合把方法整理成Skill。

还有一种情况：某条要求绝对不能跳过。

比如，未经审批不能发送报价。这时，除了在Skill里交代流程，还要让发送工具检查审批状态，条件不满足就拒绝执行。文字指令负责指导，系统规则负责拦截。

DSH讲的“一切皆插件”，描述的是它组织和扩展运行功能的架构。它并不意味着每份业务操作说明都要开发成插件。承载Skill的功能可以由插件提供，Skill里的任务方法仍然可以单独编写和维护。

企业做智能体，可以先拿一项小任务问两句话：现在缺的是工具，还是做法？

缺工具，就补连接；缺做法，就把步骤和标准写清楚。两笔投入各有用途，先找准缺口，才知道该从哪里动手。

参考资料

技术说明依据2026年11月7日核查的资料；具体功能以实际产品和版本为准。