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

返回本页常规视图.

AI Agent 的最新资料

最近看到的值得收藏和研究的资料，包括博客，论文，视频，书籍等

1 - 2025 年的资料

2025年的资料

1.1 - Agent Infra 图谱：哪些组件值得为 Agent 重做一遍？

深度分析 Agent Infra 四大核心赛道，探讨创业与云厂商机会

原文地址： https://www.bestblogs.dev/article/234f9a

摘要

本文从投资视角出发，对新兴的 Agent Infra（Agent 基础设施）领域进行了全面的图谱分析，将其划分为 Environment、Context、Tools 和 Agent Security 四大核心赛道。

详细阐述了每个赛道的价值、关键技术（如 Sandbox、Browser Infra、RAG、MCP、Memory、Search、Payment、Backend Workflow）以及值得关注的初创公司。文章探讨了创业公司在 Agent Infra 领域的两大机会：在现有 Infra 中寻找 AI-native 需求，以及抓住 Agent 开发的新痛点。同时，附录总结了主要云厂商（AWS， Azure， GCP）在这些领域的布局，指出当前云厂商的产品多源自传统 Infra，Agent-native 产品相对缺乏。整体为技术从业者和投资者提供了 Agent Infra 领域的全景视图和潜在方向。

主要内容:

  1. Agent Infra 是 Agent 落地的关键，涵盖开发到部署全生命周期。

    Agent Infra 是 Agent 从概念走向实际应用不可或缺的支撑体系，提供 Agent 执行任务所需的计算环境、信息、工具和安全保障。

  2. Environment 和 Context 是 Agent Infra 的核心赛道。

    Environment 为 Agent 提供运行容器（Agent-native computer），Context 为 Agent 提供记忆和知识，是 Agent 有效规划和行动的基础。

  3. Tools 层正快速扩展，搜索和金融工具尤为值得关注。

    Agent 需调用各类工具完成任务，特别是搜索和支付，Agent 经济出现新商业模式，需要专属支付工具和交易网络。

  4. Agent Security 机会需待 Agent 生态成熟后涌现。

    Agent 安全需从静态权限转为动态意图分析，但 AI-native 安全 Infra 是需求驱动，尚处早期，老牌安全厂商主导。

  5. 创业公司机会在于寻找 AI-native 需求和抓住新痛点。

    创业公司可在现有 Infra 中寻找 Agent 特有的高性能需求，或开发易用性高、降低开发门槛的新 Infra 产品。

作者：Lai、bryan、haozhen

编辑：penny

2025 年以来，Agent 开发量和使用量都有明显提高。Agent 的爆发带来了 Agent Infra 需求的爆发。在过去 1-2 年，Agent 开发大多依赖开发者手动使用传统 Infra 搭建，开发工程量大、流程复杂，但随着越来越多 Agent-native Infra 涌现，Agent 开发的难度和周期都在缩小，开发的范式正在重构和收敛。

我们之前已经研究了 Browserbase 、E2B 等公司，本文是我们对于 Agent Infra 领域图景更全面的 Mapping。我们划分出了 Environment、Context、Tools、Agent Security 这四大赛道，逐步分析每个环节的价值和值得关注的初创公司：

• Environment 的作用是给 Agent 执行任务提供容器，是一个 Agent-native computer；

• Context 层是在 Agent 工作中赋予记忆 Memory 和领域知识的重要中间层；

• Tools 由于 MCP 协议的统一而百花齐放，同时目前 Tools 的核心用户还是开发者，普通用户的使用门槛太高；

• Agent Security 是在 Agent 产品范式固定之后会涌现的大机会，需要同时确保避免 Agent 受攻击和发起攻击。

目前 Agent Infra 是模型公司、云厂商、初创公司都在积极拓展的领域，我们认为创业公司的机会在于：1）在已有 Infra 中寻找真正 Agent-native 的需求，使 Agent 开发者开发出效果更好的产品，比如 Browserbase 对传统 headless browser 做了这样的迭代；2）抓住 Agent 开发中的新痛点，例如 MCP 领域现在缺乏一个好的 marketplace 和 selector，帮助 Agent 去选择对的工具。

概述

Agent Infra 是 Agent 落地的关键，涵盖了 Agent 从开发到部署的完整生命周期。我们对这个领域进行了初步扫描后，按重要性划分出了四大赛道，分别是 Environment、Context、Tools 和 Security，并进一步拆解了我们看好的细分领域的 thesis 和初创公司。

