Claude+官方发布《构建高效的+Agents》简体中文版

Claude官方发布《构建高效的Agents指南》 在上一篇文章中，我们解读了Claude官方发布的研究报告 如何构建有效的AIAgents：化繁为简——深度解读Claude实践《Buildingeffectiveagents》(上) 很多朋友想通读Anthropic的这份原版报告，今天我为你带来这篇研究报告的中文翻译完整版。 导读部分 当我们畅想人工智能的未来时，很容易陷入一个直觉思维： 系统越复杂，功能越强大。 然而，Anthropic最新发布的研究报告却给�了一个令人深思的答案——在AI代理（AIAgents）的开发中，"LessisMore"才是制胜法则。 过去一年，通过与数十个行业团队的密切合作，Anthropic发现了一个有趣的现象： 最成功的AI代理系统并非建立在复杂的框架之上，而是采用简单、可组合的设计模式。这个发现颠覆了许多开发者的固有认知。 想象一下，当你需要一个能自主完成复杂任务的AI助手时，你会怎么做？ 是堆砌繁复的技术框架，还是从最基础的模块开始，逐步构建一个优雅精简的系统？ 这个选择，可能比你想象的更重要。 为什么简单的设计反而能带来更好的效果？AI代理的未来究竟在何方？ 让我们跟随Anthropic的研究发现，一起探索AI开发中这个令人着迷的悖论…… 在公众号后台发送口令“Agent”即可获取完整原版PDF报告。 接下来，我们来跟随Anthropic研究团队，从他们过去一年的实践中一起看看如何“构建有效的Agents”。 等等，在这之前，我们可能先得统一下对“Agents”的理解。这样才能更准确地理解Anthropic 研究报告的意思。 最近AIAgent比较火，带动了很多人热衷讨论，就连续看到了一些比较奇葩的言论：有人说他家的智能空调就是一个"数字孪生的AI智能体"。 看到这种说法，我忍不住想笑：照这么说，我家那台老洗衣机岂不是早就进化成"智能体"了？其实，这反映�一个挺普遍的问题：很多人对Agents这个概念理解得不够透彻。 我们不妨从词源学的角度�发来理解"Agent"这个词。 它源自拉丁语"agere"，意为"行动、执行、推动"，引申义为"代表他人做某事的人"。这个词在进入英语后，一直保持着"代表某人或某个组织行动的人"这层核心含义。我们看看现实生活中的例子就更清楚了： o•FBIAgent（联邦调查局特工）——代表政府执行执法任务 o•TravelAgent（旅行社代理人）——代表旅客安排行程 o•InsuranceAgent（保险代理人）——代表保险公司办理业务。这些场景中的Agent都在扮演着"代表他人做某事"的角色。 正是基于这种"代表他人做某事"的本质含义，我们不应该把AIAgent生硬地翻译成"智能体 "。 "智能体"这个词虽然听起来很高级，但完全丢失了"代理"这个核心概念。更准确的译法应该是"AI代理人"或"AI执行者" ——它强调了这类AI系统的本质：代表人类执行特定任务的数字化代理人。 当我们真正理解了Agents的本质，对其应用也就有了更清晰的认识。具体来说，有三点关键洞察值得分享： 第一点，它必须从实际工作流程�发。任何一个靠谱的AIAgent项目，都应该先摸清楚现 有流程中的痛点。比如，哪些环节特别耗费人力？哪些任务总是让团队叫苦不迭？这些才是 AIAgent该着手解决的问题。 说完痛点，我们来看价值，AIAgents的核心价值在于实现从手动到自动的转变。 它就像一个得力助手，接管那些原本需要人工重复操作的任务。 重点是"接管"而不是"创造"——我们要找的是已经存在且有价值的人工环节，而不是为 了用AI而用AI。 最后，从商业角度来看，也是最实在的一点：投资回报率。 把手动流程转化为自动化后，到底能省下多少人力成本？能提升多少效率？这些都是衡量AIAgent项目是否值得投入的关键指标。 相比之下，那些本来就是自动化的系统，比如自动调温的空调，硬要贴上AIAgents的标签，不过是赶时髦罢了。 真正的AIAgents应该是帮你解决实际问题的数字助手，而不是概念上的哗众取宠。 这也正印证了Anthropic团队所强调的"LessisMore"理念——真正有价值的AIAgents往往始于对具体问题的深入理解，而不是华丽的技术包装。 以下请阅读Anthropic团队的研究报告。 构建高效的Agents 过去一年里，我们与来自不同行业的数十个团队合作，共同开发基于大语言模型（LLM）的代理系统。 我们发现一个持续的现象：最成功的实现并非依赖复杂的框架或专门的代码库，而是采用简单、可组合的模式构建。 在这篇文章中，我们将分享与客户合作以及自主构建代理系统过程中的经验，并为开发者提 供一些实用建议。 什么是Agents代理？ "代理"（Agent）可以有多种定义方式。有些客户将代理定义为完全自主的系统，它们能够长期独立运行，利用各种工具完成复杂任务。 也有客户用这个术语来描述更具规范性的实现，即遵循预定义工作流程的系统。 在Anthropic，我们将这些变体都归类为代理型系统，但在架构上区分了工作流和代理： o•工作流是通过预定义的代码路径来编排LLM和工具的系统。 o•而代理则是LLM能够动态指导自身的处理过程和工具使用的系统，它们能够自主控制任务的完成方式。 接下来，我们将详细探讨这两类代理型系统。 在附录1（"代理的实践应用"）中，我们会介绍客户在使用这些系统时发现特别有价值的两 个领域。 何时（以及何时不）使用代理？ 在构建基于LLM的应用时，我们建议先寻找最简单的解决方案，只在必要时才增加复杂性。这可能意味着完全不需要构建代理型系统。 代理型系统通常会用延迟和成本来换取更好的任务表现，您需要考虑这种取舍是否值得。当确实需要更复杂的系统时，对于明确定义的任务，工作流能提供更好的可预测性和一致性；而当需要大规模的灵活性和模型驱动的决策时，代理则是更好的选择。 不过，对于许多应用来说，优化单个LLM调用（配合检索和上下文示例）通常就足够了。 框架的使用时机和方式 目前有许多框架可以让代理系统的实现变得更简单，包括： o•来自LangChain的LangGraph； o•亚马逊Bedrock的AI代理框架； o•Rivet，一个拖放式的LLM工作流构建工具； o•Vellum，另一个用于构建和测试复杂工作流的图形界面工具。 这些框架通过简化标准的底层任务（如调用LLM、定义和解析工具、链接调用等），使入门变得容易。 但是，它们往往会创建额外的抽象层，这可能会掩盖底层的提示和响应，使调试变得更困难。 它们也可能诱使开发者在一个更简单的设置就足够的情况下增加不必要的复杂性。我们建议开发者直接从使用LLMAPI开始：许多模式只需要几行代码就能实现。 如果您确实要使用框架，请确保理解底层代码。对框架内部机制的错误假设是客户常见的错 误来源。 具体实现示例请参考我们的操作指南。 构建模块、工作流和代理 在这一节中，我们将探讨在生产环境中常见的代理系统模式。 我们将从基础构建模块——增强型LLM开始，逐步增加复杂度，从简单的组合工作流到自主代理。 构建模块：增强型LLM 代理系统的基本构建模块是经过增强的LLM，它具备检索、工具使用和记忆等功能。 我们当前的模型可以主动使用这些能力——生成自己的搜索查询、选择合适的工具，并决定保留哪些信息。 TheaugmentedLLM 对于实现，我们建议重点关注两个方面： 将这些功能针对性地适配您的具体用例，并确保为LLM提供简单、文档完备的接口。 虽然实现这些增强功能的方式有很多， 但其中一种方法是通过我们最近发布的模型上下文协议（ModelContextProtocol），它允许开发者通过简单的客户端实现来集成不断增长的第三方工具生态系统。 在本文的剩余部分，我们将假设每个LLM调用都能访问这些增强功能。 工作流：提示链 提示链将任务分解为一系列步骤，每个LLM调用都会处理前一个调用的输�。 您可以在任何中间步骤添加程序化检查（参见下图中的"gate"），以确保整个流程仍在正轨上。 Thepromptchainingworkflow 工作流的使用时机：这种工作流最适合那些可以轻松、清晰地分解为固定子任务的情况。主要目标是通过让每个LLM调用处理更简单的任务来用延迟换取更高的准确性。 提示链的实用示例： o•生成营销文案，然后将其翻译成其他语言 o•撰写文档大纲，检查大纲是否符合特定标准，然后基于大纲撰写文档 工作流：路由 路由会对输入进行分类，并将其引导至专门的后续任务。这种工作流允许关注点分离，并构建更专门化的提示。 如果没有这种工作流，为某一类型输入优化可能会影响到其他输入的性能表现。 Theroutingworkflow 使用时机：路由适用于那些有明显不同类别、需要分开处理的复杂任务，且这些类别可以通过LLM或传统的分类模型/算法进行准确分类。 路由的实用示例： o•将不同类型的客服查询（一般问题、退款请求、技术支持）引导到不同的下游流程、提示和工具 o•将简单/常见问题路由给较小的模型（如Claude3.5Haiku），将困难/特殊问题路由给更强大的模型（如Claude3.5Sonnet），以优化成本和速度 工作流：并行化 LLM有时可以同时处理任务，并通过程序化方式汇总其输�。这种并行化工作流主要有两种关键变体： o•分段：将任务拆分为并行运行的独立子任务 o•投票：多次运行相同任务以获得多样化的输� Theparallelizationworkflow 使用时机： o•并行化在以下情况下特别有效： o•一是可以将子任务并行化以提高速度 o•二是需要多个视角或尝试来获得更高置信度的结果。 o•对于涉及多个考虑因素的复杂任务，当每个考虑因素由单独的LLM调用处理时， LLM通常表现更好，因为这允许对每个具体方面进行专注处理。并行化的实用示例： 分段应用： o•实现安全防护，其中一个模型实例处理用户查询，而另一个筛查不当内容或请求。这比让同一个LLM调用同时处理安全防护和核心响应的效果更好 o•自动化评估LLM性能，每个LLM调用评估模型在给定提示下的不同表现方面。 投票应用： o•审查代码中的漏洞，多个不同的提示审查代码并在发现问题时进行标记。 o•评估给定内容是否不当，多个提示评估不同方面，或要求不同的投票阈值来平衡误报和漏报。 工作流：编排者-执行者 在编排者-执行者工作流中，一个中央LLM动态地分解任务，将它们分配给执行者LLM，并综合它们的结果。 Theorchestrator-workersworkflow 使用时机： 这种工作流非常适合那些无法预测所需子任务的复杂任务（例如，在编程中，需要修改的文件数量和每个文件中的修改性质可能都取决于具体任务）。 虽然在结构上与并行化类似，但关键区别在于其灵活性——子任务不是预先定义的，而是由编排者根据具体输入来确定。 编排者-执行者工作流的实用示例： o•需要对多个文件进行复杂修改的编程产品 o•涉及从多个来源收集和分析可能相关信息的搜索任务 工作流：评估者-优化者 在评估者-优化者工作流中，一个LLM调用生成响应，而另一个在循环中提供评估和反馈。 Theevaluator-optimizerworkflow 使用时机： 当我们有明确的评估标准，且迭代优化能带来可衡量的价值时，这种工作流特别有效。判断是否适合使用这种工作流有两个标志： o•首先，当人类明确表达反馈时，LLM的响应能够明显改善； o•其次，LLM能够提供这样的反馈。这类似于人类作者在创作精良文档时可能经历的迭代写作过程。 评估者-优化者工作流的实用示例： o•文学翻译，其中译者LLM最初可能无法捕捉到的细微差别可以通过评估者LLM的有用批评来改进。 o