大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



 
  
    
     
本文深入介绍了Agent智能体的概念、发展历程及其关键技术，阐述了Agent如何从简单的文本交互进化为能够自主完成任务的目标导向系统。文章重点解析了推理能力、行动能力（工具调用）以及Agent设计范式（如ReAct、Plan-and-Execute），并探讨了Context Engineering和A2A协议在构建高效、可扩展的Agent系统中的重要性。通过这些关键技术的融合，Agent能够更好地感知环境、自主决策并执行任务，标志着AI从被动响应向主动执行的转变。
 

我们先来看下Wikipedia中Agent智能体的定义：

在人工智能领域，智能体（Intelligent Agent）是一个能够感知环境、自主采取行动以实现目标，并通过机器学习获取知识来提升其性能的实体。

从这个定义可以提炼出Agent的几个关键能力：感知环境（Perception）、自主决策（Autonomy）、执行行动（Action）、自主进化（Self-evolution）。Agent运行过程如下图所示：

其实Agent的概念并不是最近才出现，也并不是大模型时代的产物。在过去很长一段时间，AI领域已经存在大量关于Agent的研究，其中最典型的就是基于强化学习RL来训练一个的Agent，我们可以将AlphaGo看作是一个强化学习驱动的只能在特定环境（围棋）工作的专用Agent。

随着生成式AI和大语言模型LLM的出现，Agent开始进入一个新的阶段。很多研究开始思考：是不是可以让大语言模型LLM来充当Agent的『大脑』呢？虽然大语言模型具有强大的文本生成、理解和推理能力，但有个问题：LLM无法直接的感知和改变外部环境。

如何理解这里所说的『感知和改变环境』呢？我们举例来说明：假设你要实现一个网页版的贪吃蛇游戏，LLM只能根据你的需求给你生成对应的代码，如果想要真正的运行对其测试，这时你只能手动复制代码到本地并在浏览器中执行；如果想继续修改并完善程序，你还需要将相关代码以及对应的问题手动输入提供给LLM，也就是LLM能获取的信息全部来自于你提供的输入信息，这就是典型的大语言模型无法感知和改变外界环境的表现。

那有没有办法解决这个问题呢？其实是有的，我们只需要给LLM接上外部工具即可（关于LLM如何调用外部工具，我们会在下面进行介绍，大家先理解概念就行），比如：查看文件列表的工具、文件读写的工具以及运行终端命令的工具，工具就像大语言模型的"眼睛"和"双手"，有了工具LLM就能感知和改变外部环境了。试想一下，如果有了以上工具之后，LLM是不是就能自己『写代码 -> 运行 -> 调试 -> 再修改』我们的程序了，这个过程完全不需要人类参与，完全实现了自动化。

基于这个思路，为了让LLM驱动的Agent可以自主完成目标任务，LLM不仅需要能够接入一系列外部工具，还必须具备以自我驱动方式进行任务规划与执行的能力（即逻辑推理能力）。当推理能力、逻辑能力以及对外部信息的访问与LLM相结合时，就形成了“智能体（Agent）”这一概念。

从最基础的角度来看， Agent智能体可以理解为一种应用系统：它通过观察外部世界，并借助自身可用的工具采取行动，从而实现既定目标。智能体具有自治性，在被赋予明确目标或任务时，能够在无需人类干预的情况下独立运行。同时，它们在实现目标的过程中也具备主动性——即使没有人类提供明确的指令，智能体也可以通过推理判断下一步该做什么，以逐步达成最终目标。

从工程角度来看，一个Agent智能体通常由以下部分组成：

• 大语言模型（大脑）：是Agent的核心推理中枢，负责对任务进行理解、推理和决策；
• Tools（双手）：用于将推理能力转化为实际行动，帮助Agent与外部世界交互；
• Orchestration（神经系统）：作为调度与控制中枢，负责管理整个Agent运行流程，包括任务规划、状态记忆和推理任务执行等。

Agent智能体架构图如下所示：

总结一下，Agent智能体的本质就是能够感知环境、进行推理、调用工具并自主完成任务的智能系统。在生成式人工智能的浪潮中，Agent的落地标志着AI：

从『输入文字、输出文字』的 ChatBot，

演进为了『输入目标、输出结果』的 Autonomous Agent。

目前大部分Agent还是基于特定行业场景领域构建的垂类Agent，比如像Cursor和Claude Code为代表的Coding Agent以及常用的客服Agent、数据分析Agent等等；当然现在也有很多现象级的通用Agent产品出现，例如Manus、GenSpark，以及最近比较火的OpenClaw。

在Agent发展的关键技术中，一个重要方向就是大语言模型LLM『认知能力』的提升，这主要体现在两个方面：推理能力（Reasoning）与行动能力（Acting）。

