浅谈AI Agent 演进之路

1、了解下 AI Agent 的定义

AI Agent（人工智能代理）简单来说是一种能够感知环境、进行决策和执行动作的智能实体。与传统的人工智能相比，AI Agent 具备独立思考和调用工具逐步完成目标的能力。

例如：当要求 AI Agent 帮助下单外卖时，它可以自主调用应用程序、选择餐品、提交订单并完成支付，而无需人为指定每一步操作。

AI Agent 的主要能力组成部分包括：

1、逻辑推理能力和行动能力（Planning）

         1.1、子任务分解：将复杂的任务拆解为更小的、可管理的子目标，以便高效处理。

         1.2、反思与完善：通过对历史行为的自我批评和反思，从错误中学习并优化后续操作，提升任务完成质量。

2、记忆能力和上下文理解（Memory）

          2.1、短期记忆：用于上下文学习，帮助模型记住最近的对话或信息。

          2.2、长期记忆：通过外部向量存储和检索，提供保留和召回长期信息的能力。

3、工具使用能力（Tools）

         3.1、AI Agent 可以调用外部 API 获取额外信息，例如：实时数据计算、代码执行能力或专有信息源的访问权限。

针对上述三种能力，我们来具体看看过去几年 AI 生态圈是如何一步步发展的。

Step 1、 推理 Planning：让 AI 能“思考”和“行动”

           首先 AI Agent 需要有很强的逻辑能力，因为最终在执行多步动作或是帮用户执行任务时，Agent 需要去整理清楚决策思路，如：应该使用哪些工具、有了工具之后如何取获取信息、得到信息之后应该去做哪些操作，所以推理能力是 Agent 最重要的能力之一。

2022年10月：ReAct 推理技术发布

         就在 ChatGPT 上线前一个多月，2022年10月普林斯顿与 Google Brain 合作的团队提出了 ReAct 框架的论文[2]，该框架是一个将推理行为与大语言模型 LLMs 相结合通用的范例。

ReAct（在语言模型中协同推理与行动）框架论文

         ReAct 规范简单来说，就是让 AI 在回答问题的同时，能够去执行一些步骤，不仅仅只是“动动嘴皮子”。具体来讲的话，ReAct 做的事情其实更加偏向于提示词工程（Prompt Engineering），它想通过设定一些不同提示词，能够让大语言模型按照一定的格式去输出。比如：

          第一步：观察现在的情况是怎么样的，理解用户的需求是什么

          第二步：在观察的基础上再去思考一下你下一步要去做什么

          第三步：确定下一步动作后，目前手上有1、2、3三种工具，自己决策为了帮用户解决问题，你会选择何种工具

         第四步：确定工具后执行 function call 或 API 获取到相关信息

        在2023年年初，AI Agent 技术的三大要素的第一步 Planning 就已经搭建好了，逻辑推理能力得到了显著的提升，也可以接各种外部的 API、调用外部工具来完成任务，那么接下来开发者生态进入到了技术发展的Step2。

Step 2 、记忆 Memory：让 Al 有更强的“记忆”能力

        2023年5月11日：Claude 大模型支持 100K token（上下文窗口）

        2023年6月13日：OpenAI 发布 Function Calling & GPT 大模型支持 16k token

        2023年11月21日： Claude 2.1 大模型支持 200k 上下文

        2024年的2月：Google 发布 Gemini 1.5 大模型支持百万级 token

         2024年初，大模型支持的上下文窗口的 token 数扩展到了百万级别。至此，这个 AI Agent 发展必备的第二个技术壁垒 Memory 的限制也完全的被打破了，对于开发者来说就不是大问题了，直接进入Step 3。

Step3 工具 Tools：让 AI 开始“动手”

          时间到了 2023 年年底，前两个技术壁垒的突破让 LLM 大语言模型充当虚拟世界的机器人这件事情变得更加可行，时机成熟时一些初创公司开始在硅谷生态圈活跃了起来。

