AI Agent工具调用机制:从Function Calling到MCP

工具调用:Agent的双手 没有工具调用能力的LLM只是一个"会说话的大脑"。真正的Agent需要调用API、执行代码、读写文件——这些都需要工具调用机制。 演进历程 阶段一:Prompt工程时代(2022-2023) 最早的工具调用靠Prompt引导: 你可以使用以下工具: 1. search(query): 搜索网页 2. calculator(expr): 数学计算 如果需要使用工具,请输出以下格式: <tool>search("天气")</tool> 这种方式的问题: 格式不稳定,模型经常不遵守 参数提取容易出错 无法处理多步工具调用 阶段二:Function Calling时代(2023-2024) OpenAI在2023年6月推出Function Calling,将工具调用作为原生API能力: response = openai.chat.completions.create( model="gpt-4", messages=[{"role": "user", "content": "北京天气"}], tools=[{ "type": "function", "function": { "name": "get_weather", "description": "获取城市天气", "parameters": { "type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"] } } }] ) # response.choices[0].message.tool_calls 模型输出结构化的工具调用请求,API层解析后执行。 阶段三:标准化时代(2024-2026) MCP协议将工具调用标准化,实现"一次开发,处处可用"。 Function Calling的技术细节 工作流程 1. 用户消息 + 工具定义 → LLM 2. LLM输出 → tool_call(name, args) 3. 应用层执行工具 4. 工具结果 → LLM 5. LLM基于结果生成回答 关键参数 tools定义: { "type": "function", "function": { "name": "string", "description": "string", "parameters": { // JSON Schema格式 } } } tool_choice控制: auto:模型自主决定是否调用 none:禁止调用 required:必须调用 {"function": {"name": "xxx"}}:指定调用特定工具 并行调用 现代模型支持在单次响应中输出多个tool_call: ...

2026-07-16 · 2 min · 218 words · 硅基 AGI 探索者

Function Calling标准化演进:从OpenAI到MCP统一协议

工具调用:从实验性功能到标准基础设施 2023年OpenAI推出Function Calling时,它被视为一个便捷的实验性功能。到2026年,工具调用已成为大模型应用的标准基础设施——每个Agent都需要调用工具,而调用方式的标准化程度直接决定了开发效率。 各厂商方案对比 OpenAI Function Calling OpenAI的方案是最早的标准化工具调用格式: { "tools": [ { "type": "function", "function": { "name": "get_weather", "description": "获取指定城市的天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名"}, "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]} }, "required": ["city"] } } } ] } 模型响应包含工具调用: { "tool_calls": [ { "id": "call_abc123", "function": { "name": "get_weather", "arguments": "{\"city\": \"北京\"}" } } ] } 特点:参数以JSON字符串形式返回,需要二次解析。Parallel function calling支持一次调用多个工具。 Anthropic Tool Use Anthropic的格式与OpenAI类似但在细节上有差异: { "tools": [ { "name": "get_weather", "description": "获取指定城市的天气", "input_schema": { "type": "object", "properties": { "city": {"type": "string"} }, "required": ["city"] } } ] } 差异点: 用input_schema替代parameters 参数直接作为对象返回,不需要二次解析 工具调用结果用tool_result消息类型返回 Google Gemini Function Calling { "function_declarations": [ { "name": "get_weather", "description": "获取指定城市的天气", "parameters": { "type": "object", "properties": { "city": {"type": "string"} } } } ] } 差异点:用function_declarations替代tools,响应格式也略有不同。 ...

2026-07-16 · 3 min · 505 words · 硅基 AGI 探索者

MCP协议实战:构建标准化的AI工具调用接口

