企业集成与生产 — Claude Certified Architect Professional Prep Course

屏幕 1：方向：学习目标

模块概览 2 分钟方向：学习目标

模块 1 介绍了架构概念。本模块深入探讨具体细节。

本模块为您提供了将原型与生产系统区分开来的具体工具：在构建之前设置质量门槛，在部署之前建立成本和可靠性模型，在承诺之前进行可行性评估，确保集成架构通过安全审查，以及一种实验方法，用于验证变更是否真正有效。

通过本模块的学习，您将能够：

1 在编写第一行生产代码之前，定义成功标准并构建评估套件，区分基于模型和基于代码的评估，选择评估工作流程阶段，并将评估作为生产系统任何变更的门槛机制。 2 完成从概念验证到生产的检查清单，将成本和延迟映射到预算，指定可靠性模式（重试、回退、断路器），为所选架构命名故障模式，并阐明每种故障的缓解措施，包括如何使代理（使用工具、跨回合推理并执行多步操作的系统）在生产中可靠。 3 通过估计调用量、token 消耗和成本创建用例，根据 AI 能力和限制中的四个 AI 属性评估技术可行性，并将业务问题转化为具有明确边界条件的范围化解决方案架构。 4 为企业准备 Claude 部署，指定合规性（受监管行业约束、BAA 覆盖、数据驻留）、身份（SSO/OAuth）、授权、数据处理和可观测性工具的集成模式。在每个集成点放置正确的集成点（API、SDK、MCP、Claude Code）。 5 计划并解释对实时 Claude 系统的 A/B 测试或结构化实验，设定假设，选择指标，估计所需样本量，并在不夸大结果的情况下解读结果。

本模块假设您具备扎实的系统背景，并直接建立在模块 1 的基础上。它跳过了基础概念，深入探讨将原型与生产系统区分开来的决策。

免责声明 / 教育内容声明

我们构建了本架构师课程模块 2：企业集成与生产，以帮助您使用 Claude 完成实际工作。请将其视为教育内容。它不构成法律、财务或其他专业建议，因此请根据您的情况调整所学内容。我们的产品和服务发展迅速，因此某些内容可能包含错误或已过时；请记得在 Anthropic 的网站或文档中核实。课程中使用的示例和场景是说明性的，通常是虚构的。如果课程材料提到某家公司或产品，并不意味着 Anthropic 认可它们，它们认可 Anthropic，或者我们有关联。此外，请注意，您对 Anthropic 产品和服务的使用受我们的条款、政策和文档的约束；如果本课程中的任何内容与之冲突，以它们为准。

屏幕 2：评估作为验收标准：将质量融入构建过程

教学评估 17 分钟评估作为验收标准：将质量融入构建过程在第一个模块中，您做出了架构决策：模式、集成点以及系统应如何响应不同的输入。但您尚未确信这些决策在输入真实且用户不可预测时是否仍然有效。这就是评估的用武之地。评估是“evaluations”的缩写，它让您可以在系统上线或模型更新之前测试其行为，从而在问题发生之前发现它们。本节将解释什么是评估、它们的重要性以及如何使用它们在使用者发现问题之前提前解决问题。

评估先于代码：顺序的重要性评估是一种结构化测试，用于检查系统是否返回预期且准确的输出。虽然听起来很简单，但时机极为重要。标准方法是先构建系统，看看它是否正确，然后再进行测试。这并不总是最佳方法。在编写生产代码之前编写评估套件，强制发生三件事，否则这些事很容易被推迟：

首先，以可衡量的方式定义成功其次，在设计假设早期暴露时，更改它们的成本仍然较低第三，为自己设置一个门槛，可以确定模型交换、提示更改或新的检索策略是否显著改善了系统

评估套件应位于构建过程的开始，在生产代码编写之前定义，而不是作为 QA 步骤放在最后。事实上，如果您无法为某种行为编写评估，那么您就没有可靠的方法来衡量该行为是否存在。这意味着您对系统所做的每一项变更都无法验证。在开始时添加评估套件可以让您在整个构建过程中进行验证。

评估工作流程的运行方式：从任务定义到结果一个构建良好的评估工作流程按顺序运行以下阶段。每个阶段都会生成一个工件，供下一阶段使用：

阶段 | 发生了什么 | 输出

定义任务 | 以具体、可衡量的方式陈述您要评估的行为，并编写用于测试它的提示。模糊的定义会产生模糊的评估。行为规范和提示的具体程度决定了结果的意义。 | 任务规范，包括测试提示和通过标准
构建黄金数据集 | 组装系统将遇到的输入，包括边缘案例和反例。此数据集是评估运行的基础。如果数据集不具有代表性，则分数也无意义。 | 带有预期输出的标注数据集
运行自动化检查 | 将每个提示通过系统，并将输出与预期结果进行比较。自动化检查快速且成本低。将它们用于明确的行为：格式合规性、模式验证和基于权威数据的事实查找。 | 每个项目的通过/失败记录
使用评委评分 | 对于需要解释的行为，例如语气、推理的准确性和边缘案例响应的适当性，基于模型的评委可以大规模评估输出。 | 每个项目的评分及理由
解释并采取行动 | 汇总分数告诉您系统的现状以及变更是否使其朝着正确的方向移动。如果变更提高了平均分数，但悄悄降低了边缘案例或对抗性输入的性能，那么它并没有使系统变得更好。 | 总体分数，按类别细分

基于模型与基于代码的评估：何时使用每种方法并非所有需要评估的行为都可以用相同的方式检查。有些行为有单一正确答案：输出要么是有效的 JSON，要么不是。第二类是输出是否匹配预期的语气或语言风格。这两类行为需要不同的评估工具，选择适合特定行为的工具对于确保准确性和节省成本至关重要。三种评估类型在速度与灵活性之间存在不同的权衡：

基于代码的评估在几毫秒内运行确定性检查，几乎不产生成本。基于模型的评估使用评委模型评估需要解释的输出，成本大致相当于模型调用本身。人工审查评估依赖于人类判断，用于高风险或新颖行为，其中代码或模型评委都无法可靠评估。人工审查评估是最慢且最昂贵的选择。

评分阶梯：选择评分方式并非所有行为都应采用相同的评分方式，评分方法的选择遵循一个明确的阶梯。首先选择最便宜的可靠方法，只有在行为需要时才逐步升级。

基于代码的评分，只要行为允许。确定性检查，包括模式验证、精确匹配、长度和存在性检查，在几毫秒内运行，几乎不产生成本，且不会漂移。如果行为可以通过代码检查，则应如此。 LLM 作为评委，当行为需要解释时。使用评委模型评估需要判断的输出。通过使用详细的标准、约束的裁决（一组固定的标签而非自由形式的分数）、与人工标注示例的校准以及使用与评估输出不同的模型进行评分，使评判更加严格。人工评分，作为最后的手段。保留人工审查用于高风险或新颖行为，其中代码或校准的评委尚不可信。这是最昂贵且最不可扩展的选择。

评委校准：许多团队跳过的步骤 LLM 评委本身是一个可能出错的系统。在信任其裁决之前，请确保对其进行校准。为此，将其运行在一组人工标注的输出上，并确认其与人类判断的相似性足够高，可以依赖。未经校准的评委会产生看似可信的分数，但质量可能并不高。这比没有自动评分更糟糕，因为它看起来值得信赖。

优先考虑数量而非完美。许多自动评分案例胜过少量手动评分案例：广泛、廉价的覆盖范围比一小部分精心制作的案例能捕捉到更多的回归，并且它可以在每次变更时运行。

定义成功标准：将业务需求转化为可衡量的阈值像“准确总结索赔”这样的业务需求并没有真正告诉您要衡量什么。将其转化为评估标准的过程包括以下步骤：

具体识别行为：“准确总结索赔”应更新为“从每份文档中提取申请人的姓名、索赔编号、事件日期和索赔金额。” 设置阈值：决定什么算作通过。例如，如果您的阈值是结构化字段的 100% 准确性、小于 2% 的幻觉率以及 99. 5% 的时间响应在模式内，这些数字应来自业务需求。不要仅仅选择您的第一个原型恰好达到的数字；有关设置评估阈值的指导，请访问 platform. claude. com/docs/en/test-and-evaluate/develop-tests。识别故障模式：继续以同一示例为例，可能不可接受的输出包括虚假的索赔编号、缺失的事件日期或来自错误索赔的值。每个故障模式都是您评估数据集中的一个类别。包括对抗性输入：它应包括缺失字段、手写部分、非常规格式和非标准布局的文档。如果您的黄金数据集仅包含干净的输入，那么您的评估分数将无法预测生产性能。

