---
schema_version: "1"
id: 468668cb9712d86f1b499e4e3828acfaacdb146a3196b80e90a8f9537f81581c
title: AI 公平和偏见检测 - 代理模式
collection: architect
version: current
locale: zh-cn
portal_url: https://docs.salesforce.com/architect/current/zh-cn/well-architected/guides/fairness-agentic-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/well-architected/guide/fairness-agentic-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 6f3f57cbf3bc7898d925ef56913df5e80b512426196c76eb07ef315286cf7b66
products:
  - 架构良好的框架
  - Architect Site Content Repo
---
# AI 公平和偏见检测 - 代理模式

了解有关架构良好的[公平性](/docs/architect/zh-cn/well-architected/guide/fairness.html)的更多信息 → [Agent Enterprise Fairness](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-fairness.html)

## 偏见检测和缓解

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Agentforce \| 客服人员配置 | ✅ 使用代表受保护群体的不同角色，系统地测试客服人员的人口统计偏见；生成相同的请求，仅变化人口统计信号，例如姓名、位置或通信风格 |
| Data 360 \| 数据细分 | ✅ 在将 Salesforce 数据用于客服人员培训或 RAG 基础训练前，审核人口统计代表性，并识别代表性不足的群体 |
| Data 360 \| Knowledge 库 | ✅ 审核 Knowledge 库和检索源以实现人口统计平衡；确保文档质量、完整性和准确性在所有客户群中具有可比性 |
| Agentforce \| 客服人员监控 | ✅ 监控客服人员跨人口统计组的互动，以了解行为一致性；分析响应长度、详细信息级别、礼貌标记和按用户特征分层的解决方案质量 |
| Agentforce \| 客服人员监控 | ✅ 通过监控决策分配随时间的变化来检测反馈循环；通过边缘个案的人工审核和定期重新平衡来打破循环 |
| Data 360 \| 培训数据 | ✅ 在训练数据中高采样代表性不足的人口统计组，确保代表性平衡；在真实数据不足时，使用 SMOTE 等技术综合其他数据 |
| Agentforce \| 提示模板 | ✅ 通过系统提示约束客服人员行为："以同等的专业精神和细节对待所有客户人口统计。无论客户沟通风格或背景如何，都要提供长度和质量相当的解释 。 " |
| Einstein \| 预测模型 | ✅ 计算所有模型特征与受保护特征之间的相关系数；评估合法预测值是否有理由包含高度相关特征 |
| Einstein \| 预测模型 | ✅ 识别并移除与受保护特征相关的代理特征（种族的邮政编码代理、性别/族裔的名称模式代理、宗教/护理的通信时间代理、收入的设备类型代理、人口统计组成的区域分配代理） |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Data 360 \| 培训数据 | 使用历史 CRM 数据进行客服人员培训，无需审核人口统计表示，允许算法偏见加剧人为偏见 |
| Agentforce \| 客服人员配置 | ⚠ 部署客服人员时，无需对代表受保护群体的不同角色进行系统的人口统计偏见测试 |
| Data 360 \| Knowledge 库 | ⚠ 为企业客户提供详细的 Knowledge 文章，但只为小型企业客户提供通用响应，使服务质量差距永久化 |
| Agentforce \| 客服人员监控 | 允许客服人员根据与受保护特征（通信风格、语言复杂性、定时模式）相关的对话提示来调整行为，而无需监控 |
| Einstein \| 预测模型 | 在相应的决策模型中包括代理特征（邮政编码、名称模式、设备类型），而不评估与受保护特征的相关性 |
| Agentforce \| 客服人员配置 | 允许反馈循环，客服人员的决策会产生差异，从而证明未来的不利决策是正确的（例如，将客服人员的业务机会减少到特定区域，生成更少的成功数据，进一步减少预测的成功） |
| Data 360 \| 数据细分 | 在疏远代表性不足的用户的内容示例中，默认设置为多数文化引用 |

