Anthropic 最新发布：《Building effective agents》

最新推荐文章于 2025-03-07 15:43:48 发布

LLM大模型

最新推荐文章于 2025-03-07 15:43:48 发布

阅读量816

点赞数 25

文章标签：数据库人工智能 langchain LLM 自然语言处理 deepseek agent

本文链接：https://blog.csdn.net/DEVELOPERAA/article/details/146096918

版权

今天，Anthropic 在其官网发布了 Agent 构建的实践指南。核心观点如下：

简单优于复杂：在构建 LLM 应用时，应首先寻找最简单的解决方案，在必要时才增加复杂性。
workflow 与 Agent 的区别：workflow 是预定义代码路径的系统，而 agent 是能够动态指导自己过程和工具使用的系统。workflow 则适用于已定义任务的预测性和一致性, 而 agent 系统适用于需要灵活性和模型驱动决策的复杂任务
框架的使用与限制：虽然框架可以简化代理系统的实现，但它们也可能增加抽象层次，使得调试变得困难，并可能诱使开发者添加不必要的复杂性。
Agent 系统的类别：包括增强的 LLM、workflow （如提示链、路由、并行化、编排者 - 工作者、评估者 - 优化者）以及 Agent 本身。
工具的提示工程：在构建 Agent 系统时，工具的设计和文档至关重要，应该像为团队中的初级开发者编写文档一样投入精力。

以下是全文翻译

过去一年中，我们与来自不同行业的数十个团队合作，共同开发基于 LLM 的智能代理系统。

我们发现，最成功的实践案例往往并非依赖复杂的框架或专门的程序库，而是采用简单且可组合的模式进行构建。

本文将分享我们在与客户合作过程中的经验总结，以及自身构建智能代理的心得，为开发者提供切实可行的建议。

什么是 Agents？

Agent 可以有多种定义。

有些客户将其定义为能够长期独立运行的完全自主系统，这类系统可以运用各种工具来完成复杂任务。也有客户用Agent 来描述更具规范性的实现方案，即遵循预定义工作流程的系统。

在Anthropic，我们将这些变体统称为"agentic systems-代理系统"，但在架构上将其明确区分为"工作流 workflows "和"智能代理 agents:"两类：

工作流-workflows ：通过预定义的代码路径来协调LLM和工具的系统。
智能代理-agents：由LLM动态指导自身流程和工具使用的系统，能够自主控制任务的完成方式。

在后文中，我们将详细探讨这两类代理系统。在附录1（“智能代理的实践应用”）中，我们将介绍客户在使用这些系统时发现特别有价值的两个领域。

何时使用（或不使用）智能代理

开发基于LLM的应用时，我们建议从最简单的解决方案开始，只在必要时才增加复杂性。这可能意味着可以完全不构建代理系统。代理系统通常会牺牲延迟性能和成本来换取更好的任务执行效果，开发者需要权衡这种取舍是否值得。

当确实需要更复杂的系统时，工作流适合那些需要可预测性和一致性的明确任务，而智能代理则更适合需要灵活性和模型驱动决策的大规模应用场景。

不过对于许多应用来说，优化单次LLM调用，配合检索和上下文示例通常就足够了。

框架的选择与使用

目前有许多框架可以简化代理系统的实现，包括：

LangChain的LangGraph
亚马逊Bedrock的AI代理框架
Rivet，一个拖放式的LLM工作流构建工具
Vellum，另一个用于构建和测试复杂工作流的图形界面工具

这些框架通过简化调用LLM、定义和解析工具、链接调用等标准底层任务，使开发者能够快速入门。

但是它们往往会创建额外的抽象层，这可能会掩盖底层的提示和响应，增加调试难度。它们也可能诱使开发者在一个简单设置就足够的情况下增加不必要的复杂性。

我们建议开发者首先直接使用LLM API：许多模式只需要几行代码就能实现。如果确实要使用框架，请确保充分理解底层代码。对底层实现的错误假设是客户常见的错误来源。

请参考我们的手册获取示例实现（链接见文末）。

构建模块、工作流和智能代理

在本节中，我们将探讨生产环境中常见的代理系统模式。我们将从基础构建模块（增强型LLM）开始，逐步增加复杂度，从简单的组合工作流到自主代理。

1-基础模块：增强型LLM

代理系统的基础构建模块是一个经过增强的LLM，配备了检索、工具和记忆等扩展功能。我们当前的模型能够主动运用这些能力——生成自身的搜索查询，选择合适的工具，并决定保留哪些信息。

在实施过程中，我们建议重点关注两个关键方面：

