• 简介
• Agent不只是一个工具
• 规划与COT
• 猴版实现
  • ReAct
  • 无反馈的planner和solver
  • Basic Reflection
• 应用
• 其它

简介

比尔·盖茨：AI Agent将彻底改变人类生活方式尽管软件在过去几十年里取得了显著的进步，但是，从很多方面来看，它依然有些 “笨拙”。在计算机上完成任务时，你需要告诉设备使用哪个应用程序。例如，你可以用微软 Word 和谷歌文档撰写商业提案，但它们无法帮你发送邮件、分享自拍、分析数据、策划派对或购买电影票。即便是最优秀的网站，也只能片面地了解你的工作、个人生活、兴趣及人际关系，在利用这些信息来为你服务方面能力有限。但在未来五年内，这一切将彻底改变。你不再需要针对不同的任务使用不同的应用。你只需用日常语言告诉你的设备你想要做什么，软件将能够根据你愿意分享的信息量做出个性化的回应，因为它将深入理解你的生活。在不远的将来，任何联网的人都将能夠拥有一个由 AI 驱动的个人助理，其能力将远超现今的技术水平。这种能够理解自然语言并根据对用户的了解来完成多种任务的软件，被称为 “Agent”。PS：各个app 不再直面用户，而是通过接入Agent，由Agent来完成和用户之间的交互，Agent 将成为下一个平台。具象化一下，就是钢铁侠中的Javis。

企业AI智能体、数字化与行业分工现代企业是由人和机器组成的。

1. 人：负责完成复杂的、具有不确定性的任务。人是一种高度智能化的智能体。
2. 机器（蓝色方形节点）：负责完成简单的、确定性的任务。包括软件、设备等，属于工具。 于是，在这两类节点之间，就产生了三种关系：
3. 人与人之间：沟通关系。为了完成企业的目标，企业内部的人和人之间需要通过沟通的方式来协作。可能是小团队内紧密的team work，也可能是跨团队之间的沟通，或者是上下级之间的沟通。
4. 人与机器之间：人机交互。人和机器之间需要通过产品界面来交互。
5. 机器与机器之间：API。机器与机器之间通过API调用来协作，它们之间沟通所使用的，属于机器语言。 人是智能体，机器是工具。AI智能体加入进来以后，它兼具智能体和工具两种属性：
6. 半智能体：可以提供知识，且是海量的知识。
7. 半工具：可以自动化调用真正的工具。甚至，现在以大模型为基础的AI智能体，还能将一定程度的规划工作也自动化掉。 Agentic可以理解为“具有智能体特性”。一个系统越“具有智能体特性”，就意味着LLM在决定系统行为方面的作用越大。AI智能体可能扮演三种角色：
8. AI-0：直接参与业务流程自动化。作为自动化流程中的一个节点，完成以前只能由人完成的工作。需要与企业数据对接。场景举例：从文档中批量抽取信息；文档批量翻译；批量的数据挖掘、预测等。LLM的作用仅仅是提供信息或执行简单的指令。
9. AI-1：作为提供知识的Copilot。不直接面向企业的业绩目标，作为人的辅助。需要与人频繁交互，通常以Chat的形式。不需要与企业数据对接。场景：知识问答、总结、文段翻译、数据可视化分析、公开文献阅读、写报告、画图表、写代码，以及其它的各种创作性任务，等等。ChatGPT承担的主要就是这种角色。
10. AI-2：作为新型的人机交互接口。提供更自然的交互界面，主要也是Chat的形式。需要与企业数据对接。这一角色承担的任务可大可小。可以是简单的企业私有文档问答，用于替代传统的文档检索；也可以具备非常复杂的逻辑，成为企业大脑，驱动人机协作更有效率。场景：企业私域问答；用自然语言执行命令，查询企业内部数据，驱动自动化流程编排，等等。
11. AI-2xx：完全Agentic的系统。 这些系统的行为完全由LLM决定，甚至可以自己设定目标和计划。 理想的AI智能体产品形态，应该是AI-1和AI-2相结合的。用户既能从AI智能体获取企业外部的海量知识和专业数据，又能通过它与背后的企业内部数据或软件工具交互，让更多的工作由AI来完成。

下一代智能体发展的三大关键领域：规划、用户体验和记忆。

1. 规划是指 AI 智能体能够预先考虑多个步骤，并确定最佳行动方案的能力。目前，语言模型的规划能力还比较有限，主要依靠以下两种方法来加强：
   1. 外部提示策略：开发者通过设计特定的提示，引导语言模型进行规划。例如，可以要求模型在执行每个步骤之前，先列出所有可能的步骤并进行评估。
   2. 流程工程：通过设计预定义的流程图或状态机，将任务分解成多个步骤，并明确每个步骤的执行条件和顺序。这可以帮助语言模型更好地理解任务，并做出更合理的规划。 未来，随着语言模型能力的提升，它们或许能够自主进行更有效的规划，而不再需要外部提示或流程工程的辅助。
