Anthropic

本文由 Anthropic 发布，聚焦于 Claude 在编码相关任务中的应用情况。通过对 Claude.ai 和专用编码工具 Claude Code 上 500,000 次交互的分析，揭示了 AI 在编码实践中的新兴模式、应用领域及采纳趋势。 主要观点 AI 驱动编码自动化趋势显著：特别是在专用的 AI 编码工具（如 Claude Code）中，AI 更倾向于直接执行任务（自动化），而非仅仅辅助人类（增强）。 用户界面开发是 AI 编码的热点：开发者普遍使用 AI 构建面向用户的应用程序，如网页和移动应用的界面，这可能导致相关工作岗位面临更早的 AI 冲击。 初创企业在 AI 编码工具采纳上领先：与大型传统企业相比，初创企业更积极地采用尖端的 AI 编码工具，显示出更强的敏捷性。 软件开发领域的 AI 应用或为其他行业的先导指标：编码作为 AI 应用相对成熟的领域，其发展模式可能为预测 AI 在其他职业领域的影响提供参考。 关键细节 AI 使用模式：自动化与增强 在 Claude Code 上，79% 的对话被识别为“自动化”（AI 直接执行任务），而“增强”（AI 协作并提升人类能力）占 21%。相比之下，Claude.ai 的自动化比例为 49%。 “反馈循环”（Feedback Loop）模式（AI 自主完成任务，但需人类验证和纠错）在 Claude Code 上更为普遍（占交互的 35.8%），远高于 Claude.ai（21.3%）。 “指令式”（Directive）对话（AI 以最少用户交互完成任务）在 Claude Code 上也更高（43.8% vs 27.5%）。 所有增强模式（包括“学习”）在 Claude Code 上的比例均低于 Claude....

本文翻译自 MCP 官方文档。 路线图 - 模型上下文协议 (MCP) 模型上下文协议 (MCP) 正在快速发展。本页面概述了我们当前对 2025 年上半年 关键优先事项和未来方向的思考，尽管随着项目的发展，这些内容可能会发生重大变化。 这里提出的想法并非承诺——我们可能会以不同于所述的方式来解决这些问题，或者其中一些问题可能根本不会实现。这也不是一个详尽的列表；我们可能还会加入这里未提及的工作内容。 我们鼓励社区参与！每个部分都链接到相关讨论，您可以在其中了解更多信息并贡献您的想法。 远程 MCP 支持 我们的首要任务是改进远程 MCP 连接，允许客户端通过互联网安全地连接到 MCP 服务器。关键举措包括： 认证与授权：添加标准化的认证授权能力，特别侧重于 OAuth 2.0 支持。 服务发现：定义客户端如何发现并连接到远程 MCP 服务器。 无状态操作：思考 MCP 是否也可以包含无服务器环境，在这种环境中它们需要基本上是无状态的。 参考实现 为了帮助开发者使用 MCP 进行构建，我们希望提供以下方面的文档： 客户端示例：全面的参考客户端实现，演示所有协议功能。 协议起草：简化提出和采纳新协议功能的流程。 分发与发现 展望未来，我们正在探索使 MCP 服务器更易于访问的方法。我们可能研究的一些领域包括： 包管理：MCP 服务器的标准化打包格式。 安装工具：简化跨 MCP 客户端的服务器安装。 沙盒化：通过服务器隔离提高安全性。 服务器注册表：用于发现可用 MCP 服务器的通用目录。 智能体 (Agent) 支持 我们正在扩展 MCP 的能力以支持复杂的智能体工作流，特别关注： 分层智能体系统：通过命名空间和拓扑感知改进对树状智能体结构的支持。 交互式工作流：更好地处理跨智能体层级的用户权限和信息请求，以及将输出发送给用户而非模型的方式。 流式结果：来自长时间运行的智能体操作的实时更新。 更广泛的生态系统 我们也致力于： 社区主导的标准开发：促进一个协作生态系统，所有 AI 提供商都可以通过平等参与和共享治理，帮助将 MCP 打造成一个开放标准，确保它满足多样化的 AI 应用和用例需求。 其他模态：扩展到文本之外，以支持音频、视频和其他格式。 [标准化]：考虑通过标准化组织进行标准化。 参与进来 我们欢迎社区参与塑造 MCP 的未来。请访问我们的 GitHub 讨论区 加入对话并贡献您的想法。

