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