Claude 平台与解决方案设计

屏幕 1：设计 Claude 解决方案不仅仅是选择模型

教学 2 分钟 · 模块介绍 设计 Claude 解决方案不仅仅是选择模型。

在设计 Claude 解决方案时，有四个关键决策需要在开始构建之前做出。

01 Claude 应该负责哪些工作？

在塑造任何内容之前，你应该决定将哪些工作交给 Claude，哪些留给现有系统，哪些由人类负责。

02 工作的形态是什么？

你是在增强实时通话、自动化工作流程，还是部署一个能够自主行动的代理？

03 你能说出你所承诺的参考架构吗？

提前选择一个参考架构可以避免后期昂贵的调整。

04 你的工作在哪里与 Claude 交互？

选择正确的入口点、模型和上下文策略将使你的解决方案保持运作并控制成本。

在本模块中，你将学习如何做出这些决策，将一个模糊的业务问题转化为一个提议的解决方案，并针对可信的替代方案为你的选择辩护。

在本模块结束时，你将能够： 1 使用生成式 AI 的四个属性作为决策透镜，将合作伙伴的请求分解为 Claude 负责的部分、现有系统负责的部分和人类负责的部分。 2 通过命名每个选择的成本，在增强通话、工作流程和代理之间做出选择。 3 为面前的问题形状选择一个参考架构模式，并识别何时检索正在承担应由实时状态负责的工作。 4 做出可辩护的模型、上下文窗口和上下文策略决策，并在任何模型交换之前使用评估作为关卡。 5 知道每个平台入口点的适用场景（Claude. ai、API、SDK、Claude Code 或 MCP 服务器），以及每个层次的自定义内容。 6 区分用户看到的 Claude 入口点、工程师编码时使用的构建时接口以及企业采购的交付路线，并在任何其他权衡之前识别哪些被治理或受监管行业约束排除在外。

本模块的目标受众

本模块面向那些将合作伙伴的模糊请求转化为可构建、可资助和可辩护的解决方案的架构师。你具备技术能力、决策能力和权衡意识。在本模块中，你不会编写生产代码，它也不会教你编写代码。它教授的是代码之上的决策：Claude 应该负责哪些工作，这些工作采取什么形态，哪个参考架构适合，以及哪些模型、上下文和入口点选择能够保持系统的准确性和经济性。

本模块中的“工作”

这里的一切都围绕一个示例参与展开：从合作伙伴那里获取一个业务问题，并得出一个你可以在面对可信替代方案时支持的提议架构。在这个场景中，合作伙伴是高风险的、通常受监管的企业买家，设计选择在演示中看起来干净，但在三个月后的审计中被发现是错误的。这个场景以一系列决策的形式呈现，每个决策都要求你做出不同的选择。

这些决策映射到以下部分：

分解是你使用生成式 AI 的四个属性作为透镜，将请求的每个部分分配给 Claude、现有系统或人类。通过过度分配给 Claude 来犯错误是最常见且最昂贵的早期错误。 模式选择是你决定工作是增强通话、工作流程还是代理。每个选择都提供并消耗一些东西，命名这些成本是目标。 参考架构是一个已知的、良好的蓝图，要么适合问题形状，要么被误用。需要警惕的失败是检索悄悄地承担了应由实时事务状态负责的工作。 模型、上下文和入口点是你选择模型层级、上下文策略和交付路线的地方，评估成为任何模型交换之前的关卡。在考虑任何成本或延迟权衡之前，检查治理和受监管行业约束是否排除了某个路线。

与其将这些作为阶段记忆，本模块的目标是识别你面前的决策，因为每个决策都奖励不同的行动：分解时对你有益的决策与选择入口点时不同。在本模块结束时的累积任务中，你将把所有内容整合起来，从一个新的简报中组装完整的架构。

免责声明 / 教育内容通知

