AI Agent 概览 - 技术栈

生成式AI应用的分级？

层级	AI应用	描述	示例
L1	Tool (工具)	人类完成所有工作，没有任何明显的 AI 辅助	WPS、Excel、Photoshop、MATLAB 和 AutoCAD 等绝大多数应用
L2	Chatbot (聊天机器人)	人类直接完成绝大部分工作。人类向 AI 询问，了解信息。AI 提供信息和建议，但不直接处理工作	初代 ChatGPT
L3	Copilot (协同)	人类和 AI 共同工作，工作量相当。AI 根据人类要求完成工作细稿，人类进行后期校正、修改和调整，并最终确认	GitHub Copilot、Microsoft Copilot
L4	Agent	AI 完成绝大部分工作，AI 负责设定目标、提供资源和监督结果，以及最终决策。AI 进行任务拆分、工具选择、进度控制，实现目标后自主结束工作	AutoGPT、BabyAGI、MetaGPT
L5	Intelligence (智能)	智能完全不须人类监督，AI 自主拆解目标、寻找资源、选择并使用工具，完成全部工作，人类只需给出初始目标	冯·诺伊曼机器人或者......人？

Copilot和Agent区分核心在于是否有自我规划与执行闭环

blog.csdn.net/w605283073/...

从传统智能体到LLM时代背景

从传统智能体到 LLM Agent

Agent ，即"智能体"，长期以来是人工智能的核心概念，代表一种能自主感知环境、做出决策并采取行动的系统。

早期智能体多依赖强化学习（Reinforcement Learning）进行决策控制：

- 与环境循环交互：观察状态 → 决策动作 → 获得奖励 → 状态更新
- 广泛应用于机器人控制、自动驾驶、博弈系统（如 AlphaGo、OpenAI Five）

但这种传统 Agent 更偏"控制论"，适合结构化任务，对开放性语言、复杂推理支持不足。

大语言模型推动 Agent 进入新时代

随着 ChatGPT 爆火 、GPT-4、Claude、 DeepSeek 等模型持续迭代，Agent 进入了新的发展阶段：

LLM（大语言模型）成为 Agent 的"智能大脑" ，赋予其前所未有的通用能力：

🌐 自然语言理解与推理能力增强（reasoning...）
🧠 多模态感知与强上下文记忆能力提升
🔎 RAG（检索增强）机制带来外部知识接入能力
⚙️ 调用工具 / API / 搜索等执行能力成为新常态

与此同时：

✅ Token 成本大幅降低，调用性价比显著提升
✅ API 和框架生态标准化（LangChain、AutoGPT、MetaGPT等）
✅ 开源模型（LLaMA、DeepSeek、Mistral等）涌现，部署自由度提升

这一切促成了 "LLM Agent" 爆发式增长，成为向 AGI（通用人工智能）迈进的关键路径。

AI Agent 在新时代下有了更清晰的定义：

AI Agent 是一种具备自主感知、规划、决策和行动能力的智能体，它可以接收目标或任务，自主调用工具、与人/系统交互，甚至协同其他 Agent 完成复杂任务。

什么是基于LLM的Agent？

lilianweng.github.io/posts/2023-...

OpenAI 安全系统团队负责人 Lilian Weng 在其 2023 年 6 月的博客《LLM Powered Autonomous Agents》中系统总结了当前 LLM Agent 的研究现状、架构设计、存在挑战与前景探索。同时，诸如 LangChain、AutoGPT、MetaGPT 等 Agent 框架也陆续推出，为 Agent 系统的搭建提供了标准化支持。

基于大语言模型的Agent的核心是大语言模型，大语言模型 承担着大脑的角色，用于思考和规划 ，而围绕着大语言模型，Agent还包含记忆和工具，记忆用于存储短期上下文信息和长期知识信息，工具则承担着感官和四肢的角色，在大语言模型的思考和规划下，Agent一方面可以通过工具获取外部的各种信息用于进一步的思考和规划，另一方可以通过工具执行动作对外部环境施加影响。

基于LLM的Agent的整体架构

基于LLM Agent的整体架构：

一个基本的LLM Agent系统通常包含以下模块：