2. 目前，AI 智能体的用户体验仍有许多需要改进的地方，例如：
   1. 可靠性不足：由于语言模型的局限性，AI 智能体有时会犯错或无法理解用户的指令。这可能会导致用户感到沮丧和困惑。
   2. 可控性不足：用户往往无法完全控制 AI 智能体的行为，这可能会导致一些意外的后果。
   3. 缺乏个性化：现有的 AI 智能体大多缺乏个性化，无法根据用户的特定需求和偏好进行调整。
3. 记忆是指 AI 智能体存储和使用信息的能力。记忆对于 AI 智能体完成各种任务都至关重要，例如：
   1. 程序记忆：记忆如何正确地执行任务，例如如何预订机票或如何撰写电子邮件。
   2. 个性化记忆：记忆与特定用户相关的信息，例如用户的姓名、喜好、经历等。 目前，AI 智能体的记忆功能还比较简单，主要依靠以下两种方式实现：存储在数据库中：将信息存储在外部数据库中，并在需要时进行检索。嵌入语言模型中：将信息嵌入语言模型的参数中，使模型能够在生成文本时使用这些信息。

Agent不只是一个工具

万字长文：第一性原理看大模型Agent 未读完

1. 一开始大家玩 Prompt 工程（把大模型当做工具来调用，工具模式），接着是Prompt Chain或Flow，再到Agent，多Agent，很清晰的一个脉络架构。
2. 我们回到 Agent 这个概念上，实际上，人类是这个星球上最强大的 Agent。Agent是一个能感知并自主地采取行动的实体，这里的自主性极其关键，Agent要能够实现设定的目标，其中包括具备学习和获取知识的能力以提高自身性能。Agent 的复杂程度各不相同，一个简单的恒温器可以是一个 Agent，一个大型的国家或者一个生物群体也可能是个 Agent。感知环境、自主决策、具备行动能力，设定明确的目标和任务，适应环境及学习能力，都是 Agent 的关键特点。
3. 我们认为Agent技术是未来实现社会全面自动化的关键技术。在大模型出现之前，自动化更多的是一些偏结构化固定模式环境中通过实现固定算法流程来完成自动化任务，而大模型智能体的通用性带来了灵活性，使其可能应对人类在脑力劳动中面临的各种复杂长尾任务，进一步实现体力和脑力任务的全面自动化。PS：LLM本质是文字接龙，看你让大模型接什么，如果使用大模型接出来的东西。有点一生二、二生三、三生万物的意思，就好像无论汽油机、还是电动机，基本的动力输出形式是转圈圈，但是经过一些机械传导，可以转为各种机械运动形式：水平、垂直（打夯机）、椭圆运动等等，简单机械运动组合起来可以进行复杂机械运动比如纺织机，进而推动了大部分手工劳动的自动化。
4. 在通用人工智能（AGI）的漫长旅途中，大模型虽显强大，仍存在着显著的技术天花板。许多人开始探索如何挖掘大模型在大任务执行能力上的可能性，其中一个基本策略就是能够分解和组合。例如，经典的 MapReduce 模式可以将一个大型文本进行摘要，因为它的上下文有限，一种解决办法是扩大 context 的范围。另一个解决方案是，在有限的 context 中，我们先将文本拆分成小片段，对每个片段进行摘要，然后再将其组合，从而得出结果。大家也发现大模型直接给出答案似乎并不靠谱，那么是否可以让它像人类一样，一步一步思考呢？毕竟，人类在解决问题时，也是逐渐构建解决方案，而并非立即给出答案。因此，开始出现了一系列的尝试解法，比如思维链、多思维链、思维树和思维图等。上述的讨论主要是任务分解和组合，他们尽管强大，却不能与外界进行互动，这就不得不讲到反馈机制了。反馈是整个控制论的基石，也是动物体从诞生之初就具备的基本能力。最经典的方法实际就是 ReACT，ReACT让大模型先进行思考，思考完再进行行动，然后根据行动的结果再进行观察，再进行思考，这样一步一步循环下去。这种行为模式基本上就是人类这样的智能体主要模式。
5. 众人熟知的认知飞轮，感知、认知、决策、行动，今天的人工智能代理更像是基于这个认知飞轮构建的。但是从本质上，人类智能远比这复杂。
6. 智能究竟是什么？人类对世界进行建模，把世界以实体、关系、属性描绘出来。然而，这也是我们认知的极限，我们只能理解一个对象化的世界，非对象化的世界我们无法理解。比如，当我们探索量子的时候，我们还常常用对事物进行对象化的方式去理解，但是发现我们的理解力有时候是有限的，因为量子世界的真相超出了人类认知能力的范围，我们智能使用低维空间的投影去推断它，就像我们无法在三维世界去想象十一维世界的样子。
7. 其实在大模型Agent技术出现之前，人们就已经意识到，试图集成各种深度学习模型以实现人工普遍智能（AGI）并不够，还需要更高层次的认知模型。Agent都必须对世界有准确的理解才能做出正确的决策。当模型不能正确运行时，决策就会出错；只有当世界模型构建的正确，才能选择正确的模型，进而做出正确的决策。
8. 今天计算机领域的工程实践中，人们更多采用的是面向过程架构，无论是接口、函数、UI界面，还是组件，又或者是一个应用程序，都是以接口的形式存在的。而这个接口实质上是一种被调用的子流程，借此过程的完成，我们希望执行结果符合我们的预期，但程序并不为结果负责。它解决的是过程和流程问题，系统内没有目标的概念。当然，也存在一些以目标导向为核心理念的的软件工程，例如声明式编程，它只需要你描述你想要什么，而无需关心执行的过程，像HTML和SQL便是其经典例子。在这样的架构下，程序能够自行寻找达成目标的方法。然而问题在于，这种面向目标的架构只能应用于垂直领域，而无法普遍应用到所有领域，只有在特定的领域内才能发挥作用，这就限制了它的应用范围。总的来说，尽管面向目标架构在计算机领域有一席之地，但由于其只能在特定领域发挥作用，而无法解决所有领域的问题，因此它的应用还是有所限制，更多出现在特定的DSL（领域特定语言）中，这种架构的确也发挥了巨大的作用。在软件工程的范式迁移中，我们发现面向过程架构与面向目标架构之间的重要区别点：随着人类的生产方式的变化，软件工程可能正逐步演化为智能体工程(Agent Engineering)；以前我们主导的生产方式是人类处于中心位，AI做辅助。而未来可能会变成以 AI 为中心，人类变为辅助。由此，整个产品形态和平台的构成可能会发生这样的转变。