## 多客服人员编排

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Agentforce \| 客服人员监控 | ✅ 记录编排链中每个客服人员的完整输入和输出，以便最终结果中的偏差可以追溯到引入它的阶段和放大发生的位置 |
| 平台 \| CRM Analytics | ✅ 构建仪表板，显示按人口统计细分的每个编排阶段的决策分布，以确定差距在链中出现或扩大的位置 |
| 平台 \| CRM Analytics | ✅ 计算人口统计均等、平等机会和价值链每个阶段的不同影响，而不仅仅是最终结果;分阶段度量捕捉在任何单个阶段看起来可以接受但在整个价值链中降解的复合 |
| Agentforce \| 模型配置 | ✅ 最大化一致性模式中客服人员的多样性以减少相关错误：可行时的不同基础模型（例如通过自带 LLM 配置）、不同的检索源、不同的提示方法和不同的置信度阈值校准 |
| Agentforce \| 客服人员配置 | ✅ 在编排拐点插入人工审核，在该阶段，即使单个客服人员的置信度很高，也会显著缩小下游选项的范围，因为编排会产生每个客服人员置信度分数无法捕捉的紧急效果 |
| Agentforce \| 客服人员配置 | ✅ 配置编配断路器，当任何客服人员的置信度低于阈值、输出分配在阶段之间显著偏移、链遇到训练或验证中未表示的数据或用户质疑中间决策时，该断路器会停止并升级为人工 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 客服人员监控 | ⚠ 运行编排链，而不记录每个客服人员的输入和输出，因此无法跟踪在出现歧视性结果时哪个阶段引入了偏见 |
| Agentforce \| 模型配置 | 在所有客服人员共享相同基础模型或训练数据时，将多客服人员共识视为偏见纠正，因此一致性仅验证共享偏见，而非纠正偏见 |
| 平台 \| CRM Analytics | ⚠ 仅衡量最终编排结果的公平性，缺少阶段级复合，其中每个阶段似乎孤立地可以接受，但链式复合有不可接受的差异 |
| Agentforce \| 客服人员配置 | ⚠ 依赖单个客服人员的置信度分数来把控编排链，而无需在阶段缩小下游选项的拐点插入人工审核 |
| Agentforce \| 客服人员配置 | 当上游客服人员置信度低、分发在阶段之间转移或链遇到其训练和验证集之外的数据时，允许编配链在没有断路器的情况下继续 |

## 公平性度量

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 业务 \| 部署网关 | ✅ 在部署任何客服人员做出相应决定之前，将公平性评估作为强制性部署网关，其权限相当于安全审查 |
| Einstein \| 预测模型 | ✅ 通过将人口划分为人口细分、衡量每个细分的积极成果率和比较细分的比率来计算人口均等 |
| Einstein \| 预测模型 | ✅ 通过验证客服人员平等地识别合格的个人，无论人口统计特征如何，确保机会平等；验证真正的阳性率在群体之间具有可比性 |
| Einstein \| 预测模型 | ✅ 应用五分之四规则：如果任何小组的阳性结果低于表现最好的小组的 80%，调查偏见 |
| Einstein \| 预测模型 | ✅ 计算所有后续客服人员决策的不同影响比率，并在比率低于 80% 时记录调查结果 |
| 业务 \| 文档 | ✅ 记录违反人口均等反映合法商业因素而不是歧视的情况 |
| 业务 \| 法律审查 | ✅ 在通过特定于群体的阈值实施平均赔率时，请咨询法律顾问，指出在美国,第七章(1991年民权法)禁止按受保护类别调整与就业相关的决策的分数或截止值,其他司法管辖区也规定了自己的约束 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 业务 \| 部署网关 | 部署客服人员做出相应决策，而不计算人口统计组之间的公平度量 |
| Einstein \| 预测模型 | 为代表性不足的群体设置高于多数群体的证据阈值，从而系统性地缺失这些群体的合格候选人 |
| Einstein \| 预测模型 | 在没有法律依据或验证的情况下实施特定于群体的阈值，以提高公平性，而不会产生其他歧视性影响，或者在美国，完全为了与就业相关的决定而实施这些阈值，其中第七章禁止按受保护阶级调整分数或截止值 |
| 业务 \| 文档 | 在违反公平度量反映合法业务差异与歧视时，未记录 |