我们构建了这个架构师课程模块 1：Claude 平台与解决方案设计，以帮助你使用 Claude 完成实际工作。将其视为教育内容。它不构成法律、财务或其他专业建议，因此请将你所学的内容适应你自己的情况。我们的产品和服务发展迅速，因此某些内容可能包含错误或已过时；请记住在 Anthropic 的网站或文档中验证。课程中使用的示例和场景是说明性的，通常是虚构的。如果课程材料提到某家公司或产品，并不意味着 Anthropic 认可它们，它们认可 Anthropic，或者我们有关联。还要注意，你对 Anthropic 产品和服务的使用受我们的条款、政策和文档的约束；如果本课程中的任何内容与之冲突，以它们为准。

屏幕 2：架构师围绕的四个属性

教学 12 分钟 · Claude 的行为方式

架构师围绕的四个属性 在你决定 Claude 在解决方案中应该做什么之前，你需要清楚地了解 Claude 的行为方式。模型的四个属性塑造了每一个后续的设计决策。这些属性都不是需要修复的缺陷，每一个都是你设计时需要围绕的力量——就像结构工程师围绕建筑材料的属性进行设计一样。 将此屏幕视为初步基础，此时你不需要做出任何设计决策。目标是识别这四个属性的名称，并理解每个属性的设计后果，以便你在模块后期的判断练习中做出明智的选择。

四个属性及其设计后果 对于每个属性，使 Claude 在某种情况下表现出色的特性，同样也是它在另一种情况下失败的原因。将每一行视为一个能力与其对应的限制，以及架构师采取的缓解措施。

选择每个属性以查看其对应的能力、限制和缓解措施。

下一个 token 预测 知识 工作记忆 可操控性

能力：基于常见模式的任务：总结、重新格式化和解释已确立的概念。 限制：任何需要精确处理具体细节的任务。Claude 可以生成看似准确但实际上不准确的文本。这种风险集中在名称、日期、引用和统计数据上。 缓解措施：使用引用、不确定性信号和生成器-验证器循环。通过工具调用或权威来源路由具体的查找，而不是仅仅依赖模型的输出。

能力：模型训练数据中常见、最近且一致包含的主题，模型可以可靠地回答。 限制：罕见、小众、有争议或频繁变化的主题。模型可能会以与陈述事实相同的自信语气呈现过时或不完整的信息。 缓解措施：使用网络搜索、检索（RAG）、工具使用或 MCP 服务器，使外部系统成为真相的来源，而不是模型。当新鲜性或权威性很重要时，重新引入数据，而不是依赖模型训练数据中提供的内容。

能力：任何适合活动上下文窗口的内容。 限制：上下文窗口是一个硬边界：一旦内容超出窗口，模型就无法访问它。在边界处会发生两种不同的错误，但它们很容易混淆。一种是过大的请求，意味着提示或对话已经太大而无法发送。当发送过大的请求时，它会在生成之前被拒绝。如果请求超过模型的 token 限制，API 会返回一个 400 invalid_request_error，并提示提示过长。如果原始请求体超过 API 的字节限制，API 会返回一个 413 request_too_large 错误，并提示请求超过了允许的最大字节数。另一种错误发生在提示适合但生成过程中遇到窗口上限并提前停止时；在当前模型上，响应会返回一个 model_context_window_exceeded 停止原因和截断的输出。为了避免达到限制，你可以在每次响应时检查使用字段，并在发送前使用 token 计数 API。 缓解措施：使用渐进式上下文加载、分块和关键信息的前置加载。对于扩展工作，项目可以帮助管理保持在范围内的内容。当上下文变长时，养成跨轮次总结的习惯。

能力：简短、具体且可验证的指令，具有定义的格式、明确的长度限制和清晰的角色。 限制：抽象或模糊的指令、长推理链以及需要精确数值或逻辑计算的任务。对于高风险的数值准确性，确定性计算或工具执行应负责答案。模型可能会遵循指令的字面意思，但偏离其意图。 缓解措施：使用系统提示、结构化输出和代码执行来处理任何需要逻辑精度的任务。当意图和字面指令可能分歧时，明确重述目标以及指令。

从属性到设计后果 我们将在本课程的后期部分重新审视这些属性。现在将每个属性映射到它们的设计后果，以便在你需要之前建立连接：

