Agentic Enterprise 的资源和成本优化
自主客服人员消耗 Salesforce 资源的方式不同于确定性自动化。客服人员工作量不可预测且持续，而不是固定且受事务约束。资源和成本优化支柱的每成本价值理论直接深入到客服人员企业中。资源效率意味着使用您已经支付的工作量，而成本优化意味着有意将支出用于赢得回报的自主功能。客服人员会更改两者的形状。高效的客服人员设计可以控制消费，定价模型选择、总拥有成本 (TCO) 建模和财务治理可以使支出与价值保持一致。本文档将资源效率和成本优化视为一个决策，因为对于客服人员来说，它们是同一目标的两个视图。
客服人员会更改消耗的可预测性。传统的 Apex 流程在已知资源成本的已知记录集上运行。客服人员通过对话操作，一个对话可以执行几十个操作，作为客服人员执行任务的原因。每个操作都在自己的事务中消耗调控器限制，而不是在对话中累积它们。一次轮次的上下文准备可以查询 200 条记录或 20,000 条记录，这取决于用户的要求。API 消耗加速，因为客服人员可以自主操作，主动、出站和计划的客服人员可以连续操作，而不仅仅是在用户事务期间。这种不可预测性是客服人员资源管理必须经过设计才能防御的原因，而不是在发生消耗高峰后进行调整。
成本方面的变化也是如此。自主客服人员引入了基于消耗的定价，其行为不同于传统的按座位许可。Agentforce 提供两种基于消耗的定价模型，灵活信用和每次对话。每个客服人员部署会选择其中一个模型。组织一次使用一个消耗模型。，但每个用户每月提供的用于未计量使用情况的“每个用户”加载项可以与消耗模型一起分层，以便面向客户的客服人员在员工使用未计量的许可证时运行 Flex Credits 或每次对话。Data 360 通过向量搜索和检索支持客服人员基础训练，并消耗数据处理能力，而 MuleSoft 支持消耗 API 容量的客服人员集成。这些可变成本会随客服人员使用情况而变化，这形成了一种投资模式，需要针对可变性而不是固定年度订阅构建财务治理。
通过批量处理记录的操作、严格的上下文窗口和缓存，为 Agentic Enterprise 中具有优化成本的业务价值设计的解决方案可以保持客服人员的高效消耗。他们还有意通过正确的定价模型、完整的 TCO 建模和针对业务结果的持续成本监控来引导支出。如果没有这种协调，客服人员部署会累积成本，而不会显示成比例的价值，在无边界循环中推理的客服人员可能会比人工监督干预更快地消耗信用。将客服人员保持在调控器限制内的相同效率工作会将其保持在信用预算内，这是用客服人员术语表示的支柱理论。
本文档涵盖了客服人员在照片中时的变化。有关适用于每个 Salesforce 解决方案的基本资源和成本优化模式，包括性能优化、调控器限制、TCO 分析和许可纪律，请参见资源和成本优化支柱。客服人员治理和人员监督与Trust和Fairness支柱相关联,这两个支柱涵盖了保持自主行为安全和问责的方案组成部分。
客服人员资源消耗遵循与 Flow 或 Apex 相同的平台机制，但其不可预测、对话驱动的调用使消耗更难预测，因此需要防御模式。您的优化责任跨越操作链、API 消耗、响应延迟、Data 360 基础效率、上下文窗口管理以及允许客服人员在不重复的情况下扩展的可组合设计。每个责任都是一个基于成本的决策，而不是一个技术性的决策，因为客服人员在每次对话中都会重复低效率。
客服人员调用触发 Apex、流和集成的操作。一个对话可以执行几十个操作，作为客服人员完成复杂任务的原因。基本纪律与任何 Salesforce 解决方案相同，但不可预知的调用模式会提高风险。设计接受集合的操作，以便更新 50 个个案的客服人员调用一个操作，而不是 50 个单独的调用。对记录集合进行操作的单个操作对相同工作的 Salesforce 对象查询语言 (SOQL) 查询和数据操纵语言 (DML) 操作消耗更少。请谨慎地跨操作链管理 SOQL 预算，因为当每个操作运行自己的几个查询时，调用 10 到 15 个操作的工作流可能会接近或超过 100 个查询的同步限制。使用关系查询在单个语句中检索父级和子级数据，并在相同对话中的操作之间引用平台缓存中缓存的数据。这两种实践在其预算中保持了多操作链。
将超出同步限制的客服人员操作移到可排队或批处理 Apex，其中异步上下文大约使工作的 SOQL 和 CPU 剩余空间增加一倍。大型分析操作，例如对 1000 个潜在客户评分或跨历史个案分析情绪，属于异步处理，而不是阻止对话。大语言模型推理本身发生在 Salesforce 外部，并消耗 Flex Credits，而不是 Apex CPU 时间，因此，客服人员触发的操作逻辑、数据转换和集成会消耗您简档的 CPU 预算。父级记录与数千个子级记录相关联的数据偏差场景值得客服人员特别注意。出现此漏洞是因为客服人员可能会以确定性查询从未有过的方式请求拥有成千上万条相关记录的客户“所有历史”。设计具有硬子记录限制和分页的操作，并在数量超过数据偏差阈值时应用抽样。这些限制阻止了不可预知的请求变为没有边界的查询。Agentforce 会话跟踪识别哪些操作在会话级别消耗过多的查询，规模中心监控整体 Apex 事务性能和组织运行状况。
客服人员架构使用 API 的速度比用户驱动的工作流更快，因为客服人员可以自主操作，对于主动或计划的客服人员，也可以连续操作。客服人员的显示方式决定了如何减少 API 容量。通过 REST API 调用的客服人员每次对话轮次消耗一个呼叫。通过标准组件嵌入 Lightning 页面的客服人员不会消耗每次交互的 API 调用，尽管他们的成本仍然以所选定价模型的信用或对话来衡量。进行直接 REST 调用的自定义 Lightning Web 组件会消耗 API 容量。基于 Lightning 数据服务有线适配器构建的组件不会，因为 Lightning 数据服务从共享客户端缓存提供服务，而不是发出 API 调用。在试用期间监控 Event Monitoring 中的消耗，以便在全面推出之前了解实际使用情况。
事件驱动的模式是浪费客服人员 API 的最大杠杆。当条件需要客服人员干预时发布平台事件可以避免无论是否有工作都要消耗 API 调用的计划轮询，订阅变更数据捕获事件的客服人员可以保持当前上下文，而无需外部编配员进行日常轮询调用。每成本价值逻辑是直接的：没有工作的轮讯等于白花的容量，而只对实际变化触发的事件等于只对实际工作花费的容量。检索扩充生成会添加自己的消耗，因为针对 Data 360 的每个向量搜索都会消耗计算，所以设置检索限制，以仅返回客服人员实际使用的结果。
客服人员轮次的延迟是这些步骤按顺序运行时 LLM 推理时间、操作执行时间、Data 360 查询时间和集成时间的总和。当它们没有时，它是最长的并行分支加上任何顺序步骤。延迟是成本问题，也是体验问题，因为缓慢的操作会使资源打开的时间更长，并且沮丧的用户开始的对话比已解决的对话要多。较短的提示会生成更快的响应，因此可以删除繁琐的说明、冗余示例和不必要的上下文。选择性上下文会改善延迟和回答质量，其中穷举上下文转储只会增加噪音。通过对索引字段、批量化和缓存参考数据的选择性 SOQL 保持操作快速，因为无论推理有多快，3 秒的操作都会成为瓶颈。使用查询计划工具验证操作查询，以识别增加操作延迟的全表扫描。
客服人员生成器编配可以在它们之间不存在依赖性时并行执行操作，例如，同时检索客户详细信息和相关业务机会的时间与两者中时间较短者相同，而不是两者的总和。对于扇出到多个下游系统的调用，将 Agentforce 与集成平台（例如 MuleSoft）配对；客服人员调用单个操作，MuleSoft 接收请求并向后端系统发出并行调用，然后返回一个聚合响应。平台缓存消除了重复请求的推理和查询延迟，并异步处理非紧急工作，例如长文档分析，允许客服人员立即确认请求，并在准备就绪时返回结果，而不是保持对话打开。
Data 360 提供向量搜索，将客服人员响应作为当前数据的基础，而不仅仅是模型的训练数据，其效率控制基础质量和您实现基础质量所需的计算机。分块、嵌入选择、元数据筛选和结果限制是最有价值的决策。将 Knowledge 分为语义有意义的分段，因为太小的分段会强制对一个问题进行多次检索，而太大的分段会稀释与不相关上下文的相关性，并膨胀推理中的令牌预算。选择与客服人员实际查询方式匹配的嵌入模型，因为问答相似性的行为不同于文档分类，并根据代表性查询验证选择。将语义相似性与元数据筛选器相结合，以便无论相似性如何，业务约束都保持不变，例如，无论匹配多么接近，都将停用的产品从推荐中排除。设置 top-k 限制，以仅返回客服人员使用的结果。例如，如果 5 个结果通知答案，检索 50 会将 45 个未使用的结果添加到基础负载和令牌预算中。
统一简档节省资源，因为查询一个 Data 360 统一简档的客服人员在单个操作中检索完整的客户上下文，而不是针对每个轮次的客户、联系人、业务机会、个案和市场活动编排单独的查询。在监管要求的区域配置 Data 360 实例，以便处理指定管辖区数据的客服人员查询保存个人数据的实例。
大语言模型上下文窗口包含有限数量的令牌，管理该预算会使长时间的对话保持一致，而不会耗尽工作量或增加每次推理调用的成本。有意确定优先级，而不是任意截断：最近的对话历史记录优先级最高，当前记录状态和权限等关键业务数据位于第二，只有当空间允许时，才会包含旧历史记录。在最初的几次轮次后，将之前的对话总结为简洁的概述，保留关键事实，而不进行完整的逐字记录。该汇总保留了连续性，而不会增加令牌预算。将扩展上下文存储在 Data 360 或自定义对象中，作为按需查询的外部存储器，而不是在每次调用时重放完整的历史记录，并仅返回每个操作中的基本字段，因为当任务需要 8 时，一个带有记录所有 50 个字段的响应会将上下文预算更好地分配给对话或基础训练。
从可重用组件构建代理可以减少开发和维护成本。构建一次并重复使用的功能在其生命周期中比为每个客服人员重新实施和单独维护的相同功能便宜得多。通过涵盖记录操作、批准、通知和验证的集中操作库，平台团队可在每个消耗客服人员之间保持一致的行为、安全性和性能，并让新客服人员在几天内从经过验证的构建块中组装，而不是在几周内从自定义操作中组装。与尝试每个场景的单个通用客服人员相比，具有明确域边界的专注专家客服人员保持更窄的上下文和更清晰的行为，客服人员生成器编配会在任务跨域时协调专家。提示生成器中经过验证的提示模板捕获经过验证的模式，用于基础训练、推理和回复格式化，以便随着开发的加快，质量保持一致，并且 Data 360 中的共享 Knowledge 库将来自一个来源的许多客服人员作为基础训练，因此更新可以一次到达每个消费者，而不是要求对每个客服人员进行更改。
企业团队越来越多地将多个客服人员组合在一起，而不是构建单个整体客服人员，编配人员客服人员分解请求并委派给专家子客服人员，或者专家客服人员在对话跨域移动时相互交接。这种组合带来的资源和成本问题超出了单个客服人员所面临的范围，因为编排开销、客服人员间Trust和状态切换是整个链中的所有复合，而不是局限于一个操作。保持编配提示的范围窄，仅限于分类意图和路由，而不是要求编配员也说明基础任务的原因，因为该推理属于具有相关上下文和上限链深度的子代理，除非用例明显需要比编配员到子代理更深的嵌套。将每个子客服人员响应视为不可信输入，如同您对待外部 API 响应。在采取行动之前，请验证其预期形状是否符合业务规则。为每个客服人员操作单独实施字段级安全性和共享。
仅传递接收客服人员需要的状态，使用记录 ID、任务汇总和相关字段的结构化切换负载，而不是转发原始对话历史，因此整个链中的令牌预算保持可控，并在切换必须在单独事务中生存时，在 Data 360 或自定义对象中保留跨客服人员会话状态。调控器限制适用于每个客服人员，而不是每个对话一次，因此，链中的每个客服人员都有自己的 SOQL、DML 和 CPU 预算。一个编配器和三个子客服人员的链消耗了其中每个限制的四倍，更深的链消耗进一步增加。相同的乘法提高了成本，这使得无限链深度的成本风险大于调控器限制的风险。
定义编配器在子代理失败、超时或返回低置信度结果时执行的操作，无论是有界重试、后备响应还是升级为人工，这样单个子代理超时不会级联到整个链失败。将每个客服人员之间的请求与通过切换负载传播的共享跟踪 ID 进行关联，因为诊断链中哪个客服人员导致了延迟峰值或成本峰值，否则需要手动关联不同客服人员会话之间的日志。
失败的操作和失败的子客服人员调用不仅影响可靠性，因为每次重试都会重新运行已经花费在失败尝试上的 SOQL、DML 和 CPU 工作，并且在多客服人员链中，这个代价会与失败的下游客服人员的数量一起增加。在基于消耗的定价中，相同的故障复合支出和计算：重试操作会重新消耗 Flex Credits 下的信用。设计重试逻辑，以考虑可靠性和成本。在决定如何响应之前，将临时故障（例如调出超时或锁定竞争）与逻辑故障（例如验证错误或输入格式错误）区分开来，因为临时故障可能值得有界重试一次，而逻辑故障在重复时同样失败，并且只消耗了应立即升级的保证重复故障的预算。
将每个操作的重试次数上限为 2 次或 3 次，并在它们之间应用指数回退，而不是立即重新调用，因为对 SOQL 或 DML 繁重的操作进行无边界或紧密循环重试可能会耗尽单个事务中的同步限制，或者耗尽多客服人员对话中的累积链预算和累积信用支出。设计操作，以便重试的呼叫产生与单个成功呼叫相同的结束状态，使用兑换密钥，例如带有更新插入逻辑的请求 ID 或外部 ID，而不是插入，因此重试会更新相同的记录，而不是创建重复的记录；缺少兑换的操作会强制重试通过重复的下游记录将资源消耗增加一倍，或者将已经发生一次的工作的计费操作或对话增加一倍。
跟踪链中每个客服人员的完成状态，因为一个客服人员的操作可以在下游客服人员失败之前成功提交 DML，而知道已经成功的故障处理器可以从故障点补偿或恢复，而不是重新启动整个链并重新计费。在有界重试进行时，向最终用户显示重试或正在进行的状态，因为看到沉默并重复其请求的用户会触发全新的对话和一组新的操作，从而将原始尝试的资源和计费成本与重复尝试混为一谈。
本文档中描述的资源优化模式仅在架构师可以看到客服人员在生产中运行时实际花费 SOQL 查询、CPU 时间、DML 行和令牌的位置时有用。如果没有每个操作和每个会话的可见性，限制违反或延迟回归就会显示为一种症状，无法追溯到导致它的链中的操作或客服人员。这种担忧不同于 Digital Wallet 在成本监控和财务治理下提供的支出可见性。Digital Wallet 显示在单个查询、DML 行或导致消耗的操作级别上，客服人员消耗了多少信用或对话，而工具会显示消耗原因。正确的工具取决于给定客户的组织和支持协议实际授予的内容，而不是理论上哪个工具最好，因此将推荐与您的许可证和访问层相匹配，而不是默认为功能最强大的可用工具。
任何架构师都可以构建自定义平台事件，在每个操作和子客服人员调用的开始和结束时触发。这些事件仅使用标准平台功能跟踪对话的执行，并与操作级日志记录相结合，记录自定义对象在执行每个操作时捕获的 SOQL 查询计数、CPU 时间、DML 行数和堆使用情况。这两个事件都可以通过报表或 SOQL 进行查询，并为每个组织提供了基准诊断功能，而不管版本或加载项许可证如何。Event Monitoring（此前引入用于跟踪试点期间的 API 消耗）还为其组织包含该加载项的客户展示了组织范围内客服人员会话的聚合资源使用模式，让架构师识别哪些工作流在多个对话中趋向调控器限制，而不是一次诊断一个。规模中心提供接近调控器限制的交易的深度跟踪，通常通过支持参与访问，或直接在授予支持参与的客户层获得。
版本控制客服人员独立地使受控的推出、回滚和比较成为可能，并且在您改进工作客服人员时，它可以保护对工作客服人员的投资。使用自定义元数据类型和提示生成器，尽可能通过配置来驱动行为，以便管理员在没有开发周期的情况下调整提示模板和操作选择。使用试用 A/B 测试功能将一小部分用户路由到实验版本。在全面推出前，比较质量、满意度和任务完成情况。这种比较验证了实际使用的改进，并检测了回归，同时限制了暴露。定义组件之间的明确接口合同，指定输入、输出、错误和性能预期，以便可以替换实施，而无需修改依赖它的客服人员。
客服人员经济性始于根据业务价值衡量的总拥有成本，但自主客服人员基于消耗的定价使成本方面的行为与传统许可不同。您选择的定价模型是一个基本的架构决策，因为它决定了您在整个客服人员生命周期中优化的内容。本节建立定价模型、客服人员实施的完整 TCO 情况，以及客服人员功能的构建与购买决策。
Agentforce 提供两种基于消耗的定价模型，组织为给定的客服人员部署选择两种模型中的一种。每个客服人员操作的灵活信用价格，使操作效率成为成本控制的杠杆。无论对话的长度或复杂性如何，每次对话定价都会收取固定的费用，这使得对话遏制成为杠杆。每用户订阅将未计量的客服人员使用情况作为面向员工的加载项，而不是第三种消费模式，并将优化重点从消费效率转移到采用，因为价值来自授权用户积极吸引客服人员，而不是最小化每次交互。对于同一个组织，这两种消耗模型不是混合的，但是对于未计量的使用情况，每个用户每月提供的“每用户”加载项可以与消耗模型一起分层，这样，在员工使用未计量的许可证时，面向客户的客服人员可以使用 Flex Credits 或每次对话运行。
在 Flex Credits 中，每个操作的操作成本是固定的，直到定义的令牌上限。与基于令牌的推理定价不同，信用成本不随提示长度或模型复杂性而变化，因此单句答案和多段答案的成本相同。多操作交互消耗每个操作的信用，因此检索数据、原因和更新记录的交互消耗三个操作的信用，检索扩充生成在推理之前通过向量搜索和文档检索添加更多操作。因此，了解每个业务交易的平均操作数量是 Flex Credit 下的成本建模的先决条件。
在每次对话定价下，每个对话适用固定费用，一个会话中的多个轮次视为一个对话，因此成本控制来自在一个对话中解决问题和定义明确的会话边界，而不是修剪单个操作。Data 360 基础和 MuleSoft 集成会与选定模型一起消耗自己的容量，因为嵌入生成和相似性搜索会消耗每个基础查询的数据处理能力，并且每个外部操作都会消耗源和目标系统中的 API 容量。
客服人员实施的总拥有成本 (TCO) 跨越六个类别，对所有六个类别进行建模会将信用评估转化为明智的投资决策。开发成本包括客服人员设计、提示工程、集成开发和测试,范围很广,从简单的单一用途客服人员到具有复杂编排的多客服人员系统。推理成本取决于选定的定价模型，并需要建模 Flex Credits 下的预期操作量、每个对话下的对话量或每个用户下的许可用户计数。对于基于大型 Knowledge 库的客服人员，支持基础训练的 Data 360 基础设施可以媲美或超过推理成本。基础设施成本涵盖了 Data 360 和 MuleSoft 许可、额外的 Sandbox 和监控基础设施,并且它们主要是基于容量层的固定或步骤功能。运营成本包括监控操作、及时优化、事件响应和用户支持,对于成熟的客服人员计划,它们通常相当于每年开发成本中有意义的一部分,这与 AI 客服人员的一般行业基准相一致,而不是与 Salesforce 特定的数字相一致。治理成本涵盖安全审查、人工监督、审计日志记录和合规验证,这些成本随着客服人员的自主权和风险的增长而增长,公平性支柱涵盖基本计划组件。变更成本涵盖用户培训、业务流程调整和组织变更管理，并且是团队最常低估的类别。
构建电子表格 TCO 模型，预测 3-5 年的成本。记录交互量、操作计数和增长的假设。运行敏感性分析，以确定对总数影响最大的假设，然后将验证集中在这些假设上。在提交前，根据预计使用情况对所有三种成本结构（灵活信用、每次对话和每次用户）进行建模，因为最佳结构取决于使用模式，而一旦客服人员投入生产，错误的选择将花费高昂的成本。
客服人员的“构建-购买”决策遵循与任何 Salesforce 功能相同的逻辑，根据 3–5 年 TCO 范围内自定义构建的精确适用性，权衡现成解决方案的价值实现时间。商品工作流倾向于购买，而推动专有差异化的核心功能证明构建是正确的。Agentic Enterprise 提供一系列选项，而不是二元选择。预构建的 Agentforce 客服人员，例如服务代理或销售开发代表，通过快速部署和平台维护的更新提供成熟的功能。他们在选定的定价模式下消耗信用。Salesforce 独立软件供应商 (ISV) 社区的商用客服人员通过 AgentExchange 提供，您可以在其中找到已经满足要求的解决方案，而不是构建它。使用客服人员生成器构建的自定义客服人员提供了精确的拟合和竞争差异化，其代价是前期开发以及持续的即时优化和维护。通过提示生成器和操作配置自定义预构建的客服人员提供了比完全自定义开发成本更低的中间环节，同时仍然使客服人员适应您的组织。除了成本之外，还要权衡价值实现时间要求、内部开发能力、战略差异化和供应商依赖性容忍度，并将决策记录在架构决策记录中，以便可以在需求变化时重新评估。
对于基础成本结构有清晰了解的实施客服人员，可以可持续地扩展自主能力，而不是耗尽预算池。优化杠杆取决于定价模型，因为您调整以控制成本的内容在每次操作付费、每次对话付费和每次用户付费之间有所不同。所有这三个原则都是恒定的：根据实际交付的价值调整消耗，这样有能力的客服人员就不会悄悄消耗掉预算，而不是返回业务结果。
在 Flex Credits 中，优化意味着在保留质量的同时最小化每个业务结果的操作。通过单个操作而不是多步骤工作流解决简单请求，这样回答常见问题或执行常规查找就不会消耗三操作链的信用。将操作整合到有意义的单个操作中，将检索、分析和响应结合起来，而不是在一个操作提供服务时单独为每个操作付费。缓存重复请求的响应，以便常见问题从缓存中提供，而不是在每个相同的查询上消耗新的操作，这是该模型下当有意义的查询重复时的最大效率杠杆。
在每次对话定价下，优化意味着在单个对话中解决问题，而不是跨几个对话。设计会话边界和超时，以便对话适当持续，而不会过早终止并强制进行新的可计费对话。将客服人员的能力集中在首次对话解决上，以便在初始对话中完成任务，而不是需要跟进。跟踪首次对话的解决率作为成本效益度量，并阻止用户在为现有对话上下文可以处理的相关问题打开单独对话时扩大范围。
在“每个用户订阅”下，优化意味着最大化每个许可用户返回的价值，因为消耗量是未计量的，每个座位的成本是固定的。重点关注采用，以便获得许可的用户积极参与客服人员，跟踪利用率，以确定低用量用户进行有针对性的培训或许可证重新分配，并将客服人员的互动与用户群体的业务结果联系起来，以便高价值用例证明投资的合理性，而低价值使用表明需要优化或不同的定价模型。在节奏上审查用户群，以便许可证与实际使用保持一致。
无论定价模型如何，架构都会影响成本。实施分类客服人员，这些客服人员使用简单逻辑处理初始路由，并仅在复杂性需要时将用户定向到专用客服人员，以便仅在需要时进行昂贵的复杂调用。对于基于规则的逻辑就足够了的确定性场景，回归传统的自动化，让流以更低的成本处理确定性路径，而客服人员处理真正需要推理的模糊情况。有选择地检索基础数据，仅在客服人员的推理需要时调用向量搜索和文档检索，而不是每次交互时，以便 Data 360 消耗跟踪实际需求。这些模式使架构的推理和消耗成本与工作难度成正比。
自主客服人员的成本监控比传统工作负载更难，因为客服人员没有遵循可预测的请求-响应模式。客服人员可以通过多步骤推理迭代，根据运行时条件自适应调用工具，并协调其他客服人员，这会产生难以预测的高度可变的信用消耗。在没有监控的情况下，执行深度迭代工作的客服人员会在任何人干预之前消耗大量信用，低效的提示设计或冗余的推理循环会悄悄耗尽整个客服人员团队的预算。因此，有效的治理需要实时了解每个客服人员和每个操作的消耗量、自动警报以及防止成本失控的控制，同时保持使客服人员有用的自主权。客服人员的财务治理也需要明确的所有权，并为可变消耗而不是静态计算成本构建分层批准。
Salesforce Digital Wallet 是用于监控基于消耗的产品（包括 Agentforce Flex Credits）的内置工具，使用 Flex Credits 的组织应将它建立为主要的成本监测机制，而不是构建自定义仪表板来复制它所提供的内容。Digital Wallet 提供近乎实时的消耗数据，其中包含操作级使用见解、显示哪些客服人员消耗最多的每个客服人员细分、主动消耗警报以及用于模式分析和预测的历史趋势。将监控与定价模型匹配。在 Flex Credits 中，按客服人员、用户群体、时间段和操作类型跟踪消耗情况，并使用将信用消耗与业务交易联系起来的自定义仪表板补充 Digital Wallet。在“每次对话定价”下，监控对话量、平均长度和完成率。在“每个用户订阅”下，监控使用率而不是消耗量，跟踪每个用户的活跃用户和业务价值，以便显示许可证投资提供成比例的价值。
每个交互成本属性将消耗与业务交易联系起来，并揭示每个已解决个案、每个合格潜在客户或每个已处理订单的成本，这可实现 ROI 计算和跨用例比较。当消耗接近定义的阈值时，预算提醒会触发通知，例如预算的 70% 和 85%，以便在达到限制之前进行优化。配置每个客服人员和每个用例的警报，而不仅仅是组织范围内的警报，以将问题定位到其来源。异常检测显示突然消耗峰值，这表示意外的使用模式或需要调查的推理循环。与业务利益相关者和技术团队共享成本仪表板，以便透明度提高客服人员的成本意识。
在将支出提交到客服人员架构之前，应用财务治理。需要代理投资的业务个案，该投资涵盖所选定价模型下 3–5 年的预测 TCO，使用测量方法的预期业务结果，与手动流程和传统自动化等替代方法的比较，以及涵盖质量、安全和运营风险的风险评估。定义批准阈值，将部门可以授权的投资与需要主管批准的投资区分开来，以便高投资或高风险客服人员接受相称的审查。要求进行试点部署，在完全生产之前验证假设，因为试点揭示了实际消耗、质量和采用情况，为生产投资决策和定价模型选择提供信息。
将客服人员资产作为产品组合管理，而不是逐个客服人员管理，因为产品组合视图揭示了单个客服人员审核错过的优化机会。一起查看所有客服人员，比较成本、使用情况、业务价值和战略一致性，并定义日落标准，淘汰采用率低、投资回报率低、功能过时或成本过高的客服人员，这样低价值客服人员就不会无限期地累积和消耗预算。将投资从表现不佳的客服人员重新分配到高价值的业务机会，这是一种持续的实践，根据不断变化的优先级调整支出，而不是一次性清理。
成本分配为客服人员消费创建了问责制，组织通过适用于平台其余部分的相同两种模型来实施它。无内部费用的显示报表按业务部门划分的客服人员成本，这可以培养成本意识，并为优化讨论提供信息，而无需内部计费。按存储容量使用计费将实际客服人员成本分配给消耗业务部门，这推动了更强的优化行为，因为成本直接影响部门预算，但它需要准确的分配方法以避免争议。混合方法将按存储容量使用计费应用于高用量生产客服人员，同时对试验性或低用量客服人员使用显示计费，这平衡了主要投资的责任和创新的灵活性。
客服人员架构引入了自己的可持续性注意事项，因为大语言模型推理计算量很大，一些客服人员连续运行，而不仅仅是在离散的用户触发的事务中。主动、出站和计划的客服人员在循环中没有用户的情况下操作，对话客服人员在许多轮次中累积消耗，向量搜索、上下文准备和操作执行都会增加基础设施负载。可持续客服人员设计最大限度地减少了计算浪费，同时保持体验的响应性。与资源和成本优化支柱一样，一个解决方案与数据中心排放之间的关系是间接的。单个租户的效率不会直接降低排放量。但是，所有租户的效率提高有助于 Salesforce 以更高的利用率运行其基础设施，并推迟容量扩展。资源和成本优化支柱中的基本可持续性实践适用于客服人员，以及随后的效率策略都解决了特定于大语言模型支持的对话系统的问题。两者还降低了成本，这就是为什么可持续性和每成本价值是衡量不同结果的相同学科。
推理是代理架构中资源最密集的组件，因此提示长度、上下文使用情况和缓存是效率的回报。通过删除繁琐的指令和冗余示例，优化提示，以更少的令牌传达意图，因为较短的提示会按比例减少预填充计算，即使它不改变生成响应的计算。通过在前几次轮次后汇总对话历史并仅返回每个操作中的基本字段来管理上下文窗口，以便每个推理中携带的令牌预算保持有界，而不是随着对话的增长而增长。
向量搜索和统一简档查询会消耗计算资源，因此控制接地成本的相同结果限制和筛选纪律也会降低接地的基础设施负载。设置 top-k 限制，以仅返回客服人员使用的结果，因为在 5 通知答案时检索 50 会携带 45 个未使用的结果，这些结果消耗基础令牌预算而没有好处，并且使用元数据筛选器在相似性排名之前缩小搜索范围。查询统一简档，以便在一次操作中汇编完整的上下文，而不是每次轮次都对几个对象发出单独的查询，并为具有高用户相似性的客服人员缓存简档，例如处理一组固定客户的销售客服人员，这样重复的上下文汇编就不会重复查询。
客服人员操作消耗 SOQL 查询、DML 操作和 CPU 时间，因此资源和成本优化支柱的批量化、缓存和异步纪律直接应用于客服人员操作。设计接受集合的操作，以便更新多个记录是一个操作，而不是多个操作，使用关系查询在单个语句中检索父级和子级数据，在平台缓存中缓存引用数据，并在集合中而不是在每个记录中批量处理 DML。将超出同步限制的操作移到可排队或批处理 Apex，异步处理批量评分或历史丰富等非紧急工作，并尽可能为非高峰时段计划客服人员触发的批处理作业，以便负载在时间上分散，而不是集中在工作时间。监控异步执行，以便队列待办事项在失败前发出容量规划需求的信号。
客服人员的消费模式会随着使用情况的增长而变化，因此可持续性需要持续监控，而不是一次性的。通过可用的使用情况遥测跟踪每个推理的平均令牌，以便不断增加的提示大小显示优化机会，监控对话长度分布，以便没有边界的对话揭示任务边界问题，并在 Event Monitoring 中分析操作执行频率，以便高频操作成为优化优先级。查看 Data 360 查询模式，以查找值得缓存或预计算的常见查询，跟踪语义缓存命中率，以便低速率触发阈值调整，并测量延迟百分比，以便尾部延迟暴露出任何瓶颈。定期审查客服人员使用情况，了解范围偏差。例如，调查平均对话时间在几个月内从几轮增长到多轮的客服人员。细化客服人员的边界，以便消耗返回到计划。其中一些监控表面公开了聚合仪表板的使用情况，而不是作为离散的每个推理日志，因此在设计监控时请确认配置可用的精确遥测。
资源优化确定客服人员架构是否随着人口增长和用例扩展而扩展，成本优化确定该规模是否返回成比例的业务价值。这两项决定构成一项单一任务：
- 架构效率：通过批量化设计操作，跨操作链预算 SOQL，将繁重的处理转移到异步，通过复合和事件驱动的模式优化 API 消耗，通过优先级和汇总管理上下文窗口，并从可重用组件构建可组合架构。
- 财务指导：有意选择定价模型，在承诺前对完整的 TCO 进行建模，根据业务结果监控消耗，并通过分层批准和投资组合审查来管理投资。
掌握这些模式的组织在平台约束内提供响应式客服人员体验，同时使支出与客服人员返回的价值保持一致。
所有 Salesforce 解决方案的基础资源和成本优化指导，包括性能优化、调控器限制、TCO 分析、许可纪律和成本治理，都位于资源和成本优化支柱中。客服人员治理、人员监督和安全计划组件连接到 Trust 和 Fairness 支柱。本文档中详细的客服人员实施指南（涵盖资源效率、经济性、操作优化、治理和可持续性）在客服人员模式库中收集。