## 偏见检测

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Einstein \| Trust 层 | ✅ 使用 Trust 层审计数据分析人口统计组的回复分布；构建 CRM Analytics 仪表板，比较批准率、推荐模式和按客户细分的风险分数 |
| Einstein \| Trust 层 | ✅ 定期查询 Trust 层日志：显示按客户行业、地区和客户规模分组的所有高价值预测，以验证预测在细分中的一致性 |
| Agentforce \| 会话跟踪 | ✅ 按人口统计组分层的 100 个客服人员决策示例，并让审核人员使用 Agentforce 会话跟踪推理跟踪评估推理质量是否在组之间具有可比性 |
| 平台 \| CRM Analytics | ✅ 在客服人员决策模式显著偏离基线时配置警报（例如，特定细分的批准率每周下降 20%） |
| 平台 \| CRM Analytics | ✅ 构建自定义监控，以提醒公平信号："当任何客户群的平均对话长度超过连续三天总平均值的 1.5 倍时通知" |
| 平台 \| CRM Analytics | ✅ 构建可重复使用的 CRM Analytics 仪表板模板，跟踪常见客服人员用例的公平性度量，包括人口统计均等、业务机会平等、不同影响比率和趋势图 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 会话跟踪 | 当用户报告偏见时，忽略 Agentforce 会话跟踪推理跟踪和 Trust 层审计跟踪，缺少引入偏见的推理步骤、数据源或检索模式 |
| 平台 \| CRM Analytics | ⚠ 无法为公平信号配置异常检测警报，允许突然的分布轮班不被检测到 |
| 平台 \| CRM Analytics | 为每个团队临时构建公平仪表板，而不是共享可重复使用的模板来标准化公平监控 |

## 人员监督

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Agentforce \| 客服人员配置 | ✅ 为高风险决策（就业、信贷、医疗、法律、住房）设计客服人员，以分析、推荐和准备决策，同时在执行前需要人工批准 |
| 平台 \| 审批流程 | ✅ 配置 Agentforce 以生成具有支持证据的推荐，通过审批流程将超过阈值的决策发送给人工审核人员，并在审批界面中显示客服人员推理跟踪 |
| Agentforce \| 客服人员配置 | ✅ 实施基于置信度的升级：高置信度 (>90%) 自主进行，适度 (70-90%) 需要人工审核，低置信度 (<70%) 完全服从人工上下文汇总 |
| Agentforce \| 客服人员配置 | ✅ 使用生产数据校准置信度阈值；在每个置信区间抽样客服人员决策，并计算实际成功率，以验证校准 |
| Agentforce \| 客服人员配置 | ✅ 设置限时升级触发器：在 5-7 轮无解析后、经过 10 分钟后、用户表示沮丧时或客服人员重复相同响应时 |
| 平台 \| 全方位 | ✅ 配置全方位，将升级的个案路由到具有完整对话上下文的适当基于技能的队列；培训人工客服人员处理升级，而无需用户重复信息 |
| Agentforce \| UX | ✅ 在客服人员聊天界面中始终提供“与人工客服人员连接”选项，而不是被锁定在最少失败交互次数之后 |
| Agentforce \| 客服人员配置 | ✅ 允许授权人员在任何时间点使用文档化的理由覆盖任何客服人员决策；在所有需要多行文本解释的客服人员决策界面中添加“覆盖客服人员”按钮 |
| 平台 \| 自定义对象 | ✅ 使用决策 ID、覆盖时间戳、理由和覆盖者记录对自定义对象的覆盖；创建 CRM Analytics 仪表板，按客服人员、决策类型和客户人口统计跟踪覆盖模式 |
| 业务 \| 文档 | ✅ 需要记录批准或拒绝的理由，以区分客服人员推荐；跟踪覆盖模式，以识别客服人员的系统缺陷 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 客服人员配置 | 将客服人员部署为高风险决策（就业、信贷、医疗、法律、住房）的自主决策者，无需人工审批 |
| Agentforce \| 客服人员配置 | 使用校准错误的置信度分数，其中“高置信度”决策仅在 75% 的时间内成功，破坏了对升级机制的Trust |
| Agentforce \| 客服人员配置 | ⚠ 将客户困在无益的自动化循环中，而不会向人员提出有时限或无时限的升级 |
| 平台 \| 全方位 | 路由没有完整对话上下文的升级个案，迫使用户重复已经提供给客服人员的信息 |
| 业务 \| 治理 | 允许分散责任，每个人承担 AI 的责任，没有人能够自主决策 |
| 业务 \| 治理 | ⚠ 在发生事件后分配责任，而不是在部署架构决策记录中记录的指定个人之前 |