非确定性。相同的输入可以在不同运行中产生不同的输出。这就是为什么存在评估框架：你不能仅凭一次观察来认证行为。（为模块 2 中的评估工作提供基础。） 上下文作为有限资源。上下文窗口是一个具有固定 token 预算的硬边界。你放入其中的内容、顺序以及你遗漏的内容都是影响模型可以处理的内容及其运行成本的设计决策。（为本模块后期的模型和上下文策略提供基础。） 自信不等于有效性。Claude 可以以与正确回答相同的流畅、自信的语气生成错误答案。这就是为什么人类在循环中的位置和验证是架构选择，而不是事后考虑。（为模块 3 中的负责任部署工作提供基础。） 知识和能力边界。模型在处理其训练数据中常见、最近和一致的主题时是可靠的，而在处理罕见、私有或快速变化的主题时是不可靠的。对于不可靠的主题，可以使用网络搜索、检索、工具和 MCP 使外部系统成为真相的来源，而不是模型。（为本模块后期的参考架构和 RAG 提供基础。）

场景：一个从误读属性开始的失败 一位架构师看到演示连续五次运行顺利，并得出结论认为行为是确定性的。在此基础上，团队部署了一个财务对账管道，将每个模型输出视为固定的、可重复的结果，并围绕它构建了没有检查的系统。在生产第二周，输出发生了漂移：相同的声明重新处理后产生了不同的分类。这种差异只是偶然被发现的，因为一位分析师碰巧重新运行了一批。输入没有任何变化，但产生了不同的输出，因为模型是一个非确定性系统，而架构是作为确定性系统构建的。 教训不是模型不可靠，而是演示不是确定性的证据，无论你的架构是否承认，这四个属性都存在。

成本 · 复杂性 · 风险 成本：在设计时不考虑这些属性是架构师可能犯的最昂贵的错误，因为成本在启动后才会显现，此时重新构建的成本最高，重建信任也最困难。 复杂性：提前命名这四个属性可以使后续的设计对话更加精确。你可以承认“这是一个知识边界问题”，而不是争论模型是否“足够好”。 风险：这些属性不会自我宣告。一个没有围绕这些属性设计的系统不会产生错误；它会悄悄地漂移，差距会导致变量输出，可能在审计或愤怒的用户中发现，而不是由系统本身发现。

屏幕 3：入口点、构建时接口、交付路线

教学 12 分钟 · 平台地图与基本元素

入口点、构建时接口、交付路线 在本课程中，你将选择用户如何访问 Claude，但在此之前，你需要一套一致的词汇。三个术语经常互换使用，但它们位于架构的不同层次。本屏幕教授这些术语。选择它们将在设计的其余部分就位后进行。

三个层次，三个独立的决策 这三个层次不是彼此的替代品。每个部署都涉及所有三个层次，混淆它们是架构对话混乱的最常见来源。

入口点 人或系统直接与之交互的内容。入口点是决定谁可以与 Claude 对话以及如何对话的包装器。 示例：Claude. ai（网页、移动端、桌面端）、Claude Code、基于 API 构建的自定义应用程序。

构建时接口 工程师如何针对 Claude 进行编程，合作伙伴代码编写的层次。 示例：直接 API、SDK、MCP、代理 SDK。

交付路线 API 流量的终止点。交付路线决定了请求运行在谁的基础设施上。 示例：Anthropic 直接、AWS Bedrock、GCP Vertex AI、Microsoft Foundry。

为什么保持层次分明很重要 入口点是为用户和工作选择的。构建时接口是为工程团队和集成选择的。交付路线是为合作伙伴的云承诺和合规性选择的。这是三个不同的对话，涉及三个不同的利益相关者，一个层次中的决策很少决定其他层次。 现在，专注于学习它们的名称和区别。在真实约束下选择它们将在你拥有模型、模式和架构后进行。

一个因层次混淆而导致的失败 一个零售银行工作流程解决方案的提案将 Claude Code（一个工程入口点）放在非工程受众面前，因为作者说“这都是 Claude”。从某种意义上说，这确实是 Claude，因为相同的模型位于每个入口点之下。但入口点是包装器，Claude Code 是为运行终端的开发人员构建的，而不是为遵循工作流程的银行分行员工构建的。将这三个层次视为一个层次，抹杀了本应立即排除选择的区别。

