聊天机器人只需要会"说话"，而 Agent 要"干活"——查天气、订机票、改文档、调接口。如果模型只能输出文字，就永远无法真正改变现实世界里的任何状态。工具调用（Tool Calling / Function Calling），就是大模型与外部世界之间的那双手：模型在推理过程中决定"需要调用哪个工具、传入什么参数"，由宿主程序真正执行，再把执行结果交还给模型，让它继续下一步推理。
一、工具调用解决什么问题
没有工具调用时，模型的知识截止于训练数据，也无法执行任何操作。有了工具调用，模型可以查询实时信息、读写业务系统、触发工作流。它的关键不在于模型本身会"用"工具，而在于把"决策"与"执行"分离：模型只负责判断该做什么，程序负责可靠地做到。
二、从各家自研到 MCP 标准
早期各家大模型 API 各自定义工具调用的格式，开发者每接一个模型就要重写一层适配代码。2024 年底，Anthropic 开源了 MCP（Model Context Protocol）协议，试图统一"模型如何连接工具与数据源"这件事。在 MCP 的架构里，宿主应用作为客户端，通过标准协议连接一个个 MCP Server，每个 Server 对外暴露若干工具与资源。工具接入一次，就能在不同支持 MCP 的应用间复用，生态价值由此而来。
三、落地时最容易踩的三个坑
第一，权限与确认。工具一旦能发邮件、能下单、能删数据，就等同于把真实世界的操作权交给了模型。生产环境必须遵循最小权限原则，高风险操作保留人工确认环节。第二，工具描述的质量。模型靠工具的名字与描述决定何时调用它，描述含糊、参数 schema 不精确，调用准确率就上不去——给工具写文档，和给函数写注释一样重要。第三，失败与循环。工具可能超时、报错、返回脏数据，模型要能读懂错误并自我修正；同时必须限制最大调用轮次，防止模型在错误路径上空转消耗。
四、怎么选
如果 Agent 只在自己应用内部调用少量函数，直接用平台自带的函数调用能力最省事；如果需要跨应用协作、或想接入开源工具生态，MCP 是更面向未来的选择。记住一句话：工具是 Agent 的手，权限是拴住这只手的缰绳，二者缺一不可。
【参考来源】MCP 为 Anthropic 于 2024 年 11 月开源的开放协议（官网 modelcontextprotocol.io），其余综合整理自公开发布的行业信息与主流大模型厂商 API 文档的通用实践。