## 责任分配

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 业务 \| 文档 | ✅ 在部署前分配问责：模型所有人（公平性/准确性）、决策所有人（用例/影响）、上诉机构（公平性上诉）、审计机构（定期审计） |
| 业务 \| 文档 | ✅ 用名称而不仅仅是职务记录所有问责角色，确保问责通过组织变革持续存在 |
| 业务 \| 治理 | ✅ 授权上诉机构（道德审查委员会或指定团队）处理来自认为客服人员决策不公平的用户的上诉，以及可撤销客服人员决策的便捷、及时流程 |
| 业务 \| 治理 | ✅ 授权审核机构(合规团队)定期审核,对未达到公平标准的客服人员暂停服务,待处理 |
| 业务 \| 治理 | ✅ 与客服人员开发团队计划每月审查高频覆盖模式 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 业务 \| 治理 | ⚠ 记录仅具有职务的责任角色（例如，“数据科学潜在客户”），而没有命名的个人，允许在组织变更期间消失责任 |
| 业务 \| 治理 | 允许决策者将责任委托给 AI 系统，而不是保留个人对真实世界影响的问责 |
| 业务 \| 治理 | 使上诉流程无法访问、不及时或无权撤销客服人员的决定 |

## 透明度和可解释性

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Agentforce \| 客服人员配置 | ✅ 架构多个解释层：面向用户（纯语言）、业务（关键决策因素）、技术（模型详细信息/功能权重）和审计（完整决策跟踪） |
| Agentforce \| 客服人员配置 | ✅ 决策时显示实时汇总推理："我根据您的购买历史(3 次类似购买)、当前促销(8 折)和库存可用性推荐了产品 A" |
| Agentforce \| 客服人员配置 | ✅ 提供“您为何推荐？”链接，使用户能够查看完整的推理，包括检索的所有 Knowledge 文章、查阅的记录和决策逻辑 |
| Agentforce \| 会话跟踪 | ✅ 当用户在几周或几个月后质疑过去的决策时，从 Agentforce 会话跟踪中检索推理跟踪，以进行历史重建 |
| Agentforce \| 会话跟踪 | ✅ 按人口统计组分层的示例 Agentforce 会话跟踪推理跟踪，分析决策质量是否一致；查看每个客户细分的 100 个跟踪 |
| Agentforce \| 客服人员配置 | ✅ 使用用户适当的术语传达信心：“高置信度”/“中等置信度”/“低置信度”，使用简单语言的可靠性上下文，而不是原始的概率分数 |
| Agentforce \| 客服人员配置 | ✅ 对于中等或低置信度决策，解释将进行哪些额外审核以及预期时间表 |
| Agentforce \| 客服人员配置 | ✅ 提供反事实解释，向用户展示什么会改变结果："您的潜在客户得分会随着已验证就业信息的增加而增加 (+8 分)" |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 客服人员配置 | 显示用户误解的原始概率分数（例如“73% 置信度”），而不是用户适当的置信度语言 |
| Agentforce \| 客服人员配置 | ⚠ 提供反事实，鼓励游戏系统或无意中揭示受保护的特征作为决策因素（例如，“如果您年轻 10 岁，您的应用程序会得分更高”） |
| Agentforce \| 客服人员配置 | 仅提供一级解释，既不为最终用户服务（太技术性）也不为审计员服务（太简化） |
| Agentforce \| 客服人员配置 | 无法存储历史推理痕迹，使得在质询时无法解释过去的决策 |

## AI 披露

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Agentforce \| 客服人员配置 | ✅ 清楚表明用户何时与 Agentforce 客服人员交互，并持续进行重要披露（不会在服务中隐藏，或在交互开始时仅显示一次） |
| Agentforce \| 客服人员配置 | ✅ 显示持续可视指示符：标记为“AI 助手”的客服人员头像，显示“您正与 Agentforce 服务代理聊天”的标题，以及在整个对话中可见的“与人工客服人员联系”选项 |
| Agentforce \| 客服人员配置 | ✅ 确保喜欢人类交互的用户能够切换，而不会造成摩擦或服务质量损失 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 客服人员配置 | 在服务中嵌入 AI 披露，或在交互开始时仅显示一次，而不是保持持续的视觉指标 |
| Agentforce \| 客服人员配置 | ⚠ 惩罚选择服务降级或等待时间增加的人机交互的用户 |
| Agentforce \| 客服人员配置 | 隐藏“与人工客服人员联系”选项，或要求用户在访问人工支持之前完成客服人员交互 |