成本 · 复杂性 · 风险 成本：每个入口点都带有自己的集成成本。由于词汇不清晰而选择了错误的层次，可能导致为错误的解决方案付费，然后再次付费替换它。 复杂性：当这三个层次被精确命名和讨论时，设计评审可以隔离确切哪个决策存在争议。当它们被模糊时，评审会陷入循环争论。 风险：在用户命名之前选择的入口点是一个常见且可避免的架构错误，通常可以追溯到将这三个不同的层次合并为一个概念。

屏幕 4：将每个部分放入其层次

检查点 4 分钟 · 平台地图与基本元素

将每个部分放入其层次 点击一个平台部分以选择它，然后点击正确的层次桶以放置它。点击已放置的芯片以将其返回到池中。所有 8 个项目必须在提交前放置。

claude. ai 直接 API Claude 桌面端 SDK Bedrock / Vertex / Foundry Claude Code MCP 代理 SDK

入口点

构建时接口

交付路线

提交 暂时跳过

屏幕 5：架构师组装解决方案的组成部分

教学 16 分钟 · 平台地图与基本元素

架构师组装解决方案的组成部分 本课程中的每个模式和架构都是一小组基本元素的组合。在这里命名它们一次，以便后续课程成为你已经认识的组成部分的组合。 本屏幕命名了七个基本元素、它们的工作以及一句话来教你每个元素的用途。你现在不是在它们之间进行选择；你是在学习每个元素的用途。

七个基本元素，七个工作 将每个基本元素视为一个单一的工作。现在不要深入任何一个基本元素，而是保持对所有七个元素的整体视图。作为架构师的一个关键技能是组合这些基本元素以开发解决方案。

点击每张卡片以翻转它：正面命名基本元素及其一词工作，背面给出单行定义。

ActToolsFlip ↻ 让模型采取行动或从你的代码中获取结果的内容，模型可以调用的函数。

ConnectMCPFlip ↻ 一种协议，用于暴露一组工具，以便多个 Claude 客户端可以访问相同的入口点。

Isolate / parallelizeSubagentsFlip ↻ 将一个范围的子任务交给一个单独的上下文，以便工作在隔离或并行中运行。

GuaranteeHooksFlip ↻ 确定性代码，在定义的事件上触发，以强制执行模型无法跳过的规则。

Package a procedureSkillsFlip ↻ 一个版本化、可重用的单元（指令加可选脚本），打包一个可重复的过程。

Coordinate peersAgent TeamsFlip ↻ 多个代理作为协调的同行工作，每个代理拥有一个更大目标的一部分。

Compose at runtimeDynamic WorkflowsFlip ↻ 在运行时组装工作流程的步骤，而不是提前固定它们。

代理团队（协调的同行代理）和动态工作流程（运行时组合）扩展了单一代理和固定工作流程的旧词汇。你会在当前的从业者对话中看到它们被命名，尽管许多现有系统早于它们。

为什么现在清点它们 本模块后期教授的模式，增强通话、工作流程、代理，不是抽象类别。每个模式都是七个基本元素的特定组合。工作流程是你代码中连接的步骤，通常使用工具。代理是模型选择自己的工具调用序列。多代理系统是一个协调器委托给子代理。当你到达这些课程时，你将组合你已经命名的基本元素，而不是第一次见到它们。

场景：一个因缺少共享词汇而导致的失败 在一次架构评审中，有人说“我们将使用一个代理”。房间里的五个人听到了五种不同的东西：一个人听到了一个单一的工具使用模型，一个人听到了一个多步骤的工作流程，一个人听到了一个子代理团队，一个人听到了 Claude Code，一个人听到了一个聊天机器人。设计对话停滞了二十分钟，直到有人意识到他们用同一个词描述了不同的架构。通过建立对基本元素词汇的共同理解，团队可以清晰高效地运作。

