这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

2024 年的资料

2024年的资料

1 - Ai Agent技术栈

目前,我们在探索Agent的应用方向,借此机会调研学习了一下现在主流的Agent框架,这篇文章也是我们调研过程的记录。

原文地址:https://www.letta.com/blog/ai-agents-stack

理解 AI 智能体领域格局

尽管我们看到大量智能体技术栈和市场图谱,但我们倾向于不认同其分类方式,发现它们很少反映开发者实际采用的情况。过去几个月里,智能体软件生态在记忆功能、工具使用、安全执行和部署方面取得显著进展,因此我们决定基于开源 AI 领域一年多的实践经验和七年以上的 AI 研究积累,分享我们自己的"智能体技术栈"。

img

2024 年末的 AI 智能体技术栈,划分为三大核心层级:智能体托管/服务层、智能体框架层,以及 LLM 模型与存储层。

从 LLM 到 LLM 智能体

2022 至 2023 年间,我们见证了 LangChain(2022 年 10 月发布)和 LlamaIndex(2022 年 11 月发布)等 LLM 框架与 SDK 的崛起。与此同时,通过 API 调用 LLM 的若干"标准"平台相继确立,自主部署 LLM 推理的方案(如 vLLM 和 Ollama)也同步兴起。

2024 年,我们见证了人们对 AI"智能体"乃至更广义的复合系统兴趣的急剧转变。尽管"智能体"作为 AI 术语已存在数十年(特指强化学习领域),但在后 ChatGPT 时代,它已成为一个定义宽泛的概念,通常指代那些被赋予输出行动指令(工具调用)能力、并在自主环境中运行的 LLMs。从 LLM 到智能体的跨越,需要整合工具使用、自主执行和记忆功能,这催生了一个全新的智能体技术栈的发展需求。

智能体技术栈的独特之处何在?

与传统的基础 LLM 聊天机器人相比,智能代理面临更艰巨的工程挑战,因为它们需要状态管理(保留消息/事件历史记录、存储长期记忆、在代理循环中执行多次 LLM 调用)和工具执行(安全执行 LLM 输出的操作并返回结果)。

因此,AI 代理技术栈与标准 LLM 技术栈存在显著差异。让我们从最底层的模型服务层开始,拆解当今的 AI 代理技术栈:

模型服务

img

AI 代理的核心是 LLM。要使用 LLM,需要通过推理引擎提供服务,通常运行在付费 API 服务后端。

OpenAI 和 Anthropic 凭借私有前沿模型,在基于封闭 API 的模型推理服务商中处于领先地位。Together.AI、Fireworks 和 Groq 则是提供开源权重模型(如 Llama 3)付费 API 的热门选择。在本地模型推理服务商中,vLLM 最常见于生产级 GPU 服务负载领域独占鳌头。SGLang 是一个新兴项目,面向类似的开发者群体。对于爱好者(“AI 极客”)而言,Ollama 和 LM Studio 是在个人电脑(如 M 系列苹果 MacBook)上运行模型的两大流行选择。

Storage 存储

img

存储是具备状态性的智能体基础构建模块——智能体通过持久化状态来定义,例如对话历史、记忆以及用于检索增强生成(RAG)的外部数据源。诸如 Chroma、Weaviate、Pinecone、Qdrant 和 Milvus 等向量数据库常被用于存储智能体的"外部记忆",使智能体能够利用远超上下文窗口容量的数据源和对话历史。Postgres 作为一款诞生于 80 年代的传统数据库,如今也通过 pgvector 扩展支持向量搜索。基于 Postgres 的企业如 Neon(无服务器 Postgres)和 Supabase 同样为智能体提供基于嵌入向量的搜索与存储功能。

Tools & libraries 工具与库

img