评估作为变更的门槛机制对生产 Claude 系统的每一项变更，无论是模型交换、提示修订、上下文策略更改还是检索配置更新，都应在开发期间通过评估套件运行，然后再上线。这是唯一可靠的方法，可以知道变更是否改善了系统。单轮评估集不会告诉您系统在对话中的表现如何。多轮评估是一个单独的类别，它在一系列交换中而不是单个提示和响应上对系统进行评分。多轮评估检查几个标准：系统是否在跨回合时保持先前的上下文，是否在不发明对话中从未提及的细节的情况下回答后续提示，以及随着对话的延长，输出质量是否保持。因为评分的单位是整个对话，所以此类别需要自己的黄金数据集。这包括在每个回合中已知高质量响应的完整对话记录，涵盖系统在生产中看到的后续问题、主题转换和对话长度。考虑一个构建文档摘要工作流的团队，他们修改了摘要提示，但没有更新评估套件以匹配。评估套件通过了所有必需的检查。在交换上线两天后，现场报告显示多条款法律句子被截断为摘要。根本原因是评估集早于提示更改，并且不匹配已更改的行为。简而言之，您应在每次变更之前运行评估，以保持评估集与它正在测量的系统同步。

成本 · 复杂性 · 风险成本：每个基于模型的评估都是一次 API 调用。尽管成本值得关注，但不要让成本驱动您使用比用例所需的更小的评估集。更大的风险是评估不足：通过评估不足的评估套件滑入生产中的破坏性变更的成本远高于几次额外的 API 调用。根据使您对结果有信心的大小调整数据集，并将成本视为次要约束。复杂性：评估基础设施增加了一个需要维护的并行系统。黄金数据集必须保持最新，评委提示必须经过设计和测试，当系统需求发生变化时，通过阈值必须重新审视。下一步：有关工作实现模式，包括评分设计和黄金答案比较的演练，请参阅 Claude Cookbooks，网址为 github. com/anthropics/claude-cookbooks/blob/main/misc/building_evals. ipynb。风险：过时的评估套件提供虚假的信心。它会产生一种误导性的印象，即变更安全，而检查正在测量系统中不再存在的行为。回归的最高风险时刻是评估存在但已过时的时候。

屏幕 3：测量错误内容的评估套件

警惕评估 5 分钟测量错误内容的评估套件

为什么会出现这种错误当演示正常工作时，宣布它“足够好”似乎是一个合理的决定。手动抽查需要时间，而系统在每次测试的输入上似乎都能正确响应。问题在于，团队只能测试他们想到的输入，而生产则暴露了其余部分。

需要重建的合作伙伴事后分析以下是现场部署中反复出现的模式的综合事后分析。团队为一家专业服务公司构建了一个合同审查助手。他们手动测试了助手针对他们团队熟悉的十份合同，宣布系统准备就绪，然后上线。两周后，回归出现了。

事后分析发现系统在一类从未测试过的合同上失败，即那些具有非标准义务结构的合同。模型从错误的章节中提取了义务。评估套件存在。它是在项目开始时构建的，并且基于团队在开发过程中使用的十份合同。这并不是完整合同人口的代表性样本。当提示更改时，评估套件仍然通过，但只是因为黄金数据集仍然反映了旧提示的预期输出。它从未更新以考虑新行为。

导致我们走到这里的决策

评估数据集是从方便的输入构建的，而不是代表性样本。一个不涵盖生产中将面临的输入分布的评估套件正在测量一个与您正在交付的系统不同的系统。评估输入集在提示更改后未更新。评估仍然每次都通过，因为它正在评估提示不再产生的行为。分数看起来稳定，因为没有测试发生了什么变化。手动抽查被视为评估的替代品。抽查可以确认特定输入产生特定输出，但它们无法告诉您系统在未知输入上的行为是否正确。

需要注意的事项评估套件存在但配置错误有两种方式：数据集不具有代表性，且未保持最新。这两个问题在生产暴露差距之前都是不可见的。系统在开发中看起来健康，因为它只在已经优化的输入上进行了测试。

屏幕 4：分类评估类型

检查点评估 5 分钟分类评估类型下面列出了八项评估任务。将每一项拖到它所属的桶中：基于模型的评估或基于代码的评估。正确的分类取决于被检查的行为是否需要解释或是否直接。

检查每个响应是否是与定义输出模式匹配的有效 JSON。
评估模型在复杂分析中的推理是否合理且完整。
验证响应长度是否小于 500 个 token。
评分系统如何处理情绪激动的客户投诉。
确认提取的索赔编号与源文档中的定量值匹配。
评估摘要是否从长篇简报文档中捕捉到最重要的点。
验证输出中是否包含所有必需的部分（执行摘要、方法论、发现、建议）。
评估面向客户的消息的语气是否适合品牌的专业性。

基于代码的评估

基于模型的评估

检查答案暂时跳过

屏幕 5：从概念验证到生产：成本、延迟和可靠性

教学概念验证到生产 16 分钟从概念验证到生产：成本、延迟和可靠性您的评估套件告诉您系统是否正确行为，但并未告诉您它是否能在合作伙伴期望的规模下负担得起正确行为。这个差距是概念验证（POC）到生产的差距，它有四个维度：成本、延迟、可靠性和故障模式。在演示中，这四个维度都是不可见的。 POC 还为您提供了系统是否改善了其设计改进的业务指标的第一个信号。值得有意捕捉该信号：即使在建模生产成本之前，也要在 POC 样本上测量合作伙伴关心的结果。如果成本符合预算，但系统未在重要指标上产生可衡量的改进，那么部署仍然是失败的。

概念验证（POC）与生产系统的区别 POC 旨在展示能力。它以低容量运行，使用干净的输入，并且用户耐心。生产系统以合作伙伴业务生成的容量运行，使用真实输入，并且用户对缓慢或不正确的响应没有容忍度。POC 误导您的四个维度是成本、延迟、可靠性和故障模式。

成本和延迟建模：在构建之前了解数字成本和延迟模型在最终确定架构之前构建。您需要的三个输入是调用量（每天或每月的请求）、每个请求的 token 预算（输入 token 加上预期输出 token）和模型层级。从这三个输入中，您可以估计月度成本，并在编写任何代码之前检查它是否在预算上限内。每个请求的 token 预算是大多数成本模型出错的地方。团队根据他们拥有的输入计算平均 token 计数，并假设这是分布。实际上，token 分布通常是偏斜的：大多数请求很短，但长请求的尾部消耗了总成本的很大一部分。基于平均使用量的成本模型可能会显著低估这些较长请求的成本影响，通常低估两到三倍。延迟遵循类似的模式。中位数延迟反映了中间值，但 SLA 违规通常是由高端较慢的请求引起的。这就是为什么 p95 是比中位数更有用的设计目标。p95 是 95% 的请求完成的延迟值。只有最慢的 5% 超过它。缓存是最有效的成本和延迟杠杆，当系统提示长且稳定时。提示缓存保留缓存 token 的处理提示前缀，因此 API 不会在后续请求上重新处理它们。节省随着缓存前缀的长度和重用频率的增加而增加。例如，如果缓存读取按标准输入 token 费率的 10% 收费，那么在许多请求中重用的长前缀会产生最大的有效节省。在 platform. claude. com/docs/en/about-claude/pricing 上查找最新的缓存读取费率。风险是一致性：如果缓存内容需要反映实时状态，缓存会创建一个可能违反用例要求的一致性窗口。存储的是提示前缀。

可靠性控制：在每个模型调用中构建的内容生产 Claude 系统中的可靠性控制解决了不同的故障场景，并位于调用堆栈的不同层。

使用指数退避进行瞬态错误恢复。当模型返回瞬态错误（例如速率限制 429、超时或 5xx）时，系统应逐步延长重试之间的延迟。这可以防止重试洪水将短暂的中断变成长时间的停机。根据您的用例可以容忍的延迟设置最大尝试次数和总等待时间。回退链。如果主要模型或端点不可用，系统应自动将请求路由到替代方案，例如不同的模型层级或缓存响应。它不应向用户引发错误。回退行为应作为评估套件的一部分进行测试。断路器。断路器测量下游依赖项的错误率，并在错误超过既定阈值时触发。一旦触发，请求立即失败，而不是等待超时。这可以防止一个降级的依赖项拖垮整个系统。

可靠性控制必须位于正确的阶段才能有效：新尝试应靠近 API 调用，断路器位于服务边界，回退链位于编排层。将它们放在错误的层意味着保护了系统的错误部分，而暴露了正确的部分。

按架构类型划分的故障模式代理处理无法在单个模型调用中完成的任务：它们可以使用工具、观察结果、在执行过程中调整计划，并完成需要每个步骤动态推理的多步骤过程。Claude Code 是一个生产示例，它导航代码库、运行测试、应用修复，并在单个回合架构中不可能的工作流中迭代。以下控制管理如何可靠地构建这些系统。