成本 · 复杂性 · 风险 成本：使用比工作所需的更重的基本元素，每次请求都会在延迟、token 和操作表面积上付出代价。例如，当一个单一的工具调用就足够时，使用一个代理团队。 复杂性：添加到设计中的每个基本元素都是一个需要构建、观察和治理的部分。纪律是使用满足要求的最少基本元素。 风险：没有共享词汇，团队无法有效沟通，因为他们不同意这些部分是什么。

屏幕 6：将基本元素与工作匹配

检查点 4 分钟 · 平台地图与基本元素

将基本元素与工作匹配 将左侧的每个项目与右侧的三个集合中的匹配项匹配。这是模块设计部分之前的准备检查。回答所有三个集合，然后提交。

集合 1 of 3：行为属性与其设计后果 将每个属性与其创建的设计后果匹配。 非确定性选择... 为什么存在评估框架为什么存在检索和工具为什么上下文策略是一个设计决策为什么人类在循环中的位置很重要 知识边界选择... 为什么存在评估框架为什么存在检索和工具为什么上下文策略是一个设计决策为什么人类在循环中的位置很重要 上下文作为有限资源选择... 为什么存在评估框架为什么存在检索和工具为什么上下文策略是一个设计决策为什么人类在循环中的位置很重要 自信不等于正确性选择... 为什么存在评估框架为什么存在检索和工具为什么上下文策略是一个设计决策为什么人类在循环中的位置很重要

集合 2 of 3：平台部分与其层次 将每个平台部分与其所在的层次匹配。 Claude Code选择... 入口点构建时接口交付路线 MCP选择... 入口点构建时接口交付路线 Bedrock选择... 入口点构建时接口交付路线

集合 3 of 3：基本元素与其工作 将每个基本元素与其一词工作匹配。 工具选择... ActIsolate / parallelizeGuaranteePackage a procedure 子代理选择... ActIsolate / parallelizeGuaranteePackage a procedure 钩子选择... ActIsolate / parallelizeGuaranteePackage a procedure 技能选择... ActIsolate / parallelizeGuaranteePackage a procedure

提交 暂时跳过

屏幕 7：Claude 的适用场景（Claude / 系统 / 人类）

教学 9 分钟 · 分解

Claude 的适用场景（Claude / 系统 / 人类） 当你为合作伙伴架构解决方案时，你已经做出了三种决策：请求是什么，你有哪些可用的系统来解决它，以及人类判断需要在哪里介入。本模块增加了第四个决策：确定 Claude 可以在哪里提供帮助。 第四个决策是架构师容易出错的地方，因为他们缺乏对 Claude 可预测的优势和失败模式的深入理解。本模块的目标是为你提供一个具体的决策框架，以确定“Claude 可以在哪里提供帮助”的具体场景。

谁负责什么？每个解决方案都有三个所有者：提前分配它们为你成功做好准备 你使用 Claude 架构的每个解决方案都落在以下三个桶中：

所有者属于这里的内容

Claude 负责的工作受益于语言理解、总结、规划、起草或工具介导的行动的工作。 现有系统负责的工作你的合作伙伴已经付费使其可靠的内容：订单状态服务、策略引擎、规则表、记录数据库。 人类负责的工作判断调用、异常路径、审批、正确性比速度更重要的时刻。

架构师有时会将所有三个桶合并为“Claude 负责的工作”，但过度分配任务给 Claude 几乎总是使过程更昂贵、更慢、更困难。关键是知道 Claude 最擅长什么，以及它在你的解决方案中应该负责什么。

委托：决定 Claude 被信任负责什么 分解产生一个委托地图。对于请求的每个部分，你不仅要决定 Claude 是否能做，还要决定 Claude 是否应该负责：适合 AI 的工作、保留给人类的工作，或 Claude 起草并由人决定的协作工作。通过以下方式证明每个分配：

可逆性：错误的调用可以撤销吗？ 风险：错误的调用成本是什么？ 责任：谁必须为此负责？

本屏幕将教你委托的纪律，这是四个 AI 流畅性能力中的第一个。告诉你 Claude 可以被信任的四个行为属性在基础部分已经教授；在这里你将应用它们。