Environment 指的是 Agent 可操作的容器，相当于给了 Agent 一台可自行操作的计算机，Agent 可以在其中端到端地完成任务，这个赛道包括 Sandbox、Browser Infra、Agent 操作系统等不同的细分领域，我们看好其中的 Sandbox 和 Browser Infra。

Context 为 Agent 有效运行提供所需的信息，这个信息既包括任务相关的背景知识，也包含各类工具的使用方法。有了这些信息，Agent 才能在特定任务场景中，合理判断应以哪种顺序调用哪些工具，才能更有效地完成任务。我们将主要分析这个赛道中的 RAG、MCP 和 Memory。

Tools 相关的 Infra 使 Agent 能够便捷调用各类工具，实现搜索、UI 设计、数据访问、支付等多样化的任务。随着 Agent 交互复杂度的持续上升，工具层正迅速扩展。搜索（Search & Scraping）、金融（Finance & Payment）、后端工作流（Backend Workflow）这三类工具，尤为值得重点关注。

Security Infra 以 Agent-native 的方式保障 Agent 的行为与数据在执行过程中的安全与合规。随着 Agent 能力边界的不断拓展，市场对 Agent 安全性的要求也在同步提高。然而，这一环节的 AI-native Infra 机会需要在 Agent 生态更为完善后才能出现更清晰的格局。

img

除了上述赛道和公司之外，Agent Infra 领域还在不断涌现更为成熟的解决方案。Infra 是模型公司、云厂商、初创公司都在积极拓展的领域，我们认为创业公司的机会主要有两类：

1**. 在已有 Infra 中寻找有 AI-native 需求的环节。**这种需求可以是 Agent 开发对该环节的某些性能提出了更高的要求，例如 Sandbox 需要更快冷启动速度、更强的隔离性；这种需求也可以是需要和 AI workflow 结合的更好，有更多 AI-native 的功能点，例如增加 RAG 功能，或者和某些 AI 开发者常用的语言或 SDK 有更好的结合。

2. 抓住 Agent 开发中的新痛点。Agent 开发要追求 R&D 和时间投入的 ROI，对降低开发门槛和工程量的 Infra 产品有较大需求，因此一套易用性高且价格合理的 Infra 就有机会被广泛采用。而且 Agent 生态是一个强调共建的生态系统，而 Infra 的持续创新，正在大力推动这种生态的构建。

投资主题 1：Environment

Environment 提供 Agent 开发和行动的容器，相当于给了 Agent 一台可自行操作的计算机，Agent 可以在虚拟环境中端到端地完成任务，训练并探索新能力。我们将主要分析这个赛道中的沙盒（Sandbox）和 Browser Infra。

img

Sandbox：为 Agent 创造理想的虚拟机环境

Sandbox 是一种安全机制，为执行中的程序提供隔离环境，即为 Agent 提供了一个可以隔离运行的虚拟机环境，开发者可以在这个环境中实现 Agent 的开发、部署、运行。但随着 Agent 的不断发展，传统的虚拟机并不能很好地满足 Agent 需求，原因在于：

  1. Agent 对虚拟机的性能提出了更高的要求，比如需要更高的隔离性、更快的启动速度、更强的稳定性；

  2. Agent 的虚拟机还要求具备一定的 AI 性能，例如需要具备代码解释器（code interpretor）的功能，或需要整合开发者常用的 AI 架构，如 Vercel AI SDK。

因此我们判断 Sandbox 存在初创公司的机会，比如 E2B 提供了更 AI-native、更快启动的 microVM ，获得了 Perplexity、Hugging Face 等头部 AI 企业的认可；Modal 则提供了更 Cloud-native、更可规模化的虚拟机，可以更好地满足 Agent 开发需求。

img

注：🌟 代表值得重点关注的公司

Browser Infra: 使 Agent 更好地适应浏览器环境

在如今的人类社会中，大部分的信息都存在于互联网浏览器中，大部分的生产力工作也都能在浏览器环境中完成。因此，我们判断浏览器环境将是 Agent 最重要的工作环境之一，浏览并操纵网页的能力也将成为 Agent 的核心能力之一，而 Browser Infra 正赋予了 Agent 这种能力。

具体来看，Browser Infra 大致可以分为两类：

  1. 第一类 Infra 让 Agent 可以大规模浏览网页，比如 Agent 能在云端同时浏览不同网页来获取所需信息；
  2. 第二类 Infra 使得 Agent 可以操纵网页，比如 Agent 能灵活地进行加载、选择、点击等网页端的操作。

对于第一类 Infra 而言，传统的解决方案是利用 Puppeteer、Playwright 等 browser 库进行开发，优势是能获得更高的定制化程度，对产品的控制力更强，价格也更便宜，但是劣势在于需要强大的工程团队和大量开发时间，且构建出的产品比较臃肿。