根据具体使用场景定制这些功能
确保为LLM提供简单且文档完善的接口

虽然实现这些增强功能的方法有很多，但一种方法是使用我们最近发布的模型上下文协议，该协议允许开发者通过简单的客户端实现与不断扩展的第三方工具生态系统集成。

在本文接下来的内容中，我们假设每次调用LLM时都能访问这些增强功能。

2-工作流：提示链(Prompt chaining)

Prompt chaining 将任务分解为一系列步骤，每个LLM 调用都会处理前一个步骤的输出。你可以在任何中间步骤添加程序化检查（参见下图中的"Gate"），以确保流程仍在正轨上。

适用场景：这种工作流最适合那些可以轻松、清晰地分解为固定子任务的场景。其主要目标是通过将每次LLM调用变成更简单的任务，用延迟来换取更高的准确性。

提示链的实用案例：

生成营销文案，然后将其翻译成其他语言
先写文档大纲，检查大纲是否符合特定标准，然后基于大纲撰写完整文档。

3-工作流：路由(Routing)

路由会对输入进行分类，并将其导向专门的后续任务。这种工作流实现了关注点分离，能够构建更专门化的提示。如果不采用这种工作流，为某一类输入优化可能会损害对其他输入的处理效果。

适用场景：对于复杂任务，若存在明确分类且最好分别处理，且分类可由LLM或传统分类模型/算法准确执行时，路由机制效果良好。

路由的实用案例：

将不同类型的客服查询（一般问题、退款请求、技术支持）引导至不同的下游流程、提示和工具。
将简单/常见问题路由给Claude 3.5 Haiku等较小模型处理，将困难/罕见问题交给Claude 3.5 Sonnet等更强大的模型处理，以优化成本和速度。

4-工作流：并行 (Parallelization)

LLM有时可以同时处理任务，并通过程序化方式汇总其输出。这种并行化工作流主要有两种变体：

分割：将任务分割为可并行运行的独立子任务
投票：多次运行相同任务以获得多样化的输出

适用场景：当拆分子任务可以并行以提高速度，或需要多个视角尝试以获得更高置信度的结果时，并行化是有效的。

对于涉及多方面考虑的复杂任务，通常在每个考虑因素由单独的LLM调用处理时，LLMs表现更佳，从而使每个特定方面都能得到专注关注。

并行化的实用案例：

分割：

实现防护机制，一个模型实例处理用户查询，另一个筛查不当内容或请求。这比让同一个LLM同时处理防护和核心响应的效果更好
自动化评估LLM性能的评估过程，其中每个LLM调用针对给定提示的不同方面评估模型的性能。

投票：

审查代码漏洞，多个提示同时检查并标记发现的问题
评估内容是否不当，使用多个提示评估不同方面，或设置不同的投票阈值来平衡误判率

5-工作流：Orchestrator-workers

在 orchestrator-workers 工作流中，中央LLM 动态分解任务，将其分配给工作节点LLMs，并综合它们的结果。

适用场景：这种工作流适合无法预测所需子任务的复杂任务。例如在编程中，需要修改的文件数量和每个文件的修改性质往往取决于具体任务。虽然在拓扑结构上与并行化相似，但其关键区别在于灵活性——子任务不是预定义的，而是由调度器根据具体输入确定。

orchestrator-workers 的实用案例：

需要对多个文件进行复杂修改的编程产品
搜索任务涉及从多个来源收集和分析信息，以寻找可能的相关信息。

6-工作流：评估器-优化器 Evaluator-optimizer

在 Evaluator-optimizer 工作流中，一个LLM调用生成响应，另一个在循环中提供评估和反馈。

适用场景：这种工作流在有明确评估标准，且迭代优化能带来显著价值时特别有效。判断是否适合采用这种工作流有两个标志：首先，当人类明确表达反馈时，LLM 的响应能够得到明显改善；其次，LLM 能够提供这样的反馈。这类似于人类作者在撰写精炼文档时所经历的迭代写作过程。

评估器-优化器的实用案例：

文学翻译中存在一些细微差别，翻译者LLM可能最初未能捕捉到，但评估者LLM可以提供有用的批评意见。
需要多轮搜索和分析才能收集全面信息的复杂搜索任务，由评估器决定是否需要进一步搜索.

7-Agents

随着LLMs 在关键能力上日趋成熟——包括理解复杂输入、进行推理和规划、可靠使用工具以及从错误中恢复，Agent 正在生产环境中逐渐崭露头角。Agent 的工作始于用户的指令或交互式对话。一旦任务明确，Agent 就会独立进行规划和操作，必要时会回到用户处寻求更多信息或判断。