Planning 规划：LLM作为Agent的大脑，负责思考和规划，思考和规划又分为两部分：
- 分而治之（Task Decomposition）：对于复杂的任务，大语言模型会将其分解为多个相对简单的子任务，每个子任务包含独立的子目标，从而分而治之、逐步求解；
- 自我反思（Self-Reflection）：大语言模型会对过去的规划和执行进行自我反思，分析其中的错误，并对后续的思考和规划进行改进，完善最后输出的结果。
Memory 记忆：记忆是对大语言模型本身由模型结构和参数所蕴含知识的补充，记忆又可以分为短期记忆和长期记忆：
- 短期记忆，即大语言模型的上下文学习，包括提示、指示、前序步骤的大语言模型推理结果和工具执行结果等；
- 长期记忆，即外部可快速检索的向量索引 ，这也就是目前比较流行的一种大语言模型应用的解决方案------RAG（Retrieval-Augmented Generation，检索增强生成）。RAG的流程可以简单概括为，将包含知识的文档切分为块，并对块向量化，构建块向量索引，然后将问题也向量化，然后从块向量索引中检索和问题相关的块，最后将块和问题合并作为大语言模型的输入进行推理。RAG可以有效缓解大语言模型无法扩展知识、由知识局限产生的"幻觉"的问题。
Tool 工具 ：工具作为Agent的感官和四肢 ，Agent一方面可以通过工具获取外部的各种信息用于进一步的思考和规划，例如通过搜索引擎搜索某个关键词的最新信息，另一方可以通过工具执行动作对外部环境施加影响，例如调用外部系统的接口执行指令并获取执行结果。

另外，在《A Survey on Large Language Model based Autonomous Agents》论文综述中，另外提出画像（Profile）组件进行限定人设，即system prompt，用于引导LLM解决某类特定问题。

Agent 协议生态三部曲：MCP、A2A 与 AG-UI

4.1 从 Prompt 到 Function Calling：最早的调用协议尝试

大模型工程化初期，开发者主要依赖 Prompt + 文本解析：模型输出格式化文本，后端用正则提取参数执行。方式灵活，但稳定性差、解析困难。
2023 年，OpenAI 推出 function Calling，首次在 API 层将工具调用标准化。通过 JSON Schema 描述函数，模型可自动生成结构化参数，极大提升了调用可靠性与开发效率。

Function Calling 的能力边界

Function Calling 虽标准化了解析接口，但其能力仅限于"单步函数调用"，在以下方面存在系统性短板：

- 无法处理 多工具间的动态调度；
- 缺乏 任务状态追踪与历史上下文管理；
- 无 权限控制、作用域隔离机制；
- 缺少 工具注册与能力发现标准；
- 无法支持插件生态的统一协议对接。

随着 Agent 系统复杂度提升，Function Calling 无法承载智能体系统中的任务分发、工具链集成与上下文共享需求。

4.2 MCP：智能体与系统之间的统一调用协议层

MCP（Model Context Protocol） 正是在这一背景下诞生，它的核心定位是：为 LLM 驱动的智能体提供 统一的系统交互协议层，就像互联网的 TCP/IP，或浏览器的 DOM 标准。

- 基于 JSON-RPC 2.0 的标准通信通道（支持 SSE / 本地）；
- 对工具（Tool）、资源（Resource）、提示（Prompt）进行模块化建模；
- 支持工具能力声明、动态发现、权限控制、使用追踪；
- 统一管理 LLM 与系统之间的数据流、调用流、上下文流。

4.2.1 为什么"现在"才有 MCP：因为模型足够强了

MCP 的成立并非偶然。它的落地价值必须建立在一个关键前提之上：

模型必须具备"多步任务规划、工具调用决策、上下文管理"的能力，才能支撑起 MCP 这样一套复杂协议栈的运行。

换句话说，MCP 是"模型能力增强"后系统响应层的必然产物：

- 在 GPT-3 时代，模型尚难以自主规划任务或使用多个工具；
- 到 GPT-4 / Claude 3 / DeepSeek-V2 时代，模型已能执行反复推理、任务分解、动态调用，并结合工具结果调整下一步动作；
- 此时，开发者急需一种机制，能支撑 LLM 在长时间、多工具、强上下文的任务执行过程中保持稳定、可控、可追踪 ------ 这正是 MCP 所解决的。

MCP 的意义不仅在于标准化调用链，更在于构建出一种 Agent 与外部系统之间的工程化协作范式。