因此当下的 Agent 开发正在逐步采用更 AI-native 的 Browser Infra，希望能用易用性更高的产品来实现 Agent 的快速搭建和发布，这一领域的代表公司是 Browserbase。在访谈中，我们发现开发者看重 Browser Infra 的因素包括带宽、价格、速度等，而 Browserbase 正是在这几个维度达到了一个高性能的平衡，因此获得了开发者青睐。

第二类 Infra 能够赋予 Agent 更强的理解浏览器内容的能力，相比直接简单调用 API，Agent 能够像人一样更深入的进行网页操作。我们认为这是一块更新兴、更 Agent-native 的 Infra 机会，Browser Use 这家公司尤其值得关注，这也是 Manus 在使用的 Browser Infra，在 Manus 问世之后进一步走红。

img

注：🌟 代表值得重点关注的公司

投资主题 2：Context

丰富的上下文信息是 Agent 有效规划和行动的基础。基于文本 Context，Agent 可以更好地理解任务的背景，实现更具体的特定任务；基于工具 Context，Agent 也能够更好地理解工具的用法和用途，从而决定使用哪些工具，以哪种顺序调用工具，如何将工具整合在一起来完成任务。我们将主要分析这个赛道中的 RAG、MCP 和 Memory。

img

RAG: 为 Agent 提供具体的 Context

RAG（Retrieval-Augmented Generation），即检索增强生成，这是一种结合了信息检索与生成式 AI 的技术架构，广泛用于提升 LLM 在问答、文档摘要等任务中的准确性与时效性。如今 Agentic RAG 系统能够持续分析 Context 和用户意图，自主从多种来源（包括实时数据流和外部 API）检索并整合相关信息，使得 Agent 可以更好完成任务。

RAG 的提出时间较早，目前基本已成为一种共识性的技术，并在各类应用场景广泛使用，相关的头部创业公司也发展得较成熟，比如专注企业内部数据 RAG 搜索的 Glean 已经获得了包括 Reddit、Duolingo、Bookings 在内的一众企业的认可，最新估值已接近 70 亿美元。

img

注：🌟 代表值得重点关注的公司

MCP: 提供标准化的工具和数据接口

MCP 是 Anthropic 在去年 11 月发布的一个开放式协议，重新定义了 Agent 调用外部工具、获取数据以及与各类服务交互的方式。如今 MCP 已成为 Context 的一大标准化解决方案，相关生态也在不断发展。

目前 MCP 相关的 Infra 创业机会还处在相对早期的阶段，在一些业务逻辑互通的细分赛道，已有公司在原先业务基础上拓展至 MCP 相关的产品。例如：

  • Mintlify 可以用客户已有的 Documentation 或 OpenAPI spec 直接做出 MCP Server，不需要额外的代码；

  • Stainless 可以在 SDK 生成的基础上增加了 MCP Server generator，同样简化了 MCP server 的构建过程；

  • Composio 也在集成主流 Agent 工具的基础上新增了 MCP connector 产品，托管了 100 多个的 MCP Server，内置身份验证，让 Agent 可以简化繁琐的逐一设置并连接 MCP 的过程。

此外，还有一类做 MCP marketplace 的公司，集合各细分领域的 MCP Server 供 Agent 开发者进行选择和使用。自从 MCP 发布以来，MCP Server 数量在快速增长，MCP.so 里的 MCP Server 数量已经高达 1.3w+。

但是我们认为单纯做 marketplace 的价值较薄，最重要的价值是为 Agent 评估和编排 MCP server 的使用，这类工作和价值量可能会集成在 Agent 开发端。

img

注：🌟 代表值得重点关注的公司

Memory: 赋予 Agent 特定的记忆力

Memory 是构建复杂 Agent 的关键基础。如果仅依赖 LLM 自带的有限上下文窗口作为短期记忆，Agent 将在跨会话中处于 stateless 的状态，难以维持连贯性。同时，缺乏长期记忆机制也限制了 Agent 自主管理和执行持续性任务的能力。引入额外的 Memory 可以让 Agent 做到存储、检索，并利用历史交互与经验，从而实现更智能和持续的行为。

Agent 的 Memory 包括短期记忆（STM，存储单次交互信息）、长期记忆（LTM，可以横跨多次交互信息以实现个性化）和程序记忆（指导 Agent 行为的规则）等。Memory 给 Agent 赋予了特定的记忆力，本质一种提升 Agent 智能性的方式，Agent 能凭此有更高的个性化程度和一致性表现，也能在多步骤或长周期的复杂任务中提升准确性。