一方面，推理能力的提升以思维链（Chain-of-Thought，CoT）技术为代表，特别是长思维链（Long CoT），使大语言模型能够进行多步推理，从而更好的完成任务理解、规划与决策。

另一方面，行动能力的增强则依赖于工具调用（Tool Calls）机制，其中OpenAI提出的Function Calling是一种典型的实现方式，通过这一机制，大语言模型能够基于工具描述完成工具选择，并自动生成调用参数，从而实现对外部环境的实际操作。

下面我们分别对大语言模型的推理能力和行动能力进行详细介绍。注意：这里的视角都是针对大语言模型的。

推理能力Reasoning

针对大语言模型，我们提到推理能力，大家都会想到以OpenAI O系列以及DeepSeek R1为代表的Reasoning Model，它们一般被称为深度思考模型，这个思考的过程就叫做推理（Reasoning）。

目前，我们认为构建Reasoning Model方法大概有以下4种：

• 基于Few-shot/Zero-shot CoT InContext Learning；
• Structured Reasoning 结构化推理链；
• Reinforcement Learning 强化学习；
• 知识蒸馏SFT微调；

Chain-of-Thought（CoT）

CoT是2022年发布的论文 Chain-of-Thought Prompting Elicits Reasoning in Large Language Models 中提出的一种用于提升大语言模型推理能力的技术，其核心思想是：让模型把“中间思考过程”一步一步表达出来，而不是直接给出最终答案。CoT的本质是一种InContext Learning（上下文学习），通过在Prompt中提供Few-shot或者Zero-shot（Let’s think step by step）示例来诱导模型进行『多步推理』，以此把复杂问题拆分成多个简单步骤，显著提升模型的推理能力和可解释性。

Structured Reasoning

结构化推理链（Structured Reasoning）是指：将原本“线性”的思维链CoT，扩展为“多路径、可评估、可搜索”的推理过程，通过多路径的探索以及对中间结果的评估以此来提供全局最优的推理结果。常见的方法包括：Self-Consistency、Tree-of-Thought（ToT）等，这部分大家可以自行研究。

Reinforcement Learning，RL

基于强化学习对模型进行Fine-tuning也可以使模型展现出卓越的推理能力

DeepSeek-R1的训练过程如下（大家了解就好）：

知识蒸馏SFT微调

同时在DeepSeek-R1的论文最后也提到，基于DeepSeek-R1可以将Reasoning能力蒸馏到更小的Dense模型中。以Qwen2.5-32B作为基础模型，直接从DeepSeek R1进行蒸馏，蒸馏后模型的表现优于对齐并进行强化学习的模型，这表明大型基础模型发现的推理模式对于提升推理能力至关重要。

 特别说明：

其实构建Reasoning Model的这几种方式之间并不是互斥的，这一点从DeepSeek R1的训练过程就可以看到，其训练过程就包括了强化学习RL和SFT监督微调，同时在训练资料的构造中同样使用了CoT InContext Learning的方式。

工具调用Tool Calls

工具调用（也称函数调用）为大语言模型LLM提供了一种强大且灵活的方式，使其能够与外部系统交互，并访问训练数据之外的信息。其中Function Calling是由OpenAI在2023年6月首次提出，被作为工具调用实现的一种事实规范。

Function Calling

Function Calling是一种机制，它让大语言模型能够理解用户意图，并请求外部系统执行特定操作，而不是直接生成最终答案。其核心价值在于，它让模型能够自主决定“何时”以及“如何”使用外部工具来完成任务。

在介绍Function Calling运行过程之前，先来理解和对齐几个关键概念：

Tools（工具）

这里讲的工具也称为函数（Function），是我们赋予模型新的可以访问的"能力"。

当模型在生成回复时，它可能会判断需要使用某个工具来获取数据或执行操作。例如我们可以提供如下工具：获取天气预报、查询某个账户信息、处理订单退款或任何我们期望模型具备的新的能力。

Tool Calls（工具调用）

工具调用是模型的一种"特殊响应形式"。

当模型认为需要调用工具时，它会响应返回对应的工具调用请求及其参数。例如我们输入：北京天气怎么样？这时模型可能返回：调用get_weather(location=“北京”) 。（这里只是示例，真正的Schema见下文）

Tool Call Outputs（工具调用输出）

工具调用输出是Tool Calls指定的工具被真正调用后返回的结果，通常以结构化JSON或纯文本表示。

比如：get_weather(location=“北京”) 工具调用后返回结果：{“temperature”: “25”}。

基于Function Calling的大语言模型交互过程如下：