架构 | 首先崩溃的地方 | 缓解措施代理 | 无限制的工具使用和不断增长的上下文。一个可以在没有预算约束或回合限制的情况下调用工具的代理将在单个请求超出预算上限之前以看不见的方式增加成本和延迟。 | 设置每回合 token 预算、最大工具调用次数和明确的停止标准。将工具集限制为所需的最小值。评估代理的停止行为，而不仅仅是其输出质量。 RAG（检索增强生成） | 检索质量漂移。当文档被添加或从索引中删除而未重新索引时，当查询和文档表示不一致时，或者当索引按计划刷新导致实时状态查询的陈旧性时，检索层会降级。 | 将检索质量保持在评估循环中。将检索精度和召回率作为系统指标进行监控，而不仅仅是输出质量。将实时状态查询与静态知识查询分开。文档处理管道（评估器-优化器） | 低置信度提取的异常路径。一个无论提取置信度如何都将所有文档路由通过相同流程的管道将在边缘案例上以与在干净文档上产生正确输出相同的速率产生错误输出。 | 在提取步骤中添加置信度评分。将低置信度提取路由到人工审查队列，而不是下游处理。在评估集中包括边缘案例和困难文档。编排器-工作者 | 编排器和子代理之间的故障边界模糊，跟踪片段化，掉线的子代理可能在合成时无声失败。 | 定义可恢复（子代理：重试或标记）与不可恢复（编排器）的边界。在所有代理之间创建共享跟踪 ID。在合成时协调覆盖范围，使结果等于提交的单位。

成本 · 复杂性 · 风险成本：不要假设您的概念验证成本与生产相匹配。在承诺架构之前建模成本，而不是在第一个计费周期之后。复杂性：重试、回退链和断路器在未设计它们的系统中更难添加。从一开始就构建可靠性，而不是在第一次生产事件后匆忙修复。风险：没有回退和断路器的系统有一个故障点：主要模型端点。当该端点在峰值负载下宕机时，没有恢复路径，整个用户面对的工作流失败而不是优雅降级。

模型版本固定注意：模型版本固定适用于上表中的每个架构。它是一种操作纪律，而不是架构选择。在配置中固定模型版本，监控 Anthropic 模型弃用页面 platform. claude. com/docs/en/about-claude/model-deprecations，并维护版本更新手册。

屏幕 6：演示成本概况成为生产账单

警惕概念验证到生产 5 分钟演示成本概况成为生产账单

为什么这种错误容易发生 POC 旨在证明能力。它不是为了建模成本而设计的。团队针对小数据集构建，运行几百次请求，账单可以忽略不计。低容量下的 POC 账单是一个样本，它不反映生产支出。

上线后审查中的三个引述以下引述来自一个团队在上线后 60 天的部署审查。每个引述都指出了同一错误的不同方面。

引述 1 “每天运行 10–50 次请求的 POC 仍然可以为生产成本估算提供信息，但前提是数字按预期生产容量缩放并带有适当的误差范围。向客户展示原始演示成本而不进行这种推断是风险所在。”

引述 2 “我们假设 token 分布是均匀的。事实并非如此。尾部的长文档消耗了总 token 支出的 80%。”

引述 3 “当端点在第三天峰值时返回 529 错误时，整个工作流崩溃了。我们没有回退，因为我们从未测试过调用失败时会发生什么。”

什么坏了，为什么每个引述都指出了一个不同的故障，但它们按顺序叠加。成本模型错误，因为它是在错误的容量下构建的。token 分布假设错误，因为它是在错误的输入下构建的。可靠性故障在开发中不可见，因为从未测试过故障案例。所有三个故障都有相同的根本原因：POC 被视为成本和可靠性模型，而不仅仅是能力演示。POC 回答了“系统能否做到这一点”，但它没有回答“在规模下做到这一点需要多少成本”或“当依赖项失败时会发生什么”。

需要注意的事项 POC 在三个维度上被视为生产模型：成本、输入分布和可靠性。所有三个都是生产系统属性，必须单独设计，而 POC 没有建立其中任何一个。

屏幕 7：成本与可靠性计算器

检查点概念验证到生产 5 分钟成本与可靠性计算器使用计算器探索配置。调整模型层级、提示缓存、max_tokens 上限和调用量乘数；读数显示每个设置的月度成本和 p95 延迟。您的目标：找到一个同时满足成本上限和延迟目标的配置。计算器仅显示值；它不会对您的探索进行评分。（数字用于建模；在发布时确认当前费率。）

场景客户服务代理每月处理 50,000 次请求。系统提示为 5,000 个 token，并且在请求之间稳定。平均用户输入为 300 个 token，平均输出为 400 个 token。成本上限为 800 美元/月。p95 延迟目标为 3 秒。

模型层级

Haiku Sonnet Opus

提示缓存

开启

Max_tokens 上限：512

调用量乘数：1. 0×

预计月度成本 720 美元成本上限：800 美元/月

p95 延迟 2. 5 秒延迟目标：≤3 秒

决策：一旦您有一个同时满足两个目标的配置，哪个杠杆发挥了最大的作用？

A. 切换到 Opus，因为最强大的模型总是最安全的。 B. 开启提示缓存，因为 5,000 个 token 的系统提示在所有 50,000 次请求中都是稳定的，因此缓存它可以削减主要的输入成本驱动因素。 C. 提高 max_tokens 上限，因为更多的余量可以提高质量。

提交暂时跳过

屏幕 8：用例规模与可行性

教学规模 18 分钟用例规模与可行性生产准备清单告诉您系统必须实现什么才能可行。它涵盖了模型输出的质量和系统周围的可靠性。输出质量通过评估验证，系统可靠性通过架构控制（如重试、回退和断路器）验证。满足这两个标准是生产准备的含义。规模告诉您特定的业务问题是否可以满足该标准，以及哪些约束控制设计。可行性分为三种状态：按范围可行、有约束可行和不可行。正确识别状态是使范围文档有用的原因。

如何确定用例规模确定用例规模意味着在编写任何代码之前生成成本模型。模型不必精确，但必须足够准确，以验证架构是否符合预算，并在正式化之前暴露 token 分布假设。四个输入驱动模型：调用量、每个请求的 token 预算、模型层级和敏感性参数。

步骤 1：估计调用量。每天或每月有多少次请求？这个数字来自业务需求，而不是开发人员的直觉。每天处理 1,000 次对话的客户服务代理每天产生 1,000 次 Claude 调用，加上任何多回合继续调用。从业务所有者那里获取这个数字。样本数据集不会给您准确的数字。步骤 2：设置每个请求的 token 预算。token 预算有两个组成部分：输入 token（系统提示、检索上下文和用户消息）和输出 token（预期响应长度）。建模分布而不仅仅是平均值。如果文档长度变化很大，成本模型应考虑到典型情况和极端情况。如果系统提示长且稳定，提示缓存可以显著减少输入成本。缓存需要在请求中显式标记 cache_control。缓存写入比标准输入产生更高的每 token 成本，因此成本模型必须考虑首次使用的写入成本。默认缓存 TTL 为 5 分钟；请求频率低于 TTL 的工作负载不会实现一致的缓存节省。步骤 3：预测月度成本。将调用量乘以输入 token 计数乘以输入 token 费率。分别将输出 token 计数乘以输出 token 费率。然后，将两个数字相加。所有模型层级的输入和输出 token 以不同的费率定价。如果应用提示缓存，请使用缓存读取费率而不是标准输入费率。在最终确定模型之前，请在 platform. claude. com/docs/en/about-claude/pricing 上验证当前费率。如果适用，添加缓存节省。将结果与生产准备清单中的成本上限进行比较。如果预测超过上限，则需要在编写一行代码之前更改架构。例如，如果 Batch API 相对于标准 API 定价提供 50% 的价格折扣，并支持每批最多 100,000 次请求，则将其建模为任何工作负载的成本替代方案，其中 SLA 允许异步处理。对于受监管的工作负载，在通过它路由 PHI 或类似受监管数据之前，请验证批处理是否涵盖在合作伙伴的 BAA 和合规配置中。在 platform. claude. com/docs/en/about-claude/pricing 上查找最新的 Batch API 折扣率和批量大小限制。步骤 4：运行敏感性分析。如果调用量翻倍，成本会发生什么变化？如果 token 分布向尾部移动会发生什么？敏感性分析告诉您成本模型的脆弱性以及在与业务所有者承诺设计之前需要验证的假设。

如何确定用例范围将业务需求转化为范围化架构的发现序列分为四个步骤。跳过任何步骤都会产生一个无法在与业务所有者的下一次对话中存活的承诺。