img

一些创业公司通过提供外部数据库的方案为 Agent 构建 Memory，例如 Mem0 采用混合数据库系统从交互中提取并存储关键信息，Zep 则运用时序知识图谱追踪动态变化的用户数据、提升个性化能力。

与此同时，模型公司也在不断优化模型本身的 Memory layer，比如一些开源模型通过引入额外的、可训练的"记忆槽"，使模型具备一定的记忆存储能力。相比其他领域，创业公司在 Memory 的机会边界相对没有那么清晰。

img

注：🌟 代表值得重点关注的公司

Case study - Letta

Letta 成立于 2024 年，专注于构建具备长期记忆能力的 stateful AI Agent 平台，由伯克利实验室孵化而来，团队研究背景非常强。Letta 整合了可视化开发环境（ADE）、生产级 API 及服务器运行时系统，ADE 可实时查看 Agent 记忆生成、管理的轨迹，Letta 还可以通过 context 管理，来实现 Agent 状态持久化，使 Agent 具备持续学习进化的能力。

img

近期，Letta 团队发布了一个关于 “Sleep time compute"的有趣研究，进一步说明了 Memory 在提升 Agent 性能上具有重要作用。该研究的主要想法是让 AI 充分利用不与用户交互的时间（即 sleep-time），来预先处理 Context 信息，并提前完成推理，将 raw context 处理为 learned context，这样可以在实际应答时，减少即时推理的计算负担，最终达到提高推理质量的效果。

img

Agent 有大量的 Sleep-time

img

AI 可以在 Sleep-time 完成对 Context 预处理

投资主题 3：Tools

在完成搜索、数据提取、支付等各种任务的时候，Agent 需要调用各种工具，这个领域的玩家价值在于给开发者提供了可直接调用、无需自建的 Infra。随着 Agent 交互复杂度的不断提升，工具层正在快速扩张，OpenAI 判断 Agent 可调用的工具数量将会在几个月内从目前的 10 个量级 Scale 到 100 个量级。我们将主要介绍搜索（Search & Scraping）、金融（Finance & Payment）、后端工作流（Backend Workflow）这三个方面的工具。

img

Search & Scraping: 赋予 Agent 搜索能力

搜索是 Agent 获取外部信息的重要途径，我们认为 Agent 搜索领域的机会非常大，原因在于：

  1. 相比人类，Agent 会进行更频繁、更复杂的搜索，Agent 在完成单一任务的时候往往就需进行数十次搜索，随着多步骤任务的推进以及 multi Agent 的发展，未来 Agent 的搜索量将远超人类。

  2. 传统搜索引擎无法满足 Agent 的搜索需求，Agent 需要更 AI-native 的搜索工具。传统的搜索引擎基于关键词进行检索，常返回"SEO 垃圾”，而 Agent 搜索更侧重理解而非匹配，因此 Agent 搜索在 context 的理解、搜索的全面性和准确性上都提出了更高的要求。

由于 Google 等搜索巨头不愿完全开放 API，再加上当今的搜索引擎构建成本已从数亿美元降至数千万美元，我们判断 Agent 搜索领域存在以下三个创业公司的机会：

  1. 为海量 Agent 搜索提供足够快速且廉价的解决方案，如 Serper 和博查提供了价格远低于 Bing 的搜索 API，获得了希望自行处理海量原始信息的 Agent 开发者的青睐；

  2. 给 Agent 提供更智能的搜索， 如 Exa 实现了更复杂的语义搜索，能提供更优质的检索结果；

  3. 为 Agent 提供智能的爬虫架构， 如 Firecrawl 提供了开源的数据抓取框架，增强了 Agent 获取网页信息的能力。

目前看来，第一类创业机会的价值点最清晰，许多开发者非常看重搜索信息的全面性和 API 价格，希望自己能够在 Agent 产品中完成信息筛选，从这个角度来看 Search API 有 commoditize 的趋势。

img

注：🌟 代表值得重点关注的公司

Finance & Payment: 让 Agent 能交易和货币化

Agent 在金融领域的应用也值得关注，我们判断随着 Agent 能力的发展，Agent 会成为金融领域重要的主体，虽然当前 timing 还相对偏早，但这一领域可能会有 Visa 或 Stripe 级别的大机会。

