Workflow、Agent、Skill：你用对了吗？
做 AI 产品、搭平台、或者只是想把某个“按钮一键生成内容”的能力跑起来时，很多团队都会很快遇到三个词：Workflow、Agent、Skill。
它们经常被混用：把一段提示词叫 Skill，把一段编排叫 Agent，把一个按钮叫 Workflow……结果是系统越做越大，概念越用越乱，最后只能靠“约定俗成”勉强维护。
这篇文章想用一种更“工程化”的方式，把这三个概念拆清楚：它们分别解决什么问题、应该放在哪里、在什么场景下谁是主角。如果你正在搭建类似 Harness 的架构（底层工具调用 + 记忆 + 工作流编排 + 智能生成），希望能直接对你有用。
一、先给一句“总纲”：三者的核心分工
你可以把它们理解成一条链路上的三层：
Skill：可复用能力单元（做一件事）
把输入变成输出，尽量“函数化”、可测试、可复用。Workflow：编排与运行时（把多件事按规则串起来）
决定先做什么、后做什么，失败怎么办，是否并行，是否需要人工确认，如何落库、重试、回滚、观测。Agent：面向用户/业务的“入口角色”（决定做什么）
负责理解意图、收集缺参、选择策略、选择要跑的 workflow 或 skill，并在必要时与用户交互、解释结果、兜底。
一句话版本是：
Agent = 决策与入口
Workflow = 编排与运行时
Skill = 原子能力与复用
二、Skill：你真正应该沉淀的“能力资产”
1）Skill 的核心作用是什么？
Skill 的目标不是“写一段 prompt”，而是把某种能力封装成可重复调用的组件：
- 输入输出明确：给什么、返回什么尽量清晰
- 可复用：多个 workflow/多个场景都能调用
- 可测试/可评估：你能定义“好输出”的标准（哪怕是打分/规则校验）
- 可迭代：可以升级版本、做 A/B、换模型而不影响上层流程 把 Skill 当成“能力库”，而不是“流程说明书”。
2）典型 Skill 长什么样？
以内容生成平台为例，你可以有：
- title_generator：输入受众/风格 → 输出多候选标题
- caption_generator：输入结构化素材 → 输出正文草稿
- compliance_checker：输入文案 → 输出风险点/替代表达
- image_prompt_builder：输入主题/文案 → 输出用于生图的 prompt
- image_generator / image_enhancer：输入 prompt/图片 → 输出图片资产
- style_ranker：输入多候选 → 输出排序与原因（可选） 注意：这些 Skill 可能内部用 prompt，也可能是传统算法/规则/外部工具调用。关键在于它对上层呈现为一个稳定能力。
3）Skill 适合解决什么问题？
- 需要复用的能力沉淀（越复用越该做 Skill）
- 需要独立优化的模块（标题写得好不好，可以单独评测）
- 需要“可替换实现”的能力（同一个 Skill 可以换模型/换策略）
三、Workflow：当你开始认真“交付结果”，就离不开它
1）Workflow 的核心作用是什么？
Workflow 不只是把步骤写成 1、2、3。更关键的是：它提供流程的运行时能力。这也是为什么“把工作流写进 Skill 里”很多时候并不能替代 workflow 引擎。
Workflow 通常承担：
- 编排：串行/并行/分支/条件路由
- 可靠性：重试、超时、幂等、防重复扣费、防重复写入
- 状态管理：长流程中断恢复、进度、可取消
- 补偿/回滚：部分成功后失败，怎么收拾残局（Saga 思路）
- 产物落库：生成结果、版本、来源、成本、日志
- 观测与治理：成功率、耗时、成本、错误分布、审计 你可以把 Workflow 看成“自动化流水线 + SLA + 可追踪的执行记录”。
2）为什么按钮式场景尤其需要 Workflow？
例如：用户上传素材后点击按钮“一键生成文章标题与内容”，以及“无图时一键生图”。
这类“按钮式一键生成”通常会遇到：
- 出图/生成耗时较长 → 异步任务、进度条、可取消
- 同时很多人点 → 队列、限流、并发控制
- 调用外部模型/工具有失败 → 重试策略
- 多候选、多版本 → 落库、对比、回滚
- 计费与成本 → 幂等、防重复扣费、审计
- 模型升级与灰度 → 版本化与策略路由 这些几乎都不是“prompt 写得更好”能解决的，而是 workflow runtime 的基本盘。
3）Workflow 适合解决什么问题？
- 明确的业务流程（比如“生成→检查→落库→通知”）
- 需要可靠性与可治理（平台级能力必备）
- 跨多个 Skill/工具/子系统协作的执行链路
四、Agent：不是“会说话的机器人”，而是“策略入口”
1）Agent 的核心作用是什么？
很多人把 Agent 理解成“对话机器人”，但这只是形态之一。更本质的是：Agent 是一个能做决策的入口角色，它负责把用户需求映射到系统能力上：
- 意图识别：用户到底要生成标题还是要美化图片？
- 补齐信息：缺少受众/风格/禁用词时怎么办？
- 策略选择：用哪个模板、生成几条、走快模式还是质量模式
- 路由编排：选择哪个 workflow 或直接调用哪个 skill
- 结果解释与兜底：失败时降级策略是什么？如何给用户可用输出？
2）按钮式产品还需要 Agent 吗？
需要，但Agent 不一定要对用户显性出现。
在按钮式场景中，“意图”已经被按钮固定了，所以你往往不需要一个面向用户的对话 Agent 做意图识别。但 Agent 仍然可以以“内部节点执行者”的方式存在：
- 作为 workflow 的一个节点做：候选排序、风格路由、异常处理、内容自检
- 作为策略引擎：根据用户画像/偏好选择模板、控制生成长度、决定是否加标签
- 作为多模型路由：根据内容类型选更适合的模型或参数 换句话说：按钮式产品里，Workflow 是第一公民；Agent 更像是 workflow 里的“智能节点”。
3）Agent 适合解决什么问题？
- 需求不确定、输入不完整、需要动态策略的场景
- 同一个入口要覆盖多类任务（用户一句话可能触发不同流程）
- 需要解释、需要交互、需要“像人一样处理异常”的场景
五、到底怎么用才算“用对了”？给你三个常见模式
模式 A：Agent → Workflow → Skill（最通用）
- 用户找 Agent（对话/@/API）
- Agent 选择并触发 Workflow
- Workflow 编排多个 Skill 执行并落库 适用：入口复杂、任务多样、需要强策略。
模式 B：按钮 → Workflow → Skill（你们“小红书一键生成”最像这个）
- 用户点击按钮
- 直接触发 workflow run（job）
- workflow 内部调用 skill（必要时调用 agent 节点） 适用：动作明确、强调可靠交付与平台治理。
模式 C：只用 Skill（早期原型/超短链路）
- 不需要异步、重试、落库治理
- 2～3 步以内，失败了让用户重来即可 适用：快速验证、低并发、低风险场景。
但一旦进入平台化，你大概率会从 C 演进到 B 或 A。
六、一个“自检清单”：你是不是把概念用反了？
你可以用这 6 个问题快速判断：
- 这段东西能不能被多个场景复用？能 → 更像 Skill
- 这里是否需要重试/超时/幂等/进度/可取消？需要 → 必须有 Workflow
- 这里是否需要根据输入动态选择策略或流程？需要 → 更像 Agent
- 用户的心智是“点一个动作”还是“找一个角色”？点动作 → Workflow；找角色 → Agent
- 你们未来最常改的是“能力实现”还是“流程步骤”？改能力 → Skill；改步骤 → Workflow
- 这一步失败会不会产生“半成功”的副作用？会 → Workflow 必须承担补偿/回滚策略
结语：别纠结名词，纠结“职责边界”
Workflow、Agent、Skill 这三个词没有宇宙通用标准，但它们之所以值得分开，是因为它们分别对齐了三种不同的系统诉求：
- Skill 对齐复用与能力沉淀
- Workflow 对齐可靠交付与治理
- Agent 对齐策略决策与入口体验 当你把职责边界划清楚，系统就会变得更可维护：
prompt 不会散落，流程不会纠缠，升级不会牵一发动全身。