智能体是一个利用LLM来决定应用程序控制流程的系统，智能体的基本概念是在没有人工定义工作流（Workflow）的情况下，利用外部工具或功能，选择要执行的一系列操作，在没有人类控制的情况下独立运行（自主性，无需持续的人工干预或输入）。对于 toB 产品，智能体能够解决功能点繁多、使用链路冗长、使用方法复杂难上手等问题。从技术角度来看，智能体通过大模型理解用户意图并生成结构化描述，进而执行相关操作。因此，智能体在实际应用中扮演着至关重要的角色，成为了连接大模型和现有应用的桥梁。

Agent和过去程序代码不一样的地方就是它或多或少是有一些智能的，和过去一个函数或者应用写好之后就处于不可改动的情况不同。也就是意味着，利用Agent或者Multi-Agent实现的应用程序是有可能实现进化的。传统的应用程序不过是为Agent提供了一个基本的”环境”，Agent可以通过与人(“用户”)的交互以及环境的互动过程中，通过数据和反馈来感知外部，并且不断生成代码和使用工具来优化应用。例如，过去人们购买的应用软件都需要等待厂家的升级来进行版本的改动和调整，但是基于Agent的应用程序就有可能通过自然语言来构筑新的功能，而无需等待版本的更新。也就是说，应用应该是”成长”出来。如果将来LLM能够收集数据来更新自己，那么人类就真的变成了超级智能的引导程序。

Agent 有两个关键特性

1. 非确定性行为序列。利用LLM 作为推理引擎，通过LLM 来决定如何与外部世界进行交互，这意味着代理的行为不是预设的序列（硬编码是预置流程），而是根据用户输入和先前动作的结果动态决定的。这种灵活性使得代理能够应对多变的环境和复杂的任务。
2. 工具的使用。人类和动物的最大区别是会制造和使用工具。Agent 不仅拥有大量工具，而且在不同环境和不同任务场景下，会自主选择和使用工具。

规划与COT

“大模型视角”下的文本与我们“人类视角”并不一样。以Strawberry为例，其被拆分为【“str”, “aw”, “berry”】，自然也就不难理解为什么llm对于这个问题的回答是“两个r”了，毕竟对于它来说，这三者均是作为一个整体存在的，而不是从字母维度切分的。通过CoT方法编写Prompt后，可以引导大模型输出正确结果。

Strawberry里有几个r？请你先将单词拆分成一个个字母，再用0和1分别标记字母列表中非r和r的位置，数一下一共有几个r

为什么这么做可以提升大模型的表现呢？，大模型每一次生成是在“根据上文预测下一个Token”的话，那么CoT的作用便在于，它可以引导大模型先行生成有力的推理过程，比如引导其生成Strawberry拆解后的字母列表，或者数字的逐位比较，这样模型在生成最终结论的时候，会受到上文推理过程的影响，将下一个Token的概率分布限定在某个范围内，从而大大增加输出正确答案的概率。而若是不用CoT加以限制的的情况下，大模型倾向于先给出一个答案，再给出理由，那么很自然地变成了，先根据“问题”预测一个最有可能的“答案”，再为这个“答案”编造相应的“理由”，毕竟大模型的生成过程是逐步进行的，而不是全局性的，它在答案之后输出的理由永远只可能是为了圆“答案”这个谎而存在的。我们人类在思考的时候，通常也是会先有推理过程，再有结论，只不过在诉诸于语言时，可能会选择 先抛出结论表明立场，再给出解释 的表达方式，而思考过程对外界是不可见的，但是对于大模型而言，它的语言本身即是思考，并不存在诉诸于语言之前的思考过程，所以我们也需要引导它像人类一样先思考再判断，将思考过程以语言的方式表达出来。换句话说，“理由先行”的输出风格或许有助于大模型给出更加可靠的答案。