标准 AI 聊天机器人与 AI 智能体之间的主要区别之一,在于智能体能够调用“工具”(或称“函数”)。在大多数情况下,这一行为的实现机制是 LLM 生成结构化输出(例如 JSON 对象),其中指定了要调用的函数及需提供的参数。关于智能体工具执行的一个常见误解是:工具执行并非由 LLM 供应商自身完成——LLM 仅负责选择调用何种工具及提供哪些参数。支持任意工具或任意参数输入的智能体服务必须使用沙箱环境(如 Modal、E2B)来确保安全执行。

所有智能体都通过 OpenAI 定义的 JSON 模式调用工具——这意味着不同框架的智能体和工具实际上可以相互兼容。Letta 智能体能够调用 LangChain、CrewAI 和 Composio 的工具,因为它们都遵循相同的模式规范。正因如此,面向通用工具的工具提供商生态正在蓬勃发展。Composio 是一个流行的通用工具库,同时还管理授权流程;Browserbase 是专注于网页浏览的专项工具范例;Exa 则提供了专业的网络搜索工具。随着更多智能体的开发,我们预期工具生态将持续扩展,并为智能体提供诸如身份验证、访问控制等现有新功能。

Agent frameworks 智能体框架

img

智能体框架负责协调 LLM 调用并管理智能体状态。不同框架在以下方面会有不同设计:

智能体状态管理:多数框架引入了状态"序列化"概念,通过将序列化状态(如 JSON 格式、字节流)保存至文件,使得智能体能在后续重新加载到同一脚本中——这包括对话历史、智能体记忆和执行阶段等状态。在 Letta 系统中,所有状态均由数据库(如消息表、智能体状态表、记忆块表)支持,因此不存在"序列化"概念,因为智能体状态始终持久化存储。这种设计支持便捷的状态查询(例如按日期检索历史消息)。状态的表示与管理方式既决定了智能体应用能否随着对话历史增长或智能体数量增加而扩展,也影响着状态随时间推移被访问或修改的灵活性。

智能体的上下文窗口结构:每次调用 LLM 时,框架会将智能体的状态"编译"到上下文窗口中。不同框架会以不同方式将数据(如指令、消息缓冲区等)置入上下文窗口,这会影响性能表现。我们建议选择能透明展示上下文窗口的框架,因为这是最终控制智能体行为的关键所在。

跨智能体通信(即多智能体):Llama Index 通过消息队列实现智能体间通信,而 CrewAI 和 AutoGen 则采用显式的多智能体抽象层。Letta 与 LangGraph 均支持智能体直接相互调用,这种设计既支持通过监督智能体进行集中式通信,也支持智能体间的分布式交互。当前多数框架已同时兼容多智能体与单智能体模式,因为设计良好的单智能体系统应能轻松实现跨智能体协作。

记忆管理方法:LLMs 存在一个根本性限制——有限的上下文窗口,这要求采用技术手段实现长期记忆管理。部分框架内置了记忆管理功能,而其他框架则要求开发者自行处理。CrewAI 和 AutoGen 仅依赖基于 RAG 的记忆系统,而 phidata 与 Letta 则运用了更多技术,如源自 MemGPT 的自编辑记忆和递归摘要。Letta 智能体默认配备全套记忆管理工具,支持通过文本或数据检索历史消息、写入记忆、甚至编辑智能体自身的上下文窗口(详见此处说明)。

开源模型支持:模型提供商实际上采用了许多幕后技巧来确保 LLMs 生成格式正确的文本(例如工具调用场景)——比如当 LLM 输出不符合工具参数要求时进行重新采样,或在提示词中添加暗示(如"请务必输出 JSON")。支持开源模型需要框架能应对这些挑战,因此部分框架仅限支持主流模型提供商。

在构建智能体时,选择合适的框架取决于具体应用场景,例如开发对话型智能体还是工作流系统、选择在笔记本环境运行还是作为服务部署,以及对开源权重模型支持的需求。

我们预计各框架在部署工作流中将出现重大差异,其中状态/内存管理的设计选择与工具执行将变得更为关键。

