本文是《WorkBuddy AI 工作流实战》系列第 1 篇。

如果你经常听到 Agent、Skill、Tool、工作流这些词，却总觉得它们混在一起，这篇文章会用一套框架讲清楚：为什么复杂任务更适合交给工作流、Agent 如何持续推进任务，以及 Agent、Skill、Tool 分别负责什么。

---

一、为什么只靠“聊天”还不够？

很多人使用 AI 的方式，仍然停留在“一问一答”：输入一个问题，得到一个答案，本轮任务就结束了。

这种方式适合查概念、改文案、写一段代码，但遇到真正需要落地的复杂任务，就会变得很费劲。例如：

读取一份 50 页的 PDF，提炼核心观点，整理待办事项，并将结果保存为 Markdown 文件。

为了完成这件事，AI 不仅要“回答问题”，还要连续完成读取文件、拆解任务、提取信息、生成内容、检查结果和写入文件等操作。如果每一步都需要你手动下指令，你就从任务发起者变成了“人工调度器”。

工作流解决的正是这个问题。

对比维度	普通聊天	AI 工作流
任务形态	单轮或少量问答	多步骤、长链路任务
推进方式	用户持续给出指令	Agent 根据目标规划并推进
工具调用	通常较少	可连续读取文件、运行脚本、调用接口
人工参与	经常需要逐步确认	可在关键节点确认，其余步骤自动执行
复用能力	更偏一次性	可沉淀为重复调用的流程或 Skill

一句话概括：

聊天是“你问，它答”；工作流是“你给目标，它按步骤把事情推进到结果”。

WorkBuddy 这类 Agent 工具的价值，就在于让 AI 不只生成文字，还能围绕目标规划步骤、调用工具、检查结果，并持续执行任务。

---

二、工作流为什么能持续运行？核心是 Agent Loop

AI 工作流能够连续完成多步任务，通常依赖一个核心机制：Agent Loop（智能体循环）。

它的基本过程如下：

可以把这个循环拆成五个环节：

1. 理解上下文：识别用户目标、已有资料、限制条件和期望输出。
2. 决定下一步：把大任务拆成当前可以执行的具体动作。
3. 调用工具：读取文件、运行命令、搜索信息或请求外部接口。
4. 观察结果：检查工具返回了什么，判断是否符合预期。
5. 继续或收口：目标尚未完成就进入下一轮；完成后校验并交付。

以“整理 PDF”为例，Agent 可能经历这样的循环：

发现用户提供了 PDF
→ 调用工具读取文档
→ 判断内容较长，按章节提取重点
→ 汇总摘要和待办事项
→ 检查是否遗漏关键章节
→ 写入 summary.md
→ 返回文件位置和执行结果

这里最重要的不是 AI“一次就想对”，而是它能够根据每一步的真实结果继续判断和修正。

Agent Loop 是工作流持续运转的动力机制；Skill 和 Tool 则分别为这个循环提供方法与执行能力。

---

三、三块核心积木：Agent、Skill、Tool

理解 AI 工作流，关键是分清 Agent、Skill 和 Tool 的职责。

组件	它是什么	主要职责	类比
Agent	能理解上下文并进行规划的 AI 执行主体	判断做什么、何时做、使用什么能力，以及失败后如何调整	负责干活和决策的师傅
Skill	针对特定任务沉淀的方法、规则和步骤	告诉 Agent 某类任务应该如何稳定完成	师傅掌握的专项操作手册
Tool	与文件、命令、网络或外部服务交互的执行器	真正执行读取、写入、搜索、运行和调用等动作	锤子、扳手等具体工具

1. Agent：负责决策

Agent 是整个工作流的调度核心。它会结合用户目标、上下文和执行结果，动态决定下一步做什么。

例如，用户要求“整理一份 PDF”，Agent 需要判断：

• 先用什么工具读取文件；
• 是否需要分章节处理；
• 应该生成摘要、表格还是待办清单；
• 输出前是否还要检查格式与完整性；
• 工具执行失败后应该重试、换方案，还是向用户确认。

因此，Agent 的核心不是“调用一次工具”，而是围绕目标持续做决策。

2. Skill：提供专项方法

Skill 可以理解为一份可复用的“专项能力说明书”。它会告诉 Agent：遇到某类任务时，应遵循哪些步骤、使用哪些工具、满足哪些质量标准。

例如，一个“长文摘要 Skill”可能规定：

1. 识别文章结构；
2. 按章节提取核心观点；
3. 区分事实、结论和行动项；
4. 输出摘要与待办清单；
5. 检查是否遗漏关键内容。

没有 Skill，Agent 也可能完成任务；有了 Skill，相同任务通常会执行得更稳定、更一致，也更容易复用。

