Agent 与 LLM 的交互协议：从 ReAct 到工具调用

引言Agent 的核心引擎现代 AI Agent如 Claude Code、Cursor Agent、Aider能够自主完成编程、数据分析等复杂任务其背后依赖两个核心层工具执行层通过 MCP 等协议与外部系统交互文件读写、命令执行、API 调用推理决策层Agent Host 与 LLM 之间的交互协议决定 Agent“何时做、做什么、怎么做”本文聚焦于推理决策层——Agent 与 LLM 之间的交互协议。你将理解Agent Host 如何将工具能力“翻译”给 LLMLLM 如何输出结构化的决策思考 行动为什么 ReAct 模式和 XML 格式成为行业标准一次完整的 Agent 推理循环是如何运转的第一章Agent Host 的双重身份1.1 Agent Host 在架构中的定位在 MCP 架构中Agent Host如 Claude Code处于中间层向下工具层通过 MCP Client 与 Server 通信发现并调用read_file、run_command、get_weather等工具向上模型层将工具列表和对话历史组织成 Prompt调用 LLM API解析 LLM 的响应LLM不直接理解 MCP 协议。它看到的不是tools/list或 JSON-RPC而是经过 Host 转换后的、符合该模型 API 规范的工具定义。1.2 为什么需要这层“翻译”不同 LLM 提供商的工具调用格式各不相同模型提供商工具调用格式关键字段OpenAIFunction Callingtools,tool_callsAnthropicTool Usetools,tool_usecontent blockGoogle GeminiFunction Callingtools,functionCallAgent Host 的核心职责之一就是将 MCP 的标准化工具定义转换为目标 LLM 所能理解的格式。这种“适配器模式”使得 Agent 可以灵活切换底层模型而无需修改工具实现。第二章Agent ↔ LLM 交互全流程2.1 整体流程图用户输入 │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ Agent Host │ │ │ │ ① 发现工具 ② 格式转换 │ │ ┌─────────────────┐ ┌──────────────────────────────────┐ │ │ │ MCP Client │ │ 将 MCP Tool 定义转换为 │ │ │ │ tools/list ────►│───►│ 目标 LLM 的 tools 参数格式 │ │ │ │ ◄─── Tool 列表 │ └──────────────────────────────────┘ │ │ └─────────────────┘ │ │ │ ▼ │ │ ③ 发起 LLM 推理 ④ 解析模型响应 │ │ ┌──────────────────────────────────┐ ┌────────────────────┐ │ │ │ 调用 LLM API传入: │ │ 检测响应中是否包含 │ │ │ │ - 系统提示含 ReAct 指令 │──►│ function_calls │ │ │ │ - 用户消息 │ │ 或 final_response│ │ │ │ - 转换后的工具定义 │ └────────────────────┘ │ │ └──────────────────────────────────┘ │ │ │ ▼ │ │ ⑤ 执行工具 ⑥ 结果回传 │ │ ┌─────────────────┐ ┌──────────────────────────────────┐ │ │ │ 解析 function_ │ │ 将工具结果作为 tool 角色消息 │ │ │ │ calls 提取参数 │───►│ 追加到对话历史再次调用 LLM │ │ │ │ 调用 MCP Client │ │ 直到 LLM 返回 final_response │ │ │ └─────────────────┘ └──────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘ ▼ 最终回复用户2.2 步骤详解步骤①发现工具Host 启动时通过 MCP Client 向每个 Server 发送tools/list获取工具列表。每个 Tool 包含name、description、inputSchemaJSON Schema 定义参数。步骤②格式转换Host 将 MCP Tool 定义转换为目标 LLM 的tools参数。以 OpenAI 为例# MCP Tool 定义{name:get_weather,description:获取指定城市的天气,inputSchema:{type:object,properties:{city:{type:string}}}}# 转换为 OpenAI 格式{type:function,function:{name:get_weather,description:获取指定城市的天气,parameters:{type:object,properties:{city:{type:string}}}}}步骤③发起 LLM 推理Host 构建 Prompt包含系统提示明确要求模型按 ReAct 模式输出使用 XML 标签见第三章对话历史用户消息、之前的工具调用记录工具定义转换后的 tools 参数步骤④解析模型响应LLM 返回的响应通常有两种格式function_calls要求调用工具final_response直接回答用户Host 解析 XML提取工具名称和参数。步骤⑤执行工具Host 根据解析结果通过 MCP Client 调用tools/call将参数传递给对应的 MCP Server。步骤⑥结果回传与循环Host 将工具执行结果以role: tool的消息追加到对话历史再次调用 LLM。重复③~⑥直到 LLM 输出final_response。第三章ReAct 模式与 XML 交互格式3.1 两条技术路线原生 Function Call vs. XML Prompt在开始深入之前必须先澄清一个关键分歧。阅读 Agent 相关技术文章时初学者最容易产生的困惑是“为什么有的 Agent 用 JSON 返回工具调用有的用 XML”这两种方式对应着两种不同的实现路线且在实际的 API 调用中是互斥的路线实现方式典型代表优缺点原生 Function Call使用模型 API 内置的tools参数模型在tool_callsJSON 字段中返回结构化调用OpenAI、Anthropic、Google 官方 API✅ 稳定可靠无需解析❌ 流式控制受限难以获取思维链XML Prompt 驱动在 System Prompt 中内嵌工具定义要求模型在纯文本中输出 XML 标签Host 通过正则或流式解析器提取Claude Code、Cursor、AutoGPT早期✅ 流式可控可获取thinking绕过模型限制❌ 依赖 Prompt 工程解析容错成本高虽然现代 LLM API 提供了原生的 Function Calling JSON 接口但像Claude Code、Cursor等高级 Agent为了获得更强的流式控制、思维链可见性、以及对长上下文的更好兼容性往往选择绕过原生接口在纯文本流中强制使用 XML 标签来输出决策。Host 接收到文本后通过正则或流式 XML 解析器提取动作。本文的其余部分聚焦于路线②XML Prompt 驱动这也是当前最先进 Agent 系统的共同选择。如果你使用原生 Function Calling步骤④中你将从response.tool_calls读取结构化数据而非解析 XML但整体的“发现 → 决策 → 执行 → 观察”循环逻辑是相通的。3.2 什么是 ReActReActReasoning Acting是一种 Prompt 范式要求 LLM 在每一步先输出推理过程再输出行动决策。这种模式最早由 Google 在 2022 年提出现已成为 Agent 系统的默认选择。核心优势可解释性开发者能追踪模型的决策路径调试错误错误恢复当工具返回意外结果时模型可在下一轮思考中调整策略多步推理复杂任务天然需要多轮思考-行动循环3.3 XML 标签格式在 XML Prompt 驱动路线下LLM 的每次响应必须包含两个部分① 推理过程thinkingthinking用户询问北京天气。我看到工具列表中有 get_weather正好可以完成这个任务。city 参数从问题中提取为“北京”。调用这个工具后我就能获得准确信息。/thinking② 行动决策二选一调用工具function_callsinvokenameget_weatherparameternamecity北京/parameter/invoke/function_calls直接回复final_response北京今天晴气温 18°C ~ 26°C。/final_response3.4 为什么选择 XML维度XML 标签JSON流式解析可增量解析遇到开标签即可处理需完整 JSON 才能解析自然语言嵌入与自然文本融合良好需要转义干扰阅读LLM 生成难度更符合 LLM 的文本生成习惯需要严格括号匹配容易出错可读性清晰标记思考与行动嵌套结构不易阅读关键点XML 标签是 Agent Host 与 LLM 之间的内部约定不属于任何标准协议。不同 Agent 可能使用不同的标签名如thought、action但本质都是“思考 行动”的二段式结构。第四章完整模拟交互——编程智能体查询天气以下通过角色扮演完整展示一个编程智能体类似 Claude Code与 LLM 的交互过程。4.1 模拟设定角色职责用户提出查询请求Agent Host管理对话历史、解析 XML、执行工具、控制 ReAct 循环LLM小白输出thinkingfunction_calls或final_responseMCP Server提供工具本例中包含get_weather工具列表通过 MCP 发现工具名描述参数read_file读取文件pathwrite_file写入文件path,contentrun_command执行命令commandsearch_code搜索代码pattern,pathget_weather获取天气来自 MCP 天气 Servercity4.2 LLM 的系统提示词简化版你是一个编程智能体遵循 ReAct 模式。可用工具如下 - get_weather(city): 获取城市天气 你的输出格式 1. thinking 你的推理过程 /thinking 2. 要么 function_callsinvoke name工具名parameter name参数名值/parameter/invoke/function_calls 要么 final_response 你的最终回答 /final_response 只输出上述格式不要添加其他文字。4.3 交互日志第 1 轮用户提问Host 发送给 LLM用户: 北京今天天气怎么样 Host → LLM小白: message conversation_history[{role:user,content:北京今天天气怎么样}]/conversation_history tools toolnameget_weather/namedescription获取城市天气/descriptionparametersparameter namecity typestring//parameters/tool /tools instruction请按 ReAct 模式处理。/instruction /messageLLM 响应thinking用户询问北京天气。我看到 get_weather 工具正好可用city 参数为“北京”。调用它即可获得数据。/thinkingfunction_callsinvokenameget_weatherparameternamecity北京/parameter/invoke/function_calls第 2 轮Host 执行工具回传结果Host模拟 MCP 执行: get_weather 返回“北京今天晴18°C~26°C空气质量良好” Host → LLM小白: message conversation_history [ {role:user,content:北京今天天气怎么样}, {role:assistant,content:thinking.../thinking}, {role:tool,tool_call_id:call_001,content:北京今天晴18°C~26°C空气质量良好} ] /conversation_history instruction请根据工具结果生成最终回复。/instruction /messageLLM 响应thinking工具返回了北京天气详情晴18-26°C空气质量良好。信息完整可直接组织成自然语言回复用户。/thinkingfinal_response北京今天晴气温 18°C ~ 26°C空气质量良好非常适合户外活动/final_response第 3 轮Host 返回给用户Host → 用户: 北京今天晴气温 18°C ~ 26°C空气质量良好非常适合户外活动4.4 流程复盘步骤角色动作关键内容①用户提问自然语言②Host打包请求对话历史 工具定义 ReAct 指令③LLM思考 决策thinkingfunction_calls④Host执行工具调用 MCP Server 的get_weather⑤Host回传结果将工具结果追加到历史⑥LLM再思考 最终回复thinkingfinal_response⑦Host返回给用户最终回答关键认知LLM 从未直接接触 MCP 协议它只看到 XML 格式的对话历史和工具定义。Host 完成了所有协议翻译和工具调度工作。第五章总结与认知5.1 核心要点Agent Host 是唯一的协议翻译者向下工具层通过 MCP 发现和调用工具JSON-RPC向上模型层根据所选的实现路线原生 Function Call 或 XML Prompt将工具定义转换为 LLM 能理解的格式两条路线按需选择原生 Function Call快速原型、标准应用、追求稳定性XML Prompt 驱动高级 AgentClaude Code/Cursor、追求流式控制和思维链可见性ReAct 模式是 Agent 推理的骨架每一步都包含“思考”thinking和“行动”function_calls或final_response这种设计让 Agent 具备多步推理和错误恢复能力MCP 提供工具ReAct 提供决策MCP 解决了“如何调用工具”的问题标准化接入层ReAct XML 解决了“何时调用工具、如何决策”的问题推理决策层5.2 从 MCP 到 Agent 的完整链路用户提问 │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ Agent Host如 Claude Code │ │ │ │ ① MCP 发现工具 ② 构建 ReAct Prompt │ │ ┌────────────┐ ┌───────────────────────────────────┐ │ │ │ tools/list │ │ System: 工具列表 XML 格式要求 │ │ │ │ ◄── Tool[] │ │ User: 用户问题 │ │ │ └────────────┘ └───────────────────────────────────┘ │ │ │ │ ③ 发送 Prompt 给 LLM纯文本是否使用原生 tools 参数可选│ │ ④ LLM 返回文本含 XML 标签 或 原生 tool_calls 字段 │ │ ⑤ Host 解析决策提取 XML 或反序列化 JSON │ │ ⑥ 执行工具MCP Client → tools/call │ │ ⑦ 将工具结果追加到历史重复③~⑥直到 LLM 输出 final │ └──────────────────────────────────────────────────────────────┘ │ ▼ 最终回答5.3 Agent 与普通聊天的本质区别维度普通聊天ReAct Agent输出内容直接回答思考 行动工具调用或回答交互轮次单轮多轮思考-行动-观察循环能力边界固定模型训练时学到的知识可扩展通过 MCP 接入任意工具可解释性低无法追踪决策路径高thinking暴露推理过程错误恢复无可基于工具错误信息重新决策5.4 生产环境最佳实践① 系统提示词设计系统提示词应明确声明模型的角色和职责可用的工具列表名称、描述、参数输出格式要求XML 标签结构或 JSON 格式ReAct 模式的执行规则② 工具描述优化工具描述直接影响 LLM 调用的准确性建议description应包含“何时调用”的明确指引参数描述应说明格式和取值范围示例优于抽象描述③ 错误处理Agent Host 应处理工具调用超时设置合理超时超时后向 LLM 返回错误消息解析失败要求 LLM 重新输出或返回友好错误工具返回错误将错误信息追加到对话历史让 LLM 决定重试或降级④ 对话历史管理长对话应截断或摘要避免超出上下文窗口保留最近 N 轮推理-行动记录即可工具返回的大文件内容应考虑摘要后再追加5.5 未来演进方向根据最新的 MCP 规范演进方向Agent-LLM 交互协议也在持续发展Tasks 扩展支持长时间运行的工具调用Agent 可在工具执行期间发送进度通知无状态核心简化 Host 实现降低维护成本MCP Apps为 Agent 带来 UI 交互能力用户可在工具调用过程中提供实时反馈这些变化将进一步增强 Agent 的自主性和交互性但 ReAct 作为推理决策的核心模式以及结构化输出无论是 XML 还是 JSON作为与 LLM 交互的主流方式依然会保持其重要地位。附录Server-Side Sampling已弃用A.1 什么是 Server-Side SamplingServer-Side Sampling 允许 MCP Server 通过 Client 向 Host 请求 LLM 采样。例如一个代码分析 Server 可能需要 LLM 生成代码注释。这是 MCP 中为数不多的“反向”交互。A.2 协议交互Server 向 Client 发送sampling/createMessage请求{jsonrpc:2.0,id:1,method:sampling/createMessage,params:{messages:[{role:user,content:请总结这段代码的功能}],maxTokens:500}}ClientHost将请求转发给 LLM并将结果返回给 Server。A.3 弃用说明重要更新根据最新的 MCP 规范更新Sampling 功能已被标记为Deprecated弃用。其核心原因在于安全风险——恶意 Server 可能通过精心构造的提示词进行注入攻击Host 难以完全防御架构演进——MCP 趋向于更薄的协议层让 Server 更独立Server 应直接调用 LLM API而非依赖 Host 中转新实现不应采用此功能现有实现应迁移到 Server 直接集成 LLM 提供商 API。结语Agent 与 LLM 的交互协议决定了 Agent 能否高效、准确地完成复杂任务。理解并掌握这套协议是构建可靠 AI Agent 系统的基础。对于开发者而言掌握这套协议意味着你能选择正确的实现路线原生 Function Call 适合快速原型XML Prompt 驱动适合追求极致流式控制和可观测性的生产级 Agent你能更好地调试 Agent通过thinking标签追踪模型的推理路径定位错误决策的根源你能优化工具设计精准的工具描述能显著提高模型调用的准确性减少“幻觉调用”你能理解性能瓶颈多次推理的延迟累积、上下文窗口的限制都需要在系统设计时仔细考量从 MCP 的标准化工具接入到 ReAct 的结构化推理决策再到 XML 或 JSON 的结构化输出控制——这三个层次共同构成了现代 AI Agent 的技术基座。无论技术如何演进理解并掌握这套核心交互协议都是深入 Agent 开发领域的必修课。本文基于 MCP 规范及主流 Agent 实现Claude Code、Cursor、Aider的最佳实践总结而成。