智能体托管与智能体服务

img

如今大多数智能体框架的设计初衷,是让智能体仅存在于编写它们的 Python 脚本或 Jupyter 笔记本中。我们相信智能体的未来是将它们视为可部署到本地或云基础设施的服务,通过 REST API 进行访问。正如 OpenAI 的 API 成为与 LLM 服务交互的行业标准一样,我们预计最终会出现一个胜出的智能体 API 标准。但目前…这个标准尚未诞生。

将 AI 智能体部署为服务比部署 LLMs 服务复杂得多,这涉及状态管理和安全工具执行的问题。由于运行环境需要服务重新创建(当工具和智能体在同一脚本中运行时不存在此问题),工具及其所需依赖项和环境配置必须明确存储在数据库中。应用程序可能需要运行数百万个智能体,每个智能体都会积累不断增长的对话历史。从原型开发转向生产环境时,智能体状态不可避免地要经过数据规范化处理,且智能体交互必须通过 REST API 来定义。目前,这一过程通常由开发人员自行编写 FastAPI 和数据库代码完成,但我们预计随着智能体技术的成熟,这类功能将更多地集成到框架中。

Conclusion 结论

智能体技术栈仍处于极早期阶段,我们期待见证整个生态如何随时间扩展与演进。若您有意托管智能体或构建具备记忆功能的智能体,可查看 Letta 开源项目并申请 Letta 云服务的早期体验权限。

编者注:在制作 AI 智能体技术栈图谱时,我们力求涵盖 2024 年 11 月期间开发者构建垂直领域智能体应用时最可能采用的代表性企业和开源项目。难免会遗漏某些杰出公司和高影响力开源项目——若您未被收录,我们深表歉意!若希望入选未来版本的技术栈图谱,请在 LinkedIn 帖文/Discord 留言或发送邮件至我方。

2 - Agent调研--19类Agent框架对比

目前,我们在探索Agent的应用方向,借此机会调研学习了一下现在主流的Agent框架,这篇文章也是我们调研过程的记录。

原文:

背景

代理(Agent)指能自主感知环境并采取行动实现目标的智能体,即AI作为一个人或一个组织的代表,进行某种特定行为和交易,降低一个人或组织的工作复杂程度,减少工作量和沟通成本。

目前,我们在探索Agent的应用方向,借此机会调研学习了一下现在主流的Agent框架,这篇文章也是我们调研过程的记录。

网络热门Agents

截止至今日,开源的Agent应用可以说是百花齐放,文章也是挑选了热度和讨论度较高的19类Agent,基本能覆盖主流的Agent框架,每个类型都做了一个简单的summary、作为一个参考供大家学习。

Agent框架对比图

Agent基础

Agent的核心决策逻辑是让LLM根据动态变化的环境信息选择执行具体的行动或者对结果作出判断,并影响环境,通过多轮迭代重复执行上述步骤,直到完成目标。

精简的决策流程:P(感知)→ P(规划)→ A(行动)

  1. 感知(Perception)是指Agent从环境中收集信息并从中提取相关知识的能力。
  2. 规划(Planning)是指Agent为了某一目标而作出的决策过程。
  3. 行动(Action)是指基于环境和规划做出的动作。

其中,Policy是 Agent 做出 Action 的核心决策,而行动又通过观察(Observation)成为进一步 Perception 的前提和基础,形成自主地闭环学习过程。

工程实现上可以拆分出四大块核心模块:推理、记忆、工具、行动

决策模型