本文翻译自 MCP 官方文档。 核心架构 模型上下文协议 (MCP) 构建在一个灵活、可扩展的架构之上，旨在实现 LLM 应用和集成之间的无缝通信。本文档涵盖了其核心架构组件和概念。 概述 MCP 遵循客户端-服务器架构，其中： 主机 (Hosts) 是发起连接的 LLM 应用（例如 Claude Desktop 或 IDE）。 客户端 (Clients) 在主机应用内部，与服务器保持 1:1 连接。 服务器 (Servers) 向客户端提供上下文、工具和提示。 核心组件 协议层 协议层处理消息分帧、请求/响应关联以及高级通信模式。 class Session(BaseSession[RequestT, NotificationT, ResultT]): async def send_request( self, request: RequestT, result_type: type[Result] ) -> Result: """ Send request and wait for response. Raises McpError if response contains error. """ # Request handling implementation async def send_notification( self, notification: NotificationT ) -> None: """Send one-way notification that doesn't expect response....

本文翻译自 MCP 官方文档。 使用 LLM 构建 MCP 本指南将帮助您使用 LLM（大型语言模型）来构建自定义的模型上下文协议 (MCP) 服务器和客户端。本教程将重点介绍 Claude，但您可以使用任何前沿的大型语言模型来完成此操作。 准备文档 在开始之前，请收集必要的文档以帮助 Claude 理解 MCP： 访问 https://modelcontextprotocol.io/llms-full.txt 并复制完整的文档文本 导航至 MCP TypeScript SDK 或 Python SDK 代码库 复制 README 文件和其他相关文档 将这些文档粘贴到您与 Claude 的对话中 描述您的服务器 提供文档后，清晰地向 Claude 描述您想要构建什么样的服务器。具体说明： 您的服务器将公开哪些资源 它将提供哪些工具 它应提供哪些提示 它需要与哪些外部系统交互 例如： 构建一个 MCP 服务器，该服务器需具备以下功能： - 连接到我公司的 PostgreSQL 数据库 - 将表结构（table schemas）作为资源进行公开/暴露 - 提供用于运行只读 SQL 查询的工具 - 包含用于常见数据分析任务的提示（prompts） 与 Claude 协作 在与 Claude 合作开发 MCP 服务器时： 首先从核心功能开始，然后迭代添加更多功能 请 Claude 解释您不理解的代码部分 根据需要请求修改或改进 让 Claude 帮助您测试服务器并处理边缘情况 Claude 可以帮助实现所有关键的 MCP 功能：...

本文翻译自 MCP 官方文档。 模型上下文协议 (MCP) 是一个开放协议，用于标准化应用程序如何向大语言模型 (LLM) 提供上下文信息。您可以将 MCP 视为 AI 应用的 USB-C 接口。正如 USB-C 提供了一种标准化的方式，将您的设备连接到各种外围设备和配件，MCP 也提供了一种标准化的途径，将 AI 模型连接到不同的数据源和工具。 为什么要使用 MCP？ MCP 能够帮助您在大语言模型 (LLM) 的基础上构建 AI 智能体 (AI Agent) 和复杂的工作流程。大语言模型 (LLM) 常常需要与数据和工具进行集成，而 MCP 提供了以下优势： 日益丰富的预构建集成方案，您的大语言模型 (LLM) 可以直接使用。 灵活切换不同大语言模型 (LLM) 提供商和供应商的能力。 在您的基础设施中安全地保护数据的最佳实践。 通用架构 从本质上讲，MCP 遵循客户端-服务器架构，其中宿主应用程序可以连接到多个服务器： MCP 主机 (MCP Hosts)：希望通过 MCP 访问数据的应用程序，例如 Claude Desktop、集成开发环境 (IDE) 或 AI 工具。 MCP 客户端 (MCP Clients)：与服务器保持 1:1 连接的协议客户端。 MCP 服务器 (MCP Servers)：轻量级的程序，每个程序都通过标准化的模型上下文协议 (Model Context Protocol) 提供特定的功能。 本地数据源 (Local Data Sources)：您的计算机中的文件、数据库和服务，MCP 服务器可以安全地访问这些数据。 远程服务 (Remote Services)：通过互联网访问的外部系统 (例如，通过应用程序编程接口 (API))，MCP 服务器可以连接到这些系统。 面向服务端开发人员 开始构建你自己的服务器，以便在 Claude for Desktop 和其他客户端中使用。...

