昨天一个学员发消息问我："我在各种地方看到提示词、Skill、MCP、Agent，这几个词好像在说同一件事，又好像不是，到底什么关系？"

这问题不算罕见。这四个词最近两年出现频率极高，很多人用了很久也没真正搞清楚边界。今天统一讲一遍，用一个比喻拉通，读完应该不会再混。

---

做个比喻

把 AI 想象成一个全能助理，刚刚入职，什么都会，但需要你告诉他怎么做事。

提示词：你口头交代他的指令

Skill：写成文档的操作手册，交代他这类事情固定怎么处理

MCP：给他配的工具箱，里面有数据库权限、查询接口、发消息通道

Agent：让他不只是接收指令，而是主动帮你完成一个多步任务，自己思考怎么推进

这四个东西，解决的是同一个 AI 助手在不同层面的问题：说什么、怎么记住怎么说、能用什么工具、能不能自己规划。

如果用建筑比喻：

Agent = 房屋的总设计师 + 住户，既是使用工具的人，也是规划结构的决策者。 它住在房子里，决定今天用洗衣机还是电脑，当发现地基（提示词）不稳时，它还能调取工具来“修缮”地基。

Skill = 家用电器/工具（如洗衣机、电脑），具备特定功能的模块（如发邮件、查天气），平时待命，被需要时才启动。

MCP = 水电煤气管网，负责连通外部世界，传输数据、调用工具、反馈状态，是维持运转的“生命线”。

提示词 = 地基，奠定人格、目标和基础规则，看不见但决定上限。

---

一、提示词（Prompt）

它到底是什么

提示词就是你给 AI 的输入，包括你的问题、指令、背景信息、角色要求、输出格式限制……凡是你发给 AI 的文字，都叫提示词。

说白了，就是"你和 AI 说的话"。

但有意思的地方在于：同样一件事，怎么说，结果差很多。

你说"帮我分析这个需求"，AI 可能给你一堆废话。你说"你是一位测试架构师，请基于以下需求，按边界值分析和等价类划分方法，输出带优先级的测试点列表，格式为 Markdown 表格"，AI 给你的结果可以直接用。

这就是提示词工程要解决的核心问题：精准描述意图，减少 AI 的猜测空间。

提示词有几个关键要素

要素	说明	例子
角色定义	告诉 AI 以什么身份回答	"你是一位资深测试工程师"
任务描述	明确做什么事	"分析以下功能需求的测试点"
背景信息	输入材料	粘贴需求文档内容
约束条件	输出格式、范围、边界	"只考虑正向流程，输出不超过10条"
输出格式	你希望看到的样子	"用 Markdown 表格，含优先级列"

提示词越结构化，AI 越好配合。这不是因为 AI 笨，而是它的能力范围太宽，需要你给它收窄。

---

二、Skill（技能包）

跟提示词有什么区别

提示词是你每次临时说的话。Skill 是把一套"怎么跟 AI 说这类事"的最佳实践固化下来的文档。

还是用助理比喻：提示词是你当下口头交代的指令，Skill 是你交给他的 SOP 操作手册，里面写清楚这类任务的标准处理方式、输出格式、注意事项。

以 WorkBuddy 平台为例，一个 Skill 文件（SKILL.md）通常包含：

角色定义 触发场景 处理流程 输出模板 知识库

比如我们之前做的 test-requirement-analysis Skill，里面内嵌了通用测试点检查清单（附录A）和 RPN 风险识别模型（附录B）。每次用它分析需求，不用重新描述方法论，Skill 里已经写好了怎么分析、怎么输出，直接套用就行。

Skill 的价值在哪里

可复用。 同样的工作流，第一次要花几十分钟摸清楚怎么让 AI 配合，后面每次只需要触发 Skill 名称，结果稳定一致。

可传承。 你总结的提示词最佳实践可以分享给团队，不用每个人自己摸索。

可迭代。 某次发现某类需求 AI 输出质量不对，打开 Skill 文件改一下规则，下次就修复了。

---

三、MCP（Model Context Protocol）

这个词最容易吓人

MCP 是 Anthropic 在 2024 年底提出的一套开放协议，全称 Model Context Protocol。听起来很技术，但核心只有一件事：让 AI 能安全、标准化地使用外部工具和数据。

继续用助理比喻：提示词和 Skill 解决的是"你怎么说"和"说什么规范"，MCP 解决的是"他能用什么工具"。

你交代助理帮你查一下飞书文档里的会议纪要，他能不能查，取决于你有没有给他飞书的访问权限，以及这个访问权限是通过什么通道给的。MCP 就是这个"通道标准"——它定义了 AI 怎么连接外部系统、怎么调用工具、怎么读写数据。

MCP 能接的工具举几个例子