从 CoT 到 Agent，最全综述来了

1. 什么是“语言智能”？语言智能可以被理解为“使用基于自然语言的概念对经验事物进行‘理解’以及在概念之间进行‘推理’的能力”，随着参数量的飞升，以 Transformer 为基础架构的大规模语言模型以 “Chat” 的方式逐渐向人们展现出了它的概念理解与概念推理的能力。直观上，作为“语言模型”的大模型具备概念理解能力并不难理解，但是仅仅像 Word2vec 一样只能得到“国王”与“男人”的“距离”更近的结论对于语言智能而言必然远远不够。真正引发人们对大模型逼近“语言智能”无限遐想的，在于大模型展现出的概念推理能力。推理，一般指根据几个已知的前提推导得出新的结论的过程，区别于理解，推理一般是一个“多步骤”的过程，推理的过程可以形成非常必要的“中间概念”，这些中间概念将辅助复杂问题的求解。
2. 2022 年，在 Google 发布的论文《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》中首次提出，通过让大模型逐步参与将一个复杂问题分解为一步一步的子问题并依次进行求解的过程可以显著提升大模型的性能。而这一系列推理的中间步骤就被称为思维链（Chain of Thought）。区别于传统的 Prompt 从输入直接到输出的映射 <input——>output> 的方式，CoT 完成了从输入到思维链再到输出的映射，即 <input——>reasoning chain——>output>。如果将使用 CoT 的 Prompt 进行分解，可以更加详细的观察到 CoT 的工作流程。
   1. 虽然与传统的直进直出的Prompt相比，COT能让模型带来更多的思考（其实只是更多tokens自回归带来的准确性提升）。但是它很多时候的结果产出与我们人类的预期还是会有偏差，抽奖不可避免。
3. 在许多 Agent 需要处理的任务中，Agent 的“先天知识”并不包含解决任务的直接答案，因此 Agent 需要在一系列与外部环境的交互循环中，制定计划，做出决策，执行行动，收到反馈……在一整个计划、决策与控制的循环中，大模型需要具备“感知”，“记忆”与“推理”的能力。无论是环境的反馈，还是人类的指令，Agent 都需要完成一个对接收到的信息进行“理解”，并依据得到的理解进行意图识别，转化为下一步任务的过程。而使用 CoT 可以大大帮助模型对现有输入进行“感知”，譬如，通过使用“Answer: Let’s think step by step. I see $$, I need to …”的 Prompt，可以让模型逐步关注接收到的信息，对信息进行更好的理解。

ReACT框架的一个关键特点是其任务拆解模块，能够将复杂的任务拆解成一系列更小、更明确的子任务，这些子任务更容易被模型理解和执行，让模型不再“消化不良”。一篇大模型Agent工具使用全面研究综述任务规划的方法：

1. 无需调整的方法（Tuning-free Methods）：利用LLMs的内在能力，通过少量示例或零示例提示来实现任务规划。例如，使用CoT（Chain of Thought）或ReACT等框架来引导LLMs逐步思考和规划。
2. 基于调整的方法（Tuning-based Methods）：通过在特定任务上微调LLMs来提高任务规划能力。例如，Toolformer等方法通过微调来增强LLMs对工具使用的意识和能力。

工具选择的分类：

1. 基于检索器的工具选择（Retriever-based Tool Selection）：当工具库庞大时，使用检索器（如TF-IDF、BM25等）来从大量工具中检索出与子问题最相关的前K个工具。这种方法侧重于通过关键词匹配和语义相似性来快速缩小工具选择范围。
2. 基于LLM的工具选择（LLM-based Tool Selection）：当工具数量有限或者在检索阶段已经缩小了工具范围时，可以直接将工具描述和参数列表与用户查询一起提供给LLM。

工具学习范式：

1. 没有反馈的计划制定。一步任务解决，这种范式涉及到在收到用户问题后，LLMs立即分析用户请求，理解用户意图，并规划出所有需要的子任务来解决问题。在这个过程中，LLMs会直接生成一个基于选定工具返回结果的响应，而不会考虑过程中可能出现的错误或根据工具的反馈调整计划。
   1. 单路推理，仅一次大语言模型调用就输出完整的推理步骤；
   2. 多路推理，借鉴众包思想，让大语言模型生成多个推理路径，进而确定最佳路径；
   3. 借用外部的规划器。Agent Planning大揭秘：外部规划器怎么玩？
2. 有反馈的计划制定。这种范式允许LLMs与工具进行迭代交互，不预先承诺一个完整的任务计划。相反，它允许基于工具的反馈逐步调整子任务，使LLMs能够一步步地解决问题，并根据工具返回的结果不断完善计划。这种方法增强了LLMs的问题解决能力，因为它允许模型在响应工具反馈时进行适应和学习。反馈的提供者来自三个方面:环境反馈、人类反馈和模型反馈。

ReAct模式最早出现的Agent设计模式，目前也是应用最广泛的。从ReAct出发，有两条发展路线：