我们认为 Agent 需要专属支付工具与交易网络。在当下，完成一个复杂任务通常会涉及到调用付费内容或工具，因此 Agent 需要具备支付能力。而当 Agent 被调用并完成任务时，也应当能像人一样"赚取"报酬。比如 Skyfire 就在利用区块链技术为 Agent 提供身份认证、交易和变现服务，使得 Agent 能够真正成为经济社会的生产主体。

img

Skyfire 让 Agent 具备支付和收款能力

img

例子：AI Agent 使用 Skyfire 进行自动化支付

Agent 经济也会出现新的商业模式与变现方式。当前大多数 Agent 是按 seat 或是任务次数收费，未充分将 Agent 工作的价值变现。我们判断 Agent 的计费方式会逐步变为按照任务过程和结果付费。复杂的 Agent 网络也可能共同完成任务，未来可能需要构建一套适用于 Agent 的智能合约，为 Agent 自动化分配经济利益。

例如，Sequoia 近期投资的 Paid 这家公司就是根据每个 Agent 的实际产出来定价、最大化 Agent 收益，并能够管理 Agent 的毛利、为客户量化 Agent 的 ROI 等，希望重构一套 Agent 时代的货币化机制。

img

注：🌟 代表值得重点关注的公司

Backend Workflow: 简化 Agent 后端开发

除了上述工具之外，还有一类工具的作用在于简化 Agent 后端开发，目的是在数据库搭建、任务自动化、工作流编排等方面降低 Agent 开发难度。这类解决方案往往是在服务大企业开发场景的基础上，凭借易用性或 LLM-native 的特性吸引到新一代的 AI 开发者。例如：

Supabase 提供了 Backend-as-a-service ，被视作“开源版的 Google Firebase 替代方案”。Supabase 将后端工作打包为一站式服务，提供自动 API、用户认证、对象存储、实时订阅、向量数据库等多个功能模块，让开发者可以像用乐高积木一样即插即用地快速搭建后端。随着 vibe coding 爆火，Supabase 已经被 Lovable 、Bolt.new 等 AI coding 产品设置为默认后端，吸引了 200 多万开发者。

Firebase Studio 是 Google 发表的一个基于云端的全栈 AI 开发平台，目的是帮助开发者快速构建、测试和部署生产级应用，整合了 Gemini 大模型、Project IDX 和 Firebase 全家桶服务，提供从原型设计到上线的一站式开发体验。

Inngest 则提供了工作流编排平台，提供 “Zero-Infra” 和 AgentKit，将原先时间长、步骤复杂的 Agent 开发与编排进行了简化。

img

注：🌟 代表值得重点关注的公司

投资主题 4：Agent Security

Security 也是我们认为较关键的 Infra。随着 Agent 能力边界拓展，Agent 安全性上的要求也在同步提升。

img

当 Agent 代表用户进行各类行动时，我们不仅需要对 Agent 进行身份验证，还需保证 Agent 的每个意图、每个行动都是安全的。随着 Agent 智能性增强，Agent 的安全框架需要从静态的权限控制转变为动态的意图分析。此外，Agent 每次数据交互都需要动态校验，这也对数据安全提出了更高的要求。

目前，Agent 使用的 Security 相关的 Infra 产品以相对老牌的玩家为主。相对老牌的玩家本身在服务大企业的数据和运行安全时就已经积累了完善的 Infra 能力，能够较好地将功能外溢并服务好当前的 Agent。例如 Chainguard 为 Agent 在开发阶段提供安全的基础镜像，Haize Labs 对 AI system 进行压力测试、增强稳健性，Oligo 则为 Agent 提供运行实时监控与异常检测。

**我们认为 Security 这一领域遵循“需求驱动”的逻辑，即先有成熟的下游产品设计，再有对应的安全问题与解决方案。**因此，这一环节的 AI-native Infra 机会需要在 Agent 生态更为完善后才能出现更清晰的格局，当前阶段还是偏早。

img

附录：云厂商在 Agent Infra 的布局

Agent Infra 领域还有一类不容忽视的玩家就是云厂商，云厂商可以提供 Agent 所需的算力资源、部署环境等。为了更好看清 Agent Infra 领域的玩家格局，我们汇总了 AWS、Azure、GCP 这三大云厂商在该领域的布局。

  • Environment

