以下最佳实践可以帮助您构建强大的代理应用。
简洁的目标
目标应该是对代理目的的简要说明。
提供质量说明
说明应：
- 体现解决最终用户问题的分步方法
- 是简明扼要的自然语言语句，其中包含高级指令
- 简单明了，并指定工具使用场景
每个代理至少有一个示例
每个代理都应至少有一个示例，但建议至少具有四个。 示例应包含满意路径场景。
如果没有足够多的示例，代理可能会导致不可预测的行为。如果代理未按预期响应或行为，则可能是缺少示例或定义不清楚的原因。请尝试改进您的示例或添加新的示例。
说明和示例的精确度
虽然写出清晰的描述性说明说明很有帮助，但实际上，您的样本的质量和数量决定了代理行为的准确性。 换言之，要花更多时间编写详尽的示例，而不是编写完美的指令。
工具架构 operationId 字段
为工具定义架构时，operationId 值非常重要。您的代理说明将引用此值。
以下是有关此字段的命名建议：
- 只能包含字母、数字和下划线。
- 在架构中所述的所有
operationId中必须是唯一的。 - 必须是能够反映所提供功能的有意义名称。
工具架构验证
您应验证您的工具架构。 您可以使用 Swagger 编辑器检查 openAPI 3.0 架构语法。
处理空的工具结果
如果您的代理依赖于某个工具作为响应，那么空的工具结果可能会导致不可预测的代理行为。有时，代理 LLM 会在回答中产生幻觉，而不是工具结果。为防止出现这种情况，您可以添加具体说明，以确保代理 LLM 不会尝试自行回答。
某些用例要求代理响应以工具结果或提供的数据为基础，并且仅需要根据代理 LLM 的知识来减少响应。
减少幻觉的说明示例：
- “您必须使用该工具回答用户的所有问题”
- “如果未从该工具获得任何数据，请回答您不知道用户查询的答案”
- “如果工具中没有返回任何数据，请不要编造答案”
使用 Gemini 生成架构
Gemini 可以为您生成架构。例如，尝试“可以为 Google 日历创建示例 openAPI 3.0 架构吗”。
专注客服人员
避免创建非常大型和复杂的代理。 每个代理都应完成明确具体的任务。 如果您的代理较为复杂，可考虑将其拆分为多个较小的分代理。
避免循环和递归
在说明中关联代理应用时，请勿创建循环或递归。