场景：分解合作伙伴请求，将每个步骤分配给正确的所有者 一个合作伙伴要求一个“索赔分类助手，读取索赔，决定优先级，查找政策覆盖范围，并发送电子邮件给调整员。”架构师的第一反应可能是将所有四个步骤放在“Claude 负责的工作”桶中，但四个属性的透镜阻止了这种情况发生：

“读取索赔。”这完全在 Claude 的能力范围内。读取和解释索赔是模式丰富的语言工作，如果输出模式受到约束，下一个 token 预测和可操控性都在为你服务。这是 Claude 负责的工作。 “决定优先级。”这个步骤可能看起来像语言任务，但实际上不是。优先级是你的合作伙伴已经定义和维护的确定性规则。在你的合作伙伴组织中，优先级的内容存在于规则引擎中，而不是 Claude 的训练数据中。将此路由到 Claude 引入了不必要的知识限制。相反，Claude 调用规则引擎，现有系统负责决定优先级。 “查找政策覆盖范围。”这与优先级遇到相同的问题，但风险更高。政策会变化，覆盖表会更新，模型无法可靠地知道它在训练期间学到的版本何时停止更新。答案必须来自持有实时覆盖数据的系统，通过工具使用或 MCP 服务器检索。 “发送电子邮件给调整员。”这个步骤需要拆分。起草消息是语言工作，是 Claude 负责的内容。发送消息属于电子邮件系统。任何超过价值阈值的内容都应该由人类审查和批准，因为如果 Claude 自行决定，其工作记忆和可操控性的限制都会成为风险。

分解应该通过回答“四个属性在哪里支持 Claude 而不是已经正确执行此任务的系统？”而不是“Claude 可以在哪里提供帮助？”来驱动。密切关注这种框架的转变，这是本模块正在构建的关键概念。

成本 · 复杂性 · 风险 成本：每个可以由简单确定性系统处理的查找都被发送给 Claude。你最终为模型付费，让它执行数据库查询或规则表可以以一小部分成本完成的工作，而在数千次请求中，这会迅速累积。 复杂性：当你将逻辑从表驱动系统中移出并放入模型时，错误变得不可追踪。确定性规则以可预测、可调试的方式失败。模型处理相同的工作会产生变量输出，这些输出更难观察和诊断。 风险：模型无法可靠地知道其信息何时过时，也不会标记差距。当模型成为真相的来源而不是合作伙伴的实际系统时，权威答案可能会悄悄地漂移，不会抛出错误，也不会发出警告。

屏幕 8：当确定性检查悄悄漂移时

注意 4 分钟 · 分解

当确定性检查悄悄漂移时

设置钩子 当团队对 Claude 感到兴奋时，将确定性检查放入模型中提供了一个更干净的设计：一个组件，更少的集成，更容易演示。这是高级架构师在团队快速推进且规则看起来“足够简单”时做出的举动。

一次范围通话，转录 下面的对话是一次真实的范围交流。两个人在简化设计时做出了合理的决定，在那一刻看起来像是一个干净的胜利。他们实际上做的是将一个确定性业务规则，一个必须每次都正确的规则，交给模型，一个概率系统，它在大多数时候是正确的，但不是所有时候。这个差距在开发过程中没有显现，而是在三个月后的审计中显现。 本节探讨了一种失败模式，目标是向你展示出了什么问题，以便你能够早期识别模式并做出不同的决定。

合作伙伴：“我们有一个规则，任何超过 5000 英镑的索赔都需要高级调整员。今天我们正在对索赔表进行 SQL 检查。Claude 能处理这个吗？” 架构师：“我们可以提示 Claude 提取金额并相应地路由，如果超过 5K。这使它保持在一个步骤中，而不是连接到单独的系统进行检查，所以它更简单。” 合作伙伴：“完美，这对我有用。”

[三个月后，在生产中]

在处理的 14,000 个索赔中，41 个路由错误 所有 41 个都有相同的问题。金额没有写成一个干净的数字。它隐藏在句子中，比如“估计损失约为五千英镑。”模型将“大约五千”视为一个宽松的估计，而不是应该触发高级审查的数字，所以这些索赔被发送到标准处理。规则是精确的。它必须处理的信息不是，模型遵循了规则的字面意思，而不是其意图。

