AI

在过去的一年里，我们与数十个团队合作，构建了跨行业的大语言模型 (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....

自从今年二月份开始搭建自己的博客以来，我在 AI 的帮助下翻译了 100 多篇英文文章，这里给大家分享一下我的主要翻译 pipeline。在分享之前，我想先感谢一下大家都熟悉的博主——宝玉，他在推特上分享了大量 AI 相关的资讯，特别是他的三步翻译法，对我帮助很大。 我翻译英文文章的初衷是让优秀的文章可以被更多人看到，同时也方便自己留存，所以用准确恰当的中文来表达原文的含义是必要的，这点是沉浸式翻译做不到的，下面我来讲一讲我完整的翻译 pipeline。 第一步：获取文章正文 html 刚开始翻译英文文章的时候，我获取原文的方式简单粗暴，就是直接复制原网页上的内容，但缺点很明显，复制过来的内容丢失了原来的排版和格式，如果遇到包含图片的文章就更麻烦了，还需要把图片一个一个存下来，并插入到复制内容的原位置，工作量比较大切复杂。我解决这个问题的方案也很简单，在 chrome web store 上找一个能支持自动提取网页正文 html 的插件，因为html 里包含了各种标签，所以可以把版式和图片保留。这种插件很多大家可以自行搜索，也可以使用 FisherAI 插件。 这里我也简单介绍一下 FisherAI 插件，这是我年中的时候写的一款插件，说明一下这不是广告啊，因为没什么收费内容，当初写它的目的也是为了方便我自己使用而已，且它的源代码也开源了。写这个插件主要源于我对文章有自动总结和摘要的需求，看了市面上一些摘要插件，基本都无法满足我的需求。我想要的是不仅可以自动摘要，也可以聊天，也要支持工具调用，最重要的是要支持自定义使用的模型和 api key。至于提取网页正文 html 的功能正好是我的一个需求，就顺手加到了这个插件里。 第二步：使用三步翻译法进行翻译 所谓的三步就是：直译–>反思–>意译。我基于这三步翻译法创建了一个 ChatGPT 插件： TransLingo，它可以方便我调试 prompt 以及验证翻译结果的准确性。 对于短的文章，用这个插件翻译很方便，但遇到长文章就比较麻烦了，需要在插件的聊天窗口里点很多次继续，才能翻译完成，有的时候还由于文章太长被截断或失败的情况。对于长文章，有一个比较方便的解决方案，就是使用 Google AI Studio，因为 gemini 从一开始就支持 100 万 + token 上下文，特别适合长文翻译，且价格也很便宜，我最常用的模型就是 gemini-1.5-flash，这不今天 google 又放出来了 gemini-2-flash-exp，主打多模态，后续应该可以切换到这个模型上了。 下面也分享以下我在用的三步翻译 prompt，大家可以自行取用。 你是一位精通简体中文的专业翻译，尤其擅长将专业学术论文翻译成浅显易懂的科普文章。请你帮我将以下英文段落翻译成中文，风格与中文科普读物相似。 规则： - 翻译时要准确传达原文的事实和背景。 - 即使意译也要保留原始段落格式，以及保留术语，例如 FLAC，JPEG 等。保留公司缩写，例如 Microsoft, Amazon, OpenAI 等。 - 人名不翻译 - 同时要保留引用的论文，例如 [20] 这样的引用。 - 对于 Figure 和 Table，翻译的同时保留原有格式，例如：“Figure 1: ”翻译为“图 1: ”，“Table 1: ”翻译为：“表 1: ”。 - 全角括号换成半角括号，并在左括号前面加半角空格，右括号后面加半角空格。 - 输出格式为 Markdown 格式 - 在翻译专业术语时，第一次出现时要在括号里面写上英文原文，例如：“生成式 AI (Generative AI)”，之后就可以只写中文了。 - 遇到用figure包裹的img标签，只需保留img的src属性，其他属性如alt/loading/width/height/srcset等需要忽略掉。 - 以下是常见的 AI 相关术语词汇对应表（English -> 中文）： * Transformer -> Transformer * Token -> Token * LLM/Large Language Model -> 大语言模型 * Zero-shot -> 零样本 * Few-shot -> 少样本 * AI Agent -> AI 智能体 * AGI -> 通用人工智能 * o1 -> o1 策略： 分三步进行翻译工作，并打印每步的结果： 1....