大数据

提示词工程、skill以及agent三者的关系

Posted by 蓝染君

2026年7月13日

On 2026年7月13日

关于提示词工程和skill以及agent我现在分不太清楚，尤其是如何工程化的编写。我初步的理解是，使用自然语言写伪代码的形式写提示词，但是要求提示词描述清楚业务需求以及注意事项

一、先分清三个概念

用一个比喻：

提示词 (Prompt) = 一张任务便签，告诉模型“你现在要做什么，注意什么”。
Skill (技能) = 一个封装好的工具箱，里面包含一张高级便签（系统提示词） + 可能绑定的 API / 知识库 / 代码片段，专门完成某类任务。
Agent (智能体) = 一个能自己动手的机器人，它会读便签，然后自主决定调用哪个 Skill、查询什么工具、分几步完成，并且会反思和纠错。

三者关系是：
Skill 依赖高质量的提示词来实现功能；Agent 把 Skill 当作自己的“手和脚”来调用，并用提示词作为自己的“大脑”。

二、如何工程化地编写？

你提到“用自然语言写伪代码的形式写提示词”，这其实已经是工程化的核心思路之一。下面我分开讲，并给出可直接套用的结构。

1. 提示词的工程化写法：结构化的“任务说明书”

不要把提示词写成散文，要像写函数文档一样，有明确的区块和约束。推荐使用 Markdown + 分隔符，例如：

## 角色
你是一个电商客服专家，只处理退换货问题。

## 任务
根据用户输入，判断其退换货意图，并生成对应的处理建议。

## 业务流程（非常重要）
1. 先确认订单是否在7天无理由退货期内。
2. 若用户未提供订单号，必须先索要订单号，不要直接给建议。
3. 仅当获得有效订单号且通过系统查询（此处模拟）后，才能输出最终方案。

## 输出格式
必须严格按 JSON 返回，不要包含其他文字：
{
  "intent": "退货" | "换货" | "未知",
  "next_step": "索要订单号" | "给出退货地址" | "转人工",
  "reply": "回复用户的自然语言"
}

## 注意事项（边界条件）
- 不要承诺赔偿金额。
- 如果用户辱骂，统一回复：“很抱歉给您带来不便，我会尽力帮您解决。”
- 商品属于生鲜类目的，一律告知不支持退货。

## 角色
你是一个电商客服专家，只处理退换货问题。

## 任务
根据用户输入，判断其退换货意图，并生成对应的处理建议。

## 业务流程（非常重要）
1. 先确认订单是否在7天无理由退货期内。
2. 若用户未提供订单号，必须先索要订单号，不要直接给建议。
3. 仅当获得有效订单号且通过系统查询（此处模拟）后，才能输出最终方案。

## 输出格式
必须严格按 JSON 返回，不要包含其他文字：
{
  "intent": "退货" | "换货" | "未知",
  "next_step": "索要订单号" | "给出退货地址" | "转人工",
  "reply": "回复用户的自然语言"
}

## 注意事项（边界条件）
- 不要承诺赔偿金额。
- 如果用户辱骂，统一回复：“很抱歉给您带来不便，我会尽力帮您解决。”
- 商品属于生鲜类目的，一律告知不支持退货。

工程化要点：

角色、任务、流程、格式、边界，五大块缺一不可。
业务流程用编号列表，就是“自然语言伪代码”。
输出格式用 JSON / XML 强制模型结构化返回，方便程序解析。
注意事项专门列出反面案例、禁止行为、极端情况。

2. Skill 的工程化：封装成可复用的“函数”

Skill 不只是个提示词，它是 提示词 + 输入输出规范 + 工具接口 的集合。工程化思路是把它设计得像一个微服务。

一个 Skill 的定义卡片（以Dify/Coze等平台为例，手工设计同理）：

Skill名称: 退换货意图处理
Skill描述: 根据用户消息判断退换货意图，生成符合政策的回复。供客服Agent调用。
输入参数:
  - user_message (string, 必填) : 用户的原始消息
  - order_info (object, 可选)  : {order_id, product_category, days_since_delivery}