1. 用户发起请求到应用程序；
2. 应用程序向模型发起请求，在请求中携带工具列表及其描述（Tool Definitions）；
3. 如果模型判断需要调用工具，会响应Tool Calls返回工具及其参数给应用程序，请求调用工具；
4. 应用程序基于Tool Calls响应信息，调用工具并得到工具输出结果；
5. 应用程序重新向模型发起请求，其中携带工具输出结果；
6. 模型基于历史消息以及工具调用结果生成最终的结果返回应用程序；
7. 应用程序将最终结果返回用户。

其中步骤2、3、5是Function Calling定义工具调用的关键实现，我们可以理解，如果一个模型能够解析工具列表、能够选择工具并给出调用参数、能够解析工具输出结果，那我们就说这个模型具有Function Calling的能力。

在Function Calling的规范中，Tool Definitions基于Input Json Schema协议定义，并在每个API请求的tools参数中声明。例如工具get_weather的定义如下所示：

在模型决定调用某个工具时，会返回Tool Calls响应，其中type定义为function，如下所示：

最后客户端应用程序在工具调用完成后会再次发起请求，请求信息包括：历史消息以及工具调用输出，如下所示：

 特别说明：

我们知道大语言模型能做的事只有文字接龙，并不具备真正的工具调用能力，所以大语言模型学会的是在适当的时候生成"调用工具的文本结构描述"，其本质还是文字接龙。工具调用一般需要由应用程序自行实现，这部分不在Function Calling定义的范畴内。

以上就是Function Calling的整体运作过程，通过在API请求体中携带tools列表，这样模型就能在需要的时候在可用的工具列表中选择适当的工具来解决用户的问题。可是大模型是怎么学会使用工具的呢？

其实要让大语言模型学会"工具调用"这件事情，答案还是训练和微调。在介绍SFT微调阶段时提到过，要让模型学会调用工具，需要在微调数据中扩展对应"工具调用"相关的人工标注示例。在实践中，不仅是SFT微调阶段，在Pre-train阶段以及RLHF阶段，都会重点关注模型使用工具的能力。大家如果感兴趣可以看下早期Meta发表的论文 Toolformer: Language Models Can Teach Themselves to Use Tools。

到这里，我相信你已经了解了Function Calling是如何运作的，从这个角度来看，Function Calling统一了应用程序和大语言模型之间关于"工具调用"的规范，再次强调一下，Function Calling统一的是应用程序和大语言模型这条链路上关于"工具调用"的规范。但是在整个链路上还有很多问题Function Calling并没有涉及，比如：

• Tool工具的实际调用在Function Calling中没有明确定义，意味着每个应用程序客户端都需要对接不同的Server？
• Tools工具列表需要每一个应用程序自行维护，是否可以使用注册与发现的机制来动态维护呢？
• Tool Definition中关于工具定义的信息需要应用程序手动维护，是否可以基于工具函数的定义自动生成呢？
• …

那这些问题如何解决呢？答案就是MCP协议，接下来我们来看看MCP是如何解决这些问题的。（从这个角度大家应该可以看到，其实Function Calling和MCP解决的是不同方面的问题，所以网上关于MCP完全替代了Function Calling的说法是完全错误的，他们之间本质上是互相补充的关系。）

Model Context Protocol（MCP）

“N x M”集成问题与标准化的需求：

我们知道，工具调用是应用与外部世界交互的关键机制。然而，随着可接入的工具、数据源以及服务接口不断增多，系统集成的复杂度迅速上升。在缺乏标准化的情况下，每一个应用都需要为每一个外部工具单独开发接入逻辑，从而形成所谓的 “N × M 集成问题”：当系统中存在 N 个应用和 M 个工具时，理论上需要维护 N × M 条独立的集成链路。

为了解决这一问题，Anthropic 在 2024 年 11 月推出了 Model Context Protocol（MCP）作为开放标准。MCP 的初衷是用统一的即插即用协议取代零散的定制集成，作为应用与庞大外部工具和数据之间的通用接口。通过标准化这层通信，MCP 可以将应用与工具的具体实现细节解耦，从而打造一个更模块化、可扩展且高效的生态系统。

MCP 采用 Server-Client 架构，将应用与工具集成分离，使工具开发更模块化、可扩展。MCP 的核心组成包括 Host、Client 和 Server。

MCP Host 是负责创建和管理各个 MCP Client 的应用，主要职责包括管理用户体验、协调工具使用，以及执行安全策略和内容防护。 我们平时使用的Claude Code、Cursor、Cline、Cherry Studio等平台，都可以理解为是MCP Host，其实就是我们所使用的AI Application或Agent。

MCP Client是嵌入在 MCP Host 中的一个组件，保持与 MCP Server 的连接，负责发送命令、接收响应，并管理与 MCP Server 的通信会话。

