如何构建有效的AI Agents:从复杂到简约——深度解读Claude实践总结《Building effective agents》(上)

在人工智能技术日新月异的今天,大语言模型(LLM)已经成为技术创新的热点。

然而,在追逐技术前沿的热潮中,我们是否忽视了工程设计的本质?

作为全球人工智能领域的领军企业之一,Anthropic以其在AI安全和伦理方面的深入研究而闻名。

该公司开发的Claude是目前最先进的大语言模型之一,凭借其强大的理解能力、逻辑推理能力和工具使用能力,在AI助手领域占据重要地位。
在这里插入图片描述

在本文解读的这份研究中,Anthropic团队基于其在开发Claude及帮助众多企业构建AI代理系统的丰富经验,为我们揭示了高效AI代理系统设计的关键原则。

这些见解不仅来自理论研究,更是源于实践检验,具有极强的参考价值,让我们重新思考LLM AI Agent 系统设计的本质。

一、返璞归真:简约设计的崛起

在当前AI领域,各类框架和工具如雨后春笋般涌现,开发者们往往会陷入一种迷思:越复杂的框架是否意味着越强大的能力?

Anthropic的研究给出了一个出人意料的答案:

恰恰相反。通过深入研究数十个行业领域的LLM代理实践案例,研究团队发现,那些最成功的实现往往采用简单、可组合的模式,而不是复杂的框架体系。

文章开篇说道:

"在过去一年里,我们与数十个团队合作,帮助他们在各个行业构建大语言模型(LLM)代理系统。

我们发现一个一致的现象:最成功的实施案例并非采用复杂的框架或专门的库,而是使用简单、可组合的模式进行构建。

在这篇文章中,我们将分享从与客户合作以及自身构建代理系统过程中获得的经验,并为开发者提供构建有效代理系统的实用建议。"

这个发现具有几个层面的重要意义:

首先, 它挑战了行业中普遍存在的一种认知——即构建复杂的AI系统需要依赖复杂的工具和框架。

这种"以复杂应对复杂"的思维定式在实践中被证明并非最佳选择。

其次 ,“simple, composable patterns”(简单、可组合的模式)这个短语透露出一种模块化、积木式的系统设计思维。

这种设计理念强调的是基础构建块的简单性和组合的灵活性,而不是整体框架的复杂性。

再次 ,这段话也体现了Anthropic的研究方法论——将实践经验转化为可操作的开发建议。

"practical advice"这个承诺表明,这篇文章不是纯理论的学术探讨,而是基于真实案例的实践指南。

最后 ,这个开篇也暗示了一个重要的技术发展趋势:

在AI代理系统设计领域,我们可能正在经历一个从"框架驱动"向"模式驱动"的转变。

这种转变可能会对整个行业的技术栈选择和系统架构设计产生深远影响。

这段开篇简短但信息量丰富,它不仅为整篇文章定下了基调,也为我们理解当前AI代理系统设计的最佳实践提供了一个重要的视角。

正如爱因斯坦所说:“不应否认任何理论的终极目标都是尽可能让基本元素变得更加简单且更少,但也不能放弃对任何一个简单数据的合理阐释。” 这似乎正是Anthropic在AI代理系统设计中发现的真理。

这个发现对于当前正在规划或开发AI代理系统的团队具有重要的指导意义:

也许我们需要放下对复杂框架的依赖,回归到更简单、更灵活的设计模式上来。

这让我想起了 Unix 设计哲学中著名的KISS原则(Keep It Simple, Stupid) ,强调在系统设计和操作过程中应该尽量避免不必要的复杂性 ,并以简单性为核心,这样能减少出错风险,提高系统的稳定性和可用性。

在软件工程领域,简单性往往是可靠性和可维护性的基石。而在LLM代理系统的设计中,这个原则似乎又一次得到了新的印证。

二、架构思维的革新:解构AI Agents系统的双重范式

在探讨具体实现之前,研究团队提出了一个富有洞见的架构区分:AI 工作流 (AI Workflows) 和智能体 (AI Agents)

这不仅仅是技术层面的分类,更是反映了两种截然不同的系统设计理念。

什么是 AI Agents
“”Agents“”可以有多种定义方式。一些客户将 AI Agents 定义为完全自主的系统,这类系统能够在较长时间内独立运行,使用各种工具来完成复杂任务。
另一些客户则用这个术语来描述更具规范性的实现,即遵循预定义工作流程的系统。
在Anthropic,我们将所有这些变体都归类为Agents 系统,但在工作流智能体之间划分了一个重要的架构区别:

  • 工作流是通过预定义的代码路径来编排LLM和工具的系统。
  • 智能体则是由LLM动态指导自身流程和工具使用的系统,能够自主控制任务完成的方式。