3. Tool：执行具体动作

Tool 是真正接触外部环境的执行器，例如：

• 文件读取与写入工具；
• Shell 或代码执行工具；
• 网页搜索和内容抓取工具；
• 数据库、浏览器及第三方 API；
• 通过 MCP 接入的外部系统能力。

大模型本身擅长理解和生成内容，但“读取你电脑上的文件”“运行一段脚本”“把结果保存到磁盘”这类动作，通常需要 Tool 才能完成。

三者到底是什么关系？

可以记住这句话：

Agent 负责判断，Skill 提供方法，Tool 负责执行。

它们不是三个互相替代的概念，而是工作流中不同层次的组成部分：

用户提出目标
    ↓
Agent 理解任务并做出决策
    ↓
参考 Skill 中沉淀的方法和规范
    ↓
调用 Tool 执行具体操作
    ↓
Agent 根据结果继续判断，直到完成目标

---

四、用一个例子串起来：把 PDF 整理成摘要和待办

假设你向 Agent 提出下面的目标：

请读取 project_report.pdf，生成一份 1000 字以内的摘要，提取所有待办事项，并保存为 summary.md。

这时，三者会这样分工：

阶段	Agent 做什么	Skill 提供什么	Tool 做什么
理解目标	识别输入文件、输出格式和字数限制	提供文档整理的标准流程	—
读取内容	决定先解析 PDF	规定长文应按章节处理	读取并提取 PDF 文本
整理信息	判断哪些内容属于核心观点和待办	提供摘要、行动项的提取规则	必要时运行脚本辅助处理
检查结果	检查字数、完整性和格式	提供质量检查清单	获取文件状态或统计结果
保存交付	确认输出路径	规定 Markdown 输出模板	写入 summary.md

可以看到：

• Agent 始终负责“现在该做什么”；
• Skill 让处理过程有章可循；
• Tool 把决策变成真实操作；
• Tool 返回结果后，Agent 再进入下一轮判断。

这就是一条完整的 AI 工作流。

---

五、所有工作流都可以用这套骨架理解

无论任务简单还是复杂，都可以先用下面五个环节进行分析：

目标 → 规划 → 执行 → 校验 → 产出

环节	要解决的问题	“整理 PDF”示例
目标	输入是什么，期望结果是什么	将 PDF 转成摘要和待办清单
规划	需要拆成哪些步骤	读取、提取、整理、检查、保存
执行	需要调用哪些 Skill 和 Tool	使用文档处理方法与文件工具
校验	如何判断任务完成得正确	检查重点、字数、格式和文件状态
产出	最终交付什么	生成 summary.md 并返回结果

这套骨架有两个直接用途：

1. 分析现有工作流：快速定位问题出在规划、工具执行还是结果校验。
2. 设计新工作流：先定义目标和产出，再补齐中间步骤与质量标准。

后续实战也会围绕这套骨架展开：先把重复任务固化为 Skill，再逐步加入异常处理和质量门禁。

---

六、几个常见误区

误区 1：Agent 就是聊天机器人

聊天机器人通常以生成回复为终点；Agent 更强调围绕目标采取行动，并根据执行结果继续决策。两者都可能使用大模型，但任务推进方式不同。

误区 2：Skill 就是 Tool

Skill 主要描述“应该怎样完成一类任务”，Tool 则负责“执行某个具体动作”。前者偏方法和规范，后者偏操作能力。

误区 3：工具越多，工作流越强

工具数量不等于执行质量。真正影响结果的，往往是 Agent 能否选择正确工具、Skill 是否给出清晰步骤，以及流程中有没有有效校验。

误区 4：自动化意味着完全不需要人

可靠的工作流并不是盲目自动执行。涉及删除文件、发布内容、支付费用或修改生产环境等高风险操作时，仍然应该设置人工确认节点。

---

总结：记住这三句话

1. 工作流不是多聊几轮，而是围绕目标持续规划、执行和校验。
2. Agent 负责判断，Skill 提供方法，Tool 负责执行。
3. 工作流的通用骨架是：目标 → 规划 → 执行 → 校验 → 产出。

如果还觉得抽象，可以记住这个类比：

Agent 是师傅，Skill 是操作手册，Tool 是手里的工具；Agent 按照方法使用工具，并根据现场结果不断调整，直到把任务做完。

---

下篇预告

概念理清之后，下一篇直接动手：

《动手搭建第一条 AI 工作流：把重复任务固化成可复用 Skill》

我们会把“长文 → 摘要 + 待办清单”这类高频任务写成第一个 SKILL.md，让 Agent 从“临场发挥”变成“按标准流程稳定执行”。