步骤 1：业务需求到能力列表。系统需要做什么？分别命名每个能力。“处理保险索赔”是一个目标。能力可能包括从索赔文档中提取结构化字段、从政策数据库中查找政策覆盖范围、根据索赔类型和价值将索赔路由到适当的调整员队列，以及起草调整员通知。分别识别它们，以便将每个分配给适当的所有者。步骤 2：能力列表到架构草图。对于每个能力，决定它属于哪里。Claude 拥有哪些能力？哪些属于现有系统？哪些需要人工干预？这是模块 1 中的分解步骤，应用于特定用例。步骤 3：架构草图到边界条件。陈述架构工作的条件和不工作的条件。可行性是一个裁决加上使裁决为真的约束。一个适用于最多 20 页文档但在更长文档上失败的架构有一个必须记录的边界条件。步骤 4：边界条件到 SOW 中的范围。工作说明书包含边界条件。这确保开发团队和业务所有者都理解系统设计处理的内容以及明确超出范围的内容。

如何进行技术可行性评估仅询问“Claude 能否做到这一点”的可行性评估是能力检查。四个 AI 属性为您提供了一种结构化方法，用于识别设计需要补偿控制的地方，以及这些控制应该是什么。选择每个属性以查看它提出的可行性问题以及设计补偿的地方。

下一个 token 预测知识工作记忆可引导性

可行性问题：此任务是否需要概率生成，还是需要特定值的精度？分类、摘要和起草是模型擅长的概率任务。提取特定权威值（账号、政策日期、索赔金额）需要根据真相源进行验证。设计补偿：生成器-验证器循环；提取值的基于代码的评估；检索定量数据的工具调用。

可行性问题：此任务是否依赖于罕见、有争议、最近或领域特定的信息，这些信息可能未在训练数据中表示？如果是，设计必须将知识带入上下文窗口。不要依赖模型提供它。设计补偿：稳定知识的检索增强生成；实时数据的工具调用；对有争议索赔的不确定性标记。

可行性问题：输入是否适合上下文窗口，还是任务需要处理聚合超过窗口的输入？长文档、多文档任务和扩展对话都会触及此约束。设计补偿：分块策略；渐进式上下文加载；跨回合的摘要；输入超过上下文限制的管道架构。

可行性问题：指令是否具体、明确且可验证？抽象或模糊的指令、长推理链以及需要精确数值或逻辑计算的任务都是模型可能偏离意图的地方。设计补偿：具有明确输出模式的系统提示；结构化输出；数值精度的代码执行；评估器-优化器循环。

可行性裁决一旦范围序列和技术评估完成，架构就可以进行可行性评估。有三种可能的结果。

裁决 | 含义 | 记录内容按范围可行 | 四个 AI 属性的论点在每个能力上都支持 Claude。成本模型在上限内。延迟 p95 在 SLA 内。没有能力需要改变架构的补偿控制。 | 明确陈述假设。当假设发生变化时，按范围可行的裁决变为有约束可行。有约束可行 | 设计在特定条件下工作，这些条件必须强制执行。文档长度必须保持在阈值以下。检索索引必须按定义的计划刷新。对于高于置信度阈值的输出，必须存在人工审查门。约束是架构的一部分。 | 明确记录每个约束。对于每个违反的约束，识别故障模式。开发团队需要知道他们设计的是什么，而不仅仅是他们构建的是什么。不可行 | 至少一个能力面临 AI 属性限制，无法在范围和预算内补偿。成本模型超过上限，无法通过模型层级、缓存或架构更改缩小差距。不可行的裁决是正确的评估，可以避免后期更昂贵的失败。 | 说明哪个约束是取消资格的以及原因。如果范围缩减会改变裁决，请命名它并向业务所有者提出选择。

业务价值和 ROI 映射：将可行设计转化为合理的投资可行性裁决告诉业务所有者系统可以在预算和约束内构建。它没有告诉他们构建它是否值得。确定业务价值和 ROI 映射是回答第二个问题的步骤。它们将范围化架构与业务预期的财务和运营结果联系起来，以业务所有者已经使用的术语表达：节省的时间、减少的错误率、缩短的周期时间或保护的收入。映射将技术设计转化为预算持有人可以辩护的决策。业务案例基于五个主要支柱，识别它们使 ROI 对话保持在蓝图和业务所有者都使用的语言中：效率（相同的工作更快或更便宜地完成）、转型（以前不可行的工作变得可能）、生产力（相同的人更多的产出）、解决方案成本（系统本身的运行成本）和性能 SLA（部署必须保持的服务水平）。将每个 ROI 声明映射到它推进的支柱，以便价值声明既捕获数字又捕获它所代表的价值的类型。机制是两个状态的比较。基线状态是今天如何完成工作，以业务关心的单位衡量。预测状态是 Claude 进入工作流后如何完成工作，以相同的单位衡量。价值是两个状态之间的差异，减去运行系统的成本。成本数字直接来自本集群早期生成的规模模型，因此 ROI 计算重用您已经完成的工作，而不是重新开始。映射分为四个步骤构建，每个步骤都必须基于业务所有者会认可的数字：

步骤 1：以业务单位命名基线。从今天如何执行任务开始，并以业务已经跟踪的单位衡量它。对于索赔审查工作流，这是每个索赔的分析师小时数或平均解决天数。基线必须来自业务所有者自己的运营数据，因为每个后续数字都与之进行比较。从直觉中提取的基线会产生财务团队不会接受的 ROI 数字。步骤 2：预测部署后的状态，以相同的单位。估计一旦 Claude 进入工作流，同一任务的执行情况，以与基线相同的单位衡量。当可行性裁决需要人工审查时，预测必须包括该成本。将低置信度输出路由给审查员减少了劳动力，但并没有完全消除它。当设计指定人工干预审查时，预测完全自动化会夸大价值，并产生运营会拒绝的数字。步骤 3：从规模模型中减去运行成本。将规模期间产生的预计月度成本视为新状态的经常性成本。部署的价值是步骤 2 中的运营收益减去此运行成本。此步骤仅隔离经常性运行成本。构建成本单独处理，并在步骤 4 的回收期计算中考虑。将规模输出包含在 ROI 计算中保持两个分析的一致性。token 预算或模型层级的更改然后同时更新成本上限和价值案例。步骤 4：陈述回收期和敏感性。将结果表示为回收期，即累积运营收益覆盖构建成本和运行成本所需的时间。然后陈述如果容量假设或每任务收益假设错误，该期间如何移动。引用没有敏感性分析的回收期会邀请基于单一乐观场景的决策，该场景通常在业务案例在启动后遇到实际容量时失败。

映射的输出是架构师与可行性裁决一起交给业务所有者的简短价值声明。它将“我们能构建这个吗？”和“构建它值得吗？”的答案与业务已经拥有的数字联系起来。这两个工件一起进入工作说明书。这些是最常见的 ROI 映射错误、它们的原因以及它们往往出现的地方。

风险 | 原因及出现位置基线是估计的而不是测量的。 | 当业务所有者没有干净的运营数据时，基线从直觉中填充。这使得明显的收益具有误导性。错误在财务团队在业务案例审查期间询问基线数字来源时隐藏。此时必须重建整个案例。预测假设完全自动化，而设计需要人工审查。 | 需要人工审查门的可行性裁决意味着劳动力减少，而不是完全消除。价值案例通常误导性地将其建模为完全消除。差距在启动后的第一个运营期间显现，当实际分析师小时数未能像业务案例承诺的那样下降时。运行成本取自平均值而不是规模分布。 | 重用平均 token 成本而不是规模模型中的分布低估了经常性成本，从而夸大了净价值。这集中在具有重尾输入的工作流上，其中一小部分大请求驱动了大部分成本。

成本 · 复杂性 · 风险成本：基于平均 token 计数的规模会低估成本，当某些请求比其他请求大得多时。出错意味着在合同已经签署后重新协商架构。复杂性：跳过四个 AI 属性中任何一个的可行性评估可能会错过改变设计的约束。工作记忆是最容易被忽视的，因为它很少在开发期间出现在小、干净的输入上，但它会在生产中显现。风险：未记录的有约束可行裁决在生产中违反约束时变为不可行系统。约束是设计的一部分，与它们限定的架构具有相同的权重。

屏幕 9：跳过约束的范围调用

警惕规模 5 分钟跳过约束的范围调用

演示陷阱当业务所有者对用例感到兴奋且初始演示正常工作时，在收集容量和 SLA 约束之前确认可行性感觉是高效路径。能力存在，原型正常工作，放慢速度询问约束感觉像是在寻找说不的理由。问题是，如果未应用预期规模的约束，“技术上可行”是没有意义的。

范围对话：过早承诺以下是发现调用中出现的模式的摘录，当能力问题在约束问题被提出之前得到回答时。