MCP Server 提供了开发者希望AI应用 或 Agent 可插拔使用的能力，通常作为外部工具、数据源或 API 的代理适配器实现，它的主要职责包括发布可用工具、接收并执行命令、格式化并返回结果。在企业场景中，MCP Server 还负责安全、扩展性和治理相关的能力。

各个组件的相互关系如下图所示：

MCP Client 与 Server 之间的所有通信都建立在标准化技术基础上，以确保一致性和互操作性。

基础协议：MCP 使用 JSON-RPC 2.0 作为基础消息格式，提供轻量、基于文本且与编程语言无关的通信结构。

传输机制：MCP 需要标准化的传输协议，保证 Client 与 Server 之间正确理解消息。MCP 支持两种传输方式：

• stdio（标准输入/输出）：用于本地环境的快速通信，当 MCP Server 作为 Host 的子进程运行时使用。适合工具访问本地资源，如用户文件系统。事实上目前大部分的MCP Server都是基于node或python实现本地程序，其通信协议都是基于stdio。
• 可流式 HTTP（Streamable HTTP）：推荐用于远程通信的协议，支持 SSE 流式响应，同时允许无状态服务器，可在普通 HTTP 服务器上实现，无需 SSE 支持。

基于MCP和Function Calling的大语言模型整体交互过程如下所示：

1. 用户在应用程序中配置要使用的MCP Server；
2. 配置保存之后，应用程序会主动和MCP Server交互进行初始化，首先调用intialize方法，类似于TCP/IP的三次握手过程，建立连接后会调用tools/list方法获取MCP Server的工具列表，MCP会返回对应工具的Tool Definitions，这样初始化过程就完成了；
3. 用户发起请求到应用程序；
4. 应用程序向模型发起请求，在请求中携带工具列表及其描述（Tool Definitions）；
5. 如果模型判断需要调用工具，会响应Tool Calls返回工具及其参数给应用程序，请求调用工具；
6. 应用程序基于Tool Calls响应信息，调用tools/call方法请求MCP Server对应的工具；
7. MCP Server执行后返回结果给应用程序；
8. 应用程序重新向模型发起请求，其中携带工具输出结果；
9. 模型基于历史消息以及工具调用结果生成最终的结果返回应用程序；
10. 应用程序将最终结果返回用户。

其中步骤1、2、6、7是MCP协议中明确定义的部分，下面我们来看下MCP交互过程中的具体协议实现。

这里我们以Cline插件作为我们的Host，大语言模型使用deepseek v3.2，并基于MCP官方示例实现一个weather MCP Server，为了能看到具体的交互协议过程，我们在Cline和weather之间增加一个log_proxy用于打印交互协议。首先我们在Cline中配置weather：

配置保存之后，Cline作为MCP Host会主动调用initialize方法初始化，这个过程类似TCP/IP的三次握手：

请求: { "method": "initialize", "params": { "protocolVersion": "2025-11-25", "capabilities": {}, "clientInfo": { "name": "Cline", "version": "3.76.0" } }, "jsonrpc": "2.0", "id": 0 } 响应: { "jsonrpc": "2.0", "id": 0, "result": { "protocolVersion": "2025-11-25", "capabilities": { "experimental": {}, "prompts": { "listChanged": false }, "resources": { "subscribe": false, "listChanged": false }, "tools": { "listChanged": false } }, "serverInfo": { "name": "weather", "version": "1.26.0" } } } 请求: 

接下来Cline会主动调用tools/list方法获取工具列表，weather会返回工具get_weather的tool definition：

请求: { "method": "tools/list", "jsonrpc": "2.0", "id": 1 } 响应: }, "required": [ "location" ], "title": "get_weatherArguments", "type": "object" } } ] } } 

下面我们来尝试问一个问题：北京的天气怎么样？

从上图可以看到，DeepSeek在任务执行过程中决定需要调用weather MCP Server的get_weather工具，这时Cline会调用tools/call方法获取结果：

请求: }, "jsonrpc": "2.0", "id": 5 } 响应: { "jsonrpc": "2.0", "id": 5, "result": { "content": [ { "type": "text", "text": "{ "weather":"小雨", "temperature":10 }" } ], "isError": false } } 

到这里，你应该已经对工具调用（Tool Calls）的实现机制有了较为完整的认识。通过逐步分析，相信你应该理解了为什么在 Function Calling 提出之后还需要引入 MCP 协议。要实现一个Agent，除了推理能力（“大脑”）以及工具调用能力（“双手”），还需要能通过大脑指挥双手的机制（“神经系统”），也就是Agent的设计范式。

Agent设计范式