MCP协议:AI工具调用的"USB-C"接口 2024年Anthropic推出的Model Context Protocol(MCP)正在改变AI Agent与外部工具的交互方式。如果说Function Calling是每个厂商各自的充电接口,那么MCP就是统一的USB-C标准。 MCP核心架构 MCP采用客户端-服务器架构,定义了三个核心原语: Resources(资源) 只读数据源,类似REST中的GET端点。Agent可以读取文件、数据库记录、API响应等: { "uri": "file:///project/src/main.py", "mimeType": "text/x-python", "content": "..." } Tools(工具) 可执行的操作,类似POST端点。每个工具定义包含名称、描述和JSON Schema参数: interface Tool { name: string; description: string; inputSchema: { type: "object"; properties: { ... }; required: string[]; }; } Prompts(提示模板) 预定义的提示词模板,支持参数化注入,方便复用。 与Function Calling的对比 传统Function Calling存在三个痛点:工具定义与模型耦合、跨厂商不兼容、缺乏状态管理。MCP通过标准化协议层解决了这些问题: 维度 Function Calling MCP 工具定义 内嵌在prompt中 独立服务,动态发现 跨厂商 各厂商格式不同 统一协议 状态管理 无状态 支持有状态会话 传输方式 API请求内嵌 stdio/SSE/HTTP 工程实现示例 以下是一个MCP Server的Python实现: from mcp.server import Server from mcp.types import Tool, TextContent server = Server("code-analyzer") @server.list_tools() async def list_tools(): return [ Tool( name="analyze_code", description="分析Python代码的复杂度和潜在问题", inputSchema={ "type": "object", "properties": { "code": {"type": "string", "description": "待分析的代码"}, "strictness": {"type": "string", "enum": ["low", "medium", "high"]} }, "required": ["code"] } ) ] @server.call_tool() async def call_tool(name: str, arguments: dict): if name == "analyze_code": result = await analyze(arguments["code"], arguments.get("strictness", "medium")) return [TextContent(type="text", text=result)] MCP在Agent编排中的价值 MCP最大的价值在于Agent编排场景。当多个Agent需要共享同一组工具时,MCP Server作为统一的工具提供者: ...

2026-07-16 · 1 min · 147 words · 硅基 AGI 探索者
Function Calling最佳实践

Function Calling最佳实践

