对话界面，而非应用界面
RBM 代理非常适合在对话式界面中为用户提供具体而高效的任务。设计好的代理可确保互动重点、易于理解和结构化，就像自然对话一样。
代理不能依赖于应用或网页的视觉界面，不应试图模仿界面。相反，代理需要依靠精心设计的对话来满足用户的需求，引导他们采用口头提示、建议和良好的错误处理方式。
此外，代理不应模仿手机树，也不应依赖用户用代表给定操作的数字作为响应的接口。用户应该自然而然地就能与代理沟通，就像他们交流对话中的另一个人一样。
如需详细了解对话界面，请参阅对话界面及其重要性。
检查设备的功能
在与用户对话之前，请验证用户的设备可接收 RCS 消息。发送功能请求以确定设备的功能，并相应地定制代理的互动。仅通过设备支持的方式与用户互动。如果用户的设备未启用 RCS，请设置回退到其他技术（例如短信）的通信方式。
发起对话
对话的开始设定了用户对代理可以执行的操作的预期。正式开始对话时要做一个有力的注意：显示代理的个性，优先显示用户关心的信息，并分享代理的能力。为用户提供与代理互动和继续对话的明确选项。
保持良好的节奏
在对话中使用各种类型的信息可以提高代理的互动度和互动度，但要注意不要让您的用户感到应接不暇。广告内容应以引人入胜且易于理解的长度为长，让用户一次在屏幕上看到完整的信息。图片和复合信息卡可能会占用大量屏幕空间，因此务必要留意用户需要滚动多长时间才能阅读完整条消息。
让消息井然有序
如果您按顺序发送多条消息，用户必须按顺序接收这些消息。某些消息（例如包含媒体的消息）的处理时间要长于其他消息（例如纯文本消息）。为了确保用户按照您发送消息的顺序接收消息，请等到收到消息的 200 OK 响应后再发送序列中的下一条消息。
200 OK 响应用于确认 RBM 平台已收到消息，并且用户应以正确的顺序接收消息。如果您没有在发送其他消息之前等待 200 OK 响应，用户可能会不按顺序收到您的消息。
检查是否有重复收到的邮件
当您检查并回复用户发来的消息时，请检查 messageId 并验证您之前是否尚未收到并回复消息。
对于分布式系统，发送消息的方法有两种：最多一次和至少一次。
- 采用“最多一次”系统时，系统会发送消息一次，但如果在此过程中出现了网络或通信错误，则可能不会收到消息。
- 对于“至少一次”系统，系统可能会多次发送消息，但即使发生网络或通信错误，系统也可能会收到消息。
Google Cloud Pub/Sub 使用“至少一次”系统。虽然这可能会导致传入的消息重复，但您可以通过跟踪 messageId 字符串来轻松删除重复消息。如果您已收到一条消息，则可以放心地忽略您收到的具有相同 messageId 的所有其他消息。
撰写清晰一致的消息
发送引人入胜且易于理解的信息。好的消息文本会提示用户做出响应，并且文本样式、格式和节奏一致，有助于赢得用户的信任。
创建消息文本时，请牢记以下其他最佳做法：
- 请勿做出死胡同。每条建议的回复都应引发与用户有意义的对话。
- 如有必要，请将用户称为“您”，而不是“我”。
- 对于标题和标签，请使用句首字母大写形式，而不要使用首字母大写形式。例如，使用“帐号对帐单”，而不是“帐号对帐单”。
- 使用缩写词。“it's”比“it's”更具对话性。
- 谨慎使用感叹号。
- 请使用序列号。例如，使用“A、B 和 C”，而非“A、B 和 C”。
- 输入数字。例如，使用“1, 2, 3”，而不是“one, two,three”。
尊重用户不想看到的消息
如果用户表明他们不想再收到来自代理的消息，您需要尊重他们的选择。代理必须了解用户何时回复“STOP”并做出适当的回应。您的代理应该了解用户可能会希望通过哪些方式来停止接收消息，包括他们可能会使用的所有和所有沟通方式。
请参考您业务所覆盖的国家/地区的相关法律和最佳做法， 了解该如何回应 STOP 及其他强制命令。例如，请参阅 CTIA 最佳做法。
帮助用户
您的代理应回复来自用户的帮助消息，并向用户介绍代理的功能。您只要提供与代理的功能相对应的建议回复列表等简单内容，就能将糟糕的用户体验转化为有用体验。
使用指数退避算法实现重试
调用任何 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 像素，图像的大小上限为 1 MB，视频的最大文件大小为 5 MB。媒体缩略图的最佳分辨率为 605x452 像素，建议的文件大小为 40 KB，建议的大小上限为 100 KB。
建议的回复和操作
复合信息卡中的建议回复和操作应与该卡片中的内容直接相关。
芯片组中的建议回复和操作应是推进对话或调整对话的方式。
建议的回复
建议的回复可帮助用户以轻松回复代理的方式做出响应。除非互动需要自由形式回复，否则请使用建议的回复。处理过程比自由文本更轻松，而且可以让代理将对话引向最佳路径。
建议操作
通过建议的操作，代理可以接入原生设备操作，并为用户提供紧密集成的体验。相关的建议操作可方便致电客服团队或在地图上查找位置。
但不要向用户呈现过多的选项。请仅提供与最新消息相关的操作，并仅提供尽可能多的操作。推荐操作次数和回复回复次数应限定为在给定情境中对用户有用。
设计总结
创建对话时，以对话、易用性和效率为设计最为重要。代理应专注于对话界面，并通过建议的回复和操作引导用户完成最佳工作流程。使用图片或复合信息卡时，代理应保持一种节奏，让用户可以轻松保留上下文并阅读消息。
在设计代理时，既要考虑用户体验，又要避免对话瓶颈，即为用户提供良好的体验，让他们将来愿意再次使用您的代理。