在执行过程中，Agent 需要在每一步都从环境中获取"基准事实"（如工具调用结果或代码执行情况）来评估进展。Agent 可以在检查点或遇到障碍时暂停以获取人类反馈。任务通常在完成时终止，但也常常包含停止条件（如最大迭代次数）以保持控制。

Agent 虽然能够处理复杂任务，但其实现通常较为简单。它们通常只是基于环境反馈在一个循环中使用工具。因此，设计工具集及其文档时必须清晰且周到。我们在附录 2（“为工具进行提示工程”）中详细阐述了工具开发的最佳实践。

何时使用： Agent 适用于难以或无法预测所需步骤数量，且无法硬编码固定路径的开放性问题。LLM可能需要运行多轮，因此你必须对其决策能力有一定程度的信任。Agent 的自主性使其特别适合在可信环境中扩展任务。

需要注意的是， Agent 的自主特性意味着更高的成本，并可能产生累积性错误。我们建议在沙箱环境中进行广泛测试，并配备适当的防护机制。

智能代理的实用案例：

以下是我们自身实践中的一些示例：

用于解决 SWE-bench 任务的编程智能代理，该任务涉及根据任务描述对多个文件进行编辑
我们的"计算机使用"参考实现，即Claude使用计算机完成任务的方案

这些案例展示了 Agent 在复杂、开放性任务中的实际应用价值，同时也强调了在实施过程中需要注意的关键考虑因素。

模式的组合与定制

这些构建模块并非固定不变的规范。它们是开发者可以根据不同用例进行调整和组合的常见模式。

与任何LLM功能一样，成功的关键在于衡量性能并不断迭代实现。需要再次强调：只有在确实能够改善结果的情况下，才应考虑增加复杂性。

总结

在LLM领域，成功并不在于构建最复杂的系统，而在于构建最适合需求的系统。

从简单的提示开始，通过全面评估进行优化，只在更简单的解决方案不足时才添加多步骤的代理系统。

在实现智能代理时，我们遵循三个核心原则：

保持代理设计的简单性。
通过明确展示代理的规划步骤来确保透明度。
通过全面的工具文档和测试来精心打造代理-计算机接口（ACI）。

框架可以帮助你快速入门，但在转向生产环境时，不要犹豫减少抽象层并使用基本组件进行构建。遵循这些原则，你可以创建既强大又可靠、可维护，并能赢得用户信任的智能代理。

附录1：智能代理的实践应用

我们与客户的合作揭示了两个特别有前景的AI代理应用场景，展示了上述模式的实践价值。这两种应用都说明了智能代理在需要对话和行动、具有明确成功标准、能够形成反馈循环并整合有意义的人类监督的任务中最具价值。

A. 客户支持

客户支持通过工具集成将熟悉的聊天机器人界面与增强功能相结合。这非常适合更开放的智能代理，因为：

支持交互自然遵循对话流程，同时需要访问外部信息和执行操作
可以集成工具来获取客户数据、订单历史和知识库文章
退款发放或工单更新等操作可以通过程序处理
可以通过用户定义的解决方案明确衡量成功

B. 编程代理

软件开发领域展现了LLM功能的巨大潜力，从代码补全发展到自主问题解决。智能代理在这里特别有效，因为：

代码解决方案可以通过自动化测试验证
代理可以使用测试结果作为反馈来迭代解决方案
问题空间明确且结构化
输出质量可以客观衡量

附录2：工具的提示工程

无论正在构建哪种代理系统，工具都可能是代理的重要组成部分。工具使 Claude 能够通过在我们的 API 中精确指定其结构和定义，与外部服务和 API 进行交互。当 Claude 响应时，如果它计划调用工具，API 响应中将包含一个工具使用块。工具定义和规范应与您的整体提示一样，给予同等程度的提示工程关注。在此简要附录中，我们描述了如何的工具进行提示工程。

通常有多种方式可以指定相同的操作。例如可以通过编写 diff 来指定文件编辑，或者通过重写整个文件来指定。

对于结构化输出，可以在 markdown 中返回代码，也可以在 JSON 中返回代码。

在软件工程中，这些差异是表面上的，并且可以无损地从一种形式转换为另一种形式。但某些格式对于 LLM 来说比其他格式更难编写。编写 diff 需要知道在新代码编写之前，块头中有多少行发生了变化。在 JSON 中编写代码（与 markdown 相比）需要额外转义换行符和引号。