工具类型	实际例子
文件系统	读写本地文件、创建目录
数据库	查询 MySQL、PostgreSQL
协同工具	飞书文档、飞书日历、Notion
代码平台	GitHub、TAPD
搜索	网页搜索、内部知识库检索
自定义接口	企业内部的任何 API

有了 MCP，AI 不再只是"聊天工具"，而是真的能帮你做事——查数据库、写文档、创建任务、发消息。不是你把信息复制进对话框，而是 AI 直接拿数据源里的内容来工作。

对测试工程师意味着什么

以前你用 AI 分析 Bug，得自己把 TAPD 上的 Bug 列表复制出来粘贴进去，输出的结果再自己抄回去。有了 MCP 接入 TAPD，AI 可以直接读取 Bug 数据，分析完之后直接写回系统，整个流程不需要人工中转。

这不是概念，WorkBuddy 里的 TAPD 连接器就是基于 MCP 协议实现的。

---

四、Agent（智能体）

这个词被用烂了，但核心不复杂

Agent 的本质是：AI 从"回答问题"变成"完成任务"。

正常的 AI 交互是一问一答—你说一句，它回一句。每次都需要你推进。

Agent 不同。你给它一个目标（"帮我整理本周所有 Bug，写成周报发给测试组长"），它自己拆分步骤、调用工具、处理中间结果，直到任务完成。整个过程你不需要在旁边盯着，它自己推进。

用助理比喻：普通 AI 是接线员，你告诉他什么，他做什么；Agent 是项目经理，你说"这个事情帮我搞定"，他自己协调资源、安排步骤、把结果交回来。

Agent 的核心能力构成

一个完整的 Agent 需要四个组件：

感知—读取输入。不只是文字，可以是图片、文件、数据库记录、API 返回结果。

推理—拆解任务，规划步骤，判断当前该做什么。这是 LLM 的核心能力。

行动—调用工具执行。这里就用到 MCP 了——没有工具接入，Agent 只能说，不能做。

记忆—短期记忆（当前对话上下文）和长期记忆（存到数据库或文件里，下次还能用）。

这四个能力缺一个，Agent 的自主性就会打折。一个没有工具的 Agent 只能输出文字；一个没有记忆的 Agent 每次都从头开始；一个推理能力差的 Agent 容易走偏执行错误步骤。

真实场景

以 Hermes Agent 为例—这是一个 UI 自动化测试 Agent。你告诉它"测试登录页面的错误提示文案是否正确"，它会自己：

1. 打开浏览器，导航到登录页

2. 输入错误的用户名密码

3. 截图，识别错误提示文案

4. 对比预期文案，判断是否通过

5. 输出测试结果，如果失败自动记录 Bug 截图

你不需要写一行 Selenium 代码，不需要维护定位器，Agent 自己完成了完整的测试执行。

---

五、四者之间的关系

搞清楚概念之后，来看它们怎么配合工作。

层级	是什么	解决什么问题	类比
提示词	你给 AI 的指令	精准传递意图	口头交代
Skill	固化的提示词最佳实践	可复用的工作规范	SOP 手册
MCP	AI 连接外部工具的协议	打通数据和操作权限	工具箱 + 权限卡
Agent	能自主规划执行的 AI	完成多步任务，不需人工推进	项目经理

它们不是互相替代的关系，而是分层叠加的关系：

没有好提示词，Skill 写不好

Skill 是对提示词工程的沉淀和复用

Agent 要自主做事，必须借助 MCP 提供的工具

Agent 的每一步推理，底层依然在执行提示词

换句话说：提示词是地基，Skill 更像房屋里的家用电器或专用工具，MCP 是水电煤气管网，Agent 既是使用工具的人，也是规划结构的决策者。 

---

六、对测试工程师的实际影响

讲了这么多，落到我们的日常工作里，变化在哪里？

写测试点：以前手动拆。现在用 test-requirement-analysis Skill，传入需求文档，自动按 8 个维度输出测试点，带优先级和风险等级。

查 Bug 数据：以前从 TAPD 导出 Excel，粘贴进对话框。现在通过 MCP 连接 TAPD，AI 直接读数据，输出 Bug 周报。

写自动化脚本：以前自己写 Selenium 定位器和断言。现在描述测试场景，Agent 自动生成可执行脚本，有的甚至能直接跑起来。

整理测试报告：以前填表格、汇总数字。现在触发 test-report-writer Skill，输入测试执行数据，自动生成带受众视图的测试报告。

这四个能力不是独立的，实际工作里往往是叠加使用的：一个 Agent 借助 MCP 读取数据，按照 Skill 定义的流程处理，每一步的推理里都在执行精心设计的提示词。

能把这四个东西用起来的测试工程师，和还在手工做这些事的人，效率差距是显而易见的。

如果你也在探索 AI 辅助测试，点击关注，持续分享实战案例。