几种常用的Agent的Prompt格式

一、基础框架范式（Google推荐标准）

1. 角色与职能定义

<Role_Definition>
你是“项目专家”（Project Pro），作为家居园艺零售商的首席AI助手，专注于家装改造领域。你的核心使命：
1. 协助客户精准选购商品
2. 解决园艺技术问题
3. 安排安装服务
4. 优先使用工具获取实时数据（非依赖内部知识库）
</Role_Definition>

关键要素：身份定位、核心目标、能力边界、工具使用优先级

2. 上下文注入

<Context>
用户档案：
- 年龄：32岁
- 国籍：中国
- 偏好：极简风格/预算敏感
<Data>
近期热销商品：智能灌溉系统（销量增长40%）
</Data>
</Context>

作用：提供个性化服务依据，减少幻觉

3. 任务执行流程（COT思维链）

<Execution_Steps>
1. 调用商品检索工具，获取符合用户需求的商品清单
2. 使用比价工具分析价格趋势
3. 进入<折扣计算>模块申请优惠
4. 生成Markdown格式的购买方案
</Execution_Steps>

设计技巧：

• 单步骤只做一件事
• 明确工具调用顺序
• 嵌入子模块（如<折扣计算>）

4. 输出规范（含示例）

<Output_Format>
| 商品名称 | 价格 | 折扣 | 推荐指数 |
|----------|------|------|----------|
| 智能花盆 | ¥299 | 8折  | ★★★★☆    |
---END-OF-RESPONSE---

强制要求：结构化数据 + 终止标识符

5. 硬性约束条款

<Constraints>
- 绝对不承诺库存数量
- 折扣幅度严禁超过15%
- 不确定时必须声明“需要进一步确认”
</Constraints>

二、进阶设计框架

1. CO-STAR框架（政府级标准）

2. 结构化模块设计

# 输入信息区
<Input>
用户问题：{query}
历史记录：{chat_history}
</Input>

# 工具调用区
<Tools>
- product_search(品牌, 价格区间): 返回商品列表
- discount_calculator(原价, 会员等级): 计算折扣
</Tools>

# 流程控制区
<Workflow>
1. 识别用户意图 → 2. 调用工具 → 3. 验证结果 → 4. 格式化输出
</Workflow>

工程优势：模块解耦、便于迭代调试

三、关键设计技巧

1. 工具调用规范

   • 每个工具需提供清晰示例：

     approve_discount(type:str, value:float, reason:str) 
     # 示例：approve_discount("seasonal", 0.1, "节假日促销")

   • 参数强制校验：严禁捏造未提供参数

2. 防幻觉机制

   • 设置否定性指令：

     <Anti-Hallucination>
     - 禁止推荐库存未知的商品
     - 无法确认的信息必须声明“根据现有数据无法回答”
     </Anti-Hallucination>

3. 多智能体协作

   <Multi-Agent>
   1. 请求[质检Agent]分析商品质量报告
   2. 移交[物流Agent]计算配送时间
   3. 汇总结果至[报告生成Agent]
   </Multi-Agent>

四、避坑指南

1. 示例数量控制

   • 最佳实践：3-5个典型示例
   • 过多导致模型机械复制，过少降低准确性

2. 动态工作流设计

   <Dynamic_Flow>
   IF 用户需要比价 THEN 激活[比价模块]
   ELIF 需要安装服务 THEN 调用[服务预约工具]
   </Dynamic_Flow>

3. 版本迭代建议

   • 采用控制变量法调整Prompt
   • 每次只修改单个模块并记录效果变化

工业级提示：对复杂任务（如客户投诉处理），必须设计反思环节 ：

<Reflection>
1. 检查方案是否满足所有约束条件
2. 验证工具返回数据的时效性
3. 生成备选方案（至少2个）
</Reflection>

权威学习资源

1. Google Prompt工程白皮书（含中文译本）
2. 微软CoT设计指南：Chain-of-Thought Prompting
3. 多智能体框架：CAMEL: Communicative Agents

注：以上框架需结合具体场景调整，电商推荐场景建议优先采用Google范式+COSTAR组合，客服场景推荐动态工作流+反思机制。实际部署时，建议通过A/B测试验证不同模块效果（如工具调用示例数量对准确率的影响）。