智能体、插件、技能、工作流：一次彻底搞清楚
智能体、插件、技能、工作流：一次彻底搞清楚
在 AI 应用的世界里，"智能体"、"插件"、"技能"、"工作流"这四个词被高频使用，却经常被混用。很多人用着插件，却以为自己在用智能体；花了大量精力搭工作流，其实只需要一个技能就够了。
搞清楚它们的边界，可以让你少走很多弯路。
一、先把四个概念说清楚
智能体（Agent）
智能体的核心是"自主决策"。
它有目标，有感知，能根据当前情况自行决定下一步做什么。你给它一个任务，它会拆解、规划、调用工具、执行、反馈，直到完成——整个过程中，它在驾驶席上。
典型例子：Claude Code、AutoGPT、Devin。你说"帮我给这个项目写测试"，它会读代码、分析结构、生成测试、运行调试，直到跑通。你不需要告诉它每一步怎么做。
智能体的三个关键特征：
- 有记忆：知道之前做了什么，能在上下文中推理
- 会规划：把大目标拆成小步骤
- 能行动：通过工具改变外部世界（写文件、调 API、发消息）
插件（Plugin）
插件的核心是"功能扩展"。
插件本身不会主动做任何事，它是一个等待被调用的能力接口。有人调用它，它执行并返回结果；没人调用，它就安静待着。
典型例子：ChatGPT 的 Web Search 插件、计算器插件、天气查询插件。它们本身不会思考，只是当智能体或用户需要某个能力时，提供那个能力。
插件的两个关键特征：
- 被动：只响应调用，不主动发起
- 专一：通常只做一件具体的事（搜索、翻译、查数据）
技能（Skill）
技能的核心是"可复用的行为模式"。
技能比插件复杂，比智能体克制。它封装了一套完整的处理逻辑——通常包括提示词、工具调用序列、判断逻辑——针对某个特定领域或任务类型，可以在不同上下文中复用。
典型例子：Claude Code 的
/commit技能。调用/commit，它知道先看 diff、再看 log 风格、再写提交信息。这些都是预设好的行为模式。
技能的两个关键特征：
- 领域聚焦：针对特定任务类型深度优化
- 模式化：有固定的处理流程，但在流程内有灵活性
工作流（Workflow）
工作流的核心是"步骤编排"。
工作流把多个动作、工具、甚至多个智能体按照特定顺序或逻辑串联起来，形成一条流水线。它更关心"顺序"和"条件"，而非"推理"。
典型例子：n8n 的自动化流程——当收到一封邮件，提取关键信息，存入数据库，发送 Slack 通知。整个流程是预先定义好的，每一步做什么、什么触发下一步，都写死在图里。
工作流的两个关键特征：
- 确定性：流程路径是预先规划的，不靠推理
- 协调性：把多个独立组件串联成整体
二、一张图看清层级关系
┌─────────────────────────────────────────────┐
│ 工作流 │
│ （编排和调度 → 智能体、工具、人工节点） │
│ │
│ ┌──────────────────────────────────┐ │
│ │ 智能体 │ │
│ │ （自主决策 → 调用技能和插件） │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 技能 │ │ 插件 │ │ │
│ │ │（行为模式）│ │（功能接口）│ │ │
│ │ └──────────┘ └──────────┘ │ │
│ └──────────────────────────────────┘ │
└─────────────────────────────────────────────┘
层级从上到下：
- 工作流 是最外层的调度者，它可以包含多个智能体和工具节点
- 智能体 是执行者，在一个任务范围内自主决策，调用下层能力
- 技能 是智能体的行为预设，领域专用、可复用
- 插件 是最底层的能力接口，被上层任意调用
三、核心区别：三个维度
维度一：谁在做决定
| 概念 | 决策主体 |
|---|---|
| 工作流 | 预先定义的逻辑 |
| 智能体 | AI 自主推理 |
| 技能 | 预设模式 + 局部推理 |
| 插件 | 无决策，只执行 |
如果有一个 AI 在"思考下一步该怎么做"，那是智能体。
如果是按照写好的图/流程在走，那是工作流。
维度二：粒度大小
插件 < 技能 < 智能体 < 工作流
插件是一个螺丝刀，技能是一套工具箱，智能体是一个工程师，工作流是一条装配线。
维度三：可预测性
| 概念 | 行为可预测性 | 适合的任务 |
|---|---|---|
| 插件 | 极高 | 固定计算、查询 |
| 技能 | 高 | 标准化任务 |
| 工作流 | 高 | 多步骤自动化 |
| 智能体 | 中到低 | 复杂、开放性任务 |
工作流和插件的行为是可以完全预测的。
智能体会根据情况做出不同决策，行为有不确定性——这是它的能力，也是它的风险。
四、什么时候用什么
用插件，当你需要
- 访问一个固定的外部能力（搜索、翻译、天气、数据库查询）
- 该能力输入输出格式明确，逻辑简单
- 这个能力需要被多个地方复用
错误做法：用智能体去做一件用插件就能搞定的查询任务，浪费算力，增加不确定性。
用技能，当你需要
- 在某个领域反复执行相似任务（写 commit、处理 PDF、生成推文）
- 这个任务有固定的最佳实践，值得封装
- 你希望 AI 的行为在这个任务上保持一致
错误做法：每次都重新用自然语言描述"如何写 commit"，这应该封装成技能。
用智能体，当你需要
- 任务目标明确，但路径未知（"帮我调研这个市场"、"帮我修复这个 bug"）
- 过程中需要根据中间结果调整策略
- 任务需要多步推理和工具协作
错误做法：用工作流处理需要推理的任务。当条件太复杂、分支太多，工作流会变成一张蜘蛛网，这时候放一个智能体进去更合适。
用工作流，当你需要
- 流程固定、步骤清晰（接收邮件 → 分类 → 回复）
- 需要集成多个系统或服务
- 需要定时触发或事件驱动
- 需要极高的可靠性和可审计性（每一步都要留记录）
错误做法：用智能体做完全结构化的流程任务，增加不必要的随机性，还更贵。
五、实际场景里的组合方式
这四个概念在实际系统里往往是嵌套使用的。
场景 A：内容自动化管道
工作流：每天早上 8 点触发
→ 插件：抓取 RSS 新闻
→ 智能体：分析新闻，选出值得写的选题
→ 技能：用固定模板生成推文草稿
→ 插件：发布到 Buffer 排期
场景 B：AI 编程助手
智能体：理解用户的需求，规划执行策略
→ 技能：读代码（按领域优化的读取方式）
→ 技能：写测试（遵循项目测试规范）
→ 插件：运行测试（执行 shell 命令）
→ 技能：写 commit（遵循提交规范）
场景 C：客服系统
工作流：用户发送消息 → 分类意图
→ 简单问题 → 插件：查 FAQ 数据库，直接回答
→ 复杂问题 → 智能体：调用多个工具，综合推理后回答
→ 投诉类 → 人工节点：转人工处理
六、一个判断框架
遇到要搭建 AI 系统的场景，可以按这个顺序问自己：
这个任务的步骤是固定的吗？
是 → 考虑工作流
否 → 考虑智能体任务中有没有需要访问外部系统的具体操作？
有 → 用插件封装这些操作有没有某种任务类型会反复出现、且有固定最佳实践？
有 → 提炼成技能整个系统需要多个组件协作吗？
需要 → 用工作流做顶层编排
大多数实际系统都是"工作流 + 智能体 + 技能 + 插件"的组合，而非单一选择。关键是在每一层用对抽象。
结语
混淆这四个概念的代价，是用了错误的工具解决问题——要么过度复杂（用智能体做简单查询），要么能力不足（用插件做需要推理的任务）。
记住最核心的那条线：谁在做决定？
有推理、有自主性，是智能体。
有顺序、有逻辑编排，是工作流。
有可复用的行为模式，是技能。
有单一能力接口，是插件。
搞清楚这条线，大多数困惑就会消失。
If you read this far — thank you.
Come tell me what you thought on X.