对话式界面，而非应用界面
RBM 代理非常适合用于为用户提供高效且具体的任务 在对话界面中呈现设计出色的代理可确保互动始终如一 重点突出、清晰易懂、条理分明，像是自然的对话。
代理不能依赖应用或网页的视觉界面， 也不要试图模仿相反，客服人员需要 旨在解决用户通过口头提示来引导他们， 以及良好的错误处理能力。
此外，代理也不得模仿电话树或依赖用户的界面。 以表示指定操作的数字响应。用户应该能够 自然地与智能体通信，就像他们 会话中的其他人员。
如需详细了解对话式界面，请参阅对话式界面及其原因 至关重要。
检查设备的功能
在发起与用户对话之前，请确认 设备可以接收 RCS 信息。发送 功能请求 以确定设备的功能，并定制代理的互动方式 。仅以用户设备支持的方式与其互动。如果 用户的设备未启用 RCS，请设置后备通信方法 另一种技术，如短信
发起对话
对话的开始会让用户对客服人员能做的事情产生预期 用途。以有说服力的方式开始对话：展示客服人员的个性； 尽早展示用户关心的信息，并分享您的代理 其他功能。为用户提供明确的选项，以便他们与代理互动，并 继续对话
遵守邮件大小上限
RBM 对 RBM 消息和媒体文件的大小上限设置了限制 消息中可能包含的内容这些记录在 发送消息 页面。
保持好节奏
在对话中使用各种类型的信息可以吸引用户的注意力， 与代理互动，但要注意不要让用户感到无所适从。保留 撰写短小精悍、易于理解的内容，让用户看到 同时在屏幕上图片和复合信息卡可能会占用大量资源 因此，请留意用户需要滚动到 阅读整封邮件。
确保邮件井然有序
如果您按顺序发送多条消息，请务必确保用户
按顺序显示这些消息有些信息（例如包含媒体内容的信息）会
比其他类别（例如纯文本邮件）的处理时间更长。接收者
确保用户按照您的发送顺序接收邮件，等到您
收到针对消息的 200 OK 响应，然后在
序列。
200 OK 响应确认 RBM 平台已收到消息，并且
确保用户以正确的顺序接收消息。如果您
请等待 200 OK 响应后再发送其他消息，用户可能会收到
顺序错误。
检查是否有重复收到的邮件
查看并回复用户发来的邮件时，请检查
messageId，并确认您尚未收到并
之前已回复此邮件。
分布式系统可以通过两种方法发送消息：最多一次， 至少一次。
- “最多一次”系统发送一次消息， 但如果使用过程中出现网络或通信错误， 可能收不到
- “至少一次”系统可能会向 但即使有网络，也可以接收消息 或通信错误。
Google Cloud Pub/Sub 使用“至少一次”系统。虽然这会导致
收到重复的邮件，因此您可以通过 删除重复邮件，
跟踪 messageId 字符串。如果您已收到一条消息，
您可以放心地忽略
messageId。
撰写清晰一致的消息
发送有吸引力且清晰易懂的消息。较好 消息文本会提示用户进行回复，且风格、格式和 文本节奏和节奏可以赢得用户信任。
创建消息文字时，请遵循以下其他最佳实践：
- 不要制造死胡同。每条建议的回复都应能产生有意义的回复 与用户进行的会话。
- 如有必要，请使用“您”，而不是“我”。
- 对于标题和标签，请使用句首字母大写，而不是词首字母大写。例如： “账号活动报告”，而不是“账号活动报告”。
- 使用缩写词。“是”比“其实”更具有对话性。
- 请谨慎使用感叹号。
- 使用逗号作为分隔符。例如，“A、B 和 C”，而不是“A、B 和 C”。
- 写为数字。例如，应该使用“1, 2, 3”，而不是“one, two, three”。
尊重用户不需要的邮件
当用户指明他们不想再收到来自您的 您需要尊重他们的选择您的代理必须了解 回复“STOP”并做出适当的回应。您的代理应了解 用户可能会通过哪些方式告知他们不想再接收邮件； 包括他们为了传达自己的需求而可能会使用的任何及所有语言。
请查阅您所在国家/地区的法律和最佳实践， 对 STOP 和其他强制命令做出响应。例如，请参阅 CTIA 最佳做法。
为用户提供帮助
您的代理应回复用户的 HELP 消息，并告知用户 代理的功能简单的建议回复列表 都可能会导致糟糕的用户体验 转换为有用的内容
使用指数退避算法实现重试
调用任何 API 时，由于基础设施原因，调用都可能会失败 服务过载、QPS 限制和其他错误。妥善恢复 失败的 API 调用时，使用指数退避算法实现重试。
使用指数退避算法进行重试时，您的基础架构会自动执行 以下：
- 标识失败的 API 调用。
- 设置初始等待时长和最大重试次数。
- 在等待期间暂停。
- 重试 API 调用。
评估 API 调用响应：
- 如果成功，请继续执行工作流程中的下一步。
- 如果失败，增加等待时长并返回第 3 步。
- 如果在重试次数上限后失败，则进入失败状态。
理想的等待时长和理想的最大重试次数因使用场景而异。 请根据基础架构的延迟时间要求确定这些数值 和工作流。
复合信息卡
借助复合搜索卡，您可以将媒体内容、文字和建议整合到一条消息中。如 因此，媒体不应是复合信息卡中的唯一元素，并且建议的回复 或建议操作应始终与独立的复合信息卡一起显示。
纵向复合搜索卡
纵向复合搜索卡会在卡片顶部显示横向媒体。横屏 媒体的宽高比应为 2:1、16:9 或 7:3。
向用户发送媒体内容时，您应尊重用户的资源。 当横向媒体的宽高比为 2:1 时，媒体的最佳分辨率为 1440x720 像素，建议的图片文件大小上限为 2MB 视频大小为 10 MB。媒体缩略图的最佳分辨率是 770x335 像素，建议的文件大小为 40 kB 大小上限为 100 kB。
横向复合信息卡
横向 Rich Card 显示在视频画面的左侧或右侧 卡片。竖屏媒体的宽高比应为 3:4。
向用户发送媒体内容时，您应尊重用户的资源。 当纵向媒体的宽高比为 3:4 时，媒体的最佳分辨率是 768x1024 像素，建议的图片文件大小上限为 2MB 视频大小为 10 MB。媒体缩略图的最佳分辨率是 250 x 330 像素，建议的文件大小为 40 kB 大小上限为 100 kB。
复合信息卡轮播界面
复合信息卡轮播界面非常适合浏览内容或各种选项， 只有在有多个项目要读取或比较时才应使用，例如， 流量套餐或设备轮播界面中的第一项应该是最佳选择 以及为何它是最佳选择的原因 都应该传达给用户
轮播界面下方的建议内容信息卡应推进或转换对话。 建议内容信息条不应重复轮播界面中列出的选项，并且 不是轮播界面中所显示项目的选择工具。
复合信息卡轮播界面中的媒体
复合信息卡轮播界面会在复合信息卡顶部显示横向媒体。 轮播界面中横向媒体的宽高比应为 4:3。
向用户发送媒体内容时，您应尊重用户的资源。 当媒体的宽高比为 4:3 时，媒体的最佳分辨率为 960x720 像素，图片的文件大小上限为 1MB，文件大小上限为 5MB 。媒体缩略图的最佳分辨率为 605x452 像素 建议的文件大小为 40 kB，建议的大小上限为 100 kB。
建议的回复和操作
复合信息卡中的建议的回复和操作应与 卡片中的内容
条状标签列表中的建议的回复和操作应该是推进或 转变对话风格。
建议的回复
建议的回复可帮助用户以 轻松响应除非互动需要自由形式的回复，否则请使用 建议的回复。它们比自由格式文本更易于处理，并且 将对话引导到最佳路径。
建议操作
通过建议操作，代理可以接入原生设备操作， 为用户提供紧密集成的体验。建议操作（如相关） 可让您轻松致电客户支持部门或在地图上查找位置。
但不要让用户感到无所适从。仅提供与以下内容相关的操作： 最近的消息，并且仅提供必要的操作。限制 对于对组织来说有用的内容，建议的操作和建议回复的数量 用户。
设计总结
在进行设计时，重点考虑对话性、易用性和效率， 创建代理的过程。代理应专注于对话式界面， 通过建议的回复和操作，引导用户完成最佳工作流程。时间 使用图片或复合搜索卡，代理应保持适当的节奏， 轻松保留上下文并阅读消息。
考虑用户体验并避免对话死循环 设计代理可为用户提供良好的体验，让他们愿意 以便日后再次使用您的代理