以下最佳实践有助于构建强大的代理应用。
自然语言的代理名称
使用能清楚说明代理名称的自然语言。例如，“Customer Help Center Agent”比“company_specialist”更具描述性，这有助于提高 LLM 在运行时的性能。
简洁的目标
目标应该是对客服人员目的的简要描述。
提供质量说明
相关说明应：
- 反映解决最终用户问题的分步方法
- 是包含简略说明的简洁自然语言语句
- 直截了当，指明工具使用场景
每个代理至少有一个示例
每个代理应该至少有一个示例，但建议至少有四个示例。示例应包括满意的路径场景。
如果没有足够的示例，代理可能会导致不可预测的行为。如果代理没有响应或行为符合您的预期，则缺少示例或定义不当的示例可能是导致错误的原因。请尝试改进示例或添加新示例。
说明和示例的准确性
虽然写出清晰的描述性说明有帮助，但真正能决定代理行为的准确性是由示例的数量和质量决定的。换言之，与编写非常精确的指令相比，要花更多的时间来编写详尽的示例。
示例中的参考工具
如果代理旨在使用工具提供响应，请在与此类请求对应的示例中引用工具。
工具架构 operationId 字段
在为工具定义架构时，operationId 值非常重要。您的代理说明将引用此值。
以下是对此字段的命名建议：
- 只能包含字母、数字和下划线。
- 在架构中描述的所有
operationId中必须是唯一的。 - 必须是反映所提供功能的有意义的名称。
工具架构验证
您应验证工具架构。 您可以使用 Swagger Editor 检查 OpenAPI 3.0 架构语法。
处理空的工具结果
当代理依靠工具来为其响应提供信息时，空的工具结果可能会导致代理行为不可预测。有时，代理 LLM 会在响应中提供信息，而不是工具结果。为防止出现这种情况，您可以添加具体说明，以确保代理 LLM 不会尝试自行回答。
某些使用场景要求代理响应基于工具结果或提供的数据，并且需要仅根据代理 LLM 的知识来减少响应。
关于如何减少幻觉的说明示例：
- "您必须使用该工具回答所有用户问题"
- “如果您未从该工具获得任何数据，请回复您不知道用户查询的答案”
- “如果未从该工具获得任何数据，请不要编造答案”
使用 Gemini 生成架构
Gemini 可以为您生成架构。 例如，请尝试“您可以为 Google 日历创建一个示例 OpenAPI 3.0 架构吗”。
专注客服人员
避免创建庞大而复杂的代理。 每个客服人员都应完成具体且明确的任务。 如果您的代理比较复杂，请考虑将其分解为多个较小的分代理。
避免循环和递归
在说明中关联代理应用时，不要创建循环或递归。
向示例提供路由信息
当一个代理应路由至另一个代理时，您应向示例提供此信息。 这是输入和输出示例部分中 End example with output information（包含输出信息结束示例）字段中的示例。
例如，此字段的最终句子可以是“将路由回默认代理以执行进一步查询”。
使用 Dialogflow CX Messenger JavaScript 函数实现个性化
使用 Dialogflow CX Messenger 时，以下函数有助于将用户个性化信息从网页界面发送给代理：