引言为什么很多 Agent 看起来“像会做事”很多人第一次看到 Agent会觉得很神奇。例如帮我查天气帮我搜航班帮我发邮件帮我读数据库帮我调用公司内部接口模型居然真的能“去做”。于是很多人会误以为大模型本身就会查天气、会发邮件、会操作系统。但实际上大模型本身什么都不会。它既不能联网也不能直接访问数据库更不会真的帮你点按钮。真正让 Agent 看起来“会做事”的关键是 Tool Calling工具调用。一句话理解模型负责“决定要做什么”工具负责“真正执行”。例如用户帮我查一下北京明天的天气。模型并不会直接知道天气。它真正做的是我需要调用 weather_tool(city北京)然后程序去执行真正的天气 API再把结果返回给模型。最后模型再整理成自然语言回复用户。所以一个真正的 Agent本质上通常是用户 → 模型判断是否需要工具 → 调用工具 → 得到结果 → 模型整理输出这篇文章我们就来讲清楚什么是 Tool / Function Calling模型到底是怎么调用工具的如何在 LangChain 中编写自己的 Tool如何让 Agent 调用你的数据库、API、公司系统一、什么是 Tool Calling所谓 Tool Calling就是给模型一组“它可以使用的工具”由模型自己决定什么时候调用。例如你给模型两个工具1. 查询天气 2. 查询股票然后用户说北京明天天气怎么样模型会自动判断这个问题需要用“查询天气”工具。而不会去调用股票工具。再比如帮我查一下英伟达最近股价。模型就会选择股票工具。Tool Calling 和普通 Prompt 最大区别普通 Prompt用户提问 → 模型直接回答Tool Calling用户提问 → 模型判断是否需要工具 → 调用工具 → 拿到结果 → 再回答所以Tool Calling 是 Agent 真正开始“行动”的第一步。二、Function Calling 到底是什么你可能会看到两个名字Tool CallingFunction Calling它们本质上几乎是同一个东西。区别只是Tool更偏 Agent / LangChain 里的说法Function Calling更偏 OpenAI API 的说法例如OpenAI 会要求你先告诉模型{name:get_weather,description:查询城市天气,parameters:{city:string}}然后模型可能返回{tool_call:{name:get_weather,arguments:{city:北京}}}这时你的程序再真正去执行get_weather(北京)最后把结果回给模型。所以要特别记住模型不会真的执行函数。它只是“告诉你它想调用哪个函数”。真正执行的是你的代码。三、一个最简单的 Tool 示例先看一个最小例子。我们写一个天气工具fromlangchain.toolsimporttooltooldefget_weather(city:str)-str:查询指定城市的天气returnf{city}今天晴天25度。这里函数名get_weather参数city返回值字符串注释告诉模型这个工具是干什么的注意这个 docstring 很重要查询指定城市的天气因为模型会根据这个描述判断什么时候应该调用这个工具。四、让模型真正调用 Tool接下来把工具交给模型。fromlangchain_openaiimportChatOpenAIfromlangchain.agentsimportinitialize_agent,AgentType llmChatOpenAI(modelgpt-4.1-mini)tools[get_weather]agentinitialize_agent(toolstools,llmllm,agentAgentType.OPENAI_FUNCTIONS,verboseTrue)然后调用responseagent.invoke(北京今天天气怎么样)print(response)运行时你会看到类似过程模型判断需要调用 get_weather 调用参数city北京 工具返回北京今天晴天25度。 最终回答北京今天晴天25度。这就是一个最基础的 Agent Tool Calling。五、自定义 Tool调用你自己的 API真实项目里你不会只查天气。更常见的是调公司接口查数据库调 ERP调 CRM调订单系统调 MCP 平台例如tooldefquery_order(order_id:str)-str:根据订单号查询订单状态# 实际项目里这里通常会调用数据库或 HTTP APIiforder_id123456:return订单123456已发货预计明天送达。return未找到订单。然后responseagent.invoke(帮我查一下订单123456现在到哪了)模型就会自动提取order_id 123456然后调用query_order。这也是为什么很多企业里的 Agent最终看起来像“会操作业务系统”。因为它背后其实是LLM 公司已有接口六、Tool 最重要的其实是描述很多人第一次写 Tool 时会觉得代码写好了为什么模型不用最常见的原因不是代码错了而是 Tool 描述太差。例如tooldeffoo(x:str):return...模型根本不知道这个工具是干什么的。更好的写法应该是tooldefsearch_flight(city:str)-str:查询指定城市最近的航班信息Tool 最好满足三点名字清楚注释清楚参数清楚例如tooldefsend_email(to:str,subject:str,content:str)-str:向指定邮箱发送邮件模型看到后就更容易知道什么情况下该调用参数应该填什么七、Tool 可以不只是返回字符串真实项目里Tool 往往会返回结构化数据。例如tooldefget_user_info(user_id:str)-dict:根据用户ID查询用户信息return{name:张三,vip:True,balance:120.5}模型收到后可以继续推理用户是 VIP余额 120.5 元。很多复杂 Agent本质上就是调用工具 → 得到结构化结果 → 再调用下一个工具 → 最后总结八、多个 Tool 时模型如何选择例如tools[get_weather,query_order,send_email]然后用户说帮我查一下订单123456模型通常会自动选择query_order而不是天气或邮件。所以 Agent 的关键不是“写很多 Tool”而是Tool 描述要足够清晰让模型知道该选哪个。如果两个 Tool 描述太像模型就容易选错。例如search_user query_user模型就不一定分得清。更好的方式是根据用户ID查询用户资料 根据手机号查询用户资料九、Tool Calling 的局限虽然 Tool Calling 很强但它也有几个常见问题。1. 模型可能调用错工具例如本来该查订单却调用了查用户2. 模型可能参数提取错误例如订单123456被错误提取成123453. 模型可能明明不需要工具却还是调用因此真实项目里通常会加参数校验权限校验白名单Tool 调用日志例如ifnotorder_id.isdigit():return订单号格式错误十、企业项目里Tool 往往就是“系统能力接口”如果你做的是企业 Agent那么你的 Tool 很可能不再是查天气查股票而是查询订单创建工单发起审批查询 CRM查询数据库调用 MCP调用内部微服务例如你之前做的 MCP 平台本质上就非常适合作为 Agent 的 Tool 层。因为 MCP 本身就是把各种系统能力统一封装成标准接口。那么 Agent 只需要模型决定调用哪个能力 → MCP 执行 → 返回结果这正是企业级 Agent 最常见的架构。十一、一个推荐的 Tool 设计原则如果你准备自己设计 Tool建议遵守下面几个原则一个 Tool 只做一件事名字和描述尽量明确参数不要太多Tool 不负责复杂逻辑复杂流程交给 Agent 编排例如不要写万能业务处理工具而要拆成查询订单查询用户创建工单发送短信这样模型才更容易选对。十二、下一步Tool Calling 之后才是真正的 Agent很多人第一次接触 Tool Calling会觉得这不就是模型调用函数吗没错。但真正的 Agent并不是只调用一次 Tool。它通常会思考 → 调工具 → 看结果 → 再思考 → 再调工具 → 最终完成任务例如用户帮我安排下周去上海出差Agent 可能会查日程查机票查酒店比较预算发确认邮件而这背后其实就是很多 Tool 串起来。下一篇我们就会进入真正的 AgentReAct模型如何边思考、边调用工具、边观察结果。结语一句话总结Tool Calling 是 Agent 真正开始“行动”的能力。模型不负责真正执行。模型真正负责的是判断是否需要工具选择哪个工具提取参数根据结果继续推理而你负责提供 Tool执行 Tool返回结果只要你掌握了 Tool Calling你就已经迈出了从“聊天机器人”到“真正 Agent”的第一步。