所谓『设计范式』就是Agent在执行任务时的一套『标准工作流程』。Agent设计范式中最简单、最常见也是应用最广泛的就是ReAct。如果要学习Agent的底层实现原理，那首先要了解的就是ReAct范式，那到底什么是ReAct呢？

ReAct范式

ReAct（Reasoning and Acting）是由Google于2022年10月在论文 ReAct: Synergizing Reasoning and Acting in Language Models 被提出，是一种人工智能推理与行动相结合的范式，用于提升大语言模型在复杂任务中的自主决策、可解释性和稳健性，已成为Agent构建的重要基础架构。

ReAct 通过显式的将“推理（Reasoning）”与“行动（Acting）”交替进行，使模型在每一步都生成自然语言的“思考”，然后调用工具或与环境交互，并将观察结果反馈到下一步推理中。其循环形式为：

观察 → 思考 → 行动 → 观察 → 思考 → 行动 …

这种机制让 LLM 不仅可以依赖内部推理，还能基于实时外部反馈调整计划，纠正错误，并在动态环境中维持任务进展。其运行过程如下所示：

那ReAct如何实现呢？其推理与行动交替进行的行为是LLM本身具备的能力么？其实这里的奥秘就在System Prompt的设计上。下面我们通过一个具体的例子来看下ReAct的实现过程。

这里为了快速演示我们直接基于DeepSeek实现，基于ReAct的System Prompt定义如下：

# 职责描述 你需要解决一个问题。 为此，你需要将问题分解为多个步骤。 - 对于每个步骤，首先使用 
  
    
    
      思考要做什么，然后使用可用工具之一决定一个 
     
       。 - 接着，你将根据你的行动从环境/工具中收到一个 
      
        。 - 持续这个思考和行动的过程，直到你有足够的信息来提供 
       
         。 — 所有步骤请严格使用以下 XML 标签格式输出： - 
        
          用户问题 - 
         
           思考 - 
          
            采取的工具操作 - 
           
             工具或环境返回的结果 - 
            
              最终答案 # 示例说明 示例1: 
             
               今天北京的天气如何？我该穿什么？ 
              
             
               我需要先获取北京当前的天气信息 
              
             
               调用天气API("Beijing") 
              
             
               天气：12°C，小雨 
              
             
               根据天气情况，气温较低且有雨，需要给出穿衣建议 
              
             
               生成穿衣建议 
              
             
               建议穿外套并携带雨伞，注意保暖和防水 
              
             
               今天北京气温约12°C，有小雨，建议穿外套并携带雨伞，注意保暖和防水。 
              # 可用工具 - read_file(file_path)：用于读取文件内容； - write_to_file(filename, content)：将指定内容写入指定文件，成功时返回"写入成功"； - run_terminal_command(command)：用于执行中断命令； # 注意事项 - 你每次回答都必须包括两个标签，第一个是 
             
               ，第二个是 
              
                或 
               
                 - 输出 
                
                  后立即停止生成，等待真实的 
                 
                   ，擅自生成 
                  
                    将导致错误 - 如果 
                   
                     中的某个工具参数有多行的话，请使用 来表示，如： 
                    
                      write_to_file("/tmp/test.txt", "a b c") 
                     - 工具参数中的文件路径请使用绝对路径，不要只给出一个文件名。比如要写 write_to_file("/tmp/test.txt", "内容")，而不是 write_to_file("test.txt", "内容") # 环境信息 - 操作系统：MacOS - 当前目录：/tmp/react/demo - 目录下文件列表：空 
                    
                   
                  
                 
                
               
              
             
            
           
          
         
        
       
      
    

接下来我们将System Prompt在DeepSeek中进行设置后，输入我们的任务：实现一个网页版贪吃蛇游戏。

这时DeepSeek返回对应的Thought和Action，这里需要调用工具write_to_file写入index.html文件。这时我们模拟调用工具，写入完成后我们回复：

写入成功。

这时DeepSeek开始继续新一轮思考，返回对应的Thought和Action（由于篇幅原因，我们省略了部分内容）：

接下来模型思考后要调用工具write_to_file写入style.css文件，我们继续模拟调用工具完成后回复：

写入成功。

DeepSeek继续思考并调用工具write_to_file写入script.js文件。

同样我们回复写入成功。。

最后DeepSeek思考后不再需要调用工具，返回了Final Answer，整个ReAct的过程就结束了。

如果你想基于ReAct实现一个Agent，这时需要你自行去解析LLM返回的结构化Thought、Action、Observation和Final Answer的内容，这里使用的是xml格式，针对你自己的场景可以自定义使用其他格式。具体实现我已经放到了github代码库中，大家可以阅读了解。

 有意思的是，ReAct论文的发表时间是早于ChatGPT的，所以从这个点可以看到，在LLM发展的早期阶段，大家已经开始非常积极的尝试基于LLM来构建Agent。

