以下最佳实践可帮助您构建强大的代理。
自然语言中的 Playbook 名称
使用具有明确含义的自然语言为 Playbook 命名。例如，“客户帮助中心手册”比“company_specialist”更具描述性，这有助于提高 LLM 在运行时的性能。
简洁的目标
目标应简要说明 Playbook 的用途。
提供优质的说明
说明应：
- 反映解决最终用户问题的分步方法
- 是简洁的自然语言句子，用于提供高级别的说明
- 简单明了，并指定工具的使用场景
每个 Playbook 至少包含一个示例
每个 Playbook 都应至少有一个示例，但建议至少有四个。示例应包含正常路径场景。
如果没有足够的示例，则剧本可能会导致不可预测的行为。如果您的 Playbook 未按预期响应或行为，可能是因为缺少示例或示例定义不当。尝试改进示例或添加新示例。
说明和示例的精确性
虽然编写清晰且描述性强的说明很有帮助，但实际上，示例的质量和数量才决定了 Playbook 行为的准确性。换句话说，花更多时间编写详尽的示例，而不是花时间编写完全精确的说明。
在示例中引用工具
如果该手册旨在通过使用工具提供回复，请在与此类请求对应的示例中引用这些工具。
工具架构 operationId 字段
为工具定义架构时，operationId 值非常重要。您的手册说明将引用此值。以下是此字段的命名建议：
- 只能使用字母、数字和下划线。
- 在架构中描述的所有
operationId中必须是唯一的。 - 必须是反映所提供功能的具有意义的名称。
工具架构验证
您应验证工具架构。您可以使用 Swagger 编辑器检查 OpenAPI 3.0 架构语法。
处理空工具结果
如果您的 Playbook 依赖于某个工具来确定其响应，空的工具结果可能会导致 Playbook 行为不可预测。有时，Playbook LLM 会在回答中幻想出信息，以替代工具结果。为防止这种情况，您可以添加特定说明，以确保 Playbook LLM 不会尝试自行回答。
在某些用例中，playbook 回答需要基于工具结果或提供的数据进行充分的推理，并且需要仅根据 playbook LLM 的知识来缓解回答。
减少幻觉的说明示例：
- “您必须使用该工具回答所有用户问题”
- “如果您没有从该工具收到任何数据，请回复您不知道用户询问问题的答案”
- “如果工具没有返回任何数据，请勿杜撰回答”
使用 Gemini 生成架构
Gemini 可以为您生成架构。例如，尝试输入“您能否为 Google 日历创建一个 OpenAPI 3.0 架构示例”。
专注型 Playbook
避免创建非常大且复杂的 Playbook。每个 Playbook 都应完成一项明确的特定任务。 如果您的 Playbook 较为复杂，不妨考虑将其拆分为较小的子 Playbook。
避免使用循环和递归
在指令中关联代理时，请勿创建循环或递归。
为示例提供路由信息
当某个 Playbook 应路由到另一个 Playbook 时，您应向示例提供此信息。此示例来自输入和输出示例部分的包含输出信息的结尾示例字段。
例如，此字段的最后一句可以是“重定向回默认的 Playbook 以进行进一步查询”。
使用 Conversational Agents (Dialogflow CX) Messenger JavaScript 函数进行个性化设置
使用 Conversational Agents (Dialogflow CX) Messenger 时，以下函数可用于将用户个性化信息从网页界面发送到 Playbook：