AI开发者 - 构建Agent的三个核心思想

前言

本文章主要内容来源于Anthropic(Claude)的工程师Barry Zhang的分享

视频地址:https://www.youtube.com/watch?v=D7_ipDqhtwk

如何构建一个有效的Agent:https://www.anthropic.com/engineering/building-effective-agents

博客阐述了如何去构建一个有效的Agent,以及各种场景下构建Agent的形式,对比当下构建我们构建的Agent,还是有一部分内容缺失的,比如缺少了内容的feedback,缺少了对于Agent执行任务质量的自动检验。

视频中作者主要对博客中的构建Agent的三个要点进行了展开,观点比较新颖,尤其是第三点,对于如何构建Agent提出了不一样的思考方向,接下来主要就这三点内容进行阐述。

不要为所有的事情都构建Agent

Barry Zhang列出了几个CheckList用来判断自己的场景是否适合构建Agent

任务的复杂性

  • 不复杂:比如很容易就可以构建出整个决策树,这种建议采用工作流的方式,并且是比较经济实用的。
  • 复杂:Agent适合处理比较模糊的问题,比如代码生成,只是一个从需求转换为代码的过程,结果的预期是模糊的,两个不同的人,写出来的代码肯定都不一样,但达成的效果都是一样的。

任务的价值

这里主要指的是成本,也就是让Agent去做这件事带来的价值是否与消耗的token是否成正比。

否则还是考虑考虑工作流或者不使用Agent吧。

可行性

Agent是否在任务的各个节点是否都可以做的很好。

这一点没太理解作者的解释,我个人理解是如果整个任务中,有一些节点不适合Agent去做,可以尝试将这些节点抽离出来,以工作流的方式去实现,或者是在多Agent协作的模式中,将这些节点拆分到其它的Agent中去做,也就是简化单一Agent职责。

任务执行错误的风险和发现错误的成本

  • 如果对任务的执行结果要求比较高,那Agent不太适合去做。
  • 能不能在Agent执行任务失败后第一时间发现问题。

通过这一点可以反思下我们目前的Agent,有没有这些问题,在设计Agent之初,应该考虑到这一点,当然还要具体场景具体分析了。比如目前我们的场景,有没有正确的帮用户去处理相关的任务,效果是不是如预期一样进行,是不是缺少了这个Feedback机制。

在本节的最后,作者举例为什么Agent适合编码,按照上述的几个标准,都给出了相应的解释:

  1. 任务的复杂性: 将设计文档转换为代码本就是一个比较复杂且模糊的事情
  2. 任务的价值: 作为开发人员,当然我们认为自己的代码的价值很高~
  3. 可行性: Agent可以胜任这个工作,感觉作者有点儿过于自信Claude的编码能力了,虽然做简单的作业是没有问题,但如果当代码文件过多时,AI的能力显得就不足了。不过最近OpenAI(CodeX)和Google(jules)都发布了代码生成的Agent,但现阶段仅限于对GitHub仓库的项目进行操作
  4. **执行错误的风险和发现错误的成本:**代码生成可以生成对应的单测和持续集成来验证生成的质量

Google jules:https://jules.google/

Keep It Simple

作者提到Agent的三个核心元素:环境、工具和系统提示。

  • 环境是Agent对于现实世界的认知
  • 工具是Agent与现实世界的交互的方式
  • 系统提示:Agent的目标、约束和在实际工作时的理想行为

任何Agent都脱离不了这三个元素,且尽量只有这三个元素。主要针对这三个元素进行迭代,其效果是非常显著的,这也是为什么作者认为Agent要Keep It Simple。

像你的Agent一样思考

Barry Zhang认为我们总是自以为理解Agent的行为,但其实我们的理解可能是错误的,建议我们从Agent的的角度尝试去完成一次任务,在这个过程中可能会感到不适,但只有这样我们才能知道Agent需要什么。

作者以他们公司构建的Computer Use Agent举例,当他以Agent的角度去思考之后,发现自己就像一个无头苍蝇一样不知所措,甚至不知道自己该点哪里。后来他知道了Agent需要知道自己所处的是一个什么分辨率的显示器。

在这个过程中可能我们会感觉到不适,但只有经历过这种不适之后,才能知道Agent需要什么。需要哪些环境、需要哪些边界、需要哪些工具、需要哪些上下文。

在这里还提到了Agent的自我迭代,这个想法之前没有听过,其大意是将AI的执行轨迹扔给AI,询问哪些地方做的不好,我们提供什么才可以帮助它做的更好,以帮助我们去理解Agent是如何看待这个世界的,其核心也是让人类不要自以为是的理解AI的行为。

总结

Barry Zhang本次分享中的几个观点都还挺有意思的,尤其是“像你的Agent一样思考”,对于后续去构建Agent包括迭代现有的Agent都有一些启发。还有他提到的“任务执行错误的风险和发现错误的成本”,也是指的我们在构建Agent的过程中去思考的点。

该数据集通过合成方式模拟了多种发动机在运行过程中的传感器监测数据,旨在构建一个用于机械系统故障检测的基准资源,特别适用于汽车领域的诊断分析。数据按固定时间间隔采集,涵盖了发动机性能指标、异常状态以及工作模式等多维度信息。 时间戳:数据类型为日期时间,记录了每个数据点的采集时刻。序列起始于2024年12月24日10:00,并以5分钟为间隔持续生成,体现了对发动机运行状态的连续监测。 温度(摄氏度):以浮点数形式记录发动机的温度读数。其数值范围通常处于60至120摄氏度之间,反映了发动机在常规工况下的典型温度区间。 转速(转/分钟):以浮点数表示发动机曲轴的旋转速度。该参数在1000至4000转/分钟的范围内随机生成,符合多数发动机在正常运转时的转速特征。 燃油效率(公里/升):浮点型变量,用于衡量发动机的燃料利用效能,即每升燃料所能支持的行驶里程。其取值范围设定在15至30公里/升之间。 振动_X、振动_Y、振动_Z:这三个浮点数列分别记录了发动机在三维空间坐标系中各轴向的振动强度。测量值标准化至0到1的标度,较高的数值通常暗示存在异常振动,可能与潜在的机械故障相关。 扭矩(牛·米):以浮点数表征发动机输出的旋转力矩,数值区间为50至200牛·米,体现了发动机的负载能力。 功率输出(千瓦):浮点型变量,描述发动机单位时间内做功的速率,取值范围为20至100千瓦。 故障状态:整型分类变量,用于标识发动机的异常程度,共分为四个等级:0代表正常状态,1表示轻微故障,2对应中等故障,3指示严重故障。该列作为分类任务的目标变量,支持基于传感器数据预测故障等级。 运行模式:字符串类型变量,描述发动机当前的工作状态,主要包括:怠速(发动机运转但无负载)、巡航(发动机在常规负载下平稳运行)、重载(发动机承受高负荷或高压工况)。 数据集整体包含1000条记录,每条记录对应特定时刻的发动机性能快照。其中故障状态涵盖从正常到严重故障的四级分类,有助于训练模型实现故障预测与诊断。所有数据均为合成生成,旨在模拟真实的发动机性能变化与典型故障场景,所包含的温度、转速、燃油效率、振动、扭矩及功率输出等关键传感指标,均为影响发动机故障判定的重要因素。 资源来源于网络分享,仅用于学习交流使用,请勿用于商业,如有侵权请联系我删除!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

壹氿

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值