Plan and Execute范式

ReAct范式通过重复的『思考-行动-观察』循环构建Agent，这种方法利用了思维链（CoT），使LLM在每一步都能做出一个适合的行动决策。虽然这种范式对于简单任务是有效的，但明显存在以下问题：

• LLM在每一步只能针对一个子问题进行规划；
• 每次调用工具都需要进行一次LLM调用；

这可能导致Agent的执行效率不高以及执行的路径并非全局最优。

为了解决上述问题，可以引入一个显示的规划（Planning）步骤。目前主流的Agent比如Manus和Claude Code，其运行模式都是先规划再执行，在Agent规划时会生成一个待办列表或者Todos，这样的架构就是Plan-and-Execute。相较于ReAct范式，Plan-and-Execute这种范式可以让任务执行的更快、更省成本，而且效果也更好。其运行过程如下图所示：

Plan-and-Execute Agents 包含两个基本组件：

• Planer：在任务开始时，用于基于LLM规划（Plan）生成任务列表，同时实时监控任务状态并不断更新（Replan）任务列表；
• Executor：具体的执行Agent，接受任务列表中的任务，并调用1个或多个工具完成任务。

关于Plan-and-Execute的更多内容，可以参考LangChain的官方Blog介绍：Plan-and-Execute Agents。在文中还提出了ReWOO和LLMCompiler等Agent架构，以此来进一步加快Agent任务的执行速度。

Context Engineering

大家都知道大语言模型的本质就是在做文字接龙，那么大语言模型的训练过程就是在寻找一个函数，这个函数的输入就是Prompt，这个函数的输出就是要预测的下一个Token的概率分布，如下所示：

在实际使用过程中，模型的参数也就是 f 已经固定，如果发现预测的结果并不好，这个时候我们只能不断的尝试优化我们的输入Prompt x 以得到一个更好的结果。那对应的如何构建一个高质量的输入Prompt的技术就统称为Prompt Engineering。

其实从本质上我们可以认为Context Engineering和Prompt Engineering并没有什么区别，可以将其看作是Prompt Engineering的进化版本，但是这个过程会变动更复杂，这时的输入除了User Prompt以外，还包括System Prompt、对话历史信息、工具调用信息、外部信息、长短期记忆信息等等内容，这些内容就构成了模型的上下文Context。

总之，不管是Prompt Engineering还是Context Engineering，它们都是在做一件事情，就是在大语言模型的输入中如何动态的管理和构建适当的上下文信息，以此来生成我们期望的Token概率分布。

下面我们来看看随着大语言模型和Agent的不断发展，其上下文Context都包含了哪些重要信息？

从上图可以看到，在Agent框架中Context至少需要包括以下内容：

用于引导推理的上下文Context，定义了 Agent 的基本推理模式和可执行动作，决定其整体行为。

• System Prompt：定义 Agent 角色、能力和约束边界的高级指令；
• Tool Definitions：Agent 可调用的 API 或函数的模式定义，用于与外部世界交互；
• Few-Shot Examples：经过精心筛选的示例，通过上下文学习引导模型的推理过程。

证据性与事实性上下文Context，是 Agent 进行推理的核心数据来源，涵盖预存知识和针对特定任务动态检索的信息，作为 Agent 生成响应的"证据"。

• Long-Term Memory：跨多个 Sessions 积累的、关于用户或相关主题的持久化知识；
• External Knowledge：从数据库或文档中检索的外部信息，通常借助检索增强生成（RAG）技术实现；
• Tool Outputs：工具调用后返回的数据或结果；
• Sub-Agent Outputs：被委派特定子任务的专门 Agent 所返回的结论或结果；
• Artifacts：与用户或 Session 关联的非文本数据（如文件、图片等）。

即时对话信息上下文Context，将 Agent 锚定于当前交互场景，明确即时任务。

• Conversation History：当前交互的完整逐轮记录；
• User’s Prompt：用户提出的即时查询请求；
• State / Scratchpad：Agent 在即时推理过程中使用的临时信息或中间计算结果。

从这个角度，那如何对上下文Context进行有效的存储、管理、检索、组装的工程技术就是Context Engineering，Agent的效果好不好很大程度上依赖于高质量且聚焦的上下文Context。在构建 Agent 的过程中，最棘手的挑战之一是如何管理不断膨胀的上下文Context。理论上，具备大型上下文窗口的模型可以处理冗长的对话记录，但在实践中，上下文越长，成本和延迟就越高，此外，随着上下文不断增长，模型从中捕捉关键信息的能力会逐渐下降。

