对话式界面，而非应用界面
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 像素，图片的推荐文件大小上限为 2 MB，视频的推荐大小上限为 10 MB。媒体缩略图的最佳分辨率为 770x335 像素，建议的文件大小为 40 kB，建议的大小上限为 100 kB。
横向复合信息卡
横向复合搜索卡会在其左侧或右侧显示纵向媒体。竖屏媒体的宽高比应为 3:4。
向用户发送媒体内容时，您应尊重用户的资源。当竖屏媒体的宽高比为 3:4 时，媒体的最佳分辨率为 768x1024 像素，图片文件的大小上限为 2 MB，视频文件的大小上限为 10 MB。媒体缩略图的最佳分辨率为 250x330 像素，建议的文件大小为 40 kB，建议的大小上限为 100 kB。
复合信息卡轮播界面
复合信息卡轮播界面非常适合浏览内容或各种选项，但只应在有多个项目（例如流量套餐或设备）要读取或比较时使用。在任何给定情况下，轮播界面中的第一项都应是最佳选择，并且应向用户传达为何它是最佳选择的原因。
轮播界面下方的建议内容信息卡应推进或转换对话。 建议内容信息条不应重复轮播界面中列出的选项，也不是轮播界面中所显示项的选择工具。
复合信息卡轮播界面中的媒体
复合信息卡轮播界面会在复合信息卡顶部显示横向媒体。轮播界面中横向媒体的宽高比应为 4:3。
向用户发送媒体内容时，您应尊重用户的资源。当媒体的宽高比为 4:3 时，媒体的最佳分辨率为 960x720 像素，图片文件大小上限为 1MB，视频文件大小上限为 5MB。媒体缩略图的最佳分辨率为 605x452 像素，建议的文件大小为 40 kB，建议的大小上限为 100 kB。
建议的回复和操作
复合信息卡中的建议的回复和操作应与该卡片中的内容直接相关。
条状标签列表中的建议回复和操作应该是推进或转换对话的方式。
建议的回复
建议回复可帮助用户以易于响应的方式响应代理。除非互动需要自由形式的响应，否则请使用建议的回复。它们比自由格式文本更易于处理，并且可让您的代理将对话引导到最佳路径。
建议操作
通过建议操作，代理可以接入原生设备操作，并为用户提供紧密集成的体验。如有需要，您可以通过建议操作轻松致电客户服务团队或在地图上查找营业地点。
但不要让用户感到无所适从。请仅提供与最新消息相关的操作，并且仅提供必要的操作。建议在给定上下文中只针对对用户有用的内容建议操作和建议回复的数量。
设计总结
在创建代理时，针对对话式、易用性和效率进行设计至关重要。代理应专注于对话式界面，并使用建议的回复和操作引导用户完成最佳工作流。使用图片或复合搜索卡时，代理应保持一定的节奏，让用户能够保留上下文并轻松阅读消息。
在设计代理时，请考虑用户体验并避免对话死循环，可以为用户提供良好的体验，并让他们愿意将来再次使用您的代理。