合作伙伴：“我们需要一个文档审查助手，可以处理我们的法律合同并标记非标准条款。” 架构师：“我们可以做到。模型擅长阅读合同并识别条款模式。让我整理一份可行性报告。” 合作伙伴：“太好了，构建需要多长时间？” 架构师：“初始版本需要六周。” [构建两周后] 合作伙伴：“我应该提到：我们每天处理大约 800 份合同。其中一些是长达 300 页的框架协议。我们需要在 30 秒内得到结果。”

出了什么问题在收集三个基本约束之前发布了可行性裁决：调用量（每天 800 次）、输入大小（最多 300 页）和延迟要求（30 秒）。长合同是否适合上下文窗口取决于选择的模型层级。具有 100 万 token 上下文窗口的模型可以处理 300 页合同而无需分块；具有 200k token 窗口的模型可能需要分块策略来处理最长的文档。因此，上下文窗口容量是模型层级决策的一部分，而不是既定假设。每天 800 次请求，30 秒的延迟要求并不像看起来那么严格。这平均每 108 秒一次请求。在该容量下，顺序处理是可行的，无需并行运行请求。在该请求速率下，容量压力成本，而不是延迟。延迟由任务复杂性、模型大小和输出长度驱动。这些是模型层级决策需要围绕的变量。架构师确认能力作为必要的第一步，但它也是最后一步，这意味着在设计可能之前做出了承诺。

需要注意的事项能力问题在问题被提出之前得到了回答。容量、延迟和输入大小的约束是可行性裁决的输入。裁决只有在收集约束之前才是可靠的。

屏幕 10：证明可行性调用

检查点规模 5 分钟证明可行性调用对于每个场景，选择命名正确可行性裁决和其背后的单一负载约束的选项。仅裁决是不够的，约束是使裁决可辩护的原因。

场景 1/3 一家专业服务公司希望有一个研究助手，可以总结 10–40 页的行业报告并起草客户简报。每周 50 份报告，简报在 24 小时内完成，500 美元/月的上限。

A. 不可行，报告太长，不适合上下文窗口。 B. 按范围可行，输入大小适合上下文窗口，容量、延迟和成本在 Sonnet 层级内都在范围内；没有 AI 属性提出取消资格的约束。 C. 有约束可行，每个简报都需要人工审查门。

场景 2/3 一家物流公司希望有一个延迟预测器，可以读取非结构化的承运人电子邮件，提取延迟原因和新 ETA，并将它们写入订单管理系统。每天 5,000 封电子邮件，10 秒内完成，1,000 美元/月。

A. 按范围可行，Haiku 带缓存处理容量和延迟。 B. 不可行，容量太高。 C. 有约束可行，负载约束是事务写入的提取准确性，因此需要基于代码的提取准确性评估加上低置信度提取的人工审查门，然后再写入记录系统。

场景 3/3 一家金融服务公司希望从当前市场状况加上其专有模型中获取实时交易建议，并在 2 秒内交付。

A. 不可行，负载约束是实时知识差距：实时市场数据需要工具调用实时提要，并且是否在 2 秒预算内适合往返必须验证，然后才能发布任何可行性裁决。 B. 按范围可行，Claude 已经知道当前市场状况。 C. 有约束可行，只需添加人工门。

暂时跳过

屏幕 11：企业集成模式：身份、授权、数据和可观测性

教学集成 14 分钟企业集成模式：身份、授权、数据和可观测性合规约束在做出任何其他决策之前消除了入口点选项，因此入口点选择首先进行。其余五层管理如何从那里构建集成。规模告诉您系统需要做什么以及它是否可以在约束内做到。集成模式告诉您它如何连接到企业堆栈。该连接有五层，每层都有一个属于架构师的架构决策，而不是实施团队。

入口点选择：何时使用哪种集成任何集成中的第一个决策是系统将通过哪个入口点连接。合规约束在此第一阶段消除选项，然后才进行任何其他架构决策。表格涵盖了五个可用的入口点，何时使用每个入口点，以及每个入口点在灵活性或维护方面的成本。入口点：何时使用哪种集成入口点 | 何时使用 | 您需要权衡什么直接 API | 您需要完全控制如何构建请求、如何处理响应以及如何管理错误。系统的每个部分都是您自己的代码。 | 您负责构建和维护重试逻辑、流式传输、工具编排和错误处理。实施工作比 SDK 路径更高。 SDK（Python/TypeScript） | 您需要一个处理基础知识的便利层，而不放弃对系统设计的控制。SDK 处理 HTTP 层，并为您提供类型化接口，同时将编排留给您的代码。 | 比原始 API 更少的细粒度控制。SDK 版本升级偶尔会以需要代码审查的方式改变行为，然后才能部署。 Claude Code | 主要用户是开发人员，任务涉及编写、审查或导航代码。不适合作为嵌入式产品的后端。 | 不设计用于具有多个用户或面向客户部署的产品。Claude Code 设计用于开发人员工作流，而不是作为多租户产品的后端；产品集成应使用 Claude API、客户端 SDK 或代理 SDK。代理 SDK | 您需要 Claude 在您自己的产品中跨多个回合行动，您的应用程序控制周围的工作流。代理 SDK 运行一个托管循环，处理迭代、工具执行和终止，因此您的团队不必构建该基础设施。适用于 Python 和 TypeScript。当单个请求和响应足够时，或者任务不需要跨工具的多回合推理时，这不是正确的选择。 | 托管循环放弃了对每个迭代步骤的细粒度控制。如果您的用例需要在回合之间自定义逻辑，原始 API 循环为您提供该控制，但代价是您自己构建和维护循环。 MCP（模型上下文协议） | 您将 Claude 连接到现有工具或内部服务，并希望有一种标准方式来管理这些连接，而不将它们混入您的编排逻辑中。MCP 提供了一个工具集成协议，将集成层与编排层分开。 | MCP 在 Claude 和您的工具之间添加了一个协议层，这使得调试工具调用比直接函数调用更复杂。

集成层的安全性和合规性约束模块 1 确立了监管和政策约束，如 HIPAA、GDPR 和 FedRAMP，律师-客户特权，以及数据驻留要求，在任何其他决策之前消除入口点选项。本节将相同的逻辑应用得更深一层：在该入口点上的哪种集成模式可能通过适当的架构选择、内部政策、合同条款和其他项目帮助满足或减轻对约束的担忧。下表将该分析从入口点选择扩展到完整的集成设计。注意：这不应被视为法律指导 - 与您自己的法律和合规团队合作，实施满足您组织需求的控件。约束到集成矩阵约束 | 运行位置（路由） | 连接方式（集成模式） | 信任谁（身份） | 处理什么（数据处理） | 记录什么（可观测性）律师-客户特权* | API 在公司自己的应用程序后面运行，通过公司批准的网关记录每个请求。 | 网关位于用户和 Claude 之间。它持有 API 密钥，强制执行谁可以访问什么，并生成公司拥有的审计日志。 | 用户通过 SSO 登录。用户身份和权限由服务器分配，用户无法声明。 | 所有特权内容通过网关流动，网关作为官方记录。 | 每个请求和响应都在网关记录，并根据公司政策保留。 HIPAA（PHI 处理） | API 在业务伙伴协议（BAA）涵盖的配置上运行。HIPAA 合格的云路径包括直接 Claude API（与 Anthropic 签署 BAA）、AWS Bedrock 和 Google Vertex AI。BAA 必须涵盖使用的特定配置，而不仅仅是提供商。 | 云提供商调解集成。BAA 必须涵盖使用的特定配置，而不仅仅是提供商。 | 用户通过合作伙伴的身份验证系统进行验证。访问 PHI 仅限于 HIPAA 下的最低必要。 | PHI 在 API 调用之前被剥离到任务所需的程度。尽可能使用参考 ID 而不是完整的数据字段。 | 日志捕获请求、模型版本、用户身份和数据范围，并根据 HIPAA 要求保留。 GDPR 和数据驻留 | 模型执行限制在批准的区域内。这可以通过云路径（AWS Bedrock 或 Google Vertex AI）或直接使用 Claude API 的 inference_geo 参数实现，该参数目前支持“us”和“global”值。注意，inference_geo 不支持直接欧盟固定 - 虽然 GDPR 合规性不需要欧盟驻留，因为跨境转移在有效的转移机制下是合法的，当部署有欧盟数据驻留要求时，应使用云路径而不是直接 API。使用 Claude API 时，DPA 直接与 Anthropic 签订。使用云路径时，DPA 条款继承自云合同。注意：Microsoft Foundry 欧盟数据驻留列为 2026 年即将推出，发布时没有确认的时间表。如果部署引用 Foundry 并要求欧盟固定，请在承诺该路径之前验证当前可用性。 | 执行区域在集成层锁定，并在每个请求时检查。数据不会离开批准的区域。 | 用户在批准的数据区域内进行验证，并根据 GDPR 要求处理。 | 个人数据仅在固定区域内处理。跨境转移数据需要记录的法律依据，并且仅在明确证明时构建。 | 日志记录谁访问了什么数据、处理的法律依据以及何时删除。 FedRAMP 和政府 | 集成在持有所需 FedRAMP 授权的云配置上运行，具有正确的影响级别。FedRAMP 合格的路径是 Claude for Government、AWS Bedrock GovCloud 和 Google Vertex Assured Workloads。直接 API 上的 Claude Enterprise 未经 FedRAMP 授权，不能作为这些路径的替代品。 | 架构仅限于携带授权的特定云和配置。不允许超出该边界的任何内容。 | 用户通过机构的批准身份提供者进行身份验证。访问由机构的角色和政策层控制。 | 数据根据机构的分类规则处理。受控的非机密信息保持在授权边界内。 | 日志满足机构的持续监控要求。内部数据驻留政策 | 集成在合作伙伴组织已经批准的云提供商上运行。正确的路径是 CIO 已经清除的路径，无论方便与否。 | 架构受采购批准的限制，无论工程偏好如何。 | 用户通过合作伙伴的标准 SSO 登录。角色根据合作伙伴的现有政策分配。 | 数据处理按合作伙伴的现有分类方案进行。Claude 层继承现有控制，不引入新控制。 | 日志馈入合作伙伴的现有日志基础设施，而不是单独的系统。