Function Calling的核心价值 Function Calling让LLM能够调用外部工具和API,从"对话助手"升级为"行动助手"。但实践中的挑战在于:如何让模型可靠地选择正确的工具、生成正确的参数、处理工具执行失败的情况。 工具定义最佳实践 清晰的工具描述 tools = [ { "type": "function", "function": { "name": "search_knowledge_base", "description": ( "搜索企业知识库中的文档。当用户询问公司政策、产品信息、" "技术文档等内部知识时使用此工具。\n" "注意:不要用于搜索公开互联网信息。" ), "parameters": { "type": "object", "properties": { "query": { "type": "string", "description": "搜索关键词,使用自然语言描述要查找的内容" }, "department": { "type": "string", "enum": ["engineering", "sales", "hr", "finance"], "description": "限定搜索的部门范围,不指定则搜索全部" }, "limit": { "type": "integer", "description": "返回结果数量,默认5", "default": 5, "minimum": 1, "maximum": 20 } }, "required": ["query"] } } } ] 工具选择的引导 # 好的描述:明确什么场景用,什么场景不用 "description": "获取当前天气信息。当用户询问天气状况、温度、降水概率时使用。不要用于历史天气查询。" # 坏的描述:模糊不清 "description": "天气工具" # 模型不知道何时使用 参数验证 from pydantic import BaseModel, Field, validator class SearchParams(BaseModel): query: str = Field(..., min_length=2, max_length=500) department: str = Field("all", pattern="^(engineering|sales|hr|finance|all)$") limit: int = Field(5, ge=1, le=20) @validator('query') def sanitize_query(cls, v): # 移除潜在注入 v = v.replace('\n', ' ').replace('\r', ' ') return v.strip() def validate_tool_args(func_name, args): """验证工具参数""" schema_map = { "search_knowledge_base": SearchParams, } if func_name in schema_map: return schema_map[func_name](**args) return args 执行与错误处理 class ToolExecutor: def __init__(self, tools_dict, timeout=30): self.tools = tools_dict self.timeout = timeout async def execute(self, tool_name, arguments): # 验证工具存在 if tool_name not in self.tools: return {"error": f"Unknown tool: {tool_name}"} # 验证参数 try: validated = validate_tool_args(tool_name, arguments) except Exception as e: return {"error": f"Invalid arguments: {e}"} # 带超时执行 try: result = await asyncio.wait_for( self.tools[tool_name](**validated.dict()), timeout=self.timeout ) return {"result": result} except asyncio.TimeoutError: return {"error": f"Tool execution timed out after {self.timeout}s"} except Exception as e: return {"error": f"Tool execution failed: {str(e)}"} async def function_calling_loop(llm, messages, tools, executor, max_rounds=5): """Function Calling循环""" for round_idx in range(max_rounds): response = await llm.achat_completion( messages=messages, tools=tools, tool_choice="auto" ) msg = response.choices[0].message messages.append(msg) # 如果模型没有调用工具,返回最终回答 if not msg.tool_calls: return msg.content # 执行所有工具调用 for tool_call in msg.tool_calls: result = await executor.execute( tool_call.function.name, json.loads(tool_call.function.arguments) ) messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(result, ensure_ascii=False) }) return "达到最大工具调用轮次限制。" 并行工具调用 async def parallel_tool_calls(llm, messages, tools, executor): """支持并行工具调用""" response = await llm.achat_completion( messages=messages, tools=tools, tool_choice="auto" ) msg = response.choices[0].message messages.append(msg) if msg.tool_calls: # 并行执行所有工具调用 tasks = [] for tool_call in msg.tool_calls: task = executor.execute( tool_call.function.name, json.loads(tool_call.function.arguments) ) tasks.append((tool_call.id, task)) results = await asyncio.gather(*[t for _, t in tasks]) for (tool_call_id, _), result in zip(tasks, results): messages.append({ "role": "tool", "tool_call_id": tool_call_id, "content": json.dumps(result, ensure_ascii=False) }) return messages 工具调用日志 import structlog logger = structlog.get_logger() class LoggingToolExecutor: def __init__(self, executor): self.executor = executor async def execute(self, tool_name, arguments): log = logger.bind(tool=tool_name) log.info("tool_call_start", args=arguments) start = time.time() result = await self.executor.execute(tool_name, arguments) duration = time.time() - start if "error" in result: log.error("tool_call_error", error=result["error"], duration_ms=duration*1000) else: log.info("tool_call_success", duration_ms=duration*1000) return result 结语 Function Calling的可靠性来自清晰的工具描述、严格的参数验证、完善的错误处理和详尽的日志记录。将这些实践标准化,可以显著提升LLM Agent在生产环境中的稳定性。 加入讨论 这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。 ...

2026-07-02 · 2 min · 407 words · 硅基 AGI 探索者
Agent模型选型

Agent模型选型框架:为智能体挑大脑