4.2.2 Function calling和MCP对比

MCP（Model Context Protocol）与传统的 Function Calling 在AI与外部系统交互的设计理念、应用场景和技术实现 上有显著差异，在定位上MCP是端到端的标准化协议框架，function calling是单点技术能力（模型级功能）

	MCP	Function Calling
性质	协议	功能
范围	覆盖通信协议、资源管理、工具调用、安全控制等全链路	聚焦于模型调用外部函数的交互逻辑
设计目标	解决AI与异构系统的通用集成问题	增强模型单次调用的功能性扩展
通信能力	基于JSON-RPC 2.0，支持SSE/stdio	无独立协议，依赖HTTP API封装
资源管理	通过root定义虚拟化数据访问路径	无原生资源管理能力
工具调用	支持动态发现、权限控制、多工具协同	静态函数声明，需硬编码参数
上下文感知	结合实时数据更新（如数据库变更通知）	依赖对话历史，无法感知外部状态

4.2.3 MCP 架构与运行机制概览

1. 架构角色定义

MCP（Model Context Protocol） 是面向 LLM 驱动智能体系统设计的一套标准通信协议，核心采用 Client-Server 架构：

MCP Host：发起任务的主控端（如 ClaudeDesktop、IDE 插件），扮演轻量 AI Agent 角色；
MCP Client：与服务器保持 1:1 连接的协议客户端
MCP Server：注册和暴露工具能力的服务程序，可访问本地资源或远程服务。

MCP Server 可访问本地文件、数据库，也可桥接远程 API，是 LLM 与外部系统之间的标准执行接口。

本地数据源 ：MCP 服务器可以安全访问的您的计算机文件、数据库和服务

远程服务：MCP 服务器可通过互联网（例如通过 API）连接到的外部系统

2. 协议能力模型

MCP Server 需声明三种核心能力模块：

模块类型	描述
Resources	可读写的数据源（文件、数据库等）
Tools	可执行的能力接口（如搜索、API、推理）
Prompts	任务场景提示或系统约束语

3. 执行流程简述

MCP 的工作流程如下：

能力声明：Server 注册其提供的工具与资源；
动态发现：Host 可查询 Server 能力描述；
统一调用：LLM 通过 Client 发送标准调用请求；
结果回传：Server 执行任务并返回结构化结果。

📌 MCP 的设计核心是让 LLM 像"操作系统进程"一样，通过通用协议调用系统中的各种"插件"，支持任务驱动的自动化编排。

接入MCP列表：github.com/modelcontex...、mcp.so/

github.com/modelcontex...、modelcontextprotocol.io/introductio...

4.2.4 MCP demo

Vscode的插件Cline安装DALL-E和git tools server为例：

同时编写一个简易的MCP demo，通过客户端cline就可以访问到mcp的tool（例如简单编写了访问lingxi-websearch）

fast-agent.ai/、github.com/liaokongVFX...

Agent系统的架构的持续演进

x.com/GPTDAOCN/st...

5.1 Multi-Agent的持续演进

随着应用越来越复杂，基于大语言模型的大模型智能体也在向多智能体的协同进行演进，由各个智能体各司其职、分工协作来共同完成任务。

多智能体强调多样化的智能体配置、智能体间的交互和集体决策过程，这使得多个自主智能体能够通过合作解决更动态和复杂的任务。

arxiv.org/abs/2402.01...

5.2 多智能体的整体架构

智能体和环境的交互（Agent-Environment Interface）；
- 沙箱环境（Sandbox）、物理环境（Physical）、无环境（None）
智能体画像构建（Agents Profiling）；
- 预先定义（Pre-Defined）、模型生成（Model-Generated）、数据衍生（Data-Derived）
智能体间的通信（Agents Communication）；
- 通信范式：合作、竞争、辩论
- 通信结构：中心化、去中心化、分层、共享消息池
- 通信内容：文本、代码等

智能体能力获取（Agents Capabilities Acquisition）。
- 三类反馈：环境、Agent、Human-in-the-loop
- 三种进化方式：
- - 记忆（Memory）
  - 自我进化（Self-Evolution）
  - 动态生成（Dynamic Generation）
- 结合 MAPE-K 控制循环（监控、分析、规划、执行、知识），用于增强系统自主性和自我意识，在多智能体系统研究中被广泛应用和改进