在决定工具格式时，我们建议：

给模型足够的 token 来"思考"，避免陷入死角
保持格式接近模型在互联网文本中自然遇到的形式
确保没有诸如必须精确统计数千行代码或对其编写的代码进行字符串转义等“额外开销”。

一个经验法则是，考虑人类与计算机界面（HCI）投入了多少精力，并计划在创建良好的代理与计算机界面（ACI）上投入同样多的精力。以下是一些关于如何做到这一点的思考：

设身处地为模型着想。根据描述和参数，是否明显知道如何使用此工具，还是需要仔细思考？如果是后者，那么对模型来说可能也是如此。一个好的工具定义通常包括示例用法、边缘情况、输入格式要求以及与其他工具的明确界限。
如何更改参数名称或描述以使内容更加显而易见？可以将其视为为团队中的初级开发人员编写出色的文档字符串。在使用许多相似工具时，这一点尤为重要。
测试模型如何使用您的工具：在您的工作台中运行多个示例输入，以观察模型所犯的错误，并进行迭代改进。
设计防错功能，使工具更难出错

在为 SWE-bench 构建代理时，我们实际上花费了更多时间优化工具，而非整体提示。例如，我们发现模型在使用相对文件路径的工具时会出现错误，尤其是在代理移出根目录后。为解决此问题，我们将工具修改为始终要求绝对文件路径——结果发现模型能完美运用此方法。

如何系统的去学习大模型LLM ？

大模型时代，火爆出圈的LLM大模型让程序员们开始重新评估自己的本领。 “AI会取代那些行业？”“谁的饭碗又将不保了？”等问题热议不断。

事实上，抢你饭碗的不是AI，而是会利用AI的人。

继科大讯飞、阿里、华为等巨头公司发布AI产品后，很多中小企业也陆续进场！超高年薪，挖掘AI大模型人才！ 如今大厂老板们，也更倾向于会AI的人，普通程序员，还有应对的机会吗？

与其焦虑……

不如成为「掌握AI工具的技术人」，毕竟AI时代，谁先尝试，谁就能占得先机！

但是LLM相关的内容很多，现在网上的老课程老教材关于LLM又太少。所以现在小白入门就只能靠自学，学习成本和门槛很高。

基于此，我用做产品的心态来打磨这份大模型教程，深挖痛点并持续修改了近70次后，终于把整个AI大模型的学习门槛，降到了最低！

在这个版本当中：

第一您不需要具备任何算法和数学的基础
第二不要求准备高配置的电脑
第三不必懂Python等任何编程语言

您只需要听我讲，跟着我做即可，为了让学习的道路变得更简单，这份大模型教程已经给大家整理并打包，现在将这份 LLM大模型资料 分享出来：包括LLM大模型书籍、640套大模型行业报告、LLM大模型学习视频、LLM大模型学习路线、开源大模型学习教程等, 😝有需要的小伙伴，可以 扫描下方二维码领取🆓↓↓↓

👉CSDN大礼包🎁：全网最全《LLM大模型入门+进阶学习资源包》免费分享（安全链接，放心点击）👈

一、LLM大模型经典书籍

AI大模型已经成为了当今科技领域的一大热点，那以下这些大模型书籍就是非常不错的学习资源。

在这里插入图片描述

二、640套LLM大模型报告合集

这套包含640份报告的合集，涵盖了大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示。(几乎涵盖所有行业)
在这里插入图片描述

三、LLM大模型系列视频教程

在这里插入图片描述

四、LLM大模型开源教程（LLaLA/Meta/chatglm/chatgpt）

在这里插入图片描述

五、AI产品经理大模型教程

在这里插入图片描述

LLM大模型学习路线 ↓

阶段1：AI大模型时代的基础理解

目标：了解AI大模型的基本概念、发展历程和核心原理。
内容：
- L1.1 人工智能简述与大模型起源
- L1.2 大模型与通用人工智能
- L1.3 GPT模型的发展历程
- L1.4 模型工程
- L1.4.1 知识大模型
- L1.4.2 生产大模型
- L1.4.3 模型工程方法论
- L1.4.4 模型工程实践
- L1.5 GPT应用案例

阶段2：AI大模型API应用开发工程

目标：掌握AI大模型API的使用和开发，以及相关的编程技能。
内容：
- L2.1 API接口
- L2.1.1 OpenAI API接口
- L2.1.2 Python接口接入
- L2.1.3 BOT工具类框架
- L2.1.4 代码示例
- L2.2 Prompt框架
- L2.3 流水线工程
- L2.4 总结与展望