Context Engineering 在 Agent 每轮对话的运行循环中体现为一个持续推进的过程：

关于Context Engineering的更多内容我们会在后面进行介绍，本篇不进行展开，大家有兴趣也可以基于这个思路进行探索，也可以看看各个开源的Agent框架是如何解决这些问题的。其中一个思路就是构建Multi-Agent，下面我们先了解下在构建Multi-Agent的通信标准A2A协议。

Agent to Agent Protocol（A2A）

除了追求构建一个通用的“万能”Agent之外，我们还可以通过构建由多个专业化 Agent 组成的协作体系，来实现更复杂的任务处理。这种模式类似于现实世界中的团队协作：不同 Agent 各司其职，通过分工与协作共同完成目标。在这种架构下，Agent 之间可以相互调用，甚至可以将其他 Agent 抽象为一种“工具”来使用，从而实现能力的复用与组合。

然而，这种 Agent 间协作同样面临新的挑战：不同 Agent 可能基于不同的技术框架实现，并部署在不同的云环境或基础设施之上，导致其调用方式、接口协议及数据格式各不相同，从而增加了集成成本，限制了复用效率。为了解决这一问题，需要引入统一的标准化协议，对 Agent 之间的交互进行规范化。这正如 MCP 协议为工具调用提供统一接口一样，在 Agent 层面，也需要类似的标准——即 A2A 协议，以实现跨 Agent 的高效协作与互操作。

A2A协议是Google在2025年4月发布的开放标准，全称是 Agent-to-Agent 协议，顾名思义，这个协议提供了Agent与Agent之间通信与协作的标准规范。

在A2A协议中有3个核心参与者：User、A2A Client、A2A Server。

User用户作为任务发起方，可以是最终用户，也可以是其他服务。用户发起请求或定义需要一个或多个Agent协作完成的目标。

A2A Client（Client Agent）是一个应用程序、服务或另一个Agent，代表用户完成任务。Client是A2A通信的发起方。

A2A Server（Remote Agent）就是远端的Agent服务，通过A2A协议对外暴露了一个HTTP endpoint。Remote Agent接收来自Client Agent的请求，处理任务，并返回结果。从Client Agent角度来看，Remote Agent是一个黑盒，Client Agent并不了解其内部的工作原理和实现方式。

A2A协议同样使用 JSON-RPC 2.0 作为基础消息格式，提供轻量、基于文本且与编程语言无关的通信结构，其规范中各个参与者的交互方式如下：

A2A协议中定义的基本通信实体如下：

Agent Card：描述Agent的基本信息（包括：capabilities, endpoint, skills, and authentication），以JSON格式表示；

Task：Remote Agent根据Client Agent的请求生成的有状态的工作单元；

Message：Client Agent与Remote Agent通信承载信息的结构体；

Artifact：Remote Agent在任务执行过程中生成的产物（a document, image, or structured data）；

Part：Message或Artifact的基本内容容器。

基于A2A协议的整体交互过程如下所示：

1. 用户在应用中注册添加一个Remote Agent；
2. 注册提交之后，应用会作为Client主动与Remote Agent通信，通过GET /.well-known/agent-card方法获取Agent Card（在获取到Card后如果Remote Agent需要Authentication，这时还会与Auth Server通信进行鉴权，这部分在图中没有画出，大家知道就好），这样Remote Agent的注册就完成了；
3. 接下来应用会创建一个调度Agent，在A2A官方Sample中叫做Host Agent，用于对任务进行拆解和下发，后续调度Agent会作为Client Agent调用其他的Remote Agent执行任务，这部分不是A2A协议定义的部分。
4. 用户发起请求任务到应用程序；
5. 应用程序将任务委托给调度Agent进行处理；
6. 调度Agent拆解任务，调用send_message方法将任务交给Remote Agent执行；
7. Remote Agent执行后返回结果给调度Agent；
8. 调度Agent将最终结果返回给应用程序；
9. 应用程序将最终结果返回用户。

其中步骤1、2、6、7是A2A协议中明确定义的部分，下面我们来看下A2A交互过程中的具体协议实现。

这里我们以A2A官方a2a-samples项目中的demo作为我们的应用平台，在应用平台启动时会创建一个调度Agent（a2a-samples中定义为Host Agent）用于拆解和下发任务，同时我们会基于a2a sdk实现一个weather Remote Agent用于提供天气查询，整个交互流程如下所示：

首先我们在平台中先注册自定义的weather Remote Agent，其监听端口 10000。点击提交后，平台会作为Client Agent通过GET /.well-known/agent-card.json获取weather Remote Agent的Agent Card，其结果如下所示：