5.3 A2A 协议：Agent 间通信的标准化方案

2025 年 3 月，在 MCP 协议走红的同时，Google 提出了 A2A（Agent-to-Agent）协议，作为其补充。

MCP 解决的是 Agent 与外部工具/数据的调用与集成；
A2A 则致力于不同 Agent 之间的通信、任务委派与能力发现，即"Agent 的协作语言"。

📌 类比比喻：

MCP 更像是"操作系统调用接口"，每个 Agent 可通过它稳定接入结构化工具完成具体任务；
A2A 则是"Agent 层的网络协议"，使不同 Agent 之间可以发现彼此、共享能力、协同完成跨职能任务。

agent2agent.biz/

github.com/google/A2A

5.3.1 A2A 的重要意义与设计理念：

跨平台互通（Interoperability） ：通过标准化消息协议，连接不同框架和供应商构建的智能体，支持远程 Agent、本地 Agent 及人类用户之间的交互。
复杂任务分工（Complex Workflows） ：支持任务的委托、拆解与协作执行，解决单一智能体无法胜任的复杂场景。
安全隔离（Secure & Opaque） ：智能体间无需暴露工具调用逻辑或内部内存即可协作，保障数据安全与商业机密。
与 MCP 协同互补：MCP 负责工具连接，A2A 负责 Agent 协作，两者共同构成 Agentic 应用的协议底座。

标准化消息格式：定义统一的任务、回应、状态结构；
发现机制（Discovery Mechanism） ：通过 Agent Card 公开能力；
任务委派框架：支持任务划分与多 Agent 执行；
能力广告（Capability Advertisement） ：Agent 互相发布能力信息，建立服务市场；
访问控制与安全机制：权限管理与交互审计，保障通信安全。

5.3.2 A2A 三类核心角色：

User：用于认证与权限确认；
Client Agent：发起任务者；
Server Agent：任务执行者。

5.3.3 A2A 工作流程：

发现阶段 ：客户端从 /.well-known/agent.json 获取 Agent 能力卡片（Agent Card）；
启动任务：
- 即时任务：使用 tasks/send 发起一次性请求；
- 长期任务：使用 tasks/sendSubscribe 建立 SSE 流式响应；
任务处理：Server 解析任务并执行；
交互更新（可选） ：如任务状态为 input-required，可追加消息参与；
任务完成 ：Server 端返回 completed、failed 或 cancelled 状态。

🔍 该流程支持从简单调用到多轮任务协同的场景，特别适用于多模态、多阶段、多 Agent 协作系统。

5.3.4 MAS + A2A 的挑战与现实：

尽管 MAS 是未来趋势，但截至 2025 年，其落地仍受限于：

- 协同推理缺乏稳定支持（成功率常低于 50%）；
- 系统设计复杂，行为不可预测，调试与控制困难；

因此，A2A 协议目前更多用于研究场景，在生产环境中的广泛应用尚需时日。

5.3.5 A2A demo

例如：github.com/a2aproject/...

这里以旅行社场景中的多代理协作 samples/python/agents/a2a_mcp作为例子，进行分析：

文件/目录描述

agent_cards/ ：此目录存储每个 A2A 代理卡的 JSON 模式。这些卡片定义了系统中不同代理的身份、功能和端点。MCP 服务器负责处理这些卡片，*_agent.json

例如：

json 复制代码

{
    "name": "Air Ticketing Agent",
    "description": "Helps book air tickets given a criteria",
    "url": "http://localhost:10103/",
    "version": "1.0.0",
    "capabilities": {
        "streaming": true,
        "pushNotifications": true,
        "stateTransitionHistory": false
    },
    "defaultInputModes": [
        "text",
        "text/plain"
    ],
    "defaultOutputModes": [
        "text",
        "text/plain"
    ],
    "skills": [
        {
            "id": "book_air_tickets",
            "name": "Book Air Tickets",
            "description": "Helps with booking air tickets given a criteria",
            "tags": [
                "Book air tickets"
            ],
            "examples": [
                "Book return tickets from SFO to LHR, starting June 24 2025 and returning 30th June 2025"
            ]
        }
    ]
}

src/a2a-mcp: A2A 与 MCP 示例的核心代码

agents:

common:公共代码。

