1. 项目概述当Agent学会“自己动手”在构建智能体Agent的旅程中我们常常会陷入一个思维定式我们作为开发者需要预先为Agent设定好它能使用的所有工具并编写严格的调用逻辑。这就像给一个探险家一张详尽的地图和一套固定的工具包告诉他“你只能按图索骥只能用这些工具。”然而真正的智能尤其是在处理开放世界任务时往往体现在“自主选择”与“灵活应变”的能力上。“Day 3多工具时代Agent自己选——加入计算器和时间工具”这个项目正是迈向这一目标的关键一步。它不再将Agent视为一个被动的、只能执行预设流程的脚本而是尝试赋予其初步的“工具使用意识”。核心目标很明确让Agent在面对用户问题时能够自主判断是否需要使用外部工具并从其“工具箱”中挑选出最合适的那一个来完成计算或查询时间等具体任务。这听起来简单实则涉及从架构设计到逻辑判断的多个层面。它解决的不仅仅是“11等于几”或者“现在几点”这类具体问题而是一个更根本的问题如何让Agent理解“何时”以及“如何”调用工具以弥补其自身知识或能力的局限性。对于刚接触Agent开发的初学者这是理解工具调用Tool Calling机制的最佳实践对于有经验的开发者这是构建更复杂、更自主的智能工作流的基础模块。今天我们就来彻底拆解这个项目看看如何让Agent学会“自己动手丰衣足食”。2. 核心设计思路从“硬编码”到“动态调度”在传统的编程范式中如果我们想让程序处理计算我们会直接写result 1 1如果想获取时间我们会调用系统API。但在基于大语言模型LLM的Agent架构里我们采取了一种截然不同的思路将能力“工具化”并将选择权“下放”给模型。2.1 范式转变为什么需要Agent自己选工具首先我们必须理解这种设计的必要性。大语言模型本身是一个强大的“世界知识”压缩器和推理引擎但它存在固有的局限实时性缺失模型的训练数据有截止日期它无法知道今天的准确日期、当前的确切时间或者最新的股价。精确计算能力弱虽然LLM能进行简单的算术但对于复杂、多步骤的精确计算如(3527.89 * 1.18) / 12它容易出错远不如一个专用的计算器程序可靠。无法执行外部操作它不能帮你发送邮件、查询数据库、控制智能家居。因此工具Tools应运而生。它们是Agent延伸出的“手”和“眼睛”。但早期的做法是“硬编码”调用逻辑如果用户问题包含“计算”就调用计算函数如果包含“时间”就调用时间函数。这种方式僵硬、脆弱无法处理复杂、隐含的意图。动态工具选择的优势在于意图理解泛化用户可能问“帮我算一下午餐AA制每人该付多少钱”其中并没有“计算”二字。Agent需要理解其数学计算需求。多工具协同未来Agent可能需要先后或同时使用多个工具如先计算日期差再根据结果查询日程。系统可扩展性新增一个工具如天气查询时只需将其注册到工具箱无需修改核心调度逻辑。Agent通过学习自然能学会在合适场景使用它。2.2 架构蓝图智能体、工具与执行引擎的协作要实现自主选择我们需要一个清晰的架构。通常一个具备工具调用能力的Agent系统包含以下核心组件智能体Agent核心通常由一个大语言模型驱动负责理解用户输入User Input进行思考Reasoning并决定下一步行动Action。这个“行动”很可能就是“使用某个工具”。工具集Toolkit一个注册了所有可用工具的集合。每个工具都有明确的名称、描述和参数格式。例如计算器工具名称calculator描述“用于执行精确的数学运算支持加减乘除、幂运算等。”时间工具名称get_current_time描述“获取当前的准确日期和时间。”工具调用接口定义Agent如何与工具交互的规范。目前主流的是Function Calling函数调用模式。Agent的输出不再是纯文本而是一个结构化的请求如{“action”: “calculator”, “action_input”: “125 * (1 0.08)”}。执行引擎或代理循环这是系统的大脑。它接收Agent的结构化请求找到对应的工具函数执行它并将工具返回的结果如“135.0”重新反馈给Agent。Agent再根据这个结果组织最终的回答给用户。这个流程构成了一个“感知-思考-行动-观察”的循环。我们的项目就是在搭建这样一个循环的最小可行系统。注意工具的描述description至关重要它是Agent了解工具功能的唯一文档。描述必须清晰、准确说明工具的用途、适用场景和输入格式。模糊的描述会导致Agent误用或不用工具。3. 实操构建手把手实现一个双工具Agent理论讲完我们进入实战。我们将使用目前最流行的Agent开发框架之一——LangChainPython版来演示。选择它是因为其抽象层次适中既能清晰展示原理又具备强大的生产级扩展能力。3.1 环境准备与依赖安装首先确保你的Python环境建议3.8以上并安装必要库。我们将使用OpenAI的模型作为Agent的“大脑”因为它对Function Calling的支持非常成熟稳定。pip install langchain langchain-openai python-dotenv同时你需要准备一个OpenAI的API密钥。在项目根目录创建.env文件来管理密钥这是一个好的安全实践。# .env 文件内容 OPENAI_API_KEY你的实际api密钥3.2 定义我们的两个核心工具工具的本质是一个Python函数加上一些元数据名称、描述。LangChain提供了tool装饰器来简化这一过程。from langchain.tools import tool from datetime import datetime import math # 工具1精确计算器 tool def calculator(expression: str) - str: 执行一个数学表达式的精确计算。 支持加减()、减(-)、乘(*)、除(/)、幂(**)、括号。 表达式必须是字符串格式。 示例: 2 3 * (4 - 1) - 11 # 重要使用eval存在安全风险仅用于演示。生产环境应使用安全计算库如 ast.literal_eval 或 numexpr。 try: # 这里为了绝对安全可以做一个简单的过滤但演示中我们假设输入是模型生成的相对可控。 # 生产代码务必替换为更安全的计算方式 result eval(expression, {__builtins__: {}}, math.__dict__) return str(result) except Exception as e: return f计算错误{e} # 工具2获取当前时间 tool def get_current_time(placeholder: str ) - str: 获取当前的本地日期和时间。 调用此工具无需任何有效参数但为了符合格式可以传递一个空字符串。 返回格式为YYYY-MM-DD HH:MM:SS now datetime.now() return now.strftime(%Y-%m-%d %H:%M:%S)关键解析与避坑指南tool装饰器它自动将函数转化为LangChain可识别的Tool对象函数文档字符串docstring会成为工具的“描述”这是Agent学习使用工具的关键。计算器的安全性这是本项目最大的一个“坑”。直接使用eval()是极度危险的因为它会执行传入的任何Python代码。在实际项目中绝对禁止这样做这里仅为了演示流程的简洁。你应该使用ast.literal_eval但它不支持数学函数或更专业的库如numexpr、sympy或者自己编写一个安全的表达式解析器。时间工具的参数我们定义了一个placeholder参数。这是因为有些模型/框架要求工具调用必须有输入参数。即使不需要我们也定义一个可选参数来保持格式统一避免调用时报错。3.3 构建智能体并集成工具接下来我们将工具装配给一个LLM创建出我们的Agent。from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain import hub from dotenv import load_dotenv import os # 1. 加载环境变量你的API密钥 load_dotenv() # 2. 初始化大语言模型 # 使用gpt-3.5-turbo性价比高对工具调用支持好。gpt-4更精准但成本高。 llm ChatOpenAI(modelgpt-3.5-turbo, temperature0, openai_api_keyos.getenv(OPENAI_API_KEY)) # temperature0 使输出更确定减少随机性对于工具调用任务更可靠。 # 3. 准备工具列表 tools [calculator, get_current_time] # 4. 获取一个预设的Agent提示词模板 # LangChain Hub上有很多社区贡献的模板react模板专为推理行动循环设计。 prompt hub.pull(hwchase17/react) # 5. 创建Agent agent create_react_agent(llm, tools, prompt) # 6. 创建执行器 agent_executor AgentExecutor.from_agent_and_tools( agentagent, toolstools, verboseTrue, # 开启详细日志方便观察Agent的思考过程 handle_parsing_errorsTrue, # 优雅处理Agent输出解析错误 max_iterations5, # 防止Agent陷入死循环限制最大思考步数 early_stopping_methodgenerate # 当Agent认为不需要再使用工具时直接生成最终答案 )核心要点解读ReAct框架我们使用的react模板代表“Reasoning Acting”。这是一个经典的Agent范式鼓励模型先“思考”Reasoning一步再决定“行动”Acting即调用工具如此循环。在verbose日志中你会看到Thought:、Action:、Observation:的交替出现这正是其工作原理。AgentExecutor这是驱动整个循环的“引擎”。它负责运行Agent解析其输出调用工具并将结果塞回给Agent进行下一轮思考直到Agent输出最终答案或达到迭代上限。verboseTrue强烈建议在开发调试时开启。你能清晰看到模型内心的“独白”这对于理解Agent为何做出某个选择、调试工具描述是否准确具有无可替代的价值。3.4 运行测试看Agent如何自主决策现在让我们用几个问题来测试我们的Agent。# 测试案例1纯计算问题 question1 “如果一件商品原价是288元现在打85折请问折后价格是多少请计算。” result1 agent_executor.invoke({input: question1}) print(答案, result1[output]) # 测试案例2纯时间问题 question2 “现在几点了” result2 agent_executor.invoke({input: question2}) print(答案, result2[output]) # 测试案例3混合意图问题需要计算 question3 “从2023年1月1日到今天一共过去了多少天哦不对你先告诉我今天日期我再算。” result3 agent_executor.invoke({input: question3}) print(答案, result3[output]) # 测试案例4无需工具的问题 question4 “你好请介绍一下你自己。” result4 agent_executor.invoke({input: question4}) print(答案, result4[output])预期观察与解析开启verbose后对于问题1你可能会在日志中看到Thought: 用户需要计算折扣价格。我需要使用计算器工具。原价288元打85折就是乘以0.85。 Action: calculator Action Input: 288 * 0.85 Observation: 244.8 Thought: 我已经计算出结果是244.8可以回答用户了。 Final Answer: 折后价格是244.8元。Agent成功识别了计算需求并精准调用了计算器。对于问题3日志可能更复杂Thought: 用户先问过去了多少天但马上改口说要先知道今天日期。我应该先获取当前日期。 Action: get_current_time Action Input: “” Observation: 2024-05-27 10:30:15 Thought: 现在我有了今天的日期2024-05-27。但用户想计算从2023-01-01到今天的间隔天数。这需要日期计算我的计算器工具只能做算术不能直接算日期差。我需要将日期差转换成算术问题。我可以计算两个日期之间的天数差但这需要知道每月天数考虑闰年很复杂。我现有的工具无法完美解决。我应该向用户说明情况或者提供一个基于当前日期的估算。 Final Answer: 今天是2024年5月27日。要精确计算从2023年1月1日到今天的天数需要考虑闰年和每月天数我的计算器工具无法直接处理日期差。如果您需要精确值建议使用专门的日期计算工具或编程库。这个案例非常精彩它展示了1. Agent能处理复杂的、带有修正指令的对话。2. Agent能意识到自己工具的局限性计算器不能算日期差并给出了诚实且有用的回应。这正是智能的体现——知道何时说“我不知道”。4. 深入原理Agent是如何学会“选择”的你可能好奇模型并没有被“编程”它是如何知道该用哪个工具的呢秘密全在提示工程Prompt Engineering和模型微调Fine-Tuning上。4.1 提示词中的工具“说明书”当我们使用create_react_agent时那个从Hub拉取的prompt模板内部已经包含了引导模型使用工具的指令结构。它会将以下关键信息格式化后送给模型你有权使用以下工具 {tool_descriptions} 请遵循以下格式 Question: 用户输入的问题 Thought: 你需要思考下一步该做什么 Action: 需要调用的工具名称必须从 [{tool_names}] 中选择 Action Input: 调用该工具所需的输入 Observation: 工具返回的结果 ... (这个循环可以重复多次) Thought: 我现在知道了最终答案 Final Answer: 给用户的最终答案其中{tool_descriptions}和{tool_names}会被替换成我们定义的工具列表。模型在训练时已经见过大量类似格式的文本它学会了在这种“框架”下进行推理先阅读工具说明书理解问题然后模仿示例输出结构化的Action和Action Input。4.2 Function CallingOpenAI模型的“原生技能”我们使用的是ChatOpenAI它原生支持Function Calling。这是一种更优雅、更底层的方式。我们实际上可以不用ReAct提示模板而是直接将工具的定义以JSON Schema格式传给模型。from langchain.agents.format_scratchpad import format_to_openai_function_messages from langchain.agents.output_parsers import OpenAIFunctionsAgentOutputParser # 另一种方式使用OpenAI原生的函数调用 agent ( { input: lambda x: x[input], agent_scratchpad: lambda x: format_to_openai_function_messages(x[intermediate_steps]), } | prompt | llm.bind_functions(tools) # 关键将工具绑定到LLM使其具备函数调用能力 | OpenAIFunctionsAgentOutputParser() )在这种模式下模型的输出直接是一个符合OpenAI函数调用规范的JSON对象而不是需要解析的文本。这种方式通常更稳定、更快速因为它是模型被专门训练过的能力。LangChain的create_react_agent底层其实也兼容了这种模式它为我们选择了最合适的交互方式。核心区别ReAct提示更通用理论上适用于任何支持文本生成的LLM通过文本格式引导。原生Function Calling更专用需要模型本身支持此功能如GPT-4, GPT-3.5-turbo, Claude等通过结构化JSON交互。我们的示例默认使用了兼容性更好的ReAct方式。5. 常见问题、调试技巧与进阶优化在实际开发中你一定会遇到Agent“犯傻”的情况。以下是典型问题及解决思路。5.1 问题排查清单问题现象可能原因解决方案Agent完全不调用工具直接回答。1. 工具描述不清晰或与问题不匹配。2. 模型温度temperature过高导致输出随机。3. 提示词模板未正确鼓励工具使用。1.重写工具描述使其更精准、包含典型用例关键词。例如计算器描述中加入“折扣、利率、平均数”等词。2.降低temperature至0。3. 在系统提示词或用户问题中明确要求“请使用可用工具”。Agent调用了错误的工具。工具功能描述有重叠或歧义。细化工具职责使描述更具区分度。例如明确“计算器只做纯数学运算”而“查询汇率”是另一个工具。Agent在工具调用后陷入循环不断重复调用。1. 工具返回的结果格式混乱模型无法理解。2. 问题本身需要多步复杂推理超出模型能力或迭代次数限制。1.规范化工具输出确保返回的是清晰、简洁的字符串。2.增加max_iterations或优化提示词引导其总结。检查verbose日志看是否在重复同一操作。解析错误Parsing Error。Agent输出的Action:或Action Input:格式不符合提示词要求。1. 设置handle_parsing_errorsTrue让执行器尝试修复。2. 使用更稳定的原生Function Calling方式bind_functions。3. 换用推理能力更强的模型如GPT-4。5.2 提升工具调用可靠性的实战技巧给工具起个好名字工具名应像函数名一样清晰、见名知义如calculate_math_expression就比tool1好得多。描述即契约在工具描述中除了功能最好写明输入格式的精确示例。例如“输入必须是一个可计算的数学表达式字符串如‘(23)*4’。”少即是多初期不要给Agent太多工具超过5个过多的选择会增加模型的困惑。随着智能体能力增强再逐步扩展工具箱。善用系统提示词System Message你可以在创建Agent时在提示词模板前加入强化的系统指令如“你是一个乐于助人的助手并且必须优先使用提供的工具来获取准确信息或执行计算。如果你不确定可以承认知识的局限性。”实施后处理Post-processing对于计算器这类工具在调用前可以对用户输入或模型生成的表达式进行一次简单的清洗和验证如移除中文符号提高成功率。5.3 从双工具到“多工具时代”的演进本项目实现了计算器和时间两个工具。以此为基石你可以轻松扩展到“多工具时代”新增工具只需按照tool的格式定义新函数并将其添加到tools []列表中即可。例如添加一个网络搜索工具或数据库查询工具。工具路由Tool Routing当工具数量很多时可以考虑分层或分类。例如先让一个“路由Agent”判断问题属于“计算”、“查询”、“创作”中的哪一类再调用相应的子工具集。这属于更高级的多智能体协作范畴。记忆与状态管理目前的Agent是“无状态”的每次对话独立。通过引入ConversationBufferMemory等组件可以让Agent记住之前的对话历史和工具调用结果处理更复杂的多轮任务。让Agent自主选择工具是构建实用AI应用的关键一跃。它打破了LLM作为“纯聊天机器人”的局限将其升级为一个可以主动操作数字世界、获取实时信息的“智能执行体”。从今天这个简单的计算器和时间工具开始你的Agent已经拥有了最初的“自主意识”。接下来为它装备更多工具定义更复杂的任务一个真正强大的数字助手就在眼前。