1. 一条更偏重Agent的规划能力，包括REWOO、Plan & Execute、LLM Compiler。在重规划的模式下，ReAct模式加上规划器就成为REWOO，再加上重规划器就成为Plan & Execute，再叠加计划并行执行能力就成为LLM Compiler。
2. 一条更偏重反思能力，包括Basic Reflection、Reflexion、Self Discover、LATS。在重反思模式下，ReAct模式加上左右互搏框架就成为Basic Reflecion，边推理边执行则演变为Self-Discover，加入强化学习则演变为Reflexion，最后的LATS是推理和规划的集大成者，LATS = Tree search + ReAct + Plan&Execute + Reflexion。

从最初的ReAct模式出发，加入规划能力即演变成REWOO；再加上Replan能力即演变成Plan-and-Execute；最后再加上DAG和并行处理能力，即演变成LLM Compiler。

1. ReAct模式是最早出现、也是目前使用最广泛的模式。核心思想就是模拟人思考和行动的过程，通过Thought、Action、Observation的循环，一步步解决目标问题。ReAct模式也存在很多的不足：
   1. 首先是LLM大模型的通病，即产出内容不稳定，不仅仅是输出内容存在波动，也体现在对复杂问题的分析，解决上存在一定的波动
   2. 然后是成本，在任务提交给LLM后，LLM对任务的拆解、循环次数是不可控的。因此存在一种可能性，过于复杂的任务导致Token过量消耗。
   3. 最后是响应时间，LLM响应时间是秒级以上。因为无法确定需要拆分多少步骤，需要访问多少次LLM模型。
2. REWOO的全称是Reason without Observation，是相对ReAct中的Observation 来说的。通过生成一次性使用的完整工具链来减少token消耗和执行时间。简化微调过程。由于规划数据不依赖于工具的输出，因此可以在不实际调用工具的情况下对模型进行微调。包括三个部分：Planner；Worker；Solver。缺陷在于，非常依赖于Planner的规划能力，如果规划有误，则后续所有的执行都会出现错误。尤其是对于复杂任务，很难在初始阶段就制定合理且完备的计划清单。AI大模型实战篇：AI Agent设计模式 - REWOO
3. Plan-and-Execute。先计划再执行，即先把用户的问题分解成一个个的子任务，然后再执行各个子任务，并根据执行情况调整计划。相比ReWOO，最大的不同就是加入了Replan机制，其架构上包含规划器、执行器和重规划器。Plan-and-Execute和ReAct也有一定的相似度，但是Plan-and-Execute的优点是具备明确的长期规划。局限性在于，每个任务是按顺序执行的，下一个任务都必须等上一个任务完成之后才能执行，这可能会导致总执行时间的增加。AI大模型实战篇：AI Agent设计模式 - Plan & Execute
4. LLM Compiler，训练大语言模型生成一个有向无环图，DAG可以明确各步骤任务之间的依赖关系，从而并行执行任务，实现类似处理器“乱序执行”的效果，可以大幅加速AI Agent完成任务的速度。主要有以下组件：Planner（输出流式传输任务的DAG）Task Fetching Unit（调度并执行任务）Joiner（由LLM根据整个历史记录（包括任务执行结果），决定是否响应最终答案或是否将进度重新传递回Planner） AI大模型实战篇：AI Agent设计模式 - LLM Compiler，Agent的并行处理器

规划和反思

1. Basic Reflection，类比于左右互博。左手是Generator，负责根据用户指令生成结果；右手是Reflector，来审查Generator的生成结果并给出建议。在左右互搏的情况下，Generator生成的结果越来越好，Reflector的检查越来越严格，输出的结果也越来越有效。非常适合于进行相对比较发散的内容生成类工作，比如文章写作、图片生成、代码生成等等。也面临着一些缺陷：对于一些比较复杂的问题，显然需要Generator具备更强大的推理能力；Generator生成的结果可能会过于发散，和我们要求的结果相去甚远；在一些复杂场景下，Generator和Reflector之间的循环次数不太好定义，如果次数太少，生成效果不够理想；如果次数太多，对token的消耗会很大。AI大模型实战篇：Basic Reflection，AI Agent的左右互搏之术
2. Self-Discover框架包含两个主要阶段，自发现特定任务的推理结构、应用推理结构解决问题。AI大模型实战篇：Self Discover框架，万万想不到Agent还能这样推理
   1. 阶段一：自发现特定任务的推理结构，主要包含三个主要动作：选择（SELECT）、适应（ADAPT）和实施（IMPLEMENT）。在这个阶段，模型从一组原子推理模块（例如“批判性思维”和“逐步思考”）中选择对于解决特定任务有用的模块。模型通过一个元提示来引导选择过程，这个元提示结合了任务示例和原子模块描述。选择过程的目标是确定哪些推理模块对于解决任务是有助的。一旦选定了相关的推理模块，下一步是调整这些模块的描述使其更适合当前任务。这个过程将一般性的推理模块描述，转化为更具体的任务相关描述。例如对于算术问题，“分解问题”的模块可能被调整为“按顺序计算每个算术操作”。同样，这个过程使用元提示和模型来生成适应任务的推理模块描述。在适应了推理模块之后，Self-Discover框架将这些适应后的推理模块描述转化为一个结构化的可执行计划。这个计划以键值对的形式呈现，类似于JSON，以便于模型理解和执行。这个过程不仅包括元提示，还包括一个人类编写的推理结构示例，帮助模型更好地将自然语言转化为结构化的推理计划。
   2. 阶段二：应用推理结构，完成阶段一之后，模型将拥有一个专门为当前任务定制的推理结构。在解决问题的实例时，模型只需遵循这个结构，逐步填充JSON中的值，直到得出最终答案。