这段文字实际上揭示了AI代理系统领域的一个重要概念框架。

让我们从几个关键层面来解读:

2.1 概念的多元性

文章首先承认了"Agents "概念的多样性,这反映了当前行业对AI Agents 的理解仍处于演进阶段。

有趣的是,这种多样性主要体现在两个维度:自主程度(完全自主 vs 预定义流程)和运行时长(长期运行 vs 特定任务)

2.2 架构的二分法

Anthropic提出的工作流与智能体的区分极具洞见。

这种区分不是基于功能或复杂度,而是基于系统的决策自主性

  • AI Workflows 工作流就像是一条预先规划好的铁轨,LLM在其上运行
  • AI Agents 智能体则更像是一个能够自主导航的系统,可以根据情况动态选择路径

2.3 控制权的分配

这个区分实际上反映了一个深层的设计哲学:如何在系统中分配控制权。

AI Workflows 工作流将控制权交给预定义的流程,而AI Agent 智能体则将控制权赋予LLM本身。

这种差异会导致两种完全不同的系统行为模式。

2.4 实践的指向性

通过提到附录中的实际应用案例,文章暗示这种理论框架不是纯粹的学术分类,而是源于实践并服务于实践的洞察。

这种理论与实践的结合使得这个框架具有更强的指导意义。
在这里插入图片描述

2.5 设计的启示

这种分类为系统设计提供了清晰的指引:

  • 对于流程明确、需要高度可控的场景,AI Workflows 工作流模式更合适
  • 对于开放性问题、需要灵活应对的场景,AI Agents 智能体模式可能更有优势

这个概念框架不仅帮助我们理解不同类型的AI代理系统,更重要的是为选择合适的系统架构提供了理论基础。

它提醒我们,在设计AI系统时,不应简单地追求自主性的最大化,而是要根据具体应用场景选择合适的控制模式。

AI Workflows 工作流 就像一个精心编排的交响乐团,每个乐手(组件)都有其预定的谱子(代码路径)。

这种方式特别适合那些规则明确、流程固定的场景。

想象一个企业的文档处理系统,从收件、分类、处理到归档,每个环节都有其明确的规则和步骤。
在这里插入图片描述

AI Workflows 工作流系统在这种场景下能够提供稳定可靠的表现。

相比之下,AI Agents 智能体更像是一个富有创造力的即兴演奏家。

它能够根据当前情境动态决策,选择最适合的工具和方法来完成任务。

这种灵活性使得代理系统特别适合处理开放性问题和需要创造性思维的场景。

例如,在软件开发中,AI Agents 智能体可以根据具体的bug描述,动态决定需要修改哪些文件,以及如何修改。
在这里插入图片描述

三、权衡之道:AI Agents 系统的取舍艺术

何时(以及何时不)使用Agents

在构建LLM应用时,我们建议寻找最简单可行的解决方案,只在必要时才增加复杂性。
这可能意味着完全不需要构建Agent系统。
Agent系统通常用更好的任务表现来换取延迟和成本的增加,你需要考虑这种权衡是否值得。

当确实需要更复杂的系统时,工作流能为明确定义的任务提供可预测性和一致性,
而当需要大规模的灵活性和模型驱动的决策时,Agents则是更好的选择。
然而,对于许多应用来说,优化单个LLM调用,配合检索和上下文示例通常就足够了。

3.1 简约至上:重新思考Agent系统的必要性

这段文字首先提出了一个极具洞见的观点:在追求技术方案时,最简单的解决方案往往是最好的。

这不仅是一种技术层面的建议,更是一种工程设计哲学。

在当前 AI 大模型技术和GPU 算力集群快速向着更大规模和更加复杂的方向发展的背景下,这种返璞归真的思维显得尤为珍贵。
在这里插入图片描述

3.2 性能与成本的平衡

文章揭示了Agents 系统中一个关键的权衡:任务表现与系统开销之间的此消彼长关系。

这种权衡涉及三个关键维度:

  • 延迟(系统响应时间)
  • 成本(资源消耗)
  • 任务表现(输出质量)

3.3 场景驱动的技术选择

