--- schema_version: "1" id: b28382ac2ab3e0af5b166d4c77afaff8ab0eddd9f388a67b6920306d4b45c4df title: 代理企业 collection: architect version: current locale: zh-cn portal_url: https://docs.salesforce.com/architect/current/zh-cn/well-architected/guides/agentic-enterprise.md canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/well-architected/guide/agentic-enterprise.html source_site: architect.salesforce.com content_type: documentation content_hash: e09de7adf37854ac00febd08527af8dbdd912a9f51171372f840ea428d20121d products: - 架构良好的框架 - Architect Site Content Repo --- # 代理企业 ## 概览 Agentic Enterprise 代表了公司如何使用 AI 的根本转变。它从需要人类不断指导的被动工具转变为自主的客服人员，他们能够自己感知、推理和行动，同时与人类的意图保持一致。在这样的组织中，人类、客服人员和平台在受管业务系统中协同工作，以提供无法单独实现的结果。 本文档是[结构良好框架](/docs/architect/zh-cn/well-architected/guide/framework.html)的附录。该框架的五个支柱 -- -- Trust、可靠性、卓越运营、资源和成本优化以及公平性 -- -- 提供了适用于*所有* Salesforce 解决方案的基础指导。此概述解释了当解决方案成为代理时会发生什么变化，并为您指出了逐柱的详细信息。 代理系统结合了大型语言模型、检索扩充生成、函数调用和编排模式，以创建适应上下文的功能，而不是遵循僵化的编程路径。客服人员将概率推理（LLM 推理）与确定性执行（工作流和编排）结合起来，以实现适应性和治理。 对于架构师，这种行为会在每个支柱中引入设计注意事项。客服人员在其推理层中使用非确定性行为进行操作，这需要可靠性、监控和控制的新模式。客服人员自主权要求增强安全边界和在环人员监督。多客服人员协调会产生紧急的复杂性，需要精心编排。Agentic Enterprise 不仅仅是将 AI 功能添加到现有架构中，它还重新想象了系统的设计、部署和治理方式。 做得好，这种组合可以创造真正的业务价值：客服人员处理以前需要人工干预的复杂、多步骤的工作流，跨来源综合信息，并在整个组织中扩展专业知识。它还引入了需要精心设计的挑战。非确定性行为会使测试、监控和错误处理复杂化。自主权提出了控制、问责和安全的问题。成本结构从固定基础设施转移到可变推理消耗。架构师必须平衡自主权与风险、创新与控制以及能力和成本。 > ### 帮助与行为 > > 客服人员架构中的一个根本区别是客服人员是*协助*人工（副驾驶模式：建议、推荐、起草）还是自主*行动*（客服人员模式：决定、执行、完成）。副驾驶需要人工批准状态修改操作；客服人员在权限范围内独立操作。这种区别决定了 Trust 要求、可观察性需求和监督模式。从帮助转向行动是架构的转变，而不是配置的变化，它需要通过自主操作的镜头重新评估每个支柱。 ## 统一系统：人员 + 客服人员 + 平台 Agentic Enterprise 是人员、客服人员和平台在受管业务系统中协同工作的组织，以提供无法单独实现的结果。这个由三部分组成的模型塑造了每个架构决策： - 当客服人员能力不足或利益攸关时，**人员会**提供监督、判断和干预。通过客服人员协作，客服人员可以专注于高价值判断，而处理日常执行和信息综合。人员在系统级别保持控制：他们定义边界，客服人员在其中决定和采取行动。 - **客服人员**提供智能自动化、自然语言界面和自适应决策。客服人员不是独立的功能，而是业务工作流的集成参与者。他们从受管数据中感知上下文，使用概率性和确定性技术推理适当的操作，并通过业务工作流和外部集成采取行动。 - **平台**提供了使客服人员工作成为可能的受管基础架构 — 累积的业务逻辑、统一的数据、编排和协作基础架构。该平台将企业级客服人员系统与不受监管的 AI 实验区分开来：它强制执行权限、维护审计跟踪、应用合规规则，并使客服人员在组织治理中运行。 移除人员，您将失去责任感；移除客服人员，您将失去智能；移除平台，您将失去治理。Agentic Enterprise 需要将所有三个作为统一系统。 ## 客服人员需要的功能 任何代理架构（在任何技术堆栈上）都必须提供一组通用的功能。客服人员需要可信的数据来推理，需要可以安全操作的业务逻辑，需要在其生命周期中进行治理，需要共同理解数据的含义，以及需要上报到人员的路径。这些是架构要求，而不是产品：在 Salesforce 提供部分堆栈的情况下，剩余功能仍然需要关注。 Salesforce 将这些功能作为集成集提供。将它们视为系统会使依赖性变得明确：削弱任何依赖性，客服人员以可预测的方式受到限制。本节介绍每项功能，为何对客服人员重要，以及 Salesforce 如何提供。 ### 受信数据和上下文 客服人员需要经过监管和验证的数据才能有效推理 — AI 模型从训练数据中知道模式，而不是从公司的客户记录、产品目录或交易历史中知道。此功能通过将客服人员定位在准确、允许、最新和可跟踪的数据中，而不是任意 Web 内容或未经验证的来源中，弥补了这一差距。 - **当前业务数据**支持对时间敏感的决策:商业代理回答*"我的订单*状态如何?"、服务代理显示未结个案或销售代理排名本季度结束的业务机会。 - **历史数据** — 例如，Data 360 中保存的大型数据集 — 支持趋势分析、预测和从过去的模式中学习。 - **聚合访问**允许客服人员对任何地方的数据推理。它减少了连接的源的重复，并提供了统一的视图。 *Salesforce 通过 Data 360 产品组合提供此功能。* > **架构含义：**客服人员质量取决于数据质量。投资于数据治理、分类和谱系。显示错误数据的客服人员比显示"我不知道"的客服人员更快地削弱 Trust。 ### 业务逻辑客服人员可以通过 只能回答问题的客服人员是副驾驶。可以创建记录、更新业务机会、发送通信和触发自动化的客服人员是自主的。这种自主权允许客服人员*采取行动*，而不仅仅是*提供帮助* — 它调用现有的、经过良好测试的业务流程，而不是在生成的代码中重新实施它们。 - 客服人员将自然语言意图转化为标准业务操作，而不是要求用户编写代码。 - 客服人员将权力下放到封装的多步骤流程（例如，处理信用检查、库存更新和通知的退款流）。 - 随着业务规则的发展，客服人员会自动继承更改，前提是逻辑存在于工作流中，而不是反映在客服人员的说明中。 *Salesforce 通过 Customer 360 业务逻辑和平台自动化提供这种能力。* > **架构含义：**设计客服人员来调用现有的工作流，而不是替换它们。调用经过验证的自动化的客服人员比通过生成的代码重新实施业务逻辑的客服人员更加可靠。 ### 客服人员生命周期的治理 客服人员需要从开发到部署、监控和停用的治理。如果没有它，不受控制的客服人员扩散就会产生影子 AI：客服人员权限不明确、没有审计跟踪、行为未经测试，成本未知。此功能确保客服人员使用防护栏构建，通过批准门部署，监控偏差，并在不再需要时停用。 - **开发工具**从自然语言描述生成初始配置，并在设计时实施防护(权限验证、子代理范围)。 - **运行时编排**管理客服人员调用、权限实施、审计日志记录和失败处理。 - 可**重用功能**允许团队采用预构建的客服人员和行动，包括垂直领域专家功能，而不是从头开始构建每个客服人员。 - **会话可观察性**存储客服人员交互、推理步骤和结果，用于分析、调试和漂移检测。 *Salesforce 通过 Agentforce Studio、Agent Fabric 和 AgentExchange 提供此功能。* > **架构含义：**将客服人员视为受管资产，而不是一次性脚本。系统级别的治理可以防止客服人员蔓延。 ### 对数据含义的共同理解 查询数据的客服人员需要了解语义：“收入”是什么意思，哪个字段是“客户名称”，表是如何关联的。如果没有共享的语义定义，客服人员会生成使用错误字段、误解空值或违反业务规则的查询。使用一个，每个客服人员查询受管定义并返回一致、正确的结果，会计日历和收入确认逻辑位于定义中，而不是客服人员提示中。该层在平台的本地安全模型中操作：访问权限由平台自己的行级和字段级控制控制控制，而不是在语义层中重新实施。因此，客服人员受平台强制实施的相同数据权限的约束。 *Salesforce 通过与 Tableau Next 和 Data 360 集成的受管语义层 Tableau 语义提供此功能。* > **架构含义：**在部署 Analytics 代理之前，定义语义层。查询原始表的客服人员会产生治理差距和不一致的结果。 ### 升级到人类的路径 没有人工监督的完全自主的客服人员会产生合规风险、问责差距和用户不信任。这种能力使人员可以控制：客服人员在不确定时升级，请求批准影响大的行动，并保持推理的透明度。 - **批准工作流**允许客服人员在执行后续操作（退款、关闭业务机会、删除数据）之前请求人工签核。 - **持续交互历史**记录意图、访问的数据、推理步骤和采取的操作 — 实现审计、调试和持续改进。 - 当客服人员缺乏信心或遇到边缘个案时，**升级模式会**移交给具有完整上下文的人工专家。 *Salesforce 通过具有持久、可审计交互历史的人工在环审批和升级工作流提供此功能。* > **架构含义：**预先设计明确的升级规则。定义哪些决策需要人工批准 — 财务阈值、不可逆操作、受管数据，并在部署自主客服人员之前实施这些工作流。 ### 功能如何协同工作 这些能力是相互依存的。客服人员利用可信数据来推理，通过业务逻辑操作，在生命周期治理下操作，通过共享语义查询，并在需要时升级为人工。删除受信数据和客服人员的幻觉；删除业务逻辑，他们只能回答，不能采取行动；删除治理，他们扩散到影子 AI；删除共享语义，他们的查询漂移；删除人为升级，他们在没有监督的情况下采取行动。API 优先消费模型 — Salesforce 无头 360 — 允许客服人员通过一致的编程界面（API、MCP 和 CLI）获得这些功能，而不是逐个集成单独的系统。 ## 支柱如何应用于客服人员系统 架构良好的框架支柱仍然是客服人员系统的基础 — 客服人员仍然在调控器限制内工作，需要适当的访问控制，需要监控，消耗资源，并公平地为用户服务。从核心支柱指导开始，然后应用每个支柱的同伴添加的代理注意事项。 核心支柱指导： - [Trust](/docs/architect/zh-cn/well-architected/guide/trust.html) — 共享责任模型、四层访问控制(组织/对象/字段/记录)、加密、OAuth 流、审计跟踪、合规框架 - [可靠性](/docs/architect/zh-cn/well-architected/guide/reliability.html) — 带有推荐操作缓冲的调控器限制(70% 上限是广为引用的社区最佳实践,不是 Salesforce 官方规范)、异步处理、断路器、容量规划、多组织模式、灾难恢复 - [卓越运营](/docs/architect/zh-cn/well-architected/guide/operational-excellence.html) — Event Monitoring、Proactive Monitoring、DevOps 实践(源驱动开发、CI/CD)、自动化、事件管理、DORA 度量 - [资源和成本优化](/docs/architect/zh-cn/well-architected/guide/resource-and-cost-optimization.html) — SOQL 优化、防止数据偏差、代码组织、打包策略、性能监控、TCO 建模、构建与购买、许可证优化、成本监控 - [公平性](/docs/architect/zh-cn/well-architected/guide/fairness.html) — 无障碍([WCAG 2.2 AA](https://www.w3.org/TR/WCAG22/) ) 、 不歧视模式(共享规则、FLS ) 、 隐私架构、AI 道德治理 ### 适用于客服人员系统的 Trust Core Trust 模式(共享责任模型、最小权限、加密、OAuth)仍然是基础。客服人员系统添加： - **客服人员身份和身份验证** — 客服人员可以使用基于 JWT 的身份验证，而不是静态 API 密钥，这支持每个客服人员的审计跟踪和精细的权限跟踪 - **用户身份传播** — 当客服人员代表用户调用外部系统时，传播*用户的*身份(而不仅仅是客服人员的身份),以便下游系统强制执行用户级权限和审计跟踪 - **权限边界** — 客服人员的最低权限、从运行用户继承权限、显式客服人员权限和委派边界的验证 - **后续决策的人员** \- 高影响或不可逆转的行动和受监管数据的审批工作流 - **可解释性** — 客服人员解释他们的推理，引用事实声明的来源，并使他们采取的数据和操作透明 - **遵守自主系统** — 遵守 [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) 的风险分类(区分有限部署和高风险部署)以及特定于行业的法规,例如 [HIPAA](https://www.hhs.gov/hipaa/index.html) 和功能金融服务法;对客服人员驱动的处理保持严格的同意管理 **为何如此重要：**在没有正确 Trust 边界的情况下自主行事的客服人员会产生安全漏洞、违规和用户不信任。核心 Trust 支柱提供共享责任模型和四层访问控制；代理变体增加了可选的基于 JWT 的代理身份验证、HITL 批准门和可解释性。 **了解更多信息：**[代理企业信任](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-trust.html) ### 代理系统的可靠性 核心可靠性模式（控制器限制、异步处理、断路器、容量规划）仍然是基础。客服人员系统添加： - **处理非确定性推理** — 相同的输入可以产生不同的输出；通过置信度评分、验证检查和后备策略设计方差 - **温和降级** — 当推理失败或返回低置信度时，降级为更简单的功能，而不是完全失败 - **组织失败处理** — 多客服人员工作流需要失败隔离、重试策略和部分结果处理，以便一个失败的专家客服人员保持隔离，而不是级联 - **模型性能 SLO** — 为客服人员服务定义可接受的延迟、准确性和可用性目标 - **客服人员协调电路**中断 — 防止一个客服人员遇到错误或延迟过长时的级联故障 **为何如此重要：**概率性客服人员行为意味着确定性可靠性模式是不够的。核心可靠性支柱为外部集成提供异步模式和断路器；客服人员变体为推理故障和编排故障处理增加了优雅的降级，以实现多客服人员协调。 **了解更多信息：**[代理企业可靠性](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-reliability.html) ### 适用于客服人员系统的卓越运营 核心卓越运营模式（事件监控、DevOps、自动化、事件管理）仍然是基础。客服人员系统添加： - **客服人员开发生命周期 (ADLC)** — 在客服人员的整个生命周期中对其进行管理，从设计和测试到部署、监控和调整 - **观察概率系统** — 捕获推理步骤、置信度分数、访问的数据源和决策原理，而不仅仅是输入→输出 - **差异检测** — 根据行为基准监控数据分发轮班、业务规则更改或上游模型更新导致的性能下降 - **客服人员版本和部署** — 提示和配置的逐步推出、A/B 测试、回滚和版本控制 - **客服人员故障事件响应** — 区分模型故障、编排故障和数据故障，以便进行有针对性的补救 **为何如此重要：**非确定性行为会使可观察性更加困难。核心运营卓越性支柱提供 Event Monitoring 和 DevOps 实践；客服人员变体增加了 ADLC、漂移检测和客服人员特定的可观察性。 **了解更多信息：**[代理企业卓越运营](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-operational-excellence.html) ### 代理系统的资源和成本优化 核心资源和成本优化模式（SOQL 优化、调控器限制、代码组织、性能监控、TCO 建模、构建与购买、许可证优化、成本监控）仍然是基础。客服人员系统添加： - **推理延迟优化** — 流响应、并行执行、缓存和提示优化 - **令牌经济性** — 每个调用、检索和推理步骤都消耗令牌；为有限的上下文窗口设计上下文管理策略（汇总、选择性检索） - **内存检索优化** — 高效的向量搜索和语义检索，因此 RAG 模式不会造成延迟瓶颈 - **多客服人员延迟管理** — 并行专家执行、异步委派和超时预算，以防止顺序客服人员链累积延迟 - **客服人员模块化** — 将整体客服人员分解为专家客服人员，以便重复使用、独立扩展和目标优化 - **基于消耗定价** — 与按用户许可不同，客服人员成本随使用情况而变化，需要不同的预算和预测 - **客服人员工作单位 (AWU)** — 根据客服人员完成的工作衡量支出，而不仅仅是原始令牌消耗，并根据交付的价值调整消耗 - **构建与购买代理功能** — 评估构建差异化功能与采用商品化功能 - **客服人员 ROI 评测** — 根据客服人员运营成本跟踪业务结果 **为何如此重要：**令牌消耗和推理延迟是新的资源约束，客服人员成本模型与基础设施成本有着根本的不同。核心支柱提供调控器限制指导、SOQL 优化和 TCO 框架；客服人员变体增加了令牌经济性、推理延迟优化、基于消耗的定价管理和客服人员工作单位，用于根据客服人员完成的工作来衡量成本。 **了解更多信息：**[代理企业资源和成本优化](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-resource-and-cost-optimization.html) ### 代理系统的公平性 核心公平模式（可访问性、不歧视、隐私、AI 道德治理）仍然是基础。客服人员系统添加： - **可解释性** — 客服人员解释他们决定的原因、他们使用哪些数据以及他们考虑哪些替代方案。（Trust 支柱涵盖了作为审计和透明度控制的解释性；公平性涵盖了作为用户理解影响他们的决策的权利。） - **可争议性** — 用户可以质疑客服人员的决定、请求人工审核并了解申诉流程 - **偏见检测和缓解** — 使用不同的输入进行测试，并监控不同人口群体之间的差异结果 - **人的监督**与影响成正比 — 高风险决策需要人与人并肩;低风险决策可以自主操作 - **公平的客服人员**体验 — 为所有用户有效服务，无论语言熟练程度、技术专长或可访问性需求如何 **为何如此重要：**自主客服人员做出影响人员的决策会提高公平性风险。核心公平支柱提供了可访问性和不歧视模式；代理变体增加了可解释性、可竞争性和相称的人类监督。 **了解更多信息：**[代理企业公平性](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-fairness.html) ## 将此文档与支柱指南一起使用 在构建代理解决方案时： 1. 从概念模型**开始**：客服人员需要的功能，以及支柱如何适用于客服人员。 2. **阅读核心支柱指南**，了解适用于所有 Salesforce 解决方案的基础方法。 3. 有关特定于客服人员的设计详细信息，请**阅读客服人员支柱**。 构建经过验证的平台模式，然后解决客服人员介绍的注意事项。核心支柱提供了基础，客服人员同伴提供了详细信息，本概述将它们联系在一起。 ## 组织就绪：卓越中心 以上功能和支柱描述了如何构建代理系统。将该系统投入生产需要常设治理结构：卓越中心 (CoE)。在人员、客服人员和平台的统一系统中，CoE 授予人员控制权限。CoE 定义了客服人员的边界，决定了生产范围，并将客服人员的工作与业务意图和监管要求协调起来。CoE 是受管客服人员系统和不受管的实验之间的差异，这些实验渗透到影子 AI 中 — 客服人员权限不明确、没有审计跟踪，成本未知。 自主权使每个治理决策都有意义。CoE 帮助团队有意做出这些决定，并始终如一地执行它们，而不是一个团队一个团队地解决它们。 ### 卓越中心管理的内容 CoE 将业务、IT 和合规集中在共享待办事项和就绪的共同定义上。其成员关系跨越客服人员决策涉及的视角： - **执行发起人**拥有预算权限并清除组织障碍。 - **业务潜在客户**将策略转化为优先级，并拥有待办事项。 - **计划办公室和数据**管理员将客服人员工作与更广泛的计划联系起来，并评估数据完整性和安全性。 - **架构师、管理员**和开发人员拥有数据模型、集成模式和交付节奏，并在工作开始前解决技术约束问题。 客服人员发货、更换和偏移的速度比传统软件更快。为了使治理与交付保持一致，CoE 以加速的异步优先审查节奏运行。与传统 CoE 相比，节奏更紧凑，异步审查成为默认工作模式： - **持续异步审查**是主要模式:成员在更改时在共享渠道中保持一致，而不仅仅是在计划的会议上。 - **每周运营审核**确认，实时更改与有效客服人员和集成保持兼容 — 比每月或每季度审核更快，交付速度更慢。 - **每月战略审查**根据业务优先级对积压进行权衡，并根据当前数据质量基准评估准备情况。 CoE 明确决定谁批准对客服人员依赖的对象、字段和自动化的更改；谁在请求竞争时拥有优先级；何时收回技术债务；以及哪些业务指标定义了成功。 ### 跨支柱评估准备情况 客服人员就绪的 CoE 管理每个支柱。核心支柱指南提供了基础控制；CoE 是它们成为强制执行的可观察实践的地方。 - **Trust** -- 对象、字段和记录级安全性控制客服人员使用的数据。客服人员级访问控制会限制每个客服人员可以访问的数据和操作。身份、最小权限和威胁建模嵌入到客服人员的设计中。见[Trust](/docs/architect/zh-cn/well-architected/guide/trust.html)和[Agentic Enterprise Trust](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-trust.html)。 - **卓越运营** — 跟踪和审计日志捕获客服人员的决策、操作和输出。监控仪表板会根据客服人员开发生命周期中的目标审查绩效和一致性。请参阅[卓越运营](/docs/architect/zh-cn/well-architected/guide/operational-excellence.html)和[卓越代理企业](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-operational-excellence.html)运营。 - **可靠性**和**资源和成本优化** — 规范、测试生成、反馈循环和弃用控制整个客服人员生命周期。速率限制、资源控制和补救策略包含客服人员错误的影响。请参阅[可靠性](/docs/architect/zh-cn/well-architected/guide/reliability.html)和[资源和成本优化](/docs/architect/zh-cn/well-architected/guide/resource-and-cost-optimization.html)。 - **公平性** — 人工在环检查点允许人员拦截或查看后续操作。升级路径和员工培训使人们准备好审查和覆盖客服人员工作流。请参阅[公平性](/docs/architect/zh-cn/well-architected/guide/fairness.html)和[代理企业公平](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-fairness.html)性。 ### 就绪信号 当这些条件满足时，CoE 准备管理客服人员工作负载： - **策略** — 定义、强制执行和审核客服人员的访问和操作策略。 - 可**观察性** — 监控和审计工具支持客服人员行为的实时和回顾性审查。 - **设计安全** — 安全性、隐私性和合规性从一开始就内置于客服人员工作流中。 - **生命周期** — 结构化流程管理客服人员的入职、更新和停用。 - **人员监督** — 审查者处理异常并使用反馈来改进客服人员的工作流。 在部署第一个生产客服人员之前，请确认以下四个基础： - **记录的数据质量**基准，定期审核。 - 具有指定所有者和记录注销**的正式方案更改审批流程**。 - **维护的技术债务**登记册,在战略节奏审查。 - 涵盖数据访问、客服人员范围和审计要求**的 AI 治理策略**。 > **架构含义：**在部署自主客服人员之前，建立 CoE 并确认这些基础。从一开始就内置的治理会随着客服人员的采用而扩大。之后改造的治理与它要防止的蔓延竞争。 **另请参阅：**客服人员企业运营卓越性指南中的[部署审批流程](/docs/architect/zh-cn/well-architected/guide/agentic-enterprise-operational-excellence.html#deployment-approval-processes) — 每个客服人员的“去/不去”核对清单，是对本节组织级就绪视图的补充。 ## 开始使用 开始代理之旅的组织应： 1. **从高价值用例开始** — 将初始客服人员集中在具有明确 ROI 的工作流上；成功会形成势头。 2. **建立基本能力** -- 建立数据治理、Knowledge 库和集成模式。 3. **开发客服人员专业**知识 — 培养提示工程和客服人员架构的技能，即使低代码和自然语言工具降低了准入门槛。 4. **建立卓越中心** — 在部署生产客服人员之前，建立负责审批流程、安全测试和监控的治理机构（请参阅*组织就绪性：以上卓越*中心）。 5. **迭代** — 计划持续优化，而不是完美的初始部署。 6. **评测价值** — 跟踪业务结果、成本节约和用户满意度，为投资提供信息。 Agentic Enterprise 是准备采用 AI 支持的工作流的组织的一个转型机会。精心设计的架构可让您在管理风险和复杂性的同时实现它。

分享您对良好架构框架的反馈。