3. Reflexion本质上是强化学习，可以理解为是Basic reflection 的升级版。Reflexion机制下，整个架构包括Responder和Revisor，和Basic Reflection机制中的Generator和Reflector有点类似。但不同之处在于， Responder自带批判式思考的陈述，Revisor会以 Responder 中的批判式思考作为上下文参考对初始回答做修改。此外，Revisor还引入了外部数据来评估回答是否准确，这使得反思的内容更加具备可靠性。AI大模型实战篇：Reflexion，通过强化学习提升模型推理能力
4. LATS，全称是Language Agent Tree Search，LATS = Tree search + ReAct + Plan&Execute + Reflexion。融合了Tree Search、ReAct、Plan & Execute、Reflexion的能力于一身之后，LATS成为AI Agent设计模式中，集反思模式和规划模式的大成者。

工具调用的步骤：

1. 参数提取：LLMs必须能够从用户查询中提取出符合工具描述中指定格式的参数。
2. 调用工具：使用提取的参数向工具服务器发送请求，并接收响应。

现有方案如CoT和基于分解的提示，都有擅长的任务类型，适合作为独立的原子模块，不具有普适性；大模型自动推理？谷歌等发布SELF-DISCOVER！

猴版实现

ReAct

class LLMSingleActionAgent {
  llm: AzureLLM
  tools: StructuredTool[]
  stop: string[]
  private _prompt: string = '{input}'
  constructor({ llm, tools = [], stop = [] }: LLMSingleActionAgentParams) {
    this.llm = llm
    this.tools = tools
    if (stop.length > 4)
      throw new Error('up to 4 stop sequences')
    this.stop = stop
  }
}
class AgentExecutor {
  agent: LLMSingleActionAgent
  tools: StructuredTool[] = []
  maxIterations: number = 15
  constructor(agent: LLMSingleActionAgent) {
    this.agent = agent
  }
  addTool(tools: StructuredTool | StructuredTool[]) {
    const _tools = Array.isArray(tools) ? tools : [tools]
    this.tools.push(..._tools)
  }
  async call(input: promptInputs): Promise<AgentFinish> {
    ...
  }
}

无反馈的planner和solver

planner的prompt模版

You are an AI agent who makes step-by-step plans to solve a problem under the help of external tools.
For each step, make one plan followed by one tool-call, which will be executed later to retrieve evidence for that step.
You should store each evidence into a distinct variable #E1, #E2, #E3 ... that can be referred to in later tool-call inputs.

##Available Tools##
{tool_description}

##Output Format (Replace '<...>')##
#Plan1: <describe your plan here>
#E1: <toolname>[<input here>] (eg. Search[What is Python])
#Plan2: <describe next plan>
#E2: <toolname>[<input here, you can use #E1 to represent its expected output>]
And so on...

##Your Task##
{task}

