跳到主要内容

第 1.5.3 节：把 Prompt、能力清单和 Mock/真实双模式串起来

本节围绕“把 Prompt、能力清单和 Mock/真实双模式串起来”展开，先建立直观判断，再进入工程细节。完成本节后，你应该能够说清 Prompt、能力清单与双模式的处理顺序、关键检查点和失败处理。

实现步骤或决策流程​

客服工作台最小切片如何落地​

本章的落地方式是把完整客服工作台先缩成一个“分流台”。分流台不替用户办完所有事，但必须稳定决定下一步。

落地步骤产出物为什么必要
1典型问题集覆盖产品咨询、订单查询、退款、投诉、缺信息和超范围问题。
2输入字段契约统一 user_message（用户消息）、session_id（会话编号）、trace_id（追踪编号）和业务上下文。
3输出字段契约统一 intent（意图）、risk_level（风险等级）、missing_fields（缺失字段）和 next_action（下一步动作）。
4Mock（模拟）规则没有真实模型时也能验证流程和字段。
5真实模型模式验证自然语言理解效果，但必须经过同一份校验。
6状态日志记录每次判断、错误和停止原因，方便复盘。
7失败兜底输出无效、信息不足、高风险、模型失败时进入安全路径。

这个切片做稳以后，第 1.6 章只需要把 next_action（下一步动作） 中的工具意图接到受控工具层，而不是重新设计入口。

推荐技术流​

步骤做什么为什么
1确定最小业务目标防止第一个项目范围失控。
2列出典型客服问题覆盖咨询、订单、退款、投诉、缺信息和超范围问题。
3设计输入字段让系统知道用户、会话和问题来源。
4设计输出字段让模型结果能驱动后续流程。
5编写 Prompt（提示词）结构把角色、任务、边界和输出契约说清楚。
6准备 Mock（模拟）规则没有真实模型也能验证流程。
7接入真实模型模式验证真实语言理解效果。
8校验输出字段防止无效结果进入业务流程。
9记录状态和日志保证问题可追踪、可复盘。
10用验收样例测试证明系统能处理典型问题和失败情况。

这条技术流的核心理由是：第一个 Agent（智能体）要先证明“流程可靠”，再追求“功能丰富”。

项目边界​

本章提供：

  • 项目目标。
  • 业务流程。
  • 输入输出字段契约。
  • Prompt 结构。
  • Mock（模拟）模式和 Real Provider（真实模型供应商）模式设计。
  • 状态、日志和停止条件。
  • 失败兜底和验收标准。

本章不提供：

  • 可直接复制部署的完整项目实现。
  • 真实订单系统接口。
  • 真实工单系统接口。
  • 真实退款审批实现。
  • 编程语法教学。

这个边界不是偷懒，而是为了让读者先把 Agent 工程骨架理解清楚。

输入字段契约​

字段说明客服工作台示例验收要求
trace_id（追踪编号）一次请求的唯一追踪标识本次售后咨询编号日志、输出和错误都能串起来。
session_id（会话编号）多轮对话编号同一用户连续咨询能把追问和补充信息归到同一会话。
user_id（用户编号）当前用户身份登录用户或访客编号不能用用户口头输入替代系统身份。
user_message（用户消息）用户本次输入我买的设备用了两天就坏了必填，不能空。
channel（渠道）用户来自哪里网站、App（应用程序）、企业微信影响回复方式和转人工方式。
prior_summary（历史摘要）当前会话已有摘要用户已提供商品名，未提供订单号控制上下文长度。
business_context（业务上下文）已知业务信息售后入口、产品线、地区不能包含用户无权访问的信息。

输出字段契约​

字段说明推荐取值验收要求
intent（意图）用户问题类型product_question、order_status、refund_request、complaint、unknown能驱动下一步动作。
risk_level（风险等级）风险高低low、medium、high投诉、退款和隐私默认不能低估。
need_human（是否需要人工）是否转人工true 或 false高风险场景必须可转人工。
missing_fields（缺失字段）还缺什么信息order_id、product_name、contact_info缺信息时不调用真实工具。
next_action（下一步动作）系统建议动作answer、ask_followup、search_knowledge、call_tool、create_ticket、handoff第 1.6 章会重点使用 call_tool。
reply（回复草稿）给用户看的回复安抚、说明边界、追问信息不承诺退款，不编造订单状态。
confidence（置信度）判断可信程度high、medium、low低置信度时保守处理。
stop_reason（停止原因）本轮为什么结束valid_result、need_info、handoff、invalid_output方便复盘。

