概要

普通聊天接口让大模型“回答问题”，Function Calling 则让大模型参与“选择并调用系统能力”。

两者表面上都接收消息并返回结果，但工程目标完全不同：普通聊天主要生成自然语言；Function Calling 需要模型、工具、权限、状态和错误处理共同组成一个执行闭环。

我在企业诊断报告类 AI 项目中设计过兼容 OpenAI Function Calling 格式的轻量工具调用框架，也做过 MCP 客户端与服务端集成。本文从工程角度说明两者的区别，以及什么时候值得引入工具调用。

普通聊天：输入消息，输出文本

概要

提到企业大模型应用，很多方案的第一反应都是：把资料放进向量数据库，搭一套 RAG，再做一个聊天页面。

RAG 很有价值，但它解决的是“从非结构化知识中找到相关证据，并辅助模型生成回答”。如果业务真正需要的是精确计算、实时查询、流程执行或规则判断，先上 RAG 反而可能绕远路。

在企业智能问数、知识检索和自动诊断报告的实践中，我越来越倾向于先判断任务类型，再决定使用 RAG、工具调用、规则引擎还是普通软件功能。

场景一：答案必须来自实时结构化数据

例如：

• 查询本月某区域销售额；
• 统计当前库存、订单和告警数量；
• 对比两个时间段的转化率；
• 按组织、产品和客户层级聚合数据。

高级 Java 与 AI 应用工程（四）：LLM、RAG、Function Calling 与 MCP

技术定位

企业 AI 应用的本质是将概率模型嵌入确定性系统：程序负责身份、权限、数据、工具与审计，模型负责语言理解、归纳和受约束的决策。RAG 解决知识与事实来源，Function Calling/Skill 解决受控动作，MCP 解决工具互操作，评测与观测解决持续可信。

1. 从“聊天”到“业务系统”

LLM 擅长语言理解、信息抽取、归纳与受约束的决策；它不天然可靠、不了解实时数据，也不具备权限。生产系统应把模型放在受控流程中：模型负责推理，程序负责权限、数据、动作和校验。