文章提供了清晰的技术选择指南:

  • 对于明确定义的任务,AI Workflows 工作流是更好的选择,因为它能提供可预测性和一致性
  • 需要灵活性和智能决策时,AI Agents系统的优势才真正显现
  • 大多数简单应用场景,优化单个LLM调用就已足够

3.4 最小可行方案的智慧

文章的核心在于提倡一种渐进式的系统构建方法:

  1. 从最简单的解决方案开始
  2. 通过实际需求驱动复杂度的增加
  3. 在每个阶段评估复杂性带来的收益是否值得

这种考虑权衡的思维方法提醒我们:

技术方案的选择不应该被炫技或跟风所驱动,而应该立足于实际需求和具体场景。

在AI系统设计中,找到正确的平衡点往往比盲目追求复杂性更重要。

这个发现对于当前正在规划或开发AI系统的团队具有重要的指导意义。

这段文字本质上是在讨论工程设计中的一个永恒主题:

如何在简单性和功能性之间找到最佳平衡点。

它提醒我们,在追求技术创新的同时,不要忘记"够用就好"的工程智慧。

四、AI Workflows工作流实践:在复杂与简约之间寻找平衡

何时以及如何使用AI Workflows工作流

目前已有许多AI Workflows工作流可以让Agent系统的实现变得更简单。比如

  • LangChain的LangGraph、
  • 亚马逊Bedrock的AI Agent工作流、
  • 用于拖放式GUI的LLM工作流构建器Rivet,
  • 以及另一个用于构建和测试复杂工作流的GUI工具Vellum。

这些工作流通过简化标准的底层任务(如调用LLM、定义和解析工具、链接调用等),让开发者能够轻松起步。
然而,它们往往会创建额外的抽象层,这可能会模糊底层的提示和响应,增加调试难度。
在一些本可以用简单设置解决的场景中,它们也可能诱使开发者增加不必要的复杂性。

我们建议开发者从直接使用LLM API开始: 许多模式只需要几行代码就能实现。
如果你确实要使用工作流,请务必理解底层代码。
对底层机制的错误假设常常是开发者最容易犯的错误。

在这里插入图片描述

4.1 回归本源:重新思考技术选择

在这个工具和平台层出不穷的时代,我们常常会迷失在众多选择中无法自拔。有句老话怎么说来着:“选择太多,所以迷惑。”

Anthropic的这篇研究为我们带来了一个清醒的视角:

技术的价值不在于其复杂程度,而在于解决问题的效果。

现代AI Workflows 确实能带来便利,让开发过程变得更加流畅,但这种便利背后潜藏着值得深思的问题。

4.2 简约之美:追寻工程的本质

当我们谈论工作流的选择时,往往容易被表面的便利性所吸引。

然而,正如研究所指出的,过度依赖工作流可能会带来意想不到的复杂性。

这就像一个魔术师的工具箱,看似能解决所有问题,但实际上可能让简单的问题变得更加复杂。

最朴素的解决方案,反而可能是最优雅的答案。

4.3 求本溯源:深入 AI 系统的底层逻辑

这里让我们关注原文中的一段深刻洞察:

“然而,它们往往会创建额外的抽象层,这可能会模糊底层的提示和响应,增加调试难度。”

这段话道出了现代 AI 开发中的一个核心难题:

AI Workflows 工作流虽然提供了便捷的开发体验,却可能在便利的表象下掩盖了系统的本质。

读到这句话时,我看着桌上的iPhone,突然让人想起已故的苹果公司创始人乔布斯的产品设计理念:

把简单留给用户,把复杂留给自己。

iPhone看似简约优美的操作界面背后,是iOS系统极其复杂的设计逻辑。
在这里插入图片描述

但关键在于,苹果的工程师们始终对这些系统底层的复杂性保持着清晰的认知和掌控。

反观AI系统开发,当我们过度依赖 AI Workflows 工作流时,就像是在自己与系统之间竖起了一道磨砂玻璃——虽然能看到轮廓,却难以捕捉细节的真实样貌。

这种情况恰恰违背了乔布斯的设计哲学:我们不是主动拥抱并掌控复杂性,而是被工作流刻意营造的"简单假象"所蒙蔽。

在AI技术迭代加速的今天,这种对根本原理的探究显得尤为珍贵。

正如中国古人在《礼记‧大学》中所言:“致知在格物”,真正的技术掌握不在于熟练使用工具,而在于深入理解其运作原理。

直接使用LLM API这种看似"原始"的方式,实际上是一种掌控复杂性的明智选择。