能力清单​

本章暂时不执行真实业务工具，只设计最小能力清单。

能力类型作用风险是否执行真实外部动作
客服问题分类模型理解能力判断用户意图中否
风险分级规则与模型结合判断是否涉及投诉、退款、隐私或合规中高否
缺失字段识别结构化输出能力判断是否需要订单号、商品名、联系方式中否
知识库检索意图工具调用准备标记后续是否需要 RAG（检索增强生成）中否
工单草稿建议写入前准备生成创建工单前的信息摘要中高否，只生成草稿
转人工判断安全兜底能力把高风险或低置信度问题交给人工中高否，只输出建议

真正的查订单、查售后政策、创建工单和发起退款审批，会在第 1.6 章作为工具调用展开。

Prompt（提示词）结构​

本章的 Prompt 只需要表达 5 件事：

模块要写清什么
角色你是企业客服问题分流 Agent。
任务根据用户问题判断意图、风险、缺失字段和下一步动作。
边界不承诺退款，不编造订单，不直接执行外部动作，高风险问题要转人工。
上下文用户问题、会话摘要、业务入口和可用下一步动作。
输出契约必须返回本章定义的稳定字段，供系统校验。

Prompt 的目标不是让模型“说得像客服”，而是让模型的结果能进入后端流程。

Mock（模拟）模式设计​

Mock（模拟）模式用于无密钥学习、自动化验证和页面演示。它不调用真实模型，而是按固定规则返回分流结果。

输入特征Mock（模拟）返回口径
包含“投诉”“没人回”“曝光”等表达risk_level（风险等级）为 high，need_human（是否需要人工）为 true。
包含“退款”“退货”intent（意图）为 refund_request，missing_fields（缺失字段）至少检查 order_id（订单号）。
包含“发货”“物流”“订单”intent（意图）为 order_status，next_action（下一步动作）为 call_tool。
包含产品咨询next_action（下一步动作）为 search_knowledge。
无法判断intent（意图）为 unknown，next_action（下一步动作）为 ask_followup。

Mock（模拟）模式不是为了伪装智能，而是为了保证流程稳定。

Real Provider（真实模型供应商）模式设计​

真实模型模式在本章只说明实现要求：

  • 通过环境变量读取模型供应商配置。
  • 保护 API Key（接口密钥），不写入文档、截图、日志和仓库。
  • 传入 Prompt、用户问题、会话摘要和输出契约。
  • 校验模型输出是否符合字段契约。
  • 输出无效时重试或降级。
配置项含义说明
APP_MODE（应用运行模式）mock 或 real控制是否调用真实模型。
MODEL_PROVIDER（模型供应商）openai、deepseek、qwen 等只保存供应商名称。
MODEL_NAME（模型名称）具体模型名称可按任务切换。
API_KEY（接口密钥）真实调用凭据只放安全配置，不写进书稿。

停止条件​

客服问题分流 Agent 必须在这些情况下停止：

  • 已生成有效结构化结果。
  • 用户缺少订单号、商品名等必要信息，需要追问。
  • 风险过高，需要转人工。
  • 输出校验连续失败。
  • 用户问题超出客服工作台范围。
  • 模型或供应商异常，系统进入降级。

停止条件让 Agent 保持可控，也让成本和风险有边界。

和第 1.6 章的连接​

第 1.6 章会接住本章的 next_action（下一步动作）。

本章输出第 1.6 章处理
search_knowledge（检索知识）后续接入 RAG 知识库。
call_tool（调用工具）判断应该查订单、查物流还是查售后政策。
create_ticket（创建工单）设计工单工具字段、权限和幂等。
handoff（转人工）进入人工客服或审批流程。
ask_followup（追问）回到会话状态，等待用户补充信息。

没有第 1.5 章的分流结果，第 1.6 章的工具调用就缺少入口判断。

版本与资料来源​

本书不承诺提供可直接复制部署的完整项目实现，配套项目以制作方法、模块边界、字段契约和验收标准呈现。

过时风险：Agent SDK（软件开发工具包）和工具调用接口会持续变化。进入项目实现前必须重新核对官方文档。

继续学习​