mcp：mcp的client、server实现。

tarvel_agency.db

技术关键词：python、A2A、MCP、Agent Card

AG-UI 协议：连接 Agent 与界面的事件感知系统

6.1 为什么需要 AG-UI？

随着 AI Agent 从命令行工具逐步走向图形界面、浏览器插件、移动端助手等交互密集场景，传统模型-工具调用范式（如 MCP）难以覆盖用户与 UI 层之间的实时交互需求。这一缺口催生了新型协议的诞生------AG-UI（Agent-User Interaction Protocol）。

AG-UI 由 CopilotKit 团队于 2025 年 5 月发起并开源，旨在建立一套开放、标准、实时的事件驱动通信协议，让 AI Agent 能够感知用户行为、输出流式信息、控制组件状态，从而实现真正的前后端双向交互。

它标志着 Agent 能力从工具调用走向界面级协作，补齐了 UI 感知与用户交互这一关键链路......

"AG-UI 标准化了前端如何通过开放协议连接 AI Agent，可视为 AI 驱动系统的通用翻译器。"

------CopilotKit 团队

6.2 工作机制：事件驱动的交互闭环

AG-UI 并非传统的接口协议，而是一套围绕"事件流"的交互标准。其典型工作流程如下：

1. 客户端通过 REST API 发起 Agent 请求；
2. 服务端基于 SSE/WebSocket 创建事件流通道；
3. Agent 在执行任务过程中，按步骤推送事件（如 TEXT_MESSAGE、TOOL_CALL 等）；
4. 前端监听并解析事件流并实时渲染；
5. 若任务需要用户参与或有补充操作（如 input_required），可通过事件反向反馈给 Agent（如按钮点击、文本输入）；
6. Agent 接受反馈，并继续事件推送，直到完成。

这一机制实现了"模型执行过程 × 用户实时输入 × 界面状态联动"的闭环交互。

在AG-UI 协议中最核心的部分在于事件的定义：

- 文本消息事件（TEXT_MESSAGE_）用于实时流式文本生成；
- 工具调用事件（TOOL_CALL）用于完整的工具调用生命周期管理；
- 状态管理事件（STATE）用于状态同步，确保客户端和服务端状态一致；
- 生命周期事件（RUN* / STEP_）进行执行控制，管理整个代理执行的生命周期；

AG-UI 协议的事件类型定义体现了 AI Agent 系统的核心需求：流式处理、状态管理、工具集成、错误处理、可扩展性。协议的设计既考虑了技术实现的效率，也兼顾了用户体验的流畅性，是现代 AI 应用系统设计的重要参考。

6.3 协议机制与核心能力

AG-UI 的设计理念是以"事件"为最小交互单位，基于通用传输协议（如 SSE、WebSocket、Webhook）实现端到端的低延迟通信。其事件模型覆盖了从文本生成、工具调用到界面状态更新的全流程，并允许用户实时介入 Agent 决策链路。

核心能力	说明
实时事件推送	基于流式协议（如 SSE/WebSocket）传输轻量事件，支持毫秒级 UI 响应
UI 状态同步	Agent 可感知并更新前端组件状态，如按钮启用、表单内容变化等
工具调用集成	支持完整生命周期事件（TOOL_CALL_START/END/ERROR），与工具系统协同
用户主动介入	通过 `input_required` 等事件暂停流程，等待用户确认或补充信息
生命周期控制	提供 `RUN_STARTED` / `RUN_ENDED` 等事件标记任务边界，实现任务编排与回溯

这些能力并非分立存在，而是通过一整套 结构化事件模型 串联起来，构成了 AG-UI 的通信基础。

事件体系：让交互更细腻、更确定

AG-UI 协议当前共定义 16 种标准事件类型，被划分为五大类：

事件分类	用途
Lifecycle Events（生命周期事件）	表示 Agent 运行的开始与结束（RunStarted、RunFinished、RunError）
Text Message Events（文本消息事件）	支持流式文本消息生成与展示（Start、Content、End）
Tool Call Events（工具调用事件）	管理工具调用的全流程（Start、Args、End、Result）
State Management（状态同步事件）	UI 状态的快照与增量同步（StateSnapshot、StateDelta）
Special Events（特殊事件）	外部系统集成、自定义事件扩展（Raw、Custom）