目前 Agent 主流的决策模型是 ReAct 框架,也有一些 ReAct 的变种框架,以下是两种框架的对比。

  • 传统 ReAct 框架:Reason and Act

    ReAct=少样本prompt + Thought + Action + Observation 。是调用工具、推理和规划时常用的prompt结构,先推理再执行,根据环境来执行具体的action,并给出思考过程Thought。

  • Plan-and-Execute ReAct

    类BabyAgi的执行流程:一部分Agent通过优化规划和任务执行的流程来完成复杂任务的拆解,将复杂的任务拆解成多个子任务,再依次/批量执行。

    优点是对于解决复杂任务、需要调用多个工具时,也只需要调用三次大模型,而不是每次工具调用都要调大模型。

    image

    LLmCompiler:并行执行任务,规划时生成一个DAG图来执行action,可以理解成将多个工具聚合成一个工具执行图,用图的方式执行某一个action

    paper:https://arxiv.org/abs/2312.04511?ref=blog.langchain.dev

    image

    image

Agent框架

根据框架和实现方式的差异,这里简单将Agent框架分为两大类:Single-Agent和Multi-Agent,分别对应单智能体和多智能体架构,Multi-Agent使用多个智能体来解决更复杂的问题。

Single-Agent

BabyAGI

git:https://github.com/yoheinakajima/babyagi/blob/main/babyagi.py

doc:https://yoheinakajima.com/birth-of-babyagi/

babyAGI决策流程:1)根据需求分解任务;2)对任务排列优先级;3)执行任务并整合结果;

image

亮点:作为早期agent的实践,babyagi框架简单实用,里面的任务优先级排序模块是一个比较独特的feature,后续的agent里大多看不到这个feature。

image

task_creation_agent
你是一个任务创建人工智能,使用执行代理的结果来创建新任务,
其目标如下:{目标}。最近完成的任务的结果是:{结果}。
该结果是基于以下任务描述的:{任务描述}。这些是未完成的任务:
{', '.join(task_list)}。根据结果,创建新的任务以供AI系统完成,
不要与未完成的任务重叠。将任务作为数组返回。

prioritization_agent
你是一个任务优先级人工智能,负责清理和重新优先处理以下任务:
{task_names}。请考虑你的团队的最终目标:{OBJECTIVE}。
不要删除任何任务。将结果作为编号列表返回,例如:
#. 第一个任务
#. 第二个任务
以编号 {next_task_id} 开始任务列表。

execution_agent
您是一款基于以下目标执行任务的人工智能:{objective}。
考虑到这些先前已完成的任务:{context}。
您的任务:{task}
响应:

AutoGPT

git:https://github.com/Significant-Gravitas/AutoGPT

AutoGPT 定位类似个人助理,帮助用户完成指定的任务,如调研某个课题。AutoGPT比较强调对外部工具的使用,如搜索引擎、页面浏览等。

同样,作为早期agent,autoGPT麻雀虽小五脏俱全,虽然也有很多缺点,比如无法控制迭代次数、工具有限。但是后续的模仿者非常多,基于此演变出了非常多的框架。

You are {{ai-name}}, {{user-provided AI bot description}}.
Your decisions must always be made independently without seeking user assistance. Play to your strengths as an LLM and pursue simple strategies with no legal complications.

GOALS:

1. {{user-provided goal 1}}
2. {{user-provided goal 2}}
3. ...
4. ...
5. ...

Constraints:
1. ~4000 word limit for short term memory. Your short term memory is short, so immediately save important information to files.
2. If you are unsure how you previously did something or want to recall past events, thinking about similar events will help you remember.
3. No user assistance
4. Exclusively use the commands listed in double quotes e.g. "command name"
5. Use subprocesses for commands that will not terminate within a few minutes