​ 三大云厂商都陆续推出了自己在 Enviroment 上的产品，但我们认为，目前没有出现 Agent-native 的产品。

  • Sandbox

    1. AWS 在 2014 年推出 Amazon S3 Buckets，提供了存储桶和访问控制列表等机制；2020 年又推出了 Amazon EC2 Nitro Enclaves，可以运行敏感代码，确保数据与主系统完全隔离，适用于高安全需求场景。

    2. Azure 发布过一个开源项目 Azure Sandbox，2022 年推出了 Azure Container Apps Sandbox Mode，可以在 Hyper-V 隔离的沙盒中运行不受信任的代码（如 LLM 生成的代码），支持动态会话和代码解释器。

    3. GCP 早在 2008 年就发布了 Google Compute Engine，提供高性能的虚拟机实例，支持多种操作系统和配置；2017 年推出无服务器计算平台 Google Cloud Functions，用户可编写和部署函数代码，无需管理服务器基础设施。

  • Browser Infra

    1. AWS 在 2014 年发布了开源框架 Lambda Serverless Chrome，开发者可以部署无头浏览器，实现网页截图、PDF 生成、自动化测试等功能。

    2. Azure 在 2019 年推出了一个无头浏览器控制库 Azure Playwright ，支持的浏览器涵盖 Chrome、Firefox、Safari、Edge 等。

    3. GCP 在 2018 年发布 Google Puppeteer 库，也是一个无头浏览器控制库，可直接控制无头 Chrome，支持网页自动化测试、爬虫等任务。

  • Context

​ 2023-2024 年，公有云厂商纷纷推出 RAG 相关解决方案，推动了一波尚未上云的企业加速上云。2025 年，公有云厂商开始积极拥抱 MCP，他们不仅有数量庞大的 API 体系，还配备了对应的 CLI 工具，简化了与 MCP 的集成流程。

  • RAG

    1. AWS 先后在 2020 年和 2023 年推出了企业级智能搜索 Amazon Kendra 和端到端的 RAG 解决方案 Amazon Bedrock Knowledge Bases。前者为 RAG 应用提供文档检索能力，能够处理大量不同格式的文档，快速找到与用户问题相关的准确答案；后者支持自定义连接器、流式数据摄取，增加了结构化数据检索和知识图谱的功能。

    2. Azure 早在 2014 年就发布了开源数据管道和转换套件 GraphRAG，目的是利用 LLM，从非结构化文本中提取结构化数据；2018 年又推出了 Azure Cognitive Search，可以智能搜索，并与 Azure AI 集成。

    3. GCP 分别于 2023 年和 2025 年推出了 Vertex AI Search 和 Vertex AI RAG Engine。前者是一款完全托管的搜索 API，简化了企业数据源的连接，支持跨数据源搜索，适用于对开箱即用的质量、可扩展性以及细粒度访问控制要求较高的企业场景；后者则是一项托管的编排服务，简化了信息检索、LLM 集成的流程。

  • MCP

    1. AWS 推出了 AWS MCP Server，通过一系列模块化服务器套件，给开发人员提供 AWS 文档、知识库等资源直接访问的能力。

    2. Azure 发布了 Azure MCP Server 和 Playwright-MCP，前者支持访问多种 Azure 服务，包括 Azure Cosmos DB、Azure Storage 和 Azure Monitor 等，功能包括数据库查询、存储管理和日志分析等；后者是一个开源框架，允许 LLMs 通过结构化数据，来与网页交互，实现自动化测试等功能。

    3. GCP 推出了开源 Agent 交互标准 Agent-to-Agent Protocol 和开发套件 Agent Development Kit，前者支持不同框架的 Agent 直接协作，考虑到 MCP 的使用场景是 Agent 与工具交互，A2A 的使用场景是 Agent 之间的通信，A2A 会与 MCP 形成互补格局；后者支持 MCP 工具集成。

  • Tools

​ 在 Tools 领域，除了 Azure 和 GCP 各自推出了 Search API 之外，三大云厂商也在 Backend Workflow 赛道早早推出了各自的产品，但我们认为，Tools 领域和 Enviroment 领域类似，目前并没有看见 Agent-native 的产品。

  • Backend Workflow

  1. AWS 在 2016 年就推出了 AWS Step Functions，通过可视化方式编排多个 AWS 服务，支持以状态机的形式定义执行步骤和状态转换，简化了分布式系统的开发与运维管理。

  2. Azure 在 2016 年推出 Azure Logic Apps 和 Azure Functions。前者提供可视化设计器和预构建连接器，用于构建和管理自动化工作流；后者则支持多种编程语言的事件驱动计算，可与 Azure 生态中的其他服务无缝协作，适合用于构建无服务器架构的应用程序。

  3. GCP 于 2017 年推出了 Google Cloud Functions，这是一个支持多种编程语言的事件驱动型无服务器计算平台，能够响应包括 HTTP 请求、Pub/Sub 消息、Cloud Storage 变更等多种事件类型；2020 年推出了 Google Cloud Workflows，用于编排各类 Google Cloud 服务的自动执行与集成。

