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代理时，我们实际上花了更多的时间优化工具而不是整体提示。例如，我们发现模型在使用相对文件路径的工具时会出错，因此我们更改工具始终要求使用绝对文件路径，解决了代理移出根目录后相对文件路径的错误问题。 |
扫一扫
304
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