它能帮助开发者建立对系统的透彻理解,在遇到问题时洞察根源,找到最优解决方案。

如果你确实要使用工作流,请务必理解底层代码。
对底层机制的错误假设常常是开发者最容易犯的错误。

这种追本溯源的开发方式,体现的是一种真正的工程智慧。

在人工智能这个日新月异的领域,只有真正理解并掌控了复杂性,我们才能为用户创造出简单易用且可靠的系统。

这不仅是一种技术选择,更是一种追求卓越的专业态度。

正如iPhone手机系列产品的成功一样,真正的技术创新,在于将复杂的技术转化为简约优美的用户体验,而不是简单地逃避复杂性。

它提醒我们,在技术日新月异的今天,一些永恒的系统工程原则仍然闪耀着智慧的光芒。

简单性、可控性、深入理解,这些看似古老的价值观,在AI时代反而显得更加重要。

在快速发展的AI领域,这种返璞归真的思维方式格外珍贵。

它告诉我们,真正的创新不在于再产品上不断堆砌复杂的功能,而在于找到问题的本质并给出优雅的解决方案。

正如我们这个宇宙的数学、物理规律一样,最深刻的真理往往有着最简单的表达方式。

让我们用乔布斯这段经典的话作为上篇的结尾:
在这里插入图片描述

"简约是最高层次的精致。要让事物变得简单需要付出大量努力,这意味着你必须真正理解问题的本质,并找到优雅的解决方案。
简约并不仅仅是极简主义,也不是简单地去除杂乱。相反,它需要你深入钻研,探索事物的复杂性。
要达到真正的简约,你必须深入到问题的本质。你必须深刻理解一个产品的精髓,才能判断出哪些部分是非必需的,并将它们去除。"
—— 史蒂夫·乔布斯

今天先解读到这里,敬请期待下篇解读。

原文链接:https://www.anthropic.com/research/building-effective-agents

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:/a/944117.html

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

高中数学刷题版:函数奇偶性[干货]

文章目录 一、奇偶性定义例题 二、运算性质1、两个函数的和差积商2、复合函数3、画草图4、对称中心与对称轴 三、奇偶性判断例题 四、根据奇偶性求解析式例题 五、单调性与奇偶性的综合应用例题 一、奇偶性定义 1、定义域都是关于原点对称。 2、解析式关系 奇函数:…

【Sentinel】流控效果与热点参数限流

目录 1.流控效果 1.1.warm up 2.2.排队等待 1.3.总结 2.热点参数限流 2.1.全局参数限流 2.2.热点参数限流 2.3.案例 1.流控效果 在流控的高级选项中,还有一个流控效果选项: 流控效果是指请求达到流控阈值时应该采取的措施,包括三种&…

【Rust自学】7.4. use关键字 Pt.2 :重导入与换国内镜像源教程

喜欢的话别忘了点赞、收藏加关注哦,对接下来的教程有兴趣的可以关注专栏。谢谢喵!(・ω・) 7.4.1. 使用pub use重新导入名称 使用use将路径导入作用域内后。该名称在词作用域内是私有的。 以上一篇文章的代码为例: m…

集装箱的纸箱和塑料箱识别数据集,使用YOLO,COCO JSON,PASICAL VOC XML格式标注,识别准确率高达97.5%

集装箱的纸箱和塑料箱识别数据集,使用YOLO,COCO JSON,PASICAL VOC XML格式标注,识别准确率高达97.5% 数据集分割 训练组88% 4605图片 有效集8% 438图片 测试集4% 219图片 预处理 自动定向&#x…

TOP K问题:利用堆排序找出数组中最小的k个数

设计一个算法,找出数组中最小的k个数。以任意顺序返回这k个数均可。 找小的数需要建大堆来解决,首先将数组中前K个数建成一个大堆,将从k1个数直到数组结束的所有数与堆顶的数进行比较,如果比堆顶的数小,则替换堆顶的数…

VDA 学习手册

VDA(Verband der Automobilindustrie,德国汽车工业联合会)报文标准是专为汽车行业制定的电子数据交换(EDI)标准,用于支持供应链管理中的数据传输。它是由德国汽车工业联合会开发和维护的,广泛应…

自动化测试- 自动化测试模型

目录 自动化测试模型简介 1、线性模型 举例 测试页面html文件 测试脚本 2. 关键字驱动测试(Keyword-Driven Testing) 需测试内容 关键字驱动测试框架 创建测试用例文件 运行测试 3. 数据驱动测试(Data-Driven Testing) …