Agent Card的完整格式内容如下所示：

{ "capabilities": { "streaming": false }, "defaultInputModes": [ "text" ], "defaultOutputModes": [ "text" ], "description": "提供某地的天气预报", "name": "Weather Agent", "preferredTransport": "JSONRPC", "protocolVersion": "0.3.0", "skills": [ { "description": "给出某地的天气预报", "examples": [ "北京的天气怎么样？" ], "id": "天气预报", "name": "天气预报", "tags": [ "天气", "预报" ] } ], "url": "http://127.0.0.1:10000", "version": "1.0.0" } 

之后我们点击保存，这样就完成了Remote Agent的注册。之后我们可以启动一个对话，同样输入：北京的天气怎么样？等待一会儿显示了最终的结果，如下所示：

具体的执行链路大家可以参照上面的交互过程，这个任务首先会委托给调度Agent也就是Host Agent，由调度Agent对任务进行理解并拆解，并决定将任务交给weather Remote Agent进行处理。交互协议如下：

POST/HTTP/1.1 Host: 127.0.0.1:10000 User-Agent: python-httpx/0.28.1 Content-Length: 363 Accept: */* Accept-Encoding: gzip, deflate Content-Type: application/json { "id": "0a97a43d-cded-4ed2-a660-38331ba98976", "jsonrpc": "2.0", "method": "message/send", "params": { "configuration": { "acceptedOutputModes": [], "blocking": true }, "message": { "contextId": "1aae4ae6-a422-4e37-9cd9-d3c83a8a4d8e", "kind": "message", "messageId": "2b53cd71-c811-4d1a-81f5-2b786add98a7", "parts": [ { "kind": "text", "text": "北京的天气怎么样？" } ], "role": "user" } } } HTTP/1.1 200 OK date: Thu, 02 Apr 2026 06:33:58 GMT server: uvicorn content-length: 688 content-type: application/json ] } ], "contextId": "1aae4ae6-a422-4e37-9cd9-d3c83a8a4d8e", "history": [ { "contextId": "1aae4ae6-a422-4e37-9cd9-d3c83a8a4d8e", "kind": "message", "messageId": "2b53cd71-c811-4d1a-81f5-2b786add98a7", "parts": [ { "kind": "text", "text": "北京的天气怎么样？" } ], "role": "user", "taskId": "c-b02d-4ba3-8c4c-d31fc5658eba" } ], "id": "c-b02d-4ba3-8c4c-d31fc5658eba", "kind": "task", "status": { "state": "completed" } } } 

从A2A协议的定义中我们看到了Skill关键字，当然这个Skill和Agent Skill并不是一个东西，其实从Multi-Agent的角度来看，Remote Agent提供的能力同样也可以看成是一个Skill，可以理解为另一种按需调度的Skill。

以上就是本篇的所有内容，我们尝试从促进Agent进化的关键技术的角度来讲述了一个『输入文字、输出文字』的 ChatBot 是如何一步一步演进为今天『输入目标、输出结果』的 Autonomous Agent。下一篇我们会对Agent Skills进行整体介绍，来看看Agent Skills到底解决了哪些问题，为什么Agent Skills能成为今天Agent Infra的重要组成部分，敬请期待。

本篇文章相关代码可以从这里找到：

• https://github.com/goorstop-n/genai-tech-demo/tree/main
• https://github.com/a2aproject/a2a-samples/tree/main

2026 年春节前后，国内大模型迎来史无前例的集体爆发与同台竞技。短短不到一个月，主流厂商几乎全部登场：字节跳动 Seedance 2.0 刷屏科技圈，各大互联网公司纷纷推出 AI 红包新玩法，一场场精心准备的 “大模型春晚” 轮番上演，吸引无数 AI 爱好者围观喝彩。

大模型赛道竞争如此激烈，普通人到底该怎么入局，抢占未来 10 年的行业红利？

如果你还不知道从何开始，我特别整理了一套全网最全、最细的大模型零基础教程。我也是一路自学走过来的，太清楚小白前期学习的痛点：没人带、没方向、没资源，真的很难学进去！

下面这套资料，就是我专门为零基础、想转行、想提升的同学准备的全套学习方案。

扫码免费领取全部内容

从入门到实战，全套视频都整理好了，跟着学效率更高

2026 年最新行业报告，系统分析各行业现状、趋势、痛点与机会，帮你看清：哪些行业最适合落地大模型，哪里才有真正的机会。

【大厂 AI 岗位面经分享（107 道）】

【AI 大模型面试真题（102 道）】

【LLMs 面试真题（97 道）】

适用人群

四阶段学习规划（共90天，可落地执行）

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

  👇👇扫码免费领取全部内容👇👇

  

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】