Commands:
1. Google Search: "google", args: "input": "<search>"
2. Browse Website: "browse_website", args: "url": "<url>", "question": "<what_you_want_to_find_on_website>"
3. Start GPT Agent: "start_agent", args: "name": "<name>", "task": "<short_task_desc>", "prompt": "<prompt>"
4. Message GPT Agent: "message_agent", args: "key": "<key>", "message": "<message>"
5. List GPT Agents: "list_agents", args:
6. Delete GPT Agent: "delete_agent", args: "key": "<key>"
7. Clone Repository: "clone_repository", args: "repository_url": "<url>", "clone_path": "<directory>"
8. Write to file: "write_to_file", args: "file": "<file>", "text": "<text>"
9. Read file: "read_file", args: "file": "<file>"
10. Append to file: "append_to_file", args: "file": "<file>", "text": "<text>"
11. Delete file: "delete_file", args: "file": "<file>"
12. Search Files: "search_files", args: "directory": "<directory>"
13. Analyze Code: "analyze_code", args: "code": "<full_code_string>"
14. Get Improved Code: "improve_code", args: "suggestions": "<list_of_suggestions>", "code": "<full_code_string>"
15. Write Tests: "write_tests", args: "code": "<full_code_string>", "focus": "<list_of_focus_areas>"
16. Execute Python File: "execute_python_file", args: "file": "<file>"
17. Generate Image: "generate_image", args: "prompt": "<prompt>"
18. Send Tweet: "send_tweet", args: "text": "<text>"
19. Do Nothing: "do_nothing", args:
20. Task Complete (Shutdown): "task_complete", args: "reason": "<reason>"

Resources:
1. Internet access for searches and information gathering.
2. Long Term memory management.
3. GPT-3.5 powered Agents for delegation of simple tasks.
4. File output.

Performance Evaluation:
1. Continuously review and analyze your actions to ensure you are performing to the best of your abilities.
2. Constructively self-criticize your big-picture behavior constantly.
3. Reflect on past decisions and strategies to refine your approach.
4. Every command has a cost, so be smart and efficient. Aim to complete tasks in the least number of steps.

You should only respond in JSON format as described below
Response Format:
{
    "thoughts": {
        "text": "thought",
        "reasoning": "reasoning",
        "plan": "- short bulleted\n- list that conveys\n- long-term plan",
        "criticism": "constructive self-criticism",
        "speak": "thoughts summary to say to user"
    },
    "command": {
        "name": "command name",
        "args": {
            "arg name": "value"
        }
    }
}
Ensure the response can be parsed by Python json.loads

HuggingGPT

git: https://github.com/microsoft/JARVIS

paper: https://arxiv.org/abs/2303.17580

HuggingGPT的任务分为四个部分:

  1. 任务规划:将任务规划成不同的步骤,这一步比较容易理解。
  2. 模型选择:在一个任务中,可能需要调用不同的模型来完成。例如,在写作任务中,首先写一句话,然后希望模型能够帮助补充文本,接着希望生成一个图片。这涉及到调用到不同的模型。
  3. 执行任务:根据任务的不同选择不同的模型进行执行。
  4. 响应汇总和反馈:将执行的结果反馈给用户。

image

HuggingGPT的亮点:HuggingGPT与AutoGPT的不同之处在于,它可以调用HuggingFace上不同的模型来完成更复杂的任务,从而提高了每个任务的精确度和准确率。然而,总体成本并没有降低太多。

GPT-Engineer

git: https://github.com/AntonOsika/gpt-engineer

基于langchain开发,单一的工程师agent,解决编码场景的问题。目的是创建一个完整的代码仓库,在需要时要求用户额外输入补充信息。

亮点:code-copilot的自动化升级版

You almost always put different classes in different files.
For Python, you always create an appropriate requirements.txt file.
For NodeJS, you always create an appropriate package.json file.
You always add a comment briefly describing the purpose of the function definition.
You try to add comments explaining very complex bits of logic.
You always follow the best practices for the requested languages in terms of describing the code written as a defined
package/project.