什么坏了：确定性规则交给概率系统 阈值没有改变，但执行规则的内容改变了。一个需要每次都正确的确定性规则被折叠到 Claude 中，它在大多数时候是正确的。它们之间的差距就是 41 个错误路由存在的地方。 团队从未构建一组测试用例来检查路由，因为他们将路由视为模型会处理的事情，而不是业务依赖的规则。这种差异是问题的关键。业务依赖的规则必须被测试、观察并由人类拥有。你假设模型会处理的事情在它坏掉之前一直被忽略。 错误路由是由审计发现的，而不是系统自己的监控。那种会捕捉到 SQL 检查失败的日志不会记录模型在单个请求中做出的选择，所以没有任何东西标记漂移。失败一直不可见，直到有人去寻找它。

为什么这坏了 一个需要每次都正确的规则被交给一个在大多数时候正确的系统。这种权衡在范围界定期间很容易被忽略，因为模型处理了干净的情况，而干净的情况是你在演示和早期测试中看到的。“大多数时候”的成本直到你审计时才会显现，而那时合作伙伴已经在打电话了。

屏幕 9：排序现场服务能力

检查点 4 分钟 · 分解

排序现场服务能力 一个现场服务合作伙伴交给你一个知识助手的请求列表，他们的工程师将在现场使用。点击一个能力以选择它，然后点击正确的所有者桶以放置它。所有 8 个项目必须在提交前放置。

将工程师的案例笔记总结为一页交接 返回最近仓库中零件 SKU 78-A 的当前库存水平 批准工程师请求的超过 2000 英镑的退款 从设备标签的照片中提取零件号 计算三个工单的总计费时间 起草一封后续电子邮件给客户，解释延迟 告诉工程师保修是否适用于此序列号 决定是否将安全事件升级给现场经理

Claude

现有系统

人类

提交 暂时跳过

屏幕 10：分解请求

检查点 4 分钟 · 分解

分解请求 下面是一个合作伙伴简报。对于每个步骤，选择正确的所有者：Claude 负责的工作、现有系统负责的工作或人类负责的工作。上一个检查点测试你是否能识别四个属性；这个测试你是否能分解拆分。

简报 一个区域物流合作伙伴想要一个助手，对于每个入站运输异常：读取承运人的自由文本异常注释，决定运输是否符合合作伙伴发布政策的自动退款条件，查找客户的合同层级，起草通知给客户，并发出退款。

读取承运人的自由文本异常注释

Claude 现有系统 人类

决定运输是否符合合作伙伴发布政策的自动退款条件

Claude 现有系统 人类

查找客户的合同层级

Claude 现有系统 人类

起草客户通知

Claude 现有系统 人类

发出退款

Claude 现有系统 人类

提交 暂时跳过

屏幕 11：将基本元素组合成增强通话、工作流程、代理

教学 13 分钟 · 模式选择

将基本元素组合成增强通话、工作流程、代理 一旦你确定了 Claude 负责的任务部分与系统和人类负责的部分，下一个决策是结构性的：Claude 的参与采取什么形态？ 有三种模式可供选择：增强 LLM、工作流程和代理。每种模式在两个轴上采取不同的立场：可预测性（工作路径的可预测性）和模型自主性（你愿意赋予模型的自主性）。

三种结构化 Claude 参与的模式

增强 LLM 工作流程 代理

单一模型调用：你发送请求，模型完成任务，你的代码处理周围的布线。你可以添加工具使用、检索或扩展思维到该调用，但模型仍然在一个有界工作中完成一次。控制流永远不会基于模型的决定分支。当任务定义明确，输出是你可以验证的内容，并且没有理由将工作拆分为多个步骤时使用此模式。 你将任务分解为命名的步骤，并在你自己的代码中编排它们。每个步骤可能会或可能不会调用 Claude。因为控制流存在于你的代码中而不是模型内部，你可以像对待任何其他软件一样记录、测试和推理其行为。当错误成本真实存在，可观察性很重要，并且步骤可以提前确定时使用此模式。 你给 Claude 一个目标和一组工具，模型决定自己的步骤序列以达到目标。控制流存在于模型内部，而不是你的代码中。这就是它成为代理而不是工作流程的原因：工作路径没有在任何你可以检查的地方提前编写。只有当工作路径无法提前枚举，并且意外或不一致输出的成本是可接受和可恢复的时，才使用此模式。在生产中，代理通常受限于约束的工具入口点、每轮预算、明确权限和停止标准。这些约束不是选项；它们防止代理成为责任。