2023年12月：Simular 发布AI Agent Demo

        23年12月底时，一个叫 Simular AI[3] 的公司发布了他们的第一个 Agent 使用 demo，它应该是业界第一个在发布会上公布让大模型去控制人的电脑的 AI Agent 公司，这一点也算得上是技术的跃升。

2024月10月：Claude 大模型增加 Computer use功能

        2024 年 10月 Claude 大模型发布了 Computer Use 功能，进一步支持 AI Agent 对控制的计算，让 AI 更像一个真正的可以行动起来的智能助手。可以看出，开发者社区或初创社区的行动都比大公司要早很多。

      AI Agent 的四代技术与 AI OS

       AI Agent 技术发展中的逻辑推理能力、上下文记忆能力和工具调用能力，在某种程度上来说，还属与Single Agent（单独智能体）的技术迭代过程。但是要让 AI Agent 真正发展起来，既要做到主流化规模化，就需要实现多个智能体Multi-Agent（多智能体）之间的通信互联。

      当不同的 AI Agent 在不同的设备、不同的机房之间去做计算和联动，这才有机会能够推动上亿级别用户的应用。而这里就存在一个难点，需要一个通用的标准化协议适配范式。

让我们结合AI Agent 技术发展历史来具体看下 AI Agent 技术更新的定义：

【已实现】第一阶段：Single Agent（单独智能体）

  AI  Agent 拥有 Planning、Memory、Tools，中间有大模型 LLM 的驱动。

【已实现】 第二阶段：Multi-agent（单机）

      Agent 中的 Planning 部分拥有逻辑推理和调度的能力，比如：要实现一个复杂任务，用户可以写很多 prompt，把复杂任务拆成很多个子任务，让各个 Agent 之间去通信，但此时的复杂仍是在一个单进程内完成的。像 LangGraph、CrewAI和微软推出的 AutoGen 都已实现多个 Agent 在一个单机上的库之间通信。

【探索中】 第三阶段：Agent实现不同设备、不同机房之间联动（MCP协议）

          如果要支持上亿级别用户的应用，肯定需要一个能在不同设备、不同机房间数据联动和流通的架构，这就是我们目前依然处在尝试中的 Agent 第三阶段架构。这个阶段尝试解决的问题是：很多网站或者工具并不支持AI Agent 的调用（目前很多网站和服务都会有“反机器人/anti-bot”的设置）。

        在 Manus 的测评案例中，我们也会发现 AI Agent 在执行任务时，也会经常访问不了很多数据来源而导致任务失败。所以在这个阶段中，我们需要去打造一个通用协议来解决这个问题，才能够去支持 AI Agent 与外界的联动。

        目前很多公司包括 Antropic 在做协议适配上的尝试，2024年11月初，Antropic 推出了“模型上下文协议”（Model Context Protocol 简称MCP）协议，旨在统一大语言模型与外部数据源和工具之间的通信协议，MCP 的主要目的在于解决当前 AI 模型因数据孤岛限制而无法充分发挥潜力的难题。

        形象一点来说，Antropic 将 MCP 协议称之为“AI 应用的USB-C端口”，支持将大模型直接连到数据源。此前，企业和开发者要把不同数据接入 AI 系统，都得单独开发对接方案，而MCP做的就是提供一个「通用协议」来解决这个问题。