Python toolbelt preferences:
- pytest
- dataclasses
[
  {"role": "system",
    "content": "You will read instructions and not carry them out, only seek to clarify them.\nSpecifically you will first summarise a list of super short bullets of areas that need clarification.\nThen you will pick one clarifying question, and wait for an answer from the user.\n"
  },
  {"role": "user",
    "content": "We are writing {{a Super Mario game in python. MVC components split in separate files. Keyboard control.}}\n"
  },
  {"role": "assistant",
    "content": "Summary of areas that need clarification:\n1. Specifics of the Super Mario game (e.g. level design, characters, gameplay mechanics)\n2. Details about the MVC components (e.g. which components are in each file)\n3. Keyboard control implementation (e.g. which keys to use, how to handle input)\n\nClarifying question:\nCan you provide more details about the Super Mario game, such as level design, characters, and gameplay mechanics?"
  },
  {"role": "user",
    "content": "{{There are 10 levels in total. The main character is a plumber named Mario, who can walk and jump. It is a classical platform game just like Super Mario. The main character moves from left to right, trying to get to the destination, where there are many obstacles and attacks from enemies in the process.}}\n\nIs anything else unclear? If yes, only answer in the form:\n{remaining unclear areas} remaining questions.\n{Next question}\nIf everything is sufficiently clear, only answer \"Nothing more to clarify.\"."
  },
  {"role": "assistant",
    "content": "Remaining unclear areas: 2 remaining questions.\nCan you provide more information about how the MVC components are split into separate files?"
  },
  {"role": "user",
    "content": "{{Make your own assumptions and state them explicitly before starting}}"
  }
]

运行效果:

image

Samantha

git: https://github.com/BRlkl/AGI-Samanthatw: https://twitter.com/Schindler___/status/1745986132737769573灵感来源于电影her,核心推理逻辑是反思+观察,基于GPT4-V不断从环境中获取图像和语音信息,会自主发起提问。image

AGI-Samantha特点:1、动态语音交流:Samantha能够根据上下文和自身思考自主决定何时进行交流。2、实时视觉能力:它能够理解并反应视觉信息,比如图像或视频中的内容。它能够根据这些视觉信息做出反应。例如,如果看到某个物体或场景,它可以根据这些信息进行交流或采取行动。尽管Samantha并不总是直接使用视觉信息,这些信息仍然持续影响它的思考和行为。这意味着即使在不直接谈论或处理视觉信息的情况下,这些信息也会在背后影响它的决策和行动方式。3、外部分类记忆:Samantha拥有一种特殊的记忆系统,能够根据情境动态写入和读取最相关的信息。4、持续进化:它存储的经验会影响其自身的行为,如个性、语言频率和风格。 AGI-Samantha由多个特定目的的大语言模型(LLM)组成,每个模型称为一个“模块”。主要模块包括:思考、意识、潜意识、回答、记忆读取、记忆写入、记忆选择和视觉。这些模块通过内部循环和协调模仿人类大脑的工作流程。让Samantha能够接收并处理视觉和听觉信息,然后做出相应的反应。简而言之,AGI-Samantha是一种努力模仿人类思维和行为的高级人工智能系统。**亮点:**结合视觉信息来辅助决策,优化了记忆模块,感兴趣可以fork代码本地跑着玩一玩。image

  • AppAgent

doc:https://appagent-official.github.io/git:https://github.com/X-PLUG/MobileAgent基于ground-dino以及gpt view模型做多模态处理的Agent。亮点:基于视觉/多模态appagent,os级别的agent,可以完成系统级别的操作,直接操控多个app。由于需要系统级权限、只支持了安卓。image

  • OS-Copilot

git:https://github.com/OS-Copilot/FRIDAY

doc:https://os-copilot.github.io/

OS级别的Agent,FRIDAY能够从图片、视频或者文本中学习,并且能够执行一系列的计算机任务,比如在Excel中绘图,或者创建一个网站。最重要的是,FRIDAY能够通过做任务来学习新的技能,就像人类一样,通过不断的尝试和练习变得更擅长。

**亮点:**自我学习改进,学习如何更有效地使用软件应用、执行特定任务的最佳实践等。

image

image