按可预测性和自主性映射用例 在任何用例上绘制两个轴：路径的可预测性，以及你愿意赋予模型的自主性。

高 低 低可预测性 高可预测性 模型自主性

代理高自主性，低可预测性。模型拥有轨迹。 工作流程可预测的形状；每个步骤内有界的模型判断。 增强 LLM高可预测性，低自主性。一个有界的模型调用。

增强 LLM 位于高可预测性、低自主性的象限。你知道任务，你知道好的样子，模型执行一次。 工作流程占据中间地带。整体形状是可预测的，但每个步骤可能以包含的方式涉及模型判断。 代理位于高自主性、低可预测性的角落。这是当提前枚举步骤是问题的昂贵部分时的模式：开放式调查、长期工作和下一个动作取决于上一个动作的结果的任务。Claude Code 是一个经过生产验证的示例：它探索一个不熟悉的代码库，根据已经找到的内容决定读取哪些文件，并运行多步骤的工程工作，没有人可以提前编写脚本。这是代理解锁的能力，但相关成本同样真实。这是非确定性失败在生产中集中的地方，因为模型的轨迹是控制流，没有守卫可以坐的代码边界。

工作流程中的子模式 选择工作流程并不能完全指定设计。工作流程可以采取四种形状，每种形状反映了步骤之间关系的不同假设。

子模式形状何时适用示例

链式 步骤 2 将步骤 1 的输出作为输入，顺序线性工作。 当任务自然分解为具有明确交接的阶段时使用此模式，例如提取、分类、总结。每个阶段都有一个定义的输出，下一个阶段消耗。 合同审查管道：第一次调用从原始文档中提取所有义务和截止日期，第二次调用按风险级别分类每个，第三次调用为律师起草摘要备忘录。每个阶段都有一个干净的输出，下一个阶段消耗。

路由 一个分类器，通常是 Claude 本身，决定采取哪个下游路径。 当输入种类不同，不同种类需要不同处理时使用此模式。 一个传入的支持票到达：分类器读取它并将账单问题路由到账户数据的检索索引，技术问题路由到产品文档的检索索引，升级直接路由到人类队列。相同的输入入口点，三种不同的处理路径。

并行化 多个模型调用并发运行；结果被聚合或投票。 当子任务独立并且可以同时运行时使用此模式。审查多个文件或审查长文档的不同部分适合此形状，因为没有一个子任务依赖于另一个的输出。 对十二个供应商合同的尽职审查：每个合同同时发送到一个单独的模型调用。所有十二个结果返回并聚合为一个风险报告。没有一个调用依赖于另一个的输出，所以没有理由顺序运行它们。

评估器-优化器 一个模型调用产生输出的第一次尝试。第二次调用评估它并请求修订。循环重复，直到达到质量标准或重试限制。 当质量可验证但单次尝试不够可靠时使用此模式。针对测试套件运行的代码生成，或具有严格模式的结构化输出提取，是常见应用。 模型起草对客户投诉的响应。第二次模型调用根据评分标准（是否命名具体问题，承担责任，提供品牌语调的具体下一步）对草稿进行评分，并检查输出是否符合预期结构。如果不符合，评估器返回具体反馈，生成器重写。当每个评分标准通过或达到重试限制时，循环退出。

这些四种模式并不互斥。大多数生产工作流程结合了不止一种模式，正确的选择通常是满足任务错误容忍度和可观察性要求的最简单模式，并在你有生产数据后重新审视该选择；仅在测量显示更简单模式不足时升级。

选择正确模式的框架：按顺序五个因素 按顺序遍历这五个因素。对于每个因素，询问它是否排除了三种模式中的任何一种——增强 LLM、工作流程、代理。第一个排除模式的因