本文介绍了模型上下文协议（Model Context Protocol, MCP），这是一个旨在连接 AI 助手与数据源（如内容仓库、业务工具和开发环境）的新标准。MCP 的目标是帮助前沿模型生成更优质、更相关的响应。当前，尽管 AI 模型的能力迅速提升，但它们与数据的隔离是一个主要瓶颈。每个新的数据源都需要定制化的集成方案，使得构建真正互联互通的系统变得困难。MCP 通过提供一个通用的、开放的标准来解决这个问题，用单一协议取代碎片化的集成方式，从而更简单、更可靠地让 AI 系统访问所需的数据。 模型上下文协议（MCP）是一个开放标准，允许开发者在数据源和 AI 驱动的工具之间建立安全的双向连接。其架构包括：开发者可以通过 MCP 服务器暴露数据，或者构建连接到这些服务器的 AI 应用（MCP 客户端）。 今天发布了 MCP 的三个主要组件： 模型上下文协议规范和 SDK：为开发者提供构建 MCP 连接器的工具和指南。 Claude Desktop 应用中的本地 MCP 服务器支持：允许用户在本地环境中测试和使用 MCP 服务器。 MCP 服务器的开源仓库：提供预构建的 MCP 服务器，方便快速集成常见企业系统，如 Google Drive、Slack、GitHub、Git、Postgres 和 Puppeteer。 Claude 3.5 Sonnet 模型能够快速构建 MCP 服务器的实现，降低了组织和个人将重要数据集与 AI 工具连接的难度。Block 和 Apollo 等早期采用者已经将 MCP 集成到其系统中。Zed、Replit、Codeium 和 Sourcegraph 等开发工具公司也在利用 MCP 增强其平台，使 AI 代理能够更好地检索相关信息，理解代码任务的上下文，并生成更精确、更实用的代码。 MCP 的优势在于，开发者不再需要为每个数据源维护单独的连接器，而是可以基于统一的标准协议进行开发。随着生态系统的成熟，AI 系统在不同工具和数据集之间移动时能够保持上下文，从而构建更可持续的架构。 开发者可以立即开始构建和测试 MCP 连接器。所有 Claude.ai 计划都支持将 MCP 服务器连接到 Claude Desktop 应用。Claude for Work 客户可以开始在本地测试 MCP 服务器，将 Claude 连接到内部系统和数据集。未来还将提供用于部署远程生产 MCP 服务器的开发者工具包。...

Anthropic 于 2025年 2 月 25 日发布了其最新的 AI 模型 Claude 3.7 Sonnet，并称其为目前最智能的模型，也是市场上首个混合推理模型。该模型独特之处在于它既能提供近乎即时的响应，也能进行更长时间、逐步深入的思考，并且用户可以通过 API 精细地控制模型的思考时长。 Claude 3.7 Sonnet 既是普通 LLM 又是推理模型。在标准模式下，它是 Claude 3.5 Sonnet 的升级版；在扩展思考模式下，它会在回答前进行自我反思，从而提高其在数学、物理、指令跟随、编码和许多其他任务上的性能。Claude 3.7 Sonnet 的开发理念与其他推理模型不同。 Anthropic 认为，推理能力应该是前沿模型的集成能力，而不是一个完全独立的模型，就像人类使用同一个大脑进行快速反应和深入思考一样。这种统一的方法为用户创造了更无缝的体验。 Claude 3.7 Sonnet 现已在所有 Claude 计划（包括 Free, Pro, Team 和 Enterprise 计划）以及 Anthropic API, Amazon Bedrock 和 Google Cloud 的 Vertex AI 上提供。扩展思考模式在除免费 Claude 层级外的所有平台均可用。 Claude 3.7 Sonnet 的定价与其前代产品相同，为每百万输入 tokens 3 美元，每百万输出 tokens 15 美元，其中包括思考 tokens 。 与 Claude 3.7 Sonnet 模型一同发布的还有 Claude Code ，这是一个用于 agentic coding 的命令行工具，目前以有限的研究预览版形式提供。 Claude Code 旨在让开发者能够直接从终端将大量的工程任务委托给 Claude 完成。...

