LLMs之Agent:《Building effective agents》翻译与解读—什么是智能体(Agent)→Agent的使用时机和框架→常见的工作流模式(提示链/路由/并行化/协调器-工作者/评估器-优化器)→Agent的特点和适用场景
导读:本文系统地介绍了如何构建有效的基于大型语言模型(LLM)的智能体(Agents)。文章从智能体的定义出发,逐步深入到不同类型的智能体架构、构建方法以及最佳实践。作者强调了简单性和可组合性的重要性,并提供了多种构建智能体的模式和方法,包括工作流和智能体两种架构,以及多种工作流模式(提示链、路由、并行化、协调器-工作器、评估器-优化器)。文章还强调了工具设计和测试的重要性,以及在构建过程中遵循简单性、透明性和精心设计的 ACI 的原则。通过具体的应用案例和最佳实践,文章为开发者提供了构建有效智能体的全面指南。 作者建议开发者从简单的方案开始,逐步增加复杂性,并始终关注性能和迭代改进。
>> 在LLM领域成功不在于构建最复杂的系统,而在于为需求构建合适的系统。
>> 从简单的提示开始,通过全面评估进行优化,只有在简单方案不足时才添加多步骤的代理系统。
>> 实施代理时遵循三个核心原则:保持设计的简单性、优先考虑透明性、精心构建代理-计算机接口(ACI)。
>> 框架可以帮助快速启动,但在生产过程中不要犹豫减少抽象层,使用基本组件进行构建。
>> 遵循这些原则,可以创建出不仅强大而且可靠、可维护、用户信任的代理。
目录
LLMs之Agent:基于Anthropic实现Agent的源码解读(basic_workflows.ipynb)—链式顺序工作流、并行工作流、路由工作流
《Building effective agents》翻译与解读
1.1、对比:Workflows(预定义+协调)、Agents(动态+指导)
3、常见的工作流模式:提示链、路由、并行化、协调器-工作者、评估器-优化器
The orchestrator-workers workflow
The evaluator-optimizer workflow
High-level flow of a coding agent
相关文章
LLMs之Agent:基于Anthropic实现Agent的源码解读(basic_workflows.ipynb)—链式顺序工作流、并行工作流、路由工作流
https://yunyaniu.blog.csdn.net/article/details/144943782
LLMs之Agent:基于Anthropic实现Agent的源码解读(agents/evaluator_optimizer.ipynb)—利用LLM进行迭代式的解决方案生成和评估(不断反馈和改进直到找到满足特定要求的解决方案)
https://yunyaniu.blog.csdn.net/article/details/144953694
LLMs之Agent:基于Anthropic实现Agent的源码解读(agents/orchestrator_workers.ipynb)—利用LLM进行任务分解和并行处理实现复杂任务管理和内容生成——定义提示模板(协调器提示模板【分析任务并分解为不同的方法】+工作器提示模板【根据指定的风格和指南生成内容】)→利用FlexibleOrchestrator创建协调器实例并处理任务(分解任务并在并行工作器LLM上运行)
https://yunyaniu.blog.csdn.net/article/details/144953891
《Building effective agents》翻译与解读
地址 | |
时间 | 2024年12月20日 |
作者 | Anthropic团队 |
1、什么是智能体(Agent)?
本小节区分了“工作流 (Workflows)”和“智能体 (Agents)”两种类型的智能系统。“工作流”是通过预定义代码路径协调 LLM 和工具的系统;而“智能体”是 LLM 动态地指导自身流程和工具使用的系统,自主控制任务完成方式。
1.1、对比:Workflows(预定义+协调)、Agents(动态+指导)
维度 | Workflows (工作流) | Agent (智能体) |
定义 | 通过人工预定义明确的规则和流程,来编排LLMs和工具 | 完全自主系统,长时间独立运行,使用多种工具完成复杂任务 |
决策方式 | 遵循预设的工作流程,缺乏自主调整能力,所有操作都在事先规划好的框架内进行。 | LLM动态地自主控制流程和工具使用,无需预定义的规则,能够根据环境变化作出实时调整。 |
灵活性 | 灵活性较低,受限于有明确规则或流程的真实场景,确保了执行的一致性和可预测性。 | 更加灵活,能够根据任务需求和环境变化灵活调整行为。适用于处理那些难以预测步骤数量的任务,尤其是在需要不断探索和适应新情况的情况下。 |
控制与稳定性 | 提供更高的稳定性和可靠性,特别是在重复性和结构化任务中表现出色。 | 可能存在不可控性和不稳定的问题,因为LLM会尝试自动编排流程,这可能导致执行效率问题。 |
适用场景 | 适用于较为简单或标准化流程,具有明确规则的任务,例如数据处理、自动化业务流程等。 | 适合解决复杂、难以规划、需要不断探索的任务,如开放性问题求解、创造性任务等。 |
开发难度 | 相对简单,开发者可以专注于特定任务逻辑的设计,减少对未知变量的关注。 | 开发复杂度较高,需要考虑更多不确定性因素,并设计出足够强大的反馈机制来保证系统的正确运行。 |
实例描述 | Anthropic定义中提及的遵循预定义路径的Agentic系统,比如RAG系统 | 附录1中的“Agents in Practice”提供了两个客户使用Agent系统的实际案例 |
2、Agent的使用时机和框架
2.1、何时(以及何时不)使用Agent
本小节建议优先选择最简单的解决方案,只有在必要时才增加复杂性。强调在选择使用智能体前应仔细评估其成本和收益,并建议优先考虑简单的方案。
>> Agent通常以延迟和成本为代价换取更好的任务性能,需要权衡利弊。
>> Workflows适用于定义明确的任务,而智能体适用于需要灵活性和模型驱动决策的场景。对于许多应用,优化单个LLM 调用加上检索和上下文示例就足够了。
2.2、何时以及如何使用Agent框架
本小节介绍了几个常用的智能体构建框架,例如 LangChain 的 LangGraph、Amazon Bedrock 的 AI Agent 框架、Rivet (基于拖拽式GUI的LLM工作流构建器)和 Vellum(构建和测试复杂工作流程的GUI工具)。这些框架简化了 LLM 调用、工具定义和调用链等任务,但也可能增加抽象层,导致调试困难。
>> 建议开发者先直接使用 LLM API,只有在需要时才使用框架,并确保理解底层代码。框架可以简化开发,但可能增加复杂性,建议谨慎使用,并深入理解框架的底层机制。
2.3、“构建有效代理”的案例实战
地址:https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents
3、常见的工作流模式:提示链、路由、并行化、协调器-工作者、评估器-优化器
本小节从基本的增强型 LLM 开始,逐步介绍了各种工作流模式,包括提示链、路由、并行化、协调器-工作器和评估器-优化器。每种模式都包含了其适用场景和示例。详细介绍了构建智能体的各种模式,并提供了每种模式的适用场景和示例,为开发者提供了丰富的选择。
模块/工作流 | 定义 | 适用场景 | 示例 |
构建模块:增强型LLM | 基础构建模块,通过检索、工具、记忆等功能增强的LLM,能够主动生成搜索查询,选择合适工具,并决定保留的信息。 | 通用应用场景,通过扩展能力实现高效交互与处理。 | 使用 Model Context Protocol 集成第三方工具,提供简单易用的接口以满足具体需求。 |
工作流:提示链(Prompt chaining) | 将任务分解为一系列步骤,每个LLM调用处理上一步的输出,必要时加入程序性检查确保流程正确。 | 任务可清晰分解为固定子任务,目标是提高准确性而非降低延迟。 | >> 生成市场推广文案并翻译成不同语言。 |
工作流:路由(Routing) | 对输入进行分类,将其定向到特定的后续任务。通过分类实现关注点分离,建立更专业化的提示,从而优化性能。 | 复杂任务,输入类别明显不同,需分别处理,分类可通过LLM或传统算法完成。 | >> 客服问题分类(一般问题、退款请求、技术支持)并分别处理。 |
工作流:并行化(Parallelization) | 任务可同时处理,输出结果程序性聚合,包括“分段处理”和“投票”两种形式: | 提速和提高置信度,适用于可以并行化的子任务,或需要多角度尝试以获得高置信度结果(结果可靠性)。 | >> 分段处理:用户查询与内容筛查由不同LLM处理以提高性能。自动评估LLM表现,每次调用评估不同方面。 |
工作流:协调器-工作者(Orchestrator-workers) | 中央LLM动态分解任务,分派给“工人”LLM并汇总结果。任务子部分非预定义,而是由协调器根据输入动态决定。 | 复杂任务,子任务不可预测或需要根据输入实时调整。 | >> 编码产品需对多文件进行复杂修改。 |
工作流:评估器-优化器(Evaluator-optimizer) | 一个LLM生成响应,另一个LLM提供评估和反馈,循环往复改进结果。 | 适用于有明确评估标准,迭代优化能显著提高结果质量。 | >> 文学翻译,评估者LLM提供反馈以改进译文质量。 |
The augmented LLM
The prompt chaining workflow
The routing workflow
The parallelization workflow
The orchestrator-workers workflow
The evaluator-optimizer workflow
4、Agent的特点和适用场景
本小节阐述了智能体的特点和适用场景,并强调了工具设计和测试的重要性。智能体能够处理复杂任务,其核心是 LLM 基于环境反馈循环使用工具。设计清晰的工具集和文档至关重要。智能体适用于开放式问题,但需要进行广泛测试并设置防护措施。
>> Agent随着LLM在理解复杂输入、进行推理和规划、可靠使用工具以及从错误中恢复等关键能力上的成熟,逐步出现在生产环境中。
>> Agent从用户的命令或与用户的互动讨论开始工作,任务明确后独立计划和操作,必要时可返回询问用户更多信息或判断。
>> Agent在执行过程中,需在每一步从环境中获取“真实情况”(如工具调用结果或代码执行情况)以评估进度。
>> Agent在检查点或遇到障碍时可以暂停,等待人工反馈。任务通常在完成后终止,但常见做法是设置停止条件(如最大迭代次数)以保持控制。
>> Agent可以处理复杂任务,其实施通常简单,主要是LLM在环境反馈的基础上循环使用工具。因此,设计工具集和文档时需要清晰、周到,至关重要。
>> Agent适用于开放式问题,难以预测所需步骤数量,无法硬编码固定路径的情况。
>> Agent的自主性意味着更高的成本和可能累积的错误,建议在沙盒环境中进行广泛测试,并设置适当的防护措施。
>> Agent在编码任务、使用计算机完成任务等场景中有用。
>> Agent中,构建块并非强制性的,开发者可以根据不同的用例进行组合和定制。成功的关键是衡量性能并在实施中进行迭代,只有在明显改善结果时才考虑应增加复杂性,即仅在更简单的解决方案不足时才增加复杂性。
Autonomous agent
High-level flow of a coding agent
附录
附录 1:实践中的智能体案例
本附录通过具体的应用案例,进一步说明了智能体的实用价值。介绍了智能体在客户支持和编码领域的两个应用案例,这两个案例都强调了智能体在需要对话和行动、有明确成功标准、能够进行反馈循环以及整合有意义的人工监督的任务中的价值。
应用场景 | 特点与优势 | 实施细节 | 成功衡量标准 |
客户支持(Customer support) | >> 结合聊天机器人界面和工具集成增强功能; | >> 使用基于使用量的定价模型,仅对成功解决的服务收费;展示了对代理有效性的信心。 >> 为需要对话和行动的任务增加价值,有明确的成功标准,启用反馈循环,并整合有意义的人类监督。 | >> 通过用户定义的解决方案清晰衡量成功。 |
编码代理(Coding agents) | >> 从代码补全发展到自主解决问题; | >> 代理现在能够仅基于pull request描述解决GitHub上的真实问题; | >> 通过自动化测试和人类审查确保解决方案的正确性和适用性。 |
附录 2:提示工程的工具设计
本附录强调了工具设计在智能体构建中的重要性,并提供了具体的建议。讨论了如何进行工具的提示工程,包括选择合适的工具格式、编写清晰的工具定义和文档,以及对工具进行充分测试。
要点分类 | 建议 |
工具的重要性 | 工具对于代理系统至关重要,它使Claude能够通过在我们的API中指定其准确结构和定义来与外部服务和API交互。 >> 工具定义和规范应得到与整体提示同等的关注。 |
工具使用块 | 当代理响应时,如果LLM计划调用工具,则会在API响应中包含一个工具使用块。 |
指定动作的方式 | 动作可以通过多种方式指定,例如通过编写差异(diff)或重写整个文件来指定文件编辑。 >> 结构化输出可以放在markdown或JSON中。 |
格式选择建议 | 选择对模型友好、易处理的格式,减少不必要的复杂性。 >> 给模型足够的token使其在陷入困境之前能够“思考”。 >> 避免格式上的“额外开销负担”,如需要精确计数大量代码行或转义字符串中的代码。 |
创建良好代理-计算机接口(ACI)的建议 | 投入与人机界面(HCI)设计相同的努力来创建好的ACI。 >> 设身处地为模型考虑:工具的使用是否直观? >> 提供示例用法、边缘案例、输入格式需求及与其他工具的清晰界限。 >> 改变参数名称或描述以提高透明度,使事情更加明显。 >> 测试模型如何使用工具,并在工作台中运行许多示例输入以查看模型犯的错误,并进行迭代。 >> Poka-yoke你的工具,即改变参数以减少错误发生的可能性。修改工具参数,使得犯错更加困难。 |
实际应用案例 | 在构建SWE-bench代理时,我们实际上花了更多的时间优化工具而不是整体提示。例如,我们发现模型在使用相对文件路径的工具时会出错,因此我们更改工具始终要求使用绝对文件路径,解决了代理移出根目录后相对文件路径的错误问题。 |