附录: 公司总结(脑图)

1.2 - AI Agent 基础设施栈

人工智能代理基础设施栈–三个定义层： 工具、数据和编排

原文地址： https://www.madrona.com/ai-agent-infrastructure-three-layers-tools-data-orchestration/

想象一下，一家初创公司的 20 人团队可以在不到两年内产生 1 亿美元的年度经常性收入。这不是一个未来主义的幻想-这是人工智能驱动的增长正在展开的现实。Cursor、Bolt、Lovable 和 Mercor 等公司正在打破传统的规模规则，证明配备智能代理的精益团队可以颠覆整个行业。

这揭示了创业动态的转变。创始人不再受员工人数或传统开发周期的限制。随着人工智能代理从早期的成功转变为现代软件的基础部分，它们正在推动基础设施需求的转变。

这种转变遵循一种熟悉的模式：随着新应用程序的出现，它们会突破现有基础设施的极限，从而产生对新功能的需求。反过来，基础设施的进步释放了更强大的应用程序，推动了下一波创新。人工智能代理也不例外–它们的快速采用正在重塑软件的构建方式和支持软件的基础设施。对于创始人来说，这提供了一个巨大的机会：构建人工智能原生基础设施–涵盖工具、数据和编排–这将为下一波智能应用提供动力。

在这个新时代，每位创始人都面临着一个关键的选择：适应人工智能的变革力量，否则就有落后的风险。代理采用率的激增不仅仅是一种趋势，而且是对软件构建、部署和扩展方式的根本性重新构想。

从效率到基础设施：更深层次的信号

这不仅仅是高效增长的问题–这一转变标志着更深层次的东西。随着成功的代理应用程序的清晰模式出现在人们的视野中，创始人们正急于接受和扩展有效的模式。代理采用的激增对支持这些应用程序的基础架构层提出了新的要求。

自 2024 年 6 月我们撰写《 人工智能代理基础设施的兴起 》以来，我们一直在跟踪这一演变。当时，景观是稀疏的，由 DIY 解决方案主导，因为开发人员优先考虑灵活性，以尝试不同的方法。有一大批新公司正在为未来的代理商状态构建基础设施，但这些公司面临着一个不断变化的目标。今天，这一情况发生了巨大变化。

证据无处不在：无服务器 Postgres 提供商 Neon 报告称，人工智能代理现在正在其平台上创建数据库，其速度是人类开发人员的 4 倍以上，从而加速了 Neon 的整体指标：

像 Browserbase 这样的专业 AI 代理基础设施组件也在加速。例如，Browserbase 的 Stagehand UI 自动化库最近每月的 npm 安装量超过了 50 万。

这些不仅仅是增长指标–它们是软件构建和部署方式发生根本性转变的信号。

这种转变为代理应用程序和支持它们的基础设施提供了机会。与“当市场地图出现时，为时已晚”的古老格言相反，我们看到2025年成立的公司已经在这个领域获得了巨大的吸引力。基础能力和模式的发展如此之快，以至于新进入者能够迅速确定和满足新出现的需求。

从实验到清晰的模式

一年前，代理开发的特点是广泛的实验。开发人员基本上从头开始构建，在寻找获胜方法时优先考虑灵活性以实现重点转移。今天，情况发生了巨大变化。已经出现了多种可重复的模式，聪明的创始人正急于接受和扩展有效的模式。

这些模式建立在我们在 1 月份对代理格局的分析中所确定的基础上，展示了一组常见的代理模式是如何进入视野的： 下一代副驾驶是上下文感知的助手，可以主动帮助完成复杂的任务，例如 Bolt.new，AirOps 和 Colimit。拉文纳、Sailplane 和 Basepilot 等队友代理通过自动驾驶多步工作流程向前迈进了一步。 代理组织引入了多个专门代理一起工作的协作系统，如 Aaru 的概率模拟所示。下一个类别， 代理即服务 ，提供专门的代理功能作为面向开发人员的服务，而不是面向用户的产品。

所有这些都对上图所示的基础设施堆栈有影响。

基础架构堆栈出现：三个定义层

随着代理模式的固化，AI 代理基础设施堆栈的三个层已经成为特别定义：工具，数据和演示。每一层都面临着激烈的竞争，因为提供商竞相解决与传统 SaaS 基础设施根本不同的代理特定挑战。

工具层：使代理具有能力

工具层的扩展最为显著，反映了代理交互的日益复杂。主要战场包括：

浏览器基础设施和 UI 自动化