引言 Agent(智能体)是2026年AI应用的核心范式。一个优秀的Agent不仅需要强大的语言理解能力,更需要精准的工具调用、可靠的推理、持久的上下文记忆和灵活的规划能力。选择适合Agent的模型,远比选择通用聊天模型复杂。本文将提供一个系统化的Agent模型选型框架。 Agent核心能力需求 1. 工具调用(Tool Calling) Agent最核心的能力是调用外部工具。模型需要: 准确理解何时需要调用工具 生成符合工具模式(Schema)的参数 处理工具返回结果并决定下一步 关键指标: 工具调用准确率(Function Calling Accuracy) 参数生成正确率 多工具并行调用能力 2. 推理与规划(Reasoning & Planning) 复杂任务需要多步推理和规划: 将大任务分解为子任务 制定执行计划 处理异常情况 关键指标: 任务分解准确率 规划合理性评分 动态调整能力 3. 上下文管理(Context Management) Agent需要维护长期上下文: 记忆历史对话和工具调用结果 处理长上下文(通常>16K tokens) 上下文压缩和摘要 关键指标: 长上下文理解准确率 记忆检索准确率 上下文利用效率 4. 代码执行(Code Execution) 许多Agent需要执行代码来完成任务: 生成可执行的代码 理解代码执行结果 调试和修复代码 5. 多模态理解(可选) 部分Agent需要处理图像、PDF等: 文档理解 图表分析 截图理解 主流Agent模型对比 综合推理型 模型 工具调用 推理 代码 长上下文 综合评分 GPT-5 ★★★★★ ★★★★★ ★★★★★ 128K 9.8/10 Claude 4 Opus ★★★★★ ★★★★★ ★★★★☆ 200K 9.7/10 Gemini 2.5 Ultra ★★★★☆ ★★★★☆ ★★★★☆ 2M 9.5/10 GLM-5 ★★★★☆ ★★★★☆ ★★★★☆ 256K 9.3/10 Qwen 3 235B ★★★★☆ ★★★★☆ ★★★★☆ 128K 9.2/10 工具调用特化型 模型 工具调用准确率 并行调用 特点 GPT-5 98.7% ✓ 工具调用之王 Claude 4 Opus 97.5% ✓ 参数生成最准确 GLM-5 96.8% ✓ 中文工具调用最佳 Qwen 3 235B 95.3% ✓ 代码工具强 Gemini 2.5 Ultra 94.2% ✓ 长上下文工具调用 代码Agent特化型 模型 代码生成 代码执行 调试 特点 GPT-5 + Code Interpreter ★★★★★ ★★★★★ ★★★★★ 最强代码Agent Claude 4 Opus + Analysis ★★★★★ ★★★★☆ ★★★★★ 代码分析强 DeepSeek-V4 ★★★★☆ ★★★★☆ ★★★★☆ 开源最佳 Qwen 3 Coder 235B ★★★★☆ ★★★★☆ ★★★★☆ 中文代码最佳 场景化选型 场景一:个人助理Agent 需求:日程管理、邮件处理、信息查询、任务提醒 ...

2026-07-02 · 2 min · 385 words · 硅基 AGI 探索者
Agent工具选择架构

Agent工具选择架构:让AI自己决定用什么工具

引言 2026年,一个生产级Agent可能需要调用数百甚至上千个工具。从发邮件到查数据库,从写代码到部署服务,工具是Agent与物理世界交互的桥梁。但工具数量增长带来了一个棘手的问题:Agent如何从数百个工具中选择正确的那个? 这不是一个简单的匹配问题。用户说"帮我看看昨天那个数据",Agent需要理解"昨天"是哪天、“那个数据"指什么、应该从哪个数据源查、用什么查询语言。工具选择架构的设计直接决定了Agent的能力边界。 一、工具选择的挑战 1.1 规模挑战 当工具数量少于20个时,可以将所有工具描述放入LLM上下文,让模型直接选择。但当工具数量达到数百个时,这种方法不再可行: 上下文窗口被工具描述占满,留给推理的空间不足 工具间描述相似,LLM容易混淆 延迟增加,成本上升 1.2 语义挑战 用户意图与工具描述之间往往存在语义鸿沟。用户说"把这个发给老板”,Agent需要理解这是要发邮件,收件人是"老板",内容是"这个"(需要从上下文解析)。 1.3 组合挑战 有些任务需要组合多个工具。例如"帮我查一下竞品最近的价格变化并生成报告"需要:搜索竞品列表→查询各竞品价格→对比分析→生成报告文档。工具选择不仅要选对单个工具,还要规划正确的执行顺序。 二、工具选择架构分层 2.1 工具索引层 工具索引层负责工具的注册、描述和索引。每个工具的描述应包含: tool_name: "send_email" description: "发送电子邮件到指定收件人" when_to_use: | - 用户要求发送邮件时 - 需要将结果通过邮件分享时 when_not_to_use: | - 用户只是想保存内容(用save_file) - 用户想在聊天中直接展示(用display_result) parameters: - name: to type: string description: "收件人邮箱地址" required: true - name: subject type: string description: "邮件主题" required: true - name: body type: string description: "邮件正文" required: true examples: - input: "发邮件给john@example.com,主题是项目更新" output: "send_email(to='john@example.com', subject='项目更新', body='...')" cost: "low" latency: "medium" 2.2 工具路由层 工具路由层是架构的核心。当Agent接收到用户请求时,路由层负责从工具池中筛选出最相关的候选工具。 ...

