💡 Agent可以理解为某种能自主理解、规划决策、执行复杂任务的智能体。Agent 是让 LLM 具备目标实现的能力，并通过自我激励循环来实现这个目标。它可以是并行的（同时使用多个提示，试图解决同一个目标）和单向的（无需人类参与对话）。
Agent = LLM+Planning+Feedback+Tool use
决策流程：感知（Perception）→ 规划（Planning）→ 行动（Action）
Agent创建一个目标或主任务后，主要分为以下三个步骤：
- 获取第一个未完成的任务
- 收集中间结果并储存到向量数据库中
- 创建新的任务，并重新设置任务列表的优先级
AI Agent主流框架
1. 微软的Jarvis
step1: 规划：利用好LLM 的推理规划能力，对用户输入进行任务拆解；
step2: 决策：利用LLM的决策能力，判断每个拆解的子任务，我们可以用什么方案解决
step3: 行动：通过决策得出的推荐工具（API，model，插件）去解决每个问题
step4: 总结输出最终解决方案和结果给用户
缺点：需要频繁调用LLM，token数量巨大带来高昂成本
2 微软的promptFlow
step1: 任务拆分，可以是人工拆分，也可以是LLM拆分，自定义~
反正从输入到输出就是一个任务流。我们只需要定义好每个步骤的输入和输出是什么。
step2: 每个task使用LLM去决策如何执行，也可以人工实现逻辑，也可以使用成熟插件，自定义~
step3：总结输出给用户
整个思路就是每个步骤都可控，输入，输出以及f(x)是什么都是我自己定义，我们通过评估使用LLM或者按传统思路实现逻辑，都很灵活。最好这个任务流可以可视化，方便我们理清思路。
3. Langchain
Langchain也是AI Agenthttps://github.com/langchain-ai/langchain。langchain开发的初衷是让开发者能够快速的构建一个LLM原型应用。Langchain主要组件有：
Models:模型，各个类型的LLM模型集成，比如GPT-4
Prompts:提示，在提示词中引入变量以适应用户输入，包括提示模版管理，优化和序列化。
Memory:记忆，用来保存模型交互的上下文
Indexes：索引，用来结构化文档，外挂知识库就是索引的一个功能应用
Chains:链， 对模型的一系列组件工具的链式调用，以上一个输出为下一个输入的一部分。
Agents: 代理，决定模型采取哪些行动，应该选哪个工具，执行并观察流程
Multi-Agent：多个Agent共享一部分记忆，自主分工相互协作。
对于Langchain我们用的最多的就是利用他进行外挂知识库，但是这其实知识Indexes这个组件的应用，Langchain的功能远不止此；其中Chains的思路其实就是promptFlow；Agents里面的AgentAction就是Jarvis的思路。
缺点：Langchain才是功能和工具最齐全的框架，但是Langchain功能太多，导致整个框架太重，极其不灵活；大家通常只用他的一个组件功能
相关案例
斯坦福的虚拟小镇
代码已开源：https://github.com/joonspk-research/generative_agents
一个agent就是一个虚拟人物，25个agents之间的故事
架构
记忆（Memory）
短期记忆：在上下文中（prompt）学习。它是短暂有限的，因为它受到Transformer的上下文窗口长度的限制。
长期记忆：代理在查询时可以注意到的外部向量存储，可以通过快速检索访问。
反思（Reflection）
反思是由代理生成的更高级别、更抽象的思考。因为反思也是一种记忆，所以在检索时，它们会与其他观察结果一起被包含在内。反思是周期性生成的；当代理感知到的最新事件的重要性评分之和超过一定阈值时，就会生成反思。
- 让代理确定要反思什么
- 生成的问题作为检索的查询
计划（Plan）
计划是为了做更长时间的规划。像反思一样，计划也被储存在记忆流中（第三种记忆），并被包含在检索过程中。这使得代理能够在决定如何行动时，同时考虑观察、反思和计划。如果需要，代理可能在中途改变他们的计划（即响应，reacting）。
Huggingface：Transformers Agents 发布
它在 Transformers 的基础上提供了一个自然语言 API，来 “让 Transformers 可以做任何事情”。
这其中有两个概念：一个是 Agent (代理)，另一个是 Tools (工具)，我们定义了一系列默认的工具，让代理去理解自然语言并使用这些工具。
- 代理：这里指的是大语言模型 (LLM)，你可以选择使用 OpenAI 的模型 (需要提供密钥)，或者开源的 StarCoder 和 OpenAssistant 的模型，我们会提示让代理去访问一组特定的工具。
- 工具：指的是一个个单一的功能，我们定义了一系列工具，然后使用这些工具的描述来提示代理，并展示它将如何利用工具来执行查询中请求的内容。
目前在 transformers 中集成的工具 包括：文档问答、文本问答、图片配文、图片问答、图像分割、语音转文本、文本转语音、零样本文本分类、文本摘要、翻译等。
总结
观点1：Agent特点
- Agent本身是类似于DM的升级版，能够充分利用对环境的感知，进行决策规划，充分调用LLM的能力。
- 私有化部署时，集成到企业工作流中，面临的边际成本很难降低，且没有通用性。
- Agent需要调用外部工具，调用工具最好的方式就是输出类Makedown代码
由LLM大脑输出一种可执行的代码，像是一个语义分析器，由它理解每句话的含义，然后将其转换成一种机器指令，再去调用外部的工具来执行或生成答案。尽管现在的 Function Call 形式还有待改进，但是这种调用工具的方式是非常必要的，是解决幻觉问题的最彻底的手段。
观点2：Agent落地的瓶颈
Agent本身用到两部分能力，一部分是由LLM作为其“智商”或“大脑”的部分，另一部分是基于LLM，其外部需要有一个控制器，由它去完成各种Prompt，如通过检索增强Memory，从环境获得Feedback，怎样做Reflection等。
Agent既需要大脑，也要外部支撑
- LLM本身的问题：自身的“智商”不够，可进行LLM升级为GPT-5；Prompt的方式不对，问题要无歧义。
- 外部工具：系统化程度不够，需要调用外部的工具系统，这是一个长期待解决的问题。
通用AGI：现阶段Agent的落地，除了LLM本身足够通用之外，也需要实现一个通用的外部逻辑框架。不只是“智商”问题，还需要如何借助外部工具，从专用抵达通用——而这是更重要的问题。
解决特定场景的特定问题：将LLM作为一个通用大脑，通过Prompt设计为不同的角色，以完成专用的任务，而非普适性的应用。但是面临的关键问题，即Feedback将成为Agent落地实现的一大制约因素，对于复杂的Tools应用，成功概率会很低。
观点3：多模态在Agent的发展
多模态只能解决Agent感知上的问题，而无法解决认知的问题。
多模态是必然趋势，未来的大模型必然是多模态的大模型，未来的Agent也一定是多模态世界中的Agent。
观点4：Agent从专用到通用的实现路径
假设Agent最终将落地于100种不同的环境，在目前连最简单的外部应用都难以实现的前提下，最终能否抽象出一个框架模型来解决所有外部通用性问题？
先将某一场景下的Agent做到极致——足够稳定且鲁棒，再逐步将它变成通用框架，也许这是实现通用Agent的路径之一。。