特权保护取决于适当的合同条款、保留设置、内部政策和其他项目。本图表中的信息旨在帮助减轻特权放弃的担忧。

在任何集成设计开始之前，按顺序处理约束：识别管辖法规或政策，确定哪些入口点和路由仍然可用，选择适合的集成模式，并记录身份、数据处理和可观测性要求。跳过任何步骤可能会构建技术上可行但在法律或安全审查中失败的东西。

每个企业 Claude 集成都需要在下表定义的层上做出决策。合规性首先，来自法规（如 HIPAA、GDPR 和 FedRAMP）和政策（如数据驻留和律师-客户特权）的约束在做出任何其他决策之前消除路由和入口点。其余四层在幸存于该过滤器的任何选项内运行。注意这些部分不涉及 ZDR 用例。

层 | 架构决策 | 错误时的表现合规性和受监管行业约束 | 哪些交付路由和入口点幸存于管辖约束？BAA 覆盖、FedRAMP 授权、数据驻留固定和批准的供应商列表在开始设计之前消除选项。 | 集成建立在无法通过下一次法律或安全审查的路由上。此时重新设计的成本是已经投入的时间加上从头开始的新架构。身份和 SSO | 用户身份边界相对于 Claude 集成点的位置在哪里？在 Claude 调用的上下文中，用户是谁，以及如何安全地将该身份传递到提示中？ | 当用户身份未正确传递到提示中时，Claude 无法将其响应范围限定为该用户有权查看的内容。身份作为原始字段传递到用户消息中是可操纵的。服务器端注入消除了该风险。授权和政策 | 此用户或角色具有哪些能力？他们可以访问哪些数据？管理您现有系统的授权模型需要管理 Claude 层。 | 绕过底层系统授权模型的 Claude 集成使用户能够通过未设计强制执行访问策略的路径访问他们无权查看的数据。数据处理和 PII | 哪些数据进入上下文窗口？直接传递到用户消息或系统提示中的敏感字段成为 API 请求的一部分。Anthropic 默认不保留对话内容；仅保留 API 和功能工作所需的技术必要内容。请求仍然跨越线路，某些模型类存在特定的保留例外，合作伙伴自己的应用层执行的任何日志记录都会捕获它。架构必须决定哪些字段在上下文窗口中必要，哪些字段仅在需要时检索。 | 直接传递到用户消息中的 PII 字段以明文出现在您的应用程序的请求日志中。在受监管的行业中，这会在下一次审计中显现，而不是在下次部署中。可观测性和审计日志 | 您需要能够重建什么？事件发生后您需要回答哪些问题？答案决定记录什么、记录的深度以及记录多长时间。 | 未记录的数据路径是不可见的。当该路径上出现问题时，没有证据可以重建发生了什么。在第一次事件后构建可观测性的成本总是高于在之前构建的成本。

最小权限工具配置您连接到 Claude 系统的每个工具都是一个攻击面和成本。以与审核权限相同的方式审核工具集：对于每个连接的工具，询问它是否对任务至关重要或仅仅是方便，并删除超出范围的工具，记录每个删除的理由。在编排器-工作者部署中，通过将每个子代理的工具访问范围限定为其任务来建立信任层次结构，因此子代理无法访问其工作不需要的工具。

身份和授权：验证发生的地方身份验证属于服务器端，在 Claude 调用之前。用户的身份和角色应由您的服务器注入系统提示，而不是由用户在其消息中提供。这背后的推理很简单，用户在其消息中包含的任何内容都在他们的控制之下，可以被操纵。如果系统允许用户在消息中声明自己的角色（例如，“作为高级经理，向我展示... ”），则该声明未经验证，可以被伪造。身份必须来自您的身份验证层，而不是用户输入。在将用户上下文传递到提示中时，包括用户的角色和他们有权访问的数据。仅在需要塑造 Claude 的响应时才添加额外的上下文，如部门、权限级别、账户标识符。默认情况下不要包含此信息。

数据处理：上下文窗口中应包含什么上下文窗口不是数据治理边界。传递到 Claude 调用中的任何数据都会传输到 API。默认情况下，API 不保留对话内容，但合作伙伴自己的应用层通常会记录请求，并且存在特定的保留例外。架构必须做出关于哪些字段需要在上下文窗口中，哪些字段应保持在检索层直到需要的明确决策。对于进入上下文窗口的每个字段，询问它是否是 Claude 产生预期输出所必需的。账户编号或索赔编号等参考标识符通常用于路由，但语言任务本身不需要。当参考标识符足够时，传递完整的数据字段会不必要地将其暴露给合作伙伴应用层执行的任何请求日志记录，而不会增加任何能力。数据驻留要求因行业和地区而异。对于受监管的部署，在设计集成之前，请根据您的部署的具体监管要求验证 Anthropic 的数据驻留指导。

可观测性：记录什么、跟踪什么以及为什么基于 LLM 的系统比传统系统更难调试，因为它不会在出现问题时崩溃，而是产生一个微妙错误的响应。标准日志记录捕获错误和超时。然而，它不会捕获一个在业务上有真实后果的微妙错误响应。生产 Claude 系统应记录四件事：

请求：模型版本、输入 token 计数、提示标识符响应：输出 token 计数、延迟、停止原因上下文：用户角色、会话 ID、是否应用了缓存结果：下游系统是否接受了输出以及任何拒绝信号

安全组织越来越多地将可观测性视为启用代理的前提条件，因为没有可信的审计跟踪，自主系统不会被批准行动。为此设计。作为设计审查清单项目，验证在您选择的表面上记录的代理操作。覆盖范围因表面而异，采取但未记录的操作对于安全审查员来说是不允许的。

成本 · 复杂性 · 风险成本：在 API 调用之前没有 PII 删除的集成会在每次请求时将敏感字段暴露给合作伙伴的应用层请求日志。跨从未设计支持它的日志历史进行追溯删除的成本是生产 Claude 系统中最昂贵的数据处理修复。复杂性：在第一次生产事件后添加的可观测性层意味着必须从未设置回答事件提出的问题的系统中重建根本原因。构建日志记录以回答您需要回答的问题，在您需要提问之前。风险：在共享 API 密钥上运行的多租户系统无法将速率限制违规归因于导致它的租户。当组织级限制在峰值负载时触发时，峰值可见但来源不可见，每个租户都会吸收影响。任何生产多租户部署都需要每个租户的单独 API 密钥以进行归因和隔离。

屏幕 12：直接进入提示的 PII 字段

警惕集成 5 分钟直接进入提示的 PII 字段

跳过安全的演示陷阱当目标是快速使演示正常工作时，最快的工作 Claude 集成路径是将您拥有的数据直接传递到提示中。添加 PII 删除层、构建服务器端身份注入和仪表化可观测性堆栈都会增加时间。它们也不会增加可见的能力，因为系统在没有它们的情况下也能正常工作。跳过它们的成本直到第一次审计才会显现。

受监管行业部署的跟踪摘录以下跟踪是医疗保健相关部署中的字段模式的综合。团队构建了一个患者入院摘要工具。摘要工作正常。数据处理不正确。