## 算法问责和审计

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| Event Monitoring | ✅ 配置 Event Monitoring 以跟踪：API 事件日志显示客服人员系统交互、客服人员服务帐户的登录事件，以及客服人员访问批量数据时的报表导出 |
| 平台 \| Event Monitoring | ✅ 将 Event Monitoring 日志流式传输到外部 SIEM，以便长期保留和篡改符合监管要求的证据 |
| 平台 \| 字段审计跟踪 | ✅ 对存储客服人员决策或受客服人员决策影响的对象启用字段审计跟踪（无限期保留已归档历史），从支持的标准对象和启用了字段历史跟踪的自定义对象中进行选择；对于信用、就业和其他高风险用例至关重要 |
| 平台 \| Shield | ✅ 将 Shield Event Monitoring 用于风险最高的客服人员决策，其中审计跟踪完整性至关重要（增强功能、结构化事件字段、合规报告集成） |
| 平台 \| 自定义对象 | ✅ 创建 Agent Decision__c 自定义对象存储：Decision_ID、时间戳、Agent_Type、Model_Version、 confidence_Score、 Outcome、User_ID、Record_ID；连接对象 DecisionInput__c 将决策链接到输入功能快照 |
| 平台 \| 自定义对象 | ✅ 在决策时存储准确的输入特征值（不是可能会变化的当前值），以便测试决策是否会与更新的数据不同 |
| 业务 \| 文档 | ✅ 每个后续决策的记录模型版本、配置状态（阈值、业务规则、参数）和环境上下文（用户身份、时间戳、对话历史记录） |
| 平台 \| LWC | ✅ 在记录中构建 LWC 组件嵌入，以通过“查看原因”链接显示决策历史 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 平台 \| 字段审计跟踪 | 对于需要多年监管保留的高风险决策，依赖标准字段历史（18 个月保留） |
| 平台 \| 自定义对象 | 仅存储当前记录值，而不是决策时间输入快照，因此无法准确重建历史决策 |
| 业务 \| 文档 | ⚠ 无法在决策时记录模型版本和配置状态，导致在发现偏差时无法进行根本原因分析 |
| 平台 \| Event Monitoring | 仅在 Salesforce 中保留审计日志，没有外部 SIEM 流，缺乏监管合规的篡改证据 |

## 持续公平性监控

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| CRM Analytics | ✅ 构建仪表板，显示：按人口细分的决策分布（条形图）、一段时间内的公平度量（带有警报阈值的趋势线）、具有五分之四规则指标的差异性影响率、对决策有贡献的热门预测因素、按人口组的覆盖率 |
| 平台 \| CRM Analytics | ✅ 当输入分配与训练数据人口统计发生显著变化时发出警报；监控分配轮班，指示潜在的公平性下降 |
| Agentforce \| 客服人员配置 | ✅ 将“报告关注”选项添加到 Agentforce 聊天界面；将报告路由到具有完整对话上下文的道德审查委员会；跟踪具有所需调查工作流的自定义对象 |
| 业务 \| 治理 | ✅ 每周监控公平仪表板，在 24 小时内调查阈值违规，每月进行覆盖模式分析，每季度执行全面的公平审计 |
| 业务 \| 治理 | ✅ 使用户能够通过可访问的机制报告感知的偏见；用户报表显示定量度量缺失的定性问题 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 业务 \| 治理 | ⚠ 将偏见检测视为一次性部署前验证，而不是随着客服人员通过提示更新、模型版本更改和数据分布更迭而不断监控 |
| 平台 \| CRM Analytics | 在公平度量违反定义的阈值时，无法配置警报，导致逐渐漂移不被检测到 |
| Agentforce \| 客服人员配置 | 没有为用户提供报告感知偏见的无障碍机制，缺少定量度量无法显示的定性问题 |

