新助手；选择编写范式。
使用 Actions 编辑器构建，而不是使用旧版 Dialog 技能。Actions 将面向任务的对话建模为步骤、条件和变量，无需管理节点树。
原因: Actions 是 IBM's 当前推荐的编写模型；Dialog 是旧版且更难维护。专业考试假定 Actions 优先设计。
最后审核：2026年6月
C1000-180 考试涉及的架构模式快速参考。从头到尾阅读，或跳转到任意章节。
新助手；选择编写范式。
使用 Actions 编辑器构建，而不是使用旧版 Dialog 技能。Actions 将面向任务的对话建模为步骤、条件和变量，无需管理节点树。
原因: Actions 是 IBM's 当前推荐的编写模型；Dialog 是旧版且更难维护。专业考试假定 Actions 优先设计。
决定如何将大型支持域分解为单元。
每个独立的用户目标（重置密码、查询余额、预约）对应一个 action。保持 action 的单一目的和可重用性。
原因: 狭窄的、以任务为范围的 action 比尝试处理所有事情的整体流程更容易测试、分析和改进。
用户输入可能会触发几个相似的 action。
启用消歧功能，以便助手显示候选 action 的澄清菜单，而不是猜测。
原因: 消歧减少了错误 action 的发生，揭示了用户'的真实意图，提高了完成率。
助手在多次尝试后仍不理解用户。
设计一个“无匹配 action”/其他路径，提供澄清性回复，并在 N 次失败后升级给人工座席。
原因: 明确的后备机制可以防止死循环并保护客户满意度；未捕获的无匹配是导致放弃对话的主要原因。
对话超出助手的能力范围或用户感到沮丧。
添加一个“连接到座席”步骤，将对话上下文附加到服务台（例如 Zendesk, Genesys, Salesforce）进行转接。
原因: 将对话记录和收集到的变量传递给座席，可以避免强制用户重复自己的话。
利益相关者希望在所有回复中保持一致的品牌声调。
预先定义角色和语调指南；一致地编写回复文本并重用变体，以避免机械式重复。
原因: 一致的语调能建立信任；在不同 action 中混用正式和非正式措辞会让人感觉不连贯。
用户'的措辞中缺少或含糊不清的必要细节。
通过 slot 提问有针对性的澄清问题，而不是假设一个默认值。
原因: 明确确认高风险参数（金额、账户、日期）可防止代价高昂的错误 action。
设计一个有许多边缘情况的新流程。
首先编写端到端的“正常路径”，然后分层添加验证、离题处理和错误分支。
原因: 在核心流程之前构建边缘情况会导致过度工程化、难以测试的 action。
一个 action 在完成前需要几条信息。
在自己的步骤中将每个值作为 slot 收集；助手会提示尚未提供的值，并跳过已提供的值。
原因: 基于步骤的 slot 填充无需手动分支即可处理乱序和多值输入。
一个值在当前 action 结束后必须持久存在。
将其存储在会话变量中，而不是步骤/action 变量中。action 变量作用域仅限于 action；会话变量在整个对话中都存在。
原因: 选择错误的作用域是一个经典错误：当 action 完成时，值会消失，或者无法在 action 之间共享。
一个步骤要求用户从一个已知的固定集合中选择。
使用带有预定义选项的“选项”回复类型，而不是自由文本，并将每个选项映射到一个值。
原因: 选项限制了输入，消除了解析歧义，并在支持的渠道上显示为按钮。
收集到的值（电子邮件、日期、金额）可能格式不正确。
在该步骤上添加验证条件；如果无效，则通过纠正性提示将用户保留在该步骤上。
原因: 在捕获时进行验证可以避免将错误数据传递给扩展和下游步骤。
后续步骤应仅针对某些用户或值运行。
对已收集的变量设置步骤条件，以便在条件为 false 时跳过步骤。
原因: 条件在不复制 action 的情况下表达分支；编辑器从上到下评估它们。
多个 action 需要相同的子流程（例如，验证身份）。
将共享逻辑分解为子 action，并从每个父 action 调用它。
原因: 子 action 保持验证逻辑的 DRY（Don\'t Repeat Yourself）和一致性；复制步骤会导致不同步。
用户在流程中途提出不相关的问题（“你们的工作时间是什么？”）。
允许离题，以便助手回答附带问题，然后返回到被中断的 action。
原因: 阻止离题会强制执行僵硬的脚本，这会使用户对合理的附带请求感到沮丧。
需要在步骤内计算或转换值。
在步骤或回复中使用内置的表达式语言（例如，变量上的字符串和数学函数）。
原因: 轻量级转换属于表达式；为简单的数学运算使用 webhook 是多余的。
后续 action 需要用户之前提供的值。
引用现有的会话变量，而不是重新提示。
原因: 重新询问已知数据会让人感觉流程有问题；向前传递上下文是良好流程的标志。
在特定条件下，流程应停止或跳转到另一个 action。
使用“结束 action”或“跳转到另一个 action 中的步骤”的转换来明确控制流程。
原因: 明确的转换可以防止在终止条件后意外地进入下一个步骤。
助手必须调用有文档的 REST API 来获取实时数据。
将 API's 的 OpenAPI 规范导入为自定义扩展，然后添加一个“调用扩展”步骤，将变量映射到参数。
原因: 自定义扩展是从步骤调用具有类型化输入/输出的外部 API 的受支持的无代码方式。
在 webhook 和自定义扩展之间进行选择。
使用自定义扩展在特定步骤内调用外部 API；使用 webhook（消息前/消息后）在每条消息上运行逻辑或转换整个 payload。
原因: webhook 按消息全局触发；扩展按步骤进行范围限定和参数映射。选择错误是常见的考试陷阱。
目标 API 需要身份验证。
添加自定义扩展时配置身份验证（API 密钥、OAuth、基本身份验证）；将秘密存储在扩展配置中，而不是对话文本中。
原因: 将凭据嵌入变量或回复中会导致其在日志和对话记录中泄露。
扩展调用返回错误或超时。
在下一步中根据扩展'的响应/状态进行分支，并显示回退消息或重试路径。
原因: 未处理的扩展故障会导致用户受阻；始终设计非 200 路径。
需要在处理前或发送前丰富或删除每条消息。
使用消息前 webhook 预处理传入输入，使用消息后 webhook 在交付前转换响应。
原因: 消息前/消息后 webhook 集中处理交叉关注点（PII 屏蔽、日志记录），而无需编辑每个 action。
用户提出可以从文档语料库中回答的开放式问题。
启用对话式搜索 (RAG)：从搜索集成中检索段落，并让 watsonx.ai 基础模型生成带有引用的可靠答案。
原因: 对话式搜索涵盖了你无法编写为离散 action 的长尾问题。
选择对话式搜索背后的检索存储。
连接 watsonx Discovery / Elasticsearch（或其他受支持的搜索集成）作为检索索引。
原因: 基础质量取决于检索索引；未索引或分块不佳的语料库会返回较弱的段落。
对话式搜索未找到相关段落。
配置无搜索结果回复，以便助手表示不知道而不是幻觉，并提供升级选项。
原因: 明确的无结果路径是保持 RAG 助手诚实和可靠的关键。
合规性要求可生成答案可追溯。
启用来源引用，以便生成的答案显示其来源文档。
原因: 引用允许用户验证答案，并满足受监管行业的可审计性要求。
调整生成答案的质量和成本。
为对话式搜索选择 watsonx.ai 基础模型（例如 Granite 模型），并根据用例调整生成设置。
原因: 模型和参数选择需要在答案质量、延迟和成本之间进行权衡；默认值并非总是最优的。
决定查询是由 action 处理还是由搜索处理。
将事务性、参数化任务路由到 action；将开放式信息问题路由到对话式搜索。
原因: 将 FAQ 式问题强制纳入僵硬的 action，或将事务强制纳入 RAG，都会降低用户体验。
助手必须接听来电。
使用电话/语音集成（基于 SIP 的语音网关）连接电话服务提供商，使用 STT 进行输入，使用 TTS 进行回复。
原因: 语音网关将 SIP 电话连接到助手；没有它就没有电话渠道。
语音回复听起来不对或错误识别了来电者。
在电话集成设置中调整语音转文本模型/语言和文本转语音语音。
原因: 默认语音/模型可能不匹配语言或领域词汇，从而损害识别和清晰度。
为聊天构建的流程在语音上表现不佳。
调整语音流程：避免使用按钮/长列表，保持提示简短，并明确确认口述值。
原因: 语音无法呈现富 UI；带有菜单的文本优化流程在朗读时会中断。
通过 SMS / 短信接触用户。
配置 SMS（电话/文本）集成；设计纯文本回复，不包含富文本元素。
原因: SMS 会去除富回复类型；回复必须优雅地降级为文本。
Web 聊天应显示图片、卡片或按钮。
在 action 中使用富回复类型（图片、选项、卡片）；渠道会渲染支持的类型，否则会回退。
原因: 富回复可改善 Web UX，但必须为语音/SMS 提供合理的纯文本回退。
衡量助手是否真的有帮助。
使用 Analytics 仪表板跟踪完成率、覆盖率以及随时间变化的已识别与未识别输入。
原因: 会话数等虚荣指标并不能反映任务成功；完成率和覆盖率可以。
查找用户放弃流程的原因。
阅读对话日志/记录，按 action 过滤，并找出放弃步骤和频繁的无匹配项。
原因: 真实的对话记录揭示了聚合指标只能暗示的差距。
消歧建议的顺序通常是错误的。
启用自动学习，以便助手根据用户实际选择的选项重新排序建议。
原因: 自动学习无需手动重新训练即可提高真实选择的相关性。
许多输入都落入“无匹配 action”。
从分析中挖掘未识别的输入，对其进行聚类，并编写新的 action 或向现有 action 添加示例。
原因: 覆盖率差距是最高杠杆的改进；它们是你完全失败的查询。
一个有效请求无法可靠地触发其 action。
将真实用户措辞作为训练示例添加到该 action'的步骤中，从而提高识别能力。
原因: 识别能力通过从日志中提取的代表性示例得到加强，而不是通过凭空创造的措辞。
验证某个更改是否改善了结果。
一次只进行一项更改，发布后在一个有意义的时间窗口内比较更改前后的完成率/覆盖率。
原因: 一次更改太多东西会使指标变动归因变得不可能。
作者在终端用户与助手交互时进行编辑。
在草稿环境中进行编写；用户与生产环境交互。准备好后，将版本从草稿发布到生产。
原因: 草稿/生产分离允许你安全地迭代，而不会将未完成的工作暴露给生产环境。
一套经过测试的更改已准备好投入生产。
创建版本（快照）并发布到生产环境；以前的版本仍可用于回滚。
原因: 版本控制提供了可审计的历史记录，并在发布版本回滚时能快速回滚。
草稿和生产必须指向不同的后端端点（测试与生产）。
设置特定于环境的扩展/集成设置，以便每个环境都指向正确的系统。
原因: 在不同环境之间共享一个端点可能会导致测试流量冲击生产系统。
将助手部署到 Web 聊天、电话、Slack 和 WhatsApp。
在目标环境中添加并配置每个渠道集成；渠道按环境附加。
原因: 仅在草稿上启用的渠道在生产环境中配置之前不会为生产用户提供服务。
不同的团队成员需要不同级别的访问权限。
使用 IBM Cloud IAM 在 watsonx Assistant 服务或资源组上分配基于角色的访问权限（例如，查看者、编辑者、操作员、管理员）。
原因: 通过 IAM 角色实现最小权限访问是控制谁可以编写与操作的受支持方式。
跨团队或项目组织服务和访问边界。
将助手服务置于资源组中，并将 IAM 访问策略的范围限定到该组。
原因: 资源组提供了清晰的计费和访问边界；扁平化账户在规模化时变得难以管理。
外部应用程序需要通过 API 调用助手。
生成服务凭据/API 密钥和助手 URL，并使用它们调用 v2 运行时 API。
原因: 编程访问使用范围限定的凭据；重复使用个人登录是不安全且不受支持的。
数据驻留或气隙规则禁止使用公共云。
将 watsonx Assistant 部署在 Cloud Pak for Data（本地或私有云）上，而不是 IBM Cloud SaaS。
原因: 受监管行业通常要求使用本地/CP4D 进行数据隔离和合规性。
为高容量生产部署选择计划。
根据所需的容量、功能和 SLA 选择适当的服务计划（例如，Plus/Enterprise）。
原因: Lite/试用计划限制使用量并缺乏生产功能；在发布前调整计划大小。
敏感数据出现在对话和日志中。
使用数据隔离、日志编辑/PII 屏蔽（例如，通过 webhook），并配置日志保留/安全设置。
原因: 对话记录中未屏蔽的 PII 是一种合规性责任；在摄取时进行屏蔽并控制保留。