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的过程中去思考的点。

内容概要:本文详细介绍了一个基于C++的养老院管理系统的设计与实现,旨在应对人口老龄化带来的管理挑战。系统通过整合住户档案、健康监测、护理计划、任务调度等核心功能,构建了从数据采集、清洗、AI风险预测到服务调度与可视化的完整技术架构。采用C++高性能服务端结合消息队列、规则引擎和机器学习模型,实现了健康状态实时监控、智能任务分配、异常告警推送等功能,并解决了多源数据整合、权限安全、老旧硬件兼容等实际问题。系统支持模块化扩展与流程自定义,提升了养老服务效率、医护协同水平和住户安全保障,同时为运营决策提供数据支持。文中还提供了关键模块的代码示例,如健康指数算法、任务调度器和日志记录组件。; 适合人群:具备C++编程基础,从事软件开发或系统设计工作1-3年的研发人员,尤其是关注智慧养老、医疗信息系统开发的技术人员。; 使用场景及目标:①学习如何在真实项目中应用C++构建高性能、可扩展的管理系统;②掌握多源数据整合、实时健康监控、任务调度与权限控制等复杂业务的技术实现方案;③了解AI模型在养老场景中的落地方式及系统架构设计思路。; 阅读建议:此资源不仅包含系统架构与模型描述,还附有核心代码片段,建议结合整体设计逻辑深入理解各模块之间的协同机制,并可通过重构或扩展代码来加深对系统工程实践的掌握。
内容概要:本文详细介绍了一个基于C++的城市交通流量数据可视化分析系统的设计与实现。系统涵盖数据采集与预处理、存储与管理、分析建模、可视化展示、系统集成扩展以及数据安全与隐私保护六大核心模块。通过多源异构数据融合、高效存储检索、实时处理分析、高交互性可视化界面及模块化架构设计,实现了对城市交通流量的实时监控、历史趋势分析与智能决策支持。文中还提供了关键模块的C++代码示例,如数据采集、清洗、CSV读写、流量统计、异常检测及基于SFML的柱状图绘制,增强了系统的可实现性与实用性。; 适合人群:具备C++编程基础,熟悉数据结构与算法,有一定项目开发经验的高校学生、研究人员及从事智能交通系统开发的工程师;适合对大数据处理、可视化技术和智慧城市应用感兴趣的技术人员。; 使用场景及目标:①应用于城市交通管理部门,实现交通流量实时监测与拥堵预警;②为市民出行提供路径优化建议;③支持交通政策制定与信号灯配时优化;④作为智慧城市建设中的智能交通子系统,实现与其他城市系统的数据协同。; 阅读建议:建议结合文中代码示例搭建开发环境进行实践,重点关注多线程数据采集、异常检测算法与可视化实现细节;可进一步扩展机器学习模型用于流量预测,并集成真实交通数据源进行系统验证。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

壹氿

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

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

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

打赏作者

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

抵扣说明:

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

余额充值