Agent、Skill、Tool 与 Workflow

一句话理解：Agent 是“谁来干活”，Skill 是“怎么干”，Tool 是“用什么干”，Workflow 是“按什么固定流程干”。

这四个词在各种产品发布会、框架文档和需求评审里被混着用：有人把一个 API 叫 Skill，有人把一段固定流程叫 Agent，有人说“给 Agent 加个 Workflow 工具”。概念一混，方案就会出问题：本该写成固定流程的步骤交给模型自由发挥，结果不稳定；本该沉淀成方法的经验被塞进一个巨大的 Prompt，谁都维护不了。

这一课用一个类比和一个完整例子，把四者的边界讲清楚。

用“一家咨询公司”做类比

概念	类比	本质	典型形态
Agent	负责项目的顾问	能理解目标、做判断、决定下一步的执行者	模型 + 指令 + 循环
Skill	顾问脑子里的方法论与 SOP	可复用的“做事方法”，需要时才翻出来	一份说明文档 + 脚本 + 模板
Tool	顾问手边的电脑、数据库账号、电话	对外部系统的一个具体操作	有名字、描述、参数的函数或 API
Workflow	公司规定的报销审批流程	预先写死的步骤顺序，谁来都一样	代码或流程引擎里的固定编排

几个关键区别：

• Tool 只做一件事，不做判断。 get_search_console_data(site, date_range) 就是拉数据，它不知道拉来干嘛。
• Skill 不直接作用于外部世界，它教 Agent 怎么组合工具。 “SEO 诊断方法”会告诉 Agent 先看收录、再看排名、最后看页面，但真正拉数据的是 Tool。
• Workflow 的下一步由代码决定，Agent 的下一步由模型决定。 这是两者最本质的区别，详见Workflow 与 Agent。

同一个任务里的四个角色

任务：“诊断一下官网最近自然流量下降的原因，给出修复建议。”

四个角色在这个任务里的分工如下：

在这个例子里：

• 判断“是全站下降还是某个目录下降”，需要看数据后决定，交给 Agent。
• 诊断的先后顺序与检查项，是 SEO 专家的经验，沉淀成 Skill。
• 拉数据、抓页面，是对外部系统的确定操作，做成 Tool。
• 生成并发送报告，每次都一样，写成 Workflow，Agent 只需要在最后触发它。

它们之间可以互相嵌套

实际系统中，四者经常套在一起，这也是容易混淆的原因：

嵌套方式	例子	什么时候这样做
Agent 调用 Workflow	Agent 诊断完后，调用“生成周报”流程	某一段步骤固定、要求稳定
Workflow 中嵌入 Agent 节点	工单系统固定流转，其中“判断异常原因”一步交给 Agent	主流程固定，只有个别步骤需要判断
Workflow 被包装成 Tool	把“创建退款申请（含校验与审批）”包装成一个工具	希望 Agent 调用简单，风险由流程兜底
Agent 被包装成 Tool	主 Agent 调用“竞品调研 Agent”并拿回结果	子任务复杂、需要隔离上下文
Skill 附带脚本	SEO Skill 里附一个批量检查 canonical 的脚本	方法中有确定性的计算步骤

所以判断一个东西“是什么”，不看它叫什么，而看它 是否做判断、是否作用于外部、是否可复用、步骤是否固定。

归类时，可以按下面的顺序提问：

Skill、Tool、Workflow 与 Subagent 的更细致边界，在Skill、Tool、Workflow 与 Subagent 一课展开；嵌套架构的设计方法见混合架构。

再看两个场景

Coding Agent 修一个 Bug

• Agent：Coding Agent 本身，决定先读哪个文件、改哪里、要不要再跑一次测试。
• Skill：团队的“提交规范与 PR 模板”“前端组件编写约定”。
• Tool：读文件、改文件、执行终端命令、搜索代码。
• Workflow：CI 流水线——提交后固定执行 lint、测试、构建。

销售分析 Agent 解释业绩下滑

• Agent：决定按区域拆还是按渠道拆，发现异常后继续下钻。
• Skill：“销售下滑归因方法”：先排除口径变化，再看量价拆分，再看渠道与 SKU。
• Tool：query_sales(dimension, date_range)、get_inventory(sku)。
• Workflow：每周一自动出数、生成看板、推送给区域负责人。

常见误区

• “把所有能力都做成 Tool。” 方法论不是 Tool。把“SEO 诊断”做成一个巨大的工具，Agent 就只能整体调用、无法根据中间结果调整，而且出错了也不知道错在哪一步。
• “Workflow 过时了，全部交给 Agent。” 固定、高频、要求稳定的步骤，用 Workflow 更便宜、更可靠、更好审计。Agent 应该只负责真正需要判断的部分。
• “Skill 就是一段更长的 Prompt。” Skill 的价值在于按需加载与可复用：不用时不占上下文，多个 Agent 可以共用同一套方法。它通常还带脚本和模板，而不只是文字。

产品经理检查清单

评审一个 Agent 方案时，把需求里的每个能力分到四个桶里：

• 哪些步骤需要根据中间结果动态决定？（Agent）
• 哪些专家经验需要被复用、按需加载？（Skill）
• 需要对哪些外部系统做哪些具体操作？每个操作是读还是写？（Tool）
• 哪些步骤顺序固定、每次都一样？（Workflow）
• 有没有“伪 Agent”：看起来是 Agent，其实步骤完全固定？
• 有没有“巨型工具”：一个工具里藏着多步判断？

练习

选一个你所在团队的真实流程（例如“客户投诉处理”或“每月销售复盘”），用 30–45 分钟完成：

1. 把流程拆成 8–12 个步骤。
2. 为每个步骤标注：Agent / Skill / Tool / Workflow，并写一句理由。
3. 找出一个你最拿不准的步骤，分别写出“做成 Workflow”和“交给 Agent”的利弊。

步骤	归类	理由
例：根据投诉内容判断问题类型	Agent	表述多样，需要理解与判断
例：查询订单详情	Tool	单一、确定的读操作

下一步

分清了“谁来干活”，下一课「模型与 Harness」回答一个更实际的问题：为什么同一个模型，放进不同产品里表现差距巨大。