【探索中】  第四阶段：端云一体化的分布式 Agent 网络与互联协议

         然而 MCP 解决了第三代技术的问题，还有最后一个的问题：目前 AI Agent 应用大规模爆发的壁垒，是真正统一的 Agent 和 Agent 间的协议通信标准与分布式计算，就像如今的安卓与iOS一样，我们也需要一个全球大家承认且通用的 AI OS。

    谷歌在Google Cloud Next 25大会上，开源了首个标准智能体交互协议——Agent2Agent Protocol（简称A2A)

     A2A 将彻底打破系统孤岛，对智能体的能力、跨平台、执行效率产生质的改变，A2A 协议当前有 50 多家著名企业参与共建。随着加入的企业越来越多，会极大提升A2A的商业价值以及推动整个智能体生态的快速发展。

     不出意外，本次大会重点在 AI Agent 上，除了 A2A 之外，谷歌还效仿 OpenAI 开源了 Agent 开发套件 ADK，内部测试工具 Agent Engine。

      A2A 是一种开放协议，为 Agent 提供了一种标准的交互方式，使它们能够相互协作，无论底层框架或供应商是什么。

      例如，一家大型电商公司使用了多种企业平台和服务。Atlassian 用于团队项目管理，Box 用于文件存储和共享，Salesforce 用于客户关系管理，Workday 用于人力资源管理。

以前这些平台上的 Agent 无法自由通信。现在通过 A2A 协议，这些企业平台可以安全、自由地自动化交互数据。

A2A 设计原则

A2A 是一种开放协议，为代理之间的协作提供了一种标准方式，与底层框架或供应商无关。协议遵循以下几个核心原则：

• 拥抱 Agentic 能力。A2A 专注于使 agent 能够以自然、非结构化的方式进行协作，即使它们不共享内存、工具和上下文。我们正在实现真正的 multi-agent 场景，而不会将 agent 限制为 “工具”。谷歌正在启用真正的多 Agent 场景，而不是限制 Agent 成为一个工具。
• 建立在现有标准之上。该协议建立在现有的流行标准之上，包括 HTTP、SSE、JSON-RPC，这意味着它更容易与企业日常使用的现有 IT 栈集成。
• 默认安全。A2A 旨在支持企业级身份验证和授权，在发布时与 OpenAPI 的身份验证方案具有同等效力。
• 支持长时间运行的任务。我们设计了 A2A，使其具有灵活性，并支持从快速任务到深度研究的各种场景，当人类处于循环中时，这些场景可能需要数小时甚至数天才能完成。在整个过程中，A2A 可以向用户提供实时反馈、通知和状态更新。
• 模态无关。代理世界不仅限于文本，这就是为什么我们设计了 A2A 来支持各种模态，包括音频和视频流。

A2A 工作原理

A2A 的工作原理是通过促进客户端Agent和远程Agent之间的通信来实现的。客户端Agent负责制定和传达任务，而远程Agent则根据这些任务采取行动，以提供正确的信息或执行相应的操作。在这个过程中，A2A协议有以下几个关键能力。

首先，Agent 可以通过“Agent卡”来宣传它们的能力。这些“Agent卡”是以JSON格式存在的，它们能够让客户端Agent识别出哪个远程Agent最适合执行特定的任务。

一旦确定了合适的远程Agent，客户端Agent就可以利用A2A协议与之进行通信，将任务分配给它。

   然后，任务管理是A2A协议中的一个重要环节。客户端和远程Agent之间的通信都是围绕完成任务展开的。协议定义了一个“任务”对象，这个对象具有自己的生命周期。

对于一些简单的任务，可能可以立即完成；而对于一些复杂的、长期的任务，Agent们可以相互沟通，以保持对任务完成状态的同步。当任务完成时，其输出被称为“工件”。

     此外，A2A还支持Agent之间的协作。Agent们可以相互发送消息，这些消息可以包含上下文信息、回复、工件或者用户指令。通过这种方式，Agent们能够更好地协同工作，共同完成复杂的任务。

      最后，A2A还具备用户体验协商的功能。每条消息都包含“部分”，这些部分是完整的内容片段，例如，生成的图像。

每个部分都有指定的内容类型，这使得客户端和远程Agent能够协商所需的正确格式，并且明确包括用户界面能力的协商，比如iframe、视频、网络表单等。这样，A2A就能够根据用户的需求和设备的能力，提供最佳的用户体验。