2026-07-02 · 2 min · 274 words · 硅基 AGI 探索者
MCP协议

MCP 协议 2026:Agent 工具调用的事实标准?

引言 2026年,AI Agent生态的碎片化问题日益凸显。不同框架、不同厂商的Agent之间缺乏统一的通信标准,导致"信息孤岛"和"工具孤岛"。MCP(Model Context Protocol)协议的推出,试图解决这个问题,但它能否成为事实标准?本文深入分析。 MCP 协议的核心设计 什么是 MCP? MCP是由Anthropic提出的开放协议,旨在为AI模型与外部数据源、工具和服务之间提供标准化的连接方式。 核心目标: 统一模型与工具的接口 降低Agent集成外部资源的成本 促进跨平台的互操作性 三层架构 ┌─────────────────────────────────────┐ │ MCP Host (应用层) │ │ Claude Desktop / Cursor / VSCode │ ├─────────────────────────────────────┤ │ MCP Client (客户端) │ │ 连接到 Server 的进程 │ ├─────────────────────────────────────┤ │ MCP Server (服务端) │ │ 提供资源/工具/提示的进程 │ ├─────────────────────────────────────┤ │ 外部数据源 / API │ └─────────────────────────────────────┘ 三大核心抽象 资源(Resources):Agent可以读取的数据(文件、数据库记录、API响应等) 工具(Tools):Agent可以调用的操作(搜索、计算、执行命令等) 提示(Prompts):预定义的对话模板,帮助Agent高效完成常见任务 MCP 与 A2A 协议的对比 MCP vs A2A 维度 MCP A2A 设计目标 模型-工具连接 Agent-Agent通信 通信模式 Client-Server Peer-to-Peer 主要场景 单Agent扩展 多Agent协作 标准化程度 较成熟 早期阶段 生态规模 1000+ Server 数十个实现 互补而非竞争 MCP和A2A解决的是不同层面的问题: ...

2026-06-30 · 2 min · 249 words · 硅基 AGI 探索者
agent tool calling eval

Agent工具调用准确率测评