##Now Begin##
"""

solver的prompt模版

You are an AI agent who solves a problem with my assistance. I will provide step-by-step plans(#Plan) and evidences(#E) that could be helpful.
Your task is to briefly summarize each step, then make a short final conclusion for your task. Give answer in {lang}.

##My Plans and Evidences##
{plan_evidence}

##Example Output##
First, I <did something> , and I think <...>; Second, I <...>, and I think <...>; ....
So, <your conclusion>.

##Your Task##
{task}

##Now Begin##

Basic Reflection

构建Generator

from langchain_core.messages import AIMessage, BaseMessage, HumanMessage
from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder
from langchain_fireworks import ChatFireworks

prompt = ChatPromptTemplate.from_messages(
    [
        (
            "system",
            "You are an essay assistant tasked with writing excellent 5-paragraph essays."
            " Generate the best essay possible for the user's request."
            " If the user provides critique, respond with a revised version of your previous attempts.",
        ),
        MessagesPlaceholder(variable_name="messages"),
    ]
)
llm = xx
generate = prompt | llm
essay = ""
request = HumanMessage(
    content="Write an essay on why the little prince is relevant in modern childhood"
)

构建Reflector

reflection_prompt = ChatPromptTemplate.from_messages(
    [
        (
            "system",
            "You are a teacher grading an essay submission. Generate critique and recommendations for the user's submission."
            " Provide detailed recommendations, including requests for length, depth, style, etc.",
        ),
        MessagesPlaceholder(variable_name="messages"),
    ]
)
reflect = reflection_prompt | llm

第三步 循环执行

for chunk in generate.stream(
    {"messages": [request, AIMessage(content=essay), HumanMessage(content=reflection)]}
):
    print(chunk.content, end="")

第四步 构建流程图（用langgraph）

应用

大佬：这一波Agent热潮爆发，其实是LLM热情的余波，大家太希望挖掘LLM潜力，为此希望LLM担任各方面的判断。但实际上有一些简单模块是不需要LLM的，不经济也不高效。例如我们要抽取每轮对话的情绪，可以用LLM，其实也可以用情绪识别模型。例如我们希望将长对话压缩后作为事件记忆存储，可以用LLM，也可以用传统摘要模型，一切只看是否取得ROI的最佳平衡，而不全然指望LLM。

一文说清：大模型AI Agent在企业应用中的6种基础类型

1. 创作与生成类助手，简单的借助Prompt工程即可实现
2. 企业知识助手，本质上也是一种提示工程：借助于在大模型输入时携带相关的私有知识上下文，让大模型理解、总结、整理并回答用户问题。只是这里的私有知识上下文需要借助嵌入模型（Embedding Model）、向量数据库（Vector Store）、文档加载分割（Document Loader&Splitter）等相关技术来获得。
3. 数据分析助手，基本以三种方式为主：自然语言转API、转SQL、以及代码解释器（转代码）。DB-GPT、OpenAgents、OpenInterpreter
4. 应用/工具助手，能够把自然语言转换成对企业应用或者互联网开放API调用的一种基础Agent形式。比如：如果你需要AI帮你在协同办公系统中提交一个付款申请，那么你需要调用办公系统的接口；当然，在复杂任务场景下的这种调用往往不是单一的，复杂性主要体现在大模型对自然语言转API的能力：能否根据上下文理解，精确匹配到需要使用的API（一个或者多个）；能否准确地提取或生成每个API的调用参数。LangChain、Assistants API、OpenAgents。
5. Web操作助手，主要能力是自动化Web网络浏览、操作与探索的动作与过程，以简化web浏览访问与操作。对于个人来说，可以作为个人数字助理，简单对话即可让AI帮你完成Web浏览与操作，比如在线订票。而对于企业来说，则可以作为企业的数字员工，来简化企业日常工作中重复性较高、流程与规则固定、大批量的前端操作性事务。比如批量订单处理、批量客户联络、批量网站抓取等，提高效率，降低错误率。传统的RPA机器人也是用来完成此类工作的AI形式，由于这种AI机器人工作在软件的最上层即操作层面，好处是流程直观、简单、也可以配置化，且对应用无侵入性；但其缺点是与前端应用耦合性大，每个任务需要根据前端应用界面做精心配置与调试，自适应能力较差。在大模型出现以后，给这一类RPA智能也带来了新的优化空间。
6. 自定义流程助手，严格来说是上面的几种基础Agent能力的组合，理想中的AI Agent是在丢给他一个工具包与一些知识以后，借助于大模型的理解、推理能力，完全自主的规划与分解任务，设计任务步骤，并智能的使用各种工具，检索知识，输出内容，完成任务。但是在企业应用中，由于企业知识、应用、业务需求的千差万别，以及大模型自身的不确定性，如果这么做，那么结果很可能是“开盲盒”一样的不可控。所以这也是越来越多的Agents项目要强调可控性的原因，即能够对AI智能体的执行过程与细节进行更多的控制，来让AI按照人类确认过的工作流程来完成任务。 PS： 人规定流程 + 单个步骤代码化（有些场景代码无法实现 或 个性化成本太高） ==> 人规定流程 + 单个步骤智能化 ==> 自动分析流程 + 单个步骤智能化

从需求满足的角度来聊一聊：我们首先以“用户去某地旅游”为需求来解释LLM、RAG、Agent三者的能力边界以及需求满足度。

1. LLM：能够生成“无法考证可能正确”以及“不一定及时”的相关行程攻略，景点等信息。
2. RAG：能够检索一些时效性高、内容可靠的信息源的内容，并生成相关的行程信息。PS：看能召回什么内容了
3. Agent：能够基于用户的需求目标完成，通过使用各种工具和系统交互完成攻略制定，订票，制定行程日历等过程任务。PS：先去搜一些攻略，再去订酒店 ==> 从景色、经济、时间等各个角度做一些对比。

阿里云服务领域Agent智能体：从概念到落地的思考、设计与实践

1. 工具API尽可能的将场景端到端的进行了封装，做到每个场景的API都能“开箱即用”，比如“退款”的API可以支持实例ID、订单号等多种入参，“ECS无法连接”的API也支持实例ID、IP地址等多种入参，尽量避免出现客户提供一种入参的情况下还需调用另一种API去转换的情况，这样算法侧就可以减少多步调用的场景，从而优化耗时。
2. 根据用户Query的分布特点，在阿里云客服场景下，大部分客户的问题中缺失具体信息的较多，很多问题都是“ECS连不上”、“备案进度查询”这类简明的意图名称，因此很难一次性直接提取出必填的参数信息，所以绝大多数的场景都需要参数“反问”的能力，那么涉及到反问澄清，就需要具备多轮的Agent对话能力，也就在客户提供了相应信息的情况下，Agent还能够接得上之前的意图，并且继续完成调用的链路，除此之外，还需要增加不需要调用API的情况，以及无参数提取等情况，让大模型能够知道在什么场景下要调用什么API、调用的动作、参数的提取、API的执行情况等等。
3. 在训练完成后，我们也构建了一个服务领域的Agent benchmark评测集，用于对比不同模型的Agent能力情况，这个benchmark中有多个维度的评估，包括API选择准确率、动作执行（反问、直接调用、拒识等）准确率、入参抽取准确率、端到端成功率、生成文案的BLEU和Rouge-L等指标，最终需要经过各维度的权衡决策哪版本模型作为线上模型。

其它

基于大模型的Agent进行测试评估的3种方案

一句指令帮你操作手机，最新多模态手机助手Mobile-Agent来了！为了便于将文本描述的操作转化为屏幕上的操作，Mobile-Agent生成的操作必须在一个定义好的操作空间内。这个空间共有8个操作，分别是：打开App（App名字）；点击文本（文本内容）；点击图标（图标描述）；打字（文本内容）；上翻、下翻；返回上一页；退出App；停止。点击文本和点击图标设计了输入参数。

1. 在迭代开始之前，用户需要输入一个指令。我们根据指令生成整个流程的系统提示。在每次迭代开始时，Mobile-Agent会获取手机屏幕的截图，通过观察系统提示、操作历史和当前屏幕截图，输出下一步操作。如果Mobile-Agent输出的是结束，则停止迭代；否则，继续新的迭代。Mobile-Agent利用操作历史记录了解当前任务的进度，并根据系统提示对当前屏幕截图进行操作，从而实现迭代式自我规划流程。
2. 在迭代过程中，Mobile-Agent可能会遇到错误，导致无法完成指令。为了提高指令的成功率，我们引入了一种自我反思方法。这种方法将在两种情况下生效。第一种情况是生成了错误或无效的操作，导致进程卡住。当Mobile-Agent注意到某个操作后截图没有变化，或者截图显示了错误的页面时，它会尝试其他操作或修改当前操作的参数。第二种情况是忽略某些复杂指令的要求。当通过自我规划完成所有操作后，Mobile-Agent会分析操作、历史记录、当前截图和用户指令，以确定指令是否已完成。如果没有，它需要继续通过自我规划生成操作。

别指望 AI 一次生成，其实不论是文本生成，还是代码生成，都涉及到生成式 AI 的能力问题：

1. 用户无法提供所有上下文给模型。既然能提供，提供的成本往往过高（大于 AI 生成的时间）
2. 模型无法理解你提供的所有上下文。

Agently AI应用开发框架由浅入深的应用开发指导 - 应用开发者入门篇 在Agently框架的演进过程中，Agent实例是模型能力的放大器这个关键认知深切地影响了框架的设计思想。应该如何理解这个认知？回想一下，当你最初开始使用ChatGPT或者与其类似的聊天机器人（Chat Bot）产品的时候，你对于在聊天框中输入信息并获得返回结果的期待是什么？是不是除了获得对当前一次输入问题的直接回答之外，还期望这次返回结果能够结合之前的几句对话记录，甚至是更远的几天、几周前的对话记录进行回答？是不是还期望聊天机器人能够具备更加生动的形象，并且更了解你的喜好和个人情况，给出更具有针对性的回复？是不是还期望它的回复内容中，除了从模型自身的预训练知识储备中抽取和组织信息，也希望它能够更多地结合外界的信息进行回答？是不是甚至期待它除了给出一条回复之外，还能够真切地帮你写下一段笔记、记录一个提醒、定上一个闹钟？当然了，如果你已经看到了这个章节，你也一定明白，这些期待并不能够通过直接对模型发起一次请求而得到实现，在模型之上，似乎需要有一个结构体，通过一定的结构设计和运行逻辑，来完成这些期待，对于使用者而言，他们仍然可以将这个结构体视作一个加强版的模型，通过简单的输入交互向它发起请求（例如我们在第二部分提供的方法）。在Agently框架中，这样的结构体就是Agent实例。PS： 非常深刻的一个认知

在理解了Agently框架对Agent实例这个结构体的基础设计思想之后，接下来我们来进一步说明在代码编写和运行过程中，Agent实例到底进行了哪些工作？

demo_agent = agent_factory.create_agent()
result = (
    demo_agent
        # Agent Component 能力插件提供的交互指令
        .set_role("角色", "你是一个幼儿教师")
        .set_role(
            "回复规则",
            "你需要将晦涩难懂的专业知识理解之后转化成小孩子能听懂的故事讲给用户听，" +
            "注意，虽然是讲故事，但是要保证专业知识的准确真实"
        )
        .on_delta(lambda data: print(data, end=""))
        # 基础请求指令
        .instruct("如果搜索结果中包含较多内容，请尽可能将这些内容有条理系统地转化成多段故事")
        .input("天空为什么是蓝色的")
        # 请求启动指令
        .start()
)
print("\n[最终回复]: ", result)