API 请求：在应用层的请求日志中捕获模型：claude-sonnet-4-6 系统：“您是一个临床入院摘要器。从入院表中提取关键主诉、药物和过敏。” 用户：“患者：Jane Doe，DOB：1978-04-12，SSN：123-45-6789，保险 ID：BCB-88712。主诉：胸痛，3 天前发作... ”

SSN 和保险 ID 在用户消息中，因此随 API 请求一起传输，暴露于任何应用层的请求日志记录，尽管不需要它们来生成摘要。系统提示要求主诉、药物和过敏。这些都不需要患者的 SSN 或保险 ID 在上下文窗口中。

什么坏了工具按设计工作，但数据处理错误。根据 HIPAA，患者的姓名、出生日期、SSN、保险 ID、主诉、药物和过敏等几个字段被传递到 API 调用中，并以明文形式捕获在应用层的请求日志中。这些对于语言任务不是必需的。当部署在生产认证前审查时，应用层的请求日志包含数千条带有患者 SSN 的用户消息字段条目。修复是数据架构更改：服务器端删除步骤，在 Claude 调用之前删除非必要的 PII 字段，以及检索功能，仅提供语言任务所需的字段。两者都应包含在原始设计中。

需要注意的事项数据处理架构围绕传递方便的内容设计，而不是围绕传递必要的内容。必要性是正确的过滤器：如果字段不是 Claude 执行的语言任务所必需的，它不应在上下文窗口中。

屏幕 13：批评集成图

检查点集成 5 分钟批评集成图下图显示了多租户 SaaS 公司客户服务代理的 Claude 部署。查看标记的组件和连接，并选择每个代表集成问题的部分。选择所有问题。保留健全的组件未选中。

✓ 问题 | Claude Code 用作面向客户的聊天产品的后端

↓↓↓

✓ 问题 | 所有租户共享 API 密钥

✓ 问题 | 基于“我是高级客户”的用户消息的能力检查

✓ 问题 | 账户编号和电子邮件传递到用户消息中并出现在请求日志中

↓↓↓

✓ 健全 | 服务器端身份验证层位于 API 前面

↓

✓ 健全 | 租户数据在存储层按租户隔离

↓

✓ 问题 | Claude 响应传递到下游 CRM，集成层没有日志记录

检查答案暂时跳过

屏幕 14：A/B 测试和大规模可观测性

教学 A/B 和可观测性 17 分钟 A/B 测试和大规模可观测性集成模式将 Claude 带入企业堆栈。接下来的问题是它是否在进入后按预期执行。可观测性回答监控问题。结构化 A/B 测试回答改进问题。没有两者，您要么盲目飞行，要么做出无法衡量的更改。

实时 Claude 系统的结构化 A/B 测试 Claude 系统的 A/B 测试遵循与任何实验相同的结构：假设、处理组、控制组、指标和足够大的样本量以使结果具有统计意义。与传统软件 A/B 测试的区别在于 LLM 输出是概率性的，这使得结果更嘈杂，交互效应更难控制。假设必须具体且可测试。“新提示更好”在这两方面都失败了：它没有命名处理、指标或阈值。可用的假设如下：“将摘要指令替换为提取三个最重要行动项的指令将使任务成功率至少提高 5%，而不会降低响应延迟 p95。”它命名了处理、指标、成功的阈值和约束。

在不夸大结果的情况下解读结果统计显著性意味着结果不太可能因样本量而偶然发生。它是否大到足以重要是另一个问题。变更可能具有统计显著性，但仍然太小，无法证明发布和维护新版本的操作成本。在宣布胜利之前要问的两个问题是：效应是否大到足以证明维护新版本的操作开销？以及任何次要指标是否降级？一个提高任务成功率但增加 30% 成本的提示变更可能不是净胜利，具体取决于部署的预算约束。 LLM 实验有一个经典 A/B 测试没有的额外故障模式：处理与特定输入类型之间的交互效应。一个在典型输入上提高性能的提示变更可能会在测试期间很少出现但在未来季节性高峰中频繁出现的边缘案例输入上降级性能。测试期间和输入分布对齐在 LLM 实验中比在大多数其他软件环境中更重要。

影子测试：在任何用户看到之前验证变更实时 A/B 测试将真实用户发送到新版本，这意味着回归在实验关闭之前到达部分用户。有一种方法可以在不承担该暴露的情况下测试真实流量。您并行运行新版本和当前版本，向其发送实时请求的副本，并为每个用户提供当前版本的响应。新版本的输出被记录而不是返回，您在事后离线评分。部署决策在单个用户看到新版本之前做出。该模式称为影子测试。两种模式之间的选择取决于部署可以承担多少风险以及它看到多少流量。

使用实时 A/B 测试，当部署可以吸收少量、有界暴露到更差版本并且流量足够高以在合理窗口内达到统计意义的样本时。回报是您根据真实用户行为测量新版本，包括实时响应产生的下游信号，例如用户是否接受了答案或进行了跟进。使用影子测试，当单个错误输出风险太大，或者流量太低无法在需要变更之前支持实时分割时。影子测试的成本是失去下游信号：没有用户接收影子输出，评分依赖于离线标准或黄金答案，而不是真实用户行为。对于受监管行业的部署，暴露用户到未验证的模型变更可能根本不可接受，影子测试通常是验证变更的唯一可接受方式。

大规模可观测性：仪表设计、仪表板、异常检测生产 Claude 系统的可观测性需要回答四个问题：系统在做什么，它表现如何，何时发生变化，以及为什么发生变化？每个问题需要不同的仪表层。

请求级跟踪。每个请求应生成一个跟踪，包括模型、模型版本、输入 token 计数、输出 token 计数、延迟、停止原因和任何工具调用。这是其他一切的原始材料。指标聚合。将请求级数据聚合到仪表板显示的指标中：每次请求的成本、延迟 p50 和 p95、任务成功率（如果下游系统提供接受信号）和按错误类型划分的错误率。每次请求分解至关重要：聚合指标可能看起来健康，而一小部分请求消耗了大部分预算。异常检测。在重要的指标上设置阈值警报。成本峰值超过 7 天平均值的 150% 应触发警报。延迟 p95 超过 SLA 阈值应触发警报。模型漂移（模型输出分布随时间的逐渐变化）更难用阈值警报检测，并受益于定期分布比较。变更归因。当指标移动时，仪表应能够区分模型漂移（模型在稳定输入上的行为发生变化）、数据漂移（输入分布发生变化）和模型更新效应（模型版本发生变化，新版本在现有输入上的行为不同）。这三个原因有不同的缓解措施，混淆它们会产生错误的修复。

故障分类：分类您正在查看的内容仪表告诉您指标移动；诊断告诉您哪种故障移动了它。在归因变更之前，对故障进行分类。常见类别不同，需要不同的修复：

提示故障。指令模糊或未指定，模型填补了空白。修复在提示中，而不是模型中。幻觉。模型产生了自信、流畅的内容，但未基于输入或可靠来源。修复是通过检索、工具使用或验证进行基础。更强的指令不会解决它。模型不匹配。选择的层级不适合任务，或者在未重新评估的情况下交换。修复是模型选择，由评估门控。编排器-工作者故障。在多代理系统中，跨编排器及其子代理跟踪：可恢复的子代理故障（重试或标记）看起来与不可恢复的编排器故障不同。归因需要一个跨越两者的跟踪。

辨别：判断输出辨别是四个 AI 流畅性能力之一，定义为判断模型产生的内容质量而不是表面接受的纪律。应用于生产系统，辨别是分类每个输出为可接受、需要修订或需要覆盖的习惯，并将该判断反馈到评估和监控中。没有辨别的团队看着指标移动，从不问底层输出是否实际上很好。

将可观测性数据连接到业务价值资助 Claude 部署的人不会阅读请求级跟踪。他们阅读衡量部署设计改进结果的 KPI 仪表板。可观测性堆栈需要一个翻译层，将技术指标连接到它们驱动的业务指标。对于客户服务代理，业务指标可能是平均处理时间、首次联系解决率或客户满意度评分。可观测性堆栈测量延迟、任务成功率和错误率。翻译层将任务成功率映射到首次联系解决率，将延迟映射到处理时间，以便业务所有者可以看到系统是否在移动他们关心的数字。在设计系统时构建此翻译层，而不是在第一次业务审查之后。如果技术和业务指标在构建时未映射，第一次业务审查将提出关于是什么驱动处理时间变化的问题。没有该映射，回答它需要回顾性重建，而不是运行实时查询。

成本 · 复杂性 · 风险成本：运行 A/B 测试而不预先指定主要指标意味着您总能找到想要的结果。动力不足的实验产生假阳性。看起来像改进的变更被部署，团队最终维护一个不比它替换的版本更好的版本，同时吸收全部操作开销。复杂性：在第一次生产事件后添加的可观测性仪表意味着根本原因问题无法从现有日志数据中回答。第一次正确构建仪表的增量复杂性低于追溯日志重建的复杂性。风险：仅具有聚合可观测性指标的 LLM 系统可能看起来健康，而一小部分请求消耗了大部分预算并产生了错误输出。聚合指标保护免受明显故障。每次请求分解保护免受不明显故障。

