共计 1859 个字符，预计需要花费 5 分钟才能阅读完成。
为什么需要结构化提示词？
最近在做一个电商客服 Agent 时，遇到过这些典型问题：
- 指令冲突 ：当用户同时询问 ” 退货政策 ” 和 ” 物流时效 ” 时，Agent 只会回答最后一个识别到的问题
- 上下文丢失 ：用户前一句说 ” 我想退昨天买的衣服 ”，后一句问 ” 需要什么材料？”，Agent 要求用户重新说明退货商品
- 意外越界 ：用户问 ” 怎么黑进卖家账户 ” 时，Agent 竟然分步骤讲解技术原理（危险！）
这些问题的本质，都是因为使用了纯自然语言编写的非结构化提示词。就像没有 SQL 语法前的数据库查询，每次交互都像在抛硬币。
结构化提示词的三根支柱
1. 上下文锚点（Context Anchors）
在对话中埋入隐形书签：
{
"context": {
"last_product": "女士羊毛大衣", # 自动记录最近提及的商品
"pending_actions": ["退货申请"] # 跟踪进行中的流程
}
}2. 指令分层（Instruction Layering）
把提示词拆成不同功能模块：
- 系统层 ：定义 Agent 的基础行为准则（永远不提供黑客技术指导）
- 领域层 ：电商场景特有的处理逻辑（退货流程 > 普通咨询）
- 会话层 ：当前对话的临时状态（用户正在上传凭证图片）
3. 参数约束（Parameter Constraints）
用 JSON Schema 定义输入输出：
{
"response_format": {
"type": "object",
"properties": {"answer": {"type": "string", "maxLength": 500},
"follow_up_questions": {"type": "array", "items": {"type": "string"}}
},
"required": ["answer"]
}
}结构化方案选型指南
| 方案类型 | 适合场景 | 示例工具 |
|---|---|---|
| JSON | 简单业务逻辑 +API 交互 | OpenAI Function Calling |
| YAML | 需要人工维护的复杂规则 | AutoGPT 配置文件 |
| DSL | 领域专用语言（如客服流程） | Rasa Rules |
电商客服 Agent 实战示例
def generate_prompt(context):
"""
生成结构化客服提示词
:param context: 包含用户历史、会话状态等
:return: 符合 ChatGPT 格式的提示字典
"""base_rules ="""
# 安全规则
- 禁止讨论任何违法操作
- 敏感词触发时回复："这个问题涉及安全策略，无法解答"
# 业务规则
- 优先处理退货 / 退款类问题
- 商品型号需明确到具体 SKU
"""prompt = {"system": base_rules,"user_context": {"last_mentioned_items": context.get("products", []),"current_service_type": context["service_type"] # 售前 / 售后
},
"response_constraints": {
"max_length": 300,
"must_include": ["问候语", "解决方案"],
"disallowed_phrases": ["不确定", "可能"]
}
}
return prompt性能优化双刃剑
Token 消耗计算公式
总 Token =
基础提示 Token
+ 每轮对话新增 Token * 0.3（压缩率）+ 上下文记忆 Token * 轮次 ^1.2优化策略：
- 对超过 5 轮的对话，自动摘要前 3 轮内容
- 使用 MD5 哈希值比对重复问题
- 高频问题缓存标准答案
状态维护技巧
- 短期记忆 ：保留最近 2 轮对话原始文本
- 长期记忆 ：用向量数据库存储关键决策点
- 瞬时记忆 ：当前操作步骤状态（如 ” 正在等待用户上传凭证 ”）
生产环境血泪教训
敏感词过滤的坑
- 误杀 ：” 如何破解使用难题 ” 被屏蔽（含 ” 破解 ”）
- 漏杀 ：” 教我 bypass 商家审核 ” 中的拼写变形
解决方案：
- 使用相似度匹配而非关键词
- 建立白名单机制（如 ” 破解 ” 在 ” 技术难题 ” 上下文允许）
版本管理方案
prompts/
├── v1.0
│ ├── main_prompt.json
│ └── safety_rules.yaml
├── v1.1-hotfix
│ └── refund_flow.patch
└── current -> v1.1-hotfix每次更新必须：
- 保留完整历史版本
- 通过 AB 测试验证效果
- 记录修改人 + 时间戳
终极思考题
当你的提示词模板膨胀到 2000 个 Token 时：
- 是拆分成多个专用 Agent（增加维护成本）？
- 还是接受更长的响应延迟（影响用户体验）？
我在实际项目中发现，当响应时间超过 1.5 秒时，用户满意度会下降 37%。你们是怎么平衡这个问题的？
正文完
