概要

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

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

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

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

概要

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

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

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

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

例如：

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

概要

企业知识库项目最常见的错觉是：上传几份文档，问几个预先准备好的问题，模型回答得像模像样，于是大家认为项目已经完成了大半。

但 Demo 能回答，不等于系统有人用；有人试用，也不等于能够进入真实业务流程。

我参与过企业智能问数、卡片检索和诊断报告类 AI 应用的设计与交付。实践中真正困难的部分通常不是“把向量数据库接上”，而是让知识、检索、权限、评测和业务动作形成一个可以长期运营的闭环。

本文总结企业知识库从 Demo 走向生产时最容易忽略的五个问题。

一、Demo 验证的是技术链路，用户需要的是任务结果