【Halcon】例程讲解:基于形状匹配与OCR的多图像处理(附图像、程序下载链接)

1. 开发需求 在参考图像中定义感兴趣区域(ROI),用于形状匹配和文本识别。通过形状匹配找到图像中的目标对象位置。对齐多幅输入图像,使其与参考图像保持一致。在对齐后的图像上进行OCR识别,提取文本和数字信息。以循环…

快速理解24种设计模式

简单工厂模式 建立产品接口类,规定好要实现方法。 建立工厂类,根据传入的参数,实例化所需的类,实例化的类必须实现指定的产品类接口 创建型 单例模式Singleton 保证一个类只有一个实例,并提供一个访问他它的全局…

CKA认证 | Day7 K8s存储

第七章 Kubernetes存储 1、数据卷与数据持久卷 为什么需要数据卷? 容器中的文件在磁盘上是临时存放的,这给容器中运行比较重要的应用程序带来一些问题。 问题1:当容器升级或者崩溃时,kubelet会重建容器,容器内文件会…

【JavaEE进阶】@RequestMapping注解

目录 📕前言 🌴项目准备 🌲建立连接 🚩RequestMapping注解 🚩RequestMapping 注解介绍 🎄RequestMapping是GET还是POST请求? 🚩通过Fiddler查看 🚩Postman查看 …

ROUGE指标在自然语言处理中的应用:从理论到实践

引言 你是否曾经遇到过机器生成的文本摘要与原文内容不符的情况?或者在使用机器翻译时,发现译文虽然“看起来”正确,但语义却与原文相差甚远?在自然语言处理(NLP)领域,如何科学地评估生成文本的…

编译openssl遇到错误Parse errors: No plan found in TAP output的解决方法

在编译openssl时 tar -zxvf openssl-1.1.1p.tar.gz cd openssl-1.1.1p ./config --prefix/usr --openssldir/etc/ssl --shared zlib make make test 遇到错误 Parse errors: No plan found in TAP output 解决方法: yum install perl-Test-Simple

Visual Studio 2017 配置 OpenCV 4.5.5 及二次配置的导入

重点参考: Visual Studio 2017 OpenCV_4.5.0安装_opencv4.5.0下载-CSDN博客 VS2017配置OpenCV4.5_vs2017 opencv4.5.4-CSDN博客 下载准备工作就不说了,直接从官网下载就行了。 关键就两步: 1)将OpenCV的bin目录添加到环境变量…

42 模板进阶

目录 一、非类型形参 (一)简介 (二)非类型形参与宏的区别 (三)注意点 二、模板的特化 (一)概念 (二)函数模板的特化 (三&#xff…

接口测试面试题

接口测试在软件测试中占据重要位置,无论是功能测试还是性能测试,接口的稳定性至关重要。以下总结了一些常见的接口测试面试题,帮助你从容应对面试挑战! 面试官常说:“接口测试是测试的重头戏,了解接口的设计…

使用ArcGIS/ArcGIS pro绘制六边形/三角形/菱形渔网图

在做一些尺度分析时,经常会涉及到对研究区构建不同尺度的渔网进行分析,渔网的形状通常为规则四边形。构建渔网的方法也很简单,使用ArcGIS/ArcGIS Pro工具箱中的【创建渔网/CreateFishnet】工具来构建。但如果想构建其他形状渔网进行相关分析&…

在Linux上获取MS(如Media Server)中的RTP流并录制为双轨PCM格式的WAV文件

在Linux上获取MS(如Media Server)中的RTP流并录制为双轨PCM格式的WAV文件 一、RTP流与WAV文件格式二、实现步骤三、伪代码示例四、C语言示例代码五、关键点说明六、总结在Linux操作系统上,从媒体服务器(如Media Server,简称MS)获取RTP(Real-time Transport Protocol)流…

Docker 是什么? Docker 基本观念介绍与容器和虚拟机的比较

🧑 博主简介:CSDN博客专家,历代文学网(PC端可以访问:历代文学,移动端可微信小程序搜索“历代文学”)总架构师,15年工作经验,精通Java编程,高并发设计&#xf…

Wend看源码-Java-集合学习(List)

摘要 本篇文章深入探讨了基于JDK 21版本的Java.util包中提供的多样化集合类型。在Java中集合共分类为三种数据结构:List、Set和Queue。本文将详细阐述这些数据类型的各自实现,并按照线程安全性进行分类,分别介绍非线程安全与线程安全的实现方…