Anthropic 推出了 Anthropic 经济指数 (Anthropic Economic Index)，旨在深入理解 生成式 AI 系统对劳动力市场和经济产生的重大影响。该指数的首份报告基于 Claude.ai 上的数百万匿名对话进行了首次数据分析，揭示了 生成式 AI 如何融入现代经济中的实际工作任务。为了促进更广泛的研究和政策制定，Anthropic 开放了用于此分析的数据集，并邀请经济学家、政策专家和其他研究人员为该指数提供input。 初步报告的主要发现包括： 生成式 AI 的使用目前主要集中在软件开发和技术写作任务中。 大约 36% 的职业在其至少四分之一的相关任务中使用了 生成式 AI，而约 4% 的职业在其四分之三的相关任务中使用了 生成式 AI。 生成式 AI 的使用更倾向于增强人类能力（57%），即 AI 与人类协作并提升其能力，而非直接自动化任务（43%）。 生成式 AI 在中等至中高工资职业中的使用更为普遍，但在最低和最高工资岗位中的使用率较低。这可能反映了当前 AI 能力的局限性以及技术应用的实际障碍。 数据来源与分析方法 该研究基于经济学文献中关于职业任务而非职业本身的见解，使用 Anthropic 内部的自动化分析工具 Clio 分析了约一百万次 Claude (Free 和 Pro 版本) 的对话。Clio 将每次对话与美国劳工部 ONET (Occupational Information Network) 数据库中的职业任务进行匹配，ONET 数据库包含约 20,000 个特定工作相关任务。然后，研究人员按照 O*NET 的分类方案，将任务分组到相应的职业和职业类别中。 AI 使用的行业分布 数据显示，“计算机和数学” 类别（主要涵盖软件工程角色）的职业中，生成式 AI 的采用率最高，占 Claude 查询的 37....

