当前位置：首页 > news >正文

别再混用 Skill 和 Workflow：它俩不是一层东西

news 2026/5/22 1:17:49

摘要：Workflow 解决任务如何被编排和推进，Skill 解决某个环节如何被专业化执行；把这两个概念混在一起，Agent 系统设计会从起点就跑偏。

前言：面试官一句话，直接把概念混乱暴露出来

上周模拟面试，学长看完我的 Agent 项目描述，直接泼了一盆冷水：

你这里写了 workflow，又写了 skill。那你说说，它们到底差在哪？

我当时卡住了。

不是因为这两个词陌生，而是因为它们看起来太像。都和 AI Agent 有关，都像是在告诉模型怎么做事，也都能影响任务输出质量。

但这正是硬伤。看起来像，不代表处在同一个设计层级。

在 AI Agent 系统里，workflow 更接近流程编排（Workflow Orchestration），skill 更接近能力封装（Capability Packaging）。前者决定链路怎么跑，后者决定某个环节怎么做得更专业。

先把结论钉住：Workflow 管流程，Skill 管能力

如果只用一句话回答面试题，可以这样说：

Workflow 是任务链路的编排方式，Skill 是局部专业能力的封装方式。

这句话听起来简单，但背后有一个很关键的层级差异：

Workflow 关心一件事从开始到结束怎么推进。
Skill 关心某一个任务节点怎样被更专业地完成。
Workflow 通常管理状态、分支、重试、失败处理和终止条件。
Skill 通常提供规则、模板、脚本、检查清单或领域经验。

可以把它们放进一张图里看：

这张图的重点不是箭头，而是职责边界：workflow 是骨架，skill 是肌肉。骨架决定动作路径，肌肉决定单点执行质量。

差异一：关注点不一样

Workflow 关注任务推进

Workflow 关心的是整条链路怎么走。

比如一个 AI 客服系统，用户进来以后，系统要做这些判断：

先识别意图，还是先抽取实体。
命中高风险问题时是否转人工。
工具调用失败后是否重试。
简单问题走小模型，复杂问题走大模型。
最终答案是否需要审核。

这些问题本质上都不是“某一步怎么写得更好”，而是“整条任务链路怎么被控制”。这就是 workflow 的主场。

Skill 关注局部做法

Skill 关心的是某个环节的专业执行方式。

例如同样是“审查合同”，一个普通提示词可能只会说“帮我检查风险”。而一个合同审查 skill 会明确要求：

先识别合同主体、金额、期限、违约责任。
再检查付款节点和交付条件是否匹配。
然后扫描免责条款、单方解除权、模糊责任边界。
最后输出风险等级和修改建议。

它不负责决定合同审查在整个业务链路的第几步执行。它只负责在被调用时，把这一环节做得更稳定、更专业。

差异二：粒度不一样

Workflow 的粒度通常更大。

它往往对应一个完整业务目标，比如：

完成一次 AI 面试。
生成一份行业分析报告。
处理一张客服工单。
把用户问题分流到不同处理链路。

这些目标都包含多个步骤、多个判断点、多个中间状态。

Skill 的粒度通常更小。

它更像一个可复用的专家经验包，比如：

简历项目优化 skill。
代码 Review skill。
舆情摘要 skill。
CSDN 技术文章改写 skill。
SQL 性能诊断 skill。

它们不承担完整业务闭环，而是沉淀某类任务的高质量做法。

这个粒度差异，在面试里很好用。面试官问你“为什么不把所有东西都做成 workflow”时，可以直接回答：因为很多能力并不天然属于某一条业务链路，做成 skill 更利于跨场景复用。

差异三：状态归属不一样

Workflow 往往要管理状态。

它需要知道：

当前执行到第几步。
上一步输出是什么。
是否发生失败。
是否已经重试。
是否进入人工审核。
整条链路是否完成。

因此，workflow 经常和状态机、任务上下文、日志、链路追踪、监控指标绑定在一起。

Skill 通常不直接管理全局状态。

它更像一个被调用的能力单元。调用方给它输入，它根据内部规则、模板、脚本或参考资料，返回更高质量的输出。

这也是很多初学者容易踩坑的地方：把 skill 写成一个小型 workflow，里面塞状态流转、异常分支、调度策略，最后复用性变差，维护成本反而上升。

差异四：复用方式不一样

Workflow 的复用，偏业务级复用。

一个“客服工单处理 workflow”通常服务于客服场景。它里面会绑定客服分类、优先级、转人工规则、知识库查询和工单状态流转。你把它搬到招聘系统里，大概率要重做不少逻辑。

Skill 的复用，偏能力级复用。

一个“信息抽取 skill”可以服务客服、投研、简历诊断、合同审查。一个“代码 Review skill”可以挂在开发 Agent、测试 Agent、重构 Agent 下面。

所以在系统设计里，更健康的方式通常是：

拿 workflow 做业务骨架，拿 skill 做能力封装。这个认知差距会直接反映在面试里。

差异五：评估指标不一样

Workflow 看的是链路指标。

例如：

任务完成率。
平均耗时。
工具调用成功率。
重试率。
人工接管率。
单次任务成本。

因为 workflow 是流程系统，它的价值体现在整条链路是否稳定、成本是否可控、失败是否可恢复。

Skill 看的是能力指标。

例如：

抽取准确率。
输出格式稳定性。
人工修改次数。
审查漏检率。
生成内容是否符合领域规范。

因为 skill 是能力模块，它的价值体现在某个环节的输出质量是否提升。

这两个评估体系不能混用。用任务完成率去衡量一个写作 skill，容易把问题归因错；用输出格式稳定性去衡量一个业务 workflow，也看不出链路设计是否合理。

用 Java/AI 项目怎么落地理解

如果你做的是 2026 届校招常见的 Java + AI Agent 项目，可以这样拆：

workflow:name:interview-coachsteps:-parse_resume-generate_questions-score_answer-produce_feedbackskills:parse_resume:purpose:按岗位关键词抽取项目经历和技术栈generate_questions:purpose:按 Java、Spring AI、LangChain4j 和 Agent 设计生成问题score_answer:purpose:按准确性、完整性、工程可落地性评分

这里的interview-coach是 workflow，因为它定义了完整任务链路。parse_resume、generate_questions、score_answer更适合沉淀为 skill，因为它们是可复用的专业能力。

换到另一个业务里，比如“简历优化系统”，parse_resume这个 skill 仍然可以用。但interview-coach这个 workflow 未必还能原封不动复用。

面试里可以这样回答

如果面试官问：“Skill 和 Workflow 有什么区别？”

可以这样答：

我会把它们放在两个层级看。Workflow 主要解决任务如何被编排和推进，它负责步骤、分支、状态、重试和整条链路控制。Skill 更像可复用的专业能力封装，里面沉淀的是某类任务的经验、规则、模板或脚本资源。
所以 workflow 偏过程控制，skill 偏能力增强。设计 Agent 系统时，我会用 workflow 管业务链路，用 skill 提升关键节点的执行质量。

如果面试官继续追问“为什么要拆开”，可以补一句：