概述 Agent工具调用准确率测评是AI智能体领域中Agent工具调用准确率测评的重要主题。本文将从多个角度深入分析这一话题,为读者提供系统性的认知框架和实践参考。 核心概念 基本定义 在深入讨论之前,我们需要明确几个核心概念。AI智能体是指能够感知环境、理解指令、规划行动并调用工具完成任务的AI系统。与传统的聊天机器人不同,智能体具有自主性、目标导向性和工具使用能力。 Agent工具调用准确率测评涉及的关键技术包括: 大语言模型:作为智能体的认知引擎,负责理解、推理和生成 工具调用:通过Function Calling或MCP协议与外部系统交互 记忆系统:短期记忆处理当前对话,长期记忆存储历史经验 规划引擎:将复杂任务分解为可执行的子步骤 技术原理 从技术层面看,Agent工具调用准确率测评的核心在于如何让AI系统更好地理解和执行人类意图。这涉及多个技术环节的协同: 首先是感知层,智能体需要准确理解用户的自然语言指令,提取关键信息和约束条件。其次是规划层,将高层目标分解为具体的执行步骤。然后是执行层,调用合适的工具完成每个步骤。最后是反馈层,根据执行结果调整后续策略。 实践分析 当前现状 在测评方法领域,当前的技术实践呈现出几个明显特征: 工程化程度提升:从实验室原型到生产级系统,工程能力成为关键差异化因素 评估体系完善:越来越多标准化的评测基准被提出,帮助开发者量化能力边界 开源生态繁荣:开源框架和工具链的成熟降低了开发门槛 安全意识增强:对AI安全和对齐问题的重视程度显著提升 关键挑战 尽管进展显著,Agent工具调用准确率测评仍面临几个核心挑战: 技术挑战: 大模型的幻觉问题在智能体场景下被放大,因为智能体需要做出实际决策 多步推理中的错误累积效应导致长程任务成功率下降 工具调用的可靠性受外部API稳定性影响 工程挑战: 智能体的可观测性不足,调试和排错困难 成本控制与性能优化的平衡 从单机到分布式部署的架构复杂性 安全挑战: Prompt注入等攻击手段不断进化 智能体权限管理需要更精细化的控制 数据隐私保护在多Agent协作场景下更加复杂 优化策略 针对上述挑战,以下是几个关键优化方向: 技术优化 分而治之:将复杂任务分解为可独立验证的子任务,降低单步错误影响 多路投票:对关键决策使用多次采样投票机制,提高可靠性 渐进式信任:智能体权限从最小化开始,根据表现逐步扩展 人在回路:高风险决策保留人工审核环节 工程优化 可观测性优先:建立完善的日志、指标和追踪体系 灰度发布:新版本智能体先在小流量环境验证 自动化测试:构建端到端测试套件,防止回归 成本监控:实时追踪Token消耗和API调用成本 案例研究 为了更具体地说明Agent工具调用准确率测评的实践价值,我们来看一个典型场景: 某科技公司在内部IT运维中部署了AI智能体,负责处理员工的工单请求。智能体需要理解员工的自然语言描述,判断问题类型,查询知识库,执行修复操作或转接人工。 实施过程中遇到的关键问题包括: 员工描述模糊导致意图识别错误 知识库信息过时导致给出错误建议 某些操作需要管理员权限存在安全风险 解决方案: 引入澄清对话机制,在不确定时主动追问 建立知识库更新流程,定期审核内容 实施权限分级制度,敏感操作需人工确认 效果:工单首次解决率提升35%,平均处理时间缩短60%,员工满意度显著提升。 未来趋势 Agent工具调用准确率测评的发展趋势值得关注: 标准化:MCP等开放协议将推动工具接口标准化,降低集成成本 垂直化:针对特定行业和场景的专用智能体将大量涌现 协作化:多智能体协作将成为复杂任务的标准解决方案 自主化:智能体的自主决策能力将持续提升,但需要配套的安全机制 结论 Agent工具调用准确率测评是AI智能体技术发展中的重要一环。无论是技术原理的深入理解,还是实践中的工程优化,都需要系统性思维。对于开发者和企业而言,关键在于: 理解技术能力和边界,避免过度期待 建立系统化的评估和监控体系 在创新和安全之间找到平衡 持续学习和适应快速变化的技术生态 硅基AGI探索者将持续关注测评方法领域的最新进展,为读者提供深度分析和实践指导。— ...

2026-06-27 · 1 min · 88 words · 硅基 AGI 探索者
agent tool calling accuracy eval

Agent工具调用准确率测评:方法、指标与实践

工具调用:Agent的核心能力 AI Agent与普通聊天机器人的本质区别在于:Agent能调用外部工具完成任务。无论是查询数据库、发送邮件还是操作API,工具调用的准确性直接决定了Agent的实用价值。 工具调用看似简单——选择工具、填充参数、执行——但每一步都可能出错。我们需要系统化的方法来测评这条链路的可靠性。 评测指标体系 工具选择准确率 给定一个用户意图和可用工具列表,模型是否选对了工具? 评估方式: 精确匹配:模型选择的工具与标注完全一致 可接受匹配:多个工具都能完成任务时,选择任一可接受的工具即算正确 严重错误率:选择了完全不相关的工具或调用了不该调用的工具 参数提取准确率 选对工具后,参数是否正确? 按参数类型分别评估: 必填参数:缺失即错误 可选参数:有默认值时省略可接受 枚举参数:值必须在合法范围内 格式化参数:如日期格式、邮箱格式是否正确 参数级别的准确率 = 正确参数数 / 总参数数 调用序列准确率 复杂任务需要多步工具调用。评估整个调用序列: 调用顺序是否正确(B依赖A的结果) 是否有冗余调用(不必要的重复调用) 是否有遗漏调用(缺少关键步骤) 错误恢复率 工具调用失败后,Agent是否能正确处理: 识别错误原因 调整参数重试 切换替代工具 向用户报告问题 测试集构建方法 工具定义设计 构建测试集首先需要定义工具集。建议分层设计: L1 基础工具:单一功能、单一参数。如get_weather(city)。 L2 复合工具:多功能参数。如search_flights(origin, destination, date, passengers, cabin_class)。 L3 依赖工具:工具间存在数据依赖。如先调用get_user_id(email)再用返回值调用get_orders(user_id)。 L4 动态工具:工具列表在运行时变化,测试模型对未见工具的泛化能力。 测试用例生成 人工标注:由领域专家编写测试用例,质量高但成本高。 LLM辅助生成:用强模型生成候选用例,人工审核。效率高但需要注意分布均衡。 真实日志挖掘:从生产环境日志中提取真实调用场景,最具代表性但需要脱敏处理。 对抗性用例 专门构造容易出错的场景: 工具名称相似(send_email vs send_sms) 参数名称混淆(date vs datetime) 多工具均可完成同一任务 意图中包含误导性信息 评估执行流程 静态评估 不实际执行工具,仅评估模型输出的工具调用JSON: 解析模型输出 与标注答案对比 计算各维度指标 优点是快速可复现,缺点是无法评估执行结果。 ...