DeepSeek 开源的推理模型 R1 影响力太大，从 1 月 20 号开源到现在已经一周多了，国内外社交媒体上仍然在讨论，热度不减，同时也登顶了中国、美国、英国等多个国家的 App Store 的下载榜榜首，离谱的是甚至让英伟达的股价暴跌了 17%，原因是 R1 的能力水平与 OpenAI 的 o1 相媲美，但成本仅为o1的3%-5%，训练成本仅为560万美元。投资者担心，DeepSeek的突破可能会减少对英伟达高端GPU的需求，从而影响公司的盈利能力。连 OpenAI CEO 和 Anthropic CEO 都亲自下场讨论（酸一下），可见其影响力之大。 本文是 Anthropic CEO Dario Amodei 撰写的一篇有关 DeepSeek 的文章。其的核心观点是，尽管 中国 AI 公司 DeepSeek 在降低 AI 模型成本和提升性能方面取得了显著进展，但这非但没有削弱，反而更加强调了美国对华芯片出口管制的重要性。作者认为，出口管制是确保民主国家在 AI 发展中保持领先地位，并防止中国在 AI 领域取得军事主导地位的关键手段。DeepSeek 的技术进步，实际上是在预期的 AI 成本降低趋势之内，而非颠覆性的突破，因此不能被视为放松出口管制的理由。 DeepSeek 的模型进展： DeepSeek 发布了 DeepSeek-V3 和 R1 两款模型。 DeepSeek-V3 作为预训练模型，在某些任务上性能接近美国最先进的模型，且训练成本更低，这主要归功于其在工程效率上的创新，例如 改进了 Key-Value cache 管理和 mixture of experts 方法。然而，DeepSeek-V3 的性能仍落后于某些美国模型（如 Claude 3.5 Sonnet），且其成本降低幅度与 AI 领域正常的成本下降趋势（约每年 4 倍）基本一致，并非革命性的经济变革。 R1 模型则是在 V3 的基础上增加了强化学习（RL）训练阶段，类似于 OpenAI 的 o1 模型，表明多家公司在推理模型方面都取得了进展，但这主要是因为目前正处于 RL 技术扩展的早期阶段。 AI 发展的三个基本动态： 理解 AI 发展需要关注三个动态。 Scaling laws，即模型训练规模越大，性能越好。 Shifting the curve，指算法和硬件的进步不断提高训练效率，降低成本。作者估计，目前成本曲线的下降速度约为每年 4 倍。 Shifting the paradigm，指训练范式的转变，例如从预训练模型到使用强化学习训练推理模型，这会带来新的扩展机会和性能提升。 出口管制的重要性： 尽管 AI 模型训练成本在降低，但为了追求更强大的 AI，总体的研发投入仍在持续增加。作者预测，到 2026-2027 年，实现超越人类的通用 AI 可能需要数百万芯片和数百亿美元的投入。 出口管制是阻止中国获得大量先进芯片，从而避免中美在 AI 领域形成 “两极世界” 的关键。在 “两极世界” 中，中国可能集中资源发展军事 AI，从而取得全球主导地位。有效的出口管制有助于维持 “单极世界”，即美国及其盟友在 AI 领域保持长期领先优势。 DeepSeek 的案例并非出口管制失败的证据： DeepSeek 拥有相当数量的芯片（约 5 万片 Hopper 架构芯片），因此能够训练出高性能模型并不意外。 出口管制的目的不是阻止中国获得少量芯片，而是阻止其获得支撑大规模 AI 发展的数百万芯片。 DeepSeek 目前拥有的芯片类型（包括 H100、H800 和 H20）表明，出口管制在一定程度上是有效的，中国可能通过走私和利用管制漏洞获取部分芯片，但也面临着获取最先进芯片和大规模芯片的限制。 加强和完善出口管制，仍然是阻止中国在 AI 领域取得决定性优势的关键。 原文 几周前，我 撰文指出，美国应该对出口到中国的芯片实施更严格的管制。此后，中国的人工智能公司 DeepSeek 设法在某些方面，至少在某些特定基准测试上， 在性能上逼近了美国最先进的 AI 模型，而且成本更低。 我在这里不打算讨论 DeepSeek 是否对 Anthropic 这样的美国 AI 公司构成威胁 (尽管我认为关于它们威胁美国 AI 领导地位的说法被严重夸大了) 1。相反，我将重点探讨 DeepSeek 的发布是否削弱了对芯片出口管制政策的必要性。我认为并没有。事实上， 我认为这些发布使得出口管制政策比一周前更加至关重要2。 出口管制的一个重要作用是：确保民主国家在 AI 发展中保持领先地位。需要明确的是，出口管制不是为了逃避美国和中国之间的竞争。最终，如果想要在竞争中获胜，美国和其他民主国家的 AI 公司必须拥有比中国更好的模型。但是，我们不应该在不必要的情况下，将技术优势拱手让给中国共产党。 AI 发展的三个关键动态 在阐述我的政策观点之前，我想先描述 AI 系统的三个基本动态，理解这些动态至关重要： 缩放定律 (Scaling laws)。 我和我的联合创始人在 OpenAI 工作时，是最早 记录 AI 这一特性的：在所有条件相同的情况下，扩大 AI 系统的训练规模，通常会在各种认知任务上带来更平滑、更好的结果。例如，一个价值 100 万美元的模型可能解决 20% 的重要编码任务，一个价值 1000 万美元的模型可能解决 40%，一个价值 1 亿美元的模型可能解决 60%，以此类推。这些差异在实际应用中通常会产生巨大影响——10 倍的规模提升可能相当于本科生和博士生之间的技能水平差异——因此，各公司都在大力投资训练这些模型。 曲线的改变 (Shifting the curve)。 该领域不断涌现出各种各样的创新想法，从而提高效率：例如改进模型的架构 (对目前所有模型都采用的 Transformer (转换器) 架构进行调整) ，或者改进模型在底层硬件上的运行效率。新一代硬件也会产生类似的效果。这些创新通常会 改变缩放曲线：如果某项创新带来了 2 倍的 “计算效率提升倍数 (compute multiplier)” (CM)，那么你就可以用 500 万美元而不是 1000 万美元的成本，在编码任务上获得 40% 的性能；或者用 5000 万美元而不是 1 亿美元的成本获得 60% 的性能。每个顶尖的 AI 公司都会定期发现许多这样的 CM：小的 (约 1....

在过去的一年里，我们与数十个团队合作，构建了跨行业的大语言模型 (LLM) 智能体。始终如一地，最成功的实施并没有使用复杂的框架或专门的库。相反，他们是用简单的、可组合的模式构建的。 在这篇文章中，我们分享了我们从与客户合作和自己构建智能体中学到的经验，并为开发人员提供了关于构建有效智能体的实用建议。 什么是智能体？“智能体” 可以通过几种方式定义。一些客户将智能体定义为在较长时间内独立运行的完全自主的系统，使用各种工具来完成复杂的任务。其他人使用该术语来描述遵循预定义工作流程的更具规范性的实现。在 Anthropic，我们将所有这些变体归类为智能体系统，但在工作流程和智能体之间进行了重要的架构区分： 工作流程是通过预定义的代码路径协调大语言模型和工具的系统。另一方面，智能体是大型语言模型动态地指导其自身流程和工具使用的系统，保持对其如何完成任务的控制。下面，我们将详细探讨这两种类型的智能体系统。在附录 1 (“实践中的智能体”) 中，我们描述了客户发现使用这些类型的系统具有特殊价值的两个领域。 何时 (以及何时不) 使用智能体当使用大语言模型构建应用程序时，我们建议找到尽可能简单的解决方案，并且仅在需要时增加复杂性。这可能意味着根本不构建智能体系统。智能体系统通常以延迟和成本换取更好的任务性能，您应该考虑何时这种权衡是有意义的。 当需要更高的复杂性时，工作流程为定义明确的任务提供可预测性和一致性，而当需要大规模的灵活性和模型驱动的决策时，智能体是更好的选择。然而，对于许多应用程序来说，通过检索和上下文示例优化单个大语言模型调用通常就足够了。 何时以及如何使用框架有许多框架可以使智能体系统更容易实现，包括： 来自 LangChain 的 LangGraph；Amazon Bedrock 的 AI 智能体 (AI Agent) 框架；Rivet，一个拖放式 GUI 大语言模型工作流程构建器；以及Vellum，另一个用于构建和测试复杂工作流程的 GUI 工具。这些框架通过简化标准的底层任务 (如调用大语言模型、定义和解析工具以及将调用链接在一起) 使入门变得容易。但是，它们通常会创建额外的抽象层，这可能会掩盖底层的提示和响应，从而使调试变得更加困难。当更简单的设置就足够时，它们也可能使添加复杂性变得很有诱惑力。 我们建议开发人员从直接使用大语言模型 API 开始：许多模式可以用几行代码实现。如果您确实使用了框架，请确保您了解底层的代码。对底层原理的错误假设是客户错误的常见来源。 请参阅我们的 cookbook 以获取一些示例实现。 构建模块、工作流程和智能体在本节中，我们将探讨我们在生产中看到的智能体系统的常见模式。我们将从我们的基础构建模块——增强型大语言模型——开始，并逐步增加复杂性，从简单的组合工作流程到自主智能体。 构建模块：增强型大语言模型智能体系统的基本构建模块是通过检索、工具和记忆等增强功能增强的大语言模型。我们目前的模型可以积极地使用这些功能——生成他们自己的搜索查询，选择合适的工具，并确定要保留哪些信息。 我们建议关注实现的两个关键方面：根据您的特定用例定制这些功能，并确保它们为您的 LLM 提供简单、完善的文档界面。虽然有很多方法可以实现这些增强功能，但一种方法是通过我们最近发布的 模型上下文协议 (Model Context Protocol)，该协议允许开发人员通过简单的 客户端实现 与不断增长的第三方工具生态系统集成。 在本帖的剩余部分，我们将假设每个大语言模型调用都可以访问这些增强的功能。 工作流程：提示链提示链将任务分解为一系列步骤，其中每个大语言模型调用处理前一个调用的输出。您可以在任何中间步骤中添加程序化检查 (请参阅下图中的“gate”) 以确保过程仍在轨道上。 何时使用此工作流程： 此工作流程非常适合可以轻松干净地分解为固定子任务的情况。主要目标是通过使每个大语言模型调用成为更简单的任务来权衡延迟以获得更高的准确性。 提示链有用的示例： 生成营销文案，然后将其翻译成不同的语言。编写文档大纲，检查大纲是否符合某些标准，然后根据大纲编写文档。工作流程：路由路由对输入进行分类并将其定向到专门的后续任务。此工作流程允许关注点分离，并构建更专业的提示。如果没有此工作流程，针对一种输入进行优化可能会损害其他输入的性能。 何时使用此工作流程： 路由适用于以下复杂任务：存在最好单独处理的不同类别，并且可以通过大语言模型或更传统的分类模型/算法准确处理分类。 路由有用的示例： 将不同类型的客户服务查询 (一般问题、退款请求、技术支持) 定向到不同的下游流程、提示和工具。将简单/常见的问题路由到较小的模型 (如 Claude 3.5 Haiku)，将困难/不常见的问题路由到功能更强大的模型 (如 Claude 3....