屏幕 15：50 次会话的胜利者并非如此

警惕 A/B 和可观测性 5 分钟 50 次会话的胜利者并非如此

为什么这种错误容易发生运行适当的 A/B 测试需要时间，需要样本量计算，并且可能需要几天或几周才能达到显著性。将新版本的 50 次会话与旧版本的 50 次会话进行比较只需要一个下午。看起来积极的 50 次会话比较是确认检查，而不是有意义的测试。样本太小，无法区分信号和噪声。

看起来像胜利的提示变更以下是代表一个模式的综合，该模式出现在拥有工作系统并希望改进但没有正式实验过程的团队中。一个运行客户服务代理的团队希望测试系统提示中的修订指令。他们针对 50 次客户会话运行新版本，针对 50 次会话运行旧版本。新版本的任务成功率为 68%，旧版本为 62%。他们宣布新版本为胜利者并部署了它。两周后，新版本的任务成功率稳定在 61%。明显的 6 点增益消失了。

什么坏了比较有三个问题，任何一个都足以使结果无效。

样本量太小。在高方差指标上 6 点差异需要数百个样本量才能达到统计显著性。每组 50 次会话，观察到的差异在噪声范围内。输入分布未控制。处理组中的 50 次会话恰好比对照组中的 50 次会话包含更少的边缘案例输入。明显的改进部分是由于哪些输入被路由到哪个组的产物。主要指标未预先指定。团队比较了任务成功率，因为它朝着正确的方向移动。如果它朝着错误的方向移动，他们会查看另一个指标。在看到结果后选择指标将测试变成搜索任何碰巧移动的指标。

需要注意的事项动力不足的实验和事后指标选择产生确认而不是证据，因为结果反映了您开始的假设。结果是噪声，噪声看起来像信号，因为样本太小，无法区分差异。

屏幕 16：放置在实验设计平面上

检查点 A/B 和可观测性 5 分钟放置在实验设计平面上下面的平面有两个轴：预期效应大小（您期望看到的差异有多大）和置信要求（在根据结果行动之前需要多确定）。将每个场景放置在正确的区域。正确的放置决定了正确的实验姿态，这反过来决定了最小样本量。

A. 低风险 FAQ 聊天机器人中澄清消息的微小措辞变化。 B. 医疗入院摘要器的提示架构变更，其中错误可能延迟治疗。 C. 添加新的分类类别到预计捕获 30% 传入量的路由模型。 D. 测试从 Sonnet 切换到 Haiku 在简单格式化任务上是否节省成本而不降低质量。 E. 处理每天 200 次请求的 RAG 系统中检索提示的小变更。

← 小效应大效应 →

↑ 置信度增加

高置信度

小效应 · 高置信度

大效应 · 高置信度

中等置信度

小效应 · 中等置信度

大效应 · 中等置信度

低置信度

小效应 · 低置信度

本练习中未使用

检查答案暂时跳过

屏幕 17：练习：定义评估框架

练习评估 8 分钟练习：定义评估框架简要说明一家区域保险公司正在部署一个 Claude 系统，该系统读取提交的索赔，提取结构化字段（索赔人、保单号、损失金额、损失日期），为调整员总结叙述，并标记可能需要欺诈审查的索赔。系统必须在几秒内响应，保持在定义的每索赔成本内，永远不会将一个索赔人的数据泄露到另一个人的摘要中，并且永远不会自动拒绝索赔。为该系统起草评估框架。对于下面的五个维度，写出指标、评分方法（基于代码的评估、LLM 评委或人工审查）以及选择原因的一句话。编写您的框架，然后揭示模型答案进行比较。[点击揭示答案与您的响应进行比较；随时请 Claude 比较您写的内容与提供的答案。]

准确性：字段提取

延迟：响应时间

安全性：摘要忠实性和无自动拒绝

安全性：无跨索赔人数据泄露

成本：每索赔支出

揭示模型答案暂时跳过

模型答案

准确性，字段提取：基于代码的评估。预期值（索赔人姓名、保单号、损失金额、损失日期）已知且可通过精确或模式匹配验证。无需解释；函数检查输出与真实情况的对比。
延迟，响应时间：基于代码的评估。延迟 p95 是一个数字。检查它是否低于目标。不涉及判断。
安全性，摘要忠实性和无自动拒绝：需要两种方法。基于代码的评估用于拒绝操作（二进制，要么发出拒绝，要么没有）。LLM 评委用于摘要忠实性（叙述是否准确代表源索赔而不编造是解释性任务，函数无法编码）。
安全性，无跨索赔人数据泄露：基于代码的评估。跨索赔人泄露可以通过扫描每个摘要中出现在任何输入索赔中的标识符来检查，除了正在处理的索赔。确定性检查，无需解释。
成本，每索赔支出：基于代码的评估。成本是从输入 token、输出 token、模型层级和是否应用提示缓存派生的数值。检查它是否超过上限。

正确：您在所有五个维度上正确应用了评分阶梯。区分动作：将维度 3 拆分为操作的代码和忠实性的评委，并将安全性保持在代码中，因为检查是确定性的，尽管风险很高。部分正确：至少一个维度不匹配。最常见的错误：使用评委进行字段提取（它是确定性的，代码处理它），并将自动拒绝检查视为解释性的（它是二进制的，代码处理它）。重新阅读基于模型与基于代码的评估表并修订。不正确：重新阅读评分阶梯：在行为明确时使用代码（已知值、二进制检查、数值阈值）；在正确性需要解释时使用评委。将该问题应用于每个维度并重做。跳过：如果需要，请继续，但累积任务要求您从头设计评估策略。在此之前回来。当您对自我评估满意时，标记完成。

标记完成

屏幕 18：生产准备构建器

累积模块 13 分钟生产准备构建器简要说明一家拥有 600 人的管理咨询公司希望部署一个内部知识助手。该助手应帮助顾问从过去的参与报告中检索相关摘录，回答有关公司方法论的问题，并使用过去的工作作为来源生成客户 RFP 的初稿。知识库包含 12,000 份文档，每份 5 到 80 页不等。顾问在积极参与期间使用该助手，峰值使用量为每天 800 次请求。公司有 3,000 美元/月的成本上限。响应时间必须在 p95 下 8 秒内。公司有一个现有的 SSO 系统（例如 Okta 或其他）和一个文档管理系统（例如 SharePoint 或其他）。几份文档包含受 NDA 保护的客户机密信息。点击揭示答案与您的响应进行比较；随时请 Claude 比较您写的内容与提供的答案。

决策 1，评估策略。在开始任何构建之前，您需要定义该系统的成功标准。您的主要评估任务是什么？您如何衡量检索相关性和 RFP 草案质量？每种评估类型使用什么？命名一个适合基于代码的评估的行为和一个适合基于模型的评估的行为。您的黄金数据集策略是什么？您如何处理客户机密性约束？

决策 2，POC 到生产检查清单。您有一个工作原型。在公司承诺部署之前，您需要验证什么？为该场景构建成本模型。预计成本是否在 3,000 美元/月的上限内？哪种可靠性模式对该部署最关键，为什么？命名您最关心的该架构类型特定的故障模式。

决策 3，用例规模和可行性。通过四个 AI 属性运行该用例。按范围可行吗？应用工作记忆轴。80 页的文档是否构成约束？应用知识轴。公司的专有方法论不在训练数据中。缓解措施是什么？陈述可行性裁决并命名负载约束的边界条件。

决策 4，集成模式选择。公司有 Okta SSO 和 SharePoint。Okta 身份边界相对于 Claude 调用的位置在哪里？SharePoint 中的文档包括客户机密文件，您如何处理数据处理约束？您为可观测性仪表化什么？

决策 5，A/B 测试姿态。公司希望测试一个新的检索配置，他们认为这将提高 RFP 草案质量。构建假设。处理是什么，主要指标是什么，次要指标的约束是什么？估计所需的样本量。基线任务成功率为 70%，您希望检测 5 点改进。在每天 800 次请求的情况下，这对实验持续时间意味着什么？鉴于语料库结构，您需要什么输入分布控制？

揭示模型答案暂时跳过

模型答案决策 1，评估策略：基于代码的评估：提取引用的模式合规性（文档名称、页码、部分）。基于模型的评估：RFP 草案响应的相关性和适当性。黄金数据集：从公司历史参与中构建，使用客户名称删除的过去 RFP。除非客户明确批准，否则客户机密文档不包括在评估集中