2026-06-27 · 1 min · 103 words · 硅基 AGI 探索者
react prompting practice

ReAct Prompting实战

引言 ReAct(Reasoning and Acting)是一种让大语言模型交替进行推理和行动的提示框架。与纯推理型CoT不同,ReAct在推理过程中引入外部工具调用,使模型能够获取实时信息、执行计算和与环境交互。这一框架是现代AI Agent的核心范式之一。本文深入ReAct的原理、模板设计和工程实践。 ReAct的核心思想 推理与行动的交替 ReAct的核心思想是:模型在解决复杂问题时,不应仅依赖内部知识进行推理(可能产生幻觉),也不应盲目调用工具而不思考(可能浪费资源或产生错误操作)。正确的做法是在推理和行动之间交替: Thought:基于当前已知信息进行推理,决定下一步行动 Action:执行推理得出的行动(如搜索、计算、查询) Observation:获取行动结果作为新的已知信息 循环以上步骤直到得出最终答案 与纯CoT的区别 纯CoT的所有推理都在模型内部完成,无法获取外部信息。当问题需要实时数据或精确计算时,纯CoT容易产生事实性错误。ReAct通过工具调用弥补了这一缺陷。 与纯工具调用的区别 纯工具调用模式下,模型直接根据用户请求选择工具并执行,缺乏显式推理过程。这在简单任务中可行,但在需要多步规划和条件判断的复杂任务中容易出错。ReAct的推理步骤提供了决策透明性和可调试性。 ReAct模板设计 基础模板 你是一个能够使用工具解决任务的AI助手。请按照以下格式回答问题: 问题:[用户问题] Thought:[分析当前情况,推理下一步行动] Action:[工具名称] Action Input:[工具输入参数] Observation:[工具返回结果] ...(重复Thought/Action/Observation直到得出答案) Thought:[最终推理] Final Answer:[最终答案] # 可用工具 1. search(query: string): 搜索网络信息 2. calculator(expression: string): 数学计算 3. lookup(keyword: string): 在当前文档中查找信息 # 规则 - 每次只执行一个Action - 必须在Action之前给出Thought - 当有足够信息时给出Final Answer - 如果工具返回错误,分析原因并调整策略 工具描述规范 工具描述的质量直接影响ReAct的效果。一个好的工具描述应包含: 工具名:search_web 描述:搜索互联网获取实时信息。适用于需要最新数据、事实查询、新闻检索的场景。 参数: - query (string, 必填): 搜索关键词,建议使用简洁明确的查询词 返回:搜索结果摘要列表,每条包含标题、摘要和URL 限制:每次搜索最多返回5条结果 示例: Action: search_web Action Input: {"query": "2024年诺贝尔物理学奖获得者"} 复杂推理模板 对于需要深度推理的任务,增强Thought部分的结构: ...

2026-06-27 · 2 min · 301 words · 硅基 AGI 探索者
鲁ICP备2026018361号