收藏必备！小白程序员轻松入门大模型Agent，从ChatBot到Autonomous Agent的进阶之路

本文深入介绍了Agent智能体的概念、发展历程及其关键技术阐述了Agent如何从简单的文本交互进化为能够自主完成任务的目标导向系统。文章重点解析了推理能力、行动能力工具调用以及Agent设计范式如ReAct、Plan-and-Execute并探讨了Context Engineering和A2A协议在构建高效、可扩展的Agent系统中的重要性。通过这些关键技术的融合Agent能够更好地感知环境、自主决策并执行任务标志着AI从被动响应向主动执行的转变。一、什么是Agent智能体我们先来看下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发展的关键技术在Agent发展的关键技术中一个重要方向就是大语言模型LLM『认知能力』的提升这主要体现在两个方面推理能力Reasoning与行动能力Acting。一方面推理能力的提升以思维链Chain-of-ThoughtCoT技术为代表特别是长思维链Long CoT使大语言模型能够进行多步推理从而更好的完成任务理解、规划与决策。另一方面行动能力的增强则依赖于工具调用Tool Calls机制其中OpenAI提出的Function Calling是一种典型的实现方式通过这一机制大语言模型能够基于工具描述完成工具选择并自动生成调用参数从而实现对外部环境的实际操作。下面我们分别对大语言模型的推理能力和行动能力进行详细介绍。注意这里的视角都是针对大语言模型的。推理能力Reasoning针对大语言模型我们提到推理能力大家都会想到以OpenAI O系列以及DeepSeek R1为代表的Reasoning Model它们一般被称为深度思考模型这个思考的过程就叫做推理Reasoning。目前我们认为构建Reasoning Model方法大概有以下4种基于Few-shot/Zero-shot CoT InContext LearningStructured Reasoning 结构化推理链Reinforcement Learning 强化学习知识蒸馏SFT微调Chain-of-ThoughtCoTCoT是2022年发布的论文 Chain-of-Thought Prompting Elicits Reasoning in Large Language Models 中提出的一种用于提升大语言模型推理能力的技术其核心思想是让模型把“中间思考过程”一步一步表达出来而不是直接给出最终答案。CoT的本质是一种InContext Learning上下文学习通过在Prompt中提供Few-shot或者Zero-shotLet’s think step by step示例来诱导模型进行『多步推理』以此把复杂问题拆分成多个简单步骤显著提升模型的推理能力和可解释性。Structured Reasoning结构化推理链Structured Reasoning是指将原本“线性”的思维链CoT扩展为“多路径、可评估、可搜索”的推理过程通过多路径的探索以及对中间结果的评估以此来提供全局最优的推理结果。常见的方法包括Self-Consistency、Tree-of-ThoughtToT等这部分大家可以自行研究。Reinforcement LearningRL基于强化学习对模型进行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 CallingFunction Calling是一种机制它让大语言模型能够理解用户意图并请求外部系统执行特定操作而不是直接生成最终答案。其核心价值在于它让模型能够自主决定“何时”以及“如何”使用外部工具来完成任务。在介绍Function Calling运行过程之前先来理解和对齐几个关键概念Tools工具这里讲的工具也称为函数Function是我们赋予模型新的可以访问的能力。当模型在生成回复时它可能会判断需要使用某个工具来获取数据或执行操作。例如我们可以提供如下工具获取天气预报、查询某个账户信息、处理订单退款或任何我们期望模型具备的新的能力。Tool Calls工具调用工具调用是模型的一种特殊响应形式。当模型认为需要调用工具时它会响应返回对应的工具调用请求及其参数。例如我们输入北京天气怎么样这时模型可能返回调用get_weather(location“北京”) 。这里只是示例真正的Schema见下文Tool Call Outputs工具调用输出工具调用输出是Tool Calls指定的工具被真正调用后返回的结果通常以结构化JSON或纯文本表示。比如get_weather(location“北京”) 工具调用后返回结果{“temperature”: “25”}。基于Function Calling的大语言模型交互过程如下用户发起请求到应用程序应用程序向模型发起请求在请求中携带工具列表及其描述Tool Definitions如果模型判断需要调用工具会响应Tool Calls返回工具及其参数给应用程序请求调用工具应用程序基于Tool Calls响应信息调用工具并得到工具输出结果应用程序重新向模型发起请求其中携带工具输出结果模型基于历史消息以及工具调用结果生成最终的结果返回应用程序应用程序将最终结果返回用户。其中步骤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中没有明确定义意味着每个应用程序客户端都需要对接不同的ServerTools工具列表需要每一个应用程序自行维护是否可以使用注册与发现的机制来动态维护呢Tool Definition中关于工具定义的信息需要应用程序手动维护是否可以基于工具函数的定义自动生成呢…那这些问题如何解决呢答案就是MCP协议接下来我们来看看MCP是如何解决这些问题的。从这个角度大家应该可以看到其实Function Calling和MCP解决的是不同方面的问题所以网上关于MCP完全替代了Function Calling的说法是完全错误的他们之间本质上是互相补充的关系。Model Context ProtocolMCP“N x M”集成问题与标准化的需求我们知道工具调用是应用与外部世界交互的关键机制。然而随着可接入的工具、数据源以及服务接口不断增多系统集成的复杂度迅速上升。在缺乏标准化的情况下每一个应用都需要为每一个外部工具单独开发接入逻辑从而形成所谓的 “N × M 集成问题”当系统中存在 N 个应用和 M 个工具时理论上需要维护 N × M 条独立的集成链路。为了解决这一问题Anthropic 在 2024 年 11 月推出了 Model Context ProtocolMCP作为开放标准。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。可流式 HTTPStreamable HTTP推荐用于远程通信的协议支持 SSE 流式响应同时允许无状态服务器可在普通 HTTP 服务器上实现无需 SSE 支持。基于MCP和Function Calling的大语言模型整体交互过程如下所示用户在应用程序中配置要使用的MCP Server配置保存之后应用程序会主动和MCP Server交互进行初始化首先调用intialize方法类似于TCP/IP的三次握手过程建立连接后会调用tools/list方法获取MCP Server的工具列表MCP会返回对应工具的Tool Definitions这样初始化过程就完成了用户发起请求到应用程序应用程序向模型发起请求在请求中携带工具列表及其描述Tool Definitions如果模型判断需要调用工具会响应Tool Calls返回工具及其参数给应用程序请求调用工具应用程序基于Tool Calls响应信息调用tools/call方法请求MCP Server对应的工具MCP Server执行后返回结果给应用程序应用程序重新向模型发起请求其中携带工具输出结果模型基于历史消息以及工具调用结果生成最终的结果返回应用程序应用程序将最终结果返回用户。其中步骤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 } } } 请求: { method: notifications/initialized, jsonrpc: 2.0 }接下来Cline会主动调用tools/list方法获取工具列表weather会返回工具get_weather的tool definition请求: { method: tools/list, jsonrpc: 2.0, id: 1 } 响应: { jsonrpc: 2.0, id: 1, result: { tools: [ { name: get_weather, description: \nRetrieves current weather for the given location.\n\nArgs:\n location: city e.g. 北京上海.\n, inputSchema: { properties: { location: { title: Location, type: string } }, required: [ location ], title: get_weatherArguments, type: object } } ] } }下面我们来尝试问一个问题北京的天气怎么样从上图可以看到DeepSeek在任务执行过程中决定需要调用weather MCP Server的get_weather工具这时Cline会调用tools/call方法获取结果请求: { method: tools/call, params: { name: get_weather, arguments: { location: 北京, task_progress: - [x] 使用天气工具查询北京天气\n- [ ] 分析并展示天气结果 } }, jsonrpc: 2.0, id: 5 } 响应: { jsonrpc: 2.0, id: 5, result: { content: [ { type: text, text: {\n \weather\:\小雨\,\n \temperature\:10\n} } ], isError: false } }到这里你应该已经对工具调用Tool Calls的实现机制有了较为完整的认识。通过逐步分析相信你应该理解了为什么在 Function Calling 提出之后还需要引入 MCP 协议。要实现一个Agent除了推理能力“大脑”以及工具调用能力“双手”还需要能通过大脑指挥双手的机制“神经系统”也就是Agent的设计范式。Agent设计范式所谓『设计范式』就是Agent在执行任务时的一套『标准工作流程』。Agent设计范式中最简单、最常见也是应用最广泛的就是ReAct。如果要学习Agent的底层实现原理那首先要了解的就是ReAct范式那到底什么是ReAct呢ReAct范式ReActReasoning 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定义如下# 职责描述 你需要解决一个问题。 为此你需要将问题分解为多个步骤。 - 对于每个步骤首先使用 thought 思考要做什么然后使用可用工具之一决定一个 action。 - 接着你将根据你的行动从环境/工具中收到一个 observation。 - 持续这个思考和行动的过程直到你有足够的信息来提供 final_answer。 — 所有步骤请严格使用以下 XML 标签格式输出 - question 用户问题 - thought 思考 - action 采取的工具操作 - observation 工具或环境返回的结果 - final_answer 最终答案 # 示例说明 示例1: question今天北京的天气如何我该穿什么/question thought我需要先获取北京当前的天气信息/thought action调用天气API(Beijing)/action observation天气12°C小雨/observation thought根据天气情况气温较低且有雨需要给出穿衣建议/thought action生成穿衣建议/action observation建议穿外套并携带雨伞注意保暖和防水/observation final_answer今天北京气温约12°C有小雨建议穿外套并携带雨伞注意保暖和防水。/final_answer # 可用工具 - read_file(file_path)用于读取文件内容 - write_to_file(filename, content)将指定内容写入指定文件成功时返回写入成功 - run_terminal_command(command)用于执行中断命令 # 注意事项 - 你每次回答都必须包括两个标签第一个是 thought第二个是 action 或 final_answer - 输出 action 后立即停止生成等待真实的 observation擅自生成 observation 将导致错误 - 如果 action 中的某个工具参数有多行的话请使用 \n 来表示如actionwrite_to_file(/tmp/test.txt, a\nb\nc)/action - 工具参数中的文件路径请使用绝对路径不要只给出一个文件名。比如要写 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 DefinitionsAgent 可调用的 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 / ScratchpadAgent 在即时推理过程中使用的临时信息或中间计算结果。从这个角度那如何对上下文Context进行有效的存储、管理、检索、组装的工程技术就是Context EngineeringAgent的效果好不好很大程度上依赖于高质量且聚焦的上下文Context。在构建 Agent 的过程中最棘手的挑战之一是如何管理不断膨胀的上下文Context。理论上具备大型上下文窗口的模型可以处理冗长的对话记录但在实践中上下文越长成本和延迟就越高此外随着上下文不断增长模型从中捕捉关键信息的能力会逐渐下降。Context Engineering 在 Agent 每轮对话的运行循环中体现为一个持续推进的过程关于Context Engineering的更多内容我们会在后面进行介绍本篇不进行展开大家有兴趣也可以基于这个思路进行探索也可以看看各个开源的Agent框架是如何解决这些问题的。其中一个思路就是构建Multi-Agent下面我们先了解下在构建Multi-Agent的通信标准A2A协议。Agent to Agent ProtocolA2A除了追求构建一个通用的“万能”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 ClientClient Agent是一个应用程序、服务或另一个Agent代表用户完成任务。Client是A2A通信的发起方。A2A ServerRemote 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格式表示TaskRemote Agent根据Client Agent的请求生成的有状态的工作单元MessageClient Agent与Remote Agent通信承载信息的结构体ArtifactRemote Agent在任务执行过程中生成的产物a document, image, or structured dataPartMessage或Artifact的基本内容容器。基于A2A协议的整体交互过程如下所示用户在应用中注册添加一个Remote Agent注册提交之后应用会作为Client主动与Remote Agent通信通过GET /.well-known/agent-card方法获取Agent Card在获取到Card后如果Remote Agent需要Authentication这时还会与Auth Server通信进行鉴权这部分在图中没有画出大家知道就好这样Remote Agent的注册就完成了接下来应用会创建一个调度Agent在A2A官方Sample中叫做Host Agent用于对任务进行拆解和下发后续调度Agent会作为Client Agent调用其他的Remote Agent执行任务这部分不是A2A协议定义的部分。用户发起请求任务到应用程序应用程序将任务委托给调度Agent进行处理调度Agent拆解任务调用send_message方法将任务交给Remote Agent执行Remote Agent执行后返回结果给调度Agent调度Agent将最终结果返回给应用程序应用程序将最终结果返回用户。其中步骤1、2、6、7是A2A协议中明确定义的部分下面我们来看下A2A交互过程中的具体协议实现。这里我们以A2A官方a2a-samples项目中的demo作为我们的应用平台在应用平台启动时会创建一个调度Agenta2a-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 { id: 0a97a43d-cded-4ed2-a660-38331ba98976, jsonrpc: 2.0, result: { artifacts: [ { artifactId: 53c3c404-5811-4bf3-8565-eedd02099891, name: 天气查询结果, parts: [ { kind: text, text: 天气晴朗气温为20摄氏度天气温和适宜。建议外出晒晒太阳。 } ] } ], 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: 3744024c-b02d-4ba3-8c4c-d31fc5658eba } ], id: 3744024c-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/mainhttps://github.com/a2aproject/a2a-samples/tree/main最后2026 年春节前后国内大模型迎来史无前例的集体爆发与同台竞技。短短不到一个月主流厂商几乎全部登场字节跳动 Seedance 2.0 刷屏科技圈各大互联网公司纷纷推出 AI 红包新玩法一场场精心准备的“大模型春晚”轮番上演吸引无数 AI 爱好者围观喝彩。大模型赛道竞争如此激烈普通人到底该怎么入局抢占未来 10 年的行业红利如果你还不知道从何开始我特别整理了一套全网最全、最细的大模型零基础教程。我也是一路自学走过来的太清楚小白前期学习的痛点没人带、没方向、没资源真的很难学进去下面这套资料就是我专门为零基础、想转行、想提升的同学准备的全套学习方案。扫码免费领取全部内容资料包分享1、大模型完整学习路线图2、从 0 到进阶大模型视频教程从入门到实战全套视频都整理好了跟着学效率更高3、入门必看精选书籍 核心文档PDF 版市面上技术书太多我已经帮你筛选出最值得看的一批还有大量补充资料不在图里一并打包给你4、AI大模型最新行业报告2026 年最新行业报告系统分析各行业现状、趋势、痛点与机会帮你看清哪些行业最适合落地大模型哪里才有真正的机会。5、面试试题/经验【大厂 AI 岗位面经分享107 道】【AI 大模型面试真题102 道】【LLMs 面试真题97 道】6、大模型项目实战配套源码适用人群四阶段学习规划共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 项目内容安全互联网信息服务算法备案…扫码免费领取全部内容3、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】