输出格式:
  {
    "intent": "退货",
    "reply": "...",
    "action": "create_return"
  }

System Prompt: (上述提示词完整粘贴，并增加占位符{{user_message}}, {{order_info}})

工具绑定:
  - 订单查询API: get_order_detail(order_id)  // 在Skill内部可调用

Skill名称: 退换货意图处理
Skill描述: 根据用户消息判断退换货意图，生成符合政策的回复。供客服Agent调用。
输入参数:
  - user_message (string, 必填) : 用户的原始消息
  - order_info (object, 可选)  : {order_id, product_category, days_since_delivery}
输出格式:
  {
    "intent": "退货",
    "reply": "...",
    "action": "create_return"
  }

System Prompt: (上述提示词完整粘贴，并增加占位符{{user_message}}, {{order_info}})

工具绑定:
  - 订单查询API: get_order_detail(order_id)  // 在Skill内部可调用

当 Agent 调用这个 Skill 时，它只需要传入参数，Skill 内部会执行完整的提示词推理 + 可能调用订单查询API，最后返回结构化结果。

这样做的好处： Skill 可单独测试、可替换、可组合。

3. Agent 的工程化：写“大脑”的决策指令

Agent 的提示词需要告诉它：你是谁，你有哪些工具/Skill，如何规划任务，什么情况下停下来。这仍然是用自然语言写伪代码。

一个客服 Agent 的核心提示词骨架（ReAct模式）：

你是客服智能体，拥有以下技能：
- 退换货意图处理：判断退换货意图，生成回复。
- 订单查询：根据订单号获取订单详情。
- 人工转接：将对话转给真人。

## 决策逻辑（伪代码）
循环执行直到问题解决：
  1. 理解用户最新消息。
  2. 判断当前状态：缺少订单号？需要查订单？可以直接回复？
  3. 如果缺少必要信息（如订单号），直接向用户询问。
  4. 如果信息足够，调用对应 Skill，获得回复。
  5. 如果 Skill 返回 "转人工"，则调用人工转接并结束。
  6. 如果连续3轮无法解决，也转人工。

## 输出格式
每次行动必须用以下结构：
{
  "thought": "分析当前状态和决策理由",
  "action": "调用技能名或 ask_user",
  "action_input": "参数"
}

你是客服智能体，拥有以下技能：
- 退换货意图处理：判断退换货意图，生成回复。
- 订单查询：根据订单号获取订单详情。
- 人工转接：将对话转给真人。

## 决策逻辑（伪代码）
循环执行直到问题解决：
  1. 理解用户最新消息。
  2. 判断当前状态：缺少订单号？需要查订单？可以直接回复？
  3. 如果缺少必要信息（如订单号），直接向用户询问。
  4. 如果信息足够，调用对应 Skill，获得回复。
  5. 如果 Skill 返回 "转人工"，则调用人工转接并结束。
  6. 如果连续3轮无法解决，也转人工。

## 输出格式
每次行动必须用以下结构：
{
  "thought": "分析当前状态和决策理由",
  "action": "调用技能名或 ask_user",
  "action_input": "参数"
}

这个 Agent 提示词本身就是用自然语言描述的算法流程。 它保证了 Agent 行为有章可循，而不是放任模型自由发挥。

三、你的理解是否正确？

“使用自然语言写伪代码的形式写提示词，但是要求提示词描述清楚业务需求以及注意事项”

完全正确，这就是提示词工程化的本质。
所谓“伪代码”不是写 if-else 语法，而是用结构化的自然语言描述执行流程。比如上面的“决策逻辑”部分。

进一步，Skill 和 Agent 只是在这个基础上，把这种“自然语言伪代码”组织成了更大的可运行模块。

工程化的核心就三点：

结构化（分区块，用标题、列表、分隔符）
业务需求翻译成步骤和约束（禁止散文，要可执行）
留出“接口”（用变量、输入输出格式，让程序可以拼接和调用）

文章