代理越来越需要与可视化 Web 交互-而不仅仅是 API。像 Browserbase、Lightpanda 和 Browserless 这样的公司正在构建基础设施来实现这一点，而像 Stagehand 这样的专业服务则为常见模式提供更高级别的抽象。

身份验证和安全

当代理代表用户进行操作时，身份验证和安全性就有了新的意义。像 Clerk、Anon 和 Statics.ai 这样的公司正在开创“auth for agents”–以代理本地的方式管理权限、凭证和安全性。

工具发现和集成

正如 Akash Bajwa 最近评论的那样 ，Anthropic 的模型上下文协议（MCP）正在成为一种潜在的“人工智能代理的 TCP/IP”，为代理提供标准化的方法来发现和与工具交互，同时维护上下文。Stripe、Neo 4j 和 Cloudflare 等主要参与者已经提供 MCP 服务器，这表明这可能成为工具集成的关键标准。

Composio 和 Arcade.dev 等公司正在这些协议之上构建抽象层。Composio 提供对流行应用程序（如 Gmail 和 Linear）的 MCP 兼容访问，通过 TypeScript 和 Python SDK 为开发人员提供标准化接口。同时，Arcade.dev 通过与 OpenAI 规范兼容的统一 API 层简化了身份验证和工具管理。

这种多层方法至关重要，因为它可以满足不同的开发人员需求。基础设施团队可以直接针对 MCP 等协议进行构建，而应用程序开发人员可以利用 Composio 或 Arcade.dev 等托管解决方案。这些方法并不相互排斥;相反，它们可以共存并相互补充，最终加速代理驱动应用程序的采用。

今天，发现代理就绪工具仍然经常依赖于口碑，感觉就像发现 Discord 服务器的早期一样。但是标准化协议和托管集成层的结合表明我们正在向更结构化的发现机制发展。

数据层：大规模内存

数据层说明了传统基础设施必须如何为代理工作负载而发展。Neon 的经历很有启发性。如上所述，人工智能代理现在以人类开发人员的 4 倍速度创建 Neon 数据库，推动了对即时配置、自动扩展和隔离环境的新需求。当 Create.xyz 在 Neon 上推出其开发人员代理时，Create 最终在短短 36 小时内创建了 20，000 个新数据库。最终用户只需描述他们想要构建的内容-“构建一个使用 AI 对应用程序进行排名的工作板”或“创建一个自动生成 SEO 元数据的内容管理系统”-代理自动处理所有数据库操作。

数据层专门分为不同的组件，每个组件都有一个独特的功能。 记忆系统 ，如 Mem0 和 Zep，提供特定于代理的上下文，确保代理可以保留和回忆相关信息。 存储解决方案（包括传统数据库（如 Neon）和矢量数据库（如 Pinecone））正在不断发展，以适应代理工作负载的需求。与此同时，ETL 服务正在出现，以处理非结构化数据的处理，从而在代理驱动的系统中实现更高效的数据转换和集成。

编排：管理代理复杂性

随着应用程序包含多个一起工作的代理，编排变得至关重要。LangGraph、CrewAI 和 Letta 等托管编排解决方案使开发人员能够组合和管理多个协同工作的代理，简化复杂的工作流程并增强协调。作为这些编排工具的补充，Inngest、Hatchet 和 Temporal 等持久化引擎解决了跨长期运行的代理进程维护状态的挑战，确保了连续性和可靠性。

展望未来：桥梁形成

一年前，我们将开发人员描述为“ 快速通过半成品桥梁”， 在支持它们的基础设施仍在建设中的情况下构建代理应用程序。今天，这座桥更完整了，但交通量呈指数级增长，我们仍在增加新的车道。

人工智能代理基础设施的快速发展反映了软件构建方式的根本转变。我们看到的不仅仅是令人瞠目的增长指标。我们正在关注一种新的软件开发范式的出现。

基础设施堆栈正在成熟，以满足这一时刻。从 MCP 这样的标准化协议到用于认证、内存和编排的专门服务，我们看到了将定义下一代应用程序的模式的出现。然而，创新的步伐意味着我们仍处于这一转型的早期阶段。

让我们一起建设

我们很高兴分享2025年2月人工智能代理基础设施堆栈的视图。我们的行业继续共同学习-所以请让我们知道我们错过了什么，以及我们如何更准确地反映开发人员的选择。

Madrona 正在积极投资 AI 代理，支持它们的基础设施以及依赖它们的应用程序。我们已经支持了这一领域的多家公司，并将继续这样做。您可以直接访问：jonturow@madrona.com

2 - 2024 年的资料

2024年的资料

2.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.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