## 外部审计支持

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| 集成 | ✅ 构建导出功能，使合规团队能够提取具有人口统计分层的完整决策数据集，供外部审计员审查，同时遵守数据隐私条例 |
| 业务 \| 文档 | ✅ 维护当前文档，涵盖：客服人员目的和预期用例、培训数据人口统计和已知限制、公平度量（部署前和生产）、偏见缓解策略、人员监督配置、监控方法和问责制分配 |
| 业务 \| 治理 | ✅ 在部署客服人员做出相应决策之前，进行算法影响评估，评估利益相关者群体的潜在积极和消极影响 |
| 业务 \| 治理 | ✅ 安排第三方进行半年一次的外部公平审计;保持监管视野扫描，以适应欧盟 AI 法案、国家法律和行业法规 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 平台 \| 集成 | ⚠ 设计客服人员架构时没有预期监管机构、民权组织或客户的外部审计；缺少审核员审核的导出功能 |
| 业务 \| 文档 | 允许文档在客服人员通过即时更新或模型更改而演变时过时，而无需更新公平度量和缓解策略 |
| 业务 \| 治理 | ⚠ 部署客服人员做出相应的决策，而不进行影响评估来评估利益相关者群体的效果 |

## 用户代理和同意

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Agentforce \| 客服人员配置 | ✅ 需要明确选择加入相应的客服人员（信用决策、就业筛选、服务资格），而不是默认激活 |
| 平台 \| 自定义对象 | ✅ 使用字段创建 AI_Consent__c：User_ID、Use_Case、Grant_Date、Grant_Method、Indrawal_Date、Status；为长期同意记录保留启用字段审计跟踪 |
| Agentforce \| 客服人员配置 | ✅ 将同意检查添加到客服人员调用逻辑:处理前查询 AI_Consent__c 的主动同意;支持用例级同意(服务代理与销售代理) |
| 平台 \| 社区/体验站点 | ✅ 构建可从用户简档访问的自助同意管理界面；每 12 个月计划一次同意续订提醒 |
| Agentforce \| 客服人员配置 | ✅ 在部署影响现有用户的新功能时，主动征求新用例的同意，而不是依赖没有考虑特定应用程序的原始同意 |
| Agentforce \| 客服人员配置 | ✅ 通过立即停止客服人员处理，随时启用同意撤销；使撤销如同批准一样简单，无需支持联系人 |
| Agentforce \| 客服人员配置 | ✅ 启用用户首选项管理：通信风格（简洁与详细）、主动级别、升级首选项；存储在用户记录自定义字段中，并在客服人员系统提示中引用 |
| 平台 \| 全方位 | ✅ 在整个交互过程中提供持续的“与人工客服人员连接”选项；在选中时，路由到具有完整对话上下文和优先级标志的全方位，并且不会降低服务或等待时间惩罚 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 客服人员配置 | ⚏ 默认激活相应的客服人员，而用户没有明确选择加入以了解客服人员将如何影响他们 |
| Agentforce \| 客服人员配置 | ⚠ 需要全面的 AI 同意，而不是启用粒度的用例级同意（客户可能会同意服务客服人员，同时拒绝销售客服人员） |
| Agentforce \| 客服人员配置 | ⚠ 撤销同意需要支持联系人或官僚流程，而不是立即生效的自助服务 |
| Agentforce \| 客服人员配置 | ⚠ 在部署原始同意中未考虑的全新客服人员功能时，依赖原始同意 |
| Agentforce \| 客服人员配置 | ⚠ 要求用户在与人工客服人员连接之前完成客服人员交互或解释他们的首选项 |

## 客服人员设计中的不歧视

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| Agentforce \| 客服人员配置 | ✅ 查看客服人员推理中用于受保护特征内容的所有数据源；当决策类型在法律上没有正当理由时，从客服人员输入中删除或屏蔽受保护特征 |
| Agentforce \| 提示模板 | ✅ 在系统提示中包含明确的不歧视说明：无论名称、位置、沟通风格或任何其他特征如何，都要以同等的专业精神对待所有客户。不要根据人口统计特征对客户进行假设 。 " |
| Agentforce \| 客服人员配置 | ✅ 在制作前测试不同的角色：生成相同的请求，只改变人口统计信号（名称暗示不同的种族、位置、沟通风格）；比较对质量、长度、专业性和结果的回应 |
| Agentforce \| 客服人员监控 | ✅ 计算按客户细分划分的首次接触解决率；调查细分之间是否存在显著差异 |
| Agentforce \| 客服人员监控 | ✅ 跨细分的客服人员对话示例，并让审核员通过评级员间可靠性测试，在一致的维度（准确性、完整性、专业性、帮助性）上评估回复质量 |
| Agentforce \| 客服人员监控 | ✅ 跟踪按客户人口统计分层的升级率；某些细分的升级率越高，客服人员对这些用户的效果越差 |
| 业务 \| 调查 | ✅ 调查来自所有人口群体的用户，并比较满意度得分；总体满意度高可能会掩盖少数群体的不良体验 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| Agentforce \| 客服人员配置 | 在客服人员输入中包含受保护的特征数据（残疾状态、宗教、国籍），以便做出这些特征在法律上不成立的决定 |
| Agentforce \| 提示模板 | ⚏ 部署客服人员时，系统提示中没有明确的不歧视说明，仅依赖基础模型行为 |
| Agentforce \| 客服人员配置 | ⚠ 仅测试具有多数人口角色的客服人员，消除对代表性不足群体的偏见 |
| 业务 \| 调查 | 依赖于总体满意度得分，掩盖少数群体的糟糕体验，被大多数人的满意度淹没 |

## 客服人员体验中的可访问性

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| LWC | ✅ 对于自定义聊天实施，请确保：具有正确地标的语义 HTML 结构、宣布新消息的 ARIA 实时区域、消息历史记录中的键盘导航、交互式元素上的明确焦点指示符 |
| 平台 \| LWC | ✅ 在整个开发过程中使用 JAWS、NVDA 和 VoiceOver 进行测试，而不仅仅是自动扫描 |
| Agentforce \| 客服人员配置 | ✅ 配置客服人员回复，以使用普通受众的简单语言；避免使用行话，并提供不可避免的技术术语词汇表；使用标题和项目符号列表构建长回复 |
| Agentforce \| 客服人员配置 | ✅ 通过母语人士评估，验证回复质量在不同语言之间具有可比性，而不仅仅是缺少文化细微差别的自动化度量 |
| Agentforce \| 客服人员配置 | ✅ 对于服务于不同语言群体的关键业务用例，配置特定于语言的处理（语言变量、本地化提示、按语言筛选 Knowledge 文章）并验证每种语言的质量，而不是仅仅依赖基础模型跨语言转移 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 平台 \| LWC | 无需手动可访问性测试即可构建自定义聊天实施（仅依赖自动扫描） |
| Agentforce \| 客服人员配置 | 使用没有词汇表的行话和复杂语言，为用户制造认知障碍 |
| Agentforce \| 客服人员配置 | ⚠ 完全依赖于基础模型跨语言转移，适用于资源较少的语言，为非主流语言用户提供质量下降 |
| Agentforce \| 客服人员配置 | ⚠ 仅通过忽略文化细微差别的自动化度量验证多语言响应质量 |

## 公平治理和部署网关

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 业务 \| 治理 | ✅ 在部署任何生产客服人员之前，建立具有执法权限的道德审查委员会 |
| 业务 \| 治理 | ✅ 定义强制部署网关：数据审计、公平度量计算和算法影响评估 |
| 平台 \| CRM Analytics | ✅ 在首次部署客服人员之前，在 CRM Analytics 中创建基线公平性监控仪表板 |
| 平台 \| Event Monitoring | ✅ 启用 Einstein Trust 层审计捕获，并为客服人员操作配置 Event Monitoring，作为生产前的基础 |
| 业务 \| 治理 | ✅ 在 CI/CD 漏斗中实施自动公平回归测试进行扩展 |
| 业务 \| 治理 | ✅ 随着部署规模的扩大，标准化所有新客服人员的同意管理模式 |
| 平台 \| 集成 | ✅ 构建客服人员决策重建工具，支持合规团队自助服务 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 业务 \| 治理 | 在建立具有执法权限的道德审查委员会之前，部署生产客服人员 |
| 业务 \| 治理 | 将公平性视为事后考虑，而不是相当于安全审查的强制部署门 |
| 业务 \| 治理 | 在部署客服人员做出相应决策之前，跳过算法影响评估 |
| 平台 \| CRM Analytics | ⚠ 部署第一个生产客服人员，但没有部署基准公平性监控仪表板 |